第10章 — LLMエンジン層

LLM Primer VI: AIシステムのスケーリング を章ごとに紹介していくウォークスルー、第10回。エンジンとプラットフォームの境界に名前をつけ、2026年のその層を支配する5つのエンジンを歩く章です。

なぜこの章があるのか

第1章から第9章まで、1回の順伝播が触る機械を歩きました。自己回帰ループ、KVキャッシュ、GPU基盤、それを縮める量子化、遊休時間を隠すバッチング、逐次依存性を破る投機的デコード。どれも pip install して忘れられるライブラリとしては出荷されない。誰かがそれを、モデルを包み、KVキャッシュを所有し、リクエストを連続バッチにスケジュールし、推論APIを公開する単一ノードランタイムに配線する。そのランタイムがエンジンです。第10章はエンジン層の仕事に名前をつけ、プラットフォーム層(第11章)と区別し、同じ仕事に対して異なる機構的トレードオフをする5つのエンジン — vLLM、TensorRT-LLM、SGLang、TGI、Ollama — を歩きます。

10.1 vLLMはPythonネイティブの既定

vLLMは、たいていの本番チームが最初に手を伸ばすべきエンジンです。初心者が考え方すら知らない全ての軸で正しい既定判断を下し、しかもPythonで下す。PagedAttentionが断片化を60〜80パーセントから1桁パーセントまで潰し、同じGPUで達成可能なバッチサイズをおおよそ倍にする。連続バッチングがその上に自然に載り、チャンク化プリフィルがプリフィルとデコードの仕事を同じ反復で混ぜるので両者の境界が死んだ時間にならない。コピーオンライトのプレフィックス共有はブロックテーブル設計から無料。インターフェースは真にオフラインバッチかOpenAI互換HTTPが数行で立ち、新しいモデルアーキテクチャは広いコミュニティのおかげで素早く着地する。特に別のものを選ぶ理由がなければ標準化すべきエンジンです。

10.2 TensorRT-LLMはビルドパイプラインでスループットを買う

TensorRT-LLMの売りは狭い。艦隊が排他的にNVIDIAで、1ドルあたりスループットの1パーセントも重要で、ハードウェア世代ごとにモデル固有のエンジンファイルをコンパイルするエンジニアリング税を払うなら、TRT-LLMは同じハードウェア上でvLLMより15〜35パーセント多くのスループットを抽出します。機構はカーネルレベル。Transformerグラフを NVIDIA固有のIR に落とし、隣接カーネル(layernorm + matmul + activationを1回の起動に融合)を融合し、事前チューニング済みライブラリから形状ごとの最適カーネルを選び、シリアライズされたエンジンを生成し、Triton Inference Server の下で走らせる。融合が重要なのはカーネル起動オーバーヘッドが1回5〜10 μsで、ナイーブな70Bの順伝播はトークンあたり数千回起動するからです。税はビルドパイプラインそのもの — モデルごと、GPUごと、バッチ体制ごとのコンパイル手順で、大半のチームがその運用コストを過小評価します。SGLangはもう一つの特化。RadixAttentionはエンジンがこれまで見た全プロンプトプレフィックスのKVキャッシュを基数木に保存するので、kトークンプレフィックスを共有する2つのリクエストはバッチと時間をまたいで正確にそのkトークンのKVを共有する。長い共有システムプロンプトと短い変種末尾を持つエージェント的ワークロードで、SGLangはvLLM比2〜6倍のスループットを提供し、構造化出力DSLはロジットレベルでJSONスキーマを強制するので出力は検証を通過することが保証されます。

10.3 決定木はヘッドラインスループットではなくワークロード形状を通る

5つのエンジンは小さな決定木に扇状に広がります。開発者ラップトップまたは混合アクセラレータのエッジ → Ollama。本番GPU艦隊、排他的にNVIDIA、高QPS、ビルドパイプラインを正当化するスループットROI → TensorRT-LLM。混合ハードウェアまたは頻繁なモデル入れ替え、プレフィックス重視の構造化パターン(エージェント、ツール呼び出し、長い共有プロンプト)が支配するワークロード → SGLang。混合ハードウェア、一般的なチャットワークロード、深いHugging Face統合 → TGI。それ以外 → vLLM。判断は恒久ではありません。エンジンはAPI境界で互換 — 全てがOpenAIスタイルのHTTPを話す — なので、プラットフォーム層のルータがクライアントコードを変えずにモデル、ワークロード、リージョンごとにトラフィックを移せる。多くの本番スタックは2〜3のエンジンを並行運用します。ヘッドラインベンチマークに注意。「バッチ1のLlama-2-7Bで毎秒何トークン」はどの本番ワークロードも問わない質問への回答です。自分のモデル、自分のプロンプト分布、自分の同時実行プロファイルでベンチマークする。半日で数ヶ月を節約する。

第10章が敷いたもの

この章で説明したどのエンジンも同じ境界で止まります。カーネル、KVブロック、連続バッチングは知っていても、レプリカ、テナント、チェーン、認証は知らない。第11章はそれらの関心事を扱うプラットフォーム層 — Ray Serve、KServe、BentoML、Triton Inference Server — を歩き、選択がフィーチャーの多寡よりむしろ、どの運用モデルがチームの既存インフラと能力に合うかの問題であることを示します。

次回 — 第11章: プラットフォームとオーケストレーション層。 Ray Serve、KServe、BentoML、Triton — エンジンの上に座る4つのプラットフォーム、運用文化の合いで選ぶ。