LLM推論最適化完全ガイド2026｜vLLM・TensorRT-LLM・SGLang・Speculative Decoding・Prompt Caching

LLM推論最適化とは｜コスト・レイテンシ・スループットの3軸で勝負する技術

LLM推論最適化(LLM Inference Optimization)は、大規模言語モデルを本番で動かす際のコスト・レイテンシ・スループットを改善する技術の総称です。2026年時点では、同じH100 1台でもナイーブなFP16+静的バッチング実装と、FP8量子化+Flash Attention 3+連続バッチング+Speculative Decoding(投機的デコーディング)を組み合わせた実装では5〜8倍のコスト効率差が出ます。

本記事ではvLLM/TensorRT-LLM/SGLang/LMDeployの主要推論エンジン比較、KV Cache/PagedAttention/Speculative Decoding/Prompt Cachingの主要技術、そしてrenue独自視点として「クラウドAPI運用者視点の推論最適化5判断基準」を解説します。LLM運用全般についてはAgentOps完全ガイド、モデル選定はLLM API比較も参照してください。

LLM推論の2フェーズ｜Prefill と Decode

LLM推論は根本的に異なる2つのフェーズに分かれます。

Prefill(プロンプト処理)：入力プロンプト全体を一度に処理してKVキャッシュを作成。計算集約的でGPU演算性能が支配的。TTFT(Time To First Token)を決める
Decode(逐次生成)：トークンを1個ずつ生成しKVキャッシュに追記。メモリ帯域律速でGPUメモリ帯域が支配的。TPOT(Time Per Output Token)を決める

この非対称性がLLM推論最適化の核心です。Prefillは計算並列化(連続バッチング/Prefill Chunking)で、Decodeはメモリ効率化(KV Cache最適化/量子化/Speculative Decoding)で別々に攻めます。

KV Cache と PagedAttention｜メモリ断片化を解消

KVキャッシュは過去のトークンのAttention計算結果を保持する仕組みで、Decodeフェーズの高速化に必須ですがメモリを大量消費します。従来の実装では「最大シーケンス長ぶんの連続メモリを事前確保」していたため、実際の生成長が短い場合に大量のVRAMが無駄になっていました。

PagedAttention(vLLM考案)は、OSの仮想メモリページのようにKVキャッシュを小ブロックに分割して動的に割り当てる手法です。これにより断片化がほぼゼロになり、同じGPUで2〜4倍のバッチサイズが可能になります。2026年時点でほぼ全ての主要推論エンジンがPagedAttentionまたは同等の仕組みを採用しています。

Continuous Batching(連続バッチング)｜GPUを遊ばせない

従来の静的バッチングでは、バッチ内で最長のリクエストが完了するまで他のリクエストを待たせていました。連続バッチングでは、バッチ内のリクエストが完了するたびに新しいリクエストを即座に投入するため、GPUアイドル時間がほぼゼロになります。これもvLLMが実用化の波を作り、2026年の標準となっています。

Speculative Decoding｜2〜3倍の高速化を品質ゼロ損失で

Speculative Decoding(投機的デコーディング)は、小さなドラフトモデル(1〜7B)で3〜12個の候補トークンを先読み生成し、それらをターゲットモデル(大モデル)が1回の並列Forward Passで検証する手法です。

仕組みの要点

ドラフトモデルが高速に候補を生成(低コスト)
ターゲットモデルが候補を並列検証して受理/棄却を判定
受理率はドメイン特化タスクで70〜90%
棄却されたトークンはターゲットモデルの分布から再サンプリングされるため品質損失ゼロ
結果として2〜3倍の高速化を品質劣化なしに実現

2026年の最新動向として、AWSのP-EAGLE(Parallel EAGLE)がvLLM v0.16.0以降に統合され、K個のドラフトトークンを1回のForward Passで生成する並列化で更なる高速化が実現。事前学習済みP-EAGLEヘッドがHugging FaceでGPT-OSS 120B/20B、Qwen3-Coder 30B向けに公開されています。

Prompt Caching(自動プレフィックスキャッシング)｜共有プロンプトを使い回す

チャットボット・RAG・マルチターン対話などで、多くのリクエストが同じシステムプロンプトや同じRAG文書を含む場合、毎回Prefillし直すのは無駄です。Automatic Prefix Caching(APC)はプロンプトの先頭一致部分のKVキャッシュを再利用して、Prefill時間と計算コストを削減します。

SGLangはこの領域に強く、共有プレフィックスワークロードでは最速クラスの性能を発揮します。vLLMもv0.4以降でAPCをサポート。Anthropic ClaudeやOpenAIもクラウドAPI側でPrompt Cachingを提供しており、長いシステムプロンプトやRAGコンテキストを使う場合はコストが最大90%削減されます。

量子化｜FP16からFP8/INT4への圧縮

FP16/BF16：標準。モデル重みそのままのサイズ
FP8(E4M3/E5M2)：H100以降のハードウェア対応。品質ほぼ無損失で2倍高速・メモリ半減
INT8 (AWQ/GPTQ/SmoothQuant)：品質若干低下でメモリ半減
INT4 (AWQ/GPTQ/NF4)：メモリ1/4、品質はタスクによる

2026年の実務標準は、H100以降ならFP8、A100/コンシューマGPUならINT8 or INT4(AWQ)です。

主要推論エンジン比較(2026年)

エンジン	提供元	特徴	得意領域
vLLM	vLLM Project(OSS)	PagedAttention発祥、本番運用実績豊富	汎用・速い立ち上げ
TensorRT-LLM	NVIDIA	H100最適化、最高スループット	超高スループット要件
SGLang	LMSYS	RadixAttention、自動Prefix Caching最強	共有プレフィックスワークロード
LMDeploy	InternLM	高速・軽量、INT4最適化	コンシューマGPU・軽量運用
TGI	Hugging Face	HFエコシステム統合	HF Hub連携・検証
llama.cpp	ggerganov(OSS)	CPU/Apple Silicon対応	エッジ・ローカル・Mac
Ollama	Ollama(OSS)	llama.cppベースの簡易ランナー	開発時・ローカルPoC

2026年の実測ベンチマーク(H100、公開報告例)ではSGLang v0.4.3とLMDeployがおよそ16,200 tok/s、vLLM v0.7.3が12,500 tok/s、TensorRT-LLMは100並行リクエストで2,780 out-tok/sと報告されています。用途により最適解が変わるため、必ず自ワークロードで計測してから選定します。

レイヤー別最適化チェックリスト

モデル層

必要最小のモデルサイズを選ぶ(70Bより14Bで足りないか検証)
量子化(FP8/INT8/INT4)を適用
小ドラフトモデル+Speculative Decodingを導入
タスク特化ならLoRA/QLoRA(詳細)で小モデルに凝縮

エンジン層

vLLM/TensorRT-LLM/SGLang/LMDeployから用途に最適なものを選定
PagedAttention+連続バッチング+APC有効化
Flash Attention 3、FP8カーネル最適化を有効化
Prefill Chunkingで長プロンプトを分割処理

アプリ層

システムプロンプトを共通化してPrompt Cachingヒット率を最大化
クラウドAPIのPrompt Cachingを活用(Anthropic/OpenAIとも対応)
ストリーミング応答でUX向上
並列リクエスト数をSLOに合わせて制御
キャッシュ(コンテンツハッシュベース)で同一クエリの再実行を回避

クラウドAPI vs セルフホスト｜判断基準

観点	クラウドAPI	セルフホスト(vLLM等)
初期コスト	ゼロ	GPU調達/セットアップ
トークンコスト	従量	GPU時間固定
レイテンシ制御	限定的	自由に最適化
モデル選択	提供モデルのみ	任意モデル
データ主権	ベンダーに依存	完全自社
運用負荷	ほぼゼロ	高い
Prompt Caching	ベンダー提供	APC自前設定

2026年の実務では「月間トークン消費が大きく、かつ機密性要件があり、かつ運用人員がいる」場合のみセルフホストが正当化されます。それ以外はクラウドAPI+LiteLLM等のゲートウェイで十分です。

renueの視点｜クラウドAPI運用者視点の推論最適化5判断基準

renueは広告代理AIエージェント・AI PMOエージェント・Drawing Agent・SEO記事生成エージェント等を複数運用しており、推論最適化の判断基準を5つにまとめています。

(1) まずクラウドAPI+Prompt Cachingで90%カバー：2026年のClaude/GPT-5系ではPrompt Cachingで長いシステムプロンプトのコストが大幅減。自社運用前にまずクラウドAPIの機能を使い切ります。

(2) 小さいモデルで足りないか必ず検証：GPT-5/Opusが必要な場面は実は少なく、Sonnet/GPT-5-miniやQwen/Llamaの小モデルで十分な場面が多いです。API比較で用途別に適正化します。

(3) セルフホストは「月数千万トークン×機密要件」になってから：規模が小さいうちのセルフホストはROIが合いません。コスト上限SLOを決め、超過時に初めて検討します(AgentOpsのコストSLO原則)。

(4) 自社ホスト導入時はvLLM+APC+FP8から：セルフホストを決めたら、初期構成はvLLM+PagedAttention+APC+FP8(H100)が2026年の出発点。その後、ワークロードに応じてSGLangやTensorRT-LLMを検討します。

(5) レイテンシvsコストのトレードオフを先に決める：TTFT重視かTPOT重視か、スループット重視かで最適化方針が変わります。SLOを先に定義しないと最適化が空回りします。

よくある失敗パターン

最大モデルを漫然と使う：70Bが必要な場面は少ない。14B/32Bで品質検証を怠らない
Prompt Cachingを活かせないプロンプト設計：システムプロンプトが毎回変わる設計で共通プレフィックスがない
セルフホスト早すぎ：トラフィックが少ないうちからGPU運用してROIが合わない
量子化後の品質検証なし：INT4で精度が落ちていることに気付かずデプロイ
ベンチマーク盲信：公開ベンチと自ワークロードが合わず期待値ずれ
SLO未定義：何を最適化すべきか決めないまま細部の設定をいじる

よくある質問（FAQ）

Q1. vLLMとTensorRT-LLMどちらを選ぶべきですか？

立ち上げ速度・汎用性はvLLM、最高スループットはTensorRT-LLM、共有プレフィックスワークロードはSGLangです。必ず自ワークロードで実測して決めます。

Q2. Speculative Decodingはいつ有効ですか？

ドメイン特化タスクで受理率70〜90%が出る場合に特に効果が大きく、2〜3倍の高速化を品質損失なしで実現できます。汎用チャットでも1.5〜2倍は期待できます。

Q3. Prompt Cachingはどれくらいコストが減りますか？

共通プレフィックス部分のコストが最大90%削減されます。長いシステムプロンプトやRAG文脈を使う用途ではROIが非常に高いです。

Q4. FP8量子化で品質は落ちますか？

H100以降のハードウェア対応FP8(E4M3)は多くのタスクで品質ほぼ無損失と報告されていますが、必ず自データで検証してから採用します。

Q5. renueは推論最適化を支援していますか？

はい。クラウドAPI運用最適化、セルフホスト要件判定、vLLM/TensorRT-LLM/SGLang選定、Speculative Decoding導入まで一貫して支援しています。

LLM推論最適化のご相談はrenueへ

renueは複数のAIエージェント事業を自社運用するAIエージェント開発企業として、クラウドAPI運用最適化・セルフホスト設計・Speculative Decoding/Prompt Caching導入・量子化設計まで一貫して支援しています。LLM推論のコスト・レイテンシでお困りの方はお気軽にご相談ください。

AIエージェント運用の事例を見る