缓存标称2M，实测留下3M token

作者用两台 DGX Spark 部署 vLLM 推理服务。模型是 DeepSeek v4 Flash 0731。处理缓存管理那几天，他一直觉得结果不对劲，于是写了个工具验证。

工具叫 cache-pressure，做法直截了当：塞入一批上下文，再逐一检查缓存命中。看哪些内容被保留、哪些被挤掉。

工具分三步：先跑一个探测，校准预期的命中率与未命中率。接着填充一批长度固定的上下文。最后按相反顺序做命中验证，从最新填充的往回查。它有一个明确假设：最近的上下文应该尽可能被保留。反向验证能最快看出最新内容有没有被提前驱逐。

第一次测试用 80 个上下文，retention 设为 4096。广告容量约 202 万 token。实际只留下 27 个上下文、约 105 万 token，占广告容量的 51.98%。最早被驱逐的是第 52 号上下文。接近一半的广告容量没被用上。

作者改了 vLLM 的缓存逻辑，把 retention 设为 0，再跑同一套测试。这次 80 个上下文留下 77 个，约 300 万 token，占广告容量的 146.56%。最早被驱逐的是第 2 号上下文。换句话说，引擎宣传的 2M 缓存实际能留下 3M token——广告容量那个数字本身就不准。

工具用起来不麻烦。克隆仓库、装依赖，然后跑一个 python 脚本，指定推理服务器的 base-url 和宣传的缓存大小。有个明显提醒：它会驱逐当前缓存里所有上下文，别和真实工作负载同时跑。

作者说，这工具给两类人用：需要验证部署或比较推理引擎的人，还有推理引擎维护者。他把工具跑在 vLLM、ninfer、llama.cpp 和 SGLang 上。vLLM 表现良好，其他引擎需要更合适的配置。

cache-pressure 和缓存修复代码都开源，分放在两个 GitHub 仓库。作者注明：帖子文字由人工撰写，仓库代码由 AI 生成，在他的指导和审阅下完成。

评论区补了两个更细的测试方向。一个建议是，工具按上下文逐条输出记录：上下文 ID、token 数、前缀哈希、插入顺序、命中或未命中、后端、驱逐原因。否则整体保留率可能因为探测本身改变了缓存状态而虚高。另一个建议加前缀稳定性测试。预热一个上下文后，分别在靠近开头和靠近结尾的位置改一个 token，然后对比改后与完全重放时的复用 token 数和预填充延迟。前缀缓存里，靠前的修改会从改动点起阻断之后的复用，即使原上下文还在缓存中。