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

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

---

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キャッシュ階層を提供します。⁶

図5．高速な作業台と大きな保管場所を使い分けます。すべてのシステムがこの階層を持つわけではなく、実際の構成は異なります。

ここにもコストがあります。保管場所から資料を取り出すには時間がかかり、リモートストレージならネットワークも使います。保存済みのKVキャッシュを読み込んだ後も、新しい回答を生成する間、その状態を参照し続ける必要があります。

したがって、キャッシュがあれば常に速いわけではありません。取得するコストが再計算するコストより低い場合に利点があります。短い入力は新しく計算するほうがよく、長い共通文書は取得するほうが有利になることがあります。

大規模インフラの効率は、こうした選択の積み重ねです。何を残し、どこに置き、どのリクエストに結び付けるかを一緒に設計します。

7. 小さな再利用も、規模が大きくなると差が広がる

規模の効果を数字で考えてみます。以下は実サービスの測定値ではなく、仮想的な例です。

100件のリクエストが、それぞれ同じ10,000トークンの文書と、異なる500トークンの質問を送ります。キャッシュがなければ毎回、文書を含めた入力を処理します。完全に再利用できれば、文書は最初の1回だけ計算し、その後は新しい質問を処理します。

図6．同じモデルと文書を使い、最初の計算後に期限切れ、キャッシュの追い出し、ルーティングによるミスがなく再利用できると仮定したトークン数の比較です。棒は時間やコストを表しません。

キャッシュなしで新しく処理する入力は、10,500 × 100 = 1,050,000トークンです。共通文書を再利用すると、10,000 + 500 × 100 = 60,000トークンになります。新しくプリフィルする入力トークンは約94.3%減少します。

総コストや計算時間が94.3%減るという意味ではありません。キャッシュの読み出し、保存用メモリ、必要な転送、そしてすべての回答生成が残ります。入力長に伴う計算量も、トークン数に単純比例すると考えることはできません。

それでも、この例は効率化の方向を示しています。同じ計算に繰り返し資源を使う代わりに、新しい質問や作業へより多く使う機会が生まれます。実際の効果は共通入力の長さ、再利用の頻度、メモリの余裕、ルーティングによって変わります。

8. 効率を高めながらユーザーのコンテキストを分離できるか

可能です。ただし、分離の範囲を狭めるほど、再利用できるリクエストも減ります。目標はすべてのリクエストを一つのキャッシュに集めることではなく、許可された境界内で繰り返し計算を最大限再利用することです。

前述のGPU・CPU・ストレージは、どこに保存するかを分ける階層です。公開・組織・ユーザー・セッションは、誰が再利用できるかを分ける境界です。この二つは別です。同じリモートストレージを使ってもユーザーごとのアクセスは分離できる必要があり、GPU上にあるだけで分離が自動的に保証されるわけでもありません。

同じ内容を見つけることと、利用権限は異なる

図書館の公開図書は共有できますが、個人の相談記録は該当ユーザーだけが閲覧できるべきです。キャッシュでも、内容の一致を示す識別値と、その内容を使う資格は別の問題です。ハッシュは暗号化でも、アクセス権限の証明でもありません。

コンテキストの性質	検討する再利用範囲	効率と分離のトレードオフ
公開指示・公開マニュアル	サービスが許可した共有グループ	広く再利用する機会があります
社内文書	同じ組織で同じ権限を持つユーザー	同じ会社でも文書ごとの権限確認が必要です
個人の会話・個人化情報	該当ユーザーまたはセッション	共有範囲は狭まりますが、範囲内の繰り返しは再利用できます

この表はポリシーを決める基準です。すべてのエンジンが、一つのリクエスト内でこれらの境界を自動的に分けるわけではありません。例えばvLLMのcache_saltは最初のブロックのハッシュに入り、その境界は後続ブロックの識別にも引き継がれます。ユーザーごとに異なるsaltを使うと、同じ公開文書まで別々に計算・保存することがあります。⁴

そのため、公開プレフィックスは全員で共有し、個人部分からだけ分離するという目標には、エンジンの区間別共有機能とセキュリティ特性の確認が必要です。単にユーザーデータを後に置いたり、リクエストの途中にキャッシュオプションを追加したりするだけでは十分ではありません。対応していない環境では、キャッシュ全体をユーザー別または権限グループ別に分け、その中で再利用する設計が現実的な選択肢です。

共通入力は共有し、個人のコンテキストは分離する

図7．複数ユーザーのリクエストが共通プレフィックスのキャッシュに集まる地点で、ユーザー間のキャッシュヒットが発生します。個人のコンテキストはその後で分離します。区間別の共有とアクセス制御に対応するエンジンの設計概念であり、リクエスト全体にsaltを適用するvLLMの標準的な分離方式とは異なります。

公開プレフィックスには、個人情報の影響を受けた状態が含まれてはいけません。公開資料を先に、個人のコンテキストを後に置き、入力順序とは別にエンジンが共有境界を強制する必要があります。個人部分を分離しても、あらゆるサイドチャネルが遮断されるわけではありません。

ユーザーAとBが異なるキャッシュ領域を使っていても、Aの2回目のリクエストは、Aの最初のリクエストで作った文書ブロックを再利用できます。Bも自分の領域内で同じように再利用できます。ユーザー間の共有を防ぐことと、同じユーザーの繰り返しリクエストまで毎回再計算することは異なります。 複数セッションでも、同じ権限境界と互換性のある入力を維持すれば再利用の機会があります。逆にリクエストごとに異なる分離値を付けると、その機会も失われます。

この構造に対応せず、キャッシュ全体をユーザー別に分ける場合でも、ユーザー内部の再利用は残ります。比較のため、10人のユーザーがそれぞれ同じ10,000トークンの文書と、毎回異なる500トークンの質問で10回ずつリクエストすると仮定します。すべての領域が空の状態から始まり、その後の期限切れ、追い出し、ルーティングミス、ブロック境界による損失はないとします。

入力の合計は前の例と同じ1,050,000トークンです。各ユーザーの最初のリクエストは文書を計算しますが、残りの9回はキャッシュから読めるため、キャッシュから読む文書は10人 × 9回 × 10,000 = 900,000トークンです。トークン基準のヒット率は900,000 / 1,050,000で、約85.7%です。 この条件では、ユーザー間で共有しなくても、同じユーザー内の繰り返しによって高いヒット率を得られます。

すべての入力の共有が許可された単一の信頼グループという別の仮定では、文書を1回計算して99回再利用し、約94.3%になります。この比較は、ユーザー分離によって減る再利用機会を示します。互いに信頼しないユーザーを同じグループに入れても安全だという意味ではありません。各ユーザーが1回だけリクエストして離れる場合、ユーザー別キャッシュでは同じ利点を得にくくなります。分離単位と、その中での繰り返し頻度を併せて見る必要があります。

ここでのヒット率は、キャッシュから読んだ入力トークンを入力全体で割った値です。一部でもキャッシュを読んだリクエストの割合とは異なり、総コストの削減率でもありません。

キャッシュの存在自体が情報になることもある

分離は、他のユーザーの文書を直接読めなくすることだけでは終わりません。キャッシュヒット時に応答が速くなる差を繰り返し観測すると、特定の入力が以前使われたかを推定する手掛かりになります。これをタイミングサイドチャネルと呼びます。PrefixWallの研究も、共有プレフィックスキャッシュにおけるこの情報推論リスクを扱っています。⁷

キャッシュが一致したからといって、他のユーザーの会話が現在のリクエストに自動で追加されるわけではありません。ただし、内容がリクエストに混入する問題と、使用の痕跡が漏れる問題は、それぞれ防ぐ必要があります。 キャッシュキーの一致を確認する正確性検証では、セキュリティ検証を代替できない理由です。

マネージドAPIの分離範囲も確認が必要です。Claude APIはワークスペース単位でキャッシュを分離しますが、同じワークスペースを使うサービス内の各ユーザーを個別に分離するという意味ではありません。アプリケーションが複数の顧客を一つのワークスペースで処理する場合、顧客別の文書権限と必要な分離構成を別途設計する必要があります。⁸

保管場所へ移しても、鍵は一緒に付いていく必要がある

多階層キャッシュで重要な運用条件は次のとおりです。特定製品の保証一覧ではなく、設計時に確認する項目です。

• 境界の決定：認証済みのユーザーと文書権限に基づき、サーバーが再利用範囲を決めます。クライアントが送ったユーザーIDやsaltだけを信頼し、他人の領域を選択できるようにしてはいけません。
• 境界の維持：GPUブロックの検索だけでなく、CPUキャッシュ、リモートストレージ、サーバー間転送、キャッシュの所在一覧にも同じ区分を維持します。保存場所を移すときに権限範囲が広がってはいけません。
• アクセス制御と暗号化の区別：必要に応じて転送時・保存時の暗号化を適用しつつ、復号できるサービスが誰の資料を取り出せるかも別途制限します。
• 権限変更と削除：権限が取り消されたら、キャッシュが残っていても次の利用を防ぐ必要があります。保持期限と削除ポリシーは、GPU外のコピーとストレージにも適用します。

LMCacheの保存暗号化の文書も、この違いを示します。ユーザー・テナント別のsaltで暗号鍵を分けても、共通マスターキーを持つサーバーは全テナントのデータを復号できます。この構成だけではテナント間のアクセス分離にはならないと明記しています。⁹

結局、確認すべき問いは、キャッシュがどのくらいヒットするかに加え、誰がどのキャッシュを見つけ、取得し、再利用できるかです。効率指標とともに、権限の異なるユーザー間での検索・再利用が拒否されることも検証する必要があります。

---

結論

LLMインフラは、モデルを実行する機器とともに、その機器に処理を割り当てる方法も進歩しています。同じ入力の計算を共有し、キャッシュのあるサーバーへリクエストを送り、限られたGPUメモリと外部の保存領域を使い分けることが、その例です。

AnthropicのS-1にある推論効率の説明は、この変化が実際の事業運営でも重要になっている根拠の一つです。本記事の図はvLLM・SGLang・LMCacheの公開技術から一般原理を説明したもので、Anthropicの内部配置を再現したものではありません。

キャッシュの原理は単純です。すでに行った計算を保存し、次のリクエストがその地点から処理を続けられるようにします。 大規模インフラの難しさは、その計算を多くのリクエストの中で適時に見つけ、必要な場所に置き、領域不足時に適切に解放することにあります。その全過程でユーザー別の権限境界を維持する必要があります。効率化の目標は、許可された共有を増やしながら非公開コンテキストの境界を守ることです。

処理単位の効率が改善しても、それ以上に利用量が増えればインフラ支出の総額は増えることがあります。効率化とは、同じ性能の作業1件に必要な資源を減らすこと、または同じ資源でより多くの作業を処理できることです。キャッシュは、その変化を理解するためのよい手掛かりです。

---