第 34 卷

14.1 对话缓存机制原理

DeepSeek API 的 **context cache**（提示词缓存）：重复/相似的输入 token 按**缓存价* *计费，而不是全价。dsh 每次模型请求的输入 = 系统提示 + 技能目录 + 对话历史 + 工具

schema（第 8 章 8.3），**其中不变的前缀部分就是缓存的天然候选**——这决定了 Agent 工作负载的缓存潜力远高于普通聊天。

**计费规则**（**2026-08-16 16:00 UTC 起峰谷计价**，官方[价格页](https://apidocs.deepseek.com/quick_start/pricing)；第 5 章 5.1.1 仍是峰谷计价前的旧统一价目表，

口径以本章为准）：

（单位：美元/百万 token。）

**折扣率变化（旧 → 新）**——14.3 的三原则方向仍然成立，但「缓存管输入单价」这根杠杆变短了：

旧表（统一价）新表（谷时）

同时**输出价 = 未命中价的 3 倍**（旧表是 2 倍）——**输出重的任务里，缓存优化能拿回的比例比旧表算出来的小**（输出不享受缓存折扣，且相对输入价权重上升）。

**峰谷计价（2026-08-16 16:00 UTC 起）**：

• **峰时**：UTC **01:00-04:00** + **06:00-10:00**；其余为**谷时**，谷时价正好是峰

时的一半（命中/未命中/输出三个档位一起减半）

• **北京时间**峰时 = **09:00-12:00** + **14:00-18:00**——几乎正好覆盖中国的工作

日，只留出午休

• **对国内用户**：日常写代码的时间基本全部落在 2 倍价区间内；把**长跑任务**（批量

重构、跑测试、agent 长任务）挪到**晚上或早 8 点前**，账单直接**减半**

• 这是 **100% 的差价**，比 14.3 里任何一条优化的幅度都大，且**不需要改任何配置**

• 与命中率是**乘法关系**而不是加法：谷时把三个档位一起减半，与 14.3 的优化不冲突，

可以叠加（见 14.3 末尾）

**每次请求的输入结构**（第 8 章 8.3），决定了哪些 token 能命中：

系统提示（稳定） + 技能目录（稳定） + 对话历史（增量） + 工具 schema（稳定） + 本轮消息（增量）

└────────────── 缓存命中区（重复） ──────────────┘└── 未命中区（新增量） ──┘

**命中区越大、增量越小 → 命中率越高**。理解这个结构，14.3 的三个优化杠杆本质上都是"让命中区变大"。

**缓存不只省钱，还提速**：冷启动首轮含上下文注入约 110s，热缓存约 1s（第 1 章实测）

——命中时首 token 时间量级性缩短。

> **严格前缀缓存规则（社区分析，#1052 weijiafu14，官方文档 [kv_cache](https://apidocs.deepseek.com/guides/kv_cache/)）**：DeepSeek 是**严格的前缀缓存**——前缀单元

在**用户输入结束、模型输出结束等位置持久化**；下一次请求只能命中"已经完整匹配"的前缀。

关键推论：

> - **工具结果天然 miss 一次**：工具结果是在"上一轮模型输出"之后才追加的，它**第一次进入下一次请求时必然是新后缀、必 miss 一次**——不论传原文还是压缩预览（这与截断方式无关）。

> - **"截断会避开缓存"是误读**：只要截断是确定性的（同输入同输出），后续回放的是同一份字节，已有前缀照常命中；只有首次出现的压缩结果、以及之后主动读取 artifact 新增的内容各自

miss 一次。**压缩工具不会绕开 DeepSeek 缓存，反而把"必然首次 miss"的工具结果缩小** （#1052 weijiafu14 实测：原生工具输出 42,299 字符 → 压缩持久化 7,885 字符，后续

derive/replay 哈希一致）。

> - **代价提醒（#1052 fnsii + weijiafu14）**：缓存本身是 best-effort、官方不承诺 100% 命中（weijiafu14 转述官方说明）；若完全不保留上下文前缀（如每轮重写/清空历史、换新会话丢

全部前缀），则完全无法命中缓存，等于按新输入全价计算（fnsii）。**快封顶时优先做 summary 压缩再续**（保留前缀摘要），而不是直接开新会话丢全部前缀（fnsii 建议）。

14.2 命中率实测：97% 怎么来的

手册在**真实 dsh 会话统计**中实测缓存命中率**可达 97%**（第 5 章 5.1.1）。为什么 dsh 的命中率特别高：

原因说明

会话延续同会话多轮对话，系统提示/技能目录/历史重复 → 命中

稳定的工具 schema每步请求携带相同的工具定义 → 命中

Agent 工作负载特性多步工具链反复携带相同上下文 → 命中率天然高

**边界（诚实版）**：97% 依赖"对话模式重复"——**全新任务/冷启动场景会明显下降** （第 12 章 12.5）。社区长跑实测可达 **99.7%**（[#560](https://github.com/deepseek-

ai/deepseek-harness/discussions/560)），印证"越长的会话命中率越高"。

**实测方法**：Web UI 底部会话统计行看"缓存命中 %"（第 6 章 6.6）；对比基准是 5.1.1 的"50 步工具链任务、2.4M 输入 token"——它是输入量级的典型样本。

> **口径注意（#1234 社区补充）**：Harness 界面显示的「缓存命中 %」是**对话内**口径— —只统计当前会话这一路请求。若同一时间段开过多个对话，其他对话命中率较低时，会把**多对

话整体/后台口径**拉低（社区实测对照：后台/整体约 94.5% vs 界面（对话内）98%，[#1234] (https://github.com/deepseek-ai/deepseek-harness/discussions/1234)）。**测量命中率时

先明确口径**：对话内（界面统计行）还是多对话整体（后台/API 侧）；对比命中率只在同口径下才有意义。

> **口径注意 2（峰谷计价，#45 作者实测踩过）**：2026-08-16 起峰谷计价后，**跨峰谷边界的会话**里，同一份前缀在边界前后按不同单价计费——做成本对照实验时（如 14.4 的成本模型、

14.2 的命中率实测），**跨边界的会话不能和不跨边界的会话直接比金额，只能比 token**。#45 作者实测踩过：两组数据重算时才发现时间分布不同，按金额对比会得出错误结论。

以下（第 6 章 FAQ Q4）

总 token会话总览增量小 = 命中区在变大（14.1 结构）

14.3 命中率优化实践

三个杠杆，按性价比排序：

免频繁新建会话；批量任务放同一会话/同前缀

稳定提示词系统提示/技能目录等前缀前缀一致 → 命中保持稳定，不频繁改配

置；工具 schema 不变

少打断一次把验收标准写清楚避免前缀重建 → 全价重（第 5 章 5.7 / 第 10 章来

案例启示），减少"重开会话重讲上下文"

**落地检查**：命中率低于预期时，第一反应查"前缀是否变了"——改过配置、换过档位、动过技能目录，都会让缓存失效（第 6 章 6.6 监控行）。