千寻追评：缓存账本的六个追问

读完主文，有几个点值得从另一侧切开看看。

一、「缓存命中价」的本质是什么？

很多人误以为缓存折扣是厂商让利。事实恰恰相反——缓存命中的边际成本几乎为零。API 厂商缓存的不是文本，而是 KV Cache（注意力矩阵）。一旦算好，复用只是读取内存/磁盘，不需要 GPU 重新计算。

> 缓存命中价 0.1x，不是「优惠」，是对「零边际成本」的正确定价。

未命中价才是真正的算力成本。厂商把未命中定全价，命中定零头，本质是成本加成定价——按实际消耗的资源收费，而不是按 token 数量收费。

二、DeepSeek 的 1/120 价差，暴露了什么？

V4-Pro 缓存命中与未命中的价差达到 120 倍。这个数字的潜台词是：

• DeepSeek 的 MLA 压缩把 KV Cache 体积压到标准模型的 7-10%
• 压缩后的 KV Cache 可以塞进硬盘，而不是昂贵的 GPU 显存
• 硬盘存储成本 ≈ 显存的 1/1000

结论：DeepSeek 不是在「打折」，它是在用存储经济学的常识重新定价。其他厂商的缓存还在显存里，成本下不来，所以只能给 1/10 折扣。DeepSeek 把缓存搬到硬盘，成本结构完全不同，定价自然也不同。

三、Token 中间商的新套路

主文提到中间商靠「缓存不透明」割韭菜。但更深一层的问题：中间商自己能不能命中缓存？

答案是——不一定。中转站如果做了以下任何一件事，缓存就会失效：

1. 前缀注入：在转发前加自己的跟踪标记/广告标记 2. 负载均衡：同一用户请求被随机路由到不同服务器 3. 格式转换：OpenAI 格式转 Anthropic 格式时 reorder 了消息 4. 用户隔离：每个用户的请求被隔离到不同缓存命名空间

讽刺的是：越是「正规」的中转站（做用户隔离、格式转换、负载均衡），越可能破坏缓存。反倒是简单粗暴的透明代理，缓存命中率更高。

四、Claude Code 的 DANGEROUS_ 前缀，是工程文化的标本

源码里把易变函数命名为 DANGEROUS_uncachedSystemPromptSection()，而不是 dynamicSection() 或 variableSection()。

这种命名方式传递了一个工程态度：缓存失效不是性能问题，是财务问题。 12.5 倍的成本差距，值得在代码层面用警告级命名来防止误用。

这比任何文档都有效。你在 IDE 里打 DANGEROUS_ 时，自动补全跳出来，你自然会停下来想一想。

五、Prompt Cache 改变了 Agent 架构设计

主文提到「不变的内容放前面，变化的内容放后面」。但这个原则对 Agent 系统的架构有更深影响：

• 工具定义必须稳定：如果 Agent 动态注册/注销工具，缓存前缀每轮都变
• 系统提示必须静态：如果 Agent 每轮都更新自己的「能力画像」，缓存无法命中
• 多 Agent 共享前缀：Claude Code 的 YOLO 分类器和主对话引擎共享前缀，本质上是「多个 Agent 共用同一块缓存」

结论：Prompt Cache 正在从「优化技巧」变成「架构约束」。未来的 Agent 框架设计，缓存命中率会成为一等指标，和延迟、吞吐量并列。

六、一个关于隐私的暗线

Stanford 的 ICML 2025 论文（Auditing Prompt Caching）发现：17 家 API 厂商中 7 家存在跨用户缓存共享。攻击原理是时序侧信道——如果你的 prompt 响应特别快，说明它被别人缓存过。

这意味什么？

• 你以为是「私有」的 API 调用，可能正在和陌生人的请求共享缓存前缀
• 敏感信息（医疗记录、商业文档）如果命中缓存，理论上可以被侧信道推断
• Anthropic 的做法（组织级/工作空间级隔离）是负责任的，但不是行业标准

> Prompt Cache 的安全模型，整个行业还没想清楚。

---

追评总结：缓存不仅是技术问题，也是定价问题、架构问题、安全问题。DeepSeek 用 MLA 压缩把缓存从显存解放到硬盘，重新定义了成本结构。Claude Code 用工程纪律把缓存命中率推到 92%。而 Token 中间商和不透明的缓存机制，正在制造新的信息不对称。

#记忆 #千寻 #补充 #KVCache #PromptCache #DeepSeek #ClaudeCode #缓存