Rethinking KV Cache Compression：从显存节省回到真实 serving 端到端收益

这篇论文重新测了什么：KIVI、GEAR、H2O 和 StreamingLLM 被放进带 PagedAttention/FlashAttention、tensor parallel 和真实 response length 的 serving 环境。结果说明，KV 压缩需要按请求路由，不适合作为默认开关。

1. 为什么 KV cache 值得压，但“压得小”不等于“服务更快”

自回归 decode 为避免每步重算历史 token，会为每层保存 K/V。论文给出的重负载例子是 LLaMA3-70B：FP16 权重约 130GB，batch 512、prompt length 2048 时 KV cache 可约 512GB，显存占用甚至超过权重。因此大量工作用低 bit quantization 或 token eviction 压 cache，并以 memory reduction、固定输出长度下的 tokens/s 和平均 benchmark score 证明有效。

作者指出三块缺失。第一，许多早期实现基于朴素 Transformers loop；成熟 serving stack 已有 FlashAttention、PagedAttention 与 fused kernels，压缩的相对优势会变化。第二，lossy cache 会改变采样轨迹和 EOS 时刻：每 token 虽快，输出若变成 1.7 倍，E2E latency 仍更长。第三，平均准确率会隐藏少数 catastrophic negative samples，尤其长文 QA、摘要和代码。

2. 四种 baseline 的成本结构

主配置为 KIVI G=32, R=128；GEAR sparsity 2%、rank 2；StreamingLLM/H2O 保留 64 initial/heavy + 448 recent，即 cache size 512。方法覆盖量化和稀疏两类，结论不是某个 kernel 的单点 bug。

3. 论文的评测数据流

1. 先选可信 runtime：比较普通 Transformers、FlashAttention、LMDeploy，确认 PagedAttention/FlashAttention 已显著改变 baseline，主分析放在成熟 LMDeploy 上。
2. 拆 prefill/decode：合成请求分别固定 batch 改 prompt/KV length、固定 length 改 batch，测每个方法的 throughput，而不是只测总时间。
3. 加入 tensor parallel：同一重负载在 TP=1/2/4 下重测，观察多卡已经缓解单卡 memory bandwidth 后，压缩 speedup 是否还在。
4. 恢复真实输出长度：在 ShareGPT 1,000 个请求上生成，记录每个压缩配置相对 FP16 的 response-length shift，再测 batch=1 的 E2E latency CDF。
5. 挖 negative samples：在 LongBench 上先选 baseline 表现不低于平均的 benign samples，再找压缩后相对 accuracy loss 超阈值的样本；按 summarization、QA、code 等任务归类。
6. 把观察变成工具：offline profile attention layer 构造 throughput predictor，用 BERT 预测压缩后的 response length，最后让 router 在 FP16 与某个压缩 worker 之间按估计 E2E latency 选路。

4. 两个关键定义

response length difference:
D = (L_uncompressed - L_compressed) / L_uncompressed

D < 0: 压缩输出更长
D > 0: 压缩输出更短

请求的估计端到端时间：
T_E2E ~= T_prefill(prompt_len, batch, method, TP)
         + predicted_output_len(method, request)
           / predicted_decode_throughput(KV_len, batch, method, TP)

router(request) = argmin_{FP16, compression} T_E2E

这解释了为什么 length predictor 单独使用可能无效：最短输出的 worker 不一定有最高吞吐；throughput predictor 单独用也会错过“压缩把回答拉长”的请求。二者必须在同一个 E2E 目标里相乘。

5. 一个完整请求例子

假设某 ShareGPT 请求 prompt 2048，预计 FP16 输出 200 tokens，decode 100 tok/s，总 decode 约 2 秒。H2O 在当前长 KV、大 batch 下 kernel throughput 为 1.34x，即约 134 tok/s；如果输出仍是 200 tokens，decode 降到约 1.49 秒。但真实 length predictor 预估 H2O 会生成 310 tokens（约 1.55x），decode 变成约 2.31 秒，加上可能更慢的 prefill，默认压缩反而输了。

router 的 throughput profile 看见该 batch/TP 下 H2O 有 kernel 优势，length model 同时看见这个 prompt 有变长风险，于是把它送到 FP16 worker。另一个请求同样重 KV，但预测输出不变，才送 H2O。论文的策略是 1 张 A6000 跑 FP16、3 张跑同一种压缩，不需要每个请求动态改 kernel；只需在两类现成 worker 间路由。

6. 吞吐结果：压缩存在负收益区

主要实验在 A6000 上，用 TRL、FlashAttention、LMDeploy；另在 H800 验证大模型，模型族为 LLaMA、Mistral。ShareGPT 用于 serving 与长度，LongBench 用于 negative samples。Table 3 的重负载给出最清晰对照：

H2O 的 prefill 要算 heavy-hitter score，GEAR 要做误差补偿，所以会比 FP16 慢。decode 只有长 KV + 大 batch 才更容易 memory-bound；TP 增大后，每卡 bandwidth pressure 下降，compression 的访存节省被通信和额外 kernel 抵消。论文据此建议只给 heavy-KV requests 启用压缩。

7. 输出长度和端到端证据

LLaMA-3.1-8B-Instruct、ShareGPT 上，KIVI-4、GEAR-4、H2O-512、StreamingLLM-512 的平均 length increase 分别为 1.69x、1.70x、1.55x、1.76x；semantic score 分别 50.7、46.2、46.2、46.3，FP16 为 49.6。更长不代表更有语义：GEAR/H2O/Streaming 的分数还低于 baseline。至少变长 50% 的样本占 KIVI 24.5%、GEAR 27.1%、H2O 21.3%、Streaming 26.4%；而许多场景的 decode speedup 本就不到 1.5x。

batch=1 的 E2E latency CDF 显示压缩总体收益并不显著，GEAR 甚至有更长 tail latency。这是论文最核心的反证：固定 response length 的吞吐实验把压缩引起的额外 token 从账上删掉了。

8. Negative samples：平均分掩盖了什么

LongBench 上即使把相对 accuracy loss threshold 设到 10%，仍有大量 negative samples；多个压缩算法取 ensemble 能减少但不能消除。任务构成也不均匀：KIVI negative samples 中 summarization 占 66.7%，GEAR 73.0%；H2O 的 summarization 54.6%，StreamingLLM 43.0% 且 QA 占 32.6%。作者汇总的专门负样本集上，FP16/KIVI/GEAR/H2O/Streaming 的分数分别为：summarization 31.6/24.8/23.7/24.7/24.3，QA 52.0/28.8/28.7/33.8/30.4，code 97.0/30.0/30.0/57.2/61.3。平均 benchmark “只降一点”不能代表这些请求安全。

9. Predictor、router 与消融

throughput predictor 把不同 batch/length/method 的 attention profile 接进 Vidur runtime model，准确率为 FP16 88.5%、KIVI 88.4%、GEAR 87.7%、H2O 85.8%、Streaming 86.6%。BERT length predictor 分别为 89.3%、95.7%、88.4%、87.8%、90.0%。

在线实验用 LLaMA-7B、4x A6000、LMDeploy、1,000 ShareGPT requests，Poisson arrival 10 req/s。全压缩 baseline 的平均 E2E 为 KIVI 9.1s、GEAR 13.4s、H2O 10.6s、Streaming 10.3s，FP16 是 11.4s。只按 throughput 路由降为 7.7/9.1/8.3/8.2s；只按 length 为 10.9/13.0/11.2/11.3s，甚至可能退化；二者结合为 6.3/7.4/6.9/6.6s，相对各压缩 baseline 加速 1.45x 到 1.80x。这是“请求级选择”优于“选出一个全局赢家”的直接证据。

10. 评测贡献

贡献是评测口径和系统决策，而不是新 compression primitive。作者把 modern serving backend、prefill/decode、batch/length/TP、生成长度和样本级准确率串成一条 deployment checklist，并用 predictor/router 证明这些观察可落到运行时 policy。它把“该算法平均省多少显存”改写成“这个具体请求在当前负载下是否应压缩”。

11. 局限与适用边界

• 方法排名依赖 2025 年的 LMDeploy/kernel、A6000/H800 与 LLaMA/Mistral；新 fused kernel 可能改变负收益区域。
• length predictor 需要与模型、采样参数、任务分布匹配，ShareGPT 训练/测试结论可能漂移。
• router 原型是一种压缩方法配 3 张卡、FP16 配 1 张卡，没有联合选择多种压缩、压缩率与动态资源份额。
• negative-sample evaluator 依赖 LongBench 指标和 threshold，不是所有开放式回答的可靠质量判定器。
• 论文说明 lossy compression 有风险，不等于否定无损 KV 管理、prefix cache 或未来硬件原生压缩。

12. 与合集其他论文的关系

PACE/CONCUR 也把 KV cache 当系统资源，但通过 agent admission 避免 thrashing；本篇决定单请求是否压 cache。CodeFilter 在 prefill 前裁掉负上下文，能同时减少 KV 建立量和生成误导。SPPO 是训练 activation offload 的对应读物：两者都证明 memory optimization 必须核算搬运/额外计算的端到端成本。ReSpec 的 Adaptive Server 同样根据 active batch 决定是否开加速机制，方法论高度一致。

13. 把四个指标放在同一张账上

显存容量决定能否接单

当不压缩就无法放入目标 batch 或长 prompt 时，compression 的首要价值是 admission capacity；此时即便单请求 kernel 稍慢，也可能通过更高并发提升集群吞吐。但这个收益必须在真实 scheduler 中测，而不是仅按 cache bytes 推算，因为 PagedAttention 的 block 碎片、权重与 workspace 同样占显存。

prefill 与 decode 的瓶颈不同

prefill 对整段 prompt 做并行矩阵运算，量化、heavy-hitter score 等额外步骤容易暴露；decode 每步读历史 KV，更可能受 memory bandwidth 限制。一个方法在 decode 为 1.34x、prefill 为 0.58x，并不能直接判断 E2E，短回答和长 prompt 会让 prefill 权重更大，长回答则相反。router 必须知道请求形状。

输出长度是压缩引入的新工作量

lossy K/V 改变后续 token 的条件分布，偏差会逐步累积，EOS 也可能延后。系统最终执行的是“每 token 成本乘 token 数”，所以固定 200 output tokens 的 benchmark 相当于假设压缩不改变工作量，恰好删掉了论文观测到的主要副作用。length predictor 的作用不是改善模型，只是提前估算这笔新增工作。

样本级质量决定能否使用

平均分轻微下降可能来自大量无变化样本和少数严重失败。对摘要、QA、代码等需要忠实引用远端上下文的任务，中间 token 被驱逐或量化误差可能破坏关键证据。部署策略因此应允许任务级禁止压缩或选择更保守比例，而不是为了平均吞吐把所有请求放到同一 worker。

14. 为什么 TP 会削弱压缩加速

TP=1 时一张卡承担全部 heads，长 KV 的读取更容易打满本卡带宽，减少 bytes 有明显价值。TP 增大后每卡只读部分 heads，单卡 memory pressure 已下降，同时每层多了 collective；压缩自身的量化、选择和稀疏索引成本没有同比消失，于是相对 FP16 的优势收窄甚至转负。Table 3 中 H2O decode 从 TP=1 的 1.34x 变为 TP=2 的 0.69x，是这一机制的直接例子，而不是“更多 GPU 总会更慢”。

15. 一个可执行的上线流程

1. 在目标模型、kernel、GPU、TP 上离线扫描 batch/prompt/KV length，得到 prefill/decode profile。
2. 用真实业务 prompt 重跑输出长度与任务质量，单独标记 catastrophic negative samples。
3. 部署 FP16 与压缩 worker pool，先 shadow 计算 predictor 决策，不立即切流。
4. 按任务白名单、显存压力和估计 E2E 路由；predictor 不确定或输入分布漂移时回退 FP16。
5. 持续监控实际/预测长度、TTFT、TPOT、EOS 比例和质量代理，定期更新 profile，而不是把论文中的阈值固定进代码。

这套流程保留了 compression 在 heavy-KV 场景的容量与带宽收益，也承认它是有条件的近似。论文最可复用的产物正是这条评测和路由路径，而非四种方法在某张表上的静态名次。

16. 前置背景、复现方法与结论边界

KV cache 的容量公式

每个历史 token 在每层保存 key 与 value。若层数为 N，KV head 数为 H，head dimension 为 D，元素字节数为 B，batch 为 Q，序列长度为 L，缓存量近似为二乘 N、H、D、B、Q、L。两倍来自 K 和 V。多查询注意会减少 KV head，但长上下文和高 batch 仍使容量线性增长。权重只随模型复制一次，KV 随在线请求动态增长，所以高并发时它可超过权重。

压缩分两类。量化保留全部 token，但把 K/V 从十六位降到四位等；近期 residual 常保留高精度，旧 token 才量化。驱逐只保留部分 token：StreamingLLM 固定 sink 与最近窗口，H2O用累计 attention 选择 heavy hitter。量化引入数值误差，驱逐丢信息；二者都要额外 kernel 和 metadata。

成熟 serving baseline 为什么改变结论

朴素 Transformers 为每个请求维护连续 cache，Python loop 与小 kernel 开销高；任何自定义压缩 kernel 都可能看似加速。PagedAttention 把 cache 分 block，支持非连续分配与连续 batching；FlashAttention 流式计算减少 attention 中间读写；LMDeploy 还融合算子。FP16 baseline 变快后，压缩额外量化、选择和反量化更容易暴露。

公平实验必须让 FP16 与压缩共享同一服务栈、batch、采样和计时边界。不能拿论文作者的未优化压缩实现对高度优化 FP16 得出否定，也不能反过来用朴素 FP16 夸大收益。本文重做实现并分别测 prefill 与 decode，就是为了把算法字节节省与 kernel 工程分开。

四种方法逐步执行

KIVI 利用 K 在 channel 方向、V 在 token 方向的离群特性选择不同量化粒度，以 group 三十二处理，并保留最近一百二十八 token 高精度 residual。Decode 读取旧 cache 时要反量化或用量化 kernel。GEAR 在量化残差上再做百分之二 sparse 与 rank 二低秩修正，精度目标更高，计算和内存访问也更多。

StreamingLLM始终保留前六十四个 attention sink 和最近四百四十八个 token，总 cache 五百一十二；中间历史直接丢弃。H2O 保留六十四 heavy hitter 加四百四十八 recent，需累计 attention score并更新保留集。两种 eviction 在长 KV 时读量减少明显，但 prefill 的打分/选择可能很慢，且被删证据无法恢复。

Prefill、decode、TP 的性能账

Prefill 一次处理整段 prompt，矩阵规模大、计算并行高。H2O 为所有 token 计算重 hitter，表中 TP一只有零点五八倍 baseline；GEAR 修正也只有零点八六。KIVI 四位约一点零六，Streaming约零点九五。压缩不是天然让首 token 更快。

Decode 每步只处理新 token，却读取全部历史 KV，长序列大 batch 时更受带宽限制；H2O、Streaming 在 TP一可一点三四倍。TP四时每卡 KV 已切小，collective 与压缩 overhead 占比升高，H2O 降到零点八五，KIVI零点九。是否压缩必须知道阶段、长度、batch 和 TP。

输出为何会变长

Lossy cache 改变 attention score和 value 汇聚，下一 token 概率有微小偏差；偏差一旦选到不同 token，后续前缀完全分叉。EOS 概率可能降低，模型重复解释或绕路，输出增长。ShareGPT 上四方法平均长度约为 FP16 的一点五五到一点七六倍，已足以抵消小于一点五倍的每 token 加速。

长度差 D 用未压长度减压缩长度，再除未压长度；D负表示压缩更长。平均 semantic score不能证明变长有益：KIVI分数略高，其他方法更长却更低。E2E 必须用实际生成到 EOS，而不是固定输出 token 上限；否则新增工作量被实验设计删除。

Negative sample 挖掘

作者先筛 FP16 表现不低于任务平均的 benign 样本，避免把 baseline 本来不会的题算压缩失败；再计算压缩相对损失，超过阈值标 negative。按摘要、问答、代码分类后发现失败集中且方法不同。摘要需要跨长文均匀证据，驱逐中间 token 危险；代码依赖远端定义，量化或驱逐都可能破坏精确符号。

专门负集里 FP16 代码九十七，KIVI/GEAR 三十，H2O五十七点二，Streaming六十一点三；QA 从五十二降到二十八到三十三。平均 LongBench 分数会被大量无影响样本稀释。上线应为高风险任务禁用压缩或加入质量路由，不能只监控吞吐。

两个 predictor 如何合成路由

吞吐 predictor 离线 profile attention layer，把 batch、prompt/KV length、方法与 TP 输入运行时模型，准确率约八十五点八到八十八点五。Length predictor 用 BERT 看请求文本，预测各 worker 的输出长度，准确率约八十七点八到九十五点七。前者估每 token 成本，后者估 token 数。

总时间近似 prefill 时间加预测输出长度除 decode throughput。只按吞吐会把会变长的请求送压缩；只按最短长度忽略 worker速度，表八甚至退化。合并后四种配置平均延迟六点三到七点四秒，相对全压缩九点一到十三点四秒提升一点四五到一点八倍。

路由例子的完整计算

一个 prompt 二千零四十八、FP16预计输出二百 token 的请求，若 FP16 decode 一百 token每秒，约两秒。H2O throughput 一百三十四，固定长度只需一点四九秒；但 length model 预测三百一十 token，则需二点三一秒，还没加较慢 prefill。Router 选择 FP16。另一个预测仍二百 token 的重 KV 请求才送 H2O。

原型一张 A6000 跑 FP16、三张跑同一种压缩；路由不在单请求中切 kernel，避免 cache格式转换。队列等待也应纳入生产估计：最快 worker若排队长，实际完成更慢。论文公式核心可扩展到排队时间与多种压缩率，但主原型没有联合优化这些维度。

实现与复现清单

先在目标 GPU、模型、runtime 与 TP 上扫描 batch、prompt、KV length，分别保存 prefill/decode throughput、显存与压缩 overhead。主配置使用论文的 group、residual、sparse、rank与五百一十二 cache，保证可比。再用一千 ShareGPT请求真实生成到 EOS，记录长度、TTFT、每 token 延迟、总延迟和 semantic score。

LongBench 按论文流程生成 negative set，报告阈值、任务构成和逐方法交集。Predictor 训练测试要按请求划分，不能用相同 profile点；线上 Poisson 到达率十请求每秒，固定四卡资源与 worker比例。分别跑全 FP16、全压缩、吞吐-only、长度-only和联合路由，验证消融。

监控实际与预测长度、throughput误差、EOS率、队列、cache bytes和质量代理。模型、采样温度、kernel或流量分布改变后重新 profile。Predictor不确定、任务在负样本白名单或输入超训练范围时回退 FP16。压缩首先是容量工具，其次才是速度工具。

局限与最终结论

显存容量实验应计算完整进程峰值，而不是只按 KV 元素公式。模型权重、CUDA graph、attention workspace、量化 scale、稀疏索引、分页元数据和临时反量化 buffer 都占显存。压缩 cache 字节下降四倍，不代表 batch 一定能提高四倍；PagedAttention block碎片和不同长度请求会留下不可用空洞。报告应同时给理论 cache、实际 allocated和可成功运行的最大并发。

量化方法还要说明 scale粒度与更新时机。KIVI 的 per-channel K需要跨 token统计，V按 token量化；recent residual 满后旧 token 转量化格式，会触发周期工作。不同 group size改变 scale开销和误差，四位与二位不只是容量倍数。GEAR 的 sparse/low-rank修正在 layer和step上如何更新决定开销，不能只复用论文压缩率名称而省略实现。

驱逐方法的 heavy-hitter score依赖 attention权重。FlashAttention常不显式输出矩阵，为H2O维护累计分数可能要求额外遍历或修改 kernel，这解释 prefill负收益。StreamingLLM不算动态分数，实现便宜但固定保留初始 sink是否适用于所有模型取决于训练。比较二者时应把选 token成本与减少 KV读取分开计时。

质量偏差会随解码步累积。可以在同一随机种子下记录压缩与 FP16 首次 token分叉位置、分叉前概率差、EOS位置和重复片段。若大量请求早期分叉，说明 cache误差直接改变语义；若只在尾部EOS分叉，主要问题是长度。针对二者的策略不同：前者需更保守压缩或任务禁用，后者可加入长度保护或最大额外 token预算。

长度 predictor输入应包含 prompt文本或其表示、模型与方法标识，也可能需要采样温度、最大输出和任务。一个 BERT分类/回归器在 ShareGPT准确，不代表代码或摘要。评估“准确率”需说明容忍区间或类别定义；路由最终关心时间排序，最好同时报告平均绝对长度误差和是否选对 worker。即使单模型预测误差不小，只要两 worker时间差大，路由仍可正确。

Throughput predictor基于 attention profile与Vidur运行模型。它需要插值未测 batch和长度，并把非attention算子、通信与压缩 kernel加入。FP16准确八十八点五、H2O八十五点八说明仍有误差；当估计时间接近时应保守选 FP16，或把不确定度加入目标，避免预测噪声导致频繁错路。

在线 worker比例一比三是实验设定，不是最佳容量规划。若大部分请求被路由 FP16，一张卡会排长队，联合公式只算服务时间会低估完成时间；若压缩卡空闲，则容量浪费。生产系统应把当前队列等待加入 T_E2E，并周期调整 worker份额，或让可转换实例在批次边界加载不同 kernel。转换涉及不同 cache格式，正在运行请求不能随意迁移。

请求级路由在生成前决定方法，却无法知道真实输出。可在解码中监控长度超过预测或质量代理异常后回退，但从压缩 cache恢复 FP16需要原始 K/V；若已驱逐或低位存储，只能重做 prefill。预先双存会失去容量收益。因此论文选择前置预测，生产回退通常是终止重试或对高风险请求一开始就不用压缩。

吞吐表的 speedup以 FP16同配置为一。数值小于一表示压缩更慢，不是准确率。Prefill和decode的比例由请求决定：prompt两千、输出几十时prefill主导，H2O即使decode一点三四倍也无法补零点五八倍prefill；短prompt长输出则可能相反。可用公式把两个阶段时间按实际长度相加，不应平均两个speedup。

TP反转还受通信拓扑。单机NVLink与跨机网络的 collective成本不同；压缩只减少本地 KV读取，未减少每层张量并行 all-reduce。跨机时通信更占比，字节节省更难体现。另一方面显存容量可能迫使更高TP才能运行，压缩若允许降低TP，系统收益可能来自少用卡而非同TP加速，论文同TP表没有覆盖这种重新配置价值。

Negative ensemble把多个压缩方法都失败的样本与各自特有失败分开。若不同方法错误不重合，router理论上可按任务选择KIVI或H2O而非只选FP16/一种压缩；但需要方法级质量预测，训练数据和worker更多。论文原型保持二选一，以证明联合长度/吞吐信号；扩展多方法是合理后续，不是已验证结论。

摘要任务负样本多，原因可能是关键信息分散在长文中间，recent与sink保留无法覆盖；QA可能只需少数证据，heavy hitter有机会保留但打分早期未必识别；代码对精确符号极敏感，低位误差也可能改变标识符。任务机制解释了为何统一压缩率不合理，路由可先用任务类型做粗白名单，再用预测器细分。

平均semantic score中KIVI五十点七略高FP16四十九点六，不能推出KIVI改善质量。评估器有噪声，输出更长也可能得到更多表面信息；同时至少变长百分之五十的请求占四分之一左右。应联合事实正确性、忠实度、重复与长度归一化分数，尤其不要把“更长”自动解释为“更完整”。

采样参数影响误差传播。Greedy在概率接近时一次微小变化就翻转；温度采样本来有随机差异，需要多种子统计；top-p改变候选集合，压缩对尾概率的扰动可能更明显。Length predictor与negative set都绑定论文采样配置，部署换温度后应重建。最大生成长度会截断变长输出，使表面延迟不再增长，却降低完成质量，不能把截断当优化。

服务指标还应包含首 token时间、每输出 token时间、完成时间和良好请求吞吐。Compression可能让TTFT变差、TPOT变好；用户交互更在意TTFT，离线batch更在意总吞吐。良好请求吞吐只计算通过质量门槛的完成，避免系统通过生成大量低质或被截断响应获得高token/s。

复现的顺序必须先验证FP16 runtime，再验证每种压缩数值与显存，最后做路由。若单方法实现比论文慢，router会自然少选它，联合结果仍可能看起来好，却没有复现算法观察。应公布所有profile点、代码提交、kernel编译参数和失败配置，让负收益区域可审计。

部署监控可使用shadow抽样：少量请求同时在FP16和压缩worker运行，不向用户返回shadow，比较长度、首分叉和任务代理，更新漂移统计。成本较高所以只抽样。若某任务negative率上升或predictor误差超阈值，自动切回FP16并重新画像。这样路由不是一次训练后永久可信。

隐私与多租户方面，length predictor读取prompt，必须遵守与模型相同的数据边界；profile和路由日志不应保存原文。不同租户的质量容忍与SLO可成为路由输入：低风险批处理允许压缩，高风险代码或医疗问答固定FP16。论文没有评测这些领域，因此默认保守。

最终复现实验应形成一张请求级表：输入长度、预测/实际输出长度、所选worker、预测/实际prefill与decode时间、总延迟、显存、任务分数和是否negative。聚合表给均值与分位数，样本表解释错误路由。只有这样才能从论文的平均倍数追到每个决策是否正确。

还应报告压缩 worker 与 FP16 worker 的利用率和排队分布。若联合路由平均延迟下降只是因为三张压缩卡资源多于一张 FP16，需用等资源或交换比例做对照；论文比较的是固定四卡部署内不同策略，复现不能给联合方法额外 GPU。压力从低到高扫描可观察路由是否在队列拥塞时仍稳定。

显存不足导致 OOM 的请求不能简单从延迟统计中删除。它们应计为无法服务，或由压缩 worker接纳并计入良好吞吐；容量正是压缩的重要价值。相反，压缩生成超长后触及最大长度，也应计质量失败。统一成功定义才能公平比较容量与准确性。

这套方法论也适用于新的压缩算法：先问它减少多少实际分配，再问现代 kernel 下各阶段是否加速，再恢复它改变的输出工作量，最后检查请求级失败并路由。算法名称会更新，这四步不会因某个新量化位宽而失效。

最终目标是完成更多符合质量要求的请求，而不是制造更漂亮的显存压缩率或固定长度吞吐数字。

实验硬件、LMDeploy版本与二零二五年的 kernel 会过时；未来原生低位 KV kernel可能扩大收益。Length model 依赖模型和任务；router只选 FP16与一种压缩，未联合多方法、压缩率和资源。Negative判定依赖 LongBench指标，也不能覆盖开放对话全部质量。

论文没有否定 KV compression。它证明节省显存、提高固定长度 token吞吐、保持平均分三项都不足以推出端到端更好。正确决策单位是具体请求和当前系统状态：若不压无法接单，容量价值可能优先；若重 KV 且预测长度稳定，可压；若 TP大、prefill重、会变长或任务高风险，应保留 FP16。

最可复用成果是一条评测与部署方法：现代 baseline，分阶段画像，恢复真实 EOS，挖样本级失败，最后用长度乘吞吐形成请求路由。只有把容量、速度、工作量与质量放在同一张账上，KV cache compression 才从离线技巧变成可控 serving机制。