验证本地 LLM 宣称的 KV 缓存能否承受真实压力；精确观察旧上下文如何被逐出缓存

你好，我对本地大模型的缓存管理有些执念。过去几天，我一直在使用 2x DGX Spark 和 DeepSeek v4 Flash 0731 研究 vLLM 的缓存管理。我感觉有些不对劲，于是展开调查，发现了问题并修复，但需要一种方法来验证修复效果。这促使我创建了一个工具，它通过一套简单协议帮你精确定位缓存管理在部署环境中的实际表现： 运行探测，校准预期（在你的环境中怎样算缓存命中、怎样算缓存未命中） 填充 X 个稳定的上下文，每个 Y 个 token，以完全占满缓存 按相反顺序执行缓存命中验证（最后添加的最先验证），直到出现缓存未命中 最好单独运行此工具以获得真实数值。请注意，这会逐出你当前所有的缓存上下文，因此不要与实际工作同时运行。 我的测试结果 这是我 A/B 测试的结果，对照组（我之前的生产环境）对比修复后的生产环境。 aidendle94/sparkrun-vllm-ds4-gb10:production-3.7-reffix-schedfix（修复前镜像，retention 4096）： ── 压力下的缓存保留情况 ── capacity: 2,023,924 tokens retained contexts: 27/80 retained tokens: 1,052,025 retained % capacity: 51.98% oldest evicted: context #52（更早的上下文已被逐出） 应用 dedupe + boundfix 补丁后（retention 0）： ── 压力下的缓存保留情况 ── capacity: 2,047,043 tokens retained contexts: 77/80 retained tokens: 3,000,048 retained % capacity: 146.56% oldest evicted: context #2（更早的上下文已被逐出） 这对你有什么意义 这能让你精确知道缓存实际能容纳多少 token。对大多数人来说，缓存管理是个黑盒；这个工具能让你获得真实情况（ground truth）。 没错，经过我的修复，宣传中的 2M 缓存实际转化为了 3M 的保留 token。如果你怀疑这个说法，可以审阅代码，全部是开源的：cache-pressure（以及我的 ds4 前缀缓存修复：ds4-prefix-cache-fixes）。 推理引擎自身宣传的数字是错误的，而这个工具能找到真实数值。 这个工具适用于： 1. 需要验证部署环境或对比不同推理引擎的用户； 2. 推理引擎维护者，用于辅助验证缓存管理相关的改动。 不过它基于一个重要假设：应尽可能保留最新的上下文。 我在测试该工具时注意到的情况是：vLLM 表现不错，其他引擎需要更好的配置。我主要使用 vLLM，因此花了大量时间调整配置以获得最佳效果；对于其他引擎，你需要自行判断上述假设是否符合你的需求（在我看来这显然应该是符合的，但我当然不知道你们的具体需求），以及如何通过配置你的推理引擎来实现这一点。 如何启动 1. 克隆仓库 git clone https://github.com/co-l/cache-pressure 2. 安装依赖 pip install -r requirements.txt 3. 运行工具 python3 bench/cache_pressure.py --base-url http://my-server:8000/v1 \ --kv-size <advertised_cache> 我已经在 vLLM、ninfer、llama.cpp 和 SGLang 上测试过；因此你可能需要调整探测逻辑以适配你的环境。 4. 解读结果 ── 压力下的缓存保留情况 ── capacity: 2,023,924 tokens retained contexts: 27/80 retained tokens: 1,052,025 <--- retained % capacity: 51.98% <--- oldest evicted: context #52（更早的上下文已被逐出） 保留 token 数和容量保留率是在压力下抵抗缓存逐出的实测累积值。 注意：这篇帖子 100% 由人工撰写，该仓库 100% 由 AI 在我的指导和审阅下生成。