Halo (Batch Query Processing for Agentic Workflows) — L3 相关论文综合 #

1. 相关论文 #

Halo [2509.02121] 站在"agentic 系统性能优化"这个 cluster 的中心，其 8 个 peer 覆盖了从

调度、KV 复用、跨 CPU/GPU 刻画到工具投机、模型路由、协议标准化的完整光谱。按与 Halo 的关系分组：

同族——agent serving 引擎 / 调度器（最紧密）：

• Autellix (2502.13965) —— 把 OS 的 Least-Attained-Service 提升到 program 级别调度，消除 program-level HoL blocking，同延迟下 4–15× 吞吐 [2502.13965]。与 Halo 同样把 agentic program 建模为 DAG [2502.13965]，但 Autellix 是 non-clairvoyant online 调度，Halo 是 clairvoyant offline batch 规划——这是最深刻的对立轴。
• Continuum (2511.02230) —— 为多轮 ReAct agent 引入 KV cache TTL，用 cost-benefit 模型决定 KV 在 GPU 显存的保留时长，配合 program-level FCFS，真实 SWE-agent 最高 8.18× [2511.02230]。Continuum 的 L2 直接把 Halo 列为 related（见其 frontmatter），二者都做 program-level 优先/放置，但 Continuum 攻击的是 per-turn queueing delay 这个 Halo 未涉及的痛点。
• TokenCake (2510.18586) —— 双调度器（Temporal opportunistic offload + Spatial reserved/shared 分区）解决 tool-call 期间的 KV 空闲与 critical-path 反转，vLLM 上最高降 47.06% 延迟 [2510.18586]。与 Halo 共享"consecutive/critical operator 应保住 KV"直觉，但侧重 在线内存压力协调 而非 离线放置。

同族——KV-cache 复用机制（Halo 的组件级 peer）：

• KVCOMM (2510.12872) —— 训练无关的跨上下文 KV 复用：RoPE 去/重旋转对齐 + anchor 池偏移近似，多 agent TTFT 最高 ~7.8× [2510.12872]。这是 Halo 的 γ_v KV-reuse 折扣 [2509.02121] 的一种"高保真但有损"实现路径。

跨视角——瓶颈刻画 / 混合调度：

• CPU-Centric Characterization (2511.00739) —— 首次系统刻画 agentic AI 的 CPU 侧瓶颈：工具执行占 E2E 延迟高达 88%，提出 COMB（微批重叠）+ MAS（混合准入）[2511.00739]。该论文的 L2 也把 Halo 列为 related。它对 Halo 的"tool/API 调用有固定已知延迟"假设 [2509.02121] 构成正面挑战。

弱相关——正交但同类别（agent）：

• RouteLLM (2406.18665) —— 用偏好数据学习 query→模型路由，>2× 成本节省 [2406.18665]。与 Halo 共享"成本-质量优化"目标，但 RouteLLM 用 有损 模型替换换成本，Halo 坚持 exact answer 语义保持 [2509.02121]。
• Speculative Tool Calls (2512.15834) —— tool-level speculative execution，工具执行与主模型推理重叠，节省 6–21% [2512.15834]。是 Halo compute-communication overlap 思路在 工具边界 的推广。
• Agent Interoperability Survey (2505.02279) —— MCP/ACP/A2A/ANP 协议综述 [2505.02279]。与 Halo 几乎无技术重叠（协议 vs 引擎），仅在"multi-agent 需要系统级基础设施"这个 meta-level 相关；本篇后续分析主要围绕前 7 篇展开。

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

Halo 独有的新意（none of the peers do all three）：

1. 把 query optimization 塌缩为 GPU worker placement。 Halo 显式拒绝 rule-based rewrite / Volcano 优化器，改用 makespan 最小化 + beam search 求解器 [2509.02121]。所有 peer 里没有一篇做"数据库式 plan-level 优化"——Autellix/Continuum/TokenCake 都是 运行时调度策略，不构造 consolidated plan DAG。
2. consolidated batch DAG。 Halo 把 n 个同模板 query 合并成一张暴露共享计算的图 [2509.02121]。Autellix 逐 program 独立调度 [2502.13965]，KVCOMM 逐消息在线匹配 anchor [2510.12872]——都没有"批级 plan"这一层。
3. 同时统一放置 + KV 复用 + 模型权重复用 + 自适应批处理，用一个 profiled 成本模型（γ_v/σ_v/λ_v/β）串起来 [2509.02121]。peer 各自只覆盖其中一片：KVCOMM 只做 KV 复用，Autellix 只做调度，TokenCake 只做内存生命周期。

Incremental（Halo 把已有想法整合进来）：

• beam-search placement 明确继承 JellyBean（Halo 自己承认 [2509.02121]）。
• adaptive batching = ORCA continuous batching + vLLM phase-aware batching 的组合 [2509.02121]。
• "KV transfer 比 recompute 快 ~1 数量级"这个 premise 与 TokenCake（4096-token 迁移 63.7ms vs 重算 1815ms [2510.18586]）完全一致——两篇独立实验相互佐证同一物理事实。

Contradictory / 张力点：

• Halo 假设 tool/API 有固定已知延迟 [2509.02121]，使 scheduler 能确定性排布。这与 2511.00739 的核心发现——工具执行占 E2E 延迟高达 88% 且高度可变 [2511.00739]——以及 Continuum 观测的 tool 延迟长尾（cd 最慢 10% 占 94.1% 总延迟） [2511.02230] 直接冲突（详见 §3、§7）。
• Halo(t)（Transformers 后端）有时反超 vLLM 系 baseline [2509.02121]，而 Autellix/Continuum/TokenCake 全部 以 vLLM 为不可撼动的基座。这暗示 Halo 的收益部分来自 plan 层，与后端引擎质量部分解耦。

3. 可攻击面 #

攻击 1 — "固定已知工具延迟"假设站不住（最致命）。

Halo 明确假设外部 tool/API 调用有 fixed, known latency [2509.02121]，并以此把工具调用确定性地塞进 makespan。但同 cluster 的两篇实证论文直接反驳：

• 2511.00739 测得工具执行占 E2E 延迟 高达 88%，且 CPU 并行化在 BS=128 过早饱和 [2511.00739]——工具是主导项而非可忽略的固定常数。
• Continuum 测得 tool 延迟 高度长尾（SWE-Bench tool time 925±3550 ms，方差远大于均值）[2511.02230]。

矛盾根源：Halo 的评测 workload（W1–W6，Amazon/GSM8K/BBC/MT-Bench）里，"工具"实际是 SQL/检索/摘要这类 相对可预测 的操作，且它把注意力放在 LLM 推理 的 makespan 而非工具 CPU 时间；2511.00739 专门挑选 CPU-heavy 工具（FAISS ENNS、RDKit、LexRank）并显式测 CPU 分量。两者在各自 workload 内都正确，但 Halo 的固定延迟假设在 CPU-bound agentic pipeline 上会系统性低估真实 makespan。这是 Halo 的 scope 边界，L1 自己也标注该假设"可在更一般设定下放松"。

攻击 2 — "optimality 1.00" 的度量循环性。

Halo 报告自身 optimality = 1.00，RR/CoLoc/DP 为 0.20–0.40 [2509.02121]。但 optimality 若以 Halo 的 beam-search 解或其 cost model 为分母定义，则近乎自证。Autellix 更诚实地对比了 clairvoyant 最优 SRPT 并承认存在 visible gap [2502.13965]——Halo 缺少这种 "vs 真最优"的对照。更关键的反证：Halo 自己的 Table 4 显示 DP 在 2000 queries 时逼近到 4% 以内（577.18 vs 552.32）[2509.02121]，说明在大批次下朴素数据并行几乎追平"optimality 1.00"的 Halo——optimality 分数与实际延迟优势脱节。

攻击 3 — 缺 program-level HoL / 排队延迟处理。

Halo 是 offline batch + online mini-batch，其 online 模式只 buffer 固定时间窗 [2509.02121]。Autellix 证明这类"批处理式"策略在 program 级会产生 HoL blocking（MLFQ ≈ FCFS 甚至更差）[2502.13965]，Continuum 证明 per-turn queueing delay 占总延迟 58.2% 且随 turn 数累积 [2511.02230]。Halo 的 mini-batch 缓冲无法消除这类跨轮排队气泡——W5 online 只有 0.15 q/s 而 W1 有 26.8 q/s 的 ~180× 方差 [2509.02121] 可能正是长 workflow 排队气泡的征兆，但 Halo 未从这个角度诊断。

攻击 4 — 双版本 abstract 的可信度隐患。

L1 标注 Halo 存在两个 abstract：HTML/正文 18.6×/4.7×，arxiv listing 页 3.6×/2.6×（见 L1 §0 惊讶点）。~5× 的 headline 差异对可复现性是红旗；同 cluster 里 Continuum（github.com/Hanchenli/vllm-continuum [2511.02230]）和 RouteLLM（github.com/lm-sys/RouteLLM [2406.18665]）都有明确开源，Halo 只给了 Halo_demo 且 §7 标注 [实现未公开]（无行号映射）[2509.02121]，削弱了可审计性。

4. 生态位 #

范式定位：把"数据库 batch query optimization"移植到 agentic LLM serving。

Halo 是本 cluster 里唯一从 DB/query-optimization 血统（JellyBean、Volcano、TPC-DS、Dask/Spark 对比）切入的系统 [2509.02121]。其余 peer 血统各异：Autellix 来自 OS 调度（LAS/MLFQ/ATLAS）[2502.13965]，Continuum/TokenCake/KVCOMM 来自 KV-cache 系统，RouteLLM 来自 ML 分类/偏好学习，2511.00739 来自 计算机体系结构 profiling。这种"query planner 视角"是 Halo 的独特生态位，也是它能做 plan-level 优化而非仅 runtime 调度的根源。

时代信号。 这批论文（2025-Q3 到 2025-Q4 密集出现）标志 agentic serving 从"把 agent call 当独立请求"进入"感知 program/workflow 结构"的转折。Halo 处在最激进的一端——它不仅感知结构，还 主动重排 plan。Autellix 处在温和端——结构无关的 non-clairvoyant 调度，因此更通用（覆盖 chatbot/ReAct/MapReduce/MCTS 全部 DAG 模式 [2502.13965]），Halo 则要求 同模板批查询这一更窄但更可优化的场景。

采纳证据。 直接可见的引用链：Continuum 与 2511.00739 的 L2 都把 Halo 列为 related（frontmatter related 字段），说明 Halo 已进入 agentic-serving 社区的对照系。但 Halo 的 [实现未公开] 状态 [2509.02121] 相比 Continuum/RouteLLM 的完整开源，会限制其在生产中的直接采纳——它更可能作为 设计思想（consolidated DAG + placement）被吸收，而非 代码 被复用。

5. 未探索方向 #

方向 1 — clairvoyant plan + non-clairvoyant 调度的混合。

Halo 的离线 placement 假设完美信息，Autellix 假设零信息 [2502.13965]。真实场景介于两者之间：workflow 结构已知（clairvoyant），但工具延迟不可预测（non-clairvoyant）。一个混合系统可以用 Halo 的 consolidated DAG 做粗粒度 placement，再用 Autellix 的 program-level LAS + anti-starvation 做细粒度运行时纠偏——正好覆盖 Halo 的固定工具延迟假设崩塌时的鲁棒性缺口。

方向 2 — 把 Continuum 的 KV TTL 装进 Halo 的成本模型。

Halo 的 γ_v KV 复用折扣是 静态离线 profiled 常数 [2509.02121]。Continuum 的 TTL cost-benefit 模型（Cost = MemUsage/M × τ，含 memoryfulness factor η）[2511.02230] 提供了 动态、显存压力感知 的 KV 保留决策。把 η/TTL 逻辑接入 Halo 的 C_a^d [2509.02121] 可让"consecutive operator 保 KV"的粗粒度启发式变成量化最优——尤其在 online mini-batch 模式下。

方向 3 — KVCOMM 的有损近似作为 Halo 的第二档复用。

Halo 坚持 exact answer [2509.02121]，其 KV 复用只在"相同前缀"时触发。KVCOMM 证明 跨前缀 也能用 anchor 偏移近似复用且精度接近原始 [2510.12872]。Halo 可增设一个"近似复用"档位（在质量 SLO 允许时启用 KVCOMM 式偏移），把 γ_v 的适用面从"identical prefix"扩到"semantically-near prefix"——这是当前 8 篇里没人做的 exact/approximate 双档融合。

方向 4 — 工具边界 speculation 融入 placement。

Halo 把工具当固定延迟黑盒 [2509.02121]。2512.15834 的 speculative tool call 让工具执行与推理重叠（上界 <2×）[2512.15834]，2510.18586 用工具等待窗口做 opportunistic KV offload [2510.18586]。Halo 的 beam-search 若把工具节点建模为"可 speculate / 可 offload 的可变延迟"而非固定常数，就能在 placement 阶段主动预留 overlap 窗口——直接修补 §3 攻击 1 的假设漏洞。

方向 5 — CPU-aware placement。

Halo 的成本模型只显式建模 GPU 推理（prefill/decode）与 GPU 间迁移 [2509.02121]。2511.00739 证明 CPU 工具执行才是主导瓶颈，并给出 COMB 微批重叠 + MAS 异构准入 [2511.00739]。把 CPU 分量（ρ_CPU、B_cap）加进 Halo 的 T_p(v) 准备成本项，可让 makespan 从"GPU makespan"升级为真正的"CPU-GPU co-scheduled makespan"——这是把 Halo 从 LLM-centric 推向 pipeline-centric 的最实际方向。