KV Cache（ケーブイキャッシュ）とは？読み方・LLM推論を高速化する仕組み・GPUメモリへの影響・Prompt Cachingとの違いを完全解説

KV Cacheとは

KV Cache（読み方：ケーブイキャッシュ）とは、Transformer型LLMの推論時に過去のトークンのKey/Valueテンソルを保存・再利用するキャッシュのこと。これがないと毎トークン生成のたびに、それまでのすべてのトークンに対する自己注意計算を一からやり直す必要があり、生成速度がトークン数の二乗に比例して遅くなります。KV Cacheにより、計算量はトークン数に対して線形に保たれます。

身近な例えで言うと、KV CacheはLLM推論の「下書きノート」です。一度書いた要点（Key/Value）をノートに保存しておき、次の単語を予測するときはノートを参照するだけで済むようにします。重要です。実際に1,000トークン生成すると、KV Cacheありなら約11.9秒、なしなら約56.2秒という4.7倍の差が出るというHugging Faceの実験結果もあり、長文生成では絶対に欠かせない最適化です。一方、メモリ消費が大きいため、GPUのVRAM不足や同時接続数の上限に直結する点が実務では重要なポイントです。

KV Cacheの読み方

KV Cacheの仕組み

Transformerの自己注意では、各トークンが他のすべてのトークンを参照します。デコーダはcausal（因果的）なので、トークンtのattentionは過去のトークン1〜tにしか依存しません。KV Cacheはこの性質を利用し、過去のKey/Valueを保持しておくことで「新トークン1個分の計算」だけで済むようにします。

主要な特性とメモリコスト

なぜO(n)に下がるのか

KV Cacheなしの場合、トークンnを生成するときに過去n個のK/Vを再計算する必要があり、合計でn × n = n²のコストになります。KV Cacheありなら、過去のK/Vはキャッシュから読み出すだけで、新しい計算は新トークン1個 × 過去n個 = nだけです。覚えておきましょう。これがattention層を「擬似的に二次から一次に下げる」最大の理由です。

メモリ vs 速度のトレードオフ

KV CacheはVRAMと計算速度のトレードオフです。重要です。Llama 3 70Bの場合、コンテキスト32,000トークンで1リクエストあたり約20〜40GBのKV Cacheを消費します。同時接続数を増やすにはGPUを増やすか、PagedAttentionで断片化を解消するか、KVを量子化（INT8、INT4）して圧縮する設計が必要です。

PagedAttention・vLLMとの関係

vLLMが採用したPagedAttentionは、KV CacheをOSの仮想メモリ風に「ページ単位」で管理し、断片化を抑える手法です。リクエストごとに連続したVRAM領域を確保する従来方式に比べ、同時処理可能なリクエスト数が2〜4倍に増えるとされます。実務では、自社GPUクラスタで推論を運用するチームが採用するメリットが大きい技術です。

KV Cacheの使い方・実例

基本的な使い方（Quick Start）

主要な推論ライブラリは標準でKV Cacheを有効化しています。Hugging Face Transformersの場合、generate()呼び出しでuse_cache=True（デフォルト）にするだけです。

# Hugging Face TransformersでKV Cacheを使う最小例
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3.1-8B-Instruct")
model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3.1-8B-Instruct",
    torch_dtype=torch.float16,
).to("cuda")

inputs = tokenizer("KV Cacheの仕組みを説明して", return_tensors="pt").to("cuda")
outputs = model.generate(
    **inputs,
    max_new_tokens=200,
    use_cache=True,  # KV Cacheを有効化（デフォルトTrue）
)
print(tokenizer.decode(outputs[0]))

よくある実装パターン

パターンA: vLLMでPagedAttention＋KV Cache

# 本番運用ではvLLMが標準
pip install vllm
from vllm import LLM, SamplingParams

llm = LLM(model="meta-llama/Llama-3.1-8B-Instruct", gpu_memory_utilization=0.9)
prompts = ["こんにちは", "KV Cacheの仕組みは?", "GPUメモリの使い方は?"]
outputs = llm.generate(prompts, SamplingParams(max_tokens=200))
for o in outputs:
    print(o.outputs[0].text)

向いているケース: 自社GPUで複数リクエストを高スループットで捌く、レイテンシ重視のチャットボット。

避けるべきケース: 単発推論しか必要ない検証フェーズ（vLLMの起動コストが過剰）。

パターンB: KV量子化で省メモリ化

# INT8量子化されたKV Cache（Hugging Faceの例）
from transformers import BitsAndBytesConfig

quant_config = BitsAndBytesConfig(
    load_in_8bit=True,
    bnb_8bit_compute_dtype=torch.float16,
)
model = AutoModelForCausalLM.from_pretrained(model_id, quantization_config=quant_config)
# KV Cacheも8bitで保持され、長文生成時のVRAM消費を約半分に

向いているケース: 32K以上の長文コンテキスト、同時接続数を稼ぎたいケース。

アンチパターン: KV Cacheを無効化したまま長文生成

# NG: 長文生成でuse_cache=Falseは絶対に避ける
outputs = model.generate(**inputs, max_new_tokens=2000, use_cache=False)
# → 1秒で終わるはずが1分以上かかる

研究目的で意図的に切るとき以外、KV Cacheを切ってはいけません。重要です。デバッグ時にうっかりFalseになっていないか確認しましょう。

KV Cacheのメリット・デメリット

メリット

• 計算量がO(n)に：長文生成でも線形時間で済む
• 主要ライブラリで標準有効：Hugging Face、vLLM、TensorRT-LLMなど全てで利用可
• ストリーミング生成と相性が良い：トークンを逐次返す設計に自然に適合
• 量子化・PagedAttentionと組み合わせ可能：メモリ最適化の余地が大きい

デメリット

• VRAMが急速に肥大化：長文・大モデルでGPUメモリのボトルネック
• 同時接続数の上限を縛る：1リクエスト分のキャッシュが大きいと並列度が落ちる
• 断片化問題：素朴な実装ではメモリ確保パターンが非効率
• 分散推論で再構築が必要：複数GPU間でKVを分割・同期する設計が必要

KV CacheとPrompt Caching・Embedding Cacheの違い

「キャッシュ」と名のつくLLM最適化は複数あり、混同されがちです。代表的な3種類を整理します。

つまり「KV Cacheはモデル内部の高速化、Prompt CachingはAPI側のトークン課金削減、Embedding Cacheはアプリ層のRAG最適化」と覚えておけば混乱しません。重要です。3つは併用可能で、本番LLMアプリケーションでは一般的にすべて活用します。

KV Cacheに関するよくある誤解

誤解1：「KV CacheとPrompt Cachingは同じもの」

なぜそう誤解されるのか：両方とも「キャッシュ」「LLM」「プロンプト」というキーワードを含むため混同されがちです。背景には「キャッシュという名前なら同じ仕組みだろう」という固定観念があります。

正しい理解：KV Cacheはモデル内部のattention計算を高速化する仕組み（自動有効）、Prompt CachingはAnthropicやOpenAIのAPI側でプロンプト先頭の前処理結果を再利用してトークン課金を減らす仕組み（明示指定）です。両者は別の層で動き、併用可能です。

誤解2：「KV CacheはGPUメモリを節約する」

なぜそう誤解されるのか：「キャッシュ＝メモリ効率」のイメージから誤解されやすい背景があります。

正しい理解：KV CacheはGPUメモリを消費する方向に効きます。節約されるのは計算量で、引き換えに大量のVRAMを使います。Llama 70Bで32Kコンテキストなら20〜40GB/リクエストとなり、これが同時接続数のボトルネックになります。

誤解3：「KV Cacheは新しい技術」

なぜそう誤解されるのか：vLLM・PagedAttention・FlashAttentionなど近年の話題が多いため、KV Cache自体も新しいと混同される理由があります。

正しい理解：KV Cacheの基本概念はTransformer登場時（2017年）から存在し、最初のGPT-2推論実装でも使われていました。最近の進化は「KVをいかに効率的に管理するか」（PagedAttention、量子化、Multi-Query Attentionなど）の部分です。

実務での活用シーン

KV Cacheが特に効くシーン:

• 長文生成タスク：要約、コード生成、レポート作成などトークン数が多いケース
• チャットボットの連続対話：履歴が積み重なる会話で過去K/Vを再利用
• RAGの長コンテキスト推論：取得文書を全部入れてから生成する場合
• ストリーミング応答：トークン逐次表示型のUXで遅延を最小化
• 自社GPU推論サーバー：vLLM＋PagedAttentionで同時接続数を最大化

KV Cacheに関するよくある質問（FAQ）

まとめ

• KV Cache（ケーブイキャッシュ）はTransformer型LLM推論の必須最適化、計算量をO(n²)→O(n)に下げる
• 各層のKey/Valueテンソルを保存して再利用、新トークン分のみを計算する
• VRAM消費が大きく、長文・大モデルでは同時接続数のボトルネックになる
• vLLMのPagedAttentionで断片化を解消、量子化（INT8/INT4）でさらに省メモリ化
• Prompt Caching（API側）・Embedding Cache（アプリ側）と階層的に併用
• 主要ライブラリで標準有効、debug以外で切ることはない

参考文献・出典