Datadog排查提示缓存失效：四种代码层面的静默陷阱

Datadog的AI应用团队在排查LLM成本时发现一个反直觉的现象：多个内部应用已经启用了提示缓存选项，但实际请求中完全没有缓存命中。每个请求包含超过18万输入token，单次成本在0.74到0.82美元之间，而一旦缓存生效，同样的任务成本可以降到0.02到0.14美元。差距如此之大，却找不到原因。

Staff Engineer Bruno Volpato和团队记录了这次排查的完整过程。他们的方法论是：先用Cloud Cost Management看整体支出，再用Agent Observability追踪到单个模型调用，然后比较同一个任务中第一次调用和后续调用之间的差异。一个agent完成一个任务可能调用模型多次，每次都会重复发送系统指令、工具定义和对话历史。如果缓存正常工作，后续调用应该从缓存读取这些重复内容。

排查揭示了四类静默失效模式。第一类是易变内容混入了可复用前缀。一个聊天服务把系统指令和当前时间、组织信息、功能开关、事件上下文拼在一起。提示缓存依赖请求前缀的逐字节匹配——如果时间戳出现在指令前面，哪怕后面的指令完全相同，缓存也无法命中。他们的修复方案是把稳定指令放在前面，请求特定的细节放在后面，在支持的情况下用缓存边界标记可复用部分的结束。

第二类是工具列表的非确定性顺序。那个聊天服务用Go语言构建工具列表，而Go的map遍历不保证顺序。一次请求可能按A、B、C排列工具，下一次变成B、A、C。工具描述属于缓存前缀的一部分，顺序一变，整个前缀就不匹配了。补丁很简单：在构建列表前按名称排序。团队还加了一个测试，把相同的工具以不同顺序放入map，验证生成的列表一致。

第三类是缓存选项没有传递到实际请求。一个应用启用了名为WithPromptCaching的选项，但检查发往Anthropic的请求后发现，这个选项只添加了一个beta header，请求体中缺少告诉provider缓存什么的控制参数。另一个应用更直接：SDK的缓存选项根本没有传递到准备provider请求的组件。

第四类是API路由不支持缓存。Datadog的网关可以走Anthropic的原生Messages API，也可以走兼容OpenAI格式的请求端点。原生路由有缓存读取，兼容路由完全没有。Anthropic的文档确认兼容端点不支持提示缓存。把应用迁移到原生API成为可能的修复路径，但团队在推荐之前还需要验证消息角色、工具调用和流式响应在新路由下是否正常工作。

Volpato在文章中强调了一个排查陷阱：不能只看聚合的缓存命中率。他们发现应用和网关可能同时记录同一个模型调用，导致成本被重复计算；反过来，如果记录缺少缓存字段，缓存看起来就像从未使用。有些记录省略了系统指令或工具定义，让人无法判断provider为什么没有复用之前的输入。在评估修复机会时，团队还指出一个容易被忽略的成本维度：某些provider对缓存写入收取额外费用，如果反复写入很少被复用的内容，成本反而可能上升。

这篇文章的价值不在于它发现了某个全新的缓存原理——前缀匹配和工具顺序一致性这些机制本身并非新发现。它的贡献在于展示了一次真实的排查过程：从聚合成本异常出发，逐步缩小到单个请求级别的差异，最终定位到四类具体的代码层面原因。对于正在运行LLM应用但缓存效果不理想的团队，这个排查路径和这四类模式本身比任何通用原则都更直接可用。