オープンウェイト LLM のキャッシュ：成否がプロバイダー次第になる理由

クローズドモデルでは、prompt caching の仕様は 1 つの契約として文書化されています。Claude には cache_control の breakpoint があり、OpenAI と Gemini は token 数が一定以上になると自動でキャッシュします。割引率も公開され、安定しています。ドキュメントを 1 ページ読めば済みます。

オープンウェイトでは、この前提が崩れます。同じ Qwen や Llama の checkpoint が多数のホストから提供されており、キャッシュはモデルの性質ではなく、モデルをどこで実行するかによって決まります。 その影響を示すため、実測したリクエストを見てみましょう。同一の約 4.7K-token の prompt を、multi-provider router 経由で同じ Qwen モデルに 6 回送信しました。upstream は固定していません。

モデルも router も prompt も同じです。それでも請求額は $0.0141 から $0.000286 まで、49 倍の差が出ました。違いは、router がどの upstream を選んだかと、その upstream に prefix の warm cache があったかだけです。

要約

• オープンウェイトモデルの prompt caching はモデル機能ではなく、ルーティングの結果です。 推論エンジンが無料かつ自動で実装し、その上の各レイヤーがキャッシュを維持することも壊すこともあります。
• 5 つのレイヤーのうち、キャッシュを提供するのは 1 つで、3 つは壊す可能性があります。 モデル（キャッシュしやすさを決めるが、キャッシュ自体は提供しない）→ 推論エンジン（無料のキャッシュ）→ compute host（機能として提供するが、品質にばらつきがある）→ gateway（複数 cluster へのルーティング）→ router（キャッシュを共有しない複数 vendor に分散）。
• 実測結果。 router に分散された同一リクエストは、選択先によってコストが 49 倍になりました。同じモデルでも、あるホストでは 59.6% 割引、別のホストでは 0% でした。公開されているキャッシュ割引率も、モデルによって 0% から約 98% まで幅があります。
• 取るべき対応。 経路を固定し、同じ prefix が同じ warm cache に届くようにします。監査には cached_tokens ではなくコスト差を使ってください。実際に hit していても、この値が 0 になることは珍しくありません。レイテンシはコストと分けて評価します。コスト割引が約 0% でも、warm prefill は 2〜10 倍高速です。

実測値は 2026-06-14 に、multi-provider router と自社 gateway を対象として取得しました。約 4.7K-token の固定された英語 prompt、小さな max_tokens、逐次実行という条件です。公開価格は同日に一次資料で確認し、反証を試みる形でもクロスチェックしました。環境が変わっても参考になるのは、割引率やレイテンシ変化などの比率です。絶対額は利用先、prompt、負荷によって変わります。引用する前に再現テストを行ってください。

実際に遭遇するキャッシュの種類

stack の話に入る前に、用語を整理します。オープンウェイトモデルを提供するホストには、4 種類のキャッシュ方式があり、課金方法も異なります。

1．自動 prefix caching（marker なし）。 最も一般的な方式です。server が prompt prefix を hash 化し、過去のリクエストと一致すれば KV state を再利用して、自動で割引を適用します。cache_control もコード変更も不要で、無効化できないことも少なくありません。DeepSeek、Zhipu GLM、多くのオープンウェイトモデルのホストがこの方式を採用しています。書き込みは無料です。キャッシュの保存期間は VRAM 上の数分から disk 上の長期間までさまざまで、DeepSeek は prefix を「数時間から数日」保持します。

2．明示的な breakpoint caching（cache_control）。 Anthropic が採用する方式で、一部のオープンウェイトモデルのホストも提供しています。Alibaba の Model Studio では、Qwen の message block に "cache_control": {"type": "ephemeral"} を指定します。同等の marker を提供する serving platform もあります。境界を指定して書き込みの追加料金を払い、その代わりに読み取り時の割引率が高くなります。

3．レンタル型の cache object（保存料金あり）。 注意が必要な方式です。Moonshot の旧 moonshot-v1 family では、POST /v1/caching で cache を作成します。その後、書き込み料金、token 数と保存時間に応じた料金、呼び出しごとの hit 料金が発生します。Google の明示的な Gemini caching も同じ考え方で、input cost に加え、1M-tokens、1 時間あたり約 $1.00–$4.50 の保存料金がかかります。キャッシュは借りるリソースであり、自分で garbage collection する必要があります。

4．self-host の KV 再利用（無料）。 weights を自分で動かす場合、推論エンジンが無料かつ自動でキャッシュします。書き込み料金、読み取り料金、保存料金はありません。hit すると prefill が省略されるだけです。

Model Studio の Qwen では、自動 mode と明示的 mode の両方を利用できますが、料金には明確なトレードオフがあります。implicit では書き込みが無料で、hit 時は input の 20% です。explicit では hit 時は input の 10% ですが、書き込み時に 125% が課金され、entry の TTL は 5 分に制限されます。割引率は高くなりますが、キャッシュの作成時と期限切れのたびに料金がかかります。

stack のどこにキャッシュがあるのか

重要なのは、オープンウェイトモデルの prompt caching が解決されているのは 1 つのレイヤーだけで、それより上のすべてのレイヤーで機能しなくなる可能性があるという点です。weights から上に向かって stack をたどり、各レイヤーがキャッシュを提供するのか、単に転送するだけなのか、さらに下位レイヤーで実現したキャッシュを壊す可能性があるのかを確認します。

  request
     |
     v
  +--------------------------------------------------+
  | L5  router             scatters across vendors   |  can break it
  | L4  gateway            multi-cluster routing     |  can break it
  | L3  compute host       uneven delivery           |  can break it
  |==================================================|
  | L2  inference engine   CACHING LIVES HERE, free  |  <-- the cache is born here
  |==================================================|
  | L1  model              cacheability: MLA / GQA   |  sets the ceiling
  +--------------------------------------------------+

  A cache hit is born at L2 and must survive L3-L5 routing to reach you;
  every layer above L2 is a chance to land where your prefix isn't.

レイヤー 1：モデルはキャッシュではなく、キャッシュしやすさを決める

多くの人が「DeepSeek にはキャッシュがある」と考え、キャッシュがこのレイヤーにあると思っています。まず、この点を正確に整理します。checkpoint は weights の集合であり、KV cache の有無にかかわらず同じ attention を実行します。checkpoint 自体には、キャッシュ、割引、TTL、cache_control marker は含まれません。これらは serving layer の機能です。厳密には、weights はキャッシュという製品機能を提供しません。

ただし、weights がキャッシュと無関係なわけではありません。DeepSeek がその好例です。モデルの attention architecture は KV cache のサイズを決め、キャッシュをどこまで安くできるかの上限を決めます。

• DeepSeek の **Multi-head Latent Attention（MLA）**は、KV cache を low-rank latent に圧縮し、標準的な multi-head cache の約 4〜14% まで縮小します。この圧縮があるからこそ、DeepSeek の API は prefix を disk に永続化し、cache read を input の約 2% で提供できます。architecture は実現要因であり、disk cache はその上に構築された製品機能です。
• Llama、Qwen、Mistral、DeepSeek が採用する **Grouped-Query Attention（GQA）**は、KV head を共有し、group factor に応じて cache を縮小します。Llama-3 では約 8 倍です。

レイヤー 1 が提供するのはキャッシュしやすさであって、キャッシュそのものではありません。architecture は上位レイヤーがキャッシュをどこまで安くできるかの上限を決めますが、weights 自体が cached token を返すことはありません。「DeepSeek にはキャッシュがある」という表現は、同じ名前を持つ 2 つの別物を混同しています。1 つはweights、つまり MLA を提供するこのレイヤーです。もう 1 つは DeepSeek の API と serving stack、つまり disk cache、割引、usage field を提供するレイヤー 2〜3 です。open weights を download して自分で実行すれば、MLA による小さな KV cache は利用できます。しかし、disk cache という製品機能は DeepSeek の server に残ります。代わりに、自分が deploy したレイヤー 2 の仕様を引き継ぐことになります。運用上の判断は変わりません。モデルがキャッシュするかではなく、どこで提供されるかを確認してください。ただし、architecture が無関係という意味ではありません。architecture が上限を決め、リクエストの経路が実際の結果を決めます。

レイヤー 2：キャッシュを無料で実装する推論エンジン

1 つ上のレイヤーでは、キャッシュは単に存在するだけでなく、すでに解決済みで無料です。現在の推論エンジンは prefix を自動でキャッシュします。

• vLLM：Automatic Prefix Caching。各 KV block を hash 化し、同じ prefix hash を持つ block を再利用し、LRU で evict します。V1 ではデフォルトで有効です。
• SGLang：RadixAttention。KV cache を radix tree に保存し、共通 prefix を再利用します。cache-aware scheduling にも対応します。
• TensorRT-LLM：block reuse。enable_block_reuse はデフォルトで有効です。必要に応じて、KV block を host memory に offload できます。

LMCache のような project は、さらに一歩進んでいます。KV を CPU や disk に offload し、instance 間で共有します。これは、後述するルーティング問題を解決する土台になります。self-host なら、キャッシュの仕組みはすでに揃っています。自動で動作し、実行中の GPU 以外に費用はかからず、LRU で evict され、しかも自分で所有できます。hit すると prefill が省略され、TTFT が下がり、throughput が上がります。課金自体がないため、cached_tokens の billing field もありません。効果は自分のレイテンシ指標に現れます。クローズドモデルではキャッシュを借りますが、オープンウェイトモデルなら完全に所有できます。一方、hosted 環境とは逆の制約もあります。キャッシュは一時的で、VRAM 上にあり、LRU で削除されます。prefix が hot な間しか残りません。上位レイヤーは、この状態を維持する必要があります。

レイヤー 3：compute host はキャッシュを製品化するが、品質にばらつきがある

商用の inference host はレイヤー 2 を包み、多数の replica を運用します。無料の自動 caching をそのまま利用できますが、適切に実装できているかは別問題です。ばらつきは 2 つの軸で現れます。

1 つ目は、機能の見せ方と価格が大きく異なることです。主要なオープンウェイトモデルのホストを比較すると、あるホストは cached input を一律 50% 割引し、cached token を rate limit の対象外にします。別のホストは serverless でデフォルト 50% 割引です。3 つ目はモデルごとに cached input の価格を設定し、たとえば Qwen の一部 tier を約 80% 割引で提供します。また、affinity を改善する cache-key hint も公開しています。4 つ目は dedicated endpoint で常時 caching を有効にし、無効化できない仕様です。基盤となるエンジンは同じでも、価格設定の考え方は 4 通りあります。

2 つ目は、キャッシュが初めて壊れる場所である multi-replica 問題です。warm prefix は、cold request を処理した replica の VRAM にあります。ホスト側の load balancer が次のリクエストを別の replica に送ると、そこには warm cache がありません。実際にこの現象を確認しました。同じ Qwen モデルを 1 つずつ upstream に固定し、cold→warm で実行した結果です。

Provider A では正常にキャッシュされ、その情報も返されました。Provider B は、このモデルの cache-read 価格を公開していますが、テストした cold call 1 回と warm call 2 回では割引が一度も適用されませんでした。原因が eligibility、replica への fan-out、あるいは 2 回以上の warm-up が必要だったことなのかは特定できません。ただし、この経路で実測した結果は 0 です。機能自体はレイヤー 2 で解決済みですが、実際に利用できるかはレイヤー 3 の実装に左右され、ホストごとに異なります。

レイヤー 4：gateway による multi-cluster 問題

gateway は 1 つ以上の upstream の前段に置かれ、replica 問題を cluster 問題に拡大します。cache affinity を考慮せず、cluster や provider 間で round-robin すると、warm cache には構造上到達できなくなります。リクエストのたびに、prefix が存在しない場所へ送られるためです。cache-aware gateway は、同一 prefix が同じ upstream に届くよう prefix hash でルーティングする必要があります。これは、レイヤー 2 で同じ prefix を同じ KV block に割り当てる仕組みと同じです。LiteLLM のように自分で運用する software でも、hosted service でも、この条件は変わりません。運用上のトレードオフは、LiteLLM と managed gateway の比較で説明しています。

third-party gateway 上で、複数のオープンウェイトモデルに cold→warm のテストを実施し、リクエストごとの cost を直接確認しました。

DeepSeek-V4 の hit 率は 97〜99% で、affinity が end-to-end で機能していました。一方、qwen3.5-plus と qwen3-max は catalog に cache-read 価格が掲載されているにもかかわらず、warm call の割引率は約 0% でした。この表から、gateway に関するもう 2 つの知見が得られます。

• usage field は信用できないことがありますが、コストは明確です。 ここでは 99% のコスト削減が発生した呼び出しを含め、すべての call で cached_tokens が 0 でした。OpenAI-compatible gateway の多くは、upstream が自動で cache する場合、cached-token field を設定しません。token field ではなく、cold call と warm call の cost 差で監査してください。gateway のキャッシュ機能を監査する方法でも、同じ点を扱っています。
• コストが下がらなくても、レイテンシは改善します。 warm call はすべて 2〜10 倍高速でした。qwen3.5-flash は 10.2s→1.0s です。約 0% 割引だったモデルも高速化しました。host がどのように価格を設定していても、hit すれば prefill は省略されます。そのため、請求額が変わらない gateway でも、TTFT の面では caching の効果があります。

affinity を維持しない gateway では、キャッシュがあっても到達できません。キャッシュのコストを公開しない gateway では、効果を検証できません。

レイヤー 5：router による provider 間のランダム分散

最上位では、multi-provider router が 1 つの model ID を、異なる企業が運用する cluster 間で load balance します。各社のキャッシュは独立しています。この場合、provider 内で affinity が完全に機能していても解決しません。1 回目の call がある vendor、2 回目が別の vendor に送られれば、共有キャッシュは存在しないためです。冒頭の分散はこの現象です。レイヤー 4 の問題がさらに悪化し、複数 cluster だけでなく、キャッシュ状態も価格も異なる複数 vendor に分散されます。最も高い provider は、最安 upstream の基本料金の 20 倍でした。ルーティング先が偶然 1 つの provider に固定された時点で、ようやくキャッシュが有効になりました。

対策はランダム性をなくすことです。ルーティングを決定的にし、同じ prefix が同じ warm cache に届くようにします。

# Pin the upstream; otherwise load-balancing scatters you across disjoint caches.
# (field names follow a common multi-provider router's API)
import requests

requests.post(f"{ROUTER_BASE}/chat/completions",
  headers={"Authorization": f"Bearer {API_KEY}"},
  json={
    "model": "qwen/qwen3.5-35b-a3b",
    "messages": messages,
    "usage": {"include": True},              # return cost + cached_tokens
    "provider": {                            # the part that makes caching work
        "order": ["<your-chosen-upstream>"],
        "allow_fallbacks": False,
    },
  })

この router は cached_tokens とリクエストごとの cost を返しました。hit 時には 4,224 が報告され、両方を検証できます。この点は 0 を返したレイヤー 4 の gateway より優れています。ただし、ルーティングを制約するのは利用者側の責任です。キャッシュは価格機能に見えるルーティング問題です。 レイヤー 2 のキャッシュは無料ですが、レイヤー 3、4、5 では段階的にキャッシュから遠ざかるルーティングが発生します。

割引率はどれほど高いのか：モデルや提供先によって大きく異なる

ルーティングが正しく揃った場合、どれだけ安くなるのでしょうか。クローズドモデルの cache-read 割引率は 90% 前後に集中しています。オープンウェイトモデルでは、公開されている cache-read 価格がわずかな割引からほぼ全額割引まで広がっています。同じ vendor の lineup 内でも差があります。以下は first-party が公開している価格です。

DeepSeek の自動 disk cache は、この分野で最も割引率が高い方式です。deepseek-v4-flash の cached input は、cache miss 時の $0.14/M に対して $0.0028/M で、比率は 1:50 です。レイヤー 4 のテストでも 97.9% の割引を再現できました。同じ open weights を提供する third-party host は、cached input の価格を独自に設定します。 一律で約 50% 割引するホストもあれば、モデルごとに約 50〜90% の範囲で設定するホストもあります。割引率はモデルだけでなく、どのホストにルーティングされたかで決まります。同じ機能名でも、48 point の差があります。

割引率は提供先の特性なので、同じモデルでも利用場所によってキャッシュの費用対効果が異なります。deepseek-v4-pro を 4 つの経路で比較します。

「DeepSeek-V4-Pro は caching に対応している」という説明は正しいものの、運用判断にはほとんど役立ちません。確認すべきなのは、「どこで対応し、どの料金が適用され、どのように報告されるか」です。

判断用チェックリスト

• ✅ モデルが決めるのはキャッシュではなく、コストの下限です（レイヤー 1）。MLA や GQA などの attention architecture はキャッシュをどこまで安くできるかを決めますが、cached token 自体は返しません。どこで提供され、そのホストの stack が何をするかを確認してください。
• ✅ self-host なら、すでに無料で利用できます（レイヤー 2）。automatic prefix caching が有効であることを確認し、prefix hit rate を監視してください。vLLM と SGLang ではデフォルトで有効です。
• ✅ compute host では、価格表ではなく実際の提供状況を検証してください（レイヤー 3）。cache-read 価格は provider 側の主張です。cold→warm のコスト差を測定してください。ホストが cache-key affinity hint を提供している場合は使用します。
• ✅ gateway には cache-affinity routing とコスト情報を求めてください（レイヤー 4）。同一 prefix が同じ upstream に固定されない場合や、warm call で cost が下がらない場合は、キャッシュに到達できないか、効果を検証できません。
• ✅ router では upstream を固定してください（レイヤー 5）。provider order を指定し、fallback を無効にするなどしてルーティングを制約します。そうしないと、独立したキャッシュ間の load balancing で hit を失い、20〜50 倍高い upstream に送られる可能性があります。
• ✅ レイテンシとコストは別々に評価してください。 割引率が約 0% でも、warm prefill は 2〜10 倍高速です。
• ✅ 保存料金がかかるキャッシュ方式に注意してください。 レンタル型キャッシュの Moonshot moonshot-v1 や Gemini explicit は、idle 状態でも token 数と時間に応じて課金されます。automatic prefix cache には保存料金がありません。

結論

クローズドモデルなら、「キャッシュするか」という問いの答えは 1 つです。オープンウェイトモデルでは、推論エンジンのレイヤーですでに解決されています。vLLM と SGLang は、すべての prefix を無料かつ自動でキャッシュします。その上にある仕組みは、hit を維持するか、別の場所へ分散させるかのどちらかです。compute host の replica balancer、gateway の cluster routing、router による vendor 間のランダム分散が影響します。モデルの architecture は caching をどこまで安くできるかの上限を決めます。MLA と GQA はモデルレベルで明確な効果があります。しかし、実際に何が得られるかはリクエストの経路で決まります。キャッシュの挙動はルーティングの性質として扱ってください。実際に使う経路でコストを測定し、warm-up したキャッシュに次のリクエストが届くよう経路を固定します。どれほど割引率が高くても、2 回目のリクエストが 1 回目とは別の場所に送られれば意味がありません。

KV cache が存在する理由や TTL の仕組みは、KV Cache と TTL の仕組みを参照してください。gateway のキャッシュ機能を監査する場合は、LLM Gateway はキャッシュについて誤った情報を返すのかを参照してください。

よくある質問

オープンウェイトモデルは prompt caching に対応していますか？ weights は caching をどこまで安くできるかを決めます。MLA や GQA などの attention architecture が KV cache を縮小するためです。ただし、キャッシュそのもの、割引、API は serving stack が提供します。キャッシュは推論エンジンの vLLM、SGLang、TensorRT-LLM で実装され、compute host に引き継がれ、gateway と router によって転送または分散されます。同じ checkpoint を 3 つのホストで提供すると、無料の自動 caching、キャッシュなし、explicit のみという異なる結果になる可能性があります。

同じモデルなのに、呼び出しによってコストが 49 倍になったのはなぜですか？ multi-provider router で upstream を固定しない場合、基本料金とキャッシュ状態が異なる複数 vendor の cluster 間で load balance されます。ある call は高価な provider に cold 状態で届き、別の call は安い provider に warm 状態で届きました。upstream を固定し、provider order を制約して fallback を無効にすれば、両方を制御できます。

self-host する場合、キャッシュ料金を支払う必要がありますか？ ありません。vLLM、SGLang、TensorRT-LLM の automatic prefix caching はデフォルトで有効かつ無料です。hit すると prefill が省略されます。支払うのは実行中の GPU の費用だけです。キャッシュは自分で所有し、VRAM が必要になると LRU で evict されます。

API では cached_tokens: 0 ですが、請求額は下がりました。キャッシュは機能していますか？ 機能している可能性が高いです。多くの gateway は、upstream が自動で caching する場合に cached_tokens を設定しません。cost field を確認してください。cold call と同一内容の warm call の間でコストが大きく下がっていれば、cache hit しています。

キャッシュ割引率が最も高いオープンウェイトモデルはどれですか？ DeepSeek の自動 disk cache です。deepseek-v4-flash の cached input は、uncached 時の $0.14/M に対して約 $0.0028/M で、約 98% 割引です。cold→warm のテストでは、V4 lineup 全体で 97.9〜99.2% を再現しました。多くの third-party host では、一律で約 50% の割引が適用されます。

保存料金がかかるキャッシュには注意点がありますか？ あります。Moonshot の moonshot-v1 explicit cache と Gemini の explicit cache は、キャッシュを維持する間、token 数と時間に応じて課金されます。Gemini は 1M-tokens、1 時間あたり約 $1–4.50 です。削除し忘れた idle cache にも課金が続きます。automatic prefix cache には保存料金がありません。

検証条件：multi-provider router と自社 gateway を対象に、2026-06-14 にコストとレイテンシを実測しました。約 4.7K-token の固定 prompt、小さな max_tokens、逐次的な cold→warm 実行を使用し、返されたリクエスト単位の cost から割引率を計算しています。公開価格とキャッシュの仕組みは同日に provider の一次資料で確認し、反証を試みる形でもクロスチェックしました。一部 vendor の数値、特に Moonshot の explicit-cache 料金は頻繁に変わります。引用前に最新の値を確認してください。数値は provider、prompt、region、負荷によって変わります。

参考資料

• DeepSeek：料金
• DeepSeek：KV cache／Context Caching ガイド
• DeepSeek-V3 技術レポート：MLA（KV-cache 圧縮）
• GQA：Generalized Multi-Query Transformer Model の学習（Ainslie ほか）
• Alibaba Cloud Model Studio：context cache と料金
• Moonshot AI：Context Caching
• Zhipu／Z.AI：料金と caching
• vLLM：Automatic Prefix Caching
• SGLang：RadixAttention／cache
• LMCache：KV cache の offload と共有
• Google：Gemini context caching

すべて 2026-06-14 に確認済みです。金融上の助言ではありません。価格を判断材料にする前に、最新情報を確認してください。

← ブログに戻る