DistServe
PD 分离学术原型如何用 Goodput 指标驱动双 Placement 算法设计
核心要点：
- Goodput 指标：每张 GPU 在满足 SLO attainment 目标 （如 90%） 下可承载的最大请求速率
- 双 Placement 算法：High Node-Affinity （节点间带宽充足，实例独立摆放） / Low Node-Affinity （强制同节点 NVLink）
- 三层搜索流程：枚举合法并行 + 离散事件仿真 + 二分搜索请求速率
- KV 传输 Pull 语义 + Layer-wise：报告 KV 转移占总延迟 < 0.1% (OPT-175B)
- 关键数据：7.4× 请求量或 12.6× 紧 SLO，仿真器误差 < 2%, Placement 离线 < 1.3 分钟
DistServe 是首个明确以 PD 分离作为系统核心方向、把 Goodput 作为优化目标的学术原型，发表于 OSDI 2024[1]。Mooncake / SGLang / NVIDIA Dynamo 等后续生产系统的 PD 分离设计都在不同程度上回应或扩展 DistServe 的方案。本文聚焦 DistServe 系统本身。PD 分离的原理、SLO 拆分、KV 转移代价等通用部分在 9.2 Prefill/Decode 分离原理 已经覆盖。
论文元数据是什么
核心问题：DistServe 论文的作者、会议、年份、关键参数等元数据是什么？
| 项目 | 内容 |
|---|---|
| 论文 | DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving |
| 发表 | OSDI 2024[2]; arXiv 2401.09670 v3, June 2024[1] |
| 第一作者 | Yinmin Zhong （北京大学） |
| 通讯 / 资深作者 | Xin Jin （北京大学），Hao Zhang (UC San Diego) |
| 其他合作机构 | StepFun (Yibo Zhu) |
| 第一份 arXiv | 2024-01-18 |
@tbl-distserve-meta 论文元数据
作者团队来自 PKU 系统组 （Xin Jin 实验室） 与 UCSD （Hao Zhang, Vicuna / Chatbot Arena / Vidur 等工作的同一团队），是 LLM 推理系统方向最活跃的两个学术节点之一。
为什么需要 PD 分离
核心问题：colocated 部署的三类干扰具体是什么？
DistServe 的出发点是观察到 colocated 部署下 prefill 与 decode 互相干扰，并把两者的资源分配 / 并行策略强行绑定 ("couple the resource allocation and parallelism plans for both phases")。具体表现：
- Prefill 阻塞 decode：一次长 prompt 的 prefill 耗时数百 ms，所有在 decode 的请求被推迟，P99 TPOT 抖动
- Decode 打断 prefill：decode step 插队进 batch, prefill 的大矩阵乘被打断，TTFT 抬升
- 并行策略只能折中：prefill 喜欢 TP 较大、batch 较小；decode 喜欢 batch 较大；统一并行配置对两者都不是最优
这部分的通用原理在 9.2 Prefill/Decode 分离原理 已经展开。DistServe 的独特贡献是把"消除 prefill-decode interference"工程化为一个可搜索的部署配置问题，而非仅停留在性能分析。
Goodput 怎么定义
核心问题：为什么用 Goodput 取代 throughput / latency？它怎么把两个维度合并？
定义 （原文）：
"the maximum request rate that can be served adhering to the SLO attainment goal (say, 90%) for each GPU provisioned"
其要点：
| 属性 | 说明 |
|---|---|
| 单位 | requests per second per GPU |
| SLO 约束 | TTFT 与 TPOT 两条 SLO 同时满足 |
| Attainment 目标 | 通常 P90 （90% 请求满足），也可调成 P99 |
| 与 throughput 的差异 | throughput 不约束尾延迟，可能 ≥ goodput 但实际服务质量不达标 |
@tbl-distserve-goodput Goodput 指标的四条属性
Goodput 的工程意义：把"用了多少 GPU"与"多严的 SLO"两个维度合并成一个可比较的标量，便于在大量候选并行 / 放置配置之间排序。
Placement 算法怎么搜
核心问题：给定集群 （节点数 / 每节点 GPU / 节点间带宽），怎么决定 prefill / decode 实例并行配置和放置位置？两类算法分别什么场景？
DistServe 按集群的节点间带宽分为两类，分别给出 Algorithm 1 与 Algorithm 2。
共同的搜索骨架
两个算法共享一个三层搜索流程：
- 枚举合法并行配置：在 GPU 显存约束 $G_{\text{size}} / (\text{inter\_op} \times \text{intra\_op}) < C$ 下枚举所有 TP × PP 组合 （inter_op 是 PP, intra_op 是 TP）
- 离散事件仿真：对每个候选配置用 Simulator 估算 SLO attainment （实测误差 < 2%，原文 Table 2）
- 二分搜索请求速率：在 attainment ≥ 目标 （如 90%） 下找最大可服务速率，即 goodput
Algorithm 1: High Node-Affinity （节点间带宽充足）
适用场景：节点间带宽接近节点内 （如 IB 800 Gbps + NVLink），KV cache 跨节点传输的延迟与跨 GPU 没有显著差别。
策略：
- prefill 与 decode 实例可跨节点摆放
- prefill 与 decode 独立做并行配置搜索 （互不约束）
- 找到各自的最优配置后按流量需求"复制"该配置形成实例池
复杂度：$O(N \cdot M^2)$ （此处 N/M 仅指单实例规模 — N = 每实例节点数、M = 每节点 GPU 数，非整集群规模）。
Algorithm 2: Low Node-Affinity （节点间带宽受限）
适用场景：节点间带宽显著低于节点内 （论文实测设置：节点间 25 Gbps Ethernet vs 节点内 NVLink 600 GB/s on A100）。
策略：
- 强约束：同一 pipeline stage 的 prefill 与 decode segment 必须落在同一节点内
- 该约束保证 KV cache 走节点内 NVLink，不经过低速节点间链路
- 在该约束下联合搜索两侧并行配置 （TP 与 PP 共享 stage 划分）
代价是搜索空间被剪枝、可能拿不到 Algorithm 1 的全局最优；收益是 KV 转移延迟控制在 NVLink 量级。
两算法的对比
| 维度 | Algorithm 1 (High) | Algorithm 2 (Low) |
|---|---|---|
| 节点间带宽假设 | 充足 （如 IB 800 Gbps） | 受限 （如 25 Gbps Ethernet） |
| Prefill / Decode 摆放 | 独立、可跨节点 | 同 stage 同节点 |
| 并行配置搜索 | 独立 | 联合 （共享 stage 划分） |
| KV 转移路径 | 任意 RDMA / NVLink | 强制走节点内 NVLink |
| 复杂度 | $O(N \cdot M^2)$ | 受约束剪枝后更小 |
@tbl-distserve-place-compare Placement 算法对比
实测中两个算法的离线运行时间均 < 1.3 分钟 （OPT-175B 上最大配置，原文 Figure 12），可作为部署前一次性优化或周期性重规划使用。
并行配置搜索的细节是什么
核心问题：Intra-op / Inter-op 怎么映射？Simulator 用什么数据驱动？
DistServe 的搜索器枚举两类并行：
- Intra-op parallelism （论文名词） = Tensor Parallelism (TP)
- Inter-op parallelism （论文名词） = Pipeline Parallelism (PP)
显存约束已在共同的搜索骨架 Step 1 给出。
Simulator 使用历史 trace （如 ShareGPT） 拟合 prompt 长度与输出长度的联合分布，重采样生成请求流，按 Poisson 到达模拟队列、batch 形成、KV 转移与生成步耗时，输出每个请求的 TTFT 与 TPOT。
仿真精度 （原文 Table 2）：相对实测的 P90 attainment 误差 < 2%，是离线选址可用的关键前提。
KV 传输方案是什么
核心问题：Pull 语义 + Layer-wise pipelined 在 DistServe 里怎么实现？转移占总延迟多少？
DistServe 的 KV 传输设计有两个核心特征：
| 特征 | 说明 |
|---|---|
| Pull 语义 | decoding 实例在需要时主动从 prefill 实例拉 KV, prefill 实例的显存充当 "queuing buffer", prefill 计算完不阻塞等待 |
| Layer-wise pipelined | prefill 算完第 $i$ 层立刻 ready 第 $i$ 层 KV, decode 可在后续层尚未算完时就开始拉早层 KV，与 prefill 计算 overlap |
@tbl-distserve-kv-feature KV 传输特征
物理路径按 Placement 算法选择：
- Algorithm 1 集群：跨节点 RDMA （IB 800 Gbps 量级）
- Algorithm 2 集群：节点内 NVLink (A100 600 GB/s)
原文报告 KV 转移耗时占总延迟 < 0.1% (OPT-175B, Figure 10)，意味着只要 Placement 正确选择带宽足够的路径，KV 转移本身不构成 TTFT 瓶颈。
KV 转移的通用代价模型、压缩与隐藏技术见 9.2 Prefill/Decode 分离原理; FlowKV 等专门优化见 9.7 KV cache 跨节点传输瓶颈。
实验配置和关键数据
核心问题：测试环境 / workload / 关键结果是什么？
测试环境
| 项目 | 配置 |
|---|---|
| GPU | NVIDIA A100-80GB, 4 节点 × 8 卡 = 32 卡总计 |
| 节点内互联 | NVLink （A100, 600 GB/s 量级） |
| 节点间互联 | 25 Gbps Ethernet （默认实测设置，对应 Algorithm 2） |
| 模型 | OPT-13B (26 GB), OPT-66B (132 GB), OPT-175B (350 GB), FP16 |
@tbl-distserve-hw 测试硬件配置
工作负载
三类业务对应三套 SLO:
| Workload | 数据集 | TTFT SLO | TPOT SLO | 业务特征 |
|---|---|---|---|---|
| Chatbot | ShareGPT | 0.25–4.0 s | 0.1–0.2 s | 中等 prompt + 中等输出 |
| Code completion | HumanEval | 0.125 s | 0.2 s | 短 prompt + 严苛 TTFT |
| Summarization | LongBench | 15 s | 0.15 s | 长 prompt + 严苛 TPOT |
@tbl-distserve-workload 三类工作负载与 SLO
请求到达按 Poisson 分布，多速率扫描。
关键结果
对比 baseline 为 vLLM (colocated) 与 DeepSpeed-MII （colocated + 优化 kernel）。在 P90 SLO attainment 约束下：
| 对比 | Workload | 提升 |
|---|---|---|
| vs vLLM | Chatbot (OPT-13B~175B) | 2.0–4.6× higher request rate |
| vs vLLM | Code completion (OPT-66B) | 5.7× higher rate, 1.4× tighter SLO |
| vs vLLM | Summarization (OPT-66B) | 4.3× higher rate, 12.6× tighter SLO |
| vs DeepSpeed-MII | Chatbot | 1.6–7.4× higher rate |
| vs DeepSpeed-MII | Code completion | 1.6× higher rate |
| vs DeepSpeed-MII | Summarization | 1.8× higher rate |
@tbl-distserve-results 与 baseline 的对比 （原文 §6）
论文 abstract 概括为："serve 7.4× more requests or 12.6× tighter SLO" while maintaining > 90% SLO attainment[1]。注意 7.4× 与 12.6× 不是同一个 workload 上同时取得的，是不同 baseline 与不同 workload 上的极值。
算法开销
Placement 算法离线运行时间 < 1.3 分钟 （OPT-175B 最大配置，原文 Figure 12），适合作为部署前一次性优化。Simulator 误差 < 2% (Table 2)。
DistServe 自身有什么局限 / 影响后续什么工作
核心问题：论文自陈的 4 类局限是什么？哪些后续系统继承了 DistServe 思路？
论文自身的局限
| 局限 | 说明 |
|---|---|
| 静态 Placement | Placement 是离线一次性搜索，不响应在线流量分布变化 （XpYd 比例不可动态调整） |
| 单实例模型 | 没有讨论多模型 / 多租户共享集群下的资源争用 |
| 短上下文为主 | 测试 prompt 长度未触达 128K+ 长上下文工况，长上下文下 KV 转移的相对开销会变化 |
| KV 复用未覆盖 | 没有 prefix cache / 多轮对话 KV 复用，每请求 prefill 重算 |
@tbl-distserve-limitations 论文自身局限
对后续系统的影响
DistServe 的工程影响在 2024–2025 年的生产系统里清晰可见：
| 后续系统 | 继承 DistServe 的部分 | 扩展 / 修正的部分 |
|---|---|---|
| Mooncake (Moonshot, FAST 2025) | PD 分离 + Goodput 思路 + layer-wise KV 传输 | KV-centric 架构 （独立 KV pool）、Conductor 全局调度、prefix cache 复用 |
| SGLang PD | 双池部署 + heterogeneous TP | 开源化、支持 Mooncake / NIXL 等多种 KV transport |
| NVIDIA Dynamo | PD 分离作为推荐部署模式 | KV router、与 NIXL 集成、生产级 SLO 监控 |
| Splitwise （ISCA 2024，同期工作） | PD 分离基本盘 | 异构 GPU 池 (prefill H100 + decode A100)，明确成本目标 |
@tbl-distserve-impact 对后续系统的影响
这些后续系统的展开见 9.4 Mooncake / 9.5 SGLang PD / 9.6 NVIDIA Dynamo。
Takeaway
| 知识点 | 核心结论 |
|---|---|
| Goodput | 单 GPU + SLO attainment 下的最大请求速率，合并 GPU 量 + SLO 紧度两维 |
| 双 Placement | High Node-Affinity （独立摆放） / Low Node-Affinity （强制同节点 NVLink） |
| 三层搜索流程 | 枚举并行配置 + 离散事件仿真 + 二分速率搜索 |
| KV 传输 | Pull 语义 + Layer-wise pipelined，占总延迟 < 0.1% (OPT-175B) |
| 仿真精度 | < 2%, Placement 离线 < 1.3 分钟 |
| 关键加速 | 7.4× 请求量 (Chatbot vs DeepSpeed-MII), 12.6× 紧 SLO (Summarization vs vLLM) |
| 4 类局限 | 静态 Placement / 单实例 / 短上下文 / 无 KV 复用 |
| 影响后续 | Mooncake / SGLang PD / NVIDIA Dynamo / Splitwise 全部继承 PD 分离思路 |
参考资料
- Zhong et al., DistServe, arXiv:2401.09670 v3. https://arxiv.org/abs/2401.09670
- DistServe USENIX OSDI 2024 page. https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin