来自博客的关于预填充-解码分离 (PD Disaggregation) 的一些直觉见解

• PD 并不会加速预填充 (Prefill)，实际上可能还会损害首字延迟 (TTFT)
• PD 的真正优势在于负载下平稳、稳定的每个输出令牌延迟 (TPOT)
• TPOT 的节省会随着输出序列长度而累积

最优的 P:D 比例尤其依赖于输入长度、输出长度和缓存命中率。有意义的优化是可能的，但调优可能很敏感。

基准测试使用 @raydistributed + @vllm_project 在 AMD MI325X 上执行。

使用 Ray + vLLM 在 AMD MI325X 上实现预填充-解码分离，最高可节省 67% 成本 | Anyscale

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings 在大语言模型 (LLM) 服务中，优化目标表面上很简单：给定一组延迟服务等级协议 (SLA) 目标——首字延迟 (TTFT)、每个输出令牌延迟 (TPOT)、端到端延迟 (E2E)——最大化你可以维持的每秒查询数 (QPS)，也称为“有效吞吐率 (Goodput)”。

突破有效吞吐率上限最强大的杠杆之一就是预填充-解码分离 (PD Disaggregation) (https://haoailab.com/blogs/distserve-retro/)。在这篇文章中，我们将介绍如何使用 Ray Serve LLM 在 AMD 上编排 PD 分离推理工作负载，实现高达 2.7 倍的更好有效吞吐率。

使用 PD 分离的关键优势在于，不是将两个阶段都运行在同一个 GPU 上（在那里它们会竞争计算、内存带宽和调度预算），而是将 PD 分离到专门的硬件上。预填充 GPU 处理提示处理。解码 GPU 处理令牌生成。通过消除相互干扰，每个阶段都能更接近其理论吞吐量运行，整个系统在相同的 SLA 约束下能服务更多请求。

然而，这并非免费午餐——PD 增加了操作复杂性：KV 缓存必须跨节点传输，并且必须针对每个工作负载调整预填充与解码的比例。我们展示的结果表明，在相同的 GPU 预算和 SLA 下，基于 Ray + vLLM 的预填充-解码分离可以比聚合服务 (Aggregated serving) 多服务 1.3 倍到 2.3 倍 的 QPS（具体取决于工作负载，最高可降低 67% 的计算成本），同时也展示了其无效的情况——这样你就可以为你的工作负载做出正确的决策。

PD 与聚合服务对比 - 在 SLA 下的最大可持续 QPS（相同 GPU 数量） 我们在 5 种工作负载场景（模型、输入序列长度/输出序列长度和命中率变化）下，比较了 PD 与聚合服务的最大可持续 QPS。在 AMD MI325X 上使用 Qwen3-235B 和 DeepSeek-V3 进行了验证。

PD 与聚合服务对比 - 在 SLA 下的最大可持续 QPS（相同 GPU 数量） 我们在不同的工作负载上测试了两个大型 MoE 模型——改变输入/输出长度、KV 缓存命中率和 P:D 比例——以找出 PD 分离在哪些情况下节省成本，在哪些情况下无效。这篇文章将介绍 PD 分离为何有帮助的核心直觉、支持 PD 分离的 AMD 软件栈（用于 KV 传输的 RIXL），以及如何使用 Ray Serve 进行设置。如需托管解决方案，您可以使用 Anyscale (https://www.anyscale.com/)，为您的工作负载带来类似的成本节省。

核心直觉——PD 为何有效（以及何时无效）

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings#core-intuition-%E2%80%93-why-pd-works-(and-when-it-doesn’t)

本节涵盖你需要用来理解任何工作负载下 PD 分离的四个关键见解。每个见解都包含我们实验中的数据，以及关于 PD 分离何时失效的明确指导。这些结果与硬件设置无关，应作为关于预填充-解码分离的一般指南和结论。

见解 1：PD 并不会使预填充更快——实际上可能损害 TTFT

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings#insight-1:-pd-does-not-make-prefill-faster-%E2%80%93-it-can-actually-hurt-ttft

关于 PD 最常见的误解是它能加速一切。事实并非如此。在交互式响应性最重要的指标——首字延迟 (TTFT) 上，在相同的 GPU 规模下，PD 始终比聚合服务慢。

为什么聚合服务的 TTFT 已经很好。 在 vLLM 的调度器中，没有单独的“预填充阶段”或“解码阶段”。调度器在将新请求从等待队列接纳之前，会运行当前所有活跃的请求——包括预填充和解码。对于所有仅解码器模型，默认启用了分块预填充 (Chunked prefill)，即长提示被分割成由 max_num_batched_tokens（默认值为 8192）决定大小的块。每个块作为一次调度迭代运行。通常，解码步骤每次迭代消耗的预算微乎其微。例如，一个包含 128 个并发解码请求的批次每次迭代最多使用 8192 个令牌预算中的 128 个，因此每次迭代的大部分预算都可用于预填充令牌。在这种情况下，当新请求被添加到批次中时，剩余的 8064 个令牌预算就会被分配给新请求的预填充。这意味着该迭代的 TPOT 会膨胀，但 TTFT 的膨胀不大。因此，TTFT 主要由预填充前向传播（注意力 + MoE 路由）的原始计算时间主导，而不是与解码的竞争。

聚合服务 - vLLM 调度器时间线 在聚合服务中，解码令牌每次迭代仅消耗调度器令牌预算的约 1.6%——TTFT 主要由预填充计算主导，而非解码竞争。

聚合服务 - vLLM 调度器时间线 PD 的变化。 PD 在预填充完成后增加了一个 KV 缓存传输步骤。预填充节点通过网络 (RDMA/RoCE) 将 KV 数据发送到解码节点。此传输具有固有开销，具体取决于模型架构、KV 缓存大小和网络条件。在高负载和 KV 缓存压力下，预填充节点也可能排队，从而在传输开销之上增加排队延迟。

PD 服务 - KV 传输增加 TTFT 开销 在 PD 服务中，预填充和解码节点之间的 KV 缓存传输步骤增加了开销，从而导致 TTFT 膨胀。

PD 服务 - KV 传输增加 TTFT 开销 净效果。 在相同的 GPU 规模下，聚合服务始终能实现与 PD 相等或更低的 TTFT。

Qwen3-235B on MI325X & DeepSeek-V3 on MI325X (30% 命中率) 图 3：TTFT vs QPS——聚合服务的 TTFT 保持平稳，而 PD 的 TTFT 在负载下上升。

Qwen3-235B on MI325X & DeepSeek-V3 on MI325X (30% 命中率) 如果你的 SLA 纯粹以首字延迟 (TTFT) 衡量（例如，交互式搜索、自动补全），那么聚合服务将始终优于 PD。如图 3 所示，DeepSeek-V3 上 PD 的 TTFT 基线约为 330ms（由于 KV 传输开销），而聚合服务在所有 QPS 水平下都保持在约 260ms：

• 在 TTFT < 300ms 的 SLA 下，PD 无法服务任何流量（基线 TTFT 超过目标），而聚合服务可持续 7.0+ QPS。
• 在 TTFT < 500ms 的 SLA 下，聚合服务可持续 7.0+ QPS，而 PD 仅为 5.0 QPS——聚合服务至少优胜 1.4 倍。

聚合服务在此的结构优势：没有 KV 传输步骤，并且预填充负载自然分布在多个副本之间。如果你需要同时快速的 TTFT 和快速的 TPOT，请考虑接受稍微放宽的 TTFT 目标——即使小幅放宽也能通过 PD 解锁 TPOT 和 E2E 的重大改进。

结论： 如果你的 SLA 严格受限于 TTFT，那么聚合服务是更简单、更好的选择。

见解 2：PD 真正的优势在于负载下平稳、稳定的 TPOT

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings#insight-2:-pd’s-real-win-is-flat,-stable-tpot-under-load

这是 PD 价值的核心机制。在聚合服务中，预填充和解码共享相同的 GPU。每次包含预填充令牌的调度迭代都比纯解码迭代的计算量更大。随着 QPS 上升，更多的预填充工作堆积起来，解码令牌的等待时间就会变长。TPOT 随着 QPS 的增加而线性（或更糟）地恶化，因为每个新的预填充请求都会从所有正在进行的解码步骤中窃取计算资源。

PD 完全消除了这一点。解码在专用的 GPU 上运行，这些 GPU 永远不会看到预填充令牌。无论其他节点上发生多少预填充工作，TPOT 都几乎保持平稳。

Qwen3-235B 和 DeepSeek-V3 图 4：TPOT vs QPS——聚合服务的 TPOT 急剧上升，而 PD 保持平稳。在目标 SLA 下，PD 在两个模型上都比聚合服务维持显著更高的 QPS。

Qwen3-235B 和 DeepSeek-V3

见解 3：TPOT 的节省会随着输出序列长度而累积

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings#insight-3:-tpot-savings-compound-over-output-sequence-length

PD 的每令牌 TPOT 优势在孤立情况下看起来不大（5-10ms）。但它会在每个输出令牌上倍增：

总节省 = TPOT 增量 × 输出长度。

这种累积效应就是为什么 PD 在 E2E 延迟上获胜，尽管在 TTFT 上失利。

PD E2E 优势随输出长度增长 每令牌 5.1ms 的 TPOT 优势会累积：PD 的 E2E 优势从 OSL=140 时的 12% 增长到 OSL=4K 时的 17%（Qwen3-235B, 24 GPU, QPS=4）。

PD E2E 优势随输出长度增长 PD 何时失效：短输出。 对于短输出工作负载（分类、提取、简短问答），节省的成本不足以证明复杂性的合理性。在这些情况下，你应该使用聚合服务。

见解 4：最优的 P:D 比例取决于你的工作负载

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings#insight-4:-the-optimal-p:d-ratio-depends-on-your-workload

这是对于从业者最实用的见解。P:D 比例决定了 GPU 资源如何在预填充和解码之间分配。弄错比例可能会使 PD 比聚合服务更差。

不同工作负载的关键发现：

工作负载

缓存命中率

瓶颈

最优比例

长输入，短输出 (ISL=16K, OSL=1K)

0%

预填充吞吐量

2P:1D

长输入，长输出 (ISL=16K, OSL=4K)

0%

解码吞吐量

1P:3D

多轮交互，高缓存重用

80%

解码吞吐量

1P:2D

多轮交互，中等缓存重用

30–60%

混合

1P:1D 到 1P:2D

经验法则： 将额外的 GPU 分配给瓶颈所在的地方。高缓存命中率使预填充变得便宜——分配更多资源给解码。低缓存命中率且输入长时——分配更多资源给预填充。

最常见的 PD 陷阱：使用与工作负载不匹配的比例部署。这可能使 PD 在所有指标上都严格劣于聚合服务。

错误的 P:D 比例可能比聚合服务更差 错误的 P:D 比例可能比聚合服务差得多。始终对你的特定工作负载进行基准测试。从 1:1 开始，然后根据 TTFT 或 TPOT 哪个先达到 SLA 来调整。

错误的 P:D 比例可能比聚合服务更差

AMD 的特殊之处——RIXL 和 KV 传输栈

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings#what’s-special-about-amd-%E2%80%93-rixl-and-the-kv-transfer-stack

PD 分离要求预填充和解码节点之间进行高带宽的 KV 缓存传输。在 NVIDIA 硬件上，这由 NIXL（NVIDIA Interconnect eXchange Library）通过 NVLink、InfiniBand 或 EFA 处理。在 AMD 上，我们使用 RIXL（ROCm Interconnect eXchange Library）——一个可直接替代 NIXL 的库，它使用基于 RDMA/RoCE InfiniBand 的 UCX 传输。

关键点是，RIXL 在 vLLM 中公开了相同的 NixlConnector 接口。在服务层无需任何代码更改。如果你的 vLLM 配置使用了 kv_connector: NixlConnector，它可以在 NVIDIA（通过 NIXL）和 AMD（通过 RIXL）上工作。

容器和软件栈

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings#container-and-software-stack

我们的容器镜像基于 Dockerfile.v0.18.dev 构建，包含以下组件：

组件

版本 / 来源

基础镜像

anyscale/ray:nightly-py312-cu128（对于 OSS 版本使用 rayproject/ray:nightly-py312-cu128）

ROCm

7.0（rocm/dev-ubuntu-22.04:7.0-complete for build 阶段）

vLLM

0.18.0，通过 wheels.vllm.ai/rocm/0.18.0/rocm700 预构建 wheels

RIXL

从源码构建（ROCm/RIXL 提交 f33a5599）

UCX

从源码构建（ROCm/ucx 提交 da3fac2a），使用 --with-rocm、--with-verbs、--enable-mt

ROCm Triton

从源码构建（ROCm/triton 提交 f9e5bf54）

Python

3.12

VLLM_ROCM_USE_AITER=1                        # AMD AI Tensor Engine Runtime
VLLM_ROCM_USE_AITER_MOE=1                    # 优化的 MoE 内核
VLLM_ROCM_QUICK_REDUCE_QUANTIZATION=INT4     # 使用 INT4 量化的快速 all-reduce
VLLM_ROCM_QUICK_REDUCE_CAST_BF16_TO_FP16=1   # 为快速 reduce 进行 BF16 到 FP16 的类型转换

一个关键的操作说明

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings#a-critical-operational-note

网络传输质量至关重要。 在正确配置 UCX/RDMA 的情况下，跨节点 KV 传输性能与节点内相当。如果回退到 TCP，吞吐量会灾难性地下降——我们在测试中观察到高达 19 倍的性能下降。在基准测试 PD 之前，务必验证 RDMA 传输层。

我们部署中的 UCX 传输配置：

UCX_TLS=rc,sm,self,rocm_copy,rocm_ipc
UCX_NET_DEVICES=mlx5_0:1,mlx5_1:1,mlx5_2:1,mlx5_3:1,mlx5_4:1,mlx5_5:1,mlx5_6:1,mlx5_7:1

该配置将 8 个 Mellanox ConnectX 接口用于 RoCE 结构，使用可靠连接 (RC) 传输，并启用共享内存和 ROCm GPU 直接路径。测试硬件：AMD MI325X，配备 288GB HBM3e，每节点 8 GPU。

如何复现

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings#how-to-reproduce

复现这些结果所需的一切都整合在一个仓库中：Dockerfile、服务配置和基准测试脚本。这些说明假设你在 AMD MI325X 节点上运行着一个 Ray 集群——可以通过 Anyscale (https://docs.anyscale.com/get-started)、KubeRay (https://docs.ray.io/en/latest/cluster/kubernetes/getting-started.html) 或裸机方式实现。所有制品均可在此处获取。

结论

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings#conclusion

基于 Ray + vLLM 的 PD 分离，在相同的 GPU 预算和 SLA 下，可提供 1.3 – 2.3 倍的 QPS——在 AMD MI325X 上最高可实现 67% 的成本降低。总结主要见解：

• PD 获胜的条件：你的 SLA 对 TPOT 或 E2E 延迟敏感，并且输出足够长，使得每令牌的节省能够累积。
• 聚合服务获胜的条件：TTFT 是约束瓶颈，输出较短，或者缓存命中率足够高从而消除了预填充-解码竞争。
• P:D 比例很重要。 给定工作负载下，最优值可能因情况而异。

开始使用

来源：https://www.anyscale.com/blog/ray-vllm-prefill-decode-disaggregation-amd-mi325x-67-percent-savings#get-started

• 复现我们的结果。 克隆仓库，部署配置，并针对你的工作负载运行基准测试 CLI。
• 需要托管解决方案： Anyscale (https://authkit.anyscale.com/) 为你提供托管的 Ray 服务。你可以在 k8s 上部署 Anyscale，之后就不必再管理 Ray 集群了。
• 与我们交流。 找到 PD 行为异常的工作负载？我们希望能听到你的反馈——欢迎通过 Ray 社区 或 Ray 的 Slack 联系我们。