Helium (2603.16104) — L3 per-paper synthesis #
Target: Efficient LLM Serving for Agentic Workflows: A Data Systems Perspective (Helium).
8 related peers, all category: agent. Cross-paper delta, attack surface, ecosystem niche, unexplored directions.
1. 相关论文 #
Helium 的相关篇构成一个 agent serving/scheduling 光谱，可按"优化对象"分三簇，Helium 横跨其中两簇：
簇 A — workflow-aware KV/prefix 复用 (Helium 的直接竞争带)
- KVCOMM (2510.12872)：多 agent 通信中的跨上下文 KV 复用，用 RoPE 对齐 + anchor 池近似跨前缀偏移 [2510.12872]。与 Helium 同样瞄准"多 agent 重复 prefill"，但走 近似复用（有损、免训练）而非 Helium 的 精确复用（无损、编译期）。
- TokenCake (2510.18586)：KV-cache 中心的多 agent serving，temporal offload + spatial 分区双调度 [2510.18586]。与 Helium 共享"agent-aware cache scheduling"目标，但优化 tool-call 造成的 idle KV window，Helium 假设无远程 tool call。
- Continuum (2511.02230)：多轮 ReAct agent 的 KV cache TTL 机制，用 cost-benefit 模型决定保留时长 [2511.02230]。L2 frontmatter 明确将 2603.16104 列为
related——双向相关已注册。与 Helium 互补：Continuum 管 turn 间 KV 保留，Helium 管 batch 内/跨 batch prefix 复用。
簇 B — program/call-level 调度 (Helium 的调度理论邻居)
- Autellix (2502.13965)：将 OS 的 Least-Attained-Service 提升到 program 级调度 (PLAS/ATLAS) [2502.13965]。是 Helium 引用的
[47] 同一系。二者都做 program/workflow 级调度，但 Autellix 是 non-clairvoyant online（运行时逐步揭露 DAG），Helium 是 clairvoyant offline（编译期已知整批 DAG）——这是最本质的对立轴。
簇 C — 正交但同类别 (agent serving 生态坐标)
- CPU-centric characterization (2511.00739)：从 CPU 侧刻画 agentic AI，发现工具执行占 E2E 延迟高达 88% [2511.00739]。Helium 明确把 tool call 排除在 scope 外（§2 假设），因此 2511.00739 直接量化了 Helium 忽略的那部分延迟——一个 scope 攻击者。
- Speculative Tool Calls (2512.15834)：把 speculative decoding 推广到 tool-call 级，重叠工具执行与推理 [2512.15834]。也是攻击 Helium 的 tool-call 盲区，但走投机路线。
- RouteLLM (2406.18665)：query 级 strong/weak 模型路由 [2406.18665]。与 Helium 正交（不同优化层），但 Helium 的 "same base LLM" 假设正是 RouteLLM 打破的维度。
- Interop protocols survey (2505.02279)：MCP/ACP/A2A/ANP 协议综述 [2505.02279]。远端相关——定义了 Helium 明确排除的 "remote API / cross-platform" 场景。
相关强度排序（对 Helium 的分析价值）：Autellix ≈ Continuum ≈ TokenCake > KVCOMM > 2511.00739 ≈ 2512.15834 > RouteLLM > 2505.02279。
2. 本篇 vs 相关论文的 delta #
新颖点 (Helium 独有) #
- Clairvoyant + query-optimizer 组合。所有 serving 邻居 (Autellix, TokenCake, Continuum) 都是 reactive/online：Autellix 显式 non-clairvoyant [2502.13965]，Continuum 靠历史统计预测 tool 时长 [2511.02230]。Helium 唯一假设 整批 workflow 编译期已知，因而能做 DB 式 CSE + dead-code 剪枝 + 全局 prefix 层级调度 [2603.16104]。这是它 0.9% MILP gap 的前提，也是它最脆的假设。
- TRT (Templated Radix Tree) 统一 prefix hierarchy + dependency DAG。KVCOMM 用 anchor 池 [2510.12872]、SGLang 用普通 radix tree、Autellix 用 process table——没有一个把 全局静态 prefix 结构 和 算子依赖 放进同一结构。Helium 的 TRT 是唯一能在编译期同时表达两者的数据结构 [2603.16104]。
- 精确语义保证。Helium 的 prompt cache 只对 deterministic 算子生效 (greedy sampling)，输出 bit-exact [2603.16104]；对比 KVCOMM 的近似复用会在 GSM8K/HumanEval 退化 [2510.12872]——Helium 用"限制适用范围"换取"零质量损失"。
增量点 (Helium 是别人思路的编译期化) #
- NP-hard makespan + 贪心近最优：Autellix 也把调度对比 clairvoyant SRPT 并承认存在 gap [2502.13965]。Helium 把同类问题形式化为 NP-hard 并给出 0.9% avg / 3.6% max MILP gap [2603.16104]——但仅在 2-4 agent / 2-4 query 缩小实例上验证。
- cache-aware scheduling 提升 hit rate：Helium 报告 global TRT 调度比 online LSPF 提升 32.9% cache hit rate [2603.16104]。这与 Autellix 的 intra-program cache locality >90% 观察 [2502.13965] 是同一现象的两种利用方式（Autellix routing 保 locality，Helium 编译期排序造 locality）。
矛盾点 (需 L4 调和) #
- "proactive KV cache 是 flagship" vs ablation 数据：Helium 声称 proactive KV caching 是核心创新之一 [2603.16104]，但其自身 ablation 显示去掉 proactive KV 只涨 3.55% 延迟，是四个组件里最低的；plan pruning (CSE) 才是 23.35% 的大头 [2603.16104]。内部矛盾：命名重心与实证重心错位。
- 对 tool-call 的态度分歧：Helium 把 remote tool call 排除出 scope [2603.16104]，而 2511.00739 实测 tool 执行占 E2E 88% [2511.00739]，2510.18586 整个系统就是为 tool-call idle window 设计的 [2510.18586]。矛盾根源：不同 workload 定义。Helium 研究 batch 分析型 agentic speculation（无外部工具、同一 base LLM），peers 研究 tool-augmented ReAct/SWE agent。两者在各自 workload 内都成立，但 Helium 的 "up to 1.56×" 头条无法迁移到工具密集场景——那里 CPU tool 才是瓶颈。
3. 可攻击面 #
攻击 1 — clairvoyant 假设过强，头条数字 workload-locked。
Helium 的全部优势（CSE 剪枝、编译期 prefix 调度、proactive precompute）都依赖 整批 workflow 在执行前完全已知 [2603.16104]。但真实 agent 主流是 dynamic control flow：Autellix 的 DAG 运行时逐步揭露 [2502.13965]，Continuum 服务的 ReAct agent 每轮 tool 决策由 LLM 自主产生 [2511.02230]。Helium 自己的 §9 也承认无法处理 conditional looping / dynamic mapping。结论：1.34×/1.56× 只在"编译期可知的批处理 speculation"这一窄带成立，一旦引入运行时分支，query optimizer 的静态剪枝直接失效。
攻击 2 — MILP 最优性证据的规模外推站不住。
0.9% avg gap 只在 2-4 agent、2-4 query、单 worker、8192-token KV、6 小时 solver timeout 的缩小实例上测得 [2603.16104]，而头条实验跑在 batch-80 / 16-branch [2603.16104]。贪心在小实例近最优 ≠ 大实例近最优（NP-hard 问题的 gap 通常随规模增长）。Autellix 更诚实地展示了与 SRPT 的 visible gap 而不声称近最优 [2502.13965]——Helium 的近最优主张缺乏规模一致的证据。
攻击 3 — 100.92× / 39.50× 是稻草人比较。
这些数字来自 "naive query-wise 顺序执行的 vLLM" [2603.16104]，即刻意关掉 vLLM batching 的 baseline。对比强 baseline KVFlow 时只有 1.34×–1.56×。这种 framing 与 CPU-centric 论文的诚实 profiling（明确标注 baseline 配置与瓶颈来源 [2511.00739]）形成对照。
攻击 4 — flagship 组件与 ablation 不符 (见 §2 矛盾)。
若 proactive KV 只贡献 3.55%，而收益主要来自 CSE 剪枝 [2603.16104]，那么 Helium 的真实贡献更接近"编译器优化 (dead-code + CSE)"而非"KV 系统创新"。这削弱了它相对 SGLang/KVFlow 的差异化叙事。
攻击 5 — 精确语义的隐藏耦合。
"exact semantics" 依赖 prompt cache 只对 greedy-sampling 算子生效 [2603.16104]，于是全部实验被迫用 greedy sampling。真实 agent 常用 temperature > 0 探索——一旦非确定性采样，Helium 的 prompt cache（bypass 整个算子）失效，只剩 KV prefix 复用（仅 3.55% 那档）。KVCOMM 反而在近似框架下不受此约束 [2510.12872]。
4. 生态位 #
范式定位：Helium 是 "把数据库 query optimization 移植到 agent serving" 这一子范式最系统的一次尝试。它不是渐进改良 vLLM，而是在 vLLM 之上新增一个 编译期 workflow 优化层——与 Autellix 的"OS 调度移植"[2502.13965] 属于同一"跨学科移植"思潮的两个方向（DB vs OS）。
在光谱中的坐标（online↔offline × approximate↔exact）：
- Helium = offline + exact（唯一占据此象限者）
- Autellix / Continuum / TokenCake = online + exact
- KVCOMM = online + approximate
这个空缺象限正是 Helium 的独特生态位：当你能预知整批 workload 且要求 bit-exact，没有第二个系统能做到它的全局优化。反之，这也是它最窄的适用面。
采用证据 (adoption)：
- 正向信号：Continuum 主动把 Helium 列为
related [2511.02230]，说明 2025Q4 的 agent-serving 圈已把 Helium 纳入对比坐标。
- 风险信号：源码仅
helium_demo [2603.16104]（demo 级，非生产），且作者 h-index 极低、arxiv id 2603 (2026-03) 配 vLLM v0.16.0（远超现实版本）——可复现性存疑。对比 Continuum (vllm-continuum 完整开源 [2511.02230]) 和 RouteLLM (lm-sys/RouteLLM [2406.18665]) 的成熟开源，Helium 的采用门槛更高。
时代定位：处于 "agent serving 从 call-level 走向 workflow-level" 的转折点。低垂果实（continuous batching、prefix caching）已被 vLLM/SGLang 采摘 [2511.00739]，Helium 代表下一层——把整个 workflow 当查询计划优化。但它选择的 "batch speculation + 无工具" 赛道相对小众，而生态主流（SWE-agent, ReAct + tools）正被 Continuum/TokenCake/2512.15834 占据。
5. 未探索方向 (从簇内生成) #
- Clairvoyant × Non-clairvoyant 混合调度。Helium (offline 全局最优) 与 Autellix (online non-clairvoyant) 是同一 makespan 问题的两极 [2603.16104][2502.13965]。真实 agent 是"部分可知"：workflow 骨架静态、分支运行时定。空白方向：编译期用 TRT 优化静态骨架，运行时用 PLAS 处理动态分支——no one 做了这个混合层。
- 精确 TRT 调度 + 近似 KV 复用的叠加。Helium 的 prefix 复用是精确的（只在同 worker 连续 call 之间共享 [2603.16104]），KVCOMM 的跨上下文近似复用能跨越"不同前缀 + 相同语义"的边界 [2510.12872]。把 KVCOMM 的偏移近似接到 Helium 的 TRT 叶子上，可在 TRT 判定"不可精确共享"时回退到近似共享——两篇都没做这个 fallback。
- 把 tool-call 纳入 TRT cost model。Helium 的 token-step cost model 假设无外部 tool [2603.16104]；2511.00739 量化了 tool 占 88% [2511.00739], 2512.15834 用投机重叠 tool 与推理 [2512.15834]。空白：给 TRT 的 precedence-delay 约束加一个 stochastic tool-latency 项（Helium §9 自己提到的 stochastic cost model），把 speculative tool execution 建模成可调度的独立算子。
- TTL × proactive precompute 的统一内存管理。Continuum 的 TTL 管 turn 间 KV 保留 [2511.02230]，Helium 的 proactive cache 管 batch 间静态 prefix 保留 [2603.16104]，TokenCake 管 tool-idle 期的 offload [2510.18586]。三者都是"KV 什么时候留在 GPU"的不同切面，但没有统一的 cost-benefit 框架同时决定 pin / precompute / offload——一个统一的 KV lifecycle 优化器是清晰的空白。
- 异构 base LLM 下的 workflow 优化。Helium 硬性假设所有 agent 用同一 base LLM [2603.16104]，RouteLLM 证明按 query 难度路由到 strong/weak 模型可省 >2× 成本 [2406.18665]。空白：让 TRT 的算子携带 模型选择 维度，query optimizer 同时决定"复用哪个 prefix"和"用哪个 model"——prefix 复用与模型路由的联合优化无人涉足。