【新智元导读】
老黄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服务引擎
LLM正在改变行业对AI的应用，但LLM服务成本仍然很高。
为了降低成本，很多公司专注于提升LLM系统的吞吐量，即每秒处理的请求数（rps），作为每个请求成本（$/req）的替代指标。
大多数流行的LLM服务引擎，如vLLM和TensorRT-LLM，都用吞吐量来衡量性能。
然而，实际应用对延迟的要求各不相同，因此服务级目标（SLO）也不同。常见的SLO包括：
应用程序有着多样的SLO要求
吞吐量只关注处理的请求或token数，却忽视了这些延迟需求。作者引入了有效吞吐量（goodput），它衡量每秒完成的符合SLO的请求数（同时满足TTFT和TPOT要求）。这比吞吐量更能反映服务质量，因为它考虑了成本和用户体验。
那么，到底什么是有效吞吐量？假设一个应用要求90%的请求TTFT小于200毫秒，TPOT小于50毫秒，那么有效吞吐量就是每秒能完成的最大请求数，且至少90%的请求同时满足这两个条件。
一个高吞吐量的应用可能有低的有效吞吐量。虽然吞吐量是10个请求每秒，但因为延迟约束，只有3个请求符合SLO，最终的有效吞吐量只有每秒3个请求。可以想象，尽管这种系统的吞吐量很高，但它的用户服务将很差。
高吞吐量≠高有效吞吐量
以下是在本小节中引入的术语：
-
有效
吞吐量
：
衡量LLM服务系统效能的指标，考虑了成本和用户满意度。它定义为每秒系统可以完成的请求数量，同时满足指定的服务级目标（SLO）。
-
吞吐量
：
LLM服务系统每秒处理的已完成请求数量。
-
服务级目标（SLO）：
LLM服务系统必须满足的目标，以提供令人满意的用户体验。常见的SLO包括首次token延迟（TTFT）、每个输出token时间（TPOT）、端到端延迟（E2E）和指数加权平均（EMA）延迟。
-
预填充：
LLM推理的第一阶段，处理所有输入token，填充KV缓存，并生成第一个输出token。
-
解码：
随后的阶段，通过自回归方式生成token，直到完成。
-
首次token延迟（TTFT）：
LLM服务系统响应用户请求时，生成第一个token所需的时间。
-
每个输出token的时间（TPOT）：
LLM服务系统响应用户请求时，生成后续token所需的平均时间。
在深入分析之前，需要回顾一下LLM服务请求的流程。
下图展示了这个过程：
请求进入LLM推理引擎，系统首先处理用户输入生成的第一个token（预填充），然后通过自回归生成后续token（解码）。
一个请求通常包括一个预填充步骤和多个解码步骤，直到生成完成。
传统LLM服务系统中请求的处理过程
LLM服务系统通常将预填充和解码一起批处理，使用迭代调度或连续批处理技术，使GPU能尽量大批量处理，从而提高吞吐量（每秒token数），vLLM和TensorRT-LLM等系统都广泛采用这一方法。
然而，预填充和解码在计算上有非常不同的特点。
预填充非常依赖计算，意味着即使是一个小批量的预填充，或者仅仅是一个足够长的预填充，也会迅速饱和GPU计算资源。
另一方面，解码需要更大的批量来达到计算瓶颈，且更容易受到GPU内存带宽限制的影响。
不过，预填充和解码在计算上差异很大：预填充计算密集型，容易迅速饱和GPU；而解码则需要更大批量才能达到计算瓶颈，同时也更受GPU内存带宽的限制。
由于它们的计算模式和SLO目标差异巨大，将这两者一起处理并不有利于优化有效吞吐量，原因有二：
