Zhongzhu's Blog

Keep

0%

DistServe：通过 Prefill/Decoding 解耦实现面向 Goodput 的大模型服务优化 — 深度技术评审

Posted on Edited on In ,

1. 这篇论文为什么值得认真读

先给一句结论：

DistServe 的价值在于：它把大模型服务里最痛的“延迟-成本矛盾”从调度层面硬扛，升级成“架构层面解耦”，然后再用算法做资源与并行策略的联合优化。

很多服务系统论文会给你“吞吐更高”的漂亮数字，但实际线上产品最在意的是：

  • 用户是否足够快看到首个 token（TTFT）？
  • 后续生成是否足够流畅（TPOT）？
  • 在满足服务质量（SLO）的前提下，每块 GPU 的产出值不值？

DistServe 不是只追求 token/s，而是明确优化 goodput（满足 SLO 约束下的单位 GPU 可服务请求率）。这点非常“工程真相”。

论文报告的核心收益是：

  • 相比主流方案，最高 7.4× 请求率提升；
  • 或在同样请求率下，实现 12.6× 更严格 SLO；
  • 且 >90% 请求满足延迟约束。

这是“性能数字 + 用户体验 + 成本效率”三者同时进步，而不是单指标提升。

2. 给“零基础读者”的前置知识

这一节我会从最基础的系统直觉开始讲起。

2.1 什么是大模型在线服务

当你在聊天助手里提问，后台并不是“直接跑一个函数然后秒出答案”。

真实系统要做很多事：

  1. 接收请求，
  2. 把请求排队、分批，
  3. 调度 GPU，
  4. 执行推理，
  5. 把生成内容流式返回，
  6. 同时保证延迟和成本别失控。

所以 LLM serving 本质是“模型计算 + 分布式系统 + 调度优化”的组合题。

2.2 Prefill 和 Decoding 到底在做什么

自回归生成通常分两段：

  1. Prefill 阶段：先把整段输入提示词吃进去，算出首个输出 token。
  2. Decoding 阶段：后续 token 一个一个往外生成。

生活化比喻：

  • prefill 像“做菜前备菜、起锅、下第一铲”；
  • decoding 像“后续一盘盘持续出菜”。

两段流程连续，但计算形态很不一样。

2.3 TTFT、TPOT、SLO、SLO 达标率

论文关心两个核心延迟指标：

  • TTFT（Time To First Token）：从请求发出到看到第一个 token 的时间。
  • TPOT（Time Per Output Token）：首 token 之后，每个输出 token 的平均生成时间。

再往上是服务目标：

  • SLO：例如 TTFT ≤ 0.25s、TPOT ≤ 0.1s。
  • SLO attainment：满足 SLO 的请求比例（例如要 ≥90%）。

如果系统“平均很快”但尾部很慢，SLO 达标率会很难看，用户体验也会变差。

2.4 Throughput 与 Goodput 的区别

很多人容易混：

  • Throughput：每秒处理了多少 token 或请求。
  • Goodput（本文定义）：在 SLO 达标率目标下，每块 GPU 能承载的最大请求率。

你可以 throughput 很高，但一半请求都超时，那对产品几乎没意义。

DistServe 选择优化 goodput，是非常务实的方向。

2.5 GPU 上的“算力瓶颈”与“带宽瓶颈”

GPU 性能瓶颈常见两类：

  • 算不过来（compute-bound），
  • 数据搬运不过来（memory-bandwidth-bound）。

在 LLM 推理里：

  • prefill（尤其长输入）常偏算力密集，
  • decoding（每步一个 token）常偏带宽密集。

这意味着它们在同一资源池共存时，容易互相拖累。

2.6 批处理与排队：为什么延迟会突然恶化

批处理能提升利用率，但不同“作业长度”的任务混在一起时，排队延迟会迅速上升。

特别是“长 prefill + 短 decode”混批时，decode 会被长任务卡住，TPOT 被抬高。

DistServe 在论文中用排队模型（M/D/1 思路）解释了这种现象，不是拍脑袋结论。

2.7 Intra-op / Inter-op 并行是什么

  • Intra-op 并行（可理解为张量并行风格）：把一个算子拆到多卡并行，单步更快，但通信开销高。
  • Inter-op 并行（可理解为流水并行风格）：按层分 stage 形成流水，吞吐扩展好，但会有流水气泡和协同成本。

关键点：prefill 与 decoding 的最优并行策略往往不同。

Prefill 与 decoding 解耦后，需要传 KV cache。传输开销受网络拓扑强烈影响：

  • 同节点 NVLINK：很快；
  • 跨节点网络：可能明显慢（论文实验里是 25Gbps）。

所以 DistServe 不是“只讲算法”，还专门做了网络感知的放置策略。

3. DistServe 试图解决的核心矛盾

现有系统（如 vLLM、DeepSpeed-MII）常把 prefill 和 decoding 放在同一批 GPU 上协同调度。论文指出这会导致两个根本问题：

  1. Prefill-Decoding 干扰（interference）
    • prefill 常比 decode step 慢很多，混在一起时会拖慢 decode。
    • decode 也会给 prefill 增压。
  2. 资源与并行策略耦合（coupling）
    • 两个阶段被迫共享同一套资源配置和并行策略，无法各自最优。

图 1 给了非常直观的证据：

  • 13B 模型、给定工作负载下，现有系统单卡 goodput 约 1.6 rps；
  • 若只做 prefill，可到 5.6 rps；
  • 若只做 decoding，可到 10 rps；
  • 理想解耦后（如 2 卡 prefill + 1 卡 decode）总体效率显著更高。

这不是“微调调度参数”能彻底解决的问题，而是架构层面的冲突。

4. 关键洞察：Prefill 与 Decoding 不应被强行绑在一起

DistServe 的核心思想很简单也很硬核：

把 prefill 与 decoding 分配到不同 GPU 实例上，分别优化 TTFT 与 TPOT。

这样做有两大直接收益：

  1. 消除直接计算干扰；
  2. 让两阶段各自选择更适合自己的资源和并行策略。

代价是需要在两阶段之间传 KV cache。

论文并不回避这个代价，而是把它纳入 placement 优化问题，并在实验中证明：只要放置合理，传输成本远小于解耦收益。

5. DistServe 的系统架构与请求生命周期

结合论文图 6：

  1. 请求进入中心控制器；
  2. 控制器把请求派发给队列较短的 prefill 实例；
  3. prefill 完成首 token 计算并产出 KV cache；
  4. decoding 实例拉取 KV cache，继续逐 token 生成；
  5. 输出回传给用户。

几个关键工程点：

  • DistServe 不是重写整个推理引擎，而是“编排层 + 并行执行引擎”组合；
  • 支持跨实例 KV 流转；
  • 使用 pull 式 KV 传输应对突发流量，避免 decode 端内存被突发写爆。

这类细节很重要，因为真正上线时，稳定性和尾延迟常由这些“看起来不起眼”的机制决定。

6. 论文中的权衡分析（Tradeoff Analysis）

6.1 Prefill 实例分析

6.1.1 批处理策略

图 3(a) 的核心观察：

  • 当输入足够长时，prefill 在很小 batch 下就能把 GPU 算力吃满；
  • 继续加 batch 并不能显著提效，反而会增加等待和 TTFT。

论文定义了阈值 (L_m)：输入长度超过 (L_m) 后，prefill 进入“近似算力饱和”。

调度上就应避免盲目堆 batch。

6.1.2 排队模型与并行选择

论文给了简化模型，帮助理解并行策略为什么会在不同负载下出现优劣反转。

单设备下平均 TTFT 近似：

Avg_TTFT=D+RD22(1−RD)\text{Avg\_TTFT} = D + \frac{R D^2}{2(1-RD)}

其中 (D) 是执行时间，(R) 是到达率。

再引入两种并行后（论文 Eq.2/Eq.3），得到结论：

  • 低到达率下，intra-op 可能更好（执行时间下降）；
  • 高到达率下，inter-op 常更好（排队与扩展性优势）。

图 4 的实验与推导一致，这种“理论-实验一致性”是论文可信度的加分项。

6.2 Decoding 实例分析

Decoding 的关键特点是“单步带宽受限”，因此非常依赖批处理来提升利用率。

图 3(b)、图 5 显示：

  • batch 变大时吞吐显著提升；
  • intra-op 可以降延迟但收益递减；
  • inter-op 在一定条件下近线性扩吞吐。

此外，decoding 需要长期持有活跃请求 KV cache，受显存容量约束明显。

所以论文在解耦后允许“一个 decoding 实例对应多个 prefill 实例”，从而更容易聚出较大 decode batch，提高整体 goodput。

6.3 工程落地中的现实问题

变长输入引发流水气泡

真实请求长度不均匀会导致 pipeline stage 不平衡。论文在运行期通过分批策略尽量让每批“有效 token 量”靠近目标值，减少气泡。

KV 传输压力

论文举例：OPT-66B、512 token 请求的 KV cache 约 1.13GB。

若 10 rps，则约 11.3GB/s（约 90Gbps）传输需求。

这解释了为什么 placement 必须网络感知，而不是仅按算力放置。

集群拓扑限制

当跨节点带宽不足时，必须尽量把相关 stage 放在同节点走 NVLINK，DistServe 的 low node-affinity 算法就是为此设计。

7. 方法部分：Placement 优化算法

目标函数很明确：

在给定模型、负载分布、SLO 与达标率目标下，找到使 per-GPU goodput 最大的放置方案。

7.1 高节点亲和场景（Algorithm 1）

假设跨节点网络足够快，KV 传输约束较弱。

流程：

  1. 枚举 prefill 并行配置并模拟；
  2. 二分搜索满足 SLO 达标率的最大请求率；
  3. decoding 做同样流程；
  4. 按目标流量做实例复制。

论文给出复杂度 (O(NM^2))（(M) 常见为每节点 8 卡），可接受。

7.2 低节点亲和场景（Algorithm 2）

假设跨节点带宽较弱（实验就是这类）。

关键做法：

  • 用 inter-op 分 stage；
  • 将 prefill 与 decoding 的对应 stage 尽量同节点 colocate；
  • 让 KV 传输主要走 NVLINK。

该算法多了约束，但能显著降低传输对尾延迟的冲击。

7.3 为什么要做模拟器（Simulator）

现实中不可能把所有并行与放置组合都在真机跑一遍。

DistServe 通过延迟模型 + 离散事件模拟估算 SLO 达标率，再做搜索。

附录 A 给了建模思路（prefill 与 decode 的主要计算/访存项分解）。

Table 2 显示模拟结果与真机误差 <2%，说明该模拟器在论文场景下是实用的。

7.4 在线调度与运行期优化

论文不止有“离线规划”，还补上了运行期优化：

  • FCFS 基础调度；
  • 通过 token 预算减小 pipeline bubbles；
  • pull 式 KV 传输对抗突发；
  • 周期性重规划（replan）应对负载漂移；
  • 讨论了 preemption 与故障容错作为后续方向。

8. 实现细节

论文实现量级：

  • placement + 前端 + 编排层：约 6.5K 行 Python；
  • 并行执行引擎：约 8.1K 行 C++/CUDA。

组件上：

  • OpenAI API 兼容前端；
  • NCCL 跨节点通信；
  • 节点内异步 CudaMemcpy；
  • Ray actor 管理执行 worker；
  • 集成 continuous batching、FlashAttention、PagedAttention 等优化。

这说明论文原型不是“玩具实现”，具备相当工程完整度。

9. 实验设置

9.1 集群与硬件

  • 4 节点共 32 卡；
  • 每节点 8×A100-80GB（NVLINK 互联）；
  • 跨节点带宽 25Gbps。

9.2 模型

OPT-13B、OPT-66B、OPT-175B，均 FP16。

作者故意选经典 MHA 架构（非 GQA/MQA），让 KV 传输压力更大，验证更保守。

9.3 工作负载与应用（Table 1）

  • Chatbot（ShareGPT）：
    • 13B: TTFT 0.25s, TPOT 0.1s
    • 66B: TTFT 2.5s, TPOT 0.15s
    • 175B: TTFT 4.0s, TPOT 0.2s
  • Code completion（HumanEval）：TTFT 0.125s, TPOT 0.2s
  • Summarization（LongBench）：TTFT 15s, TPOT 0.15s

9.4 对比基线

  • vLLM
  • DeepSpeed-MII（含 chunked prefill 思路）

主指标：SLO 达标率曲线，关注 90% 目标下可承载请求率和可承受最严 SLO。

10. 结果解读（含图表证据）

10.1 Chatbot 场景

图 8 给出核心结论：

  • DistServe 相比 vLLM，可承载请求率提升 2.0×–4.6×；
  • 相比 DeepSpeed-MII，提升 1.6×–7.4×；
  • 相比 vLLM，能承受 1.8×–3.2× 更严格 SLO。

原因剖析：

  • chatbot 对 TPOT 很敏感；
  • colocation 下长 prefill 对 decode 拖累严重；
  • DistServe 解耦后可单独优化 decode，TPOT 违规大幅减少。

论文还举了 175B 场景的并行配置示例，prefill 与 decoding 的最优配置不同，说明“自动搜索”是刚需，不是可有可无。

10.2 代码补全场景

图 9(a)：

  • DistServe vs vLLM：请求率 5.7×；
  • DistServe vs DeepSpeed-MII：请求率 1.6×；
  • SLO 严格度约 1.4× 提升。

代码补全是极低 TTFT 需求场景，DistServe 的 prefill 优化收益会被放大。

10.3 文档摘要场景

图 9(b)：

  • DistServe vs vLLM：请求率 4.3×；
  • DistServe vs DeepSpeed-MII：请求率 1.8×；
  • DistServe 可承受 SLO 严格度比 vLLM 高 12.6×（非常显著），比 MII 高 2.6×。

摘要任务常有长输入，对 prefill 压力巨大。colocation 会把这种压力外溢到 decode，DistServe 的阶段隔离优势在此非常明显。

10.4 延迟拆解：KV 传输是否拖后腿

图 10 给出关键证据（OPT-175B + ShareGPT）：

  • KV 传输在总延迟中占比 <0.1%；
  • 超过 95% 请求传输延迟 <30ms。

这说明 DistServe 的网络感知放置策略有效，通信并没有成为主要瓶颈。

10.5 消融实验与模拟器准确性

Table 2：模拟器与真机 SLO 达标率误差都很小（<2%）。

图 11：

  • 只给 vLLM 加并行搜索（vLLM++）收益很有限；
  • 真正决定性提升来自“prefill/decoding 解耦”；
  • 在高带宽跨节点假设下，DistServe 还能进一步提升。

10.6 算法运行时间

图 12 显示 placement 算法运行在秒到分钟级，最大场景约 1.3 分钟量级，可用于周期性重规划。

对于生产系统，这是可接受开销。

11. 我对这篇论文的技术判断

我给 DistServe 的总体评价是：工程价值非常高，且研究思路扎实。

理由有五点：

  1. 目标对（goodput + SLO 达标），不是“只卷吞吐数字”；
  2. 诊断准（干扰 + 耦合），不是“调参式补丁”；
  3. 方法完整（分析 + 算法 + 运行期机制）；
  4. 证据充分（多模型、多场景、含消融与误差校验）；
  5. 落地意识强（网络拓扑、传输策略、重规划）。

在 LLM serving 领域，这种“从问题定义到部署细节都闭环”的工作并不多见。

12. 局限性与边界条件

论文也诚实讨论了适用边界，我补充成更工程化的版本。

12.1 非延迟敏感场景

如果业务主要看离线吞吐，不强调 TTFT/TPOT，DistServe 的复杂度收益比可能下降。

12.2 极小规模资源环境

只有 1–2 张卡时，可选并行/放置空间太小，解耦收益可能不如系统复杂度带来的维护成本。

12.3 对负载统计稳定性的依赖

placement 依赖负载分布估计。若业务突发变化剧烈且频繁，规划结果可能过时，需要更激进的在线自适应。

12.4 运行期策略仍可更强

当前 FCFS 可能出现 convoy effect；抢占与故障恢复机制仍有改进空间。

12.5 网络条件极差时的风险

如果节点内外都缺乏高带宽，KV 传输可能重新成为瓶颈，解耦收益会被侵蚀。

13. 复现与工程落地清单

如果你要在公司里复现 DistServe 思路，我建议按这个顺序推进。

13.1 先做诊断

  • 采集 TTFT/TPOT 的 P50/P90/P99；
  • 统计 prefill/decode 队列等待占比；
  • 估算 KV 大小分布与传输带宽需求；
  • 定位目前最大 SLO 违规来源。

13.2 再做规划

  • 建立简单但可校验的延迟模型；
  • 用仿真替代全量真机穷举；
  • 搜索 prefill/decode 并行配置；
  • 决定实例复制比例以满足目标流量。

13.3 最后做运行期策略

  • 采用分阶段队列与调度；
  • 实现 pull 式 KV；
  • 加入负载漂移检测与周期重规划；
  • 加入容量水位、退化策略和告警。

13.4 关键监控指标

至少要持续监控：

  • TTFT/TPOT 分位数，
  • SLO 达标率，
  • 每 GPU goodput，
  • 分阶段队列长度与等待时间，
  • KV 传输延迟分布，
  • 重规划频率与生效收益。

14. 如果明天要上线 LLM 服务，我会怎么用这篇论文

14.1 什么时候优先采用 DistServe 思路

  • 你有明确 TTFT + TPOT 双 SLO；
  • 你已经观测到 prefill/decode 互相拖慢；
  • 你关心每张 GPU 的成本产出；
  • 你的集群至少有较好的节点内带宽。

14.2 什么时候先不采用

  • 业务是离线批处理、延迟不敏感；
  • 集群规模太小；
  • 网络条件不足且短期不可改善。

14.3 实施路径建议

  1. 先在一个高价值模型上灰度试点；
  2. 验证 SLO 达标率与成本收益；
  3. 再扩展到多模型、多应用调度；
  4. 最后完善抢占、故障隔离与自动回滚。

15. 总结

DistServe 的关键贡献不只是“把 prefill 和 decode 分开”这么一句口号，而是：

  • 先证明现有架构的干扰与耦合问题确实存在且严重；
  • 再给出可执行的、网络感知的放置算法；
  • 再用系统实现和端到端实验证明收益真实可落地。

一句话收尾：

在强调服务质量（TTFT/TPOT）与成本效率（per-GPU goodput）的 LLM 线上服务里，DistServe 提供了非常值得借鉴的架构基线。

16. 参考文献

  1. Yinmin Zhong, Shengyu Liu, Junda Chen, Jianbo Hu, Yibo Zhu, Xuanzhe Liu, Xin Jin, Hao Zhang. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving. OSDI 2024. arXiv:2401.09670.
  2. Woosuk Kwon et al. Efficient Memory Management for Large Language Model Serving with PagedAttention (vLLM). SOSP 2023.
  3. Amey Agrawal et al. Sarathi: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills. arXiv 2023.
  4. Bingyang Wu et al. Fast Distributed Inference Serving for Large Language Models (FastServe). arXiv 2023.
  5. Zhuohan Li et al. AlpaServe: Statistical Multiplexing with Model Parallelism for Deep Learning Serving. arXiv 2023.
  6. Pratyush Patel et al. Splitwise: Efficient Generative LLM Inference using Phase Splitting. arXiv 2023.

评审写于 2026-04-09。