本篇 (2506.02634) 的独特身份：它不是又一个 KV$ cache 机制，而是一份 生产 trace 画像 + 由画像反推出的 workload-aware 淘汰策略
[2506.02634]。因此把它放进 peer 语境时，比较轴不是"谁的吞吐更高"，
而是"每篇对 KV$ 复用/生命周期做了什么假设，本篇的真实数据支持还是推翻了这些假设"。
8 篇 peer 按其与本篇的关系可分为四组：
A. 机制底座（本篇站在其上）
"block=16 token、logical→physical 映射、GPU-CPU swap" 这套已收敛的机制
[2309.06180]，但其淘汰策略只是 FCFS + all-or-nothing 抢占，
并未针对复用特征做优化 [2309.06180]。本篇正是填补 vLLM 留下的
"策略"空白：机制不动，只替换"淘汰谁"这一个决策点 [2506.02634]。
B. workload/future-aware 淘汰的方法学兄弟（最直接的对照）
LRU 在真实负载里是错误信号并要用"未来复用"驱动淘汰
[2507.07400]；但 KVFlow 的未来信号来自 application 层的 workflow DAG
（steps-to-execution，确定性）[2507.07400]，本篇的未来信号来自 **生产 trace 的
按类别指数拟合复用概率**（统计性）[2506.02634]。见 delta 节详析。
C. 容量/卸载假设的挑战对象（本篇数据与其前提有张力）
Mooncake 的 CPU DRAM KVCache 池用 LRU + hash 去重
[2407.00079]，且其公开 trace 缺 type/UID/turn 字段
KV$ 撑爆 HBM、逼小 batch，必须把 KV$ 卸载到 CPU
[2504.03775]。这三篇都假设 KV$ 存储/迁移是重量级问题，而本篇的容量画像对
to-B 场景直接质疑了这一前提（见可攻击面/生态位）。
D. 正交的容量收缩轴（互补而非竞争）
[2405.04434]，改变的是"缓存对象的大小"；本篇优化的是"对象的淘汰顺序"。
本篇 §3.5 明确点名 MLA 属于"per-token KV 更小"的一类，是使容量需求变"中等"的原因之一
System-level 的 Scheduling/Memory-Mgmt 格子里 [2412.19442]；
但 survey 自承其复杂度模型建立在"KV$ 全量保留"的合成假设上
[2412.19442]，恰是本篇用真实 trace 要打破的。
两篇都得出"LRU 反了"这个反直觉结论，但对"如何预测未来复用"给出互补答案：
| 维度 | 本篇 2506.02634 | KVFlow 2507.07400 |
|---|---|---|
| 未来信号来源 | 生产 trace 历史，按 (type×turn) 拟合指数分布 | application 递交的 workflow DAG |
| 预测性质 | 概率性 ReuseProb_w(t,life) | 确定性 steps-to-execution |
| 适用负载 | to-C/to-B 混合、无应用结构可见 | 静态 agentic workflow（MetaGPT 类） |
| 失效模式 | 类别信息稀薄时退化回 LRU（Trace B） | runtime 动态生成 agent（ReAct）时退化为 heuristic |
| 落地成本 | 单实例、替换 vLLM 淘汰函数，79µs/次 | SGLang radix tree + scheduler 原子改造，3-4 周 |
KVFlow 明确论证"过去访问在 agentic workflow 里是随机的、未来顺序由 DAG 给出"，因此拒绝一切
基于历史的策略（含 access-time-weighted LRU）[2507.07400]。
本篇则正好相反地证明：在没有应用结构可用的通用云负载里，历史 trace 的按类别复用时间
"跨相似时段/跨天稳定、可离线预测" [2506.02634]。
矛盾根源不是谁对谁错，而是负载可观测性不同：KVFlow 的场景 application 把 DAG 暴露给后端，
未来是"已知的"；本篇的云 API/chatbot 场景后端看不到应用逻辑，只能从统计规律里"猜"未来。
两者在各自 workload 下都自洽——这正指向 delta5 的 hybrid 方向。
Mooncake 的贡献是 KVCache-centric 的全局编排（Conductor 选实例对、热点迁移、early rejection）
[2407.00079]，其 cache 池内部仍用 LRU
[2407.00079]。vLLM 提供 block 机制。本篇填的是二者都没碰的
单实例内 HBM OOM 时"淘汰谁" 这一层，并显式声明全局层 workload-aware 化留作未来工作
[2506.02634]。因此本篇与 Mooncake/vLLM 是可叠加而非竞争关系。
另一条硬 delta 是 trace 质量：本篇 Table 1 显示 Mooncake trace 缺 Type/UID/Turn，ShareGPT 缺
Time，均无法支撑"随时间的真实命中率 + 按类别复用概率"分析——这是本篇声称的核心壁垒
NEO 立论"GPU 吞吐受限于 KV$ 导致的 batch 瓶颈，必须卸载到 CPU"
[2411.01142]，APEX 继承同一前提并把它推到 decode-heavy 场景
[2506.03296]，FlowKV 则为 PD 分离的 KV$ 传输瓶颈做全栈优化
本篇的容量画像给出部分推翻的证据：GQA 模型在 to-B（纯 API）负载下所需 KV$ 缓存
"甚至小于预留 HBM，纯 GPU 缓存即够"，从而"可省掉 CPU-RDMA-SSD 存储层级"
矛盾根源（workload + 模型架构双重差异）：NEO/APEX 的"memory crisis"实测于**小显存 GPU
(T4 16GB) + 长 output** 场景 [2411.01142]，本篇的"小缓存够用"结论限定在
GQA 模型 + to-B + 8×A100 级实例。本篇也自认 MHA 模型"仍需巨量缓存，故淘汰策略在受限容量下仍重要"
[2506.02634]。两者并不真正矛盾——但本篇的结论对"KV$ 卸载/传输在所有场景都必要"
这一被 NEO/APEX/FlowKV 隐含假设的命题构成了 workload-conditional 的反例。
MLA 从模型侧把对象缩小 [2405.04434]，本篇从系统侧优化对象淘汰；本篇自述
"若未压缩的 KV$ 可复用，压缩/删除版同样可复用"，即与 StreamingLLM/KVQuant/MLA 这类压缩正交可组合
[2506.02634]。相对 Survey，本篇补上了 survey 明确缺失的一环：真实 workload 画像
（survey 复杂度模型假设全量保留 [2412.19442]），并给出 Survey §8 点名的
"cross-layer/跨类别 workload-aware"方向的一个具体系统实例 [2412.19442]。
针对本篇的具体断言，逐条列出可被反驳/证伪的攻击点：
Trace A/B [2506.02634]，本篇自承 reasoning (o1) 类新负载未覆盖
[2506.02634]。KVFlow 展示的 agentic workflow 负载里复用结构完全不同
[2507.07400]——若把 agentic 流量计入，"单轮支配"可能不再成立。攻击：结论是
2025 年通义流量快照，而非 LLM serving 的稳态规律。
即承认 MHA 需巨量缓存 [2506.02634]。NEO 实测 T4 上卸载带来 7.5× 吞吐
[2411.01142]——在小显存/长上下文/MHA 下"省掉 CPU 层"的建议会直接
伤害吞吐。攻击：该建议不能脱离 (模型架构 × GPU 显存 × output 长度) 语境引用。
[2506.02634]，说明指数族并非普适。攻击：对重尾/突发类别，
ReuseProb_w 标定误差会直接侵蚀策略收益，而论文未给出拟合失败时的降级保证
（只有 Trace B 的"退化回 LRU"这一种事后观察）。
分布法 +1%、life 正则 +2.4% [2506.02634]；在 to-B 上因 >99% 单轮而
≈ LRU [2506.02634]。攻击：真正有效的区间只有"to-C 多类型 + 容量受限"，
与 KVFlow 声称的"结构可见时确定性信号更准" [2507.07400]
相比，本篇在有应用结构的场景里可能被 dominated。
[2506.02634]，但本篇又指出 Trace B 没有 type 信息（客户端拼接）
[2506.02634]。攻击：恰恰在贡献 97% 命中的 to-B 上，类别粒度最粗，
策略最接近 LRU——即策略在其"最重要负载"上最无力。
[2506.02634]，但寿命 612s(A)/0.3s(B) 相差五个数量级
[2506.02634]——用同一个"删 Frequency"决策覆盖跨五个数量级的寿命，
缺乏对中间寿命 regime 的消融。攻击：可能存在一个寿命区间里 Frequency 仍有预测力而被误删。
范式定位：本篇是 KV$ cache 研究从 "合成负载驱动设计" 转向 "生产 trace 驱动设计" 的
标志性一步，方法论是"先画像真实特征、再优化单个 serving 组件"[2506.02634]。它把
Survey 里被列为 system-level 默认选项的 LRU [2412.19442]
从"事实标准"降级为"workload-blind 的次优解"，与 KVFlow 一起构成 2025 年"eviction 该看未来而非过去"
思潮的两个代表——一个走统计路线，一个走结构路线 [2507.07400]。
采纳证据与门槛：
alibaba-edu/qwen-bailian-usagetraces-anon）并被 USENIX ATC'25 接收，其独特资产是 Table 1 里唯一 Time/Type/UID/Turn/Content 五项俱全的 trace
[2506.02634]。这份数据本身比策略更可能成为社区公共物品。
[2506.02634]。对比 FlowKV 需要 attention kernel + allocator + transfer
三层联动的全栈替换 [2504.03775]、Mooncake 需替换整个 serving stack
[2407.00079]、KVFlow 需 3-4 周深入 SGLang 内部
[2507.07400]，本篇的工程侵入性最小。
壁垒的真实位置：本篇的护城河不在算法而在数据——ReuseProb_w 的每条曲线都要用带时间戳 +
类型 + 用户 + 多轮父链的全字段生产 trace 标定，只有大云厂商拥有 [2506.02634]。
这也决定了它的生态位是"云厂商内部可复现、外部学界难复现"，与 vLLM（开源机制、人人可用）
[2309.06180] 形成互补而非替代。
从这个 cluster 的交叉点看，最有价值的 hybrid / adaptive 方向：
ReuseProb_w 与 KVFlow 的 STE 融合：应用暴露了workflow DAG（agentic 场景）时用确定性 STE，否则回落到按类别指数拟合的统计概率
[2506.02634][2507.07400]。这能同时覆盖 KVFlow 无法处理的
ReAct 动态图 [2507.07400] 与本篇无法处理的"类别信息稀薄的 to-B"
把 ReuseProb_w 灌进 Mooncake 的 Conductor 调度/热点迁移决策 [2407.00079]
与 FlowKV 的 Load-Aware Scheduler [2504.03775]，做"跨实例的复用概率感知路由"。
只卸载"长寿命 + 高复用概率"的块，避免把 0.3s 就死的 to-B 块无谓地搬去 CPU 又搬回——直接把本篇的
画像变成 NEO/FlowKV 传输路径的准入过滤器。
[2405.04434]，从而改变本篇 §3.5 的容量数学
[2506.02634]；o1 类 reasoning 会拉长 output、改变寿命分布。本篇自承这些是
future work [2506.02634]——一份 MLA/reasoning 版的"in the wild"画像是自然续作。
而 Survey 把 cross-layer 集成列为最大空白 [2412.19442]，可按块的复用概率做
"compress-or-evict"三态决策：高概率保原精度、中概率压缩保留、低概率淘汰——把 token-level 压缩与
system-level 淘汰统一到同一个 ReuseProb_w 度量下。
[2506.02634]，并把公平性划为正交问题。把 workload-aware 优先级与 FairRide
式配额结合，是一个尚未有人做的 eviction × fairness 交叉点。