PD 分离推理架构的讲解视频可以在这里观看：

这篇文章是 LLM 推理系列的第 篇，介绍 PD 分离推理架构。

往期文章

• vLLM 快速部署教程
• vLLM 关键技术 PagedAttention 原理详解
• Prefix Caching 详解：实现 KV Cache 的跨请求高效复用
• Speculative Decoding 推测解码方案详解
• Chunked-Prefills 分块预填充机制详解

使用者痛点 🚩

• 首 token 延迟过高：使用者在聊天或搜索场景下会因等待首个响应而产生明显卡顿感。
• Token 间延迟不稳定：生成长文本时间隔时间波动大，导致交互流畅度下降。
• 资源浪费：传统 continuous batching 将 prefill 与 decode 混合。会出现算力与显存的相互抢占，导致 GPU 利用率低下。按理说，
• SLO 难以同时满足：单一指标无法反映实际服务质量。很多请求在满足吞吐的同时已经违背了延迟约束。

吞吐量vs 有效吞吐量

目前，大多数 LLM 服务程序都以吞吐量作为主要性能指标——即单位时间内处理的请求数或生成的 token 数。这种度量方式直观，而且与成本有直接关联，所以

只是下游应用的类型多种多样。它们在使用者体验上的延迟需求各异，需要满足的服务等级目标也存在显著差异。大模型服务中最常用的 SLO 包括：

• TTFT 首 token 响应延迟，直接影响使用者的等待体验。不过，
• TPOT 衡量两个连续生成的 token 之间的平均延迟。决定交互的流畅程度，

例如实时聊天机器人更关注低 TTFT，以保证响应及时而 TPOT 只需快于人类阅读速度即可；不过，相反，文档摘要则更强调低 TPOT，以便更快地产生完整摘要。

单纯依赖 Throughput 作为指标，并不能反映延迟表现；程序看似处理了大量请求，但其中不少未能满足 SLO。最终呈现给使用者的仍是不理想的服务体验。

• Throughput: 程序单位时间内处理的 token 数或请求数。很多工作把“提高吞吐量”作为主要调整目标，但这并不直接代表使用者体验。
• Goodput: 程序在满足延迟约束的前提下真正完成的请求数量。如果一个请求因为延迟过长而被使用者放弃，或者超过服务约束而无效。那么即便它产生了 token，也不能算作有效产出。

在 DistServe 论文中。引入了 Goodput 概念，即在满足 SLO的前提下每秒完成的有效请求数。与单纯的吞吐量相比，Goodput 更能体现请求在满足 SLO 情况下的吞吐水平。从而同时反映成本效益与服务质量。

为了简要说明 Goodput，假设某个应用要求至少 90% 的请求满足 TTFT < 200 ms 且 TPOT < 50 ms，则可以得到如下定义：

下图展示了一个简单例子：某应用的吞吐量为 **RPS**。但由于延迟约束，仅 **RPS** 的请求满足 SLO，所以该程序的 Goodput 仅为 **RPS**。话说回来，可以想象，在高吞吐但低 Goodput 的程序中。使用者仍会感受到较差的服务体验。

Prefill 与 Decode 共置导致干扰 ⚡️

L​LM 服务中，请求生命周期通常包含两个阶段：prefill和 decode。 大多数现有程序采用 continuous batching 技术，将 prefill 和 decode 混合统一批处理。这种方式提高整体吞吐，但由于两者计算特性和 SLO 目标差异显著。将它们共置在同一 GPU 上往往并不理想。

当 prefill 与 decode 被放在同一批次时decode 请求的延迟会被显著拉长，而 prefill 请求的首 token 延迟也会有所增加。

图中展示了三种不同执行方式：

• 1P+nD：a 个 prefill 与 n 个 decode 混合批处理。
• nD：
• PREFILL‑ONLY：

实验表明：

PD 分离整体思路 🚀

Goodput = min = 60 reqs/s ÷ 3 GPUs ≈ 20 rps/GPU