硬盘上的 KV Cache：DeepSeek 把输入缓存价差做到 50 倍的架构账

2026 年 4 月 26 日，DeepSeek 把全系 API 的输入缓存命中价一次性砍到原价的十分之一，V4-Pro 的缓存输入叠加促销后低到 0.025 元/百万 tokens。四个月后的 9 月 10 日，V4.1-Flash 发布，除了把模型换成新的非对称 Causal-Encoder-Decoder 结构，还顺带公布了一个更硬的数据：相比上一代，KV Cache 对 HBM 的需求减到 1/4，对 SSD 的需求减到 1/8，官方定价再降一轮。

表面看这是两轮价格新闻，底下是同一件事。DeepSeek 把大模型推理里最贵的那段计算，改造成了可以放在廉价硬盘上复用、并且能被精确计价、精确打折的资产。想搞清楚这个价格是怎么来的、又在什么条件下会失效，得先分清它到底缓存了什么。

缓存到底缓存了哪一段

模型处理一次请求分两步。第一步 prefill，把整段输入读进来、算出每个 token 的 K 和 V；第二步 decode，一个 token 一个 token 往外吐。KV Cache 省的是 decode 阶段的重复计算，作用域在单次请求内部，它不改变计费；prompt / prefix cache 省的是 prefill 阶段的算力，作用域跨请求，它直接打折。

真正能计费的是后者。DeepSeek 的做法是把 prompt 前缀的 prefill 结果——也就是算好的 K/V 状态——落盘。下一次相同开头进来，prefill 整段跳过，把状态从硬盘加载回显存，然后照常 decode。省下的是几十万 token 的 prefill 算力，付出的是一次 NVMe 读取的 I/O。这笔账能算得过来，前提是缓存体积足够小。

落盘与命中：比 HTTP 缓存脆得多

官方文档里有一条容易被想当然绕过去的约束：只有从第 0 个 token 开始完全相同的请求才算重复，中间片段的重复不计入命中。这不是语义相似度匹配，而是前缀的精确对齐。把「相似的问题」凑一凑就能吃到缓存的想法，从根上就不成立。

V4 之后规则还更严了一档。受 Sliding Window Attention 的影响，缓存前缀以「缓存前缀单元」为单位存取，只有完整匹配到某个单元才计为命中。系统在三类时机会落盘：

  1. 请求结束位置落盘。每次请求的用户输入结束位置与模型输出结束位置，各产生一个缓存前缀单元。
  2. 公共前缀检测落盘。系统发现多次请求之间存在公共前缀时，把这段公共前缀单独落盘成一个单元。
  3. 按固定 token 间隔落盘。长输入或长输出中，按一定 token 数量为间隔截取单元，避免超长前缀因为迟迟走不到结束位置而完全无法缓存。

这个规则落到多轮对话上会变成一条隐含要求。第一轮请求是 A + B，第二轮是 A + B + C，第二轮能完整匹配 A + B 这个单元，命中。但如果第二轮是 A + C，就命中不了——系统这时才发现 A 是公共前缀并把它落盘，要等到第三轮 A + D 才吃得到。换句话说，历史消息只能往后追加，不能重排、不能回改，连工具定义序列化出来的 JSON 键顺序漂一下都会让整段前缀作废。

图：请求前缀对齐与命中的请求链路，prefill 结果落盘、后续请求从硬盘加载 KV 进入显存再 decode

为什么 KV 能被写进硬盘

关键在压缩率。2024 年 8 月首次上线硬盘缓存时官方就点明，这件事能做的前提是 DeepSeek-V2 的 MLA 结构把上下文 KV Cache 压得足够小，传输带宽和存储容量的需求同步下降，才缓存得起。

V4 把这条路线推得更远。技术报告里的混合注意力由 CSA（Compressed Sparse Attention）和 HCA（Heavily Compressed Attention）交错组成：CSA 先把每 m 个 token 的 KV 压成一个条目，再在压缩后的条目上做稀疏选择，让每个 query 只关注 Top-k 个压缩块，擅长抓局部；HCA 用激进得多的压缩率，把每 128 个 token 的 KV 融成一个条目，但保持稠密注意力，擅长做全局语义融合。网络层上前两层用 HCA，后面 59 层交替排布。

压缩必然丢局部细节，所以两种注意力都额外挂了一条 128 token 的滑动窗口分支，把最近那段未压缩的 KV 直接送进 attention，另外加了一个可学习的 attention sink 允许 head 把总注意力权重压得很低。这些是补丁，也是必要的妥协。

效果写在报告里：1M 上下文下，V4-Pro 的单 token 推理 FLOPs 只有 V3.2 的 27%，KV Cache 占用降到 10%；Flash 更激进，FLOPs 约 10%、KV 占用约 7%。换成更好比较的基线——以 BF16 精度、GQA8 的常规实现为参照，V4 系列在 1M 上下文下的 KV Cache 可以压到基准的 2% 左右。

这里才是「缓存」二字真正的技术含量：能不能把缓存放到硬盘、命中一次能省多少，取决于 KV 小到什么程度。压缩率不够，硬盘方案的随机读写成本会直接吃掉节省。

硬盘缓存自身的工程取舍

V4 技术报告里有一段专门讲磁盘 KV Cache，值得单独拎出来。针对前缀复用场景，长序列的压缩缓存会被放到外部介质上；但未压缩的 SWA 缓存体积庞大，团队为此给了三种管理方式：

  • 全缓存：零计算冗余，代价是对 SSD 的随机写入压力大。
  • 周期性 checkpoint：每隔一段存一次，加载时重算中间一小段。
  • 零缓存：完全依赖上层 CSA/HCA 缓存，加载时只重算最近那段 token。

存储换算力，没有免费选项。选哪种，取决于你的 SSD 写入带宽和重算成本哪个更贵。

图：KV Cache 占用随代际压缩的演进对比，MLA 到 CSA/HCA 再到 V4.1 的 HBM 与 SSD 需求下降

这笔账是怎么算出来的

价格时间线本身就能说明问题：

时间 动作 结果
2024-08-02 上线上下文硬盘缓存 命中价 0.1 元/百万 tokens，约为未命中的 1/10
2026-04-26 全系缓存命中价降至首发 1/10 V4-Pro 缓存输入叠加限时促销低至 0.025 元/百万 tokens
2026-08-16 V4 正式版，引入峰谷定价 闲时价 = 高峰价的一半
2026-09-10 V4.1-Flash 发布并调价 KV Cache 需求降至上一代 1/4 HBM、1/8 SSD

按官方价格页当前的数字（人民币 / 百万 tokens）：deepseek-flash 缓存命中闲时 0.02、高峰 0.04，缓存未命中 1 / 2，输出 4 / 8；deepseek-v4-pro 缓存命中 0.15 / 0.30，未命中 4.5 / 9.0，输出 13.5 / 27。

有个反直觉的地方：九月这轮调价之后，命中与未命中的倍率反而从上百度收窄到了 Flash 的 50 倍、Pro 的 30 倍左右——因为未命中价一起降了。倍率不是重点，绝对值才是，而绝对值取决于你的前缀稳不稳。

延迟侧的收益同样直接。官方 2024 年给的极端案例是：128K 输入且大部分内容重复的请求，首 token 延迟从 13 秒降到 500 毫秒。

和显存内的 prompt cache 差在哪

OpenAI 和 Anthropic 的 prompt cache 放在显存里。显存贵、容量小、留不住，Anthropic 的 TTL 分 5 分钟和 1 小时两档，而且对写缓存单独收费——以 Opus 系列为例，$5/M 的原价输入，命中读取只要 $0.50/M，但写一次 5 分钟寿命的缓存要 $6.25/M、1 小时要 $10/M。

DeepSeek 的差异有三点：写缓存不收费、不需要显式声明生命周期、TTL 是小时到天级。代价也很明确，官方文档写的是「尽力而为」，不保证 100% 命中，缓存不再使用后会自动清空。你省下的这笔钱，对应的是一份没有 SLA 的缓存。

痛点在生产里就是命中率

Agent 场景把这个问题放大到了极致。一个长会话动辄上亿输入 token，命中与未命中的单价差 50 倍，命中率从 95% 提到 99% 对账单的影响是数量级的。

真实工程里的破坏源往往琐碎得可笑：系统提示词里注入时间戳或计数器、每轮重新序列化工具定义导致 schema 键序漂移、在历史消息中间内联工具结果、重排消息顺序。任何一条都会让前缀的字节对齐失效，缓存整段作废，而且这些改动大多藏在框架内部，不做请求侧观测根本看不见。

也正因为这样，社区里长出了一批「缓存优先」的 Agent harness。有开发者把 DeepSeek 接进以简单著称的 Pi，报出约 99.93% 的输入 token 命中缓存；也有专门为 DeepSeek 设计的终端 Agent，用「前缀只算一次并锁定哈希、日志只追加不重写、临时草稿独立存储」三条不变量，把单日 4.35 亿输入 token 的命中率做到 99.82%——按它公布的数据，同样负载无缓存要 $61.06，实际只花 $1.38。还有团队横测 8 款主流 Agent harness，同一个 DeepSeek V4 Flash，完成一次成功任务的平均成本最高能差到约 7 倍。

这些数字来自第三方实践与报道，不是官方口径，但方向是一致的：模型不变，成本由 harness 的前缀管理决定。反过来看，GitHub 上会有用户把 95% 的命中率当成「偏低」来提 issue，也就不奇怪了——在这种计价结构下，剩下那 5% 足够吃掉大部分优化空间。

图：缓存命中与未命中在 Agent 高频调用下的成本分化示意

生产环境的局限与风险

几点在设计阶段就必须承认的约束：

  1. 前缀对齐极脆。 动态注入、消息重排、序列化不确定都会打回原形，且多数破坏来自框架而不是业务代码，不做监控基本发现不了。
  2. 命中不可控。 官方定位是 best-effort，公共前缀检测和按间隔落盘都由系统侧策略决定，请求方能影响的只有前缀的稳定性，没法强制命中。
  3. 幂等性不传递。 缓存只作用于输入前缀，输出仍然走完整计算，仍受 temperature 等参数影响，同一请求两次结果可以不同。
  4. 隔离靠声明。 官方声明每个用户的缓存独立、逻辑互不可见、不长期保留。真要做多租户容量规划，最好按「全命中」和「零命中」两套成本模型各算一遍。
  5. TTL 是小时到天级。 低频任务的缓存命中预期要主动打折，别把优惠价直接写进预算。

落地建议

如果服务已经在跑 DeepSeek，性价比最高的几条改动是：

  • 把 system prompt 里静态的部分（角色设定、工具签名、few-shot 示例）全部前置，动态内容统一挪到最后一条消息；
  • 历史消息只追加。要压缩上下文就摘要成一条新消息追加在末尾，绝不改写已有前缀；
  • 工具定义做确定性序列化，保证同一组工具每次产出完全一致的 JSON；
  • 把 prompt_cache_hit_tokens / prompt_cache_miss_tokens 打进监控，命中率掉下来先查前缀漂移；
  • 可延迟的批处理尽量放到闲时，闲时价是高峰价的一半，这笔节省和缓存命中互不冲突。

参考资料

  1. DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence（arXiv:2606.19348）
  2. DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression（arXiv:2609.19969）
  3. 上下文硬盘缓存 — DeepSeek API Docs
  4. 模型 & 价格 — DeepSeek API Docs
  5. DeepSeek API 创新采用硬盘缓存，价格再降一个数量级 — DeepSeek API Docs
  6. DeepSeek V4.1 Flash：更强、更快、更普惠 — DeepSeek API Docs
  7. Change Log — DeepSeek API Docs