Tech Learning Daily

LLM は 1 トークン書くたびに、全文を振り返っている

LLM は文章を 1 トークンずつ生成する。自己回帰生成とは、それまでの全トークンを入力にして次の 1 トークンを予測し、出力したトークンを入力の末尾に足してまた次を予測する、という繰り返しのことだ。1000 番目のトークンを予測するには 999 個分の文脈が、1001 番目にはそれに 1000 番目を加えた文脈が要る。

文脈を参照する部品が Attention（注意機構）だ。各トークンは層ごとに 3 種類のベクトルに変換される。「何を探しているか」を表す Query、「自分はどんな情報か」という見出しにあたる Key、「中身」にあたる Value である。新しいトークンの Query を過去の全トークンの Key と照らし合わせ、似ているものほど重く Value を混ぜ合わせることで、文脈を取り込んだ表現を作る。

素朴に実装すると、1 トークン生成するたびに過去の全トークンの Key と Value を計算し直すことになる。2,000 トークンの回答を書くなら、プロンプト全体を 2,000 回読み直す計算だ。これがそのまま毎回行われていたら、長いプロンプトは実用にならない。

過去の Key と Value は、未来が何であっても変わらない

ここで LLM の設計上の制約が効いてくる。生成型の LLM は因果マスク、つまり各トークンが自分より前のトークンしか参照できない制限をかけて動く。3 番目のトークンの Key と Value は 1〜3 番目だけから決まり、4 番目以降に何が来ても変わらない。変わらないのだから、一度計算したら保存しておけばよい。これが KV キャッシュで、層ごとに過去トークンの Key と Value を溜めておき、新しいトークンの分だけ計算して末尾に追加する。

KV キャッシュがあると、1 回の API 呼び出しは 2 段階に分かれる。最初の prefill では、入力プロンプトの全トークンの Key と Value をまとめて計算する。入力は最初から全部そろっているので並列に計算できるが、プロンプトが長いほど時間がかかり、最初の 1 トークンが返るまでの時間（TTFT）の大半を占める。続く decode では、キャッシュを参照しながら 1 トークンずつ生成する。

ここまでは 1 回のリクエストの中の話だ。しかし同じ理屈はリクエストをまたいでも成り立つ。昨日も今日も同じ社内規程から始まるプロンプトなら、規程部分の Key と Value はまったく同じになる。prefill の結果をサーバー側に残しておけば、次のリクエストはそこから計算を再開できる。これがプロンプトキャッシュ（実装の文脈ではプレフィックスキャッシュとも呼ぶ）である。

一致を判定するのは「先頭からの連なり」

同じ文章がプロンプトのどこかに含まれていればキャッシュが効くように思える。しかし実際は、先頭から完全に一致した範囲しか再利用できない。3 番目のトークンの Key と Value は 1〜2 番目に依存するので、前に 1 文字でも違うものが挟まれば、後ろが同じ文章でも計算結果は別物になるからだ。

推論サーバー vLLM の実装はこの性質をそのまま形にしている。KV キャッシュを一定トークン数のブロックに分け、各ブロックを「直前のブロックのハッシュ＋ブロック内のトークン」でハッシュ化する。ハッシュが鎖状につながるため、途中のブロックが一致するのは、そこまでの全ブロックが一致しているときだけになる。また、トークンで埋まりきったブロックだけがキャッシュされる。

ブロック = トークン数個ずつの塊
hash(n) = H( hash(n-1) + ブロックnの中身 )

1回目 ┌─────┬─────┬─────┬─────┐
      │規程A│規程B│規程C│質問1│
      └──┬──┴──┬──┴──┬──┴─────┘
         ▼     ▼     ▼  保存
2回目 ┌─────┬─────┬─────┬─────┐
      │規程A│規程B│規程C│質問2│
      └─────┴─────┴─────┴─────┘
       ◀─── 一致: 再利用 ──▶ 計算

先頭に日時を入れた場合
      ┌─────┬─────┬─────┬─────┐
      │10:01│規程A│規程B│規程C│
      └─────┴─────┴─────┴─────┘
       ▲ ここが違う → 以降すべて再計算

図の下段が典型的な落とし穴だ。システムプロンプトの先頭に「現在時刻: 10:01」を入れると、後ろの規程が一字一句同じでも、毎回すべてが再計算になる。同じ情報を末尾のユーザーメッセージに移すだけで、規程部分は再利用できるようになる。

API ではどう指定し、どう課金されるか

Anthropic の API では、どこまでをキャッシュするかの区切り（キャッシュブレークポイント）を cache_control で指定する。プレフィックスは tools → system → messages の順に組み立てられ、ブレークポイントより前の全体がキャッシュの対象になる。ブレークポイントは 1 リクエストに最大 4 つ置ける。

"system": [
  {
    "type": "text",
    "text": "（長い社内規程）",
    "cache_control": {"type": "ephemeral"}
  }
]

寿命は既定で 5 分で、ヒットするたびに追加料金なしで延長される。数分おきに問い合わせが来るボットなら規程部分は温まったままになるが、問い合わせが 5 分以上途切れれば次の 1 回は書き込み直しになる。"ttl": "1h" を指定すれば 1 時間に延ばせるが、書き込み料金は通常の入力の 2 倍になる。5 分版の書き込みは 1.25 倍、読み出しは多くのモデルで 0.1 倍（新しいモデルではさらに安い）だ。つまり 1 回しか使わない内容をキャッシュすると割高になり、2 回目以降の再利用で元が取れる。

キャッシュの効き具合はレスポンスの usage で確認できる。cache_creation_input_tokens が書き込んだ量、cache_read_input_tokens が再利用できた量、input_tokens が最後のブレークポイントより後ろの通常課金分で、3 つの合計が入力全体になる。ブレークポイントの手前がモデルごとの最小長（512〜4,096 トークン）に満たないと、エラーにならずにキャッシュだけが黙ってスキップされる点にも注意したい。また、ツール定義を変えると tools 以降のすべてが無効になる。並び順の上流ほど変更の影響が大きい。

OpenAI の API は既定で自動的にキャッシュする方式で、指定しなくても一致する先頭部分が再利用され、ヒット量は usage.input_tokens_details.cached_tokens に出る。指定の仕方は違っても、先頭からの完全一致が条件である点は同じで、どちらのドキュメントも「静的な内容を前、動的な内容を後ろ」を推奨している。