AWS 发布多节点 Ray LLM Deep Learning Containers，在 EKS 上用两个 GPU 节点跑 prefill/decode 分离推理
来源AWS Machine Learning查看原文
速览
- AWS 把多节点推理的依赖栈打包进 Ray LLM DLC，用户只需写 YAML 配置
- 示例用两个 g6.8xlarge 分别承担 prefill 和 decode，实现 PD 分离
- KV cache 跨节点传输走 NIXL + EFA，必须显式指定 LIBFABRIC 后端
- EFA 不能跨可用区，因此 GPU 节点组被固定在单一 AZ
- 容器暴露 OpenAI 兼容 API，可直接用标准 chat completions 请求调用
- 模型权重加载因共享内存缓存从约 145 秒降到约 2 秒
- 适用场景包括 RAG、文档摘要和 agentic 应用
- 后续可扩展 decode 副本、用张量/流水线并行跑更大模型
AWS 发布面向多节点部署的 Ray LLM Deep Learning Containers（DLC），并在官方博客中给出完整示例：在 Amazon EKS 上把一个大语言模型拆到两个 GPU 节点上运行，一个节点负责 prefill 阶段，另一个负责 decode 阶段，对外只暴露一个 OpenAI 兼容端点。该容器内置 vLLM 作为推理引擎、Ray Serve 作为服务层、NIXL 负责节点间 KV cache 传输，并集成 EFA（libfabric 与 aws-ofi-nccl）做高带宽节点间通信。整个服务应用由一段 YAML 描述，通过 build_pd_openai_app 把 prefill 配置和 decode 配置连起来，不需要写 handler 类、模型打包器或自定义镜像。示例使用 Qwen/Qwen3.5-9B 模型，集群为一个 CPU 系统节点（m7i.xlarge）加两个 GPU 工作节点（g6.8xlarge），GPU 节点组因 EFA 不能跨可用区而固定在单一 AZ。AWS 称在该配置下，Qwen3.5-9B 的模型权重加载在重启时从约 145 秒降到约 2 秒。
关键事实
- AWS 发布多节点 Ray LLM Deep Learning Containers，支持在 Amazon EKS 上跨两个 GPU 节点部署单个 LLM
- 示例采用 prefill/decode 分离架构：一个 GPU 节点跑 prefill，另一个跑 decode，共用一个 OpenAI 兼容端点
- 容器内置 vLLM 推理引擎、Ray Serve LLM 服务层、NIXL KV cache 传输库和 EFA 栈（libfabric、aws-ofi-nccl）
- 服务应用通过 build_pd_openai_app 构建，只需一段 YAML，无需 handler 类、模型打包器或自定义镜像
- 示例模型为 Qwen/Qwen3.5-9B，max_model_len 设为 4096，dtype 为 bfloat16，gpu_memory_utilization 为 0.90，enforce_eager 为 true
- 集群配置为 1 个 CPU 系统节点 m7i.xlarge 加 2 个 GPU 工作节点 g6.8xlarge，GPU 节点组固定在单一可用区
本站视角
对在 AWS 上自建推理服务的团队来说，这次发布的实际价值在于把「多节点 PD 分离」从一项需要自己拼装 CUDA、vLLM、Ray Serve、NIXL、EFA 的工程活，压缩成一段 YAML 加几个部署脚本。受影响的首先是国内做出海业务、用 EKS 跑开源模型的团队，以及做 RAG、文档摘要、Agent 类应用、对首 token 延迟和长 prompt 阻塞敏感的产品方——PD 分离正是为「长 prompt 拖慢正在进行的生成」这个问题设计的。其次是平台和基础设施团队，他们过去要花大量时间处理 GPU 栈版本漂移，DLC 把 CUDA 运行时、框架和服务层的兼容性在发布前统一验证，能省掉这部分非差异化工作。 我们的判断是：这是实质性的工程封装，而非营销包装。判断依据是它解决的是真实痛点（依赖链自建、EFA 配置容易出错），而且给出了可复现的量化结果——Qwen3.5-9B 权重加载从约 145 秒降到约 2 秒，这来自共享内存卷加页缓存的配置，属于可验证的工程细节。但需要观察的是：AWS 只给出了加载时间这一个数字，没有给出吞吐、首 token 延迟、端到端 QPS 等更能说明 PD 分离收益的指标，也没有与单节点基线做对比。也就是说，博客证明了「能跑起来、配置不复杂」，但没有证明「PD 分离在这套硬件上一定比单节点更快」。 另一个值得注意的点是文中那句提醒：NIXL 在无法使用 libfabric 时会静默回退到 TCP 速度的传输，且不报错。这意味着如果用户漏配 kv_connector_extra_config 的 LIBFABRIC 后端，系统看起来一切正常，但跨节点 KV cache 传输性能会大幅下降，PD 分离的收益可能被完全吃掉。对准备上手的团队来说，这是最需要先验证的一环，博客也给出了 grep 日志确认后端的方法。 最后，这套方案对非 AWS 用户没有直接可移植性：EFA、g6.8xlarge、EKS、ECR 都是 AWS 专有组件，NIXL 的 libfabric 后端也依赖 EFA。它更像是 AWS 用来降低自家云上多节点推理门槛、同时绑定用户到 EKS 与 EFA 生态的一步。是否跟进，取决于你的推理负载是否真的受 prefill 阻塞困扰，以及是否已经或计划把推理放在 AWS 上。
背景与影响
LLM 推理分为两个阶段：prefill 并行处理整个输入 prompt 并构建 KV cache，是计算密集型；decode 逐 token 生成响应并读取、扩展该 cache，受内存带宽限制。两者共用一块 GPU 时会争抢资源，突发且计算密集的 prefill 会干扰稳定且对延迟敏感的 decode。PD 分离把两个阶段放到不同节点，各自独立扩展，代价是 prefill 构建的 KV cache 必须传给 decode 节点，传输速度必须足够快才不至于抵消收益，因此节点间互连是关键。AWS 此前已推出 Ray Serve DLC，用于在单 GPU 节点上把模型放到 HTTP 端点后面；此次的 Ray LLM DLC 把同样的思路扩展到多节点推理。多节点 Ray Serve 的常见用途包括：跑单卡放不下的基础模型或开放权重模型、需要超过单副本的吞吐、以及把推理两个阶段分开以提升性能。此前这些工作都需要用户自行搭建依赖链、挑选兼容库并排查版本漂移问题。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。