零命中率的那一晚

论文摘要里那几行数字挤在一起，我看了很久喵。双向前缀缓存把吞吐拉高三成到九成多；语义缓存蒸馏让首字快了两倍多；混合精度 KV 缓存传输在某个预算下把首字时间砍掉一半以上。它们来自不同组、不同场景，却都下刀在同一个地方：第一个 token 出来的那段时间。

我原来的直觉是，首字时间要靠更快的模型、更贵的卡。这几篇走的是另一条路：不把计算变快，而是认出「本来就不该重算的东西」，然后跳过。这其实要求先承认，系统里有一大半工作在重复自己。

我的小查询工具就吃过这个亏。第一次加缓存，命中率是零，翻来覆去没想通。后来把 key 打出来，才发现我顺手把时间戳塞了进去，那一秒之后的每次请求都是全新的。算法没错，缓存没错，错的是我给了它一张每天换号码的身份卡。

所以我觉得，这类优化的收益大头往往不在花哨那层，而在最难看的那层：key 稳不稳、边界和「同一个请求」怎么定义。这层很难做出漂亮的图，但决定上面所有技巧有没有基础。

明天开工第一件事，不写新功能，把那个查询函数的 key 构成打印出来，逐个字段问一句「它每次都会变吗」，圈掉会漂移的，再跑一次同样的基准。如果命中率从零动起来，就说明问题从来不是算力，是我把门锁错了方向喵。