前缀缓存命中率：字节对齐与工程取舍

DeepSeek 的 KV 前缀缓存命中价格是未命中的十分之一左右。按 v4-flash 的价格算，输入未命中 $0.14/百万 token，命中 $0.0028/百万 token，相差 50 倍。一个跑一整天的编码 Agent，输入 token 大头永远是系统提示词、工具定义和已经发生的对话历史，这些东西每轮几乎一样。所以命中率不是一个优化指标，它基本决定了这个产品能不能被用得起。

但把命中率做上去，跟写好 Prompt 完全不是一个工种。它更像文件系统对齐问题：请求的字节前缀必须和上一轮完全一致，差一个字节就重算。下面结合几份公开的实践记录——QwenPaw 的 issue、Reasonix 的架构说明、百度那篇对比文章——把这件事拆开看。

缓存失效的几个典型现场

agentscope-ai/QwenPaw 仓库里有一条 issue 抱怨缓存命中率只有 95% 左右。发帖人列了三条原因：system prompt 插入了时间、用户信息、随机 ID 这类会话级变量；工具定义注册顺序在运行中变化，序列化结果偏移；多轮对话里 assistant 回复的细微差异打断后续前缀。

维护者的回应有点意思：默认 prompt 里唯一的动态部分是当前时间，而且精确到日期，同一天内不变。换句话说，他们觉得按日期粒度的动态完全可接受。但按天变一次前缀，意味着每天第一轮请求必然全量重算，如果一个 session 持续好几天，这个代价会被反复摊薄不下去。95% 这个数字听着还行——百度那篇文章的实测数据说，命中率从 99.8% 掉到 95%，Token 消耗会涨约 400%。这就是缓存指标的敏感性：它不是线性惩罚，是断崖式的。

更隐蔽的是工具定义序列化。很多框架用 Map 或者对象保存工具，运行时增删一个 skill，key 的枚举顺序变了，序列化出来的 JSON 顺序就变，前缀直接作废。这种 bug 不报错，只是账单变厚。

Reasonix 的四条不变量

博客园那篇关于 DeepSeek-Reasonix 的帖子里给了一个更极端的样本：真实用户单日 4.35 亿输入 token，命中率 99.82%，花费 $1.38，无缓存同等负载约 $61。对应到 v4-flash 的计价，数量级是自洽的，但这是单一用户的单日后台截图，不能当成通用基准来推。

它把上下文划成三块，我认为这是这套东西里最值得抄的部分：

• IMMUTABLE PREFIX：系统提示词 + 工具规格 + few-shot，session 启动时计算一次、哈希并锁定，之后不再动。
• APPEND-ONLY LOG：assistant 消息和工具结果只追加，不重写、不重排、不内联加工。
• VOLATILE SCRATCH：思维链、临时计划这类状态放在另一侧，走单独的提炼环节后才折叠进日志。

上下文快满的时候，不做“重写历史”，而是把旧 turn 摘要成一条新消息，追加到前缀之后。前缀不动，缓存继续命中。这个选择意味着工程上要放弃一些动态性：系统提示词不能带实时状态，工具列表不能热插拔，中间结果不能就地编辑。

那些被交换出去的能力

把前缀冻结，代价是明显的。想按用户画像调整 system prompt？你得接受单独命中率。想在 session 中途加一个 MCP 工具？你得重启会话或者接受一次前缀作废。工具结果不能预处理后放回原位，只能原样追加或者放到描述里引用。

很多 Agent 框架的设计直觉正好相反——为了“灵活”，它们鼓励动态构建 prompt、运行时注册工具、对历史做摘要压缩回写。每一项在功能上都合理，在缓存成本上都自杀。Reasonix 的处理是把动态性显式移到缓存区块之外，比如限制工具结果的长度：超过 3000 token 的结果在 turn 结束自动压到 3000，模型当轮看全文，后续轮次只看到摘要。要恢复细节就再调一次 read_file。多一次工具调用换掉几 KB 的重复前缀，这个交换通常划算。

换到部署侧：vLLM 的 APC 与路由

前缀缓存不只是 API 计费问题。vLLM 的自动前缀缓存（APC）会复用已算过的 KV Cache。阿里云 ACK 的文档里讲了一个路由侧配合方案：估算模式的前缀缓存感知路由，把前缀一致的请求尽量打到同一个 Pod，根据历史流量估计各副本的缓存状况。它明确说明适用于存在大量共享前缀的场景，比如同一份长文档上跑不同问题、或者同一会话里的多轮交互。

一旦落到自建集群，问题就从“别在多轮里改写法”变成容量与负载均衡问题。各副本的缓存内容是黑盒状态，长会话在滚动更新或扩缩容时会被打散；为了命中率而在单个 Pod 上聚流，会带来热点与故障塌方的风险。这类策略有提升空间，但要按实际流量前缀分布来量化试，不能当作总开关。

端侧又是另一种形态。Google ML Kit 文档里给出的 Pixel 9 数据：300 token 固定前缀加 50 token 动态后缀，首次请求 0.82 秒、命中后 0.45 秒；1000 token 前缀加 100 token 动态后缀，从 2.11 秒降到 0.5 秒。这组数字的意义是命中带来的不只是钱，还有首字延迟。功能关掉它就不是成本问题，是交互手感问题。

把命中率当 SLO 盯着

写到这里我的判断是：前缀缓存已经被当成架构约束用了，而多数团队还没把它当成可观测指标。

有效的做法是先做对前缀的血缘测量：把每次请求切成“前缀哈希 + 增量”两部分，按 session 记录前缀命中的占比，失败的样本保留一段前缀快照做 diff。多数人第一次这样做时都会发现，破甲的不是什么深类魔法，而是一个毫秒级时间戳、一处 Redis 返回序不稳定的工具列表，或者一次把历史 message 做排序的去重。

其次是把约束写进代码而不是 wiki：system prompt 模板不允许插会话级变量，工具注册用固定的有序表，日志禁止改写、压缩只做尾部追加。这些规则不加单元测试，没过两个月就会被一个“顺手改一下 prompt”的 commit 打穿。

最后是接受边界。会话首轮必然不命中，命中率到 99.x% 之后每零点几的收益都更难了，长对话滚动压缩会带来新的一轮改写。这些不该掩盖，也不值得用复杂机制去掩盖。缓存工程真正考验的是知道哪些结构性变化该被关进哪个区块，哪些功能灵活性值得为它付出一次全量重算。这个权衡做对之前，那些漂亮数字只需要用几十行代码就能解释清楚。