ofox 上配置 DeepSeek V3.2 提示词缓存：10 分钟接入，账单直降 80%（2026）

每个 DeepSeek 缓存命中请求和未命中请求之间，横着一道 4.8 倍的价差——而在典型的 agent 循环里，命中还是未命中的差别，就在于你有没有把时间戳塞到提示词末尾。

30 秒答案

如果你只看表格，看这一张：

合计：约 10 分钟。配置完之后，结构合理的调用就能按 $0.06/M 的缓存读取价走，而不是 $0.29/M 的未命中价——缓存输入 token 上等于打 2.07 折。

3 条规则能覆盖 90% 的节省空间：

1. 前缀稳定、尾巴动态。 每次请求会变的内容一律放在提示词末尾，绝不放进 system 消息或 few-shot 块里。
2. 同字节同命中。 缓存匹配是 token 层面的精确匹配。一个新空格、一个不同的 ISO 时间戳、一段按用户加的盐——都会让前缀失效。
3. 不量化等于没做。 每个响应都把 prompt_cache_hit_tokens 取出来。比例一掉，说明前缀里混进了动态内容。

配置完能做什么、不能做什么

✅ 可以做：

• 用一把 ofox API key 跑 deepseek/deepseek-v3.2，代码形态跟任意 OpenAI SDK 调用一致。
• 重复前缀按 $0.06/M 走缓存读——128K 上下文，最大 32K 输出。
• 用 DeepSeek 直接返回的同一组 usage 字段（prompt_cache_hit_tokens、prompt_cache_miss_tokens）按请求追踪命中。
• 一把 key 给团队共用，从 dashboard 用量日志里观察哪条调用路径缓存效果好。

❌ 不能做：

• 强制缓存命中。DeepSeek 的缓存是尽力而为——没有 Anthropic 的 cache_control 标志，也没有 Gemini context cache 的 cache_id 可以钉。
• 跨用户共享缓存——如果每个用户的 system 提示里都带了一段独有的盐。把用户 ID 挪到末尾，或者放到提示词正文以外的 metadata 字段里。
• 让缓存一直留着。生命周期是「几小时到几天」，冷路径会被清掉。
• 跨模型版本共享缓存。deepseek/deepseek-v3.2 切到 deepseek/deepseek-r1 时缓存会重新建。
• 在 2026 年 7 月 24 日之后，把缓存节省和 DeepSeek 直连侧的 V4 别名混着用。通过 ofox 的 V3.2 模型 ID 是钉死的，基于它的工作负载在上游别名迁移之后仍能跑——不过等 V4 进了 ofox 模型目录，你需要那时再重新评估。

如果你需要上面任何一条的硬保证，答案不是「调一下这套配置」——而是换模型、换厂商。

决策框架：什么时候用这套配置，什么时候不用

适用场景：

1. 每次会话检索上下文稳定的 RAG 流水线。 检索块加 system 提示组成一段很长的稳定前缀，用户查询是尾巴。命中率 70% 以上很常见。
2. system 提示 + tool schema 不变的多轮 agent 循环。 每轮开头都一样——缓存从第二轮就开始回本。
3. 多个提示共享长 preamble 的批处理任务（比如用同一套标注指令分类 1 万张工单）。串行跑同一前缀，缓存就一直热着。

不适用场景：

1. 一次性、完全动态的提示词。 每个请求 system 都不同，每次都是 $0.29/M。缓存帮不上忙——不如换个更小的模型。
2. 延迟 SLO 严格、还要靠缓存命中达成的场景。 缓存是尽力而为，你应该按未命中来设计。
3. 合规要求禁止跨请求缓存用户数据的场景。 在数据处理层关掉它，改用每次调用都明确临时记忆的模型。
4. 需要图像输入的工作负载。 V3.2 只支持文本。要多模态就跳到 ofox 上有视觉能力的模型。

停手规则： 如果你重复的前缀短于 1k tokens，缓存节省虽然真实但很小。配置本身还是有固定成本。低于这个阈值就先别做缓存优化，等提示词变长了再回头看。

系统要求

不需要 DeepSeek 直连账号——一把 ofox key 就能用到整套模型目录里的 V3.2。

分步安装

步骤 1：申请 ofox API key

在 ofox dashboard 里生成 key。本地设成环境变量，不要落到仓库里：

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

预期结果： echo $OFOX_API_KEY 能打出你的 key，磁盘上没有任何文件持有它。

步骤 2：安装 OpenAI SDK

Python：

pip install "openai>=1.0.0"

Node：

npm install openai

预期结果： pip show openai 或 npm list openai 显示安装成功。OpenAI SDK 是合适的客户端，因为 ofox 的 API 是 OpenAI 兼容的——形态一样，只是换了 base_url。

步骤 3：第一次调用 DeepSeek V3.2

把最简版烟雾测试丢到 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 以及两个缓存字段 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

预期结果： 这个函数第二次到第 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 的价目，大任务跑之前先算一遍。1M 提示 token 按 70% 命中 / 30% 未命中、外加 20 万输出 token：

同样的工作负载在 0% 命中下（全未命中）：$0.29 输入 + $0.086 输出 = $0.376。缓存把一个真实的混合命中率任务砍掉了 43%。命中率再往上，节省更多——90% 命中时是 $0.169，比未命中省了约 55%。

配置过程中常见错误（与修复）

团队 / 多开发者配置

单人干活，一把 API key + 一个 base URL 就够了。3 人以上、负载共用的场景，结构比单条提示词的小聪明更重要。

每个开发者一把 key，模型契约共享。

每个开发者发一把独立的 ofox key；绝不把 key 提进 git。把模型 ID 和 base URL 锁在共享配置文件里，让每个人都打同一个模型——如果一个人打 deepseek/deepseek-v3.2，另一个人打了拼错的 ID，缓存就分裂了，钱也花得追查不到。

一个共享的 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;

把缓存命中率当成 dashboard 指标。

把步骤 5 里的 hit_ratio 推到你已有的观测平台（Datadog、Honeycomb、随便一张 Postgres 表都行）。在 hit_ratio < 0.4 持续 1 小时时报警。这是「有人改了提示词、把前缀搞坏了」最灵敏的单一信号。

为什么规模化后需要一个共享提示词注册表： 一旦两个服务各自重写了 system 提示，它们就各自建了一套缓存。同样的活，账单翻倍。注册表 + PR 审核能让前缀在多个服务间保持一致，缓存也就一直热着。

进阶：把命中率推到 80% 以上

基本盘搞定之后，几个套路能把比率再压一压：

工具定义按确定性顺序序列化。 如果你把 tool/function schema 序列化进 system 消息，给 key 排序。JSON 序列化器的 object key 顺序在 Python 和 Node 之间可能不一样——这一点空白的差异就够让前缀失效。

few-shot 顺序钉死。 别为了「提升多样性」去打乱示例顺序。随机顺序 = 随机前缀 = 零缓存。要多样性就注册两段独立的提示词（两个前缀都热着），别在一个里面随机洗牌。

优先用 system + assistant 轮次，少把上下文塞进 user。 在 user 消息开头放一长串检索上下文也能缓存，但放在 system 里或者放在前置 assistant 轮次里，前缀识别更干净。（ofox 的对话消息结构文档列了所有支持的形态。）

部署时批量预热。 推新提示词版本时，先用低温度发 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 块。模型把请求前缀和磁盘缓存做匹配，命中 token 按缓存读取价计费。

ofox 上 DeepSeek V3.2 的缓存命中价是多少？ 缓存读 $0.06/M tokens，未命中输入 $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 日彻底废弃。ofox 用明确的 ID deepseek/deepseek-v3.2 暴露 V3.2，独立于上游别名迁移。

怎么查 DeepSeek 的缓存命中率？ 每次对话完成响应都包含 usage.prompt_cache_hit_tokens 和 usage.prompt_cache_miss_tokens。累加之后用命中数除以总提示 token 数。

通过 ofox 调 DeepSeek 时缓存还有效吗？ 有效。命中/未命中字段原样透传，账单按缓存费率计算。base URL 是 https://api.ofox.ai/v1，模型 ID 是 deepseek/deepseek-v3.2。

2026 年中，相比 V4 Flash，V3.2 在生产环境还值得用吗？ 对缓存密集的工作负载——RAG、重复 system 提示、指令稳定的 agent 循环——$0.06/M 缓存读取的 V3.2 仍是到 128K 上下文最便宜的路径之一。等 V4 在 ofox 上落地后再重新评估。

账单上最便宜的模型，是你已经配置好让它命中自己缓存的那一个——DeepSeek V3.2 按 $0.06/百万缓存 token 计费，就是配置到位时它该有的样子。

本次更新核对的来源

• DeepSeek API 文档，KV 缓存指南（2026-06-15 验证）：https://api-docs.deepseek.com/guides/kv_cache
• DeepSeek API news，上下文缓存公告（2026-06-15 验证）：https://api-docs.deepseek.com/news/news0802
• ofox 模型目录快照（https://ofox.io/llms-full.txt），确认 DeepSeek-V3.2 在列、deepseek/deepseek-v3.2 是规范模型 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 退役通告（已和多个二手资料交叉核对）