vLLM / SGLang / TensorRT-LLM / TGI

サーバ向けエンジンが解いている問題

ローカルで1人が使うときは「自分の返事が速いか」だけを気にすれば十分でした（第6章）。サーバでは、見るべき数字が増えます。

やっかいなのは、これらが引っ張り合うことです。たくさんまとめて計算すればスループットは上がりますが、1人あたりの待ち時間は延びがちです。どこで折り合いをつけるかが、運用の腕の見せどころになります。

3つの基本技: 連続バッチ・PagedAttention・プレフィックスキャッシュ

どのサーバ向けエンジンにも、ほぼ共通して入っている技があります。くわしくは第15章で扱うので、ここでは要点だけ押さえます。

flowchart TD
  R["次々に届くリクエスト"] --> S["スケジューラ
連続バッチ処理"]
  S --> P["先頭が同じなら
キャッシュを再利用"]
  P --> G["GPUでまとめて計算"]
  G --> K["KVキャッシュ
ページ単位で管理"]
  K --> G
  G --> O["各ユーザーへ
ストリーミング返信"]

エージェント（第20章）やコーディング支援のように、同じ長い文脈を何度も送り直す使い方が増えたことで、プレフィックスキャッシュの重要性はますます高まっています。

vLLM: サーバ向けの定番

vLLM は、カリフォルニア大学バークレー校の Sky Computing Lab で生まれたオープンソースの推論・サービングエンジンです。PagedAttention を武器に2023年に登場し、いまでは2,000人を超える貢献者がいる大きなプロジェクトになりました。2025年5月には PyTorch Foundation のホストプロジェクトになっています。

# インストール（README では uv を推奨）
uv pip install vllm

# Hugging Face のモデルIDを指定して、OpenAI互換サーバを起動
vllm serve Qwen/Qwen2.5-1.5B-Instruct
# → 既定では http://localhost:8000/v1

最新版は 2026年10月18日の v0.32.0 で、ほぼ2週間おきに新しい版が出ています2026年10月時点。中身は2025年に作り直された V1エンジンに一本化され、古いV0エンジンは完全に廃止されました。V1では、チャンク化プリフィルなどの最適化が既定で有効になっています。

• 対応モデル: Hugging Face 上の200以上のアーキテクチャ（MoE、ハイブリッド型、マルチモーダル、埋め込みモデルなど）
• 量子化: FP8、MXFP4、NVFP4、INT4、GPTQ/AWQ、GGUF など
• 分散: テンソル並列、パイプライン並列、エキスパート並列など
• API: OpenAI互換に加え、Anthropic Messages API と gRPC
• ハードウェア: NVIDIA・AMD・Intel の GPU、CPU のほか、TPU や Ascend、Apple シリコンなどはプラグインで対応

迷ったらまず vLLM、と言われるのは、この「対応範囲の広さ」と「情報の多さ」のためです。

SGLang: エージェント時代の追い上げ役

SGLang は、非営利団体 LMSYS がホストするオープンソースの推論フレームワークです（Apache 2.0）。2023年12月の論文で、KVキャッシュを木構造で管理して使い回す RadixAttention を提案しました。共通の先頭を持つリクエストが多いほど、計算を大きく省けます。

# インストールと起動（公式 Quickstart より）
uv pip install --prerelease=allow sglang
sglang serve Qwen/Qwen3-0.6B --host 0.0.0.0 --port 30000

README は SGLang を「エージェント的なワークロード、大規模サービング、強化学習のロールアウトに最適化」と紹介しています。強化学習で大量の文章を生成させる用途では、verl や slime など多くの学習フレームワークが SGLang を組み込んでいます。最新版は 2026年10月16日の v0.5.22 です2026年10月時点。

対応ハードウェアも広く、NVIDIA・AMD の GPU、Google TPU、Intel、Huawei Ascend、Apple シリコンなどが README に並んでいます。OpenAI互換・Anthropic互換のAPIに加え、プリフィルとデコードを別のGPUに分ける構成（PD分離）や、KVキャッシュをCPUメモリやストレージに階層的に置く HiCache も用意されています。

TensorRT-LLM: NVIDIA の純正チューン

TensorRT-LLM は、NVIDIA が開発するオープンソース（Apache 2.0）の推論ライブラリです。NVIDIA の GPU 専用ですが、そのぶん Blackwell 世代などの最新GPU向けに作り込まれたカーネルや、FP8・NVFP4 といった低精度フォーマットを使い切れるのが持ち味です。

かつては「モデルをあらかじめ TensorRT のエンジンにビルドする」手間がかかることで知られていました。いまは PyTorch を土台にした設計に変わり、Hugging Face のモデルIDを渡すだけでサーバを起動できます。

# NGCの公式コンテナ内で、OpenAI互換サーバを起動（Quick Start Guide より）
trtllm-serve "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

PyPI 上の最新の安定版は 2026年4月の 1.2.1 で、開発版は 1.4.0rc1（2026年10月21日）まで進んでいます2026年10月時点。NVIDIA の Dynamo や Triton Inference Server とも連携できるように作られています。

TGI: 役目を終えたパイオニア

TGI（Text Generation Inference）は、Hugging Face が自社の Hugging Chat や Inference Endpoints のために作ったサーバです。連続バッチ処理やトークンのストリーミングを早くから実用化し、一時期はvLLMと並ぶ定番でした。

TGI の README は、自分たちが「推論エンジンが transformers のモデル定義に頼る流れ」を作り、それが後続のエンジンに受け継がれた、と振り返っています。ツールが引退しても、その考え方は vLLM や SGLang の中に生きているわけです。

エンジンの上の層: NVIDIA Dynamo

モデルが巨大になり、1台のGPUサーバでは足りなくなると、「何十台ものサーバにどうリクエストを配るか」が問題になります。そこで登場したのが、エンジンの上に載るオーケストレーション層です。

NVIDIA Dynamo は、README で自らを「推論エンジンを置き換えるのではなく、SGLang・TensorRT-LLM・vLLM を協調するマルチノードの推論システムに変える層」と説明しています。最新版は 2026年10月22日の 1.6.0 です2026年10月時点。

flowchart TD
  U["大量のリクエスト"] --> D["Dynamo
ルーティングと自動スケール"]
  D --> P["プリフィル用GPU群
入力を読む"]
  P --> X["KVキャッシュを転送"]
  X --> C["デコード用GPU群
返事を書く"]
  P -.-> E["中身は vLLM・SGLang・
TensorRT-LLM"]
  C -.-> E

主な機能は、プリフィルとデコードを別々のGPU群に分けて増減させる分離型サービング、KVキャッシュの重なりを見てリクエストを振り分ける KV-aware ルーティング、KVキャッシュをGPUからCPU・SSDへ逃がす仕組みなどです。プリフィルは計算性能、デコードはメモリ帯域が効くという第6章の話が、そのまま設計に反映されています。

比較と選び方

実際の選び方は、次の順で考えると迷いにくくなります。

1. まず vLLM か SGLang で動かしてみる。どちらも OpenAI互換APIなので、アプリ側のコードはほぼ同じで済む
2. 使うモデルとハードウェアで、両方のベンチマークを自分で取る。結果はモデルや設定でよく入れ替わる
3. NVIDIA GPU を限界まで使い切りたいなら TensorRT-LLM も比較に入れる
4. 複数台にまたがる規模になったら、Dynamo などのオーケストレーション層を検討する

次に読む章

• 第15章 KV cache / batching / paged attention — 基本技をもっとくわしく
• 第16章 speculative decoding / EAGLE / DFlash — 生成をさらに速くする
• 第26章 MoE — エキスパート並列が必要になる理由