ofox で DeepSeek V3.2 の Prompt Caching を 10 分で導入、請求を 80% 削減する手順（2026 年版）

キャッシュヒットの DeepSeek リクエストとミスのリクエストの間には 4.8× の価格差が横たわっており、典型的なエージェントループでは、ヒットとミスを分けるのはタイムスタンプをプロンプトの末尾に置いたかどうかです。

30 秒の答え

表だけ読めば十分という方のために、まとめておきます。

合計でおよそ 10 分です。構造を整えた呼び出しは、ミス時の $0.29/M ではなくキャッシュ読み取りの $0.06/M に乗り、キャッシュされた入力トークンに対して 79.3% の割引になります。

3 つのルールで節約の 90% はカバーできます。

1. プレフィックスは安定、末尾は動的。 リクエストごとに変わるものは必ずプロンプトの末尾に置き、system メッセージや few-shot ブロックには入れません。
2. 同じバイト、同じヒット。 キャッシュ照合はトークン単位の完全一致です。新しい空白、別の ISO タイムスタンプ、ユーザーごとの salt、どれか一つでもプレフィックスを壊します。
3. 計測しなければ存在しない。 すべてのレスポンスから prompt_cache_hit_tokens を取り出してください。比率が落ちたら、動的な何かがプレフィックスに紛れ込んでいます。

この構成でできること、できないこと

✅ できること：

• ofox API キー 1 本で deepseek/deepseek-v3.2 を動かし、コード形は OpenAI SDK の任意の呼び出しと同じ。
• 繰り返しプレフィックスで $0.06/M のキャッシュ読み取りを得る（128K コンテキスト、最大出力 32K）。
• DeepSeek が直接返すのと同じ usage フィールド（prompt_cache_hit_tokens、prompt_cache_miss_tokens）で、リクエスト単位のキャッシュヒットを追跡。
• 1 本の API キーをチームで共有し、dashboard の利用ログから、どの呼び出し経路がよくキャッシュに乗っているかを観察。

❌ できないこと：

• キャッシュヒットを強制すること。DeepSeek のキャッシュはベストエフォートで、Anthropic の cache_control フラグや Gemini context cache の cache_id のように固定する手段はありません。
• system prompt にユーザーごとの呼び出し単位 salt が入っている場合、ユーザー間でキャッシュを共有すること。ユーザー ID は末尾、もしくはプロンプト本文外の metadata フィールドに移してください。
• キャッシュを無期限に保持すること。寿命は「数時間から数日」、コールドパスでは消えます。
• モデル版間でキャッシュを共有すること。deepseek/deepseek-v3.2 から deepseek/deepseek-r1 に切り替えると新規キャッシュが構築されます。
• 2026 年 7 月 24 日以降、DeepSeek 直結側の V4 エイリアスとキャッシュ節約を混在させること。ofox 経由なら V3.2 の model ID は固定されているので、それを土台にしたワークロードは上流のエイリアス移行後も動き続けます。ただし、V4 が ofox のカタログに入った時点で再評価が必要になります。

これらの保証が必要なら、答えは「この構成を調整する」ではなく、別モデルや別ベンダーへの乗り換えになります。

判断フレーム：この構成を使うべき場面・使わない場面

ofox 上で DeepSeek V3.2 + プロンプトキャッシュを使うべき場面：

1. セッション単位で検索コンテキストが安定する RAG パイプライン。 検索したチャンク + system prompt が長い安定プレフィックスを形成し、ユーザークエリが末尾。キャッシュヒット率 70% 以上が普通です。
2. 同じ system prompt + ツールスキーマを持つマルチターンエージェントループ。 各ループの先頭が同じ内容になり、2 ターン目からキャッシュが回収されます。
3. 多数のプロンプトが長いプリアンブルを共有するバッチジョブ（例：同一のラベル付け指示で 1 万件のサポートチケットを分類）。同じプレフィックスで順次回せばキャッシュは温かいまま保たれます。

使うべきでない場面：

1. 一回限りで完全に動的なプロンプト。 リクエストごとに system が違えば毎回 $0.29/M を支払います。キャッシュは助けになりません。小さなモデルを選ぶべきです。
2. キャッシュヒットを前提とする厳しいレイテンシ SLO。 キャッシュはベストエフォートです。ミス時を前提に設計してください。
3. ユーザーデータの cross-request キャッシュを禁じるコンプライアンス要件。 データ処理層で無効化し、呼び出しごとに ephemeral メモリが明示されるモデルに振り向けてください。
4. 画像入力が必要なワークロード。 V3.2 はテキスト専用です。マルチモーダルなら ofox 上の視覚対応モデルへ。

停止ルール： 繰り返しのプレフィックスが 1k トークンより短い場合、キャッシュの節約は本物ですが小さいです。構成自体には固定コストもあります。この閾値を下回るなら、キャッシュ最適化なしで出荷し、プロンプトが伸びてから戻ってきてください。

システム要件

V3.2 を ofox 経由で使うのに DeepSeek 直結アカウントは不要です。ofox キー 1 本でカタログに到達できます。

ステップごとのインストール

ステップ 1：ofox API キーを発行する

ofox の dashboard でキーを生成します。リポジトリに入らないようローカルの env 変数に設定します。

export OFOX_API_KEY="sk-ofox-xxx"
export OPENAI_BASE_URL="https://api.ofox.ai/v1"

期待される結果： echo $OFOX_API_KEY でキーが表示される。ディスク上のどのファイルにもキーは保存されない状態です。

ステップ 2：OpenAI SDK を入れる

Python：

pip install "openai>=1.0.0"

Node：

npm install openai

期待される結果： pip show openai または npm list openai でインストールが確認できます。ofox の API は OpenAI 互換なので、OpenAI SDK が正しいクライアントです。形は同じで base_url だけが違います。

ステップ 3：DeepSeek V3.2 への最初の呼び出し

最小限の smoke test を smoke.py に置きます。

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["OFOX_API_KEY"],
    base_url="https://api.ofox.ai/v1",
)

resp = client.chat.completions.create(
    model="deepseek/deepseek-v3.2",
    messages=[
        {"role": "system", "content": "You are a terse assistant. Answer in one sentence."},
        {"role": "user", "content": "What is the cache read price for V3.2 on ofox?"},
    ],
)
print(resp.choices[0].message.content)
print(resp.usage)

期待される結果： 応答テキストと、prompt_tokens、completion_tokens、total_tokens、そして 2 つのキャッシュフィールド prompt_cache_hit_tokens、prompt_cache_miss_tokens を含む usage オブジェクト。最初の呼び出しではヒット数は 0 になります（コールドキャッシュ）。

ステップ 4：キャッシュヒットのために構造化する

プロンプトを組み直して、安定した部分を先に、可変の部分を後に置きます。動く雛形は次の通りです。

SYSTEM_PROMPT = """You are a customer-support classifier for an e-commerce site.
Label each ticket with exactly one of: refund | shipping | account | bug | other.
Output JSON only: {"label": "...", "confidence": 0.0-1.0}"""

FEW_SHOT_EXAMPLES = """Ticket: "Where is my order #12345?" -> {"label": "shipping", "confidence": 0.95}
Ticket: "Reset my password please" -> {"label": "account", "confidence": 0.92}
Ticket: "The button on /checkout doesn't work" -> {"label": "bug", "confidence": 0.88}"""

def classify(ticket_text: str) -> str:
    resp = client.chat.completions.create(
        model="deepseek/deepseek-v3.2",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT + "\n\n" + FEW_SHOT_EXAMPLES},
            {"role": "user", "content": f"Ticket: {ticket_text}"},
        ],
    )
    return resp.choices[0].message.content

期待される結果： この関数の 2 回目から N 回目の呼び出しでは、prompt_cache_hit_tokens が system + few-shot ブロックを覆うはずです。呼び出しごとに変わるのは user の行だけで、その前はバイト単位で同一に保たれます。

ステップ 5：ヒット率をログに残す

呼び出しをラップして、どこでキャッシュが効いているかを観察します。

def classify(ticket_text: str) -> dict:
    resp = client.chat.completions.create(
        model="deepseek/deepseek-v3.2",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT + "\n\n" + FEW_SHOT_EXAMPLES},
            {"role": "user", "content": f"Ticket: {ticket_text}"},
        ],
    )
    u = resp.usage
    hit_ratio = u.prompt_cache_hit_tokens / max(u.prompt_tokens, 1)
    return {
        "label": resp.choices[0].message.content,
        "tokens_in": u.prompt_tokens,
        "tokens_cached": u.prompt_cache_hit_tokens,
        "hit_ratio": round(hit_ratio, 3),
    }

期待される結果： およそ 10 回呼び出した後、この雛形では hit_ratio が 0.6〜0.85 の範囲に落ち着きます。0 付近に貼り付くなら、プレフィックスの中で呼び出しごとに何かが変わっています。トラフィックを増やす前に原因を追ってください。

ステップ 6：実際の請求を見積もる

V3.2 の単価を使って、大きなジョブを回す前に計算しておきます。100 万 prompt トークンを 70% ヒット / 30% ミス、出力 20 万トークンに分けると：

同じワークロードでヒット 0%（すべてミス）なら $0.29 入力 + $0.086 出力 = $0.376。現実的な混合ヒット率のジョブから、キャッシュが 43% を削り取ります。ヒット率を上げると節約は広がり、90% ヒットで $0.169、約 55% の削減です。

構成時にありがちなエラー（と対処）

チーム / マルチ開発者向けの構成

ソロワークなら API キー 1 本 + base URL 1 つで十分です。3 人以上で負荷を共有する場合、個々のプロンプトの巧妙さよりも構造の方が重要になります。

開発者ごとに鍵、モデル契約は共有。

開発者ごとに ofox キーを発行し、git にコミットしないこと。共有設定ファイルに model ID と base URL を固定し、全員が完全に同じモデルに当たるようにします。一人が deepseek/deepseek-v3.2 を打ち、別の一人がタイポを打てば、キャッシュは分裂し、追跡できないお金が燃えます。

共有の ai.config.ts（または ai_config.py）が最も安価な解です。

export const AI_CONFIG = {
  baseURL: "https://api.ofox.ai/v1",
  model: "deepseek/deepseek-v3.2",
  systemPrompt: SYSTEM_PROMPT,
  fewShot: FEW_SHOT_EXAMPLES,
} as const;

キャッシュヒット率をダッシュボード指標にする。

ステップ 5 の hit_ratio を既存の observability（Datadog、Honeycomb、ただの Postgres でも構いません）に流し込みます。hit_ratio < 0.4 が 1 時間続いたらアラートを上げてください。「誰かがプレフィックスを壊すプロンプト変更を出した」を検出する単一最良のシグナルです。

スケール時に共有 prompt registry が効く理由： 2 つのサービスが独立して system prompt を書き換えた瞬間、それぞれが自分用のキャッシュを構築します。同じ仕事に対して請求が倍になります。registry + PR レビューで複数サービスにわたってプレフィックスを一致させれば、キャッシュは熱いままに保たれます。

応用：ヒット率を 80% 超まで押し上げる

基礎を抑えたら、いくつかのパターンで比率をさらに絞れます。

ツール定義は決定論的にソートする。 tool/function スキーマを system メッセージにシリアライズするなら、キーをソートしてください。JSON シリアライザの object key 順序は Python と Node で異なる可能性があり、その 1 文字の空白ずれだけでプレフィックスは壊れます。

Few-shot の順序を固定する。 「多様性のため」にサンプル順序をランダム化しないでください。ランダム順序 = ランダムプレフィックス = キャッシュゼロ、です。多様性が欲しければ、シャッフルする 1 本ではなく、登録済みのプロンプトを 2 本走らせて（2 つのプレフィックスをどちらも温める）ください。

コンテキストを user に詰め込むより、system + assistant ターンを優先する。 user メッセージ先頭に長い検索コンテキストを置いてもキャッシュは可能ですが、system か先行 assistant ターンに置く方がプレフィックスの検出が綺麗です（ofox の chat メッセージ構造のドキュメントに対応形式が載っています）。

デプロイ時にバッチで暖機する。 新しいプロンプトバージョンを出すとき、本番トラフィックが来る前に低温度のダミーリクエストを 3〜5 本投げてキャッシュを温めます。最初のユーザーがキャッシュミスのプレミアムを払わずに済みます。

usage.prompt_cache_hit_tokens フィールドが何を報告しているかをもっと深く知りたい場合、DeepSeek の公式キャッシュガイドが wire レベルの詳細を扱っており、DeepSeek 2024 ディスクキャッシュ価格発表では、直結 API でキャッシュヒットがミスより約 10× 安くなる理由が説明されています。

DeepSeek V3.2 のキャッシュ価格を、独自のキャッシュ戦略を持つ他の ofox ホストモデル（Qwen 3.7、Claude ファミリー、Gemini 3.x）と比較したい場合は、モデル比較クラスタへ。

• ofox 上の DeepSeek V3.2 モデル詳細
• ofox モデルカタログ
• ofox API ドキュメント
• ofox ブログ：OpenAI 互換 API アクセス

FAQ

DeepSeek V3.2 はプロンプトを自動でキャッシュしますか？ はい。デフォルトで有効です。Anthropic の cache_control ブロックは不要です。モデルがリクエストのプレフィックスをディスクキャッシュに照合し、一致したトークンを cache-read レートで課金します。

ofox 上での DeepSeek V3.2 のキャッシュヒット料金はいくらですか？ キャッシュ読み取りは 100 万トークンあたり $0.06、ミス時の未キャッシュ入力は $0.29/M、出力は $0.43/M です。キャッシュヒットはミスより約 4.8× 安価です。

DeepSeek のプロンプトキャッシュはどれくらい持ちますか？ DeepSeek のドキュメントは寿命を「通常は数時間から数日」と表現しています。ベストエフォートで SLA はありません。保証付きキャッシュではなく、機会的キャッシュとして扱ってください。

DeepSeek V3.2 でキャッシュヒットを強制できますか？ いいえ。唯一のレバーはリクエスト構造です。安定したプレフィックス、動的な末尾、呼び出し間でバイト単位に同一な system + few-shot ブロックです。

DeepSeek V3.2 は 2026 年に廃止されますか？ DeepSeek 直結側の deepseek-chat と deepseek-reasoner のエイリアスは 2026 年 4 月 24 日以降 deepseek-v4-flash にルーティングされており（猶予期間）、エイリアス名は 2026 年 7 月 24 日に完全に deprecated になります。ofox は明示的 ID deepseek/deepseek-v3.2 で V3.2 を提供しており、上流のエイリアス移行とは独立です。

DeepSeek のキャッシュヒット率はどうやって確認しますか？ すべての chat completion レスポンスに usage.prompt_cache_hit_tokens と usage.prompt_cache_miss_tokens が含まれます。それらを合計し、ヒットを総 prompt トークンで割ってください。

ofox 経由で DeepSeek を呼ぶときもキャッシュは機能しますか？ はい。ヒット / ミスのフィールドはそのまま透過され、課金にもキャッシュレートが適用されます。base URL は https://api.ofox.ai/v1、model ID は deepseek/deepseek-v3.2 です。

2026 年半ばの本番で、V4 Flash より DeepSeek V3.2 を使う価値はまだありますか？ キャッシュ重視のワークロード（RAG、繰り返しの system prompts、安定指示のエージェントループ）にとって、$0.06/M キャッシュ読み取りの V3.2 は 128K コンテキストへの最も安価な経路の一つです。V4 が ofox に入った後に再評価してください。

請求書で最も安いモデルは、自分自身のキャッシュにヒットするよう構成済みのモデルであり、DeepSeek V3.2 をキャッシュトークン 100 万あたり $0.06 で回している状態こそ、それが達成された姿です。

この改訂で確認したソース

• DeepSeek API ドキュメント、KV cache ガイド（2026-06-15 確認）：https://api-docs.deepseek.com/guides/kv_cache
• DeepSeek API news、context caching の発表（2026-06-15 確認）：https://api-docs.deepseek.com/news/news0802
• ofox カタログのスナップショット（https://ofox.io/llms-full.txt）、DeepSeek-V3.2 が掲載され deepseek/deepseek-v3.2 が正規 model ID であることを確認（2026-06-15 確認）
• ofox V3.2 モデルページ（2026-06-15 確認）：https://ofox.io/models/deepseek/deepseek-v3.2 ——入力 $0.29/M、出力 $0.43/M、キャッシュ読み取り $0.06/M、コンテキスト 128K、最大出力 32K
• OpenRouter DeepSeek V3.2 リファレンス（2026-06-15 確認）：https://openrouter.ai/deepseek/deepseek-v3.2
• deepseek-chat / deepseek-reasoner エイリアスを 2026-07-24 に廃止する移行通知（複数の二次資料とクロスチェック済）