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 证明有效。

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

2. 4 种 baseline 的成本结构

主配置为 KIVI G=32, R=128；GEAR sparsity 2%、rank 2；StreamingLLM/H2O 保留 64 initial/heavy + 448 recent，即 cache size 512。方法覆盖量化和稀疏 2 类，结论不是某个 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. 2 个关键定义

response length difference：

\(D<0\) 表示压缩输出更长，\(D>0\) 表示压缩输出更短。

请求的估计端到端时间为：

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

5. 1 个完整请求例子

假设某 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；只需在 2 类现成 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。这是“请求级选择”优于“选出 1 个全局赢家”的直接证据。

10. 评测贡献

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

11. 局限与适用边界

• 方法排名依赖 2025 年的 LMDeploy/kernel、A6000/H800 与 LLaMA/Mistral；新 fused kernel 可能改变负收益区域。
• length predictor 需要与模型、采样参数、任务分布匹配，ShareGPT 训练/测试结论可能漂移。
• router 原型是 1 种压缩方法配 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. 把 4 个指标放在同一张账上

显存容量决定能否接单

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

prefill 与 decode 的瓶颈不同

prefill 对整段 prompt 做并行矩阵运算，量化、heavy-hitter score 等额外步骤容易暴露；decode 每步读历史 KV，更可能受 memory bandwidth 限制。1 个方法在 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 时 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 个可执行的上线流程

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 场景的容量与带宽收益，也承认它是有条件的近似。论文最可复用的产物正是这条评测和路由路径，而非 4 种方法在某张表上的静态名次。

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

KV cache 的容量公式

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

压缩分 2 类。量化保留全部 token，但把 K/V 从 16 位降到 4 位等；近期 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 工程分开。

4 种方法逐步执行

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

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

Prefill、decode、TP 的性能账

Prefill 1 次处理整段 prompt，矩阵规模大、计算并行高。H2O 为所有 token 计算重 hitter，表中 TP 1 只有 0.58× baseline；GEAR 修正也只有 0.86。KIVI 4 位约 1.06，Streaming 约 0.95。压缩不是天然让首 token 更快。

Decode 每步只处理新 token，却读取全部历史 KV，长序列大 batch 时更受带宽限制；H2O、Streaming 在 TP 1 可 1.34×。TP 4 时每卡 KV 已切小，collective 与压缩 overhead 占比升高，H2O 降到 0.85，KIVI0.9。是否压缩必须知道阶段、长度、batch 和 TP。

输出为何会变长

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

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

Negative sample 挖掘

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

专门负集里 FP16 代码 97，KIVI/GEAR 30，H2O57.2，Streaming61.3；QA 从 52 降到 28 到 33。平均 LongBench 分数会被大量无影响样本稀释。上线应为高风险任务禁用压缩或加入质量路由，不能只监控吞吐。

2 个 predictor 如何合成路由

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

总时间近似 prefill 时间加预测输出长度除 decode throughput。只按吞吐会把会变长的请求送压缩；只按最短长度忽略 worker 速度，表 8 甚至退化。合并后 4 种配置平均延迟 6.3 到 7.4 秒，相对全压缩 9.1 到 13.4 秒提升 1.45 到 1.8×。

路由例子的完整计算

1 个 prompt 2048、FP16 预计输出 200 token 的请求，若 FP16 decode 100 token/s，约 2 秒。H2O throughput 134，固定长度只需 1.49 秒；但 length model 预测 310 token，则需 2.31 秒，还没加较慢 prefill。Router 选择 FP16。另一个预测仍 200 token 的重 KV 请求才送 H2O。

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

实现与复现清单

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

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

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

局限与最终结论

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

量化方法还要说明 scale 粒度与更新时机。KIVI 的 per-channel K 需要跨 token 统计，V 按 token 量化；recent residual 满后旧 token 转量化格式，会触发周期工作。不同 group size 改变 scale 开销和误差，4 位与 2 位不只是容量倍数。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 文本或其表示、模型与方法标识，也可能需要采样温度、最大输出和任务。1 个 BERT 分类/回归器在 ShareGPT 准确，不代表代码或摘要。评估“准确率”需说明容忍区间或类别定义；路由最终关心时间排序，最好同时报告平均绝对长度误差和是否选对 worker。即使单模型预测误差不小，只要两 worker 时间差大，路由仍可正确。

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

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

请求级路由在生成前依据预测长度和任务特征选择压缩方法。解码中可以监控实际长度和质量代理；当长度超出预测或质量代理异常时，系统可终止后重试，或重新执行 prefill。对高风险请求则从一开始保留 FP16 K/V。论文采用前置预测，以避免同时保存压缩与 FP16 两份 cache 抵消容量收益。

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

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

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

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

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

采样参数影响误差传播。Greedy 在概率接近时 1 次微小变化就翻转；温度采样本来有随机差异，需要多种子统计；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 并重新画像。这样路由不是 1 次训练后永久可信。

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

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

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

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

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

最终目标是完成更多符合质量要求的请求，而不是制造更漂亮的显存压缩率或固定长度吞吐数字。请求级成功率与良好吞吐应成为最终验收口径。

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

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

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