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

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

LLM推論最適化(LLM Inference Optimization)は、大規模言語モデルを本番で動かす際のコスト・レイテンシ・スループットを改善する技術の総称です。共通の改善倍率は示しません。モデル・入力/出力長・同時実行数・エンジン版・SLO・費用範囲をそろえ、自社のワークロードで、同じ品質・レイテンシ条件で処理量と実費を比較します。

本記事では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キャッシュを小ブロックに分割して動的に割り当てる手法です。2023年のvLLM原論文はKVキャッシュの無駄をほぼなくし、FasterTransformerやOrcaに対して同程度のレイテンシで2〜4倍のスループットを報告しています。原の2〜4倍を固定のバッチサイズ倍率に置き換えません。測定対象・系列長・モデル・デコード方法による比較結果であり、2026年の全主要エンジンに同じ倍率や同一実装を保証するものではありません。

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

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

Speculative Decoding｜速度改善と出力分布を保つ条件

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

仕組みの要点

• ドラフトモデルが高速に候補を生成(低コスト)
• ターゲットモデルが候補を並列検証して受理/棄却を判定
• 共通の受理率は示さず、ドラフト/ターゲットモデル・タスク・サンプリング設定をそろえて測定する
• 原論文の投機的サンプリングでは、候補をmin(1,p(x)/q(x))で受理し、棄却時はターゲット分布pとドラフト分布qの差の正部分max(0,p−q)を正規化した補正分布から再サンプリングする。単にpから取り直す処理ではない。適切な受理・補正を行う理論上の出力分布の一致と、回答の正確さやFP8等の別の近似による品質変化を区別する
• 原論文の2〜3倍はT5-XXLと標準T5X実装の比較報告。すべてのモデル・GPU・同時実行数での速度保証ではなく、候補生成/検証の負荷と受理率によって効果が変わる

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を提供しています。キャッシュ読取単価の割引は、条件を満たして再利用できた入力トークンの通常入力単価と比べ、リクエスト全体の費用削減率と区別してください。Claudeの公式料金には通常入力の0.1倍となるキャッシュ読取区分がありますが、書込・未ヒット入力・出力・追加サービス費は別です。OpenAIの公式説明も入力トークンの再利用であり、対象モデル・単価・書込条件・ヒット率を確認します。両社の全モデルの総額が一律90%減る保証ではありません。

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

• FP16/BF16：標準。モデル重みそのままのサイズ
• FP8(E4M3/E5M2)：対応GPU・カーネルと量子化対象を確認。公式説明は重み/活性値とKVキャッシュの量子化を区別する。16bitから8bitへの対象テンソルの容量は概ね半分でも、モデル全体のメモリ半減や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	GPU向け最適化。最高スループットという順位はモデル・版・GPU・負荷・SLOで比較	超高スループット要件
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、公開報告例)では、エンジンごとにスループットの傾向が異なると報告されています。用途により最適解が変わるため、必ず自ワークロードで計測してから選定します。

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

モデル層

• 必要最小のモデルサイズを選ぶ(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のGPU最適化、SGLangの共有プレフィックス利用を比較軸にできますが、固定の最高順位は保証しません。モデル・エンジン版・GPU・入力/出力長・負荷と同じ品質/SLOをそろえ、必ず自ワークロードで実測して決めます。

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

ドラフトモデルが対象タスクのターゲット分布をよく近似し、候補生成・検証の追加負荷より並列化の便益が大きい場合に有効です。共通の受理率や汎用チャットの改善倍率は示しません。原論文の2〜3倍はT5-XXL/T5X比較の結果で、すべての環境での期待値にはしません。出力分布を保つには受理確率と棄却後の補正分布を適切に扱い、回答の正確さや他の近似による品質変化とは区別します。

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

共通プレフィックスが条件を満たして再利用された入力トークンの単価を、通常入力単価と比較します。入力区分の単価の割引とリクエスト全体の費用削減率を区別します。Claudeの読取単価には0.1倍の区分がありますが、モデルによって異なり、書込・未ヒット入力・出力・追加サービス費も計算します。OpenAIも対象モデルの入力/キャッシュ単価・書込条件と実際のヒット率を確認し、総額で比較してください。

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

FP8は精度を下げる量子化で、ハードウェア対応だけで品質無損失とは判断しません。重み・活性値・KVキャッシュのどこを量子化するか、スケール・校正・カーネル・モデルとタスクを区別します。共通の無損失保証は示しません。必ず自データで品質を評価し、速度と総メモリも比較して採用してください。

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

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

関連記事

• LLM API徹底比較2026
• LiteLLM完全ガイド2026
• LoRA/QLoRA完全実装ガイド2026
• AgentOps完全ガイド2026
• LLM Observability完全ガイド2026
• ハイブリッド検索完全ガイド2026
• モデルマージ完全ガイド2026

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

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

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

本記事の参考情報

• vLLM 公式GitHub
• vLLM Docs: Speculative Decoding
• AWS: P-EAGLE — Parallel Speculative Decoding in vLLM
• Prem AI: Speculative Decoding 2-3x Faster LLM Inference 2026
• Morph: LLM Inference — Prefill, Decode, KV Cache Guide 2026
• Morph: LLM Inference Optimization 2026
• vLLM Optimization and Tuning
• Jarvislabs: Speculative Decoding in vLLM Complete Guide

あわせて読みたい

• AIコンサルティングの4つの型
• AI導入の相談前に準備すべき5つのこと