NetflixのLLMサービング基盤をvLLMとTritonで読み解く

LLMを本番プロダクトに乗せると決めた瞬間、「外部APIをそのまま叩き続けていいのか」で必ず立ち止まる場面が来ます。

Netflixがこの7月に公開した自社サービング基盤の解説記事は、その問いに大企業がどう答えたかを丁寧に書いています。

今回はvLLMとTritonをなぜこの組み合わせにしたのかを追いながら、規模を問わず本番運用で効いてくる原則を持ち帰りたいと思います。

In-House LLM Serving at Netflix

By AI Platform’s Model Runtime team and Inference team

netflixtechblog.com

Netflix が自社で LLM 推論基盤を作った理由

Netflixが選んだのは「ホストされたAPIに寄せる」ではなく「フルスタックを自社運用する」路線でした。

理由はシンプルで、レコメンドやパーソナライズを支える既存のML基盤に、LLMを地続きで乗せたかったからです。

「安いから」「囲い込みたいから」ではなく「他のMLと同じ運用レールに載せたいから」が主因、というのが大事な視点です。

LLMだけを別系統に切り出すと、特徴量パイプラインもABテスト基盤もロギングも全部作り直しになります。

全体像はざっくり3層です。

モデル配置はTriton、ルーティング・ABテスト・特徴量取得・後処理はJVM統一サービング層、その中のModel Scoring Service（MSS）が大型モデルの推論をTritonに委譲します。

この構造がなぜ効くのかは、後半で1つずつ剥がしていきます。

vLLM をペイブドパスエンジンに選んだ判断基準

Netflixは2025年夏に推論エンジンを再評価しています。

オープンソースエンジンが商用エンジンとの性能差を大きく縮めたタイミングでした。

候補の主軸はTensorRT-LLMとvLLMで、結論としてvLLMを「ペイブドパス（社内で推奨する標準ルート）」に据えました。

速さだけで選んだのではなく、日々の触りやすさで選んだ判断です。

TensorRT-LLM から vLLM に切り替えた4つの決め手

原文で挙げられている評価軸は以下です。

1. カスタムモデルアーキテクチャを多段コンパイルパイプラインなしで読み込める
2. カスタムデコーディングロジック向けの拡張フックが用意されている
3. デバッガビリティが高い
4. MLエンジニアにとって馴染みがある

面白いのは1つ目です。

カスタムモデルを載せ替えるたびにコンパイルパイプラインを回すのは、開発ループを鈍らせる真犯人になります。

研究チームが試したいモデルを翌日には試せる、という状態を維持するためにvLLMを選ぶ、という判断は個人開発でも同じ理屈で刺さります。

vLLM と Triton を組み合わせる2つの実装パターン

Tritonは複数バックエンドを差し替えられるNVIDIA製の推論サーバです。

NetflixはvLLMをTritonの中に組み込む形で運用しており、組み合わせのパターンは2つあります。

vLLM バックエンドと Python バックエンドの使い分け

vLLMバックエンド（標準ルート）は、モデル配置時にI/O仕様を動的生成します。

OpenAI互換APIがそのまま使え、フロントエンド側を更新してもモデル再配置は不要です。

「フロントとバックのバージョンずれで本番が壊れる」事故を減らせるのが大きい。

Pythonバックエンド（カスタムルート）は、前後処理を書き込みたいとき、非標準の実行フローを差し込みたいときに使います。

I/O仕様は明示的に定義します。

判断軸はシンプルで、基本はvLLMバックエンドで賄い、逸脱が必要な場面だけPythonバックエンドに落とす、という切り分けです。

この「標準ルートを厚くする」設計は、チーム規模が小さいほど効きます。

全部カスタムで書き始めると、あとでメンテできなくなるパターンです。

JVM 統一サービング層が支える AB テストと候補生成

ここが個人的に一番アツいポイントです。

NetflixのMLはすべてJVM上の共通サービング層（Model Scoring Service, MSS）を経由します。

小型CPUモデルはMSSの中で直接動かし、大型GPUモデルはgRPCでTritonに委譲する形です。

LLMもこの流れに乗せることで、既存のMLと同じABテスト・特徴量取得・ロギング基盤がそのまま使えるようになります。

候補生成から推論後処理までを1本の線でつなぐ

1リクエストが通る道はこうです。

1. リクエストルーティング
2. ABテスト割り当て
3. 候補生成（レコメンドの候補セット取得等）
4. 特徴量取得
5. 推論（LLMはTriton経由）
6. 後処理
7. ロギング

「LLMだけ別サービスに切り出す」設計だと、この一連の流れをLLM用に再実装する羽目になります。

既存レールに載せると、ABテストや特徴量パイプラインをそのまま流用できて、比較実験のコストが劇的に下がります。

constrained decoding で推論結果を型にはめる仕組み

LLMの出力をJSONスキーマや正規表現に強制的に沿わせる仕組みがconstrained decodingです。

生成された文字列を後段で頑張ってパースするのではなく、生成の段階で「文法上あり得ないトークン」の確率をゼロにします。

NetflixはvLLMのカスタムlogits processorインターフェース経由でステートマシンとして実装しています。

ここで面白いのがvLLM V0からV1への移行過程での学びです。

V0はリクエスト単位で動く実装で、PythonのGIL制約によりCPUバウンドになり、バッチサイズに応じてレイテンシが線形に伸びていました。

V1ではバッチレベル処理に切り替え、C++マルチスレッド実装でGILを回避しています。

update_state(batch_update)でバッチの変化を追跡する形です。

「LLMの出力形式をパーサ側で守らせる」文化からの脱却は、実装レベルで効きます。

JSONパースエラーで消耗しているなら、生成時に型を効かせる方向へ切り替えたいところです。

この設計から個人開発者や中小チームが持ち帰れること

Netflixの絵を全部描くのは無理です。

ただ、絵の中の1本の線だけを自分のプロダクトに引くのは、個人でも中小チームでも十分できます。

持ち帰れる原則は4つあります。

1つ目は「標準ルートと逸脱ルートを分ける」。

基本はvLLMバックエンド（設定だけ）で回し、逸脱が必要な場面だけPythonバックエンド（カスタム）に落とす発想は、そのままチーム運用の規律になります。

全部カスタムで書き始めると、半年後に自分が書いたコードで詰みます。

2つ目は「LLMを別系統にしない」。

既存APIサーバや推論基盤に「もう1つのモデル」として同じインターフェースで載せる。

専用のLLM Gatewayを立てる前に、まず今のサービング層に混ぜられないかを考えてほしいです。

3つ目は「出力形式を後処理で守らせない」。

constrained decodingはvLLM自体がOSSなので個人でも使えます。

JSONパースエラーで消耗しているなら、生成時に型を効かせる方が結果的に速いです。

4つ目は「ABテスト基盤の流用」。

LLMのチューニングはABが命です。

既存AB基盤にLLMを乗せられれば、プロンプト変更や温度設定の比較評価コストが激減します。

Netflixの規模をそのまま真似るのではなく、規模を落として原則だけ抜き取る。

この視点で読み直すと、vLLMとTritonという技術選定の裏にあった設計判断が、自分のプロダクトにも輪郭を持ち始めます。