一、从一个环境变量说起
最近使用Claude Code的同学可能会发现，升级到较新版本（2.1.37+）后，缓存的命中率明显下降，推理速度变慢，Token消耗也增加了。如果你查看源码或相关讨论，会注意到一个环境变量：CLAUDE_CODE_ATTRIBUTION_HEADER="0"。把它设置之后，缓存就恢复正常了。
这个变量是做什么的？为什么一个简单的设置能影响缓存？这要从Claude Code系统提示词的设计说起。
二、随机归属头如何破坏缓存
Claude Code在每次请求API时，会在系统提示词（System Message）的最前面插入一段归属信息，里面包含一个动态生成的哈希值。这个哈希值每次请求都不同，比如：
text
请求1：[random_hash_abc123] + 系统提示词 + 用户输入
请求2：[random_hash_def456] + 系统提示词 + 用户输入从API服务端的视角看，这两次请求的Prompt前缀完全不同。而提示词缓存的前置条件是前缀逐字节一致------哪怕多一个空格都会判定为不匹配。所以每次请求都被当作全新的Prompt来处理，缓存完全失效。
设置CLAUDE_CODE_ATTRIBUTION_HEADER="0"后，Claude Code不再注入这段随机哈希，系统提示词恢复为固定内容，后续请求的前缀与第一次一致，缓存命中率恢复正常。
这个机制本身是Anthropic用来追踪API使用来源的，但对频繁调用的开发者来说，代价就是缓存失效。
三、提示词缓存的工作原理
大模型推理分两个阶段：Prefill和Decode。
Prefill阶段，模型需要"理解"输入的全部内容，对所有输入Token做一次完整的正向计算，生成对应的KV（Key-Value）状态。这部分计算量大，与输入长度成正比。
Decode阶段，模型逐Token生成输出，每个新Token只需要与已有的KV状态做注意力计算。
提示词缓存的思路是：既然系统提示词通常固定不变（比如"你是一个编程助手，请用中文回答..."），那第一次请求处理完系统提示词后，把它的KV状态保存起来。第二个请求来的时候，如果发现前缀（系统提示词部分）完全一样，就直接复用保存好的KV状态，跳过Prefill阶段对这部分的重计算。
这要求缓存系统能够精确匹配前缀。Claude Code的随机归属头恰好让这个条件不成立。
四、KV Cache与提示词缓存的关系
这两个概念容易混淆，但层次不同：
KV Cache是单次请求内部的优化。模型在生成第n个Token时，前n-1个Token的Key和Value向量已经算过了，存在GPU显存里。第n个Token只需要算自己的Query向量，跟存好的KV做注意力计算，不用重算前面的。这是Transformer推理的基础机制，每次请求都会用到，作用域在单个请求内。
提示词缓存可以理解为KV Cache在多次请求之间的复用。它把某个请求计算好的KV状态持久化保存，供后续共享相同前缀的请求使用。提示词缓存依赖KV Cache机制，但作用范围跨请求。
简单说：KV Cache让同一请求内生成不重算，提示词缓存让不同请求的相同部分不重算。
五、DeepSeek缓存的优势
DeepSeek的缓存策略有几个关键点：
第一，硬盘持久化缓存。 DeepSeek的上下文缓存是基于硬盘的，而非仅依赖内存。文档明确说明缓存写入磁盘，默认对所有用户开启。这带来两个好处：容量远超内存限制；请求结束后缓存不会立即消失，后续请求依然能命中。
第二，较长的缓存保留时间。 很多国外厂商的缓存只保留几分钟，且仅在内存中。内存受容量限制，加上并发请求的竞争，缓存很快被清除。DeepSeek的硬盘缓存在数小时甚至更长时间内依然有效。
第三，多层落盘策略。 DeepSeek的缓存有不同触发条件：请求正常结束时落盘；系统检测到多个请求有共同前缀时主动落盘；长文本按固定间隔落盘。这些策略提高了缓存的覆盖率和持久性。
第四，明确的计费支持。 DeepSeek对缓存命中的Token有显著的计费优惠，用户能直观看到成本下降。这让缓存从"技术优化"变成了"成本优化"，用户有动力去维护前缀的一致性。
数据上也能印证：DeepSeek官方曾披露，在某时间段内，所有输入Token中有超过一半命中了硬盘缓存。这个比例远高于仅依赖内存缓存的方案。
六、中转站的缓存差异
如果你通过API中转站（代理服务）使用大模型，缓存能不能生效还取决于中转站的处理方式。
做得好的中转站会处理请求中的随机归属头等干扰信息，确保发给后端API的Prompt前缀保持一致，让缓存正常生效。
做得差的中转站直接透传客户端的原始请求。Claude Code加上随机头之后，中转站不处理就直接转发，每次前缀都不同，后端缓存完全无法命中。用户不仅没享受到缓存带来的加速，Token成本也没有降低。
还有一种情况是账号轮询。有些中转站会把同一用户的请求分配到不同的API账号，而缓存通常与账号绑定。换账号意味着换缓存空间，上一轮的缓存直接失效。
结果是用户按全价Token计费，中转站可能按缓存命中后的低价向API厂商结算，差价成为中转站的利润。而用户却没有得到相应的速度提升和成本优化。
七、小结
大模型API的缓存机制看似简单，实际受到客户端行为、服务端策略、中转站处理等多个环节的影响。对于开发者来说，了解这些细节有助于更好地利用缓存，降低推理成本，提升响应速度。
如果你在使用Claude Code，可以检查CLAUDE_CODE_ATTRIBUTION_HEADER的设置。如果通过中转站使用API，可以关注一下服务商对缓存的处理策略，看看前缀一致性和缓存命中率是否得到保障。