LLMキャッシュはどう動くのか：AnthropicのS-1報告書から読み解くAIインフラの効率化

Wed, 28 Oct 2026 10:00:00 +0900

AnthropicはS-1で、一定のモデル性能を提供するために必要な推論計算を減らすとともに、本番環境での計算資源の利用効率も改善してきたと説明しています。– 「Compute Efficiency」の要約¹

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

LLMインフラは、同じ性能の処理に必要な計算を減らし、確保した資源をより有効に使う方向へ進化しています。AnthropicのS-1にある推論効率の説明は、この流れを示す根拠の一つです。
プロンプトキャッシュは、同一の入力の先頭部分を処理して作ったKVキャッシュを再利用します。長い文書の再計算を減らしますが、新しい質問の処理と回答の生成は引き続き必要です。
大規模インフラでは、共通の計算をメモリブロックとして共有し、キャッシュの場所と負荷を考慮してリクエストを分散します。GPUメモリの外にもキャッシュを保存するシステムがあります。
キャッシュ効率を高めるには、誰の計算を誰と共有できるかを先に決める必要があります。ユーザーごとの分離は再利用の範囲を狭めることがあり、GPUの外でも同じ権限境界を維持しなければなりません。
効果は再利用の頻度、メモリの余裕、転送コストによって変わります。再処理する入力トークンの減少率を、総コストの削減率と解釈してはいけません。

同じ製品マニュアルを持って、相談員を訪ねる場面を想像してみてください。初日は最初から読む必要があります。翌日、別の質問をしたのに、相談員がまたマニュアルを最初から読み直したらどうでしょうか。質問に答える時間より、同じ資料を繰り返し読む時間のほうが長くなるかもしれません。

LLMサービスでも似たことが起こります。質問と一緒に、製品文書、ツールの使い方、会話履歴を送るためです。画面に見えるのは新しい質問の1行だけでも、サーバーに送られる入力には、以前送った内容が長く付いています。

LLMインフラの効率化には、この繰り返し作業を見つけて減らすことも含まれます。 GPUの増設と並行して、実行済みの計算を再利用する技術も進歩しています。その中心にキャッシュがあります。

2026年10月26日に公開されたAnthropicの新規株式公開に向けた登録届出書、S-1は、この変化を確認できる根拠の一つです。本記事ではS-1の説明を出発点に、大規模インフラでキャッシュがどう動くかを7枚の図で説明します。

ここで運用者が直面する重要な問いがあります。キャッシュ効率を高めながら、複数ユーザーのコンテキストを互いに分離できるのでしょうか？ 保存領域を増やす設計とともに、誰に再利用を許可するかも考える必要があります。

以下の図は、vLLM・SGLang・LMCacheの公開技術を使って一般的な原理を説明します。Anthropicの実際の内部構成を示すものではありません。

1. S-1が示す変化：同じ資源でより多くの処理を行う

S-1は、推論に必要な計算を減らす研究と、確保した計算資源をより効率的に使う運用改善を説明しています。別のプラットフォーム機能の説明では、長いプロンプトにキャッシュを適用すると、同じリクエストをキャッシュなしで処理する場合に比べて、コストを最大約97%、レイテンシを約60%削減できるとしています。¹

ここで読み取るべき流れは、モデルを提供する方法も改善し続けているという点です。ただし、この数値は長いプロンプトに対する条件付きの効果です。Anthropic全体のインフラ運用費が同じ割合で減ったことや、その改善のすべてがキャッシュによることを意味しません。

では、キャッシュはこの流れにどう貢献するのでしょうか。理解するには、LLMが回答を作る過程を二つに分けると分かりやすくなります。

2. 回答する前に、まず入力を読む必要がある

一般的な生成LLMの推論には、大きく二つの段階があります。

プリフィル（prefill）：入力文を処理し、回答の生成時に参照する内部状態を計算します。
デコーディング（decoding）：その状態を参照しながら、回答をトークン単位で生成します。トークンは、モデルがテキストを扱う小さな単位です。

最初の段階は資料を読んで作業を準備する過程、次の段階は資料を見ながら回答を書き進める過程と考えると分かりやすいでしょう。

モデルはこの過程で、アテンションに使うキー（key）と値（value）という数値配列を作ります。これを保存したものがKVキャッシュです。同じリクエストの中では、次の回答トークンを作るたびに、それ以前のトークンのキーと値を再計算せずに済むようにします。²

この再利用をリクエスト間に広げることもできます。同じモデルと互換性のある実行条件で、新しいリクエストが以前と同じ入力から始まる場合、先頭部分のKVキャッシュを取得して続きから処理します。これをプロンプトキャッシュ、またはプレフィックスキャッシュと呼びます。³

図1．キャッシュは長い共通文書の再計算を減らします。新しい質問の処理と回答の生成は残ります。

相談員のたとえに戻ると、KVキャッシュは、読んだ内容を次の計算ですぐ参照できるように準備した作業資料に近いものです。ただし、人が読む要約文ではありません。モデル計算に使う数値配列であり、モデル自体を再学習させるものでもありません。

したがって、前回と似た回答を取り出す仕組みとは動作が異なります。同じ文書を再利用しても、今回の質問に対する回答は新しく生成します。

3. 同じ文書でも、その前に何があるかが重要

二人の顧客が同じ製品マニュアルについて質問するとします。一人は機能を、もう一人は外部システムとの連携方法を尋ねます。質問が違っても、マニュアルまでの入力が同じなら、共通の計算を再利用する機会が生まれます。

図2．プレフィックスは入力の先頭部分です。共通の経路を進み、質問が異なる地点からそれぞれ計算します。

なぜ文書の内容が同じだけでは足りないのでしょうか。一般的な自己回帰型トランスフォーマーでは、一つのトークンの内部状態は先行するトークンの影響を受けます。文書の前に別の指示があると、同じ文書も別の文脈で処理されます。そのため、先頭からどこまで一致するかが重要になります。³

例えば、リクエストの先頭に毎回異なる時刻やセッションIDを入れると、その後に同じマニュアルがあっても以前の計算をそのまま使いにくくなります。共通の指示と文書を先に置き、新しい質問を後に付けると、共通経路が長くなります。

エージェントも同じ原理です。ツール定義、作業指示、以前の会話を維持し、新しい実行結果だけを後に追加すると、再利用できる部分が増えます。会話履歴を要約に置き換えたり、共通の指示を修正したりすると、変更した地点以降は新しい計算が必要になることがあります。

これが、単に文章を短くすることとは異なる最適化である理由です。長い入力でも、大部分が安定して繰り返されるなら、再利用できる計算は多くなります。

4. 多くのリクエストに備え、キャッシュをブロックに分ける

ユーザーが増えると、マニュアル1部を再利用するだけでは十分ではありません。多くの会話が同時に進み、それぞれ長さも異なります。KVキャッシュを置くメモリの管理が重要になります。

一つの方法は、キャッシュを小さなブロックに分けることです。本全体を人ごとにコピーする代わりに、共通して読むページのまとまりを一緒に参照すると考えられます。PagedAttentionは、KVキャッシュをブロックとして管理し、メモリの無駄を減らす方法を示しました。²

図3．共通の計算は1部を一緒に参照し、リクエストごとに異なる部分は別に管理します。vLLMのブロック管理を簡略化した図です。

共通ブロックを探すには識別情報も必要です。vLLMは、ブロックのトークンに加えて、前のブロックのハッシュなどを識別に使います。ハッシュは内容を探すための識別値と考えればよいでしょう。先頭部分まで識別に結び付けるため、同じ単語があるという理由だけで、別の文脈の計算を混ぜることはありません。⁴

メモリには限りがあるので、すべてのキャッシュを永遠に保存することはできません。まだリクエストが使っているブロックと、使用が終わり再利用を待っているブロックを区別する必要があります。領域が不足すると、後者から入れ替え対象を選びます。⁴

よく使われる共通資料を残せば、次のリクエストの再計算を減らせます。まれにしか再利用されない資料を長く保持すると、新しいリクエストが使える領域が減ります。キャッシュ管理は結局、将来の再利用機会と現在のメモリ需要を調整する作業です。

5. サーバーが増えると、どこへ送るかも重要になる

推論サーバーが複数台あるとします。サーバーAには製品マニュアルのキャッシュがあり、Bにはありません。同じ質問でも、送信先によって再計算の量が変わります。

リクエスト数を単純に均等配分するだけでは、既存のキャッシュを活用できないことがあります。そこでキャッシュを考慮したルーティングが登場します。ルーティングとは、受信したリクエストを処理するサーバーに送ることです。

図4．クラスタのどこかにキャッシュがあるだけでは十分ではありません。リクエストがその計算結果を利用できる必要があります。

本をすでに読んだ相談員に次の質問を送るのと似ています。ただし、その相談員の前に大勢が並んでいるなら、別の相談員が新しく読むほうが早く終わることもあります。

そのためルーターは、誰が先頭部分を再利用できるかと、どのくらい待つかを併せて判断する必要があります。公開サービングプロジェクトのSGLangのモデルゲートウェイも、キャッシュと負荷を考慮するポリシーを提供しています。⁵

図のサーバー1台は、実際には複数GPUが協働する推論単位かもしれません。重要なのは物理的な機器の台数より、キャッシュの場所です。転送や共有の仕組みがあれば結果を取得できますが、そうした構成がなければ、受信したサーバーで再計算する必要があります。

この段階でキャッシュは、単一サーバーのメモリ機能を超えたクラスタ全体のリクエスト配置問題になります。

6. 高価な作業台には、今必要な資料を置く

GPUメモリは高速ですが、広さが限られた作業台です。読んだ資料をすべて積み上げると、次の作業を始める場所がなくなります。

そこで、一部のシステムはKVキャッシュをGPUの外へ移して保存します。すぐ使う資料はGPUに、それほど急がない資料はCPUメモリやストレージに置く方法です。LMCacheは、CPUメモリ、ローカルストレージ、リモートストレージを利用するKVキャッシュ階層を提供します。⁶

Cost-Optimization on ROBOCO