前缀缓存如何省掉重复计算
前缀缓存如何省掉重复计算
前缀重复是常态
打开一个 AI 编程助手的会话，系统提示词、工具定义、仓库背景几乎每次都一样；多轮对话里，前文也会原样重发。这些重复前缀如果每次都重新算，预填充阶段的计算量会重复得离谱，GPU 忙着算已经算过的内容，真正的增量反而被排到后面。前缀缓存的做法是：把「从第零个 token 起」的连续前缀对应的 KV Cache 存下来，下次命中就直接复用，跳过这部分预填充，省下的全是实打实的计算。
DeepSeek 的上下文缓存把命中内容放在分布式磁盘阵列上，命中部分单价只有未命中的约十分之一。官方给的例子很直观：一个十二万八千 token 的重复提示，首 token 延迟从十三秒降到五百毫秒，高命中场景下成本能砍掉九成。缓存以六十四 token 为单位存储，前缀不足六十四 token 不缓存，所以真正省下的是那些又长又稳定的公共部分，而非零散的短句。
命中率靠工程，不靠运气
前缀缓存有个硬前提：必须是从开头起字节级一致的连续前缀，中间哪怕改一个字，后面的缓存就全失效。所以成熟的用法都把不变的内容（系统提示、工具 schema、参考文档）钉在最前面，动态内容放到末尾，靠 prompt 结构设计把命中率顶到百分之七十甚至更高，命中率直接决定省了多少钱。
一旦缓存跨请求、跨进程长期驻留内存，它就成了真正的热数据，被成千上万次读取。一个在温升时悄悄劣化的内存条，可能让某段长期命中的前缀缓存开始报错而不被察觉，错误还跟着复用扩散。HeroTEST 提供模块级 DDR5 RDIMM 宽温测试与可信分级，包含余量测试与高温老化，验证模块在真实负载下的行为，欢迎和我们沟通测试细节。