多节点 Disaggregated 推理：在 AMD Instinct MI300X GPU 上运行 DeepSeek R1 671B

引言

自回归 LLM 推理包含两个截然不同的阶段：prefill 阶段并行处理整个输入 prompt 以构建 KV cache， 以及 decode 阶段利用缓存的 key 和 value 逐个生成输出 token。 这两个阶段具有截然不同的执行特性 — prefill 在单次长时间运行的步骤中一次性处理大量 token， 而 decode 则以高频率运行许多短迭代 — 然而在传统服务系统中，它们共享相同的 GPU 资源， 导致相互干扰，降低了吞吐量和延迟表现。

Prefill-decode disaggregation（也称为 disaggregated serving）通过将每个阶段分配到专用的 GPU 节点池来解决这一问题，使 prefill 和 decode 不再在相同的 GPU 上竞争资源。 该概念最早由 DistServe（Zhong 等人，OSDI 2024）正式提出，此后得到了广泛采用， 但要在生产环境中充分发挥其潜力，需要高度优化的全栈软件解决方案 — 从内核级计算效率 到集群级调度和 KV cache 传输。

在本报告中，我们使用 MoAI Inference Framework — Moreh 针对 AMD GPU 上高性能 disaggregated serving 优化的生产级推理框架 — 在运行 DeepSeek R1 671B 的 5 节点 AMD Instinct MI300X 集群上测量 prefill-decode disaggregation 的效果。我们首先展示 disaggregated serving 相对于 colocated 基线的优势，然后通过比较两种配置来研究最佳 prefill 与 decode 节点比例如何随请求模式变化：2P3D（2 个 Prefill + 3 个 Decode 节点） 和 1P4D（1 个 Prefill + 4 个 Decode 节点）。

背景：为什么要分离 Prefill 和 Decode？

干扰问题

当 prefill 和 decode 在相同的 GPU 上 colocated 运行时，它们会以多种方式相互干扰：

• 延迟尖峰。 Prefill 在单次可能长时间运行的 GPU 步骤中一次性处理大量 token。 当长上下文的 prefill 请求到达时，它会长时间占用 GPU，阻塞所有共享同一设备的正在进行的 decode 迭代。这会导致 P99 inter-token latency (ITL) 大幅膨胀 — 有时高达数个数量级 — 破坏用户期望的流畅流式体验。
• 调度冲突。 Prefill 和 decode 具有相反的调度偏好：prefill 希望快速处理 新请求以最小化 time-to-first-token (TTFT)，而 decode 需要频繁且不间断的迭代来维持低 inter-token latency。单个服务实例必须在两者之间不断仲裁，任何妥协都会降低至少一个指标。
• 耦合扩展。 运维人员无法独立增加 prefill 或 decode 容量； 每个新节点都必须同时服务两个阶段，导致瓶颈较小的阶段被过度配置。

Disaggregated Serving 的工作原理

Disaggregated serving 将集群分为独立的 prefill 节点和 decode 节点。每个池持有完整的 模型权重（不存在跨池的模型分片），但只处理其指定的阶段。当 prefill 节点完成输入处理后， 它通过高带宽互联（如 RDMA）将生成的 KV cache 传输到 decode 节点， 后者随即在无干扰的情况下继续 token 生成。

这种分离带来了几个关键优势。即使在同构集群（每个节点拥有相同的 GPU）上， disaggregation 也能提供：

• 消除 prefill-decode 干扰。 Decode 节点以稳定的速率生成 token， 不受传入 prefill 工作的干扰，从而实现显著更低且更可预测的 inter-token latency。
• 独立扩展。 运维人员可以调整 prefill 与 decode 的节点比例以匹配工作负载的 输入/输出长度分布，避免过度配置。
• 按阶段优化。 每个池可以独立应用不同的并行化策略、调度策略和批处理配置， 针对其阶段进行调优，而不会影响另一个阶段。

在异构集群中，disaggregation 解锁了额外的优化维度：由于 prefill 是计算密集型而 decode 是 内存带宽密集型，运维人员可以将计算密集型 GPU 分配给 prefill 池，将带宽优化的 GPU 分配给 decode 池，使硬件特性与每个阶段的瓶颈相匹配。本报告聚焦于同构 AMD MI300X 集群， 将干扰消除、扩展和按阶段优化的收益与任何硬件组合效应隔离开来。

实验设置

测试环境

所有实验均在 5 节点 GPU 集群上进行。每个节点为 Gigabyte G593-ZX1-AAX1 服务器， 配备双路 AMD EPYC 9474F CPU（48 核，3.6 GHz）、2,304 GB 主内存和 8 块 AMD Instinct MI300X GPU（每块 192 GB HBM3e）。节点间通过 InfiniBand HDR 互联。

配置方案

我们在同一 5 节点集群上评估了三种配置：

• Colocated（基线）： 所有 5 个节点同时处理 prefill 和 decode。 负载均衡在各节点间分配请求。
• Disaggregated 2P3D： 2 个节点专用于 prefill，3 个节点专用于 decode。 相对于 1P4D，为 prefill 分配了更多容量。
• Disaggregated 1P4D： 1 个节点专用于 prefill，4 个节点专用于 decode。 相对于 2P3D，为 decode 分配了更多容量。

基准测试场景

所有基准测试均使用 vllm bench serve 运行。 我们在不同并发级别下测试了四种 ISL/OSL（Input Sequence Length / Output Sequence Length） 组合。这些组合旨在对服务管线的不同部分施加压力，而非模拟特定应用：

• 1K/1K： 输入和输出长度均衡
• 1K/8K： 短输入，长输出（decode 密集型）
• 8K/1K： 长输入，短输出（prefill 密集型）
• 8K/8K： 长输入和长输出

对于每个场景，流量负载由两个参数控制：N_REQs（请求总数）和 REQ_RATE（请求到达速率，单位 req/s）。 在所有场景中，N_REQs 设为并发级别的 2 倍。短输出场景的 REQ_RATE 设置较高 （1K/1K 为 3–6 req/s，8K/1K 为 2–4 req/s），长输出场景的 REQ_RATE 设置较低 （1K/8K 和 8K/8K 为 2 req/s），这反映了长生成请求占用 GPU 资源时间更长的事实。 一旦指定 REQ_RATE，它 — 与 N_REQs 一起 — 比名义并发级别更精确地决定了 实际流量模式。

结果：Disaggregated 与 Colocated Serving 对比

我们首先比较 disaggregated 2P3D 配置（2 个 prefill + 3 个 decode 节点）与 colocated 基线 （所有 5 个节点同时处理两个阶段）。由于集群 40% 的计算资源保留给 prefill，2P3D 作为我们在 所有四个 ISL/OSL 场景中的主要 disaggregation 配置。

端到端延迟

在所有测试配置中，Disaggregated 2P3D 在中位端到端延迟方面实现了 1.35 倍的几何平均改善。

最大增益出现在 8K/1K（prefill 密集型）场景中，在 CON=160 时达到 1.84 倍。 这是预期的结果：有了专用的 prefill 节点，长输入序列不再阻塞 decode 操作， prefill 节点可以更高效地批处理和处理这些序列。

总吞吐量

Disaggregated 2P3D 在总吞吐量（每秒 token 数）方面实现了 1.20 倍的几何平均改善。

延迟与吞吐量对比

以下散点图展示了每个 ISL/OSL 场景的延迟-吞吐量权衡。越靠近左上方（更低延迟、更高吞吐量） 越好。每个点代表不同的并发级别。

成本效率（Token/Dollar）

由于 disaggregated serving 使用的 GPU 总数与 colocated 基线相同，吞吐量的提升直接转化为 单位 token 成本的节省。2P3D 配置相对于 colocated 基线实现了 107.57% 的 token/dollar 效率几何平均值，这意味着运维人员可以用相同的基础设施成本多服务 7.57% 的 token。

结果：Prefill 与 Decode 比例的影响

在确立 disaggregated serving 优于 colocated serving 之后，我们进一步探讨：集群的节点应如何在 prefill 和 decode 之间分配？为回答这个问题，我们在 decode 密集型 1K/8K 场景中比较 2P3D 配置 （2 个 prefill + 3 个 decode）与 1P4D（1 个 prefill + 4 个 decode），因为在该场景中将一个 节点从 prefill 转移到 decode 的影响最为明显。

端到端延迟：2P3D vs. 1P4D (1K/8K)

总吞吐量：2P3D vs. 1P4D (1K/8K)

在这一 decode 密集型工作负载上，1P4D 始终优于 2P3D。额外的 decode 节点提供了更大的聚合 decode 容量，产生了更低的端到端延迟和更高的吞吐量 — 尤其是在高并发情况下， decode 成为瓶颈时。在 CON=480 时，1P4D 达到 6,082.84 TPS，而 2P3D 为 5,668.40 TPS。

成本效率对比

在 token/dollar 效率（几何平均值）方面，1P4D 达到 111.07%，而 2P3D 相对于 colocated 基线达到 107.57%。在 decode 密集型工作负载上，额外的 decode 节点直接转化为更好的成本效率。

总结：如何选择比例？

2P3D 在 prefill 密集型 8K/1K 工作负载上实现了 1.80 倍的几何平均延迟改善， 但在 decode 密集型 1K/8K 工作负载上其优势缩小至 1.08 倍。在该场景下， 1P4D 以 1.13 倍 E2EL 改善和 111% token/dollar 效率领先， 这得益于额外的 decode 节点。 在生产环境中，真实工作负载很少是均匀的 — 短查询、长上下文 RAG 和推理请求 同时到达，最佳比例可能随着全天流量模式的变化而变化。

这使得手动配置 prefill/decode 比例本质上是脆弱的：为高峰时段流量调优的比例在非高峰时段可能是 次优的，反之亦然。挑战不仅在于选择正确的比例，更在于持续地适应调整。

延迟稳定性：P99 Inter-Token Latency

Disaggregated serving 最具影响力的优势之一是尾部延迟的显著改善。在 colocated 设置中， 长 prefill 请求会间歇性地阻塞 decode 步骤，导致 P99 inter-token latency (ITL) 飙升至 数秒。这直接降低了流式应用中的用户体验。

通过 disaggregated serving，prefill 和 decode 永远不会竞争相同的 GPU 资源。 因此，P99 ITL 大幅下降：

这意味着通过 disaggregated serving，即使在混合工作负载条件下，用户也能体验到一致、流畅的 token 流式传输 — 这是生产级对话和推理应用的关键需求。

结论

Prefill-decode disaggregation 为大规模 MoE 模型推理提供了相对于 colocated serving 的 明确且可衡量的增益。在运行 DeepSeek R1 671B 的 5 节点 AMD MI300X 集群上：

• 两种 disaggregated 配置在所有测试场景中均优于 colocated 基线，端到端延迟改善最高达 1.84 倍，P99 inter-token latency 降低 12–51 倍。
• 2P3D（更多 prefill 节点）在 prefill 密集型工作负载上表现优异， 在 8K/1K 上实现 1.80 倍几何平均 E2EL 改善。
• 1P4D（更多 decode 节点）在 decode 密集型工作负载上提供更好的成本效率， 在 1K/8K 上达到 111% token/dollar。

然而，最佳 prefill 与 decode 比例并非静态的 — 它取决于工作负载的输入/输出长度分布 和并发度，而这两者在生产环境中都会随时间变化。选择错误的比例会导致 prefill 或 decode 容量利用不足，侵蚀 disaggregation 所带来的收益。

MoAI Inference Framework 通过自动化 disaggregated serving 的配置来解决这一问题。 MoAI 无需运维人员手动选择和维护固定的 prefill/decode 比例，而是根据观察到的工作负载特性 动态调整分配 — 同时结合 expert parallelism、路由和其他分布式推理优化 — 使运维人员无需手动调优即可在 AMD Instinct GPU 集群上充分实现 disaggregation 的全部收益。