同样是去掉一个工具定义GPT-5.5 会把整段 prompt cache 全部打失效而 GPT-5.2 还能继续命中缓存。这个差异听起来只是模型版本行为不同但如果你在线上用 API 做 function calling它直接影响三件事单次请求的输入成本、首字延迟以及排查问题时会不会被误导。这篇文章就围绕这个现象展开先说 prompt cache 到底缓存了什么再对比两个版本的实际差异然后给出一套可复现的验证方法最后聊生产环境里怎么减少缓存被打穿带来的损失。适合正在用 GPT 系列接口做工具调用、批处理或智能体开发的工程师。1. 一个工具从列表里消失为什么会让整段缓存失效1.1 缓存的最小单位是“请求前缀”不是“模型记忆”要理解这个现象先得把 prompt cache 的工作方式说清楚。Prompt cache 并不是模型在记住你上次说过什么而是服务端把请求里的 token 前缀做过一次预处理下次遇到相同前缀时直接复用结果。复用的意思是省掉了重复的 prefill 计算既降低输入成本也缩短首字延迟。所以缓存命中的前提是新请求和旧请求的前缀在 token 级别完全一致。注意这里的“完全一致”非常严格不是语义相同就行。只要中间有一个 token 变了缓存就从变化点开始全部失效后面所有的内容都要重新计算。在 chat completions 请求里这个前缀通常由以下内容拼成system prompt历史对话消息工具列表也就是 tools 或 functions 的 JSON 结构当前轮次的用户消息不同模型的拼接顺序可能不完全一样但工具列表基本都会出现在请求体中。它的体量还不小如果工具数量多、描述长、参数多这部分可能占到几千甚至上万 token。1.2 工具定义是标准的“缓存敏感区域”工具列表之所以特别容易击穿缓存是因为它的结构非常容易被改动。你只是去掉一个参数或者给某个工具的 description 加了一个逗号都会改变序列化后的文本进而改变 token 序列。更隐蔽的是工具列表通常放在 system prompt 和用户消息之间。一旦这个中间区域发生变化它后面的所有内容包括聊天历史、当前用户问题、其他工具定义全部一起失效。这就是为什么“只是少了一个工具”整段缓存却保不住。如果你把一个工具列出来再仔细对比 5.2 和 5.5 的两次返回会发现 5.5 在工具变更后缓存读取直接归零输入 token 几乎全部按未命中计费而 5.2 在某些情况下仍然能看到部分缓存命中。这不是玄学是缓存策略不同。2. GPT-5.2 和 GPT-5.5 的缓存行为差异实测时怎么对齐2.1 先把我观察到的现象固定成一张对比表这里说的现象来自实际线上调用日志和社区里同样在做工具调用的开发者反馈。我把它整理成下面这张表方便你对照自己的测试结果对比项GPT-5.2 的表现GPT-5.5 的表现去掉一个工具后缓存是否继续命中多数场景仍能命中或部分命中常见表现为整段失效缓存读取归零缓存创建 token 是否激增变化不明显明显上升相当于重新 prefill 一次首字延迟基本稳定明显变长特别在工具定义很长时对线上成本的影响容易被忽略一旦工具变更频繁成本立刻上涨工具顺序变化有时不敏感更敏感哪怕只是位置调整也可能失效这个表格是基于我目前能观察到的行为总结不是官方承诺。模型版本还在迭代同一个版本的缓存逻辑也可能调整所以你在自己环境里跑出来的结果可能有偏差。关键是掌握验证方法而不是死记这个结论。2.2 为什么 5.5 会更严格官方文档没有给出完整的缓存 key 设计说明但从行为上可以推测5.5 对工具部分的处理更“一体化”。它可能把工具定义、甚至工具之间的顺序都纳入了缓存 key 的核心计算范围。工具列表一旦变化整个前缀的哈希就变了缓存只能作废。5.2 更宽松可能是因为它用的是更大粒度的分段缓存或者对工具序列化做了某种归一化处理。比如忽略字段顺序、忽略某些不影响语义的空格或属性这使得“去掉一个工具”之后仍然有一部分前缀能对上。但这不意味着 5.2 更先进反而更危险。缓存命中容易被误读成“这个改法成本很低”实际上只是当前版本的宽容掩盖了问题。一旦模型升级工具变更带来的成本和延迟都会暴出来。2.3 对比测试时最容易犯的错我在做对比时提醒自己一件事两个版本要放在完全相同的请求体下测试否则结论没有意义。具体来说以下变量都要固定system prompt 完全一致同一段历史消息同样的工具数量、顺序、内容同样的当前轮用户输入同一套接口参数比如 max_tokens、temperature同一个账号资源池避免组织级限流干扰如果只换模型版本其他都保持一致得到的差异才能归因到模型或缓存策略上。否则你很难说清楚是缓存击穿还是网络波动或者是负载变化。3. 三步验证工具变更有没有打穿缓存3.1 第一步跑一次稳定基线不要一上来就去测工具变更先建立基线。选一个固定的请求比如一个 system prompt 加 8 个工具加 5 轮对话连续调用同一模型 5 次观察返回里的缓存相关字段。不同接口版本的字段名不太一样常见的有prompt_tokens_details.cached_tokenscache_read_input_tokenscache_creation_input_tokenscache_read_input_tokens 表示本次命中了多少缓存cache_creation_input_tokens 表示本次创建了多少缓存。稳定基线情况下cache_read 应该稳定在一个数值附近cache_creation 基本为 0 或不增长。我用 Python SDK 打印这部分信息的简化写法类似下面这样resp client.chat.completions.create( modelgpt-5.5-..., messagesmessages, toolstools, ) u resp.usage print(prompt_tokens:, u.prompt_tokens) print(details:, u.prompt_tokens_details) print(cache_read:, getattr(u, cache_read_input_tokens, None)) print(cache_creation:, getattr(u, cache_creation_input_tokens, None))注意如果你的 SDK 版本不支持某些字段先检查 SDK 和接口版本不要在字段判断上卡太久。3.2 第二步制造一次“去掉一个工具”的变更基线确认没问题后把工具列表复制一份去掉其中一个工具。建议去掉一个影响面最小的工具比如只用于测试的 echo 工具不要直接删生产里真正在用的核心工具。保持其他所有内容不变发起一次新请求。这次请求要做两件事记录返回里的缓存字段记录首字延迟如果你的模型在请求里返回 usage直接从 response 里拿。如果走的是流式输出注意流式接口可能在多个 chunk 里携带 usage需要你手动拼接或单独读最后一个 chunk。3.3 第三步对比指标判断是否击穿判断标准很简单我一般看三个地方指标命中正常被击穿cache_read_input_tokens和基线接近明显下降甚至归零cache_creation_input_tokens基本不涨明显上涨首字延迟稳定明显变长另外一个容易被忽略的步骤把工具去掉之后再把工具加回来继续发同样请求观察缓存能否恢复到命中状态。如果能恢复说明击穿是临时的下次同前缀请求会重新建立缓存。如果不能恢复就要检查是不是工具列表里的其他内容发生了非预期变化比如自动排序、时间戳或随机 ID。4. 缓存友好的工具定义应该怎么组织4.1 工具列表要“稳定优先”不是“灵活优先”很多人做 function calling 时喜欢根据用户输入动态挑选工具比如用户问天气就只传天气工具用户查订单就只传订单工具。这在单次效果上没问题但对 prompt cache 是灾难。因为每次请求的工具列表都不一样等于每次都在创建新缓存永远没有命中。更好的做法是把工具集分成几个固定的“通道”每个通道包含一组稳定工具整个请求始终使用同一个固定工具列表。用户需要哪些能力通过 system prompt 里的说明来区分而不是通过增删工具来区分。如果你确实需要为不同用户提供不同工具可以在业务层做路由用户 A 走工具集 A用户 B 走工具集 B但每个用户在连续请求之间保持工具集不变。这样既能满足差异化又能让同一用户的请求尽量命中缓存。4.2 把动态内容挪到不影响缓存的位置请求前缀中的任何变化都会影响后续所有 token。如果你在 system prompt 里插入当前时间、用户 ID、业务上下文这些内容一旦变化后面的工具定义和历史消息都跟着失效。处理办法是把稳定内容放前面把动态内容放最后。比如固定 system prompt固定工具列表动态用户信息、时间信息、临时上下文当前轮的用户输入如果你发现某些动态字段在 service 层已经被塞进了 system prompt建议改成放在 messages 数组的最后一段或者作为当前轮次的附加内容传递。这样前端的工具定义和历史消息仍然可以命中缓存。4.3 工具描述和参数结构也要当配置来管理工具的 name、description、parameters 都属于缓存 key 的一部分。很多人会频繁优化描述文案比如为了提升模型调用准确率在 description 里加“请只在用户明确要求时调用”这类话。每改一次就是一个新的工具列表。所以我的建议是把工具 schema 的变更当成一次正式发布。积累一批改动统一上线而不是每改一句话就发一次。上线前后跑一遍缓存命中对比确认没有异常后再切换流量。如果团队里有多个人都在维护工具定义建议约定字段顺序固定。JSON 序列化工具可能会自动排序也可能不排序不同客户端行为不一样。最好在发送请求前用一个稳定的序列化逻辑避免同样的工具因为字段顺序不同导致缓存对不上。5. 容易误判的三个问题和排查顺序5.1 “模型变聪明/变笨了”可能只是缓存状态变了很多人感觉“GPT-5.5 怎么变卡了”第一反应是模型降智。其实更常见的原因是缓存失效。工具列表变更、并发升高、接口区域负载变化都可能让首字延迟变长。感知到“变慢”或“回答质量波动”并不等于模型本身发生变化。排查时我建议先看响应里的 usage 和延迟分布再下结论。如果 cache_read 掉到 0大概率是缓存击穿如果 cache_read 正常但延迟还是高才需要往网络、限流和模型负载方向查。5.2 tool_calls 相关报错和缓存击穿不是一回事在工具调用场景里有一个经典报错“an assistant message with tool_calls must be followed by tool messages”。这个报错和我们讨论的缓存击穿完全是两个问题。它说的是历史消息结构不合法assistant 返回了 tool_calls但你下一次请求里没有把对应的 tool 消息补上。这个报错经常出现在你“去掉一个工具”之后。因为你删了工具定义但没有清理历史消息里旧的 tool_calls 和 tool 消息导致请求体里的消息序列断裂。结果就是既没有缓存命中又报消息结构错误。看起来是缓存问题实际上是个数据清洗问题。所以当你决定去掉某个工具时要连带检查历史消息里是否还有这个工具产生的调用记录。要么一起清理要么保留工具定义只标记为不可用不要只删 tools 数组里的内容。5.3 排查顺序从请求体往前推不要先怀疑模型我一般按这个顺序排查工具变更后的异常看返回字段cache_read、cache_creation、prompt_tokens确认缓存状态对比两次请求体diff 一遍 tools 数组包括顺序、字段、空格检查历史消息是否存在旧 tool_calls是否缺少对应 tool 消息检查序列化层客户端有没有自动加字段比如加了额外参数或随机标识检查代理和日志请求是否经过中间层中间层有没有改写 body最后才看版本和模型侧逻辑这个顺序能覆盖绝大多数“工具变更导致缓存失效或调用异常”的场景。如果顺序反过来先怀疑模型很容易在错误的方向上浪费时间。6. 线上业务对待工具变更的正确姿势6.1 把缓存命中率变成监控指标如果你的业务每天有几千次带工具的请求建议把 cache_read_input_tokens 和 cache_creation_input_tokens 采集到监控系统里按模型、按工具集版本、按接口维度分别统计。不用做太复杂先看趋势。正常情况下cache_read 应该占总 prompt 输入的大部分cache_creation 只在首次请求或更新版本时出现尖峰。如果发现 cache_creation 持续高位说明你的请求前缀一直在变要么是工具列表不稳定要么是 system prompt 里有动态内容要么是请求没有走同一条稳定链路。6.2 工具升级时先把流量切到新工具集再关旧工具线上切换工具定义时不要同时删旧工具和加新工具。更稳妥的顺序是新工具集先上线但保留旧工具定义让少量流量先用新工具集观察缓存命中和调用准确率确认稳定后再把旧工具移除移除后再次观察缓存命中确认没有异常这样做的好处是即使新工具集有问题你随时可以回滚到旧工具集。而且切换过程中缓存重建的尖峰成本是可预期的不会因为频繁变更让账单波动。6.3 对模型版本升级保持警惕不要混用结论在 5.2 上验证过“去掉一个工具不影响缓存”不代表 5.5 上也一样。缓存策略会随模型版本升级而变化甚至同一规模的不同部署都可能不同。如果你同时在用多个模型版本一定要分别建立基线分别验证。如果团队正在从 5.2 迁移到 5.5我建议把“工具变更时的缓存命中表现”列为迁移验收项之一。很多模型迁移只看回答质量不看成本和延迟结果上线后发现工具更新一次就贵不少。这类问题最后往往不是不能解决而是提前没有纳入评估范围。6.4 个人建议先稳定工具再优化成本和效果回到标题那个现象。5.2 的宽容容易让你产生“工具随便改也没成本”的错觉5.5 的严格反而更像一个提醒prompt cache 的前提是稳定工具定义是 prompt 里最需要稳定的一部分。我个人的工作习惯是这样的先定工具集再写系统提示词工具集变更走发布流程每次变更后跑一次缓存命中对比动态内容放到请求尾部不污染工具前缀线上同时监控 cache_read 和 cache_creation而不是只看总 token遇到“变慢变贵”先查缓存再查工具调用链路如果你现在正被“去掉一个工具缓存就失效”这个问题困扰大概率不是模型 bug而是你的请求前缀设计还不适应新的缓存策略。把工具列表稳定下来把动态内容移出前缀把工具变更当成版本发布来管这个问题基本能控制住。踩过几次之后你会发现真正影响线上稳定性的往往不是单次效果而是那些看不到的缓存命中率。先把工具列表稳定住再谈优化比什么技巧都管用。