L3 Synthesis: Autellix (2502.13965) — Program-Level Scheduling for LLM Agent Serving #

§1 相关论文 #

Autellix 占据 agent serving 调度 的中心位置——它首次将 OS 级进程调度思想（Least Attained Service）提升到 agentic program 级别，攻击 program-level HoL blocking。以下 8 篇论文从不同视角与之交叉：

调度与延迟优化——直接相关 #

• Continuum (2511.02230)：Autellix 的直接后继与批判者。Continuum 指出 Autellix 使用 end-of-turn eviction、忽略 KV cache 保留的重要性，提出 KV cache TTL 机制解决 per-turn queueing delay。二者共享同一研究组（UC Berkeley, Gonzalez & Stoica 实验室），Continuum 将 Autellix 作为 baseline 评测 [2511.02230]。

• PASTE (2603.18897)：与 Autellix 攻击不同的瓶颈维度。Autellix 优化 LLM call 间的 scheduling wait time；PASTE 通过投机执行 tool call 优化 tool 执行本身的等待时间。PASTE 的 profiling 显示 tool 执行占总时间 35–61% [2603.18897]，而 Autellix 的 Fig. 5 显示 wait time 在中等负载下主导延迟 [2502.13965]——二者识别的瓶颈互补且可叠加。

• CPU-Centric Perspective (2511.00739)：同样攻击 agent serving 延迟，但从 CPU 工具执行视角。其核心发现——CPU 工具执行占 E2E 延迟高达 88% [2511.00739]——揭示了 Autellix 未覆盖的盲区：即使 LLM call scheduling 完美，CPU-bound 工具仍是瓶颈。COMB 的 CPU-GPU 重叠思想与 PASTE 的投机执行在设计空间上有交集。

KV cache 管理——互补维度 #

• SideQuest (2602.22603)：用 LRM 自身作为 KV cache 垃圾回收器，通过并行辅助线程语义判断 tool response 是否过期。与 Autellix 的 locality-aware load balancer 互补——Autellix 决定 call 路由到哪个 engine 以最大化 intra-program cache hit；SideQuest 决定 engine 内部哪些 KV entries 可以被 evict [2602.22603]。

• Agent Memory Below the Prompt (2603.04428)：将 KV cache 以 Q4 格式持久化到磁盘，解决边缘设备多 agent 内存压力。与 Autellix 不在同一硬件层级（边缘 vs 数据中心），但共享核心洞察：agent 的 KV cache 是跨 turn 可复用的高价值资产 [2603.04428]。Autellix 通过 routing 保持 locality，Agent Memory 通过 persistence 保持 state。

上下文管理——扩展 agent serving 空间 #

• CMV (2602.22402)：将会话历史建模为 DAG，通过 structurally lossless trimming 管理 context window。与 Autellix 在不同层次工作——Autellix 在 serving 层管理 KV cache 的 GPU 内存占用和调度优先级；CMV 在 conversation log 层管理 token 数量和会话分支 [2602.22402]。二者互补且不冲突。

Agent 执行框架——理论定位 #

• SGH Framework (2604.11378)：将 Agent Loop 形式化为 $|\mathcal{U}|=1$ 的 scheduler，提出 Structured Graph Harness。Autellix 可被精确定位在 SGH 的坐标系中：它不改变 agent 的 $|\mathcal{U}|$（仍是 loop），而是优化 loop 内每个 LLM call 的 serving 层调度 [2604.11378]。SGH 关注 agent runtime 层的结构性并行；Autellix 关注 serving 层的 program-aware 调度——两个正交层面。

• Claude Code Architecture (2604.14228)：源码级解剖生产 coding agent 架构，揭示 "1.6% 决策逻辑 + 98.4% 确定性基础设施" 范式 [2604.14228]。Autellix 的 stateful session API 和 process table 属于这 98.4% 的 serving 基础设施。Claude Code 的 5 层 compaction pipeline 和 Autellix 的 locality-aware routing 解决同一类问题（agent workload 的 context/cache 管理），但在不同系统层次。

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

Delta 1: Program-level scheduling 是 Autellix 独有的贡献 #

所有相关工作中，只有 Autellix 识别并形式化了 program-level HoL blocking——长 program 的新 LLM call 在 MLFQ 中进入最高优先级队列，反复挤占短 program。PLAS/ATLAS 的 key insight 是新 call 必须继承 program 累计 service 而非从零开始 [2502.13965]。Continuum 虽然也做 program-level 调度（program-level FCFS），但其调度目标不同——Continuum 用 FCFS 近似 SRTF [2511.02230]，Autellix 用 cumulative attained service 做 non-clairvoyant 最优。

Delta 2: Autellix 不管理 KV cache 保留——后续工作的核心批判点 #

Continuum 明确指出 Autellix 使用 end-of-turn eviction，忽略了 KV cache 在 tool call 间隙的保留价值 [2511.02230]。Autellix 的 locality-aware load balancer 追求 intra-program cache locality（长 call 路由到 primary engine），但不解决 inter-turn KV 驱逐问题。SideQuest 和 Agent Memory 从不同角度（语义 eviction、持久化）填补这一空白。

Delta 3: 对 tool 执行层的盲区 #

Autellix 将 tool call 视为 external interrupt，不对其建模或优化。PASTE 的 profiling 证明 tool 执行占 E2E 延迟 35–61% [2603.18897]，CPU-Centric Perspective 进一步证明 CPU 工具处理最高占 88% [2511.00739]。Autellix 的 4–15× throughput 提升来自纯调度优化；如果叠加 PASTE 的投机执行或 COMB 的 CPU-GPU 重叠，端到端改善空间更大。

Delta 4: 多线程 program 的 ATLAS 设计独到 #

ATLAS 用 $\max s_i$（critical path）而非 $\sum s_i$ 作为多线程 program 优先级 [2502.13965]。这避免了高并行度 program（如数十线程 MCTS）被 sum 过度惩罚。相关工作中无人做过等价设计：Continuum 不支持多线程 program（仅 ReAct 单线程），SGH 在 agent runtime 层做并行而非 serving 层，PASTE 的投机执行是 per-call 级别不涉及 program 结构。

Delta 5: 非 clairvoyant 调度的理论连接 #

Autellix 是唯一将 LAS 的 DHR 分布 optimality 理论与 agent serving 联系起来的工作 [2502.13965]。Fig. 18 量化了 non-clairvoyant 调度与最优 SRPT 之间的 gap。其他工作要么不提供理论连接（Continuum、PASTE），要么提供不同类型的理论（SGH 的 bounded termination 证明）。

§3 可攻击面 #

攻击 1: SGLang 缺席评估 #

Autellix 反复引用 SGLang 作为 predecessor（有 prefix caching 和 program-level constructs），却未将其作为 baseline 评测 [2502.13965]。SGLang 的 RadixAttention tree-based caching 与 Autellix 的 session-based routing 可能有复杂交互——SGLang 可能已隐式捕获部分 intra-program locality，削弱 Autellix 的增量贡献。

攻击 2: 工作负载分布假设未验证 #

PLAS/ATLAS 的理论优越性依赖工作负载服从 DHR（Decreasing Hazard Rate）分布——即 Pareto/log-normal 类重尾分布 [2502.13965]。论文使用 synthetic workloads 基于 real trace distributions（ShareGPT/LMSYS-Chat-1M），但未 formal 验证这些分布是否满足 DHR 条件。如果实际 production workload 是 bounded/uniform 分布，LAS 的 optimality 不成立。

攻击 3: Continuum 的 per-turn queueing delay 反驳 #

Continuum 的实测数据显示即使 CPU offloading 使 KV reload 近乎免费，scheduling bubbles 仍占总延迟 58.2% [2511.02230]。Autellix 的 PLAS/ATLAS 调度虽改善 program-level 排序，但不解决 tool call 返回后的排队问题——因为 Autellix 在 tool call 间隙已 evict KV cache，returning program 必须重新排队等待 GPU 空间。

矛盾根源: Autellix 将 program latency 分解为 wait time + execution time + interrupts，将 interrupt（tool call）视为不可优化的外部因素。Continuum 证明 interrupt 返回后的 re-queueing delay 是一个独立的、可通过 KV retention 消除的瓶颈。二者在各自框架内都正确，但 Autellix 的 latency decomposition 遗漏了这一项。

攻击 4: 代码未开源，可复现性受限 #

论文未提供 public repository [2502.13965]。核心修改涉及 vLLM scheduler 的 queue assignment 逻辑（新 call 按 program cumulative service 分配初始队列而非 $Q_1$），以及 batched KV-cache swap 优化。缺乏代码使独立验证困难，且无法确认 18× swap reduction 的实现细节。

攻击 5: Anti-starvation 的 $\beta$ 选择缺乏理论指导 #

Anti-starvation 阈值 $\beta$ 的有效范围（wait/service ratio 3–7）完全基于经验 [2502.13965]。不同 workload 分布下 $\beta$ 的最优值可能差异显著，论文未提供自适应机制或理论推导。

§4 生态位 #

时代定位 #

Autellix（2025-02）是 agent serving 调度范式的开山之作。在它之前，LLM serving 系统（vLLM、SGLang、FastServe）将每个 LLM call 视为独立请求，完全无视 program-level context。Autellix 首次论证了"program 是一等公民"的 serving 理念，其 process table + stateful session 设计成为后续工作的共同参照。

Adoption 证据 #

• Continuum (2511.02230) 直接将 Autellix 作为 baseline，在 OpenHands/SWE-Bench 上超越之 [2511.02230]。
• SGH (2604.11378) 引用 Autellix 的"process-level scheduling"作为 serving 层的实例 [2604.11378]。
• Claude Code (2604.14228) 的 stateful session 设计与 Autellix 的 stateful API 同构——从 ephemeral per-request 到 persistent per-session 的转变已成为 production agent serving 的事实标准 [2604.14228]。

范式影响 #

Autellix 开创了两个被后续工作继承的设计模式：

1. Process table 抽象：将 program 的 cumulative state（service time、active threads、waiting time）集中管理，为调度决策提供 program-level context。Continuum 的 TTL map 和 PASTE 的 event window 都是此思想的变体。
2. Non-clairvoyant program scheduling：证明不需要预知 program 结构也能有效调度——仅依赖已完成 call 的 runtime 统计。这一"用过去预测优先级"的范式被 Continuum 的 FCFS 和 PASTE 的 pattern mining 从不同角度继承。

§5 未探索方向 #

方向 1: Program-level scheduling + KV cache TTL 联合优化 #

Autellix 的 PLAS/ATLAS 调度与 Continuum 的 KV cache TTL 分别攻击 scheduling priority 和 cache retention，但从未被联合设计。一个自然的组合：用 program cumulative service 决定 call 优先级（PLAS/ATLAS），同时用 cost-benefit model 决定 KV cache 保留时间（TTL）。TTL 决策可以反馈到调度——high-TTL program 的 returning call 无需排队，低 TTL program 的 call 需要重新 prefill 因此应获得更高优先级补偿。

方向 2: Speculative tool execution + program scheduling 融合 #

PASTE 证明了 tool 调用是可预测的（27.8% Top-1, 93.8% overall hit rate）[2603.18897]。Autellix 可以利用 tool call 的预测信息做更好的调度：如果 predictor 认为当前 program 的 tool call 很快返回（如 file read），可以 pin 其 KV cache 而非 evict；如果 tool call 预计很慢（如 web fetch），可以 evict 并 deprioritize。这将 Autellix 的 scheduling 从 reactive（基于过去 service）转向 proactive（基于预测 future）。

方向 3: CPU-GPU co-scheduling for agentic workloads #

Autellix 只调度 GPU-side LLM calls。CPU-Centric Perspective 证明 CPU 工具执行占 E2E 延迟高达 88% [2511.00739]。一个统一的 CPU-GPU co-scheduler 可以同时感知 LLM call 的 GPU 调度状态和 tool execution 的 CPU 调度状态，在 tool 执行期间释放 GPU 给其他 program 的 LLM calls，tool 返回时恢复优先级——将 COMB 的 CPU-GPU 重叠理念提升到 program-level。

方向 4: Model-driven eviction 与 program-aware scheduling 的层次组合 #

SideQuest 证明 LRM 自身可以做 KV cache 的语义 eviction（56–65% token 降幅）[2602.22603]，但其 eviction 决策与 serving-layer 调度无关。一个层次化设计：SideQuest 在 engine 内部做 intra-program 的语义 eviction（淘汰过期 tool response），Autellix 在 engine 间做 inter-program 的 priority scheduling（决定哪个 program 的 call 先执行），二者通过 eviction 释放的显存反馈到调度——更多空闲显存允许更大 batch size，更大 batch 进一步改善 program throughput。

方向 5: 边缘设备上的 program-aware serving #

Agent Memory 证明了 Q4 KV cache 持久化在边缘设备上的可行性（4× agent 容量，PPL 影响 <3%）[2603.04428]。Autellix 的 PLAS/ATLAS 算法轻量（仅需 process table 查表），可以移植到边缘设备上管理多 agent 的 KV cache 调度——用 program cumulative service 决定哪个 agent 的 cache 应被 evict 到 SSD，哪个应驻留内存。结合 Agent Memory 的虚拟内存类比（block pool = page table，SSD = swap），形成边缘级 agent serving scheduler。