2026 Agentic serving 研究地图：从 request serving 到 program serving

1. 证据规则：2026 论文不能诚实地叫“高引用”

当前日期是 2026 年 7 月，大多数 2026 年论文发表不过数月，引用数还不稳定。本页因此检查会议同行评审情况、官方生产部署或开源仓库，以及能否复核实验设置和数字。较早且已有影响的基础论文会明确标为 2022 或 2024 年，不会改写成 2026 年工作。

2. 研究问题可以分成六层

3. 历史基础一：ORCA 与 SGLang 把粒度从请求降到迭代和结构化程序

ORCA（OSDI 2022）提出 iteration-level scheduling 与 selective batching，说明请求不必固定占住 batch 直到结束；这是今天 continuous batching 的重要基础。论文在 GPT‑3 175B 设置中报告相同延迟下相对 FasterTransformer 最高 36.9× 吞吐。

SGLang（NeurIPS 2024）用前端语言表示复杂 LLM 程序，并用 RadixAttention 自动复用结构化前缀；原论文报告最高 6.4×。到 2026 年，官方仓库已包含连续批处理、P/D、TP/PP/EP/DP 与广泛模型/硬件支持。论文年份是 2024，当前实现状态是 2026，二者应同时写清。

4. 历史基础二：Parrot 把 prompt 语义和应用 DAG 交给服务端

Parrot（OSDI 2024）引入 Semantic Variable，显式暴露 LLM 应用的数据流、prompt 结构和依赖，使服务端可以做跨调用调度、上下文复用与并行。论文报告最高达到数量级改善。

到 2026 年，ParrotServe 官方仓库 README 仍明确称其为 research prototype，且已不再 actively maintained。它的抽象仍有研究价值，但该仓库不适合作为生产 runtime 推荐。

5. 历史基础三：InferCept 处理工具/API 调用造成的中断

InferCept（ICML 2024）关注 inter-request dependency：生成到一半调用工具/API，随后带结果恢复。如果 runtime 丢弃 KV，就要重算；一直保留又浪费 HBM。论文提出拦截与生命周期管理，报告旧做法的重算可占 37%–40% forward time，并实现 1.6–2× throughput、约 2× requests/s。

InferCept 给出了暂停与恢复的基础问题定义，2026 年系统又加入程序级优先级、跨层 KV tier 和动态 DAG。工具等待期间，请求仍是一段带有高价值状态的 suspended computation，不能按“已完成”处理。

6. 历史基础四：DistServe 的 PD 分离是 Agent 长上下文的底座

DistServe（OSDI 2024）将 prefill 与 decode 放在不同 GPU，分别优化 TTFT 与 TPOT，并传输 KV。论文报告在其设置下可服务 7.4× 请求或满足 12.6× 更严格 SLO，超过 90% 请求满足约束。

Agent 常见的长 prompt、短回合输出和高 prefix hit 有利于 P/D 分离，同时会带来频繁的增量 prefill、KV affinity 与工具等待。2026 年研究沿用 DistServe 的基础，将固定两阶段分离扩展到 token split、异构硬件和 program-aware routing。

7. 2026 总览：研究单位从 request 变成 program、operator 和 state

2026 工作共同改变了调度器看到的对象：Agentix 看 program；Murakkab 看 workflow component；Helium 看 query-plan operator；CacheSlide/DroidSpeak 看可转换的 KV state；Software-Defined Agentic Serving 看可编程控制平面；VibeServe甚至让 agent 生成专用 serving system。

这些抽象并不互斥。一个生产栈可能用 Murakkab 选择模型，用 Agentix 排关键路径，用 SGLang/vLLM 执行 token iteration，用 Dynamo/LMCache 管 KV，再由 tool gateway 执行外部动作。

8. Agentix（NSDI 2026）：把 Agent program 设为一等调度对象

vLLM 类 runtime 只看到独立模型请求，不知道某次短调用是否位于一段即将完成的程序关键路径。Agentix 接收 program 结构，通过 program-aware preemption 和 scheduling 在节点之间协调 GPU 时间与状态。

NSDI 官方页报告，在相同 latency 下，program throughput 相对 vLLM 提升 4–15×。未来分支和工具耗时仍不可知；跨租户采用“接近完成优先”还需公平约束，实际收益取决于 workflow 的多阶段程度。

9. Murakkab（OSDI 2026）：workflow、模型和硬件联合优化

Agent 的各个 component 未必需要同等强的模型，全部固定到大模型上会浪费成本。Murakkab 提供 declarative workflow abstraction，由 profile optimizer 选择模型与硬件映射，adaptive runtime 再随负载和执行变化调整。

OSDI 官方页报告，在满足 SLO 时，GPU 使用最高减少 2.8×、能耗 3.7×、成本 4.3×。质量约束需要按 workload 校准，profile 在新任务或新模型上可能漂移，在线重映射也会触发冷启动和 cache 失效。

10. CacheSlide（FAST 2026）：缓存中段变化后的长 prompt

Agent 在 prompt 中部插入工具结果或更新状态后，后续 token 的位置会变化，普通 exact-prefix KV reuse 只能停在插入点。Relative-Position-Dependent Caching 按相对位置依赖组织可复用状态，让更多后缀继续命中。

FAST 官方页报告延迟降低 3.11–4.3×、吞吐提升 3.5–5.8×。正确性与模型的位置编码和 attention 结构绑定，不兼容模型必须回退，缓存 metadata 与重组本身也有成本。

11. DroidSpeak（NSDI 2026）：在微调模型之间共享 KV

Agent 的不同节点若使用同一 base 的多个 fine-tuned model，普通 cache namespace 会把它们完全隔离，长前缀因此被重复计算。DroidSpeak 找出必须重算的少量层，并把重算与 KV load 流水化。

NSDI 官方页报告吞吐最高 4×、prefill 最高 3.1×，质量损失可忽略。这里的“可忽略”受模型对和任务集限制；模型差异越大，需要重算的层越多，跨模型 cache versioning 也更复杂。

12. PrefillShare（2026）：从模型架构上设计共享 prefill

任意两个微调模型的 KV 很难在事后判断兼容性。PrefillShare改为让 task-specialized 模型显式共享冻结的 prefill module，使共享前缀只计算一次，再进入各任务分支。

预印本报告 P95 latency 降低 4.5×、吞吐提高 3.9×。该方案需要训练与架构协同，无法透明套用到任意现有 checkpoint；冻结共享模块还可能限制任务特化能力，因此质量、版本升级和 fallback 需要一并评估。

13. Helium（2026）：把 workflow 当 query plan

数据库会按 operator 代价、依赖和物化结果优化 query，Agent runtime 却常按调用顺序逐个执行。Helium把 workflow 表示为 query plan、LLM call 表示为 operator，主动管理 cache 并执行 cache-aware scheduling。

预印本报告最高 1.56×。LLM operator 的输出长度、质量和分支比关系数据库算子更不稳定，side-effect tool 也不能任意重排，因此代价模型需要持续在线更新。

14. Software-Defined Agentic Serving（2026）：可编程控制平面

Agent runtime 同时处理模型请求、tool RPC、KV movement、streaming 和多租户 policy，控制逻辑容易散落在应用中。该工作借鉴 SDN，将策略与数据面分离，提供可编程的 agentic-serving control plane 和 runtime communication control。

“关键路径优先”“工具流量限速”和“KV locality”因此可以集中配置，不必由每个框架各写一套。代价是中央控制需要低延迟与高可用，错误策略还会放大故障。论文目前是预印本，部署成熟度需要另行验证。

15. VibeServe（2026）：由 Agent 合成专用 serving system

通用 runtime 很难逐一适配非标准模型、硬件或 workflow。VibeServe让 agents 根据 workload 生成 bespoke serving systems，并提供官方代码。论文称其在标准场景有竞争力，并在六个非标准场景胜出。

自动生成系统仍要面对正确性、内存安全、数值等价、死锁和回归验证成本。更稳妥的做法是让 agent 生成候选，再通过固定 test suite、trace replay 与性能门禁筛选，而非直接部署生成代码。

16. AgenticCache（2026）：缓存的是计划与轨迹，不只是 KV

相似任务会重复规划、探索和工具调用，而 KV cache 只能复用 token 计算，不能直接复用成功策略。AgenticCache利用 plan locality，并通过异步后台 updater 维护 cache；代码仓库已经公开。

论文报告成功率提高 22%、模拟延迟降低 65%、token 减少 50%。计划缓存属于语义级复用，旧计划可能随环境变化而失效。命中前必须核对工具权限、资源版本与目标差异，不能像数值 KV 一样透明复用。

17. 相邻的 2026 serving 工作：它们不叫 Agent，却直接影响 Agent

Libra允许请求在任意 token 边界拆成 micro-request，适合 Agent 各阶段动态迁移；报告 goodput 最高 1.91×/1.61×。SYMPHONY分离 KV memory，适合长寿命上下文；报告 2.4× 低延迟、4× 请求数。load-aware prefill deflection针对长 prompt 排队，把部分 prefill 移到 decode worker；2P2D A100 实验报告 P95 TTFT 降 81%。

这些系统优化的是 Agent 的底层资源，而不是 program semantics。正确组合方式是 program scheduler 给出 node urgency/cache hint，底层 runtime 决定 token、KV、worker 和链路。

18. 横向比较：改了什么层，状态放在哪里

19. 怎样选研究路线，而不是堆全部系统

1. 若 70% 时间在长 prompt 重算，先做 prefix/Radix、CacheSlide 类缓存，再谈 program 调度。
2. 若 GPU 空闲而 E2E 慢，分解工具等待与 DAG critical path，使用 Agentix/Helium 类抽象。
3. 若不同节点固定用大模型，做 Murakkab 类模型选择和质量约束。
4. 若微调模型重复 prefill，评估 DroidSpeak/PrefillShare 的兼容边界。
5. 若失败来自老计划与环境漂移，AgenticCache 必须带版本验证，而非盲目命中。

20. 落地的最小公共接口

submit_program(program_id, graph_hint, deadline, tenant)
submit_node(node_id, model_candidates, context_refs, side_effect_policy)
pause_node(node_id, expected_resume_distribution)
resume_node(node_id, appended_context)
cache_hint(prefix_id, scope, reuse_horizon)
complete_node(node_id, output_ref, actual_cost, successors)
cancel_subgraph(root_node, reason)

这些接口足以连接 workflow controller 与现有 vLLM/SGLang/Dynamo，不必先重写 token runtime。接口中的 hint 可以不准确，但版本、权限、幂等和完成状态必须准确。

21. 统一复现框架

同一批 workflow trace 分别跑 request-only 与 program-aware。固定模型、工具模拟器、GPU、prefix 分布和失败注入；每项研究机制只开一个变量。公开原始 trace 与 scheduler event，避免只给最后倍数。

workload axes:
serial depth, fan-out, branch probability, tool latency/failure,
shared-prefix tokens, model switches, context growth, tenant skew

metrics:
program goodput, task success, E2E tail, critical-path idle,
GPU seconds/success, KV bytes, tool duplicates, fairness

22. 一手来源总表