Sutradhara: An Intelligent Orchestrator-Engine Co-design for Tool-based Agentic Inference

framework 2601.12967

agentkv-cacheschedulingservinglatency-optimization

← Synthesis ← framework Survey Source ↗

Sutradhara: An Intelligent Orchestrator-Engine Co-design for Tool-based Agentic Inference #

Paper ID: 2601.12967
Authors: Anish Biswas, Kanishk Goel, Jayashree Mohan, Alind Khare, Anjaly Parayil, Ramachandran Ramjee, Chetan Bansal
Affiliations: Microsoft Research, M365 Research
Published: 2026-01-19
Categories: cs.DC
URL: https://arxiv.org/abs/2601.12967

Phase 2: 综合分析 #

2a. 核心三问 #

Q1: 这篇论文试图解决什么核心痛点/问题？

Agentic LLM 应用（即 LLM 通过迭代式 tool 调用完成复杂任务）正在成为生产环境中部署 LLM 的主导范式。然而，现有系统存在三大关键瓶颈：

Tool 执行延迟主导尾部 FTR（First Token Rendered）：tool 调用占据 FTR 延迟的 30-80%，远非传统认知中"轻量 I/O 操作"；
顺序编排浪费并行性：当前系统在 LLM decode → tool 执行 → 下一次 prefill 之间强制串行，60-80% 的下一轮 prefill 内容实际上不依赖 tool 输出；
KV Cache 抖动（thrashing）破坏复用：workload-agnostic 的 LRU 驱逐策略在多个 agentic 请求并发时导致级联驱逐，摧毁大量可复用的 KV cache。

这三大问题的根源是架构性设计缺陷：orchestrator 和 LLM engine 作为解耦的黑箱运行，通过不透明的 request-response 接口通信，无法实现跨层优化。

Q2: 作者提出了什么新的"杀手锏"方法/架构？

提出 Sutradhara，一个 orchestrator-engine 协同设计（co-design）的 agentic 推理系统，通过 5 个新 API 实现 orchestrator 与 LLM engine 之间的语义信息传递：

Prompt Splitting + Tool 执行重叠：将 iteration $i+1$ 的 prompt 分为 tool-independent 和 tool-dependent 两部分。当 iteration $i$ 的 tool 在执行时，立即开始 prefill tool-independent 部分（submit_partial_prefill()），tool 结果返回后通过 extend_prefill() 补全；
Streaming Tool Dispatch：通过 register_streaming_callback() 实现 token 级回调，利用流式 JSON parser 在 decode 过程中识别完整的 tool call JSON 对象并立即分发执行，而非等待完整 decode 输出；
Workload-Aware KV Cache 管理：通过 tag_kv_blocks() 和 set_reuse_priority() 给 KV 块打语义标签（SYSTEM_PROMPT / USER_QUERY / TOOL_OUTPUT / RESPONSE / PARTIAL_PREFILL），实现优先级驱逐策略，结合请求感知调度（按 agentic 请求到达时间排优先级）。

Q3: 最终效果/结论如何？

在 A100-80GB GPU 上使用 Qwen3-14B 和 Gemma-12B 评估：

中位 FTR 延迟降低 15%，P99 FTR 降低 12.3%
端到端延迟降低 10%
无吞吐量损失
Ablation 显示：Prompt Splitting 贡献 7.57% FTR 改进，Streaming Dispatch 额外贡献 4.2%
实现仅需 3500 行 Python 代码，基于 vLLM v0.11.0，无需修改模型架构或推理 kernel

2b. 逻辑故事还原（约束推导型） #

时代定位 #

2024-2026 年，LLM 从单轮 query-response 范式快速演进到 agentic 架构，通过迭代式 tool 调用（ReAct、AutoGen、LangChain 等）完成复杂任务。然而，推理系统的优化一直聚焦在单次 LLM 调用的 TTFT 和 per-token 延迟上（PagedAttention、continuous batching、chunked prefill 等），对 agentic workload 的多迭代、多 tool 调用结构缺乏系统性认知。本文是首个大规模实证分析 agentic 推理性能的工作，揭示了 orchestrator-engine 解耦这一架构性设计缺陷。

背景：为何现有方法无法解决？ #

现有系统的核心问题是层级隔离：

Orchestrator 知道：迭代边界、prompt 组成、tool 依赖关系、哪些 prompt 片段依赖 tool 输出
LLM Engine 知道：调度、batching、KV cache 管理
两者互不通信——orchestrator 发送完整 prompt 等待完整回复，engine 把每次 LLM 调用视为独立请求

这导致三个 "不可能"：

无法重叠：engine 不知道 prompt 的哪部分可以提前 prefill
无法提前分发 tool：engine 的 decode 输出只有完全结束后才到达 orchestrator
无法智能驱逐：engine 不知道哪些 KV block 即将被同一 agentic 请求的下一个 iteration 复用

约束推导：替代方案为何失败？ #

替代方案	为何不可行
静态 DAG 编排 (Parrot, Murakkab)	Tool-based agentic 应用的 DAG 结构事先未知，工具调用取决于 LLM 实时推理结果
非透视调度 (Autellix)	仅优化吞吐量，不解决 intra-request 的 tool 延迟问题
预测 tool 执行时间 (Continuum)	tool 执行时间变异系数超过 100%（如 web search），使预测变得不切实际
Partial tool execution (Conveyor)	生产环境中多数 tool 无法在参数不完整时执行
纯 KV cache 共享 (KVFlow, DroidSpeak)	未考虑 tool 调用对延迟的显著贡献（30-80% FTR），仅优化 cache 层面

破局：Aha Moment #

关键洞察是 prompt 的 tool-independent 部分占 50-80%——system instructions、conversation history、templates 不依赖 tool 输出。这意味着 orchestrator 可以在 tool 执行期间就开始下一轮的 prefill 计算，只要 engine 提供 partial prefill + extend 的接口。第二个洞察是 LLM 生成 tool call 是流式 JSON，一个完整的 tool call object（到 } 闭合时）就可以立即分发，无需等待整个 JSON array。

核心技术壁垒 #

Partial Prefill 的 KV Cache 生命周期管理是最难复现的技术。当 partial prefill 提交后，tool 可能执行数百毫秒甚至数秒。在此期间，engine 必须：

Pin partial prefill 产生的 KV blocks 防止被驱逐
在 extend 到达时正确 splice tool output 到已缓存的上下文中
处理 tool 执行失败时的资源释放

这需要 engine scheduler 深度修改以支持 "半完成" 状态的请求，且必须在 continuous batching 框架下正确管理 GPU 内存。

质疑假设 #

Tool-independent prompt 比例假设：论文声称 50-80% 的 prompt 是 tool-independent，但这基于特定 orchestrator 的 prompt template 设计。不同 agentic 框架的 prompt 组织方式可能有很大差异；
Tool 输出插入位置假设：假设 tool 输出总是在 prompt 的固定位置插入。如果 orchestrator 根据 tool 结果动态重组 prompt 结构（如改变 system prompt），则 partial prefill 的 KV cache 可能完全无用；
Proportional tool latency scaling：用 LLM-to-tool 时间比例来模拟 tool 延迟，假设 tool 延迟与 LLM 延迟成比例——但实际 tool 延迟取决于外部服务状态，与 LLM 计算无关。

设计绑定批判 #

强制绑定 vLLM 架构：5 个新 API 深度嵌入 vLLM v1 scheduler，虽说"可移植到 TensorRT、DeepSpeed"，但实际需要对目标 engine 的调度器做大量改动
强制绑定 JSON 格式 tool call：streaming dispatch 依赖 tool call 是结构化 JSON，如果 LLM 使用自然语言或其他格式输出 tool 调用，则无法工作
强制绑定 prompt template：partial prefill 需要 orchestrator 精确知道 prompt 的 split point，与 prompt template 紧密耦合

拆解：从输入到输出 #


[User Request] → Orchestrator
    → Iteration 1: 
        → 构建完整 prompt (system + user query)
        → submit to engine → Prefill P1 → Decode D1 (生成 tool calls JSON)
        → register_streaming_callback: 流式 JSON parser
            → 第一个 tool call JSON object 闭合 → 立即分发 Tool T1_1
            → 第二个 tool call JSON object 闭合 → 立即分发 Tool T1_2
            (与 decode 重叠)
    → Iteration 2:
        → Orchestrator 识别 split point
        → submit_partial_prefill(tool-independent prefix P2a) 
            (与 T1_1, T1_2 执行并行)
        → Tools 完成 → extend_prefill(tool-dependent suffix P2b)
        → Decode D2 → 如果是 final iteration → 输出给用户
        → 如果还有 tool calls → 继续迭代
[Final Response] ← User

实践上下文 #

本文直接面向大规模 LLM agentic 应用的生产部署，如 Microsoft 的企业 AI 助手（M365 Copilot 类产品），workload 包含 document retrieval、summarization、web search 等 tool。Sutradhara 解决的是用户感知延迟（FTR）问题，在企业用户对响应速度敏感的场景中有直接价值。

生态影响追踪 #

对 vLLM 的影响：基于 vLLM v0.11.0 实现，如果被 upstream 采纳，将为 vLLM 增加 agentic workload 原生支持能力
对 agentic 框架的影响：LangChain、AutoGen 等框架可以通过实现 co-design API 来获得延迟优化，但需要暴露 prompt structure 信息
对 KV cache 研究的影响：语义标签驱逐策略（semantic tagging + priority eviction）为 workload-aware cache management 开辟新方向
潜在限制：co-design 方案增加了 orchestrator-engine 的耦合度，可能与 disaggregated serving（P-D 分离）趋势产生张力

2c. 关键图表分析 #

Figure 1: Sutradhara 整体效果预览 #

展示内容：Sutradhara 通过系统性地解锁 intra-request 并行性来降低 FTR 和 e2e 延迟。展示了 (a) 并行执行原理图 (b) 延迟增益 (c) FTR breakdown。

重要性：这是论文的"灵魂图"，一图展示了核心思想——将 agentic 请求中原本串行的 prefill/decode/tool 执行三阶段重叠起来，在两个随机请求上实现 18-35% 的 FTR 降低。

Figure 4: Tool 调用执行动态 #

展示内容：(a) Tool 执行时间占 FTR 延迟比例的 CDF——中位 27%，P90 68%，P99 83%。(b) 7 种 tool 的归一化延迟分布，变异系数超过 100%。

重要性：这是论文最核心的实证发现，直接挑战了"tool call 是轻量 I/O"的传统认知，为 orchestrator-engine co-design 提供了动机。

Figure 5: Prompt 中 tool-independent 内容的比例 #

展示内容：跨迭代的 prompt 中 tool-independent vs tool-dependent 内容的比例分析。50-80% 的 iteration $i+1$ prompt 在 iteration $i$ decode 完成时就已可用。

重要性：直接证明了 prompt splitting 的可行性——大部分 prefill 计算可以与 tool 执行并行。

Figure 6: KV Cache Thrashing 示意 #

展示内容：三个并发 agentic 请求 $R_1, R_2, R_3$ 在 LRU 驱逐策略下的级联驱逐过程。$R_2$ 的第二次迭代导致 $R_1$ 被驱逐，$R_1$ 的第二次迭代又导致 $R_3$ 被驱逐，形成恶性循环。

重要性：直观展示了 workload-agnostic LRU 在 agentic workload 下的根本缺陷。

Figure 7: Sutradhara 并行执行设计 #

展示内容：(a) Baseline 串行执行 (b) Prompt splitting 实现 prefill-tool overlap (c) Streaming tool dispatch 实现 decode-tool overlap。三步递进展示完整优化方案。

重要性：论文的核心设计图，展示了三种优化如何逐步叠加消除串行瓶颈。

Table 1: Co-design API #

API Call	Purpose	Enables Optimization
`submit_partial_prefill()`	提交 tool-independent prompt 片段	并行执行：engine 在 tool 执行期间开始 prefill
`extend_prefill()`	追加 tool 输出到已 pin 的 partial prefill 上下文	并行执行：tool 结果到达后无需重新计算前缀
`register_streaming_callback()`	逐 token 接收 partial decode 输出	Streaming dispatch：orchestrator 在 decode 进行时就解析并分发 tool
`tag_kv_blocks()`	给 cached KV blocks 打语义标签	Cache 管理：启用 workload-aware 驱逐策略
`set_reuse_priority()`	设置 KV block 优先级用于 pinning	Cache 管理：防止即将被复用的上下文被驱逐

关键要点：5 个 API 构成了 orchestrator-engine 之间的"薄接口层"，最小化侵入性的同时实现三大优化。

Table 2: Ablation 结果 #

Technique	FTR (s)	E2E (s)	FTR %	E2E %
KV (baseline)	51.5	84.2	-	-
KV + PS	47.6	80.38	7.57%	4.54%
KV + PS + DS	45.44	77.99	11.77%	7.37%

关键要点：Prompt Splitting 是主要贡献者（7.57% FTR），Streaming Dispatch 额外贡献 4.2%。E2E 改进小于 FTR（final iteration 的 decode 无法被加速）。

2d. 技术细节补充与一句话总结 #

技术细节补充 #

Workload-Aware 驱逐优先级链：

$$\text{RESPONSE} \longrightarrow \text{TOOL\_OUTPUT} \longrightarrow \text{USER\_QUERY} \longrightarrow \text{SYSTEM\_PROMPT} \longrightarrow \text{PARTIAL\_PREFILL}$$

（从先驱逐到后驱逐）

Trace 特征：中位 agentic 请求有 2 次 LLM 迭代（1 intermediate + 1 final），尾部最高 7 次；每次迭代中位 2 个 tool call，最高 20 个；中位 prompt 长度 ~20K tokens。

Intermediate vs Final iteration 特征差异：intermediate iteration 的 decode token 数是 final 的 1/5，因此 intermediate iteration 是 prefill-bound，final iteration 是 decode-bound。

实现细节：基于 vLLM v0.11.0 的 v1 scheduler，使用 asyncio 事件驱动 orchestrator，PD colocation + chunk size 256。3500 行 Python 代码。

一句话总结 #

Sutradhara 通过打破 orchestrator-engine 的黑箱隔离，在 agentic 推理中实现 prompt 分裂并行、streaming tool 分发和语义 KV cache 管理三大优化，将 FTR 延迟降低 15%。

2e. 结构化提取 #

Core Contribution: Sutradhara 提出 orchestrator-engine co-design 架构，通过 5 个 thin API 实现 prompt splitting（prefill-tool overlap）、streaming tool dispatch（decode-tool overlap）和 workload-aware KV cache management，在不修改模型架构的前提下将 agentic 推理的 FTR 延迟降低 15%。

Summary: Agentic LLM 应用通过迭代式 tool 调用完成复杂任务，但现有推理系统将 orchestrator 和 LLM engine 视为解耦的黑箱，导致三大性能瓶颈：tool 执行占据 30-80% FTR 延迟、串行编排浪费可利用的并行性、以及 LRU KV cache 驱逐在多请求并发时引发级联 thrashing。

Sutradhara 提出协同设计方案，通过 5 个新 API（submit_partial_prefill, extend_prefill, register_streaming_callback, tag_kv_blocks, set_reuse_priority）使 orchestrator 向 engine 传递语义信息。三大优化包括：(1) 将 prompt 分为 tool-independent 和 tool-dependent 两部分实现 prefill-tool 并行；(2) 通过流式 JSON parser 在 decode 过程中增量分发 tool 调用；(3) 基于语义标签的优先级驱逐策略 + 请求到达时间优先调度。

基于 vLLM v0.11.0 实现（3500 行代码），在 A100-80GB 上使用 Qwen3-14B 和 Gemma-12B 评估，tool-heavy 和 iteration-heavy 两种 trace 下一致性地降低 FTR（10-15%）和 e2e 延迟（6-10%），且不损失吞吐量。

Key Findings:

Tool 执行占 FTR 延迟的 30-80%（尾部），变异系数超过 100%，使基于预测的优化方案不可行
50-80% 的下一轮 prompt 不依赖 tool 输出，为 prefill-tool overlap 提供了天然的并行化机会
LRU KV cache 驱逐在 agentic 并发场景下导致级联 thrashing，语义优先级驱逐可有效缓解
Prompt Splitting 贡献 7.57% FTR 改进，Streaming Dispatch 额外贡献 4.2%
Co-design 方案仅需 3500 行代码改动，不修改模型架构或推理 kernel

Limitations:

仅在合成 trace（非真实生产 trace）上评估，虽声称与生产 workload 特征一致但无法直接验证
评估规模有限：单 A100 GPU，60 请求子集，仅 2 个模型（14B 和 12B 级别）
Tool 延迟通过 proportional scaling 模拟，非真实 tool 执行
Prompt splitting 效果取决于 prompt template 设计，不同 orchestrator 框架可能有不同的 tool-independent 比例
未评估 disaggregated PD 架构下的适用性
10-15% 的改进幅度在高 QPS 下会缩小（被 engine 排队时间主导）

Phase 3: 分类 #

Primary Category: framework

Secondary Tags: agent, kv-cache, scheduling, serving, latency-optimization

Infrastructure Impact:

Category	Impact
algorithm	N/A — 不涉及算法层面创新
kernel	无需自定义 kernel；所有优化在 scheduler 和 orchestrator 层面
llm	模型无关设计，适用于任何 tool-calling LLM（已验证 Qwen3-14B、Gemma-12B）
agent	高影响 — 直接优化 agentic workload 的 FTR 延迟，为 LangChain/AutoGen 等框架提供 co-design 接口范式
cluster	单 GPU 评估，未涉及分布式场景；co-design API 概念可扩展到多节点
hardware	仅在 A100 上评估，设计不绑定特定硬件

Phase 5: Deep Read — Framework 深度分析 #

1. System Scope #

Primary goal: Serving — 优化 agentic LLM 推理的用户感知延迟（FTR）
Scale: 单节点单 GPU（A100-80GB）
Online/Offline: Online — 延迟敏感型
Target workload: Tool-based agentic LLM inference（multi-iteration, multi-tool-call）

2. Architecture & Data Flow #

2a. End-to-End Data Flow #


[User Request] → [Orchestrator: Prompt Construction] → [Engine: Prefill] → [Engine: Decode]
                    ↓ prompt tokens (20K median)         ↓ KV cache           ↓ tool call JSON
                    ↓ CPU                                ↓ GPU HBM            ↓ GPU → CPU
                    ↓ ~0ms                               ↓ ~variable          ↓ ~variable

→ [Orchestrator: Streaming JSON Parse] → [Tool Execution Layer: API calls]
   ↓ partial JSON objects                  ↓ external I/O
   ↓ CPU                                  ↓ network/CPU
   ↓ per-token callback                   ↓ ms to seconds (high variance)

→ [Orchestrator: Partial Prefill Submission] → [Engine: Extend Prefill] → [Engine: Decode]
   ↓ tool-independent prompt slice            ↓ KV cache extension        ↓ final response / next tool calls
   ↓ CPU                                     ↓ GPU HBM                   ↓ GPU → CPU → User

Stage	Input → Output	Location	Latency	Data format & size
Prompt Construction	user query + history → token IDs	CPU	~0ms	List[int], ~20K tokens median
Prefill (partial)	tool-independent tokens → KV cache	GPU HBM	variable	[layers, heads, seq, dim]
Decode	KV cache → tool call JSON tokens	GPU HBM	variable, ~5x fewer tokens for intermediate	JSON string
Tool Execution	tool call spec → tool result	External API/CPU	ms-seconds, CV > 100%	string/structured data
Extend Prefill	tool output tokens → KV cache extension	GPU HBM	variable	appended KV blocks
Final Decode	KV cache → response tokens	GPU HBM	variable, ~5x more tokens	text stream

2b. Data Movement Hotspots #

KV Cache in HBM: 每次 iteration 的 ~20K token prompt 产生大量 KV cache；多个并发 agentic 请求的 KV cache 竞争 HBM 容量，是 thrashing 的根源。频率：每次 LLM 调用，阻塞式。
Orchestrator ↔ Engine 通信: token-level streaming callback 需要 CPU-GPU 间的频繁小数据传输。频率：每个 decode token，可与计算重叠。
Tool Network I/O: 外部 API 调用的网络延迟是不可压缩的瓶颈，变异系数 > 100%。频率：每次 tool 调用。

3. Design Space & Constraint Analysis #

3a. Alternative Approaches #

替代方案	可行性	原因
静态 DAG 优化 (Parrot/Murakkab)	❌ 不可行	Tool-based agent 的执行图是动态的，取决于 LLM 实时推理
Tool 延迟预测 + 调度 (Continuum)	❌ 不实用	Tool 延迟 CV > 100%，无法可靠预测
Tool partial execution (Conveyor)	❌ 受限	大多数生产 tool 需要完整参数才能执行
纯 orchestrator 优化（不修改 engine）	⚠️ 部分可行	可实现 streaming dispatch，但无法实现 partial prefill 和 cache 管理
纯 engine 优化（不修改 orchestrator）	⚠️ 部分可行	可改进 cache 策略，但缺乏 prompt structure 信息
Orchestrator-Engine Co-design	✅ 可行	最小化接口暴露同时实现三大优化

3b. Constraint Derivation #

静态 DAG 不可行证明：iteration $i$ 的 decode 输出决定 iteration $i+1$ 的 tool 调用和 prompt 结构。即 $\text{DAG}_{i+1} = f(\text{decode}_i)$，不可预知。
Tool 延迟预测不可行证明：Figure 4(b) 显示 top 7 tools 的延迟 CV > 100%，意味着标准差大于均值。即使使用历史分布预测，置信区间宽到无实用价值。
Partial execution 不可行证明：如 web search tool，参数 {"query": "..."} 中 query 必须完整才能执行。无法用半个 query 开始搜索。

3c. Assumption Audit #

假设	成立条件	可能失效场景
50-80% prompt 是 tool-independent	Orchestrator 使用固定 template（system prompt + user query + tool output 拼接）	如果 orchestrator 根据 tool 结果动态重写 system prompt
Tool call 输出为结构化 JSON	LLM 按要求格式输出	LLM hallucinate 非 JSON 输出、或使用 function calling 以外的格式
Tool 延迟与 LLM 延迟比例稳定	模拟环境	真实生产环境中 tool 延迟受外部因素影响，与 LLM 无关
单 GPU 足以处理 workload	模型 ≤14B 参数	更大模型需要多 GPU TP/PP，co-design API 需扩展

3d. Core Technical Barrier #

Partial prefill 的状态管理是核心技术壁垒。当 submit_partial_prefill() 提交后，engine 必须：

在 continuous batching 循环中维护一个"半完成"请求状态（既不是 running 也不是 waiting）
Pin 对应的 KV blocks 防止在 memory pressure 下被驱逐
处理 extend 请求到达时的上下文拼接——需要精确对齐 token 位置
超时/失败时的 graceful cleanup

这不是一个简单的 API 封装，而是对 vLLM v1 scheduler state machine 的深度修改。

3e. Design Binding Critique #

绑定 prompt template 结构：orchestrator 必须精确知道 split point，与 prompt engineering 紧密耦合。如果 prompt format 变化，split logic 需要同步更新。
绑定 JSON tool call format：streaming dispatch 的 JSON parser 假设 tool calls 是标准 JSON array of objects。如果模型使用 XML、YAML 或自然语言格式，需要重写 parser。
绑定 PD colocation：evaluation 使用 PD colocation（prefill 和 decode 在同一 GPU）。在 disaggregated P-D serving（如 DistServe/Splitwise）架构下，partial prefill 的 KV cache 需要跨 GPU 传输，延迟特征完全不同。

4. Key Innovations #

Innovation	Mechanism	Benefit	Cost/Tradeoff
Prompt Splitting	将 prompt 分为 tool-independent/dependent 两部分，提前 prefill 前者	7.57% FTR 改进	需要 orchestrator 暴露 prompt structure，增加耦合
Streaming Tool Dispatch	Token-level callback + streaming JSON parser，decode 过程中增量分发 tool	4.2% 额外 FTR 改进	Per-token callback 开销；JSON parser 需维护
Semantic KV Tagging	5 种语义标签 + 优先级驱逐	消除级联 thrashing	标签需要 orchestrator 提供，增加 API 复杂度
Request-Aware Scheduling	按 agentic 请求到达时间排优先级	减少 in-flight 请求的等待时间	可能增加新请求的排队延迟
5-API Co-design Interface	Thin API layer between orchestrator and engine	最小化侵入性的跨层优化	增加 orchestrator-engine 耦合

5. Scheduling & Resource Management #

Batch formation: Continuous batching (inherited from vLLM), chunked prefill with chunk size 256
Memory management: PagedAttention (inherited from vLLM) + semantic priority eviction
GPU utilization: Partial prefill 利用 tool 等待期间的 GPU idle time
Multi-tenancy: 通过 agentic request ID 区分不同请求，但无 SLO 隔离
Priority scheduling: 按 agentic 请求到达时间排序，earlier = higher priority

6. Target Scenarios #

Scenario	Workload Pattern	SLO/Goal	Why existing systems fail
Enterprise AI Assistant (M365 Copilot)	Multi-tool, 2-7 iterations, 20K token context	FTR < 数秒	Sequential orchestration + KV thrashing
Tool-heavy workload	High tool fanout (median 2, max 20) per iteration	Min FTR	Tool latency dominates, no overlap
Iteration-heavy workload	Deep iteration chains (7+), lower fanout	Min e2e	Sequential pipeline bottleneck

Primary bottleneck: Scheduling-bound (sequential orchestration + KV thrashing) > Memory-bound (KV cache pressure) > Compute-bound (prefill compute)

7. Performance Evaluation #

7a. Metrics #

Metric	Definition	Unit	Direction
FTR	从用户请求到 final response 第一个 token 的时间	seconds	Lower
E2E	从用户请求到完整 response 生成的时间	seconds	Lower
Median/P99 FTR	FTR 的分位数	seconds	Lower

7b. Before-After Comparison #

Optimization	Metric	Baseline	After	Improvement	Conditions
Full Sutradhara	Median FTR	51.5s	~43.3s	15.83%	Qwen3-14B, A100-80G, tool-heavy trace
Full Sutradhara	P99 FTR	-	-	12.3%	Same
Full Sutradhara	Median E2E	84.2s	~73.8s	~10%	Same
KV + PS	Median FTR	51.5s	47.6s	7.57%	Same
KV + PS + DS	Median FTR	51.5s	45.44s	11.77%	Same
Gemma-12B	Median FTR	-	-	10.74%	Tool-heavy trace
Gemma-12B	Median E2E	-	-	6.39%	Tool-heavy trace
Iteration-heavy	Tail FTR	-	-	4%	Qwen3-14B
Iteration-heavy	E2E	-	-	8%	Qwen3-14B

7c. Bottleneck Shift Analysis #


Before: scheduling-bound (sequential orchestration, tool wait blocking next prefill)
→ After PS: still partially scheduling-bound (decode-tool still sequential) 
→ After PS+DS: memory-bound (KV cache pressure becomes more visible)
→ After PS+DS+KV: engine capacity-bound (at high QPS, queueing dominates)

残留瓶颈：高 QPS 下所有系统都被 engine 排队时间主导，co-design 优化的边际效益递减。

7d. Baselines & Fairness #

Baselines: (1) Standard vLLM (FCFS scheduling, LRU eviction) (2) vLLM + request-aware scheduling
Fairness: 公平——相同硬件（A100-80GB）、相同模型（Qwen3-14B/Gemma-12B）、相同 trace
Workload: 从 6000 请求的合成 trace 中抽取 60 请求，Poisson 到达
Scale limitation: 仅单 GPU，60 请求——统计显著性有限
Baseline 可能赢的场景: 高 QPS 时所有系统趋同（被排队时间主导）

8. API & Usability #

API compatibility: Custom 5-API extension on vLLM; 不兼容 OpenAI API（需要 orchestrator 显式调用 co-design API）
Model support: 任何 vLLM 支持的模型
Deployment: 需要 co-design orchestrator + 修改版 vLLM
Configuration complexity: 中等——需要配置 prompt split point、KV tag policy、scheduling priority

9. Infrastructure Impact #

Layer	Impact
Algorithm	不直接影响算法，但 prompt splitting 概念可扩展到 speculative decoding 场景
Kernel	不需要自定义 kernel，所有优化在 Python scheduler 层
LLM	模型无关，但 tool calling 格式（JSON）需要模型支持
Agent	核心影响层：为 agentic framework 提供 co-design 接口范式
Ops	提供 semantic metadata tagging，有潜力扩展为 observability/monitoring 信号

10. Comparison Matrix #

Feature	Sutradhara	vLLM	SGLang	Autellix	Conveyor
Continuous batching	✅ (inherited)	✅	✅	✅	✅
PagedAttention	✅ (inherited)	✅	✅	✅	✅
Prefix caching	✅ (enhanced)	✅	✅	✅	✅
Agentic workload awareness	✅	❌	❌	partial	partial
Prefill-tool overlap	✅	❌	❌	❌	❌
Streaming tool dispatch	✅	❌	❌	❌	❌
Semantic KV eviction	✅	❌	❌	❌	❌
Orchestrator co-design	✅	❌	❌	❌	partial
Dynamic DAG support	✅	N/A	N/A	❌ (static DAG)	N/A
Multi-GPU	❌ (untested)	✅	✅	✅	❓

11. Adoption, Maturity & Ecosystem Influence #

Open source: 论文未提及代码开源计划
Production: 分析基于 Microsoft 内部生产平台的合成 workload
Adoption barrier: 需要同时修改 orchestrator 和 engine，不是 drop-in replacement
Downstream influence:
vLLM 社区可能会采纳 semantic KV tagging 的概念
Agentic framework（LangChain、AutoGen）可能会增加 engine hint API
Request-aware scheduling 已是相对成熟的概念，可能被更快采纳
Industry trend alignment: co-design 思想与近期 serving 系统"打破黑箱"的趋势一致（如 SGLang 的 RadixAttention 也是 engine 感知 prompt structure）