@kazukifujii: 樱花互联网的Michishita-san的文章全面总结了LLM推理，强烈推荐。它涵…

樱花网络的道下先生的文章全面总结了LLM推理，非常值得推荐。

文章中包含易于理解的图表，解释了Chunked-Prefill背后的动机，并提及了PD分离。 （从连续批处理到Chunked-Prefill的过渡解释得清晰易懂，这点很棒。）

PD分离（将Prefill和Decode分开）应该是一个相当热门的话题，但我在日本国内很少听到相关讨论，所以我认为这篇详尽解释的文章非常有价值。

如果需要具体的分离实例，可以看看DistServe作者的演讲（https://youtu.be/tIPDwUepXcA?si=4YcNpkGnDrxC-jfq…），我觉得单凭这篇文章就足以掌握概念。

目标文章：

TL;DR

将预填充（prefill）和解码（decode）阶段分配到不同的GPU池中，可以提高有效吞吐量（goodput）——即满足延迟服务级别目标（SLO）的吞吐量——而不是追求原始的总吞吐量最大化。

引言

在GPU Mode Session #58（视频作者@kazukifujii）中，加州大学圣地亚哥分校How AI实验室的二年级博士生Junda Chen介绍了大语言模型（LLM）的分离推理。他认为，有效吞吐量是评估LLM服务系统比单纯吞吐量更好的指标，因为它考虑了每个请求的延迟约束。Chen的工作影响了工业框架，如黄仁勋在GTC 2025主题演讲中介绍的NVIDIA Dynamo。

为什么有效吞吐量比吞吐量更重要

服务级别目标（SLO）

不同的应用（聊天机器人、搜索引擎、代码代理）对两个关键延迟施加了不同的SLO：

• TTFT（首次令牌时间）：例如，聊天为1-2秒；代码代理为100-200毫秒。
• TPOT（每个输出令牌时间）：连续生成令牌之间的时间。

提供商会监控这些SLO以保持服务健康。历史上，每个请求的成本通过原始吞吐量（请求数/秒或令牌数/秒）来衡量。但原始吞吐量忽略了用户是否实际体验到可接受的延迟。

有效吞吐量概念

有效吞吐量是同时满足TTFT和TPOT SLO的请求数量除以时间。例如：

• 每秒处理10个请求的系统，若要求TTFT ≤ 200毫秒、TPOT ≤ 50毫秒，有效吞吐量可能降至每秒3个有效请求。
• 高原始吞吐量并不保证高有效吞吐量；过载的系统交付了许多“坏”请求，浪费GPU计算并损害用户体验。

Chen展示了GTC 2025（GB200 NVL72 with FP4）的一张图表，显示了总吞吐量与每用户令牌率之间的权衡。选择正确的操作点（例如，200 token/s/user）可最大化有效吞吐量，而非原始吞吐量。

预填充与解码：不同的工作负载特性

预填充（计算密集型）

• 并行处理整个输入提示（系统提示+用户输入）。
• 计算KV缓存并生成第一个输出令牌。
• 即使单个预填充请求也可能饱和多个GPU（例如，1K令牌的提示可饱和100个GPU）。

解码（内存密集型）

• 逐个生成令牌（自回归）。
• 主要由将模型参数从内存移动到SRAM主导。
• 仅在非常大的批处理规模下才达到计算饱和（通常会导致内存不足错误）。

问题：混合批处理损害解码延迟

大多数系统使用分块预填充（将预填充和解码一起批处理）。Chen使用A100上的Llama 13B模型演示：

• 一个预填充（128令牌）：约14毫秒。
• 一个解码：约7.5毫秒。
• 当一起批处理时：解码延迟跃升至约14毫秒（增加了1.8倍）。
• 对于更长的提示（1K+令牌），干扰会增长到12倍的解码减速。

这是因为新的预填充请求在计算上很重，迫使解码步骤等待，从而有效延迟了每个正在进行的解码请求。“好”的吞吐量急剧下降。

分离推理作为解决方案

将预填充和解码分离到专门的GPU池中，可以避免这种干扰。预填充GPU处理计算密集的提示处理；解码GPU处理内存密集的令牌生成。这样可以独立调整每个池的大小和批处理方式，从而提高有效吞吐量。

NVIDIA Dynamo（在GTC 2025上宣布）为这种分离提供了框架。Chen指出，业界已迅速采用这种方法；现在大多数主要公司都有自己分离的服务功能。

结论

总吞吐量可能具有误导性：最大化每秒令牌数的系统仍可能产生糟糕的用户体验。有效吞吐量——满足SLO的吞吐量——是更好的成本指标。正如最新研究和行业采用所证明的那样，分离预填充和解码是一种实用方法，可以用更少的GPU实现高有效吞吐量。

来源：GPU Mode Session #58 – Disaggregated Inference (https://www.youtube.com/watch?si=4YcNpkGnDrxC-jfq&v=tIPDwUepXcA&feature=youtu.be)