Agentic serving：工具调用为什么让普通 LLM 调度器失效

1. Agentic serving 与普通 chat serving 的边界

普通 chat 也有多轮，但服务器通常只看到一次次独立 API 请求。Agentic serving 让 runtime 或上层控制面看到整个程序：节点是 LLM、embedding、reranker、代码执行、浏览器、数据库等调用；边是数据与控制依赖。系统可以据此预测下一次模型调用、预取 KV、安排关键路径和隔离危险工具。

2. 前置：把 Agent 表示成动态 DAG

静态 DAG 可在运行前列出所有节点；真实 Agent 的后续节点由模型输出决定，因此只能逐步展开。控制面至少保存 program id、node id、父边、deadline、模型候选、上下文引用、重试策略和 side-effect 标记。

工具的副作用会改变重试语义。搜索读取通常可以安全重试，发邮件或写数据库却不能因超时自动重复。serving runtime 即便不直接执行工具，也要把幂等性和取消语义传给 workflow scheduler。

3. 一次 Agent 任务的完整数据流

1. 接收用户目标与 program-level deadline，建立 trace 和状态存储。
2. 选择 planner 模型，构造 system/tool schema/repo context，prefix lookup 后 prefill/decode。
3. 解析结构化 tool call，校验权限和参数；LLM KV 进入短暂停留或降层状态。
4. 执行工具；可并行的工具由 DAG 同时发起，结果带 provenance 和大小元数据。
5. 将工具结果追加上下文，增量 prefill；必要时换小模型做摘要、rerank 或 verifier。
6. 若验证失败，产生 repair branch；若完成，输出答案并按策略保留共享 prefix、删除私有状态。

每一步都可能排队或失败，所以只测单次 LLM TPOT 不能代表 Agent latency。系统需要 program-level completion、成功率、token 成本和工具外部时间。

4. 为什么 request-level FCFS 会错

假设 Agent A 已完成 9/10 个节点，只差一个短 verifier；Agent B 刚开始一个 100K planner prefill。按到达时间跑 B 会让 A 的整项任务延迟大幅上升，尽管 A 剩余 GPU 工作很小。反之，如果每个 Agent 都在最后一步，就需要公平规则避免新任务永久饥饿。

Agentix（NSDI 2026）把 agent program 视为 first-class object，用 program-aware preemption 与 scheduling；论文报告在相同延迟下，program throughput 相对 vLLM 提升 4–15×。倍数来自论文工作负载，不表示所有 Agent 都有相同收益。

5. 程序级调度：关键路径、解锁价值与公平

一个节点完成可能解锁多个并行工具，价值高于一个不会解锁后续的同长请求。调度器可估计节点对 critical path 的影响，并保留租户配额：

估计会错，因此需要在线更新：模型实际输出长度、工具完成分布、MTP 接受率和 prefix 命中都会改变剩余工作。scheduler 应允许抢占，但设置最小驻留与迁移成本，避免计划频繁翻转。

6. 工具等待时：保留、换出还是重算 KV

工具等待是 Agent 与 chat 的系统差异之一。等待期间不需要 GPU compute，却可能占数十 GB KV。选择取决于工具延迟分布、上下文长度、恢复概率和 tier 带宽。

透明缓存层只能做数值等价的存储/量化；改变上下文语义的摘要必须由 Agent/app 明确授权并经过质量评估。

7. Agent 的前缀为什么特别适合缓存

Agent prompt 常含稳定的 system instructions、几十 KB 工具 schema、repo snapshot 和先前轨迹。多轮只在尾部追加工具结果，因此 radix/prefix cache 能复用大段 KV。缓存价值应按 hit tokens 而不是 hit request 数统计。

GLM‑5.2 的 2026 SGLang 官方 OpenHands workload 约为每轮 80K 输入、220 输出，共 13 轮，aggregate cache hit 达 92%。这个数字证明特定 coding-agent trace 有强 locality，但不能代表所有 Agent：网页浏览的内容变化、不同 repo 或动态 tool schema 都会降低命中。

8. 中段插入为什么会破坏普通 prefix cache

很多 Agent 会在固定系统前缀与历史尾部之间插入最新工具结果。绝对位置编码下，中段变化使后续 token 的位置改变，普通 prefix reuse 到插入点就停止。CacheSlide（FAST 2026）提出 Relative-Position-Dependent Caching，使缓存能适应这种 agent prompt 变化；论文报告延迟降低 3.11–4.3×、吞吐提升 3.5–5.8×。

这种缓存依赖具体位置编码与 attention 语义，不能仅靠重写 block hash 实现。部署前必须验证输出等价或质量边界，并把不兼容模型回退到普通 prefix cache。

9. 多模型工作流：模型选择也是调度

planner、executor、verifier 不一定需要同一模型。小模型可处理 schema 校验或简单工具选择，大模型只处理困难节点。选择器要同时估计质量、延迟、GPU 价格、cache 是否可复用和模型冷启动。

Murakkab（OSDI 2026）用声明式 agent workflow、profile optimizer 和 adaptive runtime 把组件映射到模型/硬件；论文报告在满足 SLO 时 GPU 使用最高降低 2.8×、能耗 3.7×、成本 4.3×。

10. 多个微调模型能否共享同一段 prefill

若多个 task-specialized 模型共享冻结的 prefill module，前缀 KV 可以只算一次，再进入不同后续模型。PrefillShare（2026 预印本）提出这种结构，报告 P95 延迟降低 4.5×、吞吐提高 3.9×。DroidSpeak（NSDI 2026）则研究 fine-tuned model 间 KV sharing，只重算少数层并流水化重算/加载，报告吞吐最高 4×、prefill 最高 3.1×。

跨模型共享不是普通 cache hit。只有数学兼容的层才能直接复用，其余层必须重算；质量评估应覆盖工具选择、长链推理和边界任务，不能只测困惑度平均值。

11. Agent SLO：从 TTFT 扩展到任务完成

用户关心的是任务完成时间、成功率和中途反馈。一个 Agent 可能每次 LLM TTFT 都达标，却因工具排队、错误重试或 verifier 串行化而超时。应同时定义：

• node-level：LLM TTFT/TBT、tool queue/execute、cache load。
• program-level：time-to-first-progress、E2E completion、critical-path idle。
• quality-level：task success、tool error、无效重试、side-effect duplicate。
• cost-level：总 input/output token、GPU seconds、外部 API 与存储费用。

12. 取消、重试、分支和副作用

当父节点被取消，尚未开始的子节点应取消，运行中的只读工具可中断；有副作用的工具要查询幂等 key，不能盲目重发。speculative branch 若未被采用，其 KV、GPU slot 和工具请求都应尽早回收。

tool_call_id = hash(program_id, node_id, attempt_semantics)
side-effect tool:
  prepare → durable intent → execute once → commit result
retry reads committed result instead of repeating the effect

LLM streaming 取消也要传播到 executor；仅断开 HTTP 而 GPU 继续生成会制造“幽灵 token”成本。

13. 多租户隔离与安全

Agent 比 chat 拥有更强外部权限。serving 控制面应把模型执行身份、工具权限与用户身份绑定，tool schema 不能成为绕过 policy 的任意 RPC。KV/prompt cache 默认 tenant-scoped，共享 system prefix 必须由平台标记为公共且不可包含私密状态。

• 每个 tool node 进行参数 schema、权限、速率和数据域校验。
• 沙箱代码执行与模型 worker 分离故障域。
• trace 中敏感 prompt、tool result 只保存摘要/受控引用。
• 程序级 quota 同时限制 GPU token、并发工具、存储和最长 wall time。

14. 2026 的系统主线

15. 一个可实现的 Agent serving 架构

LLM runtime 仍负责 token iteration、KV page 与 sampling；program controller 不应重复实现底层 scheduler。二者通过 node metadata、pause/resume、cache hints、deadline 和 completion event 协作。

16. 具体例子：代码修复 Agent 的 13 轮执行

首次请求加载 60K repo context、15K system/tool schema 和 5K issue；planner 产生搜索与测试工具。工具等待时保留共享 75K prefix、尾部 KV 降到 DRAM。搜索返回后只增量 prefill 2K；code writer 输出 patch，测试失败后 verifier 解锁 repair node。最后一轮只需短 decode。

程序级 scheduler 会优先让已通过大部分测试、只差短 verifier 的任务完成；prefix-aware router 尽量返回已有 80K KV 的 worker；tool gateway 用 patch/test idempotency key 防止重复提交。三个控制点共同决定 E2E，不是单个模型 token/s。

17. 实现与部署清单

• 为所有 LLM/tool 节点统一 trace id、program id、node id 和 attempt。
• 保存 DAG 状态与 side-effect commit，worker 崩溃后可重放但不重复副作用。
• 把工具延迟预测与 KV tier policy 联动；记录预测误差。
• router 使用 hit tokens + load + transfer cost，不只用 session affinity。
• 不同模型间共享 KV 前先建立兼容矩阵和质量测试，默认不共享。
• 设置 program wall-time、token、工具调用、分支数四类上限。
• 评测包含失败工具、慢工具、分支爆炸、取消与模型冷启动。

18. 局限：看到程序也不会自动得到最优调度

Agent 的未来分支、输出长度与工具时间都不确定，program-aware 估计可能偏差很大。保留已投入大量 GPU 的任务有利于完成吞吐，却可能伤害新租户公平；缓存粘性提高命中，也可能制造热点。系统需要显式政策、在线校准和保守回退。

19. 最小复现实验

构造三类 workflow：串行 10 轮、4 路工具 fan-out、失败后 repair loop。输入含 80K 共享 prefix，工具延迟从 50 ms 到 10 s，加入 1% 超时与取消。比较 request FCFS、node shortest-job、program critical-path、program+cache-aware。

必须报告：
program success goodput, E2E P50/P95/P99, time-to-first-progress
LLM TTFT/TBT, tool wait, critical-path idle
GPU seconds/success, total tokens/success, discarded branch tokens
KV HBM/DRAM bytes, prefix hit tokens, migration/recompute
per-tenant slowdown and starvation

20. 一手来源