我会用冷缓存和热缓存做两次测试
这是一次个人使用后的测试记录。遇到“缓存能省多少”这类问题时，我不会只跑一次请求就下结论，因为第一次和后续请求的输入构成可能完全不同。
下面这条调用记录中，输入总量为 771,144 Token，缓存输入为 770,560 Token，输出为 37 Token。按记录计算，未缓存输入只有 584 Token。这个样本说明了高缓存输入可以存在，但不能证明所有提示词、所有模型或所有时间段都会得到同样结果。
冷缓存和热缓存要分开记
我会用相同的模型、提示词、工具定义和上下文，至少测试两类请求：
| 测试类型 | 我会观察什么 |
|---|---|
| 冷缓存请求 | 初次请求的输入、输出、首字时间和最终费用 |
| 热缓存请求 | 缓存输入是否出现，费用结构和首字时间是否变化 |
如果两次请求的上下文内容、模型或渠道不同，那么即使费用有差异，也很难确定差异来自缓存。
不把“缓存”当作黑盒宣传词
对我来说，缓存是可通过数据验证的变量。它可能受提示词前缀、上下文改动、模型设置和平台规则影响。高缓存样本意味着应该继续测试，而不是可以直接写成“固定折扣”。
为了让测试更容易复盘，我会把模型、请求时间、输入总量、缓存输入、输出、首字、总耗时和最终费用放在一起记录。这样下次缓存没命中时，至少能定位是哪一项条件发生了变化。
统一入口的作用是便于重复比较
当我需要重复切换模型或渠道测试时，更在意能否连续查看调用记录、价格和用量，而不是只看一次返回结果。页面上的模型入口、价格信息和使用数据能让我少做一些来回确认，但结论仍然要建立在自己的真实请求上。
如果你的任务是长文档分析、代码 Agent 或固定系统提示词，这种冷缓存与热缓存的对照测试很值得做。本文是个人测试方法整理，图片和数字仅反映 2026 年 10 月 2 日的样本，实际缓存规则、模型能力、价格和账单以使用时页面为准。
