オープンウェイトLLMのキャッシュ：なぜあなたのキャッシュはプロバイダーのルーレットなのか

クローズドモデルの場合、プロンプトキャッシュは一つの文書化された契約だ。Claudeにはcache_controlのブレークポイントがあり、OpenAIとGeminiはトークン数の下限を超えると自動的にキャッシュする。割引率は公開されており安定している。一ページ読めばそれで終わりだ。

オープンウェイトはその前提を崩す。同じQwenやLlamaのチェックポイントが十数のホストで提供されており、キャッシュはモデルの特性ではなく、モデルが動作する場所の特性だ。 それがどこまで影響するかを示すために、マルチプロバイダールーターを通じて同じQwenモデルに対し、アップストリームを固定せずに同一の約4,700トークンのプロンプトを6回送信した実測結果を示す：

同じモデル、同じルーター、同じプロンプトで、料金は**$0.0141から$0.000286まで——49倍の開き**——純粋にルーターが選んだアップストリームと、そのアップストリームがプレフィックスをウォームな状態で持っていたかどうかによって決まった。

まとめ

• オープンウェイトモデルのプロンプトキャッシュはルーティングの結果であり、モデルの機能ではない。 推論エンジンで無料かつ自動的に実装され、その上位の各層によって保持されるか破壊されるかが決まる。
• 5層構造：1層がキャッシュを提供し、3層がそれを壊しうる。 モデル（キャッシュ可能性を設定するが、キャッシュ自体は持たない）→ 推論エンジン（キャッシュ、無料）→ コンピュートホスト（製品化するが、不均一）→ ゲートウェイ（マルチクラスタールーティング）→ ルーター（キャッシュが分断されたベンダー間に分散）。
• 実測済み。 ルーターによって分散された同一リクエストが、あるピックでは別のピックより49倍高くなった。あるモデルでは、あるホストが59.6%オフを実現し、別のホストは**0%だった。公開されているキャッシュ割引はモデルによって0%から約98%**に及ぶ。
• 対策。 繰り返されるプレフィックスが同じウォームキャッシュに当たるようにルートを固定する。cached_tokensフィールドではなくコストの差分で監査する（実際にヒットしていても0と表示されることが多い）。レイテンシは別途考慮する——ウォームなプリフィルはコスト割引がほぼ0%であっても2〜10倍速く動作する。

実測値は2026-06-14に、マルチプロバイダールーターおよび自社ゲートウェイに対し、固定の約4,700トークンの英語プロンプト、小さなmax_tokens、逐次実行で計測した。文書化された料金は同日にプライマリプロバイダーのドキュメントと照合し、対立的に交差検証した。比率（割引率、レイテンシ変化）が移植可能な部分であり、絶対的なドル金額は利用環境、プロンプト、負荷によって異なる。引用前に再現すること。

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

スタックの説明に入る前に、用語を整理しておこう。オープンウェイトのホストには4つの異なるキャッシュ形態があり、それぞれ課金方式が異なる。

1. 自動プレフィックスキャッシング（マーカーなし）。 最も一般的なパターン。サーバーがプロンプトのプレフィックスをハッシュし、以前のリクエストと一致すればKV状態を再利用して、自動的に割引を適用する。cache_control も不要、コード変更も不要で、無効化できないことも多い。DeepSeek、Zhipu GLM、そしてほとんどのオープンウェイトホストがこの方式を採用している。書き込みは無料で、キャッシュの保持期間はVRAM（数分）からディスク（DeepSeekはプレフィックスを「数時間から数日」保持）まで様々だ。

2. 明示的ブレークポイントキャッシング（cache_control）。 Anthropicの方式で、一部のオープンウェイトホストも採用している。AlibabaのModel StudioはQwenのメッセージブロックに "cache_control": {"type": "ephemeral"} を受け付け、一部のサービングプラットフォームも同等のマーカーを提供している。境界を自分でマークし、書き込みサーチャージを支払う代わりに、より大きな読み取り割引が得られる。

3. レンタル型キャッシュオブジェクト（ストレージ料金あり）。 要注目の方式。Moonshotのレガシー moonshot-v1 ファミリーでは POST /v1/caching でキャッシュを作成し、書き込み料金、トークンあたり・分あたりのストレージ料金、そしてコールごとのヒット料金が課金される。Googleの明示的なGeminiキャッシングも同じ考え方で、入力コストプラスストレージとして1Mトークンあたり時間あたり約$1.00〜$4.50かかる。キャッシュはレンタルするリソースであり、自分でガベージコレクションしなければならない。

4. セルフホストKV再利用（無料）。 自分でウェイトを実行すれば、推論エンジンが自動的かつ無料でキャッシュする。書き込み料金なし、読み取りレートなし、ストレージレンタルなし——ヒットすれば単純にプリフィルをスキップするだけだ。

Model Studio上のQwenは自動と明示の両方のモードを提供しており、実際のトレードオフがある。暗黙モードはヒット時に**入力の20%が課金され書き込みは無料、明示モードはヒット時に入力の10%が課金されるが書き込みに125%**のサーチャージがかかり、エントリの有効期限は5分のTTLに制限される。割引は深くなるが、キャッシュの投入時にも、期限切れのたびにも費用が発生する。

スタックのどこにキャッシングが存在するか

ここが核心だ。オープンウェイトのプロンプトキャッシングは、ちょうど1つのレイヤーで解決され、その上のすべてのレイヤーで危険にさらされる。 ウェイトからスタックを上に向かってたどり、各レイヤーで問う——このレイヤーはキャッシングを提供しているのか、それとも単に転送しているだけか、そして下のレイヤーがすでに行ったことを破壊できるのか？

  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にはキャッシングがある」という言い方に代表されるように、多くの人がキャッシングはここに存在すると思っているレイヤーだ。だからこそ、まずここを正確に理解する必要がある。チェックポイントとはウェイトの集合体であり、KVキャッシュが存在するかどうかに関わらず、同じアテンション計算を実行する。キャッシュも、割引も、TTLも、cache_controlマーカーも持ち合わせていない――それらはサービング層の機能だ。厳密な意味では、ウェイト自体はキャッシングというプロダクトを提供しない。

しかし、ウェイトは中立ではない。DeepSeekはその好例だ。モデルのアテンションアーキテクチャがKVキャッシュのサイズを決定し、ひいてはキャッシングをどこまで安くできるかの上限を決める：

• DeepSeekの**Multi-head Latent Attention（MLA）**は、KVキャッシュを低ランクの潜在表現に圧縮する――標準的なマルチヘッドキャッシュの約4〜14%にまで。この圧縮こそが、DeepSeekのAPIがプレフィックスをディスクに永続化し、キャッシュ読み取りを入力コストの約2%という価格で提供できる理由だ。アーキテクチャは実現要因であり、ディスクキャッシュはその上に構築されたプロダクトだ。
• Grouped-Query Attention（GQA）――Llama、Qwen、Mistral、DeepSeekが採用――はKVヘッドを共有することで、グループ係数分（Llama-3では≈8倍）キャッシュを縮小する。

つまりレイヤー1の貢献はキャッシュ可能性であって、キャッシュではない：アーキテクチャは上位の各レイヤーがキャッシングをどこまで安くできるかの上限を設定するが、ウェイト自体がキャッシュ済みトークンを提供することはない。そして「DeepSeekにはキャッシングがある」という言葉は、同じ名前を持つ二つの異なるものを静かに混同している――ウェイト（このレイヤー、MLAを提供する）と、DeepSeekのAPIおよびサービングスタック（レイヤー2〜3、ディスクキャッシュ・割引・使用量フィールドを提供する）だ。オープンウェイトをダウンロードして自分で実行すれば、MLAの小さなKVキャッシュは手元に残るが、ディスクキャッシュというプロダクトはDeepSeekのサーバーに留まる――代わりにデプロイするレイヤー2を引き継ぐことになる。だから運用上の考え方は変わらない：モデルがキャッシュするかどうかを問うのをやめ、どこでサービングされているかを問い始めること――ただし、それをアーキテクチャが重要でないことと混同してはならない。アーキテクチャが上限を設定し、パスが実際に得られるものを決める。

レイヤー2 — 推論エンジン：キャッシングが構築される場所、そして無償

一つ上のレイヤーでは、キャッシングは単に存在するだけでなく――解決済みであり、無償だ。 現代の推論エンジンはプレフィックスを自動的にキャッシュする：

• vLLM — Automatic Prefix Caching：各KVブロックをハッシュ化し、既出のプレフィックスハッシュを持つブロックを再利用し、LRUで退避する。V1ではデフォルトで有効。
• SGLang — RadixAttention：KVキャッシュをRadixツリーに格納することで、共有プレフィックスを再利用し、キャッシュを考慮したスケジューリングを行う。
• TensorRT-LLM — ブロック再利用（enable_block_reuse、デフォルト有効）、KVブロックのホストメモリへのオフロードもオプションで対応。

LMCacheのようなプロジェクトはさらに一歩進め――KVをCPU/ディスクにオフロードし、インスタンス間で共有する。これは、これから直面するルーティング問題を解決するための萌芽だ。要点：自己ホストするなら、それで完結する。キャッシングは自動で、既に稼働しているGPUのコスト以外は何もかからず、LRUで退避し、自分のものだ――ヒットすればプリフィルをスキップするだけで、TTFTが下がりスループットが上がる。何も課金されないためcached_tokensの課金フィールドは存在せず、その恩恵は自分自身のレイテンシメトリクスに現れる。クローズドモデルではキャッシングを借りるが、オープンモデルでは完全に所有できる。落とし穴はホスト型の世界とは逆だ：キャッシュは揮発性（VRAM、LRU）であるため、プレフィックスがホットな状態を保つ間しか生き残れない――それこそが上位レイヤーが維持しなければならないものだ。

レイヤー3 — コンピュートホスト：製品化の濃淡

商用推論ホストはレイヤー2をラップし、レプリカのフリートを運用します。自動キャッシュの恩恵は無償で受け継がれますが、問題はそれをうまく実装しているかどうかであり、その答えは2つの軸で見ると一様ではありません。

第一に、公開方法と価格は大きくばらつきます。主要なオープンウェイトホストを比較すると、あるホストはキャッシュ済み入力に一律50%割引を適用しキャッシュ済みトークンをレートリミットから除外します。別のホストはサーバーレスでデフォルト50%オフを採用します。3つ目はモデルごとにキャッシュ済み入力を価格設定し（例：Qwenティアで約80%オフ）、アフィニティ向上のためのキャッシュキーヒントを公開しています。4つ目は専用エンドポイントでキャッシュを常時オンにしつつ、その状態を開示不可にしています。同じ基盤エンジンを使いながら、4つの価格設計思想が存在します。

第二に — そしてこれがキャッシュが機能しなくなる最初のポイントです — マルチレプリカ問題があります。ウォームなプレフィックスは、コールドリクエストを処理した1つのレプリカのVRAMに存在します。ホスト自身のロードバランサーが次のリクエストをキャッシュがコールドな別のレプリカに送ってしまう可能性があります。実際にこの現象を確認しました。同じQwenモデルを一度に1つのアップストリームに固定し、コールド→ウォームの順で実行した結果です：

プロバイダーAはクリーンにキャッシュし、その結果を報告しました。プロバイダーBは — このモデルに対してキャッシュ読み取り価格を宣伝しているにもかかわらず — 今回のテストではコールド呼び出しと2回のウォーム呼び出しを通じて割引がゼロでした。これが適格性の問題なのか、レプリカへのファンアウトの問題なのか、あるいは2リクエストでは不十分なウォームアップ期間の問題なのかは不明ですが、このパスで計測された結果はゼロでした。機能自体はレイヤー2で解決済みです。しかし実際にその恩恵を受けられるかどうかはレイヤー3の実装の詳細であり、ホストによって異なります。

レイヤー4 — ゲートウェイ：マルチクラスター問題

ゲートウェイは1つ以上のアップストリームの前段に位置し、レプリカ問題をクラスター問題へと増幅させる。キャッシュアフィニティなしにリクエストをクラスターやプロバイダー間でラウンドロビンすると、ウォームキャッシュは構造的に到達不能になる——すべてのリクエストが、そのプレフィックスが存在しない場所へ着弾するからだ。キャッシュを意識したゲートウェイは、プレフィックスのハッシュに基づいてルーティングし、同一プレフィックスが同じアップストリームに固定されるようにしなければならない。これはレイヤー2が同じKVブロックに固定するのと同じ原理だ。

サードパーティのゲートウェイ上でオープンウェイトモデルを対象にコールド→ウォームのバッテリーテストを実施し、リクエストごとの cost を直接読み取った：

DeepSeek-V4は97〜99%を達成した（アフィニティがエンドツーエンドで機能している）。一方、qwen3.5-plus と qwen3-max は、カタログにキャッシュ読み取り価格が存在するにもかかわらず、ウォームコールで約0%しか返さなかった。このテーブルにはさらに2つのゲートウェイの教訓が潜んでいる：

• usageフィールドは嘘をつく。コストはつかない。 cached_tokens はここでのすべてのコール——99%のコスト削減を含む——で 0 を返した。OpenAI互換ゲートウェイの多くは、自動的にキャッシュするアップストリームに対してキャッシュ済みトークンフィールドを正しく設定しない。監査はトークンフィールドではなく、コールドとウォームの cost デルタで行うべきだ——ゲートウェイのキャッシュ主張を監査する際の教訓と同じだ。
• コストが改善しなくてもレイテンシは改善する。 すべてのウォームコールは2〜10倍高速だった——qwen3.5-flash は10.2s→1.0sになった——割引率が約0%のものも含めて。ヒットはホストの課金方式に関わらずプリフィルをスキップするため、請求書に何も反映されないゲートウェイでもTTFTの観点でキャッシングは効果を発揮しうる。

アフィニティを保持しないゲートウェイは、到達できないキャッシュを渡してくる。キャッシュコストを表示しないゲートウェイは、検証できないキャッシュを渡してくる。

レイヤー5 — ルーター：プロバイダー間のランダム分散

最上位には、マルチプロバイダールーターが存在する。これは1つのモデルIDを異なる企業のクラスター間でロードバランシングするが、各クラスターは独立したキャッシュを持つ。この状況では、プロバイダー内での完璧なアフィニティ制御も意味をなさない。コール1がベンダーAに、コール2がベンダーBに振られれば、共有キャッシュはどこにも存在しないからだ。これがこの記事の冒頭で示した「散乱」であり、レイヤー4の問題をさらに悪化させる。複数のクラスターだけでなく、キャッシュ状態も価格体系も完全に分離した複数のベンダーが絡むのだ（最も高価な選択肢は最安値のアップストリームの基本料金の20倍で請求された）。キャッシュが機能したのは、ルーティングがたまたま同一プロバイダーに固定されたときだけだった。

解決策は、ランダム性を排除することだ。ルーティングを決定論的にして、繰り返されるプレフィックスが同じウォームキャッシュに到達するようにする：

# アップストリームを固定する。そうしないとロードバランシングが
# 独立したキャッシュ間にリクエストを散乱させてしまう。
# (フィールド名は一般的なマルチプロバイダールーターの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},              # コスト + cached_tokensを返す
    "provider": {                            # キャッシュを機能させる部分
        "order": ["<your-chosen-upstream>"],
        "allow_fallbacks": False,
    },
  })

このルーターの優れた点として、cached_tokens（ヒット時に4,224）とリクエストごとのcostを報告してくれるため、両方を検証できる。これは0を返していたレイヤー4のゲートウェイよりも優秀だ。ただし、ルーティングの制約はユーザー自身が設定する必要がある。キャッシュは、価格機能に見せかけたルーティングの問題だ。 キャッシュ自体はレイヤー2では無料であり、レイヤー3、4、5はそれぞれ段階的にキャッシュから遠ざかるルーティングの落とし穴だ。

割引はどれくらい深いのか？結果はまちまち

ルーティングが正しく機能した場合、どれだけ節約できるのか？クローズドモデルでは、キャッシュ読み取りの割引は約90%に集中している。オープンウェイトモデルでは、公表されているキャッシュ読み取り価格は、ほんのわずかなものから、ほぼ全額に近いものまで幅広く、同一ベンダーのラインナップ内でも差がある。ファーストパーティの公表レート：

DeepSeekの自動ディスクキャッシュは業界最深の割引を誇る。deepseek-v4-flashはキャッシュ済み入力を**$0.0028/M（ミス時$0.14/Mに対して1:50の比率）**で読み取り、レイヤー4のテストでは97.9%の割引を再現した。同じオープンウェイトをホストするサードパーティは、キャッシュ済み入力を独自に価格設定している。 一律約50%を適用するところもあれば、モデルごとに約50%〜約90%と変動するところもある。つまり、得られる割引はモデルだけでなく、どのホストに当たるかによって決まる。同じ機能名で、48ポイントもの開きがある。

割引はベニュー（提供場所）の特性であるため、1つのモデルでも提供される場所によってキャッシュの経済性は異なる。deepseek-v4-proを4つの経路で比較すると：

「DeepSeek-V4-ProはキャッシュをサポートしているJapanese」は正しいが、ほぼ無意味だ。運用上の本質的な問いは「どこで、どのレートで、どのように報告されるキャッシュをサポートしているのか」だ。

意思決定チェックリスト

• ✅ 上限を決めるのはモデルであり、キャッシュではない（レイヤー1）。アテンションアーキテクチャ（MLA、GQA）がキャッシュのコスト効率の上限を決定するが、キャッシュされたトークンを直接提供するわけではない。そのため、どこで提供されるか、そのホストのスタックが何であるかを必ず確認すること。
• ✅ セルフホスティングなら、すでに無料で利用できる（レイヤー2）。自動プレフィックスキャッシュが有効になっていることを確認し（vLLM/SGLangではデフォルトで有効）、プレフィックスヒット率を監視すること。
• ✅ コンピュートホストでは、価格欄ではなく実際の提供を検証する（レイヤー3）。キャッシュ読み取り価格は主張に過ぎない。コールド→ウォームのコスト差を実測すること。ホストがキャッシュキーアフィニティヒントを提供している場合は活用すること。
• ✅ ゲートウェイ経由では、キャッシュアフィニティルーティングとコストレポートを要求する（レイヤー4）。同一プレフィックスが同じアップストリームに固定されない場合、またはウォームコール時にcostが下がらない場合、キャッシュは到達不能か検証不可能な状態にある。
• ✅ ルーターではアップストリームを固定する（レイヤー5）。ルーティングを制約すること（例：フォールバックを無効にしたプロバイダー順序フィールド）。そうしなければ、分離されたキャッシュ間のロードバランシングによってヒットを失い、20〜50倍高価なアップストリームにリクエストが送られるリスクがある。
• ✅ レイテンシーはコストとは別に評価する。 ウォームプリフィルは、ドル換算の割引がほぼ0であっても、2〜10倍高速である。
• ✅ ストレージ料金が発生するキャッシュタイプに注意する。 レンタル型キャッシュ（Moonshot moonshot-v1、Gemini明示的キャッシュ）はアイドル状態のキャッシュに対してトークン時間単位で課金される。自動プレフィックスキャッシュはそうではない。

まとめ

クローズドモデルにとって「キャッシュするか？」という問いには一つの答えがある。オープンウェイトモデルにとっては、この機能は数年前に推論エンジン層で解決済みだ。vLLMとSGLangはすべてのプレフィックスを無料かつ自動的にキャッシュする。それより上の層はすべて、ヒットを保持するか、それとも遠ざけるかを決める配管に過ぎない。コンピュートホストのレプリカバランサー、ゲートウェイのクラスタールーティング、ルーターのベンダー間ランダム分散がそれにあたる。モデルのアーキテクチャがキャッシュのコスト効率の上限を決める。MLAとGQAは真のモデルレベルの改善だ。しかし、リクエストが通るパスが実際に得られるものを決定する。キャッシュの挙動をルーティングのプロパティとして扱うこと。実際に使用するパスでコストの観点から計測し、ウォームアップしたキャッシュに確実にヒットするようルートを固定し、そして世界最大の割引も、リクエスト2がリクエスト1の届いたことのない場所に到達してしまえば何の意味もないことを忘れないでほしい。

KVキャッシュが存在する理由とTTLの仕組みについては、How KV Cache & TTL Workを参照。ゲートウェイのキャッシュに関する主張を監査するには、Does Your LLM Gateway Lie About Cache?を参照。

FAQ

オープンウェイトモデルはプロンプトキャッシングに対応していますか？ ウェイトはキャッシングのコスト効率の上限を決めます — MLAやGQAのようなアテンションアーキテクチャはKVキャッシュを縮小します — しかしキャッシュ本体、割引、そしてAPIはサービングスタックから提供されます。キャッシングは推論エンジン（vLLM、SGLang、TensorRT-LLM）に実装され、コンピュートホストに引き継がれ、ゲートウェイやルーターによって転送（または分散）されます。同じチェックポイントを3つのホストにデプロイすると、無料の自動キャッシング、キャッシングなし、または明示的キャッシングのみ、という異なる結果が得られる場合があります。

同じモデルで、あるコールが別のコールより49倍高くなったのはなぜですか？ マルチプロバイダールーターでは、ピン留めされていないリクエストが、異なるベース価格と互いに独立したキャッシュ状態を持つ複数ベンダーのクラスターにロードバランシングされます。あるコールは高価なプロバイダーにコールド状態でヒットし、別のコールは安価なプロバイダーにウォーム状態でヒットしました。アップストリームをピン留めする（プロバイダーの順序を制限し、フォールバックをオフにする）ことで、両方を制御できます。

セルフホストの場合、キャッシングに費用はかかりますか？ かかりません。vLLM、SGLang、TensorRT-LLMの自動プレフィックスキャッシングはデフォルトで有効かつ無料です — ヒットするとプリフィルをスキップするだけです。すでに稼働しているGPUのコストのみを支払い、キャッシュはユーザー自身のものとなり、VRAMが必要になるとLRUで退避されます。

APIがcached_tokens: 0を返しているのに請求額が下がりました — キャッシングは機能していますか？ おそらく機能しています。多くのゲートウェイは、自動的にキャッシングするアップストリームに対してcached_tokensを設定しません。costフィールドを信頼してください。コールドコールとそれと同一のウォームコールの間でコストが大幅に下がっていれば、キャッシュヒットが発生しています。

最も深いキャッシュ割引を持つオープンウェイトモデルはどれですか？ DeepSeekの自動ディスクキャッシュです。deepseek-v4-flashはキャッシュされた入力を約$0.0028/Mで読み取り、未キャッシュの$0.14/Mに対して約98%オフとなります。これは私たちのコールド→ウォームテストにおいて、V4ラインで97.9〜99.2%の割引として再現されました。多くのサードパーティホストは代わりに一律約50%の割引を適用します。

ストレージ料金が発生するキャッシュには注意点がありますか？ あります — Moonshotのmoonshot-v1明示的キャッシュとGeminiの明示的キャッシュは、キャッシュを維持するためにトークン時間単位で課金されます（Geminiは約$1〜4.50 / 1Mトークン / 時間）。削除し忘れたアイドル状態のキャッシュは課金され続けます。自動プレフィックスキャッシュにはストレージ料金はありません。

検証：ライブのコスト/レイテンシの数値は、マルチプロバイダールーターおよび自社ゲートウェイに対して2026-06-14に測定。固定の約4,700トークンのプロンプト、小さなmax_tokens、順次コールド→ウォームの実行を使用し、返された各リクエストのcostから割引を算出。ドキュメント化された価格設定とキャッシュの仕組みは同日にプライマリプロバイダーのドキュメントと照合し、対立的に相互検証済み。一部のベンダーの数値（特にMoonshotの明示的キャッシュ料金）は頻繁に変動します — 引用前に現在の値を確認してください。実際の数値はプロバイダー、プロンプト、リージョン、および負荷によって異なります。

ソース

• DeepSeek — Pricing
• DeepSeek — KV cache / Context Caching guide
• DeepSeek-V3 Technical Report — MLA (KV-cache compression)
• GQA: Training Generalized Multi-Query Transformer Models (Ainslie et al.)
• Alibaba Cloud Model Studio — context cache & pricing
• Moonshot AI — Context Caching
• Zhipu / Z.AI — pricing & caching
• vLLM — Automatic Prefix Caching
• SGLang — RadixAttention / cache
• LMCache — KV cache offloading & sharing
• Google — Gemini context caching

すべて2026-06-14に確認済み。金融アドバイスではありません。利用前に現在の価格を確認してください。

← ブログに戻る