缓存命中与压缩的实测画像

编写于 2026-10-16

结论先列在这里，口径与限制在下面。

1. 全期缓存命中率 97.3%，分子 3,831,076,279 token，分母 3,938,799,621 token。
2. 命中率不是被少数长会话拉起来的：91.9% 的单次调用其命中率本身就不低于 90%，其中 55.6% 不低于 99%。
3. micro-compact 很少见：窗口内只有 71 次，平均压缩幅度 7.05%，估算节省合计只占全期输入 token 的 0.021%。
4. 未观察到压缩导致命中率崩塌：压缩后 60 秒内的命中率与从未压缩过的窗口相差 2.3 个百分点，且不呈单调关系。
5. 无法给出金额结论：数据里没有缓存写入量与定价信息。

数据底稿与口径

1. 来源：本机遥测库，只读打开，未写入、未修改任何记录。
2. 范围：一个主数据集（单机环境），214,394 条观测、44,327 条模型调用记录、2,241 条 trace、1,138 个会话。
3. 窗口：2026-08-01 至 2026-08-28，其中 21 天有数据。
4. token 完整率 100%：44,327 条模型调用记录全部带 token 明细，缓存类结论不受字段缺口影响。
5. 缓存可用样本 42,859 条（占 96.7%）：排除了输入为 0 或缺少缓存字段的记录。
6. 剔除项：另一个 project 只有 85 条观测，样本量过小，整体排除。

命中率的分母必须写清楚。本文采用的口径是：

命中率 = 缓存读取 token / 输入 token（input 为含缓存的毛输入）

这个口径有四条互相独立的依据：实现里命中率的分母就是输入 token；44,327 条记录中没有任何一条出现「输入小于缓存读取」；总量满足「输入加输出等于总量」；本机记录与服务端聚合给出的命中率一致。

如果换成分母为「缓存读取加输入」的算法，全期结果会从 97.3% 变成 49.3%，与本机自身记录（触发时命中率均值 0.9455）和服务端聚合（97.2%）同时矛盾。这是本文唯一需要读者留意的口径陷阱。

缓存命中率 97.3%

调用级别的分布说明这不是均值效应。

1. 每五次调用里，有将近三次的命中率在 99% 以上。
2. 低于 50% 的调用只有 1.8%，且没有任何一条调用命中率低于 1%。
3. 按模型看，有足够样本的七个模型都落在 88.7% 到 97.6% 之间：deepseek-v4-flash 97.6%（31,975 次）、peri-sonnet 97.5%（4,510 次）、gpt-5.6-sol 94.9%（2,892 次）、deepseek-v4-pro 97.4%（2,101 次）、mimo-v2.5 92.7%（1,368 次）、gpt-5.6-terra 93.6%（677 次）、peri-opus 88.7%（216 次）。
4. 样本少于 500 次的模型（gpt-5.6-luna 456 次、gpt-4o 23 次、peri-fable 2 次）缺少可比的缓存字段或样本太少，不纳入比较。

逐日波动

1. 逐日命中率最低是 91.6%（2026-08-25，886 次调用）。
2. 逐日命中率最高是 98.9%（2026-08-08，836 次调用）。
3. 多数日子集中在 95% 到 98% 之间。
4. 命中率的日间分布与输入字段埋点缺口、与压缩策略切换没有观察到耦合。

需要说明的是，低值日正好也是样本量最小的几天之一（8-25 的 886 次、8-24 的 375 次、8-28 的 254 次），样本越小的日子越容易偏离整体水平。这里只做描述，不做因果归因。

compact 很少见，幅度也不大

1. 统计期内共 71 次 micro-compact，全部由自动触发。
2. 平均压缩前规模 166,882 token，压缩后 155,124 token，平均估算节省 11,758 token，相对降幅 7.05%。
3. 71 次压缩的估算节省合计 834,823 token，只相当于全期输入 token 的 0.021%。
4. 单次节省的最小值为 0，最大值为 114,896 token（估算），差异很大。
5. 其中 57 次（80.3%）就地完成，14 次（19.7%）升级为更大范围的压缩；升级原因里 13 次是阈值超出，1 次是回收不足。
6. 统计期内没有一次压缩失败。
7. 平均耗时 31,146 毫秒（约 31 秒），这个耗时不可忽略。
8. micro_cleared 字段在 71 次记录里全部为 0：这是一条观察，成因在数据中没有找到证据，不能读成正常或异常。

上述节省数字全部来自带 estimated_ 前缀的估算字段，必须按估算对待，不能当作实际节省。

compact 与缓存的关系

1. 触发时缓存几乎总是热的：94.4% 的压缩发生在命中率不低于 0.9 时，74.6% 发生在不低于 0.99 时，触发时命中率均值 0.9455。
2. 四组极差只有 0.0226（2.3 个百分点），且不呈单调关系：60 秒内最低，1 到 10 分钟反而最高。
3. 结论限定在「未见崩塌」：2.3 个百分点无法排除会话难度、任务类型、时间分布等混杂因素，这是推断而不是机制事实。
4. 要做因果结论，需要同一会话内的对照，本数据不具备该条件。

交叉验证

1. 自下而上与服务端聚合对齐：由观测明细汇总的输出 token 合计 27,572,028，与服务端聚合值完全相等。
2. 输入侧相差 30,000 token，相对差 0.0008%，属可接受范围。
3. 两个口径的命中率互相验证：明细侧 97.3%，服务端侧 97.2%。

替代解释

1. 工作负载本身高度重叠：这份数据来自工具密集型、多轮迭代的长会话环境，上下文天然重叠，命中率高是这种负载的正常结果。
2. 窗口是历史数据：2026 年 8 月的记录，当前版本行为可能已经变化。
3. 少量大 day 主导总量：8-11 单日 8,273 次调用，占总量的近两成，全期命中率受大样本日影响明显。

诚实边界

1. 不能给金额结论：缓存写入量字段在全部 44,327 条记录中都不存在，也没有定价信息，因此无法计算费用节省或净收益。
2. 不能把估算当实际：所有压缩节省数字都带「估算」二字，来源是自述为估算的字段。
3. 不能比较 8-15 前后：该日前后的压缩记录命名口径不同，且此前记录缺少必要字段，任何「压缩变多或变少」的说法都不成立。
4. 不能跨 8-18 至 8-23 做前后对比：这连续六天完全没有数据。
5. 不能用 8-08 至 8-14 做提示词组成分析：该窗口的输入字段完整率为 0%。
6. 不能代表全部用户：这是单机单人的环境（3 个 user_id、1 个主 project），样本严重偏向这台机器的工作负载。
7. 不能把统计期内的观察外推到其他用法：以短对话为主的用法，命中率很可能显著不同。

局限

1. 有效窗口只有 21 天，且是采集时点约四个月前的历史数据。
2. 压缩样本仅 71 次，分布在 6 个不连续的日子，任何分组都会落到个位数量级，统计功效不足。
3. 压缩缺少「未触发」对照组，无法回答「如果不压缩会怎样」。
4. 5.63% 的观测存在父链断裂，不影响 token 与缓存字段，但影响一切依赖父子关系的分析。
5. 有个别分组（例如压缩时命中率为 0 的记录）样本极少，本文未对其单独下结论。

复核方式

1. 所有数字来自只读查询，未做估算与补齐。
2. 关键口径已交叉验证：明细汇总与服务端聚合、命中率与触发时记录三方吻合。
3. 命中率的两个分母算法都列出过数值，读者可用自己的数据复算并比对。

继续阅读工具 token 消耗与超长会话统计画像。