SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference

Each language version is independently generated for its own context, not a direct translation.

这篇论文主要解决了一个大模型（LLM）服务中的**“怎么配人手”**的问题。

想象一下，你开了一家超级繁忙的**“智能餐厅”**（这就是大模型推理服务）。顾客（用户请求）进来点菜，餐厅需要完成两个主要步骤：

读菜单（Prefill/预填充）：厨师快速阅读顾客点的菜，理解需求，准备好食材。这步很快，但需要脑力（计算能力）。
炒菜上菜（Decode/解码）：厨师根据需求，一道一道地把菜炒出来端给顾客。这步比较慢，因为要等锅热、等菜熟，主要受限于传菜速度（显存带宽）。

1. 以前的问题：混在一起干

传统的做法是，让同一批厨师既负责“读菜单”又负责“炒菜”。

坏处：当厨师在专心读菜单时，炒菜就停了；当他在炒菜时，读菜单就停了。这就好比让一个服务员既当收银员又当厨师，忙起来容易乱套，导致顾客等菜的时间（TTFT）和上菜的速度（TPOT）很难同时优化。

2. 现在的方案：分工合作（P/D 分离）

为了解决这个问题，大家开始搞**“分工”**：

A 组厨师（Prefill 节点）：专门负责读菜单、理解需求。他们只负责“想”，不负责“炒”。
B 组厨师（Decode 节点）：专门负责炒菜、上菜。他们只负责“做”。
传送带：A 组把理解好的“菜单草稿”（KV Cache）通过传送带传给 B 组，B 组接着炒。

分工虽然好，但带来了新问题：到底该招多少 A 组厨师，招多少 B 组厨师？

如果 A 组人太少，顾客点菜后没人读菜单，大家排队等，体验差。
如果 B 组人太少，菜炒得太慢，顾客等得发火。
如果招多了，人闲着没事干，老板亏钱。

以前，老板（运维人员）只能靠**“拍脑袋”或者“试错”**来定人数，要么人不够，要么人太多。

3. 这篇论文做了什么？（核心魔法）

这篇论文提出了一套**“科学配餐法”，不用拍脑袋，而是用“数学公式 + 实地测试”**来算出最完美的人数比例。

第一步：算总账（理论模型）

作者先列了一个公式，就像算菜量一样：

如果老板要求每分钟要出 500 道菜（总吞吐量）。
顾客平均点 10 个菜（输入长度）和 2 个菜（输出长度）。
那么，理论上需要多少“读菜单”的人和“炒菜”的人，是有数学关系的。
核心公式：A 组人数 / B 组人数 = (读菜单速度 × 炒菜速度) 的某种比例。
- 简单说：如果顾客点的菜很长（输入长），就需要更多 A 组；如果顾客要的菜很多（输出长），就需要更多 B 组。

第二步：给“读菜单”组算速度（排队论）

这里有个难点：A 组厨师读菜单的速度，不是固定的。

如果顾客来得太急（排队人多），厨师就得慢下来，保证每个顾客都能很快拿到第一道菜（TTFT，首字延迟）。
作者用了**“排队论”（M/M/1 模型）**来模拟这个场景。
- 比喻：就像银行柜台。如果要求客户等待时间不能超过 2 分钟，那么柜台就不能开得太快（否则后面排队太长），也不能太慢。
- 通过数学推导，作者算出了在满足"2 秒内出第一道菜”的要求下，A 组厨师实际能处理多少订单，而不是他们理论上最快能处理多少。

第三步：给“炒菜”组算速度（实测）

对于 B 组厨师，作者发现：

一次炒一盘菜（小批量）和一次炒十盘菜（大批量），速度不一样。
炒得越多，效率越高，但每盘菜出来的时间（TPOT）会变慢。
方法：作者去厨房实地测试（Benchmark），画出曲线图。
- 比如：老板要求每道菜必须在 20 毫秒内端上来。
- 通过测试发现，只有当一次只炒 5 盘菜时，才能满足这个速度。
- 于是算出：在满足速度要求下，B 组厨师实际能端出多少菜。

4. 最终结果：精准配人

把上面算出来的“实际读菜单速度”和“实际炒菜速度”代入第一步的公式，就能精准算出：

需要 3 个 A 组厨师（Prefill 节点）
需要 4 个 B 组厨师（Decode 节点）

实验证明：
按照这个"3 对 4"的比例去配置服务器，结果非常完美：

既满足了老板要求的每分钟 500 道菜的产量。
又保证了顾客等菜时间不超过 2 秒，上菜速度不超过 20 毫秒。
而且没有浪费人力（不像以前可能配了 3 对 3，导致炒菜太慢；或者 3 对 5，导致读菜单的人闲着）。

总结

这篇论文就像给大模型餐厅的老板提供了一本**《科学排班手册》**。
它不再让你猜“该买多少显卡”，而是告诉你：

先看看你的顾客喜欢点什么（输入输出长度）。
看看你的老板要求多快（SLO 指标）。
用这套公式算一算，“读菜单”和“炒菜”的显卡比例应该是多少。

这样既能省钱（不浪费显卡），又能讨好顾客（速度快、体验好）。

Each language version is independently generated for its own context, not a direct translation.

这是一份关于论文《SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference》（面向 SLO 的预填充 - 解码解耦 LLM 推理计算资源分配）的详细技术总结。

1. 研究背景与问题 (Problem)

背景：
大型语言模型（LLM）的推理服务需求激增。为了优化性能并满足服务等级目标（SLO），业界广泛采用了**预填充 - 解码解耦（Prefill-Decode Disaggregation, P/D Disaggregation）**架构。该架构将计算密集型的“预填充（Prefill）”阶段和显存带宽受限的“解码（Decode）”阶段分离到不同的硬件实例上，通过传输 KV Cache 进行协同，从而独立优化两个阶段的性能（如 TTFT 和 TPOT）。

核心痛点：
尽管 P/D 架构已被 vLLM、SGLang 等框架支持，但在实际部署中，缺乏一种成熟的方法来确定最优的 P/D 硬件资源配比（即预填充实例数与解码实例数的比例及具体数量）。

如果资源分配不当，会导致资源利用率低下（成本浪费）或无法满足 SLO（用户体验差）。
现有的工具（如 NVIDIA AIConfigurator）主要关注单个实例的部署参数（如 TP/DP/EP 设置），或仅基于搜索策略，缺乏在给定总吞吐量、SLO 约束（TTFT/TPOT）及请求特征（输入/输出长度）下，精确计算 P/D 资源数量的系统性方法论。

2. 方法论 (Methodology)

本文提出了一种**结合理论建模与实证基准测试（Hybrid Approach）**的混合方法，旨在根据用户指定的总吞吐量、SLO 约束和请求特征，精确计算所需的 P/D 实例数量。

2.1 理论资源分配模型

首先，建立基于总吞吐量需求的 P/D 实例数量计算模型：

总吞吐量定义： $TP_{total} = \frac{N_{req} \times (L_{in} + L_{out})}{T_{total}}$ ，其中 $N_{req}$ 为请求数， $L_{in/out}$ 为平均输入/输出长度。
时间平衡：在流水线推理中，总耗时由预填充和解码中较慢的一方决定。为避免资源闲置，需使两阶段计算时间相等 ( $T_{prefill} = T_{decode}$ )。
实例数量公式：
- 预填充实例数： $N_{prefill} = \frac{TP_{total} \times L_{in}}{(L_{in} + L_{out}) \times TP_{prefill}}$
- 解码实例数： $N_{decode} = \frac{TP_{total} \times L_{out}}{(L_{in} + L_{out}) \times TP_{decode}}$
- P/D 比例： $R_{P/D} = \frac{L_{in} \times TP_{decode}}{L_{out} \times TP_{prefill}}$
- 注：公式中的关键变量是单个预填充和解码实例的有效吞吐量（ $TP_{prefill}$ 和 $TP_{decode}$ ），这需要在 SLO 约束下确定。

2.2 预填充阶段：基于 M/M/1 排队理论的 TTFT 约束建模

为了在满足 Time-To-First-Token (TTFT) 约束的前提下获取有效的预填充吞吐量：

建模：将预填充实例的请求排队和计算过程建模为 M/M/1 排队系统。
推导：
- 服务率 $\mu = \frac{\text{最大预填充吞吐量}}{L_{in}}$ 。
- 系统利用率 $\rho = \frac{\lambda}{\mu}$ （ $\lambda$ 为请求到达率）。
- 利用排队论公式 $T_s = \frac{1}{\mu - \lambda} = TTFT - T_{overhead}$ （ $T_{overhead}$ 为传输开销）。
- 最终公式：推导出满足目标 TTFT 的实际预填充吞吐量：
  $TP_{prefill} = \hat{TP}_{prefill} - \frac{L_{in}}{TTFT - T_{overhead}}$
- 洞察：目标 TTFT 越低，实际可达到的吞吐量越低；最大吞吐量越高，在相同 TTFT 下的系统利用率越高。

2.3 解码阶段：基于实证测量的 TPOT 约束建模

为了在满足 Time-Per-Output-Token (TPOT) 约束的前提下获取有效的解码吞吐量：

观察：解码吞吐量与 TPOT 均与解码批次大小（Batch Size）正相关。批次越大，吞吐量越高，但 TPOT 也会增加。
方法：
1. 通过基准测试（Benchmark）绘制不同 Batch Size 下的 TPOT 曲线和解码吞吐量曲线。
2. 找到满足目标 TPOT 的最大 Batch Size。
3. 根据该 Batch Size 和对应的 TPOT 计算有效解码吞吐量： $TP_{decode} = \frac{\text{Batch Size}}{TPOT}$ 。

3. 关键贡献 (Key Contributions)

理论模型建立：提出了一个计算 P/D 实例数量的理论框架，综合考虑了总吞吐量、SLO 要求、请求长度及阶段吞吐量。
预填充吞吐量推导：创新性地利用 M/M/1 排队理论，建立了从“最大基准吞吐量”到“满足 TTFT 约束的有效吞吐量”的数学映射关系。
解码吞吐量获取：提出了一种基于实证测量的方法，通过寻找满足 TPOT 约束的最优 Batch Size 来确定有效解码吞吐量。
验证与实用性：在真实场景（DeepSeek-V3.1 和 Qwen3 模型，H20/H200 硬件）中验证了该方法，证明了其能准确预测资源分配，实现成本效率与 SLO 合规的平衡。

4. 实验结果 (Results)

实验设置：
- 模型：DeepSeek-V3.1-Terminus, Qwen3-235B。
- 硬件：NVIDIA H200 (8 卡) 和 H20 (4 卡)。
- 目标 SLO：TTFT < 2s, TPOT < 20ms。
- 负载：平均输入 6144 tokens，输出 512 tokens，目标总吞吐量 5M TPM。
计算过程：
- 测得最大预填充吞吐量为 28300 tokens/s，扣除 KV 传输开销后，满足 2s TTFT 的有效吞吐量为 ~25000 tokens/s。
- 通过基准测试曲线，找到满足 20ms TPOT 的 Batch Size，得出有效解码吞吐量 ~1700 tokens/s。
- 计算得出 P:D 比例为 0.82:1，最终推荐部署方案为 3 个预填充实例 + 4 个解码实例 (3P4D)。
验证对比：
- 3P4D 方案：在约 4.8 M TPM 时同时满足 TTFT 和 TPOT 的 SLO 阈值，接近 5M TPM 的目标。
- 3P3D 方案（对比）：受限于 TPOT，仅在约 3.6 M TPM 时满足 SLO。
- 效率提升：3P4D 方案的单节点平均吞吐量为 0.69 M TPM，显著高于 3P3D 的 0.6 M TPM，证明了资源分配算法的高效性。
理论验证：M/M/1 模型预测的 TTFT 趋势与实测结果高度一致（除 KV 传输时间外），证明了排队论模型在 P/D 场景下的适用性。

5. 意义与价值 (Significance)

填补行业空白：解决了 P/D 解耦架构中“如何精确计算资源配比”这一关键运营难题，为云厂商和 LLM 服务提供商提供了可落地的资源规划工具。
成本与性能平衡：避免了过度配置（Over-provisioning）造成的成本浪费，同时也防止了资源不足导致的 SLO 违约。
方法论通用性：提出的“理论建模 + 实证基准”的混合思路具有普适性，未来可扩展至多模态模型（EPD 分离）或与其他配置优化工具（如 AIConfigurator）结合，实现更智能的自动化部署。
指导实践：明确指出了在 SLO 约束下，预填充和解码阶段的资源需求并非固定不变，而是动态依赖于请求长度、SLO 严格程度及系统最大性能，为动态调度提供了理论依据。