LLM 推理系统容量评估
LLM 推理领域有很多具体的优化技术，比如模型量化、投机解码、通算重叠、前缀缓存、算子优化、请求/专家负载均衡等等，这些技术每一个展开来讲都有很多的内容可说。但是如果你需要从 0 开始为自己的 LLM 构建具有一定规模的推理集群，并且对推理成本和线上服务质量负责，只对单个推理技术了如指掌是不够的，你需要一套思考框架来评估整个推理系统的容量和吞吐。
LLM 在线推理这套系统，本质上还是一个排队模型，所有的设计都是在这个大框架的前提下进行的。现实中，请求按照一定速率到达推理系统，先进行 prefill，再进行自回归的 decode，其中用户感知到的最重要的 SLO 显然就是 TTFT 和 tps。而作为推理服务的提供者，推理系统的构建者，我们思考问题的主线始终是：怎么用更少的 GPU，在满足 TTFT 和 tps 的前提下，serving 线上用户的所有请求。
推理系统建模
让我们先构造这样一个模型：假设目前你的产品 DAU 是 $N$，平均每个用户每天发送 $x$ 个请求，且峰值 rps 是日均 rps 的 $K$ 倍，那么你的推理系统必须能够承受 $\frac{KNx}{86400}$ 的 rps 并同时满足目标 TTFT 和单用户 tps（或 ITL）。
进一步考虑每个请求本身。我们假设大部分请求的输入输出长度方差并不大（这在很多业务场景下是成立的），因此我们可以用平均输入长度 $L{\text{in}}$ 和平均输出长度 $L{\text{out}}$ 表征一个请求，且输入中未命中 prefix cache 而真正需要计算 kvcache 的长度为 $L_{\text{extend}}$。现在我们已经有了 rps，TTFT 和 tps，输入输出长度，可以开始着手估算我们推理系统的容量。
但要注意，峰值容量的粗估并不能确保线上服务 SLO，实际场景中由于请求到达间隔、请求长度、请求调度、组批方式等存在变化，我们需要在估计容量的基础上做进一步的冗余规划，实际目标利用率 $\rho_{\text{target}}$ 还需根据线上指标的反馈进行修正。
Prefill
prefill 作为 compute bound 的场景，其 throughput 在 $L{\text{extend}}$ 不特别小的情况下是容易达到上限的，所以组 batch 并不能提高 prefill 的吞吐。假设我们的推理系统中一个 prefill 实例的最大吞吐是 $T{\text{prefill}}$，则系统达到最大负载的稳态时，所有 prefill 实例的吞吐之和应该等于输入 token 到来的速率：
这是从吞吐考虑得到的一个实例数下限，但吞吐满足需求不代表 TTFT 不会超时。假设每个实例容纳的最大请求数为 $B{\text{prefill}}$，那么该实例中请求的最长耗时可以用 $B{\text{prefill}}\cdot\frac{L{\text{extend}}}{T{\text{prefill}}}$ 估计，因此每个实例自身还需要满足：
Decode
decode 有着不同的计算特点，每轮自回归的输入只有单个 token 导致它 bound 在 HBM 带宽。增大 batch size 可以提高 decode 整体的 throughput，但 M 维度的增加会让每次 forward 的耗时随之非线性增长，因此每个用户感知到的 tps 会下降。
一个 decode 实例的吞吐、batch size 和单个用户感知的 tps 之间满足：
根据 Little 定律，decode 系统中平均存在的请求数量：
则推理系统需要的 decode 实例数量为：
当然，$B{\text{decode}}$ 和 tps 之间存在某些因果关系，但这是更底层的技术细节，就目前来讲，我们已经知道减少 decode 实例数量的关键是在 tps 下降到底线之前得到 $T{\text{decode}}={B_{\text{decode}}\cdot\text{tps}}$ 的最大值。
为什么 PD 分离是主流选择
上面的分析中，我们默认分开了 prefill 和 decode 而没有讨论单实例部署，PD 分离也是一个相当主流的方案。那么 PD 分离和使用 chunked-prefill 和 continuous batch 的单实例部署有什么优势呢？要知道，后者也已经极大削弱了长请求 prefill 对 decode 的影响，而 PD 分离还会带来通信耗时、kvcache 管理等开销。
其实 PD 分离和 chunked prefill 是同一个问题——如何在数十毫秒的 decode 中插入数百毫秒至数秒的 prefill 而不让 tpot 和 ttft 超时——的两种解法。通过把一个几百毫秒的 prefill 拆分成跟一次 decode 耗时相近的 chunk，然后和 decode 一起 forward 确实能很大程度上解决这个问题，且在一个 batch 中同时进行 prefill 和 decode 也提高了硬件算力和带宽的利用率。但 pd 分离还能给我们带来以下几个 benefit：
- prefill 和 decode 的扩缩容灵活性：假设整个系统中 prefill 和 decode 的负载比例发生了较大变化，如果是 PD 分离则可以直接对 P、D 实例进行动态扩缩容，而混合部署的 chunk size 如果不能适应当前负载，导致 prefill 吞吐过低或 decode 被严重挤压带来 tpot 上升，就需要调整实例的超参。
- prefill 和 decode 部署 config 的独立性：prefill 和 decode 的算力带宽需求是不同的，采用不同的部署方式是很正常的选择，比如 DeepSeek 开源 DeepInfer 时就介绍他们的 prefill 使用了 8 卡 GPU 机器，而 decode 使用的是 64 卡的超节点。PD 分离让我们可以在 TP/EP/DP 切分方式、最大 batch size、通信配置（偏向吞吐还是延迟）、kvcache 空间配置等方面做更灵活的调整。
- 请求在实例间调度的自由性：PD 不分离场景下，假设一个请求在实例 A 上有较长的 prefix cache 命中，但实例 A 上 decode 的 batch size 已经很大，而实例 B 虽然未缓存该请求此前的 kvcache，此时的 decode 却比较空闲，那么 PD 不分离的话，是无法充分利用这两个实例各自的优势，来更好地 serving 目标请求的。
PD 分离是以 GPU 为单位来分配给 prefill 和 decode 各自的算力，chunked prefill 则是在同一张卡上通过 chunked size 和 decode batch 调整 prefill 和 decode 各自占有的算力。对于规模较大的推理集群来说，这两者通常都可以满足我们调整 pd 算力的需求。
如果推理集群的规模本身不足，比如仅有 4 张 GPU 的情况下，如果 prefill 本身只需要 5% 的资源来处理，分一张卡（25% 的资源）做 PD 分离就会带来浪费。而 PD 分离所具有的三个独特优势，并不是采用 PD 分离就能自动得到的，还需要我们建设配套的扩缩容机制、研究精细化的 PD 性能优化、设计合理的 router 和 kvcache 管理机制。
总结
本文讨论了如何用排队模型估计推理系统中 P 和 D 各自所需的容量，并探讨了 PD 分离模式真正的优势。需要注意的是，我们只从实例层面评估了 P 和 D 各自的容量，实际上无论是 P 实例还是 D 实例其内部的 GPU 数量和单个实例的吞吐都依然是我们的优化目标，这些将在后续文章中进行探讨。
有了这些认知，我们才能在心中设想一个完整的推理系统，才能对各个推理技术的端到端收益心里有数，进而为你的推理服务的性能与成本负责。