IntentKV (2606.09916) — L3 per-paper synthesis #

1. 相关论文 #

IntentKV 的邻居可以按「它们对 agent 的 KV cache 做什么」聚成三个同心圈，越靠内越正面对撞。

内圈 — KV 的内容/布局本身（直接竞争或直接组合）

• Continuum (2511.02230) — 同为 multi-turn agent 的 KV cache 治理，但作用于 时间轴：用 cost-benefit TTL 决定 KV 在 tool-call 间隙 pin 多久，消除 per-turn queueing bubble [2511.02230]。IntentKV 作用于 空间轴：决定单次请求内哪些 KV token 保留、如何布局 [2606.09916]。两者是 IntentKV 自己 L1 里显式列的 related，且几乎正交——一个管"留多久"，一个管"留哪些"。
• KVCOMM (2510.12872) — 同样"不改模型、frozen backbone、per-request KV 变换"，但目标相反：KVCOMM 是 跨 agent 复用 KV（RoPE 对齐 + anchor 池偏移近似），IntentKV 是 跨 turn 裁剪 KV [2510.12872]。两者都把"是否复用/保留"的硬决策软化：KVCOMM 转成"如何近似偏移"的连续估计，IntentKV 转成"如何打分保留"的学习问题。

中圈 — agent serving 的调度与内存生命周期（互补的另一层）

• Autellix (2502.13965) — program-level LAS 调度，把 KV locality 作为 routing 信号但不改 KV 内容 [2502.13965]。IntentKV 是它可以调度的"更小 working set"。
• TokenCake (2510.18586) — dual-scheduler（temporal offload + spatial partition），把 tool-call 期间的 idle KV block offload/reserve [2510.18586]。与 IntentKV 正交：TokenCake 搬移完整 KV，IntentKV 缩小 KV。

外圈 — tool 延迟隐藏 / CPU 侧瓶颈 / 上层路由（不同瓶颈假设）

• Speculative Tool Calls (2512.15834) — 投机执行 tool 隐藏 tool 等待时延，engine-side 变体靠"避免序列驱逐"省 KV 重调度成本 [2512.15834]。
• CPU-Centric agentic (2511.00739) — 实证 tool 执行占 E2E 高达 88%，主张瓶颈在 CPU 侧而非 GPU/KV [2511.00739]。这是对 IntentKV 前提的最强外部质疑（见 §3）。
• RouteLLM (2406.18665) — 单轮 strong/weak 路由，无 multi-turn、无 KV、无 tool loop [2406.18665]。只在"降低 agent 服务成本"这个宽泛主题上相关，方法上几乎没有交集，作为 category 的 negative anchor 保留。

2. 本篇 vs 相关论文的 delta #

新在哪（vs 内圈）

1. retention × layout 分解是本篇独有的 framing。 之前的 agent KV 工作要么只碰内容（KVCOMM 的偏移近似 [2510.12872]），要么只碰生命周期/位置（Continuum 的 TTL [2511.02230]、TokenCake 的 offload [2510.18586]）。IntentKV 第一次明确把「保留什么」和「保留状态如何布局」拆成两个可独立归因的轴，并用 Table 7 的 dead-slot substrate 消融证明两者可分离 [2606.09916]。
2. 让 per-request pruning 与 radix prefix reuse 共存。 这是本篇的核心技术壁垒：alias-aware deallocation 让 dropped slot 只在非 sentinel、非 radix-protected、非 sibling-aliased 时才释放 [2606.09916]。之前的 compaction pruner 必须二选一（要么裁剪要么 prefix reuse），IntentKV 实测 20.7% prefix-hit vs compaction 基线的 0–3% [2606.09916]。

增量 / 平行（vs 中外圈）

• 相对 Continuum，IntentKV 是内存容量维度的节流，Continuum 是调度延迟维度的节流。二者收益来源不重叠——Continuum 的 8.18× 来自消除排队气泡 [2511.02230]，IntentKV 的收益来自缩小 live working set 和保留 prefix reuse [2606.09916]。这暗示一个未做的 hybrid（§5）。
• 相对 Autellix，IntentKV 不做 program 级调度；但 IntentKV 的更小 working set 会直接放大 Autellix 的 KV-locality routing 收益，因为更多请求能同时驻留同一 engine [2502.13965]。

矛盾 / 张力

• IntentKV 声称 KV memory/bandwidth 是 agent serving 的 bottleneck（"not compute"）[2606.09916]。CPU-Centric 论文实测 tool 执行占 E2E 高达 88%，主张 CPU 侧才是主导瓶颈 [2511.00739]。

矛盾根源: 两者的 benchmark 和 metric 不同。IntentKV 测的是 BrowseComp-Plus 这种 retrieval-heavy、超长上下文（92–115k peak tokens）的 deep-research trace，其中 tool（snippet/doc fetch）相对轻、上下文极长，KV 压力真实主导 [2606.09916]。CPU-Centric 测的是 RAG-Haystack（ENNS over 115GB）、ChemCrow（RDKit）这类 重 CPU 工具 workload，tool 计算本身极重 [2511.00739]。两者在各自 workload 上都对——瓶颈位置是 workload-dependent，IntentKV 的"KV is the bottleneck"应加限定词"in long-context retrieval agents"。

3. 可攻击面 #

1. "KV is the bottleneck" 的过度概括。 如上，CPU-Centric (2511.00739) 直接反证：GPU 越强瓶颈越快移向 CPU 工具执行 [2511.00739]。IntentKV 在 tool 执行占 E2E 88% 的 workload 上，即使把 KV 读降到 1/10，E2E 改善上限也只有 ~12%。IntentKV 的价值窗口严格绑定"上下文长、工具轻"的 retrieval/browse agent。
1. 8k budget 下学习残差反而掉 0.60 点。 IntentKV 自己承认 learned residual head 在 8k 非单调有害，因为 rule prior 已"saturate the dead-slot ceiling" [2606.09916]。这意味着 214k 参数的 head 在最有内存压力的低预算区间不产生正收益——正是最需要它的地方它最没用。攻击点：这个 head 的存在价值在哪个预算区间？
1. prefix-hit 20.7% 的绝对值仍低。 相比 Autellix 报告的 intra-program cache hit >90% [2502.13965]，IntentKV 的 20.7% 只是"相对 compaction 基线的 0–3% 大幅提升"，绝对值远未达到 program 内天然的 locality 上限。裁剪本身仍在破坏一部分 prefix 复用——只是没有全毁。
1. eviction 单向不可逆。 dropped position 一旦 redirect 到 dead slot 就无法复活 [2606.09916]。对比 KVCOMM 有 dense-prefill fallback [2510.12872]、TokenCake 可把 offload 的 KV upload 回来 [2510.18586]、Continuum TTL 过期后可 reload [2511.02230]。IntentKV 是这组里唯一"删了就没了"的方案——若 QueryMemory 误判某历史 token 未来会被 tool 重新 attend，无补救路径。这把全部赌注压在 retention scorer 的召回率上，而论文恰恰没给 retention-recall 的理论下界 [2606.09916]。
1. F1 失败模式（模型不肯 call tool）与 KV 压缩无关却拉低 True Acc。 论文自己指出主导失败类 F1 位于 agentic-behavior 层 [2606.09916]。用把 non-completion 记为错的 True Acc 做主指标，会让一部分与 IntentKV 方法无关的 backbone 行为差异污染 headline 对比。

4. 生态位 #

IntentKV 处在 "agent-native KV cache 治理" 这个 2025–2026 新兴子领域，且明确站在"frozen backbone + 服务层介入"的范式上——和 KVCOMM (2510.12872)、Continuum (2511.02230)、TokenCake (2510.18586) 共享同一时代判断：单轮 serving 的假设（一次 prompt、eviction 无所谓 prefix、token importance 静态）在 multi-turn agent 上系统性失效。

• 范式转变定位: 从"把 agent call 当独立请求"（vLLM/SGLang 默认）→"把 KV 当跨 turn 的一等状态来治理"。Autellix 从调度侧、Continuum 从生命周期侧、IntentKV 从内容侧各自捅破这层假设 [2502.13965][2511.02230]。IntentKV 独占的生态位是"内容裁剪 + prefix 兼容"这个此前被认为互斥的交叉点。
• 采纳证据: 全栈基于 SGLang + flashinfer/FA3，只改 slot map 不改 kernel，且 head 仅 214k 参数、声明 MIT 开源 [2606.09916]——工程侵入性极低，采纳门槛比需要 fork vLLM 的 Speculative Tool Calls (2512.15834) [2512.15834] 低得多。但 L2 明确标注 [实现未公开 — 部分]：无公开 repo 的 file:line，checkpoint 尚未见到 [2606.09916]，可复现性弱于 Continuum（有 github.com/Hanchenli/vllm-continuum [2511.02230]）和 RouteLLM（lm-sys/RouteLLM [2406.18665]）。
• 护城河: alias-aware deallocation 这个 correctness discipline 本身是 know-how，不是 primitive——borrowed paged slot map（PagedAttention）+ borrowed sentinel mask，难点在集成正确性 [2606.09916]。这类护城河容易被后来者一旦看懂就复制，护城河更多来自"第一个把它做对"而非算法壁垒。

5. 未探索方向 #

从这个 cluster 的组合空间里，有几个技术上可做、目前无人做的 hybrid：

1. 空间裁剪 × 时间 TTL 的联合治理（IntentKV × Continuum）。 IntentKV 缩小 单请求 KV footprint，Continuum 决定 KV 驻留时长。二者维度正交且都基于 cost-benefit 直觉——一个自然的 hybrid 是让 Continuum 的 TTL cost model 以 IntentKV 压缩后的 MemUsage(r) 为输入，pin 的是"已裁剪"的 KV，从而在同样显存下 pin 更多请求、进一步压排队气泡 [2511.02230][2606.09916]。
1. 裁剪后 KV 的跨 agent 复用（IntentKV × KVCOMM）。 IntentKV 的 QueryMemory 打分识别"高价值历史 token"；KVCOMM 的 anchor 池近似跨上下文偏移 [2510.12872]。若只对 IntentKV 判定为"保留"的 token 做 KVCOMM 式跨 agent 迁移，可同时享受"更小集合"和"跨 agent 复用"——但需解决 dead-slot sentinel 与 RoPE 去旋转的坐标系冲突。
1. retention scorer 作为调度信号上抛（IntentKV × Autellix / TokenCake）。 IntentKV 的 per-token score 目前只用于本请求裁剪。它其实也是"这个请求未来还会重读多少 KV"的预测量，可上抛给 Autellix 的 program priority [2502.13965] 或 TokenCake 的 spatial reservation [2510.18586] 作为 importance 信号，让调度器区分"KV 很快会被丢弃"vs"KV 会长期高频重读"的请求。
1. 自适应预算 + 投机的 KV 预测（IntentKV × Speculative Tool Calls）。 Speculative Tool Calls 的投机模型能提前预测下一个 tool call [2512.15834]。若把这个预测喂给 IntentKV 的 future-action label 生成（目前用对下 5 个 tool-call 参数的字面子串匹配 [2606.09916]），可把"回顾式标签"变成"前瞻式标签"，直接缓解 §3 攻击点 4 的单向不可逆风险——投机预测哪些 token 未来会被 attend，就优先保留。
1. budget-adaptive residual gating。 针对 §3 攻击点 2：既然 residual head 在 8k 有害、16k 有益，一个未探索方向是让 residual gate α 随可用预算 C 自适应（低预算退回纯 rule floor，高预算才启用 learned correction），而非全局固定 [2606.09916]。技术上只是把 α 变成 C 的函数，无需重训 backbone。