AI API 加缓存后为什么费用没降？命中率、失效和日志排查
AI API 接入缓存后仍然成本偏高时，应检查缓存键、上下文变量、过期策略、绕过条件和命中日志。
真实问题：缓存有了但账单没变
不少团队在 AI API 接入后会很快想到缓存：同样的问题、同样的提示词、同样的知识库片段，理论上不应该每次都请求模型。但上线一周后发现费用没有降，甚至排查更难，因为日志里多了一层 cache hit 和 cache miss。这里的关键不是有没有缓存，而是缓存键是否稳定、缓存内容是否可以复用、失效策略是否过度保守。永沃云枢建议把缓存当成模型调用管理的一部分，而不是单独的性能开关。站点入口 https://ai.jn83.com 中的 AI API 接入说明也强调先观察真实请求分布。
适用场景
适合客服常见问答、文档摘要、代码解释、表格字段说明、运营文案初稿等重复度较高的 AI 自动化办公场景；不适合带有用户隐私、实时价格、个人订单、权限差异或强上下文依赖的请求。CCSwitch 配置多模型时也要注意，不同模型、不同 base_url 和不同温度参数的输出不能混用同一个缓存结果。
操作步骤
第一步，给每次开发者 AI 调用记录 trace_id、model、base_url、prompt_version、temperature、业务场景、缓存键和 hit/miss。第二步，设计缓存键时只放真正影响输出的字段，例如模板版本、知识库文档版本、问题标准化文本和模型名，不要把时间戳、随机请求 ID、前端埋点放进去。第三步，先用最近 1000 条日志离线模拟命中率，再决定是否上线。第四步，为高风险场景设置 bypass 条件，例如包含个人姓名、订单号、金额、合同编号时不走共享缓存。第五步，上线后按小时看命中率、平均延迟、模型请求量和人工复核失败率，不能只看费用。
排错路径
如果命中率低于预期，先抽 20 条语义相近的请求，比较缓存键差异，常见原因是空格、标点、日期和用户 ID 被写进 key。若命中率高但投诉增加，说明缓存了不该复用的内容，要检查权限、地区、版本和知识库更新时间。若日志里 miss 原因为空，说明观测字段不够，先补日志再优化。若缓存命中后仍调用模型，可能是代码里先请求模型再写缓存，或流式输出链路绕过了缓存判断。
常见问题 / 避坑
问：可以把所有 prompt 和回答都缓存吗？答：不建议，涉及个人数据、临时业务状态和权限差异的请求容易出错。问：缓存时间越长越省钱吗？答：不一定，文档版本和政策变化会让旧回答过期。问：缓存命中是否等于质量可靠？答：不是，命中只说明复用了旧结果，仍要抽样复核。
检查清单
检查缓存键是否包含模型名、提示词版本、知识库版本和标准化问题。检查日志是否能区分 hit、miss、bypass、expired 和 error。检查 AI API 接入层是否记录费用估算和响应耗时。检查 Codex 接入生成的文档是否说明缓存适用边界。检查上线后是否保留一键关闭缓存或按场景降级的开关。
验收示例：不要只看缓存命中率
上线缓存后的第一天，可以把请求分成三组看。第一组是稳定命中的高频问题，例如产品说明、固定流程、常见错误码解释；第二组是主动绕过的问题，例如带订单号、手机号、合同编号、价格和权限差异的请求；第三组是异常未命中的问题，例如问题文本很像但缓存键完全不同。每组各抽 20 条，检查模型调用次数、回答是否复用正确、人工复核是否发现过期内容。只有当命中率提升、延迟下降、费用下降和质量没有明显变差同时成立，缓存才算真的产生价值。
日志字段建议
日志至少要保留 trace_id、user_scene、model、prompt_version、knowledge_version、cache_key_hash、cache_status、bypass_reason、input_token_estimate、output_token_estimate 和 latency_ms。不要把完整敏感输入长期写进日志，但可以保存脱敏后的标准化问题，方便判断同义问题是否被拆成多个 key。对开发者 AI 调用来说，这些字段还能帮助区分是 AI API 接入层的问题，还是 CCSwitch 配置、代理、模型名和业务代码的问题。永沃云枢的站内文章会把缓存看作成本控制的一部分，而不是承诺费用一定下降的营销开关。
还有一个容易漏掉的细节是缓存预热。新版本提示词发布后，旧缓存不一定还能复用，可以先用固定样本预热少量常见问题，再逐步放量。若一上线就清空所有缓存，短时间内费用和延迟反而会上升，排查时要把这段波动单独标记。