KVキャッシュの壁を破る——LLM高速化の決定版
この記事では、LLMが本番で遅く・高くなりやすい理由を一読で把握し、同じGPUでも同時処理数を増やし、待ち時間を減らし、単位コストを下げるための現実的な手順を示します。専門用語は後半で必要最小限に登場します。
2025年10月現在、LLM推論の遅延とコスト増は、長い入力に引っ張られて増える“持ち物(メモリ)”に加え、生成工程の回し方など複合要因で起こりがちです。実務では、
①メモリのやりくりを良くする
(例:vLLMのPagedAttention=メモリ配置の無駄を減らす工夫)、
②数値表現を軽くする
(まずはFP8、用途に応じてFP4=精度を落としすぎずにデータ量を圧縮)、
③先読みしてまとめて進める
(スペキュレイティブ推論=小さな下書きを先に作って一括確認)
の三本柱を順番に導入するのが効果的です。Blackwell世代(B100/B200)の普及で低精度推論の実用性はさらに高まりつつあります(可用性と価格はクラウドや構成に依存)。
- 要点1:長い入力で増える“持ち物(メモリ)”を抑えて、同時処理数を落とさない(=KVキャッシュ対策)
- 要点2:メモリのやりくりと数値の軽量化でVRAMと帯域を節約(=PagedAttention/FP8・FP4)
- 要点3:先読みしてまとめて進めることで待ち時間を短縮(=スペキュレイティブ推論)
実装の流れは「エピローグ:実践への第一歩」に、評価指標と戦略の選び方は「第3章:羅針盤を手に」に整理しています。
プロローグ:なぜ現場のLLMは本番で“息切れ”するのか?
要約:PoCでは速かったのに本番で遅くて高い——。背景には、長い入力に引っ張られて“持ち物(メモリ)”が増えることと、運用上の回し方が噛み合わないことがある。 本稿は、レイテンシ×スループット×単位コストを同時に改善するための実務視点を示す。
主人公はスタートアップの若手AIエンジニア・三浦ナオ(架空の人物)。 数ヶ月のプロジェクトの集大成として、自社のチャットボットをリリースした。PoCでは経営陣から絶賛され、ローカルでは自然で高速な応答を返していた。
ところが本番投入後、アクセス集中とともに応答は目に見えて遅くなり、ユーザーから不満が相次ぐ。追い打ちをかけたのは請求書だ。GPUコストが想定を超えて膨らみはじめた。
ナオはつぶやく——「なぜだ? ローカルではあんなにサクッと動いたのに…」
2025年の今、モデルは大型化し、20万トークン級の長文入力に対応するモデルも登場している。“より長く読む”ことが前提になる一方で、NVIDIA Blackwell(B100/B200)などの次世代GPUの提供が主要クラウドで進み、低精度の選択肢が広がり、推論のメモリ転送と演算効率の最適化が進んでいる。価格や可用性はプロバイダーや構成・地域で変動するが、実務で選べる“土台”は確実に厚くなった。推論効率化は、体感の速さ・同時処理・単位コストに直結する、競争力の核心だ。
本記事は、この「なぜ?」への答えを示す航海図である。LLM推論というブラックボックスを解剖し、対象サービスを「速く、安く、賢く」動かすための手がかりを、現場で再現しやすい順序で共有する。
👨🏫 AI専門家が解説:かみ砕きポイント
- 学習=“蔵書を増やす土木”/推論=“素早く本を出す窓口”。本番で重要なのは後者。
- 学習向けの代表例(H100)と、推論を含むマルチワークロードの代表例(L40S)では、求められる指標(遅延・同時処理・消費電力)が異なる。
- 長文ほど“持ち物”が増えやすいため、持ち物を減らす/詰める発想と列の回し方の工夫が効く(具体策は後章)。
第1章:霧の中へ – LLM推論の心臓部と“遅さ”の正体とは?
要約:LLMの推論はPrefill(入力を一気に読み込み文脈を作る)とDecode(1語ずつ継ぎ足していく)の2段階で進みます。長い入力ほど“しおり付きの下書きメモ(=KVキャッシュ)”が肥大し、VRAMやメモリ帯域を圧迫して遅さ・コスト増につながりやすくなります。
ここからは、三浦ナオ(彼女)の現場で起きた“遅さ”を解きほぐすために、LLM推論の心臓部=PrefillとDecodeを分解して見ていきます。
まず全体像(1分で把握)
フェーズ | 何をしているか(直感) | どこが遅くなりやすい? | 代表指標 |
---|---|---|---|
Prefill | 脚本の読み合わせ:入力全体を一気に解釈し、後続用の文脈(しおり)を作る | 計算量が大(最初の一発が重い) | TTFT(最初のトークンまで) |
Decode | 本番撮影:しおり(KV)を参照しつつ、1語ずつ足していく | メモリ帯域/データ転送、しおりの肥大(KV) | トークン毎秒/p95レイテンシ |
ナオの現場メモ:ダッシュボードでは、TTFT(初動)、トークン毎秒とp95レイテンシ(体感の速さ)、VRAM使用率とKV比率(同時処理数の上限)をまず押さえます。
KVキャッシュ=「一度読んだ文の要点(しおり)をメモしておく」仕組み。入力が長いほどしおりが増え、ノート(VRAM)を圧迫します。
“遅さ”の正体:巨大化する「しおりノート(KVキャッシュ)」
どこがボトルネックになりやすいのか。長いコンテキストほど、KVキャッシュが雪だるま式に増え、VRAMとメモリの読み書きを圧迫します。結果として、
- 同時にさばけるリクエスト数が下がる(スループット低下)
- 1件あたりの待ち時間が伸びる(レイテンシ悪化)
- トークン当たりコストが上がる(コスト増)
ナオのケース:長文の問い合わせ対応と会話履歴の維持が増え、しおりノート(KV)が肥大。これが同時処理数の低下と待ち時間の伸びに直結していました。
大規模モデル×長文(数万〜数十万トークン級)では、KVだけで数十〜百GB規模に達する場合があります(モデル規模・層数・精度・ヘッド数などの前提に依存)。このため、計算速度そのものよりも、メモリ容量とメモリ帯域という物理的な壁に突き当たりやすくなります。
コラム:KVメモリの“ざっくり見積もり”
- 覚え方:
KVメモリ ≈ 2(KとV) × 精度バイト × 層数 × 隠れ次元 or ヘッド次元 × トークン数
- 直感: 精度を下げる(FP16→FP8→FP4)とほぼ比例して小さく、トークン数は一直線に増加、層数・次元が大きいほど重くなります。
- 使い方: 厳密値よりオーダー感(何十GB級か)を掴む目的で十分。最適化の前後でどれだけ減ったかを見る指標にも。
この章で握っておくこと
- 推論はPrefill→Decodeの2段。TTFTはPrefill寄り、体感の速さはDecode寄り。
- 長文ほどKVが支配的になりやすいが、Decodeのメモリ帯域/スケジューリングなど複合要因で遅くなる。
- 測るもの:TTFT、トークン毎秒、p95/p99レイテンシ、VRAM使用率(KV比率)、1,000トークン当たりコスト。
次章から、ナオが実際に適用した順番(“持ち物を減らす/列の回し方を整える/先読みを足す”)で最適化を重ねていきます。
第2章:2つの光明 – LLMを解き放つ高速化の魔法
要約:高速化の主軸は先読みで“1語ずつ待つ”を減らす〈スペキュレイティブ推論〉と、“持ち物(KV)を軽く&整理する〈KVキャッシュ最適化〉。前者は体感の速さ(レイテンシ)、後者は同時処理(スループット)とコストに効きます。
ナオの次の一手:第1章で特定した“遅さ”の正体を踏まえ、まずはベースライン整備→KVの整理→KVの軽量化→先読み追加の順で段階導入していきます。
セクション1:先読みの魔法「スペキュレイティブ推論」
何者? 小回りの利く“下書き生成”を先に走らせ、まとめて本体が検証・採用する方式。1トークンずつの待ちを短縮します。2025年は追加モデル不要の「自己スペキュレイティブ」がさらに洗練され、導入の敷居が下がっています。
ナオの実装(短期):チャット系など短文中心のエンドポイントからA/B導入。受理率(draft採用率)とp95レイテンシ、一貫性指標(関数コール成功率など)を監視し、max draft lengthや閾値を調整。
効きどころ:TTFTよりも体感の返り。短文・会話で効果が出やすく、長文一括生成では相対的に小さめ。
セクション2:怪物使いの技「KVキャッシュ最適化」
2-1. PagedAttention:メモリ管理の“整理整頓”
何者? vLLMが採用するページング型のKV管理。断片化を抑え、空き領域を寄せながら、連続(Continuous)バッチングと組み合わせてGPUを常に満員に近い状態で回す。結果として同時処理数↑/待ち時間↓のベースライン底上げが起きます。
ナオの実装(即効):推論エンジンをvLLMに切替え、連続バッチングを有効化。同時接続あたりのp95、全体トークン毎秒、GPU稼働率の改善を確認。
2-2. 量子化(低精度化):情報を“軽くする”錬金術
何者? KVや重みの数値精度を下げる(例:FP16→FP8→FP4)ことで、VRAMと帯域を直接削減。長文ほど効く。Blackwell世代の第2世代Transformer EngineはFP4をハードウェア対応しますが、LLM推論での広範実装はフレームワーク/モデル依存のため、実務ではまずFP8から段階導入が堅実です(画像生成側ではFP4先行事例あり)。
ナオの実装(中期):まずFP8で品質A/B→問題なければKV適用可否を検証→タスクに応じて一部FP4を限定試験。要約精度/関数コール成功率/コード生成のコンパイル成功など、タスク別メトリクスで副作用を監視。問題が出た箇所は層単位の混合精度に戻す。
Key Takeaways(持ち帰り)
- ボトルネックは計算力よりも、VRAM容量と帯域(=KVの重さ・I/O)。
- レイテンシ改善=スペキュレイティブ推論、スループット改善=PagedAttention+連続バッチング。
- 長文を扱うなら、FP8/FP4などの低精度は強力(ただし段階導入+A/Bは必須)。
ナオの進捗: まずはvLLM+連続バッチングでベースラインを底上げし、続けてPagedAttention→FP8(必要に応じFP4)→自己スペキュレイティブを順に適用。各段で<p95・TPS・VRAM・品質>を記録し、無理なく恒常運用へ移行しました。
第3章:羅針盤を手に —— 最適な“答え”を生み出す生成戦略

深夜のオフィス。モニターの光だけが机を照らす。ナオはユーザーフィードバックを読み返した。速さは確かに上がった。しかし「素っ気ない」「要約が長い」との声もある。彼女は静かに息を整え、設定パネルを開いた。――次は“賢さ”を整える番だ。
まず、外部APIを呼ぶ関数コールや請求関連の説明など、ブレが許されない箇所を固める。temperature を 0.0 にし、system に厳密な出力フォーマットを記す。stop も指定する。ログの赤は消え、JSONは崩れない。一本釣り(Greedy)は味気ないが、骨格には必要だ。
次に、会話の手触りを少しだけ柔らかくする。チャット用ルートに限って Sampling を有効化。temperature は 0.7、top_p は 0.9。冗長なら 0.6 に、固ければ 0.8 に。片方だけを動かすマイルールで、挙動は読みやすい。満足度はじわりと上向く。
翻訳や要約は、整った一本がほしい。Beam Search を beam=3 で適用し、length_penalty を軽く効かせる。文はすっと収まり、p95 の伸びも許容範囲に収まった。重さと整いの均衡点が見えた。
生成戦略の比較(運用のための早見表)
戦略 | 得意(こんな時に) | 苦手(こうなることがある) | 代表ユースケース | 運用のコツ(例) |
---|---|---|---|---|
Greedy(temperature=0.0) | 再現性・厳密性を最優先 | 単調になりやすい、発想が広がらない | 事実確認、関数コール、厳格フォーマット | stop と max_tokens を厳密に指定 |
Sampling(temperature / top_p / top_k) | 多様性や会話の自然さが欲しい | ブレ・脱線、品質のムラ | チャット、コピー案、ブレスト | まずは temperature=0.7, top_p=0.9。片方のみで調整 |
Beam Search(beam 幅で候補取り置き) | 整った一貫した文が必要 | 計算が重く遅い、多様性が減る | 翻訳、要約、構造化抽出 | beam=3 を基本、p95 を監視。length_penalty で冗長抑制 |
ナオはダッシュボードに四つの針を置いた。p95 レイテンシ、トークン毎秒、整合や成功率、フォーマット合致率。Greedy で背骨をつくり、Sampling で血を通わせ、Beam で節目を整える。設定は増やさない。決めて、残す。それが運用だ。
レポートは静かに良化を示す。会話は柔らかく、関数コールは安定し、要約は収まった長さで届く。ナオは目を閉じ、短く息を吐いた。――速く、安く、そして賢く。
エピローグ:実践への第一歩 – 現場で使えるLLM最適化レシピ
要約:「計測→診断→処方→テスト」の4ステップで最適化を回す。ワークロードの特性に合わせ、KV最適化・先読み(スペキュレイティブ)・生成戦略を段階的に組み合わせる。

夜更けのオフィス。ナオはダッシュボードを開き、机の端に付箋を貼った。計測/診断/処方/テスト――順番を崩さない、と。
Step 1:計測(現状把握)
数字は嘘をつかない。まずは“今”を固定する。
- p95 レイテンシ/トークン毎秒(TPS)/1,000トークン当たりコスト/VRAM使用率(KV比率)を取得
- 時間帯別・エンドポイント別のグラフを保存し、スナップショットとしてロック
Step 2:診断(ボトルネック特定)
遅さの正体を2つの箱に仕分ける。
- 長文で膨らむメモリ系か、短文なのに体感が遅い系かを切り分け
- 混在していれば、支配的な要因(影響が大きい方)から着手
Step 3:処方(最適化の適用)
迷わないレシピで、小さく前進する。
- 長文・スループット重視:vLLM+連続バッチングで土台→PagedAttentionで断片化抑制→必要に応じFP8(場合により一部FP4)で軽量化
- 短文・レイテンシ重視:(自己)スペキュレイティブ推論を段階導入(受理率と一貫性を監視)
- 生成の賢さ:Greedyで背骨/Samplingで余白/Beamで仕上げ(タスク別に切替)
Step 4:テストと反復(品質の担保)
良くなった“つもり”で終わらせない。
- A/B テストを小さく開始:p95・TPSと品質指標(要約整合・関数コール成功・フォーマット合致)を監視
- 悪化時は即ロールバックできるよう手順を用意し、改善セットを既定化して定着
数日後、グラフは静かに安定し、異常ログは減った。ナオは最後のチェックを終え、設定に既定の印をつける。速く、安く、そして賢く。――この手順を、必要なときに何度でも繰り返せば、もう迷わない。
まとめ
本記事では、2025年時点におけるLLM推論の遅延とコスト増の根本原因が、コンテキスト長の増大に伴う「KVキャッシュ」のメモリ圧迫にあることを解き明かした。 そして、その具体的な解決策として、メモリ効率を飛躍的に高める「PagedAttention」や「量子化」、そして応答速度を直接的に改善する「スペキュレイティブ推論」という2つの強力なアプローチを解説した。
これらの技術はもはや専門家だけのものではない。vLLMのようなオープンソースの推論エンジンや、Blackwell世代(B100/B200)の提供拡大により、広い開発者層が恩恵を受けられる時代になっている。「計測・診断・処方・テスト」という実践的なレシピに沿って、自社のLLMサービスにこれらの最適化を適用し、ユーザー体験と事業採算性の両方を両立させてほしい。
専門用語まとめ
- KVキャッシュ
- Attentionメカニズムで計算されるKey(キー)とValue(バリュー)のペア。一度計算した文脈情報を保存しておくことで、後続のトークン生成を高速化する。コンテキスト長に比例してサイズが増大し、GPUメモリを圧迫する主因となる。
- Prefill / Decode
- LLM推論の2つのフェーズ。Prefillは入力全体を処理して最初のKVキャッシュを作る重い初期処理。DecodeはKVキャッシュを参照しながら1トークンずつ生成する軽い処理の繰り返し。全体のパフォーマンスは両者のバランスで決まる。
- スペキュレイティブ推論
- 小さなドラフトモデルが数トークン先までを予測(投機)し、本体のLLMが一括で検証・承認する高速化手法。逐次的なDecode処理の待ち時間を削減し、レイテンシを大幅に改善する。
- PagedAttention
- vLLMで有名になったメモリ管理技術。KVキャッシュをOSの仮想メモリのようにページ単位で管理することで、メモリの断片化を防ぎ、利用効率を最大化する。連続バッチングとの併用でスループット向上に大きく寄与する。
- 量子化 (Quantization)
- モデルの重みやKVキャッシュを表現する数値の精度を下げる(例:16ビット→8ビット→4ビット)ことで、メモリ使用量とデータ転送量を削減する技術。Blackwellの第2世代Transformer EngineはFP4をハードウェア対応するが、LLM推論での広範実装はフレームワーク/モデル依存である。
よくある質問(FAQ)
Q1. KVキャッシュの量子化で精度はどれくらい落ちますか?
Q2. スペキュレイティブ推論とビームサーチの違いは?
Q3. 自社導入の第一歩は?
主な参考サイト
- Fast Inference from Transformers via Speculative Decoding(arXiv)
- Looking back at speculative decoding(Google Research Blog)
- vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention(vLLM Blog)
- Decoding Speculative Decoding(arXiv)
- FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision(Tri Dao Blog)
合わせて読みたい
- 思考するAI、推論が拓く未来 – LLM進化の核心と社会変革
- DeepSeekとSakana AIに見る生成AIの新たな潮流
- AIチップ覇権戦争2025: NVIDIAの銀河系戦略に挑む反逆者たち
- AIが金を掘る時代へ:NVIDIA GTC 2025が示したトークン採掘の未来
- WordPress高速化完全ガイド2025|コアウェブバイタル改善術
更新履歴
初版公開
