文档(金鹏): 2026-08-06 章节 48 篇文章摘要归档
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
This commit is contained in:
@@ -0,0 +1,122 @@
|
||||
# 【推理】PD分离的绝佳入门教程 —— DistServe
|
||||
|
||||
> **来源**：知乎专栏
|
||||
> **作者**：Zoe Lee
|
||||
> **发布日期**：2026-08-05
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/19666783423
|
||||
|
||||
---
|
||||
|
||||
作为推理服务中PD分离的技术的经典方法之一，DistServe（OSDI 2024）无疑为广大学者提供了一份绝佳的入门教程。该工作详细分析了PD分离的技术动机、提出了通俗易懂的PD分离算法思想、并充分开源了代码，让每一个想了解PD分离技术的人都能够"亲自把玩"。
|
||||
|
||||
本文为在精度论文并部署代码进行多组实验后整理的"玩后感"，会从PD分离技术动机、DistServe项目算法思想、code实现以及个人理解等方面展开介绍。本人初学，望看到本文的大佬们多多指点交流～
|
||||
|
||||
## 1. PD分离技术动机
|
||||
|
||||
我们知道一条请求在推理的过程中需要经过两个步骤：第一步，根据输入序列的内容生成第一个token，该过程称为Prefill；第二步，根据输入序列以及之前已经生成的token生成下一个token，该过程称为Decoding。随着"以存代算"的KV-Cache技术的引入，大多推理过程避免了在Attention结构的重复计算，这导致Prefill与Decoding在执行时存在着较大的差异。
|
||||
|
||||
为什么Prefill和Decoding存在较大的差异？
|
||||
|
||||
首先我们从计算过程上去直观理解两个步骤的区别。在Prefill阶段，模型输入prompt的所有token，经过一步计算后得到第一个输出，与此同时每个token在计算时产生的KV-Cache被储存下来，而在Decoding阶段，每个新token的计算都会涉及到KV-Cache的读取与存储，而计算量相比Prefill而言被大大降低了，取而代之的是高频的存取操作带来的压力，这便是KV-Cache技术带来的Prefill和Decoding的差异化。
|
||||
|
||||
这种差异是否会导致放在一个batch中处理会相互拖后腿？
|
||||
|
||||
论文通过实验给出了肯定的答案。下图表示在全部是decoding状态的batch中加入一个做prefill的请求导致的延迟变化。蓝色线条的起点表示只处理一条prefill的延迟，蓝色后面的点与起点的差值都可以看做添加decoding状态的请求对该prefill状态的请求带来的延迟危害，而蓝色与橙色对应节点的差值可以看作添加的一个prefill状态的请求对decoding状态的请求batch带来的延迟危害。
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
综合分析，两阶段混合推理带来的主要问题如下：
|
||||
|
||||
1. 调度低效：在相同GPU上进行不同状态的调度会造成decoding等待prefill的现象，并且GPU在进行decoding会导致资源低利用率；
|
||||
2. 资源和并行策略的耦合：两阶段的差异对于资源和并行策略的需求不同，相同GPU上部署不可避免的会导致两阶段资源和并行策略的共享。
|
||||
|
||||
至此，PD分离就成为了一种最为直接的解决思想。
|
||||
|
||||
## 2. P/D阶段特性分析
|
||||
|
||||
在正式提出算法前，论文对于P和D阶段的batch策略和并行方案进行了分析。对于batch策略，论文通过以下实验对比了两阶段的不同特点：
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
Prefill阶段并不是batch size越大吞吐越大，吞吐随batch size的变化取决于输入文本的长度，因此在设置batch size时要考虑输入长度。而增加batch size对于Decoding阶段是一个避免低吞吐的好方法。
|
||||
|
||||
对于并行方式，为了分析Prefill阶段对于并行策略的偏好，论文首先利用M/D/1排队模型对请求队列进行了建模，进而TTFT就可以用请求在系统内的平均等待时间表示，加入Pipeline并行和Tensor并行的影响后，TTFT建模结果分别如下：
|
||||
|
||||
```
|
||||
PP=2: D + (R*D^2) / (4*(2 - R*D))
|
||||
TP=2: D/K + (R*D^2) / (2*K*(K - R*D))
|
||||
```
|
||||
|
||||
其中D为请求的执行时间，R为到达率，K为TP带来的影响系数，由于通信代价，通常 1<K<2 。当到达率R很小时，第一项执行时间为主要作用，这时TP的效果会更好，当R增加时第二项其主要作用，PP的效果则更好，结合实验结果看更清楚：
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
这一实验结论对根据不同场景下设置并行模式起到了参考作用。而Decoding阶段的并行模式分析同理，TP可以降低延迟，但是过大的TP会引入过量通信，延迟降低的优势也就不再明显，PP虽不影响单个请求的执行时间，但可以加大吞吐。
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
不过对于这一部分的分析，本人也做了粗略的实验比较了一下两个阶段TP与PP的影响，发现对于给定P/D两阶段的卡数的情况下似乎并行策略的影响不大～但是论文这部分的分析确实具有一定的启发性。
|
||||
|
||||
接下来正式介绍DistServe项目的算法思想。整个项目分成两大部分：设计并行模式、执行分离式推理。
|
||||
|
||||
### 3.1 并行模式设计
|
||||
|
||||
论文的附录给出了对Prefill和Decode阶段的耗时建模方法，而在实验中，Prefill延迟模型为：
|
||||
|
||||
```
|
||||
A + B*bs*l_in + C*sum_{i=1}^{bs} l_in_{i}^2
|
||||
```
|
||||
|
||||
Decoding延迟模型为：
|
||||
|
||||
```
|
||||
A + B*bs*l_in + C*bs
|
||||
```
|
||||
|
||||
其中 bs 为batch size， l_in 为输入的平均长度， l_in_{i}^2 表示第 i 个batch的请求平均输入长度的平方，通过采样实际执行时间，则可作为训练数据来分别拟合两个延迟模型的参数 A、B、C 。
|
||||
|
||||
总体寻优的思想也是比较清晰的。首先对不同并行策略下的耗时建立线性模型，再采集多组样本，对不同并行策略的线性模型进行拟合。值得一题的是，论文对Prefill和Decoding的耗时分别建立不同的模型，特别对于Decoding阶段又进一步区分了大Batch size和小Batch size两种场景下的建模。这或许可归因于第二节中对于Decoding阶段的分析，由于Decoding阶段的Batch size影响较大，区分建模能保证更高的精度。
|
||||
|
||||
模型建成后的寻优准则则是该论文与其他论文方法不同的地方。DistServe全篇更加强调对于TTFT和TPOT分别达到SLO的目标，因此寻优算法也遵从这一准则。算法如下：
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
前6行在做的就是遍历所有可能的并行模式，第7-13行开始利用拟合好的模型预测效果，筛选最佳方案，筛选标准是：（1）. 在Prefill和Decoding均满足SLO，（2）. 并行方案对应的最大支撑到达率大于输入到达率，对于每个并行方案的支撑到达率则采用二分查找法确定。最后在所有满足条件的方案中，找到需要GPU数量最少的方案输出。
|
||||
|
||||
论文同样给出了跨机的方法。跨机面临着缺少NVLink的高速连接，这时并行策略的性能则受制于机间通信带宽。不同于其他PD分离的方法，为了避免KV-Cache传输以及TP走机间通信，该论文在设置并行模式时，需要限制相同模型层的P和D需要在同一节点。示意图如下：
|
||||
|
||||
|
||||
|
||||
### 3.2 分离式推理
|
||||
|
||||
确定好并行模式后，就可以开始部署推理引擎了。
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
DistServe的整体逻辑遵从"生产者-消费者"模式，总体Engine负责管理Prefill、Decoding引擎，两个引擎分别实现了各自的调度器，Prefill引擎为生产者，Decoding引擎为消费者，到达的请求会首先分配到Prefill调度器的等待队列，一旦当前Prefill实例的资源满足该请求所需，就会被调度到Prefill引擎执行该阶段的计算，执行完Prefill的请求会被存储到一个中转队列中，该队列中的请求会等待Decoding调度器的调度，一旦Decoding调度器检测到中转队列请求所需资源能够满足，就会被调度到Decoding引擎，进而执行Decoding阶段的计算。
|
||||
|
||||
## 4. Code结构
|
||||
|
||||
整个DistServe项目的代码可以分成两个部分。一个部分是项目基座，由C++和CUDA语言编写，用于定义推理服务中涉及到的模型计算、通信、资源开辟释放等，该项目名为SwiftTransformer，主要包含了对Transformer架构模型的优化算子等。第二部分则是论文重点内容所涉及的调度层，主要由Python编写。而在真正执行服务时，还有一层与用户交互的api层，同样由Python编写。
|
||||
|
||||
|
||||
|
||||
代码结构说明
|
||||
|
||||
## 5. 总结与讨论
|
||||
|
||||
该项目作为PD分离的经典工作，非常适合刚接触该技术的初学者进行了解和学习。DistServe的实践简单、没有涉及过多的其他优化技巧，适合作为验证PD分离这一单一技术性能的工作，代码可读性比较高。然而也是因为实践方式较为简单，特别是对于跨机的方案限制比较多。
|
||||
|
||||
另外，PD分离技术的使用场景也有相应的限制，例如至少需要两张GPU，因此考虑PD分离技术的场景通常需有相对充足的GPU资源，才能让该技术发挥出更大的空间。
|
||||
@@ -0,0 +1,80 @@
|
||||
# 📊 文章摘要：【推理】PD分离的绝佳入门教程 —— DistServe
|
||||
|
||||
> **原文**：[2026-08-05_推理_PD分离的绝佳入门教程_DistServe.md](./2026-08-05_推理_PD分离的绝佳入门教程_DistServe.md)
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/19666783423
|
||||
> **来源**：知乎专栏
|
||||
> **作者**：Zoe Lee
|
||||
> **发布日期**：2026-08-05
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **精读范本** — 以 DistServe（OSDI 2024）为样本讲透 PD 分离的动机、建模与寻优方法，并附代码复现的一手体会。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
作者精读 DistServe 论文并部署代码实验后整理的"玩后感"：从混合 batch 中 prefill 与 decoding 相互拖累的实验证据出发说明 PD 分离动机；用 M/D/1 排队模型推导并行策略偏好（到达率低时 TP 更优、高时 PP 更优）；讲解对 Prefill/Decode 分别建立延迟模型、以"满足 TTFT/TPOT 双 SLO + 支撑到达率 + GPU 数最少"为准则的寻优算法，以及跨机部署限制（相同模型层的 P/D 必须同节点）。价值在于把论文方法论讲得通俗透彻，且作者亲自复现并报告了与论文结论存在张力的个人观察。局限是作者自认初学，跨机细节阐述有限。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **PD 分离动机有实验证据** — 混合 batch 中新增一个 prefill 请求会给 decoding 批处理带来显著的延迟危害（论文实验图），由此引出调度低效与资源/并行策略耦合两大问题 `[分类: 共识]`
|
||||
2. **batch 策略差异** — Prefill 吞吐随 batch size 的变化取决于输入文本长度，并非越大越好；增加 batch size 是 Decode 阶段避免低吞吐的好方法 `[分类: 共识]`
|
||||
3. **并行模式建模** — 用 M/D/1 排队模型推导 TTFT：到达率 R 小时 TP 效果更好，R 增加时 PP 更好；Decode 侧过大的 TP 会引入过量通信使延迟优势消失 `[分类: 范式突破]`
|
||||
4. **SLO 驱动的寻优算法** — 对 P/D 分别拟合延迟线性模型（Prefill 含输入长度二次项），遍历并行模式，筛选同时满足 TTFT/TPOT SLO 且支撑到达率达标的方案，取 GPU 数最少者 `[分类: 范式突破]`
|
||||
5. **跨机约束** — 为避免 KV Cache 跨机传输与 TP 走机间通信，设置并行模式时限制相同模型层的 P 和 D 在同一节点 `[分类: 未探索]`
|
||||
6. **生产者-消费者实现** — 总体 Engine 管理 Prefill 与 Decoding 两个引擎及各自调度器，prefill 产出经中转队列等待 Decoding 调度器消费；代码分 SwiftTransformer（C++/CUDA）基座与 Python 调度层两部分 `[分类: 共识]`
|
||||
7. **复现体会与论文结论的张力** — 作者粗略实验发现给定 P/D 卡数下并行策略的影响似乎不大，与论文强调并行模式寻优的价值形成对照（个人观察，尚需严格验证）`[分类: 争议]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设读者熟悉 Transformer 推理与排队论基础；DistServe 的目标函数假设 TTFT/TPOT SLO 由用户显式给定，寻优结论依赖延迟模型对真实系统的拟合精度。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
动机实验、延迟模型与寻优准则均忠实转述论文，并附作者部署代码的一手体会，论据扎实；作者对"并行策略影响不大"的观察明确标注为粗略实验，态度严谨，未以个人观察冒充论文结论。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
作者明确指出 PD 分离至少需要两张 GPU、跨机方案限制较多，适合 GPU 资源充足的场景；论文方法面向"以 SLO 为中心"的在线服务目标，对离线批处理等非 SLO 场景不适用，且 DistServe 实现未涉及按层传输等后续优化技巧。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "在相同GPU上进行不同状态的调度会造成decoding等待prefill的现象，并且GPU在进行decoding会导致资源低利用率"
|
||||
|
||||
> "Prefill阶段并不是batch size越大吞吐越大，吞吐随batch size的变化取决于输入文本的长度，因此在设置batch size时要考虑输入长度。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 把 DistServe 的动机实验、M/D/1 建模、寻优准则讲得透彻清晰，入门友好
|
||||
- 有真实部署与复现的一手体会，并诚实报告与论文结论的张力
|
||||
- 代码结构拆解（SwiftTransformer + Python 调度层）便于读者自行"把玩"
|
||||
|
||||
**不足**：
|
||||
- 作者自认初学，跨机方案细节与性能数字讨论有限
|
||||
- 个人复现实验未给出具体数据，观察结论有待验证
|
||||
|
||||
**适用场景**：初次接触 PD 分离的工程师与学生作为入门导读；准备精读 DistServe 论文与复现其代码的读者。
|
||||
|
||||
**关联建议**：对照阅读 DistServe 论文原文与 GitHub 仓库（LLMServe/DistServe）；与 akaihaoshuai 的实测结论（P/D 配比、cache 调度为核心）互相印证；进阶阅读 Mooncake（KVCache 中心化调度）与 NVIDIA Dynamo。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
Reference in New Issue
Block a user