7月27日、Matt Fosterが「Netflix Details Its In-House LLM Serving Platform with Triton and vLLM」と題した記事を公開した。Netflixが自社のLLM推論プラットフォームをTritonとvLLMで構築した際のアーキテクチャ設計と運用上の知見について詳しく紹介されている。
vLLMがGPUリソース管理のためにリクエストを一時停止・再開した瞬間、制約付きデコーディングのステートが静かにズレる——Netflixが公開した技術ブログは、こうした「想定外の罠」を率直に語っている。LLMを本番環境で安定稼働させることは、モデルを動かすこと自体よりも遥かに難しい。その現実がこの記事には詰まっている。
既存のJVMサービング層にLLMを統合する
Netflixの推論基盤は、既存のJVMベースのサービング層の上に構築されている。このJVM層は、ルーティング、特徴量取得、候補生成、後処理、ログ収集といった本番ワークフローを引き続き担う。
モデルサイズに応じて処理先が変わる構成だ。小規模なモデルはCPU上でインプロセス実行し、大規模なリクエストはMSS（Model Serving Service）へ委譲する。MSS側ではNVIDIA Triton Inference Serverがモデルのロード、バッチ処理、GPUスケジューリング、マルチフレームワーク対応を担う。TritonはNVIDIAが開発するオープンソースの推論サーバーで、TensorFlow・PyTorch・ONNXなど複数のフレームワークに対応したモデルを統一的に管理・配信できる点が特徴だ。この構造により、推論がローカルCPUとリモートGPUの間を行き来しても、アプリケーション側の本番ワークフローは変わらない。
GPUパスでは、vLLMを採用した。vLLMはUC Berkeleyが開発したPagedAttentionベースのオープンソース推論エンジンで、KVキャッシュをページ単位で管理することで高いスループットを実現する。役割分担は明確だ。Tritonがサービング環境全体（モデル管理・スケジューリング）を制御し、vLLMが実際の推論とカスタム拡張を担う。アプリ側にはOpenAI互換APIとKServe（HTTP/gRPC）フロントエンドを公開している。
最も苦労した箇所：バージョン互換性と制約付きデコーディング
記事で特に詳しく語られているのが、この2点だ。
Triton×vLLMのバージョン固定問題
TritonとvLLMは独立して開発されているため、バージョンの組み合わせによってはバックエンドのロードに失敗してデプロイが通らないケースが発生した。Netflixは動作確認済みのバージョンペアをピン留めして管理することで対処している。
モデルのパッケージング方式についても2種類を比較している。TritonのPythonバックエンドとvLLMバックエンドだ。vLLMバックエンドを使う方が、モデルとフロントエンドを独立して進化させやすいと報告している。どちらを採用するかは、推論エンジンの選択ではなく、モデルとサービング環境の結合度に関わる設計判断だ。
制約付きデコーディングのステート管理
制約付きデコーディング（Constrained Decoding）とは、モデルの出力を特定のフォーマット（例：有効なJSON）に強制する手法だ。生成ステップごとに「次に選べるトークン」をフィルタリングする。このフィルタリングルールは、それまでに生成されたトークン列全体に依存するため、デコーダーはリクエスト全体を通じて状態を保持し続ける必要がある。
問題はvLLMのリソース管理にある。vLLMはGPUリソースを効率的に使うためリクエストを一時停止・再開する場合がある。この再開のタイミングで、デコーダーが保持していた状態とトークン履歴が同期ズレを起こす。Netflixはこの状態のズレを検知し、生成再開前に状態を再構築するロジックを独自に追加した。これはvLLMの基本動作に起因する想定外の罠であり、制約付きデコーディングを本番投入するうえでの重要な実装ポイントだ。
Hugging Face互換性が不十分な自社モデルについても、vLLMの拡張ポイントを使ってカスタムアーキテクチャとデコーディング挙動を実装している。
デプロイ戦略
モデルレベルの変更管理にはRed-BlackデプロイとVersionedデプロイの2戦略を使い分けている。
- Red-Blackデプロイ：新旧の環境（Black／Red）を並列稼働させ、トラフィックを切り替えることでダウンタイムなしにデプロイする方式。切り戻しが容易なのが利点だ。
- Versionedデプロイ：新旧のリビジョンを明示的なバージョン番号で並存させる方式。入出力スキーマに非互換な変更が生じた場合でも、コンシューマー側が移行を完了するまで旧バージョンを維持できる。
スキーマ変更を伴うモデル更新が頻繁に発生しうるLLM運用では、Versionedデプロイによる段階的移行が特に有効に機能する。
関連する他社の取り組み
同様のアプローチはUberも採用している。UberはGenAIゲートウェイでOpenAI互換インターフェースを外部・内部モデルに対して統一的に提供し、認証・キャッシュ・オブザーバビリティ・ルーティングを集約している。実装の詳細はNetflixと異なるが、アプリケーション統合をモデルやランタイムの変化から隔離するという設計思想は共通している。
Netflixの事例が示すのは、共通インターフェースを設けてもその下層の作業は消えないという現実だ。パッケージング、バージョン互換性の管理、制約付きデコーディングのステート同期、デプロイ分離——いずれも各レイヤーで個別のエンジニアリングが必要になる。抽象化の恩恵を受けながらも、その下で何が起きているかを把握し続けることが、LLMの本番運用では依然として不可欠だ。
詳細はNetflix Details Its In-House LLM Serving Platform with Triton and vLLMを参照していただきたい。
