DynaServe: Unified and Elastic Execution for Dynamic Disaggregated LLM Serving vs 8 peers in category framework
DynaServe 的核心问题域——PD 分离架构下如何同时实现低尾延迟和高吞吐——是 2025-2026 年 LLM serving 框架领域的焦点之一。以下 8 个相关 entity 从不同切面攻击同一大问题：
| Entity | 关系 | 共性 | 差异焦点 |
|---|---|---|---|
| PPD (2603.13358) | 最近的直接竞争者 | 同在 PD disaggregation 的 request routing 层优化；同基于 vLLM；同关注 SLO 达标率 | PPD 以 multi-turn append-prefill 为切入点，DynaServe 以 single-turn 任意分割为切入点 |
| MFS (2603.17456) | 网络层互补 | 同面向 disaggregated serving 的 SLO 优化；同提出新调度抽象 | MFS 在网络 flow 层做调度（DSCP 标记、switch 硬件队列），DynaServe 在 request 层做调度（二分搜索分割点） |
| PrfaaS (2604.15039) | 跨 DC 扩展 | 同面向 PD disaggregation 的吞吐优化；同用吞吐模型推导最优配置 | PrfaaS 将 PD 推到跨数据中心（依赖 hybrid attention 降 KV 吞吐），DynaServe 限于单集群 RDMA 域 |
| Entity | 关系 | 互补机制 |
|---|---|---|
| DualPath (2602.21548) | KV 加载路径优化 | DualPath 解决 agentic workload 下 prefill engine 的 storage I/O 瓶颈（聚合 DE SNIC 带宽）；DynaServe 解决 prefill/decode 的 compute 负载失衡。两者在不同瓶颈层面互补 |
| KVServe (kvserve) | KV 压缩 | KVServe 压缩 PD 间 KV 传输数据量（up to 10x），DynaServe 的 chunk-based KV transfer 优化传输 timing。压缩+分割可叠加使用 |
| TensorHub (2604.09107) | 权重传输 | TensorHub 的 Reference-Oriented Storage 解决 RL 训练中 trainer→rollout 权重传输，DynaServe 解决推理中 P→D 的 KV 传输。两者面向不同数据类型和场景，但 TensorHub 的 pipeline replication 思想与 DynaServe 的 chunk-based transfer 有设计呼应 |
| Entity | 关系 | 正交性 |
|---|---|---|
| ZeRO-Prefill (2605.02960) | MoE prefill 特化 | ZeRO-Prefill 反转 MoE 数据流（weight streaming 替代 activation routing），仅面向 prefill-only workload；DynaServe 面向完整 prefill+decode pipeline 的通用模型。ZeRO-Prefill 的 prefill tier 可以作为 DynaServe 的 prefill GPU 使用 |
| TileRT (tilert-speed-scaling-law) | 执行引擎 | TileRT 用 AOT 持续驻留 kernel 消除 BS≈1 decode 的 inter-kernel overhead；DynaServe 在 request scheduling 层优化。TileRT 的 decode 加速可以改变 DynaServe 本地调度器的 profile table，使更多 decode 能在 SLO 内混入 prefill |
DynaServe 的核心 delta 是 micro-request 抽象——在任意 token 边界（而非仅 prefill/decode 边界）分割请求。这将 colocation 和 disaggregation 统一为同一泛化空间的特例 [2504.09285]。
与 PPD 对比最能突显这一 delta。PPD 的洞察是 append-prefill 对 decode 干扰极低（2% vs 48% TPOT degradation）[2603.13358]，因此将 Turn 2+ 请求路由到 D 节点本地执行。但 PPD 的路由决策是 per-request binary（整个请求去 P 或留 D），而 DynaServe 的分割是 per-request continuous（在任意 token 位置切割）[2504.09285]。PPD 是 DynaServe micro-request 的特例之一（$s = P$ 时退化为 disaggregation，即 PPD 的 PD path）。
| 维度 | DynaServe delta | 评估 |
|---|---|---|
| 抽象层面 | Micro-request 统一 colocation/disaggregation → 连续分割空间 | 结构性创新：改变了问题的搜索空间定义，而非在现有空间内优化 |
| 调度算法 | 二分搜索 + profiling LRU cache（<20ms per request） | 增量改进：经典的 load-balancing 技术应用于新抽象 |
| 本地调度 | SLO-aware dynamic prefill budget（profile table 自校准） | 增量改进：比 vLLM 的 static chunk 更灵活，但思路类似 chunked prefill |
| KV 传输 | Chunk-based DMA push（94% non-overlapped reduction） | 增量改进：DualPath 的 layerwise streaming 更系统化 [2602.21548] |
| 维度 | DynaServe | PPD | MFS | PrfaaS | DualPath | ZeRO-Prefill |
|---|---|---|---|---|---|---|
| 分割粒度 | 任意 token | per-request binary | per-flow (网络层) | 按长度阈值 t | 不分割（双路径加载） | 不分割（weight streaming） |
| 优化目标 | Goodput under SLO | TTFT + TPOT balance | TTFT SLO attainment | 跨 DC 吞吐 | JCT (offline) / APS (online) | Prefill 吞吐 |
| SLO 类型 | P99 TBT < 100ms | TTFT + TPOT weights | TTFT deadline | 40 tok/s | TTFT ≤ 4s, TPOT ≤ 50ms | 无（吞吐导向） |
| 硬件 | A100 | H100 | 3090 (testbed) | H200 + H20 | Hopper | A100/H100/H200 |
| 模型 | Qwen-2.5 (dense) | Llama-3.1-8B (dense) | Mixtral-8x7B (MoE) | 1T hybrid (MoE) | DS 660B (MoE) | Qwen3-235B (MoE) |
| Workload | 单轮通用 | 多轮对话 | Agent + conversation | 长上下文 | Agentic RL | Prefill-only |
| 代码开源 | 未开源 | 未开源 | 未开源 | 未开源 | 未开源 | vLLM v0.11.0 |
DynaServe 发表于 2025-04，后续 8 个月的工作在以下维度超越了其设计假设：
Attack 1: Dense-only evaluation in a MoE-dominated world
DynaServe 仅在 Qwen-2.5 (dense) 上评估 [2504.09285]，而 2025-2026 年的开放权重主力模型（DeepSeek-V3/V4, Qwen3-MoE, Mixtral）几乎全部是 MoE。MoE 模型的 expert parallelism 引入额外的 AllToAll 通信——当 DynaServe 将请求分割到不同 GPU 时，EP 通信模式是否被打断？micro-request 的 $\alpha$ 和 $\beta$ 分段是否需要跨不同 EP group？这些关键问题未被讨论。
Attack 2: A100-only hardware in an H100/H200 era
DynaServe 在 A100 上评估 [2504.09285]。H100/H200 的 FP8 计算使 prefill 加速约 2x，可能改变 prefill/decode 的相对时间比。如果 prefill 变得很快，micro-request 分割的 $\alpha$ 段 overhead（调度 + KV transfer）可能超过其均衡收益。MFS 也存在类似问题但至少提供了仿真结果 [2603.17456]。
DynaServe 声称对输出长度预测误差鲁棒（$\sigma=100$ tokens 仅 2.9% goodput drop）[2504.09285]，但这是在可预测工作负载（BurstGPT, Azure Code）上的结果。Reasoning workloads（如 o1-style CoT）的输出长度变化可达 10x 甚至 100x（从几十 token 到数千 token），$\sigma=100$ 远不够覆盖。在极端预测失败下，全局调度器的二分搜索起点 $\phi=P/(P+D)$ 可能严重偏离实际最优——不仅 goodput 下降，还可能导致 KV transfer 浪费（已传 KV 对应的 decode 位置不对）。
Attack 3: Two-way split limitation
DynaServe 限于 $\alpha$/$\beta$ 两路分割 [2504.09285]。对于 8-GPU 集群，这意味着每个请求最多只能利用 2 个 GPU 的 compute 能力。在极度不平衡的负载下（如一个超长 prefill 请求），理想的分割可能是 3-way 或更多。论文未分析 multi-way 分割的 diminishing returns 或协调开销。
Attack 4: Chunk-based KV transfer vs DualPath's layerwise streaming
DynaServe 的 chunk-based KV transfer 声称 94% non-overlapped reduction，但 DualPath 的 layerwise streaming 实现了更精细的 per-layer pipelining [2602.21548]。更关键的是，DualPath 通过 CNIC-centric traffic isolation 解决了 KV transfer 与模型推理通信的优先级冲突 [2602.21548]——DynaServe 未考虑此问题。在大规模部署中，KV transfer 流量可能与 TP 通信争抢 NIC 带宽。
DynaServe 报告全局调度 overhead <20ms/request [2504.09285]，但这只是 CPU-side scheduling latency。未报告的隐性成本包括：(1) profile table 的 warm-up period 内性能退化；(2) KV transfer 建立 RDMA 连接的 setup overhead；(3) 在高 QPS 下 global scheduler 是否成为单点瓶颈（centralized design）。MFS 的 centralized coordinator 也存在类似疑虑 [2603.17456]。
DynaServe 的范式贡献在于 统一了 colocation/disaggregation 的二元对立为连续谱。在 2025-04 发表时，这是一个有价值的理论框架——它表明此前的工作只探索了分割空间的两个端点。
然而，后续工作的走向揭示了一个模式：实际系统不需要通用的连续分割，而是需要针对特定 workload 形态的特化方案：
这暗示 DynaServe 的通用连续分割可能 over-engineer 了实际需求——real-world workload 的特征足够鲜明，binary 或 threshold-based 路由已经足够。
DynaServe 截至 2026-05 未开源 [2504.09285]，也未被 vLLM/SGLang 主线吸收。相关的 related work 中，PPD 和 ZeRO-Prefill 分别在 vLLM 上实现了原型，KVServe 以 external connector 形式 zero-fork 接入 vLLM [kvserve]。DynaServe 的 3K 行 Python+C++ 实现尚无社区复现报告。
在 DynaServe 发表 8 个月后，DeepSeek 的 DualPath [2602.21548] 和 ByteDance 的 TensorHub [2604.09107] 代表了工业界对 PD 分离优化的实际选择——两者均已部署在千卡级生产集群中，而 DynaServe 停留在 research testbed（2 servers × 4 A100）。生产系统优先选择了面向特定瓶颈（storage I/O、weight transfer）的专用方案，而非通用的分割抽象。
尽管 DynaServe 在采纳维度落后，其 micro-request 抽象对 serving 系统的概念框架仍有持久价值：
DynaServe 的 chunk-based KV transfer 和 KVServe 的 service-aware compression 是天然可叠加的组合。当 micro-request 分割导致跨 GPU KV transfer 时，KVServe 的 analytical model 可以判断压缩是否有益（B < (1-1/cr)·S）[kvserve]，在低带宽场景下自动启用压缩。DynaServe 的 profile table 可以扩展为记录 (plen, ctx, dnum, transfer_bw, time) 五元组，将网络条件纳入本地调度决策。
DynaServe 的 micro-request 和 PPD 的 multi-turn routing 尚未融合。一个自然的方向是：Turn 1 使用 DynaServe 的 micro-request 做 compute 均衡分割，Turn 2+ 使用 PPD 的 append-prefill routing 在 D 节点本地执行 [2603.13358]。这需要扩展 DynaServe 的全局调度器使其感知 session 状态和 KV cache 位置——当前 DynaServe 是 per-request stateless 的 [2504.09285]。
MFS 揭示了 disaggregated serving 中三阶段通信的网络争用导致 TTFT 膨胀 ~50% [2603.17456]。DynaServe 的全局调度器当前仅基于 compute 负载做分割决策，不考虑网络状态。一个方向是将 MFS 的 MLU 指标（Minimal Link Utilization）集成到 DynaServe 的二分搜索目标中：不仅均衡 GPU 执行时间，还确保 KV transfer 不会触发网络争用。这在 MoE 模型的 EP 通信环境下尤为重要。
当 micro-request 与 ZeRO-Prefill 的 AsyncEP 结合时，一个有趣的可能性出现：DynaServe 将 prefill 分段的 $\alpha$ 微请求路由到使用 AsyncEP 的 GPU（利用 weight streaming 的高 MFU），$\beta$ 微请求路由到标准 decode GPU。这需要两层异构：GPU 角色异构（prefill/AsyncEP vs decode）+ 请求分割异构（$\alpha$ vs $\beta$）。ZeRO-Prefill 的饱和阈值 T [2605.02960] 可以为 DynaServe 的全局调度器提供每个 GPU 的 compute capacity 信号。
TileRT 的 persistent engine kernel 将整个 decode 生命周期压缩为单次 kernel launch [tilert-speed-scaling-law]。如果 DynaServe 的 $\beta$ 微请求在 TileRT 驱动的 GPU 上执行，decode 延迟可能大幅下降——这会改变 DynaServe 的 optimal split point $\phi$（更多 workload 可以留在 decode 侧，因为 decode 变快了）。但 TileRT 的 AOT 编译和静态 GPU 角色分配与 DynaServe 的动态 routing 存在根本张力：persistent kernel 难以在运行时改变 GPU 的角色（从 "decode worker" 变为 "hybrid $\alpha$ worker"）。