はじめに

LLM の出力を速くしたくて、このブログではプレフィックスキャッシュで TTFT が約9割短くなることまで実測してきました。「同じ長文を毎回 prefill するのはもったいない」という話です。

その延長で、ひとつ気づいたことがあります。vLLM のようなローカル LLM を自前で動かしているなら、そもそも検索（RAG）を捨ててしまう設計が選べる のです。KV キャッシュの使い回しを自分で直接コントロールできるからです。API 経由で LLM を使っている場合は、この制御は原則できません。

その「検索を捨てる設計」に名前をつけた論文が、2024 年末に出ています。「Don't Do RAG」 ——知識を全文コンテキストに積みっぱなしにして、KV キャッシュごと使い回す CAG（Cache-Augmented Generation） です。

プレフィックスキャッシュを手元で触ってきた身としては、これは試さないわけにいきません。検索を消して全部入れるほうが 速くて正確 なのだとしたら、わざわざチャンクに割って埋め込んで DB を立てる意味は、ローカルで動かしているかぎりかなり薄くなります。

——本当にそうなのでしょうか。論文の評価は英語・大規模 GPU が前提です。
そこで、日本語の小説 50 問・RTX 4070（12GB）・4B モデル という自分の手元の条件で、RAG と CAG を同じ土俵で比べてみました。

この実装編では、その「土俵」をどう組んだのかを、実際のコードまで開いて説明します。CAG が全文を積んでも遅くならない仕組み、12GB で 4B モデルを動かすための設定、そして比較を歪ませないために気をつけた点——順番に見ていきます。

勝敗の数字は次の〈結果編〉でまとめて出します。

TL;DR

LLM に手元の資料を読ませて答えさせる方法は、大きく 2 つあります。「持ち込み可の試験」にたとえると分かりやすいです。

RAG（Retrieval-Augmented Generation） は、質問のたびに関係しそうな箇所だけを資料から探し出して LLM に渡す方式です。試験のたびに、必要そうなページだけコピーして持ち込むイメージです。資料が分厚すぎてコンテキストに入り切らないときでも、必要な部分だけ渡せば正確に答えられる ——これが RAG の最大の強みです。
CAG（Cache-Augmented Generation） は、資料を丸ごと最初から LLM に渡しておく方式です。教科書を 1 冊まるごと持ち込んで、机に広げっぱなしにするイメージです。成り立つ条件は 「資料がそもそもコンテキストに収まる大きさであること」。ローカル GPU はメモリが限られるので、ここは重要な前提になります。
違いは「LLM が一度にどれだけ見えているか」です。RAG は探して当たった数ページだけ、CAG は全文が見えています。今回の結果の差は、ほぼここから生まれます。
「全部渡したら、読むのに時間がかかって遅いのでは？」と思うところですが、同じ資料に何度も質問するなら、資料の読み込み計算（プレフィル）は最初の 1 回だけで済みます。計算結果を保存して使い回す仕組み（プレフィックスキャッシュ）があるからです。毎回同じ前置きを送る使い方ほど、2 回目以降の計算がまるごと節約できます——ここが今回いちばん面白い点です。
ただし CAG は、vLLM のようなローカル LLM を自分で動かしている場合にだけ選べます。ChatGPT のような API 越しの利用では、この"使い回し"を自分で操作できないからです。
本記事（実装編）は 仕組みと土台の作り方 までを扱います。速度・精度の実測と勝敗 は〈結果編〉に置きます。

技術背景 — なぜ「知識の渡し方」が論点になるのか

LLM 単体は、学習した時点までの知識しか持っていません。社内文書や最新情報、特定ドメインの知識を扱わせるには、推論時に外から知識を渡す必要があります。その代表が RAG（Retrieval-Augmented Generation） です。

RAG は知識を外部ストア（ベクトル DB）に置き、質問のたびに関連箇所だけを検索して LLM に渡します。大規模な知識ベースにもスケールする一方で、チャンク分割・埋め込み・ベクトル検索というパイプライン を運用し続けるコストがかかります。さらに「検索が外した瞬間に、LLM は正しく答える材料を失う」という構造的な弱さも抱えています。

ここ数年で状況を変えたのが、コンテキスト長の拡大 と KV キャッシュの再利用 です。モデルが数万トークンを一度に読めるようになり、しかも「同じ前置きの計算結果を使い回す」最適化が実用化されました。すると、こんな発想が成り立ちます。

知識ベースが小さくてコンテキストに収まるなら、検索などせず全文を入れてしまえばいい。計算結果をキャッシュしておけば、毎回読み直すより速い。

冒頭で触れた論文 「Don't Do RAG」 が、まさにこれを正面から主張し、CAG（Cache-Augmented Generation） という名前を広めました。検索という工程そのものを消してしまう設計です。

"Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks"
Brian J. Chan et al.（国立陽明交通大学／中央研究院）, arXiv:2412.15605, ACM Web Conference 2025 採択

GPTシリーズのトークン数

モデル	最大出力トークン数	コンテキスト長
GPT-3.5 Turbo	4,096	16,385
GPT-4	8,192	8,192
GPT-4o	16,384	128,000
GPT-5	128,000	400,000
GPT-5 Chat	16,384	128,000

最近はGPU側のメモリやモデルの能力が向上し、扱えるトークン数が伸びてきましたが、RAGが出始めの2024年前半ごろはGPT3.5 turbo の16KやGPT4の8Kとたった2年前まではこれしか使えなかったのですから、最近のモデルのトークン能力の向上には驚かされます。

なぜ自分で測り直すのか

論文のベンチマークは英語（HotPotQA / SQuAD）で、GPU も研究用の大型環境が前提です。私が使うのは RTX 4070（12GB）で、扱うのは日本語のテキストですから、論文と条件がそろっていません。同じ傾向が出るのかどうか、数字をそのまま信じる気にはなれませんでした。

もうひとつ、気になっていた点があります。定番のベンチマークには「答えが本文に書かれていない質問」という種類が含まれていません。けれども実際に使えば、そういう質問は必ず来ます。「知らないことを、正直に知らないと言えるか」——ここが RAG と CAG の設計差が最も出る場面だと考えていました。

そこで、今回はLLMが知らない知識として、Codex（GPT-5.5）に4000文字程度の物語を作らせ、その物語をRAG or 全文キャッシュで入れ、日本語・コンシューマ GPU・unknown 型を含む 50 問 という自分なりの条件をそろえて、両者を同じ設定で動かしました。CAG は vLLM を自前で動かしているからこそ試せた設計で、API ユーザーにはそもそも選択肢になりません。だからこそ、手元で検証できるうちに数字を出しておきたかったのです。この記事はその「土俵の作り方」を、コードまで開いて説明します。出てきた数字は〈結果編〉でまとめて出します。

RAG と CAG は何が違うのか

RAG は「質問のたびに探して、当たった断片だけ渡す」方式です。CAG は「最初から全部入れておき、あとは質問するだけ」の方式です。

設計上の本質的な違いは、「LLM が何を見ているか」 に集約されます。

	RAG	CAG
知識の置き場	外部（ベクトル DB）	LLM のコンテキスト（プロンプト）内
質問時の処理	検索 → 上位チャンク抽出 → 注入	そのまま投げるだけ
LLM が見る範囲	当たった3チャンクのみ	物語の全文
速くする鍵	検索を速くする	KV キャッシュの使い回し

「全部入れたら遅いのでは？」への答え — プレフィックスキャッシュ

答えから言うと、遅くなりません。理由は KV キャッシュの使い回し（プレフィックスキャッシュ） です。LLM は、同じ前置き（プレフィックス）に対する内部状態を、一度計算してしまえば再計算せずに使い回せます。全文をコンテキストに入れても、その prefill 計算は最初の 1 回で済むわけです。

全文部分を一度計算してキャッシュしておけば、2 問目以降はその計算をまるごとスキップできます。 これが「全文を入れても速い」種明かしです。

vLLM では、これが Automatic Prefix Caching (APC) として実装されています。今回はこれをそのまま使います。本当に速くなるのかどうか、実測値は〈結果編〉で出します。

実験のセットアップ

公平に比べるため、LLM・質問・採点者はすべて共通 にしました。変えたのは「知識をどう渡すか」だけです。

要素	中身
題材	自作の日本語短編小説『潮霧湾の門守り』（約2,450トークン）
質問	50問。6タイプ（simple / detail / relation / timeline / inference / unknown）に分類
LLM	`Qwen3.5-4B-FP8`（vLLM, ローカル, RTX 4070 12GB）
埋め込み（RAG用）	`cl-nagoya/ruri-v3-310m`（日本語特化）
採点	LLM-as-a-Judge（Gemini 3.1 Flash Lite, 0/1/2点）

LLM-as-a-Judge とは、人手の採点の代わりに、別の LLM を採点者として使う評価手法です。100 回答を人間が採点する手間を避けつつ、単純な文字列マッチよりも意味を汲んだ採点ができます。今回は Gemini を採点者にして、RAG・CAG どちらの回答かを伏せたブラインド方式で採点しました。詳しくは後ろの「採点」の節で説明します。

設計でこだわったのは、次の 2 点です。

題材を自作小説にしました。モデルが事前学習で答えを"知っている"可能性を消すためです。Wikipedia のような有名なテキストだと、コンテキストを見なくても答えてしまい、検証になりません。
unknown（本文に答えがない）型を質問に混ぜました。「知らないことを知らないと言えるか」を測るためです。ここは RAG と CAG の設計差が最も出るはずの観点だと考えました。

RAG 側をどう組んだか

RAG は「チャンク分割 → 埋め込み → 検索 → 生成」の 4 工程です。

固定長で切らず、意味の切れ目で分割する

隣り合う文の埋め込みのコサイン類似度を見て、類似度が下位 25% に落ちる境界（＝話題の変わり目）で区切ります。段落や章見出しは強制的に区切ります。狙いは「ひとつのチャンクに複数の話題を混ぜないこと」です。約 2,450 トークンの小説が、32 チャンク になりました。

セマンティックチャンク分割のコア（クリックで展開）

# 隣接文のコサイン類似度を計算し、下位25パーセンタイルを「意味の切れ目」とする
sims = [float(np.dot(emb[i], emb[i + 1])) for i in range(n - 1)]
threshold = float(np.percentile(sims, 25))

# 目標256字。意味の切れ目 or サイズ超過で chunk を確定
semantic_break = i < len(sims) and sims[i] < threshold
size_break = cur_len >= target * 1.5
if is_last or must_break or (semantic_break and cur_len >= target * 0.5) or size_break:
    flush()

埋め込みモデルの作法を守る

日本語特化の cl-nagoya/ruri-v3-310m には、固有の作法があります。クエリ側にだけ "クエリ: " プレフィックスを付ける （ドキュメント側には付けない）というものです。これを忘れると検索精度がはっきり落ちます。地味ですが、ここを外すと RAG 全体が実力よりも弱く見えてしまう、見逃せない一点です。

QUERY_PREFIX = "クエリ: "

def retrieve(model, index, chunks, query, top_k=3):
    vec = model.encode(
        [QUERY_PREFIX + query],          # ← クエリにだけプレフィックス
        normalize_embeddings=True,
    ).astype(np.float32)
    scores, indices = index.search(vec, top_k)   # FAISS でコサイン類似度検索
    return [chunks[i] for i in indices[0]]

検索エンジンには FAISS（Meta 製のベクトル検索ライブラリ、faiss-cpu）を使います。GPU は vLLM が占有しているため、埋め込みと検索はすべて CPU で回します。

検索結果をプロンプトに詰める部分（クリックで展開）

def build_prompt(question, context_chunks):
    context = "\n\n".join(
        f"[チャンク{i+1}]\n{c['text']}" for i, c in enumerate(context_chunks)
    )
    return (
        "以下の文章を参考にして、質問に日本語で簡潔に答えてください。\n\n"
        f"【参考文章】\n{context}\n\n"
        f"【質問】\n{question}\n\n【回答】"
    )

ここに RAG の本質が表れています。LLM が見られるのは、検索で当たった 3 チャンクだけ で、物語の全体像は見えていません。

CAG 側をどう組んだか

CAG は、驚くほどシンプルです。検索もチャンクも DB もありません。小説全文を system プロンプトに丸ごと入れて、質問を投げるだけ です。

SYSTEM_PROMPT_TEMPLATE = (
    "あなたは以下の物語についての質問に答えるアシスタントです。"
    "物語の内容だけを根拠にして、日本語で簡潔に答えてください。"
    "物語に記載のない情報は「記載なし」と答えてください。\n\n"   # ← この一文が効く
    "【物語】\n{story}"
)

messages = [
    {"role": "system", "content": system},   # ← 小説全文がここに丸ごと
    {"role": "user", "content": question},
]

「記載のない情報は『記載なし』と答えて」 という一文に注目してください。全文が見えている CAG は、この指示にきちんと従えます。一方の RAG は当たったチャンクしか見ていないので、「本当に記載がないのか」を判断する材料そのものを持っていません。

プレフィックスキャッシュを効かせる

起動時にウォームアップを一発投げて、小説全文をキャッシュに焼いておきます。1 問目はキャッシュ未生成（miss）、2 問目以降は再利用（hit） として、両者の所要時間を別々に測れるようにしました。

ウォームアップとキャッシュ計測の仕込み（クリックで展開）

# 起動直後に全文をキャッシュへ焼く
if args.warmup:
    call_llm(system, "物語の舞台はどこですか？", client)

# 1問目=miss, 2問目以降=hit として TTFT を別集計
cache_status = "miss" if i == 1 else "hit"

vLLM の起動設定には、RTX 4070（12GB）で全文コンテキストを回すための工夫が詰まっています。vLLM の Automatic Prefix Caching ドキュメントも参考にしてください。

vllm serve RedHatAI/Qwen3.5-4B-FP8-dynamic \
  --dtype auto \
  --max-model-len 32768 \          # CAG で全文＋余裕を確保
  --gpu-memory-utilization 0.90 \
  --enforce-eager \                # CUDA graph は 12GB だと OOM
  --enable-prefix-caching          # ← CAG の心臓部

設定	値	理由
量子化	FP8	BF16 は 12GB で OOM になる
実行モード	`--enforce-eager`	CUDA graph も 12GB だと OOM になる
最大コンテキスト長	`--max-model-len 32768`	CAG で全文＋余裕を確保する
GPU メモリ使用率	`0.90`	KV キャッシュ領域を確保する
プレフィックスキャッシュ	`--enable-prefix-caching`	CAG の心臓部

採点 — LLM-as-a-Judge

50 問 × 2 手法 = 100 回答を、人手ではなく Gemini に 0/1/2 の 3 段階 で採点させました。RAG と CAG は 別々に・独立して 採点します（どちらの手法の回答かを採点者に知らせません）。生成は両手法とも temperature=0.0・ストリーミングで行い、TTFT（最初のトークンが返るまでの時間）まで計測しています。

採点基準は「模範解答と照らして、事実として正しいか」です。unknown 型では「記載なしと正しく答えられたか」を見ます。

実装で得た知見 — そのまま使える勘所

同じことをやる人がつまずかないよう、効いた判断を 5 つ残しておきます。

勘所	なぜ重要か
クエリにだけ `"クエリ: "` を付ける	`ruri-v3` 系はクエリ／ドキュメントで前処理が非対称。付け忘れると RAG が実力より弱く見え、比較結果そのものが歪む
12GB なら FP8 ＋ `--enforce-eager`	BF16 も CUDA graph も即 OOM。FP8 量子化と eager 実行で、4B モデル＋32K コンテキストがぎりぎり載る
チャンクは固定長でなく意味境界で切る	1 チャンクに話題が混ざると検索の解像度が落ちる。隣接文の類似度の谷で切ると「当たり」の純度が上がる
採点はブラインド＆独立で	RAG/CAG どちらの回答かを採点者に伏せる。手法バイアスを抜かないと、精度比較は信用してもらえない
コーパスは自作する	既知のテキストだとモデルが暗記で答え、コンテキスト依存を測れない。自作小説でリークを断つ

どれも「動かすだけ」なら不要ですが、「比較の数字を信用できるものにする」ためには外せない判断でした。比較実験は、前処理ひとつで結論がひっくり返ってしまいます。

ここまでの設計まとめ

実装の負荷だけで見ると、RAG はパイプライン一式が必要で、CAG は system プロンプトに全文を入れるだけです。

条件をそろえた実験台が整いました。同じ LLM、同じ 50 問、同じ採点者。違うのは知識の渡し方だけです。立てた問いは、次の 3 つです。

6.4 倍も長いプロンプトを毎回投げる CAG は、本当に RAG より速いのか。
検索で"当たり"を引く RAG と、全文を見渡す CAG、正答率はどちらが上なのか。
そして「答えが本文にない」質問で、両者はそれぞれ何を答えたのか。

ここに、自分でも予想していなかった 速度の逆転 と、はっきりとした 設計由来の差 が出ました。次の〈結果編〉で、50 問ぶんの数字と 失敗例の実物 をまとめて出します。

参考

実装コード・データ・計測スクリプト一式（本記事のリポジトリ）: ai-systems-notes/local-llm-rag-cag-benchmark
Brian J. Chan et al., "Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks", arXiv:2412.15605, ACM Web Conference 2025
vLLM — Automatic Prefix Caching
cl-nagoya/ruri-v3-310m（Hugging Face）
FAISS — Meta AI のベクトル検索ライブラリ
RedHatAI/Qwen3.5-4B-FP8-dynamic（Hugging Face）