vLLMとTGI｜ローカルLLM

🎓 レベル：発展　|　重要度：B（推奨） 📎 前提：llama.cpp　|　原理：推論の実務（機械学習）

要点（結論先出し）

vLLM / TGI＝同時多リクエストのスループットに振った推論サーバ。**連続バッチング（continuous batching）**と PagedAttention でGPUを遊ばせない（要最新確認）。
1人の対話なら llama.cpp/Ollama で十分。**「複数人・複数リクエストを同時に捌く」**ときに効く。
主に**GPU専有・safetensors（AWQ/GPTQ等）**前提。Apple Silicon や CPUオフロード主体のローカルとは設計思想が違う。

概念 ── 「同時に何件捌くか」を最大化する

単機チャットのエンジンは1リクエストを速く返すのが目的。対して vLLM/TGI は多数のリクエストを並べてGPUを埋め尽くす設計です。鍵は2つ（要最新確認）：

連続バッチング：リクエストの開始/終了がバラバラでも、空いたスロットに次を詰めて常時フル稼働にする。固定バッチの待ち時間を消す。
PagedAttention：KVキャッシュをOSの仮想メモリのようにページ単位で管理し、断片化を抑えてVRAMを有効活用。同時実行数を増やせる。

仕組み ── バッチを動的に詰める

flowchart LR
  R["多数のリクエスト"] --> SCHED["スケジューラ（連続バッチング）"]
  SCHED --> KV["KVをページ管理（PagedAttention）"]
  KV --> GPU["GPUを常時フル稼働"]
  GPU --> OUT["各リクエストへストリーム返却"]

結果として、同時実行時のスループットは単機向けエンジンを大きく上回ります（公称で数倍〜十数倍の例も・要最新確認）。

動くコマンド（OpenAI互換サーバ例）

# vLLMをOpenAI互換APIサーバとして起動（モデル名は要最新確認）
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --port 8000 --max-model-len 8192

起動後は OpenAI互換API と同じ叩き方で接続できます。

運用の勘所

GPUをフルに専有できる環境向け。VRAMが潤沢なほど同時実行数を伸ばせる。
ローカルでは「家族/チームで共有する常駐サーバ」「同時に多数の文書を処理するバッチ」などで効く。
単発・対話・Apple Silicon・CPU主体なら llama.cpp/Ollama のほうが素直で軽い。

なぜそうするか

ローカルでも「1人がたまに使う」と「複数人が同時に使う」は要求が真逆。後者では**1件の速さよりGPU占有率（同時処理量）**が効きます。vLLM/TGIはそこに最適化しているので、用途が同時多人数なら選ぶ価値があります。クラウド規模の本番サービングになると話はMLOpsへ → オンライン推論サービング。

⚠️ よくある落とし穴

単機の対話で導入して重い：1人用途ではオーバースペック。体感が改善しないどころか設定が増える。
VRAM前提を見落とす：GPUに丸ごと載る構成が基本。CPUオフロード主体なら llama.cpp。
GGUFをそのまま使えると思う：vLLMは主にsafetensors系（AWQ/GPTQ）。形式とエンジンの相性を確認 → 量子化方式（k-quantsとGPTQとAWQ）
スループット数値を鵜呑み：構成・モデル・同時数で激変。自分の負荷で測る。

対応lab

同時リクエストの体感はストリーミングと並行リクエストの検証で扱う。