| Entity | 关联维度 | 关联强度 |
|---|---|---|
| DualPath (2602.21548) | 同为 agentic workload 优化；同在 PD 分离架构下解决 KV-cache 管理；DualPath 解决 storage 带宽，Sutradhara 解决 intra-request 延迟 | 强 |
| PPD (2603.13358) | 同为 multi-turn/iterative 请求优化；PPD 在 PD 分离中把 append-prefill 路由到 decode 节点，Sutradhara 在同节点内把 partial prefill 与 tool 执行重叠 | 强 |
| MFS (2603.17456) | 同为 disaggregated serving 中的调度优化；MFS 解决网络层流量争用，Sutradhara 解决 orchestrator-engine 层的串行瓶颈 | 中 |
| PrfaaS (2604.15039) | 同为 prefill 阶段优化；PrfaaS 把 prefill offload 到跨 DC 集群，Sutradhara 把 prefill 拆分实现 tool-overlap | 中 |
| KVServe (kvserve) | 互补关系：KVServe 压缩 PD 间 KV 传输体积，Sutradhara 通过语义标签优化 KV 驱逐策略 | 中 |
| ZeRO-Prefill (2605.02960) | 同为 framework co-design；ZeRO-Prefill 是 prefill-only MoE 的 frontend-backend co-design，Sutradhara 是 agentic 的 orchestrator-engine co-design | 中弱 |
| TensorHub (2604.09107) | 同为 framework 论文共享 RDMA/系统设计范式；TensorHub 解决 RL training 权重传输，serving 不直接相关 | 弱 |
| TileRT (tilert-speed-scaling-law) | 同为推理延迟优化；TileRT 解决 BS≈1 decode 的 inter-kernel idle，Sutradhara 解决 agentic 多轮的 inter-iteration idle | 弱 |
为什么选择这些 peers：Sutradhara 的核心贡献是 agentic 推理中 orchestrator-engine 的 co-design 接口。DualPath 和 PPD 是直接竞争者（同为 agentic/multi-turn serving 优化）；MFS、PrfaaS、KVServe 是互补系统（解决不同层面的瓶颈）；ZeRO-Prefill 和 TileRT 体现了 co-design 思想在不同 workload regime 的应用。
Intra-request parallelism via prompt splitting 是所有 peers 中独有的：将下一轮 prompt 分为 tool-independent（50-80%）和 tool-dependent 两部分，在 tool 执行期间提前 prefill [2601.12967]。其他系统要么优化 inter-request（DualPath 的调度）、要么优化 inter-turn routing（PPD 的路由决策），没有深入到 intra-iteration 的 prompt 结构。
Streaming tool dispatch via JSON parsing 也是独有的：利用 decode 输出的流式性质，在 JSON object 闭合时立即分发 tool 调用 [2601.12967]。PPD 和 DualPath 都在 LLM-engine-as-blackbox 的抽象层面工作，不涉及 decode output 的增量解析。
语义 KV 标签驱逐 将 KV block 按 prompt 结构打标签（SYSTEM/USER/TOOL_OUTPUT/RESPONSE/PARTIAL_PREFILL）[2601.12967]。DualPath 的 KV 管理基于 trie 结构的 prefix matching [2602.21548]；KVServe 通过压缩减小 KV 体积 [kvserve]——但两者都不利用 prompt 语义信息做驱逐决策。
| 维度 | Sutradhara | DualPath | PPD |
|---|---|---|---|
| 优化层 | Orchestrator↔Engine 接口 | Storage↔Engine I/O 路径 | Request routing |
| 目标指标 | FTR 延迟 (-15%) | 吞吐 (1.87×) / APS (1.96×) | Turn 2+ TTFT (-48~73%) |
| 评估规模 | 1 A100, 60 requests | 1152 GPU, 48K agents | 4 H100, 12 QPS |
| 代码开源 | 未开源 | 未开源 | 未开源 |
| 生产验证 | 合成 trace（声称与 M365 一致） | DeepSeek 生产 RL trace | 学术 workload |
| 核心壁垒 | Partial prefill 状态管理 | CNIC-centric data path | Offline scoring function |
PPD 的相对优势：PPD 在 Turn 2+ TTFT 上报告 48-73% 改善 [2603.13358]，远超 Sutradhara 的 15% FTR 改善 [2601.12967]。但两者的优化维度不同——PPD 消除了 KV re-transfer 的网络延迟，Sutradhara 消除了 tool-wait 的 GPU idle time。在 PD 分离架构下两者理论上可叠加。
DualPath 的相对优势：DualPath 在 1152 GPU 近线性扩展 [2602.21548]，而 Sutradhara 仅在单 GPU、60 请求规模验证 [2601.12967]。DualPath 直接解决 agentic workload 的 storage I/O 瓶颈（cache-compute ratio 22 GB/PFLOP），Sutradhara 解决的是 I/O 之上的编排串行化——在 DualPath 消除 I/O 瓶颈后，Sutradhara 的优化空间才完全展开。
Sutradhara 声称 tool 执行占 FTR 30-80% [2601.12967]，而 DualPath 的 DeepSeek 生产 trace 显示 agentic workload 的主瓶颈是 KV-cache 加载（TTFT 中 "Reading KV-Cache" 组件随负载膨胀）[2602.21548]。
矛盾根源：不同的部署尺度和 workload profile。Sutradhara 的 trace 来自 M365 企业级 agent（中位 2 次迭代、20K token context），tool 是外部 API 调用；DualPath 的 trace 来自 RL coding agent（157 轮、429 token/轮 append、98.7% cache 命中），tool 是快速代码执行。当 cache 命中率极高（>95%）时 prefill 退化为 I/O-bound（DualPath 场景）；当 cache 命中率一般且 tool 是网络 API 时 tool latency 主导（Sutradhara 场景）。两者在各自 workload regime 下都正确。
Sutradhara 在 1 GPU、60 请求 上评估 [2601.12967]——这是所有 peer 中最小的评估规模。DualPath 用 1152 GPU / 48K agents [2602.21548]，PPD 用 4 H100 / 12 QPS [2603.13358]，MFS 用 32 GPU testbed [2603.17456]。60 请求的子集在高方差 agentic workload 下统计功效极低——tool latency CV > 100% [2601.12967] 意味着 60 样本的置信区间可能覆盖零效应。
论文用 proportional scaling 模拟 tool 延迟（tool latency 与 LLM latency 成比例）[2601.12967]，但同时承认 tool 延迟取决于外部服务状态、与 LLM 计算无关。这个矛盾直接削弱了核心 claim：prompt splitting 的增益取决于 tool-independent prefill 时间与 tool 执行时间的比值——如果真实 tool 极快（如本地函数调用 <10ms），则 partial prefill 的 overhead（pin KV blocks + extend splice）可能反超收益。
在高 QPS 下，Sutradhara 自己承认优化的边际效益递减——被 engine 排队时间主导 [2601.12967]。15% 的中位改善在生产环境中可能进一步缩小。对比 PPD 的 48-73% TTFT 改善 [2603.13358] 和 DualPath 的 1.87× 吞吐提升 [2602.21548]，Sutradhara 的改善幅度在 peer 中处于低位。
5 个新 API 深度嵌入 vLLM v0.11.0 scheduler [2601.12967]。vLLM 迭代速度极快，KVServe 选择 external connector 正是为了避免 fork 维护成本 [kvserve]。Sutradhara 的 co-design 方案增加 orchestrator-engine 耦合——每次 vLLM 升级都可能 break prompt splitting 的状态机逻辑。PPD 也基于 vLLM disaggregated serving，但只需 scheduler-level patch（routing module）[2603.13358]，侵入性远低于 Sutradhara 的 5 API 修改。
Sutradhara 评估使用 PD colocation [2601.12967]。在 PD 分离架构下（DualPath、PrfaaS 的目标场景），partial prefill 的 KV cache 需要跨 GPU 传输到 decode engine，延迟特征完全不同。论文未评估此场景，但 PD 分离已是生产主流——Sutradhara 的适用范围可能被限制在 PD colocation 的小规模部署中。
Sutradhara 开辟了 orchestrator-engine co-design 这一新的优化维度，填补了 "单次 LLM 调用优化"（传统 serving 系统）和 "请求级调度优化"（Autellix、PPD）之间的空白。它是第一个系统性地分析 agentic 推理中 orchestrator 和 engine 之间信息不对称如何导致性能损失的工作 [2601.12967]。
请求级调度层: [PPD] [DualPath-scheduler] [MFS]
↑ 新维度
Orchestrator-Engine 接口层: [Sutradhara] ← 独占生态位
↓
Engine 内部优化层: [vLLM] [SGLang] [TileRT]
Sutradhara 的价值不在于绝对性能数字（15% FTR 改善相对温和），而在于它揭示了一个此前未被系统性利用的优化界面——prompt 结构信息从 orchestrator 流向 engine。这个 insight 对后续工作的影响可能大于 Sutradhara 本身的系统实现。
2026 年初，agentic LLM 从实验走向生产。Sutradhara 提出时（2026-01）比 DualPath（2026-02）和 PPD（2025-03/2026-05）更早系统性地分析 agentic serving 瓶颈。但其单 GPU 验证和合成 trace 评估使其更像"问题定义"工作而非"系统交付"工作——DualPath 的 1152 GPU 生产验证更具说服力。
Prompt splitting 在 PD 分离架构下尚未验证。如果 partial prefill 的 KV 可以通过 DualPath 的 layerwise streaming 传输到 decode engine、extend 操作在 decode 端执行，则两个系统可以叠加——DualPath 消除 I/O 瓶颈、Sutradhara 消除 tool-wait idle。核心挑战是 partial prefill 的 "半完成" 状态如何在 P-D 分离的两个 engine 间协调。
Sutradhara 的 5 种语义标签 [2601.12967] 可以指导 KVServe 的 compression profile 选择 [kvserve]。SYSTEM_PROMPT blocks 是高复用、高价值的——应保持高精度缓存；TOOL_OUTPUT blocks 是低复用、可丢弃的——可激进压缩或不缓存。这将 KVServe 的 service-aware controller 从 "bandwidth-driven" 扩展为 "semantic+bandwidth co-driven"。
PPD 在 Turn 2+ 时将 append-prefill 路由到 decode 节点 [2603.13358]。如果 append-prefill 是 tool-call iteration 的场景，可以进一步将 tool-independent 部分在 decode 节点本地执行 partial prefill（Sutradhara 思路），tool output 到达后 extend——完全消除 P→D 传输的 TTFT 贡献，且 decode 节点的干扰仅 2%（PPD 测量）。这是两篇论文优化维度的精确叠加。
在 disaggregated MoE serving 中，Sutradhara 的 partial prefill 会引入新的网络流——tool 执行期间发送 tool-independent KV。MFS 的 RMLQ 调度可以将 partial prefill 的 KV 传输标记为 implicit-deadline flow（RLI > 0，有 tool execution 作为 buffer），通过 defer 策略避免与 collective comm 争用 [2603.17456]。
当前 Sutradhara 的 split point 由 orchestrator 静态确定 [2601.12967]。借鉴 ZeRO-Prefill 的 saturation threshold T（物理量标定：T = t_EP × F_GPU × γ）[2605.02960]，可以设计自适应 split 策略：当 tool latency 预估 < partial prefill latency 时跳过 splitting（避免 overhead），当 tool latency > threshold 时启用。这将 prompt splitting 从"always-on"转化为"service-aware"，与 KVServe 的 analytical benefit condition 思路一致 [kvserve]。
TileRT 将整个 decode pass 合并为单个 persistent engine kernel [tilert-speed-scaling-law]。如果将 Sutradhara 的 streaming callback 机制嵌入 persistent kernel 的 tile pipeline 内部（decode 产生的 token 在 GPU-resident 的流式 JSON parser 中解析，tool call 闭合时通过 GPU-side signaling 触发 tool dispatch），则可以消除 decode→CPU→orchestrator→CPU→tool 的 round-trip，将 streaming dispatch 的粒度从 "per-token CPU callback" 压缩到 "per-tile GPU-resident signal"。