プレフィックスキャッシュ（プレフィックスキャッシュ）
推論エンジンレベルで複数リクエスト間の共通入力プレフィックスを検出し、KVキャッシュを自動的に共有・再利用する技術。vLLMのAutomatic Prefix Caching（APC）やSGLangのRadixAttentionが代表的な実装で、マルチテナント環境でのスループットを大幅に向上させる。
プレフィックスキャッシュとは、LLM推論エンジンが複数のリクエスト間で共通するトークンプレフィックスを自動検出し、そのKVキャッシュ計算結果を共有する最適化技術である。APIプロバイダのプロンプトキャッシュがユーザーAPIレイヤーの機能であるのに対し、プレフィックスキャッシュは推論エンジン内部のメモリ管理レベルで動作する。
概要
セルフホストLLM推論では、複数ユーザーが同一のシステムプロンプトやRAGコンテキストを共有するケースが頻繁に発生する。プレフィックスキャッシュはこの共通部分のKVキャッシュを1回だけ計算し、後続リクエストで再利用する。これにより、TTFT（Time-To-First-Token）の短縮とGPU計算量の削減を同時に実現する。
2026年時点の主要実装は、vLLMのAutomatic Prefix Caching（APC）とSGLangのRadixAttentionの2つ。どちらもプロダクション環境で広く使われており、マルチテナントLLMサービスでは事実上の必須最適化となっている。
主要実装の比較
| 特性 | vLLM APC | SGLang RadixAttention | TensorRT-LLM |
|---|---|---|---|
| データ構造 | ハッシュテーブル | 基数木（Radix Tree） | ハッシュテーブル |
| プレフィックス検出 | トークンハッシュ一致 | 最長共通プレフィックス | トークンハッシュ一致 |
| 部分一致 | ブロック単位（16トークン） | トークン単位 | ブロック単位 |
| エビクション | LRU | LRU | LRU |
| マルチターン最適化 | 基本対応 | ツリー構造で高効率 | 基本対応 |
| 有効化方法 | --enable-prefix-caching | デフォルト有効 | --kv_cache_enable_block_reuse |
vLLM Automatic Prefix Caching（APC）
vLLM 0.4で導入されたAPCは、PagedAttentionのブロック管理を拡張してプレフィックスキャッシュを実現する。
動作原理:
- 入力トークン列を16トークンのブロックに分割
- 各ブロックのトークンハッシュ値を計算
- ハッシュテーブルで既存のKVキャッシュブロックと照合
- 一致するブロックはKVキャッシュを再利用、不一致ブロックのみ新規計算
- 使用されなくなったブロックはLRUポリシーでエビクト
性能実測（A100 80GB、Llama 3.1 70B、同一システムプロンプト4,096トークン）:
- APC無効: TTFT 850ms、スループット 15 req/s
- APC有効: TTFT 320ms、スループット 28 req/s
- 改善率: TTFT 62%短縮、スループット 87%向上
起動コマンド:
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3.1-70B-Instruct \
--enable-prefix-caching \
--max-model-len 32768 \
--gpu-memory-utilization 0.9
SGLang RadixAttention
SGLang 0.2で導入されたRadixAttentionは、基数木（Radix Tree）データ構造を用いてプレフィックスキャッシュを管理する。vLLM APCのブロック単位管理と異なり、トークン単位の柔軟な共有が可能。
Radix Treeの利点:
- ツリー構造: マルチターン会話の分岐パターンを効率的に管理。会話Aと会話Bが途中まで同一パスを共有する場合、分岐点までのKVキャッシュを共有
- 最長共通プレフィックス: 16トークンブロック境界に縛られず、任意長のプレフィックス一致を検出
- Fork操作: 既存のKVキャッシュを起点に新しいリクエストを分岐（Copy-on-Write的）
性能実測（A100 80GB、Llama 3.1 8B、マルチターン会話シナリオ）:
- 従来推論: スループット 45 req/s
- RadixAttention: スループット 180 req/s
- 改善率: 4x スループット向上
適用シナリオ別効果:
- マルチターン会話: 3-5x スループット向上（会話履歴の漸進的蓄積を効率的にキャッシュ）
- ツリー探索（Tree-of-Thought）: 5-8x スループット向上（分岐パスの共通部分を最大限再利用）
- バッチFew-shot推論: 2-3x スループット向上（共通Few-shot例のキャッシュ共有）
- RAG（共通コンテキスト）: 2-4x スループット向上（同一ドキュメントチャンクの再利用）
プレフィックスキャッシュの設計パターン
パターン1: 共通システムプロンプト
最も基本的なパターン。全リクエストが同一のシステムプロンプトを共有する場合、初回計算後は全後続リクエストでKVキャッシュが再利用される。
パターン2: テナント別プレフィックス
マルチテナント環境で、テナントごとに異なるシステムプロンプトを持つ場合。各テナントのプレフィックスが個別にキャッシュされ、テナント内のリクエスト間で共有される。
パターン3: RAGコンテキスト共有
複数ユーザーが同一ドキュメントについて質問する場合、RAGで取得したコンテキストチャンクが共有される。キャッシュキーにはドキュメントIDとチャンクIDを含める設計が推奨される。
メモリ管理とエビクション
プレフィックスキャッシュはGPUメモリを追加消費する:
- 通常推論: アクティブリクエストのKVキャッシュのみ保持
- プレフィックスキャッシュ: 完了リクエストのKVキャッシュも保持（再利用のため）
- メモリ圧迫時: LRUポリシーで古いキャッシュからエビクト
vLLMでは--gpu-memory-utilizationパラメータ（デフォルト0.9）でKVキャッシュに割り当てるGPUメモリ比率を制御。値を高くするとキャッシュ保持量が増えてヒット率が上がるが、OOMリスクも高まる。
よくある質問（FAQ）
Q1: vLLM APCとSGLang RadixAttention、どちらを選ぶべき？ A: 単純なプレフィックス共有（共通システムプロンプト等）ならvLLM APCで十分。マルチターン会話やツリー探索など分岐パターンが多い場合はSGLang RadixAttentionが有利。プロダクション運用の安定性ではvLLMが優勢（2026年時点）。
Q2: プレフィックスキャッシュはどのくらいのGPUメモリを消費しますか？ A: キャッシュ保持量に比例。Llama 3.1 70Bで4,096トークンのプレフィックスを10テナント分保持する場合、約6.4GB（FP16）の追加メモリ。FP8量子化で約3.2GBに削減可能。gpu-memory-utilization 0.9設定のA100 80GBなら余裕で収まる。
Q3: プレフィックスキャッシュとAPIプロバイダのプロンプトキャッシュは同じ技術ですか？ A: 基本原理は同一（共通プレフィックスのKVキャッシュ再利用）だが、動作レイヤーが異なる。プレフィックスキャッシュは推論エンジン内部のGPUメモリ最適化であり、セルフホスト環境で使用。プロンプトキャッシュはAPIプロバイダがサーバー側で提供する課金最適化機能で、ユーザーはAPI設定のみで利用可能。
まとめ
- プレフィックスキャッシュはセルフホストLLM推論の必須最適化技術
- vLLM APC: ブロック単位ハッシュ方式、安定したプロダクション実績
- SGLang RadixAttention: 基数木方式、マルチターン会話で最大5xスループット
- TTFT 60%以上短縮、スループット2-5x向上が実測されている
- GPU メモリとのトレードオフ管理が運用上の重要ポイント