arno
c0ba3fb853
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
121 lines
11 KiB
Markdown
121 lines
11 KiB
Markdown
# 揭秘老黄演讲中关键技术：PD分离！UCSD华人团队力作，LLM吞吐量跃升4倍
|
||
|
||
> **来源**：微信公众平台（新智元）
|
||
> **作者**：新智元（编辑：静音、定慧）
|
||
> **发布日期**：2026-08-05（原文未标注明确日期，文中提及黄仁勋 2025 GTC，按下载日占位）
|
||
> **原文链接**：https://mp.weixin.qq.com/s/kdxJng0X3RT2UU8EnuxeSw
|
||
|
||
> 新智元报道。本文是 DistServe（UCSD Hao AI Lab 华人团队）PD分离技术的中文解读，覆盖 Goodput、TTFT/TPOT、Prefill/Decode 干扰、分离架构、2P1D 实验量化、KV Cache 传输开销、DistServe vs vLLM 评估，是 DistServe 论文核心数据的中文可引用出处。
|
||
|
||
---
|
||
|
||
**【新智元导读】** 老黄 GTC 重点展示的 PD 分离技术为何成兵家必争之地？UCSD 全华人团队力作，创新性地提出预填充-解码分离技术。在严格的延迟约束下，相比现有最先进的服务系统，可实现高达 4.48 倍的有效产出率或 10.2 倍更严格的 SLO 达成率。
|
||
|
||
现在，PD 分离已经成为兵家必争之地。
|
||
|
||
前有 Mooncake/DeepSeek 等公司采用这种技术来优化大模型的推理服务，后有 Nvidia/PyTorch 基于该技术孵化下一代 LLM 服务系统。
|
||
|
||
甚至最近，黄仁勋也在 2025 GTC 的舞台上提到了 PD 分离（Prefill-Decode Disaggregation）技术，进一步证明了这一技术获得的广泛关注。
|
||
|
||
去年，来自 UCSD 的一个华人团队发布的一篇博客，就深入剖析了这一技术的原理和它的应用场景。博客地址：https://hao-ai-lab.github.io/blogs/distserve/
|
||
|
||
## 吞吐量与有效吞吐量
|
||
|
||
如今，大语言模型应用有着不同的延迟需求。例如，聊天机器人需要快速响应（比如低于 0.2 秒），而解码速度可以较为适中，仅需与人类阅读速度相匹配；代码补全则要求快速生成，以便实时提供代码建议。
|
||
|
||
文章中展示了现有的优化吞吐量的服务系统，在延迟标准下并不理想。作者提议使用「有效吞吐量」（goodput）作为大模型服务性能的改进衡量标准，它不仅关注每秒完成请求的数量，而且符合服务级目标（SLO），更好地平衡成本和用户体验。
|
||
|
||
为了提升有效吞吐量，文章提出了「预填充-解码分离」（prefill-decode disaggregation），即将预填充和解码分配到不同的 GPU 上。通过这个方法，作者搭建了一个系统原型 DistServe，在保持严格的延迟约束下，达到了比现有系统高出 4.48 倍的有效吞吐量，或者 10.2 倍更严格的 SLO。
|
||
|
||
### LLM 正在改变行业对 AI 的应用，但 LLM 服务成本仍然很高
|
||
|
||
为了降低成本，很多公司专注于提升 LLM 系统的吞吐量，即每秒处理的请求数（rps），作为每个请求成本（$/req）的替代指标。大多数流行的 LLM 服务引擎，如 vLLM 和 TensorRT-LLM，都用吞吐量来衡量性能。
|
||
|
||
然而，实际应用对延迟的要求各不相同，因此服务级目标（SLO）也不同。常见的 SLO 包括：
|
||
|
||
- **首次 token 延迟（TTFT）**：测量 LLM 生成第一个 token 的时间
|
||
- **每个输出 token 的时间（TPOT）**：测量两个连续生成的 token 之间的平均延迟
|
||
|
||
吞吐量只关注处理的请求或 token 数，却忽视了这些延迟需求。作者引入了有效吞吐量（goodput），它衡量每秒完成的符合 SLO 的请求数（同时满足 TTFT 和 TPOT 要求）。这比吞吐量更能反映服务质量，因为它考虑了成本和用户体验。
|
||
|
||
那么，到底什么是有效吞吐量？假设一个应用要求 90% 的请求 TTFT 小于 200 毫秒，TPOT 小于 50 毫秒，那么有效吞吐量就是每秒能完成的最大请求数，且至少 90% 的请求同时满足这两个条件。一个高吞吐量的应用可能有低的有效吞吐量——虽然吞吐量是 10 个请求每秒，但因为延迟约束，只有 3 个请求符合 SLO，最终的有效吞吐量只有每秒 3 个请求。
|
||
|
||
术语小结：
|
||
|
||
- **有效吞吐量（goodput）**：衡量 LLM 服务系统效能的指标，考虑了成本和用户满意度。定义为每秒系统可以完成的请求数量，同时满足指定的 SLO。
|
||
- **吞吐量**：LLM 服务系统每秒处理的已完成请求数量。
|
||
- **服务级目标（SLO）**：常见包括 TTFT、TPOT、端到端延迟（E2E）和指数加权平均（EMA）延迟。
|
||
- **预填充（Prefill）**：LLM 推理的第一阶段，处理所有输入 token，填充 KV 缓存，并生成第一个输出 token。
|
||
- **解码（Decode）**：随后的阶段，通过自回归方式生成 token，直到完成。
|
||
|
||
## 为什么现有系统无法实现高有效吞吐量？
|
||
|
||
LLM 服务请求的流程：请求进入 LLM 推理引擎，系统首先处理用户输入生成第一个 token（预填充），然后通过自回归生成后续 token（解码）。一个请求通常包括一个预填充步骤和多个解码步骤。
|
||
|
||
LLM 服务系统通常将预填充和解码一起批处理（迭代调度或连续批处理 continuous batching），使 GPU 能尽量大批量处理，从而提高吞吐量。vLLM 和 TensorRT-LLM 等系统都广泛采用这一方法。
|
||
|
||
然而，预填充和解码在计算上有非常不同的特点。预填充非常依赖计算，即使是一个小批量的预填充，或仅仅是一个足够长的预填充，也会迅速饱和 GPU 计算资源。解码则需要更大的批量来达到计算瓶颈，且更容易受到 GPU 内存带宽限制的影响。
|
||
|
||
将这两者一起处理不利于优化有效吞吐量，原因有二：
|
||
1. 预填充和解码之间会互相干扰，导致性能下降；
|
||
2. 预填充和解码的资源分配及并行策略会相互耦合，难以优化。
|
||
|
||
### 预填充和解码的干扰
|
||
|
||
把两个请求批量到一个 GPU，解码（R1）延迟显著增加，预填充（R2）延迟稍微上升；稳定请求流中，每次解码遇到预填充请求时就会被「卡住」，解码延迟意外增加。这种干扰导致：为了满足 TTFT 和 TPOT 的 SLO，系统必须过度配置资源，尤其当某个 SLO 特别严格时。
|
||
|
||
此外，预填充和解码的资源分配和并行策略是耦合的。比如，当 TTFT 要求严格时，预填充阶段适合用张量并行（TP）来满足紧凑的延迟目标，而解码则更倾向于数据并行或流水线并行来提升吞吐量。
|
||
|
||
## 分离预填充和解码
|
||
|
||
直觉很简单：将预填充（Prefill）和解码（Decode）分配到不同的 GPU，并为每个阶段定制并行策略。这自然解决了上面两个问题：
|
||
1. 预填充和解码之间没有干扰，使得两个阶段都可以更快完成，并更容易满足各自的 SLO；
|
||
2. 资源分配和并行策略解耦，优化可以针对预填充和解码分别进行。
|
||
|
||
当请求到达系统时：① 首先进入预填充工作节点并完成预填充阶段；② 然后，系统将其中间状态（主要是 KV 缓存）迁移到解码工作节点，并进行多个解码步骤以生成后续 token；③ 请求在生成完成后离开系统。
|
||
|
||
### 一个简单的实验验证
|
||
|
||
在单个 A100-80GB GPU 上运行一个 13B 的 LLM，使用输入长度 512、输出长度 64 的合成工作负载，假设请求按泊松分布到达。逐渐增加请求速率（x 轴），测量 P90 TTFT 和 P90 TPOT（y 轴）。
|
||
|
||
将 SLO 设置为 P90 TTFT 小于 0.4 秒，P90 TPOT 小于 0.04 秒。现有系统使用 1 个 GPU 时，大约支持 3 rps（TTFT），而 TPOT 则支持 1.6 rps。由于需要同时满足两个约束，现有共同处理系统的有效吞吐量为：
|
||
|
||
**有效吞吐量（同时满足）= min(3, 1.6) = 1.6 rps（每个 GPU）。**
|
||
|
||
分离后，性能显著提升。预填充工作节点和解码工作节点在仅处理单个阶段时，可分别达到约 5.6 rps 和 10 rps。更重要的是，可以灵活地分配 2 个预填充工作节点与 1 个解码工作节点（记作 2P1D），总共使用 3 个 GPU。此时：
|
||
|
||
**有效吞吐量（2P1D）= min(5.6 × 2, 10) = 10 reqs/s ÷ 3 GPUs ≈ 3.3 reqs/s（平均每个 GPU）。**
|
||
|
||
这个实验表明，简单的分离方法在没有任何并行化的情况下就能实现 **2 倍**的有效吞吐量（3.3 rps VS 1.6 rps）。额外的好处是，预填充与解码的分离还能够为每个阶段选择最佳的并行策略来优化有效吞吐量（作者称之为「定制并行 tailored parallelism」）。
|
||
|
||
## KV 缓存传输
|
||
|
||
分离的一个代价是需要在预填充和解码 GPU 之间传输中间状态（即 KV 缓存）。乍一看，KV 缓存是 LLM 推理中一个大的内存开销，而在 GPU 之间传输 KV 缓存似乎是一个瓶颈。
|
||
|
||
但相反，通过合理的放置，KV 缓存传输的开销可以被有效地最小化，低至小于一个解码步骤的时间，这得益于今天高速的网络技术，如 NVLink 和 PCI-e 5.0。
|
||
|
||
假设有 8 通道 PCIe 5.0 x16（每个链路 64GB/s）作为 GPU 之间的节点内网络。给定一个 2048 token 的请求，在服务 OPT-175B 时传输 KV 缓存的延迟为：
|
||
|
||
**延迟 = 2048 token ×（4.5 MB/token）÷（64GB/s × 8）= 17.6 毫秒**
|
||
|
||
这个延迟小于 OPT-175B 的单个解码步骤的时间（约 30-50 毫秒，使用 A100）。对于更大的模型、更长的序列或更先进的网络（例如具有 600GB/s 带宽的 A100-NVLink），KV 缓存传输的比较开销与单个解码步骤相比变得更加微不足道。精心放置预填充和解码工作节点以利用高带宽网络，可以有效地隐藏 KV 缓存传输的开销。
|
||
|
||
## DistServe：评估分离的效果
|
||
|
||
作者在一个名为 DistServe 的系统原型中实现了所提出的技术，并在三个具有不同延迟约束的工作负载和数据集上与现有系统（vLLM）进行了比较：聊天机器人、代码补全和摘要。
|
||
|
||
- **聊天机器人**：DistServe 的有效吞吐量比 vLLM 高 **2.0 倍到 3.41 倍**。
|
||
- **代码补全**：DistServe 的有效吞吐量比 vLLM 高 **3.2 倍**，并且 SLO 比 vLLM 严格 1.5 倍。通过消除解码任务的干扰，并为预填充定制张量并行策略，DistServe 减少了预填充任务的平均延迟，从而满足更多请求的 TTFT 要求。
|
||
- **摘要**：DistServe 的有效吞吐量比 vLLM 高 **4.48 倍**，并且 SLO 比 vLLM 严格 **10.2 倍**。由于 vLLM 将预填充和解码放在一起，它在解码阶段的减速更大，未能满足 TPOT 要求。
|
||
|
||
## 团队成员
|
||
|
||
以上研究出自加州大学圣地亚哥分校的 Hao AI 实验室，全部来自于华人研究者：
|
||
|
||
- **Yinmin Zhong（一作）**：北京大学计算机系统研究组三年级博士生，导师金鑫。
|
||
- **Junda Chen**：2023 年秋季入学的计算机科学博士生，研究高效 LLM 服务系统。
|
||
- **刘胜与**：北京大学本科生。
|
||
- **Hao Zhang**：加州大学圣地亚哥分校计算机科学与工程系助理教授，领导 Hao AI 实验室。
|
||
|
||
> 参考资料：https://hao-ai-lab.github.io/blogs/distserve/
|