Home 論文解説: RAGCache — RAG向けKVキャッシュでTTFTを最大4倍高速化
投稿
キャンセル

📄 論文解説: RAGCache — RAG向けKVキャッシュでTTFTを最大4倍高速化

投稿日 23/02/2026
投稿者 0h-n0
18 分読了時間

本記事は RAGCache: Efficient Knowledge Caching for Retrieval-Augmented Generation の解説記事です。

論文概要（Abstract）

RAGCache は、RAG（Retrieval-Augmented Generation）システムにおける検索結果（知識チャンク）のKVキャッシュを事前計算・階層的に管理するフレームワークである。著者らは、同一ドキュメントチャンクが異なるクエリで繰り返し参照される特性に着目し、チャンクごとのKV状態をGPU/CPU/ディスクの3層キャッシュで管理するKnowledge Tree構造を提案している。vLLMおよびSGLangとの比較実験で、TTFT最大4倍高速化・スループット2.1倍向上が報告されている。

この記事は Zenn記事: LangGraph×Claude Sonnet 4.6のプロンプトキャッシュ最適化でAgentic RAGコスト90%削減 の深掘りです。

情報源

背景と動機（Background & Motivation）

RAGシステムでは、ユーザーのクエリに対してベクトルDBから関連ドキュメントを検索し、それをプロンプトに含めてLLMに回答を生成させる。この際、以下の非効率が発生する：

  • 同一チャンクの重複計算: FAQ対応や商品ドキュメント検索では、同じドキュメントチャンクが異なるユーザーの異なるクエリに対して繰り返し参照される
  • プレフィックスキャッシュの限界: 従来のプレフィックスキャッシュ（vLLM等）は、プロンプト全体の先頭一致でしかキャッシュヒットしない。RAGでは検索結果の組み合わせがクエリごとに異なるため、プレフィックスが一致しにくい
  • GPUメモリの制約: 全チャンクのKV状態をGPUメモリに保持するのは非現実的

著者らはこれらの課題を解決するため、チャンク単位のKVキャッシュ管理を提案している。

主要な貢献（Key Contributions）

  • 貢献1: チャンク単位のKVキャッシュを階層的に管理するKnowledge Treeデータ構造の提案
  • 貢献2: GPU/CPU/ディスクの3層LRUキャッシュによる大規模コーパスのKVキャッシュ管理
  • 貢献3: HotpotQA、Natural Questions、TriviaQAでTTFT 4倍高速化・スループット2.1倍向上を実証

技術的詳細（Technical Details）

Knowledge Tree構造

RAGCacheの中核は、ドキュメントチャンクのKV状態を木構造で管理するKnowledge Treeである。

通常のプレフィックスキャッシュでは、プロンプト全体をトークン列として扱い、先頭からの最長一致でキャッシュヒットを判定する。一方、RAGCacheはプロンプトを構造的に分解する：

1

プロンプト = [システムプロンプト] + [チャンク1] + [チャンク2] + ... + [チャンクK] + [クエリ]

各チャンクのKV状態を独立にキャッシュすることで、チャンクの組み合わせが異なるクエリでも部分的なキャッシュヒットが可能になる。

Knowledge Treeの構造は以下の通り：

\[\mathcal{T} = (V, E), \quad V = \{v_{\text{root}}\} \cup \{v_c \mid c \in \mathcal{C}\}\]

ここで、

  • $V$: ノード集合（ルートノード + 各チャンクノード）
  • $E$: エッジ集合（親子関係）
  • $\mathcal{C}$: ドキュメントチャンクの集合
  • $v_c$: チャンク $c$ に対応するノード。KV状態 $(\mathbf{K}_c, \mathbf{V}_c)$ を保持

チャンクKVキャッシュの事前計算

各チャンクのKV状態は、オフラインで事前計算（pre-warming）される：

\[\mathbf{K}_c = \text{Encode}(c) \cdot \mathbf{W}_K, \quad \mathbf{V}_c = \text{Encode}(c) \cdot \mathbf{W}_V\]

ここで、$\text{Encode}(c)$ はチャンク $c$ のトークン埋め込み列である。

ただし、チャンクのKV状態を独立に計算する場合、チャンク間の因果的注意（causal attention）が欠落するという課題がある。著者らは以下のアプローチでこの問題を緩和している：

  1. システムプロンプトのKVを共通プレフィックスとして事前計算
  2. チャンクKVはシステムプロンプトKVを条件として計算
  3. チャンク間の相互注意は推論時に再計算（選択的再計算）

3層キャッシュ管理

大規模コーパス（数万〜数百万チャンク）のKV状態を効率的に管理するため、GPU → CPU → ディスクの3層LRUキャッシュを採用している：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

from collections import OrderedDict
from typing import Optional
import torch

class ThreeTierKVCache:
    """3層LRUキャッシュによるKV状態管理"""

    def __init__(
        self,
        gpu_capacity: int,    # GPUメモリに保持するチャンク数
        cpu_capacity: int,    # CPUメモリに保持するチャンク数
        disk_path: str,       # ディスクキャッシュのパス
    ):
        self.gpu_cache: OrderedDict[str, tuple[torch.Tensor, torch.Tensor]] = OrderedDict()
        self.cpu_cache: OrderedDict[str, tuple[torch.Tensor, torch.Tensor]] = OrderedDict()
        self.gpu_capacity = gpu_capacity
        self.cpu_capacity = cpu_capacity
        self.disk_path = disk_path

    def get(self, chunk_hash: str) -> Optional[tuple[torch.Tensor, torch.Tensor]]:
        """チャンクのKV状態を取得（GPU → CPU → ディスクの順に検索）

        Args:
            chunk_hash: チャンクのハッシュ値（トークン列のSHA256等）

        Returns:
            (K, V) テンソルのタプル。キャッシュミス時はNone
        """
        # Layer 1: GPU
        if chunk_hash in self.gpu_cache:
            self.gpu_cache.move_to_end(chunk_hash)
            return self.gpu_cache[chunk_hash]

        # Layer 2: CPU → GPUにプロモート
        if chunk_hash in self.cpu_cache:
            kv = self.cpu_cache.pop(chunk_hash)
            kv_gpu = (kv[0].cuda(), kv[1].cuda())
            self._gpu_insert(chunk_hash, kv_gpu)
            return kv_gpu

        # Layer 3: ディスク → CPU → GPUにプロモート
        kv_disk = self._disk_load(chunk_hash)
        if kv_disk is not None:
            kv_gpu = (kv_disk[0].cuda(), kv_disk[1].cuda())
            self._gpu_insert(chunk_hash, kv_gpu)
            return kv_gpu

        return None  # キャッシュミス

    def _gpu_insert(self, key: str, kv: tuple) -> None:
        """GPUキャッシュに挿入（容量超過時はCPUにデモート）"""
        if len(self.gpu_cache) >= self.gpu_capacity:
            evict_key, evict_kv = self.gpu_cache.popitem(last=False)
            evict_cpu = (evict_kv[0].cpu(), evict_kv[1].cpu())
            self._cpu_insert(evict_key, evict_cpu)
        self.gpu_cache[key] = kv

    def _cpu_insert(self, key: str, kv: tuple) -> None:
        """CPUキャッシュに挿入（容量超過時はディスクにデモート）"""
        if len(self.cpu_cache) >= self.cpu_capacity:
            evict_key, evict_kv = self.cpu_cache.popitem(last=False)
            self._disk_save(evict_key, evict_kv)
        self.cpu_cache[key] = kv

    def _disk_load(self, key: str) -> Optional[tuple]:
        """ディスクからKV状態をロード"""
        # 実装はファイルI/Oまたはmemmap
        pass

    def _disk_save(self, key: str, kv: tuple) -> None:
        """ディスクにKV状態を保存"""
        pass

キャッシュキーの設計

チャンクのキャッシュキーは、トークン列のハッシュ値で生成される：

\[\text{key}(c) = \text{SHA256}(\text{tokenize}(c))\]

この設計により、チャンクの内容が同一であれば、プロンプト内の配置位置に関わらずキャッシュヒットする。ただし、チャンクの境界（分割方法）が変わるとキャッシュミスになるため、チャンキング戦略の固定が運用上重要である。

実装のポイント（Implementation）

  1. チャンキング戦略の固定: チャンクサイズや分割方法を変更するとキャッシュが全無効化される。本番環境ではチャンキングパラメータをバージョン管理し、変更時は段階的にキャッシュを再構築する

  2. KV状態のメモリ見積もり: 1チャンク（512トークン）のKV状態は約4MB（FP16、32層、128次元）。1万チャンクで約40GB。CPU RAMが十分でない場合はディスクキャッシュが必須

  3. 事前計算のバッチ処理: 大量チャンクのKV事前計算はGPUバッチ処理で効率化可能。著者らはバッチサイズ64での事前計算を推奨

  4. キャッシュウォームアップ: 本番デプロイ前に頻出チャンクのKVをGPUメモリにロードしておくことで、初回リクエストからキャッシュヒットを実現

実験結果（Results）

著者らはHotpotQA、Natural Questions、TriviaQAで実験を行い、以下の結果を報告している（論文Table 1-3より）。

指標vLLM prefix cachingSGLangRAGCache改善率（vs vLLM）
TTFTベースライン1.3x4.0x4.0倍高速化
スループットベースライン1.4x2.1x2.1倍向上
GPUメモリ効率ベースライン-階層管理-

制約と注意点:

  • ドキュメントコーパスが頻繁に更新される場合、キャッシュ無効化のコストが高い
  • チャンク間の因果的注意の欠落により、一部タスクで精度が若干低下する可能性がある（著者らはHotpotQAで0.5%以内の精度低下と報告）
  • 実験はオープンソースモデル（Llama系）で行われており、Claude等のAPIベースモデルでは適用方法が異なる

実運用への応用（Practical Applications）

RAGCacheの知見は、LangGraphベースのRAGパイプラインに以下の形で応用可能である：

APIベースモデルへの適用: Claude APIのプロンプトキャッシュは、RAGCacheの「チャンクKVキャッシュ」とは異なりプレフィックスベースである。しかし、RAGCacheの設計思想（頻出チャンクの優先キャッシュ、チャンキング戦略の固定）はAPIベースのプロンプト設計にも適用できる。

具体的な応用パターン:

  • 頻出ドキュメントをシステムプロンプトの固定部分として含め、プレフィックスキャッシュの恩恵を受ける
  • 検索結果の順序を安定させる（関連度降順で固定）ことで、プレフィックスの一致確率を上げる
  • チャンキング戦略をバージョン管理し、変更時の影響を制御する

コスト試算: 1日1,000クエリ、各クエリで平均3チャンク（各2,000トークン）を使用する場合、チャンクの再利用率が50%であれば：

  • キャッシュなし: 1,000 × 6,000 × $3.00/MTok = $18.00/日
  • キャッシュあり（50%再利用）: (3,000 × $3.75 + 3,000 × $0.30) × 1,000/MTok = $12.15/日
  • 約32.5%のコスト削減

関連研究（Related Work）

  • CacheBlend (2502.09560): RAGのKVキャッシュをブレンドして再利用する手法。部分キャッシュヒット時でも精度劣化なしでTTFL削減を実現
  • vLLM Prefix Caching: プロンプト全体の先頭一致でキャッシュヒットする方式。RAGCacheはチャンク単位の部分一致を可能にした点で拡張
  • SGLang RadixAttention: Radix Treeベースのキャッシュ管理。RAGCacheはKnowledge Treeで文書構造を活用する点が異なる

まとめと今後の展望

RAGCacheは、RAGシステムに特化したKVキャッシュ管理フレームワークとして、TTFTとスループットの大幅な改善を実証した。チャンク単位のKVキャッシュという設計は、プレフィックスベースのキャッシュでは対応できないRAG特有の課題を解決するものである。

今後の課題として、チャンク間の因果的注意の正確な再構成、動的コーパス更新への対応、APIベースモデルとの統合手法が挙げられる。RAGの推論コスト削減が求められる場面では、本論文のアプローチは有力な選択肢となる。

参考文献

blog paper arxiv
RAG KV-cache prompt-caching LLM inference-optimization langgraph
この投稿は CC BY 4.0 でライセンスされています。
最近の更新
目次