DeepSeek 提示词缓存（Prompt Caching）实战：长上下文 Agent 怎么降低 80% Token 账单
拆解 DeepSeek 自动上下文缓存机制：前缀匹配原则、命中与未命中计费差异、在 DSH 与 Coding Agent 中如何稳定命中缓存，以及避免缓存失效的工程规范。
本页内容
在长上下文 Coding Agent 和自动化循环中，Token 账单往往不是由最终输出决定的，而是被多轮对话中重复发送的几万甚至十几万上下文 Token 堆上去的。DeepSeek 在服务端原生提供了基于前缀匹配的上下文缓存（Prompt Caching / KV Cache），不仅免去了手动声明 Cache 标记的麻烦，还能将命中部分的输入成本直降 75% 到 90%。理解这套机制并设计合理的提示词前缀，是控制生产级 Agent 成本的关键一步。
无需手动标记，服务端透明按 64 Token 块前缀匹配
与部分大模型服务需要开发者在请求体中显式标注 cache_control 断点不同，DeepSeek 的上下文缓存完全在服务端自动完成。每次收到 API 请求时，DeepSeek 的分布式推理节点会对整个 Prompt 的 Token 序列计算前缀哈希。
根据官方文档，缓存以 64 个 Token 为基本存储单元。只要请求的前缀与集群节点上已有的 KV Cache 块匹配，系统就会直接复用已计算好的注意力键值状态，跳过冗余的 Prefill 计算，从而大幅缩短首字延迟（TTFT），并按照极低的缓存命中费率计费。
在 V4 与 V4.1 架构中，由于采用了多头潜在注意力（MLA，Multi-head Latent Attention），KV Cache 的显存占用被大幅压缩到传统架构的四分之一以下，甚至可以将冷缓存安全沉降到高速 SSD（占用仅八分之一）。这也是 DeepSeek 能够对全量 API 用户默认开放上下文缓存并提供深度折扣的核心系统支撑。
本节来源：DeepSeek API 文档：上下文缓存（KV Cache） · DeepSeek：DeepSeek V4.1 Flash 发布说明
命中费率仅为未命中的十分之一到四分之一
DeepSeek 的 API 定价模型将输入 Token 明确区分为缓存未命中（Cache Miss）与缓存命中（Cache Hit）。对于 DeepSeek-V3 / Chat 模型，未命中输入为 2.0 元 / 百万 Token，而命中输入仅为 0.5 元 / 百万 Token（非高峰期甚至低至 0.1 元）；在轻量高速的 V4.1 Flash 路由上，命中价格更是降至 0.028 元 / 百万 Token。
在单次问答场景下，缓存的作用可能并不明显；但对于自主运行的 Coding Agent（如 DSH、Claude Code、Cursor），多轮交互通常会在第 10 轮以上积累数十万累积输入。下表整理了官方公布的标准定价对比：
| 模型路由 | 缓存命中输入（每百万 Token） | 缓存未命中输入（每百万 Token） | 输出（每百万 Token） | 输入成本降幅 |
|---|---|---|---|---|
| DeepSeek-V3 / Chat (标准) | 0.50 元 ($0.07) | 2.00 元 ($0.28) | 8.00 元 ($1.10) | 约 75% |
| DeepSeek-V3 / Chat (夜间非高峰) | 0.10 元 ($0.014) | 1.00 元 ($0.14) | 2.00 元 ($0.28) | 最高 90% |
| DeepSeek V4.1 Flash | 0.028 元 ($0.004) | 0.14 元 ($0.020) | 0.28 元 ($0.040) | 约 80% |
| DeepSeek Reasoner (R1) | 1.00 元 ($0.14) | 4.00 元 ($0.55) | 16.00 元 ($2.19) | 约 75% |
定价数据整理自 DeepSeek 官方定价页面。非高峰时段指北京时间 00:30 至 08:30。实际结算以 DeepSeek 账户中心当期公布汇率与账单为准。
本节来源：DeepSeek API 文档：模型与价格 · DeepSeek API 文档：上下文缓存（KV Cache）
在 DSH 与 Coding Agent 中构建高命中率提示词前缀
因为 DeepSeek 采用的是严格的从左到右前缀匹配机制，Prompt 的结构编排决定了缓存命中的上限。只要最开头发生了一处微小变化，后面的所有 Token 都会发生哈希不匹配，导致前缀缓存完全失效。
在使用 DeepSeek Harness（DSH）或编排自动化工作流时，应当遵循固定静态前缀、追加动态上下文的工程原则。将最稳定的系统角色声明、MCP 工具规范和项目约束（如 AGENTS.md）放在最前面，把不断增长的工具执行记录与用户对话按追加方式排在最后。
- 前置静态系统提示词：切勿在 System Prompt 的开头插入动态时间戳、随机请求 UUID 或机器硬件状态。
- 固化 MCP 工具定义：保持工具列表顺序稳定，不要在同一会话中动态增删工具声明，以免破坏前序哈希。
- 统一挂载项目规则：将仓库架构说明、代码规范或 AGENTS.md 作为固定的 System / Context 前缀，多轮任务共享同一份项目基线。
- 严格只追加对话历史：历史对话内容保持不可变，新的用户指令和工具返回只追加在末尾，绝不在中途重排或修改早先消息。
本节来源：DeepSeek API 文档：上下文缓存（KV Cache） · DeepSeek Harness：官方 GitHub 仓库
排查缓存未命中：响应字段监控与工程避坑
验证缓存是否生效非常直接。在调用 DeepSeek API 时，检查返回 JSON 中的 usage 字段，即可看到 prompt_cache_hit_tokens 与 prompt_cache_miss_tokens 的具体数量。正常运行的 DSH 多轮编码任务中，从第二轮开始 prompt_cache_hit_tokens 占比通常应稳定在 80% 以上。
如果发现命中率异常偏低，常见原因包括：会话空闲时间过长导致服务端节点回收了热缓存（通常数小时无活动会被驱逐）；或者客户端在本地上下文压缩（Compaction）时采用了简单的滑动窗口丢弃算法，直接裁剪了顶部的系统前缀。合理的上下文管理方案应当在保留顶部前缀的同时，对中间历史轮次进行摘要折叠。
调用返回中包含 prompt_tokens: 32768, prompt_cache_hit_tokens: 28416, prompt_cache_miss_tokens: 4352。这表明前序 2.8 万 Token 全部以折后价格结算，当次请求的输入成本下降了 65% 以上。
本节来源：DeepSeek API 文档：上下文缓存（KV Cache） · DeepSeek API 文档：模型与价格
DeepSeek API 文档：上下文缓存（KV Cache） · DeepSeek：DeepSeek V4.1 Flash 发布说明 · DeepSeek API 文档：模型与价格 · DeepSeek Harness：官方 GitHub 仓库