生活分享

AWS 推出多节点 Ray LLM 容器：大语言模型的“读提示”与“生成回答”可分给两台 GPU 节点处理

AWS 推出适用于多节点部署的 Ray LLM Deep Learning Container，并演示在 Amazon EKS 上用两个 GPU 节点分别负责读取提示（prefill）与生成回答（decode）。AWS 称自行搭建大模型服务的团队可直接使用这个由 AWS 维护并测试的容器，无需自己拼凑软件栈。

阅读时间约 5 分钟

AWS 推出多节点 Ray LLM 容器：大语言模型的“读提示”与“生成回答”可分给两台 GPU 节点处理
图片：Mokaair (Original editorial artwork)

发生了什么

AWS 在其博客文章中表示，随着适用于多节点部署的 Ray LLM Deep Learning Container（DLC）推出，DLC 的预构建做法已延伸到多节点推理。据 AWS 介绍，DLC 是预构建的 Docker 镜像，把框架、依赖包与 GPU 软件栈打包成经过测试并打过补丁的组合，拉取后即可使用。AWS 的文章演示了如何在 Amazon EKS（Amazon Elastic Kubernetes Service）上，把单个大语言模型部署到两个 GPU 节点，以独立的 prefill 与 decode 节点，置于同一个兼容 OpenAI 的端点之后；也就是说，用户可以用标准的聊天请求格式调用这个服务入口。

AWS 称 Ray LLM DLC 内含 vLLM 作为推理引擎、Ray Serve 的 HTTP 作为服务层、NIXL（NVIDIA Inference Transfer Library）用于节点间 KV 缓存传输，以及负责高带宽节点间通信的 EFA（Elastic Fabric Adapter）软件栈（libfabric 与 aws-ofi-nccl）。AWS 还称 DLC 的所有组件在每次发布前一并验证，因此 CUDA 运行环境、框架与服务层之间不会出现版本漂移，安全补丁则在构建时应用。

AWS 表示整个服务应用只是一段 YAML 配置文件，不需要 handler 类、模型打包工具或自定义镜像；辅助函数 build_pd_openai_app 接收 prefill 与 decode 配置，并在同一个兼容 OpenAI 的端点后串接 KV 缓存传输。

为什么要把 prefill 与 decode 分开

据 AWS 介绍，大语言模型的推理有两个阶段：Prefill 会并行处理整个输入提示并建立 key-value（KV）缓存；Decode 则一次生成一个 token（模型输出文本的单位），并读取和扩展该缓存。AWS 指出，把两个阶段分开，可避免计算量大的长提示拖慢进行中请求的 token 生成，并让两个阶段能够独立扩展。

AWS 文章对两个推理阶段的说明
项目PrefillDecode
工作内容并行处理整个输入提示并建立 KV 缓存一次生成一个 token，并读取和扩展该缓存
AWS 所述瓶颈受计算能力限制受内存带宽限制
示例中的节点一个 g6.8xlarge GPU 节点另一个 g6.8xlarge GPU 节点

AWS 表示取舍在于：prefill 建立的 KV 缓存必须交给 decode 节点，这个传输要足够快，才不会抵消好处，因此节点间的互连很重要。AWS 称此架构适合检索增强生成（RAG）、文档摘要与智能体类应用等工作负载。

示例架构与需要注意的地方

AWS 的示例架构使用一个 CPU 系统节点（m7i.xlarge）承载系统工作负载、KubeRay operator 与 Ray head pod，另有两个 GPU 工作节点（g6.8xlarge），一个负责 prefill，一个负责 decode。AWS 指出 GPU 节点组被固定在单一可用区（Availability Zone，简称 AZ），因为 EFA 无法跨 AZ。

AWS 的示例以 Qwen3.5-9B 模型为例，将 max_model_len 设为 4096；AWS 称在 g6.8xlarge 上采用文中的缓存配置后，模型权重加载时间在重启时由约 145 秒降到约 2 秒。

AWS 另说明，负责计算的 worker pod 以 privileged: true 的设置运行，因为 NIXL 会把 CUDA VRAM（GPU 显存）注册到 EFA 网卡，仅靠 IPC_LOCK 能力不够。

对普通读者的实际意义

对普通读者而言，这意味着需要自行搭建大模型服务的团队，有一个由 AWS 维护并测试的容器可用，不必自己拼凑与 GPU 和网络相关的软件栈。AWS 指出常见的多节点推理模式包括张量并行与流水线并行（把单个实例放不下的模型拆开）、数据并行（复制模型以提高吞吐量），以及 prefill/decode 解耦（把推理的两个阶段放到不同节点）。

AWS 列出的先决条件包括：已启用计费的 AWS 账户、足够运行两个 g6.8xlarge 实例的配额（至少 64 vCPU），以及 AWS CLI、kubectl、eksctl、helm 与 envsubst 等工具。AWS 的部署流程分四步：创建 EKS 集群（全新运行约 15–20 分钟）、添加 GPU 工作节点、安装 KubeRay operator、部署 RayService。为避免持续产生费用，AWS 建议按相反顺序拆除资源。

以上均为 AWS 自身的说明，性能与成本结果请以自己的环境为准。

常见问题

什么是 prefill/decode 解耦？

据 AWS 介绍，这是把处理输入提示的 prefill 阶段与逐个生成 token 的 decode 阶段放在不同节点，让两者互不干扰并可独立扩展。

这个容器是做什么用的？

AWS 称 Ray LLM DLC 内含 vLLM、Ray Serve 的 HTTP 服务层、NIXL 与 EFA 软件栈，用于通过兼容 OpenAI 的端点提供多节点模型推理。

需要写代码才能部署吗？

AWS 表示整个服务应用只是一段 YAML，不需要 handler 类、模型打包工具或自定义镜像，但仍需要配置 EKS 集群和相关工具。

这些性能数字有其他来源佐证吗？

本文内容均来自 AWS 自己的博客文章，属单一来源，应视为 AWS 的说法。

查看同分类最新消息

同主题延伸阅读

资料来源

生活分享