Ray LLM容器：EKS跨GPU节点部署大模型实战

大模型推理部署正从单卡走向多节点集群，而工程复杂度的陡增往往让团队望而却步。Amazon EKS 结合 Ray LLM Deep Learning Containers 提供了一条更务实的路径：把一个 LLM 跨两个 GPU 节点部署，prefill 与 decode 分离，最终对外只暴露一个兼容 OpenAI 的接口。

为什么需要跨节点推理

当模型参数量超过单节点显存容量，或者吞吐需求远超单节点处理能力时，横向扩展几乎是唯一选择。传统做法是自己拼装推理栈——调度、通信、批处理、健康检查逐层搭建，工期长且容易在故障恢复环节踩坑。

Amazon EKS 上的 Ray LLM Deep Learning Containers 改变了这个分工。容器中已经预置完整推理栈，团队的工作重心从"组装"转向"配置"。据官方描述，这套方案的核心场景就是：用预先构建好的容器，把单一大语言模型分散到两个 GPU 节点上运行。

Prefill 与 Decode 分离的架构逻辑

LLM 推理在计算特征上天然分成两个阶段。Prefill 阶段处理完整输入提示，计算密集型，需要在 prompt 长度上快速消化；Decode 阶段逐 token 生成输出，内存带宽密集型，对延迟极其敏感。两者混在同一节点时，长 prompt 的 prefill 会挤占 decode 资源，导致首 token 延迟和输出流畅度互相拖累。

该架构的解法是把两类工作负载部署到不同节点上，各司其职。Prefill 节点负责"读题"，Decode 节点负责"答题"，中间通过高速网络交换 KV cache 等中间状态。这样每个节点都可以针对自身负载类型做资源配比与并行策略调优，而不是在一套配置下勉强兼顾两种模式。

对运维的实际影响

分离架构的代价是需要处理节点间通信与状态传递。好在容器层已经把这部分封装好了，Kubernetes 侧更多是资源配置、调度约束与网络规划的配置工作。对熟悉 K8s 的团队而言，上手曲线主要落在理解 prefill/decode 的资源画像，而不是重写通信代码。

KV cache 是大模型自回归推理中的一个核心技术概念。在 Transformer 解码过程中，每生成一个新 token，模型都需要对之前所有 token 重新计算注意力。如果每次都从头计算，代价会随着序列增长呈平方级膨胀。KV cache 的做法是把每一层注意力计算中已经得到的 Key 和 Value 矩阵缓存下来，后续生成时直接复用，避免重复计算。这样一来，decode 阶段的单步计算量从与序列长度的平方相关降为线性相关。

KV cache 的代价是显存占用：每个并发请求、每条序列都维护一份独立的缓存，且占用量随上下文长度线性增长。在多节点分离架构中，prefill 节点完成初始计算后，需要把生成的 KV cache 通过高速网络传给 decode 节点，这也是节点间通信成为关键瓶颈的原因。KV cache 的传输效率直接决定了分离架构能否在实际负载下兑现性能收益。

一个 OpenAI 兼容端点意味着什么

对外只暴露一个兼容 OpenAI 的接口，是这套方案在实际工程中价值最高的一点。上层应用、agent 框架、评测工具不需要感知后端是单节点还是多节点，也不需要区分 prefill 和 decode 分别跑在哪里。

这意味着迁移成本被压到最低：原本调用 OpenAI 接口的代码，改一个 base_url 即可指向自建集群。对于需要在私有环境部署、又不想重构客户端逻辑的团队，这个设计省下的工程量相当可观。

同时也带来一个值得权衡的点——兼容层是否覆盖了目标应用所需的全部参数与响应字段。建议在正式迁移前跑一轮接口行为对齐测试，尤其是流式输出、停止条件、token 计费字段这类容易被忽略的细节。

OpenAI 兼容接口通常指的是遵循 OpenAI Chat Completions API 规范的一组 REST 端点，包括 /v1/chat/completions、/v1/completions、/v1/embeddings 等路径，以及对应的请求体字段（如 messages、temperature、max_tokens）和响应结构（如 choices、usage、finish_reason）。大量开源推理框架和商业推理服务都会主动实现这套规范，以降低用户的接入成本。

兼容不等于完全一致。不同实现在流式输出的 chunk 切分方式、finish_reason 的取值时机、对 stop 序列的处理细节，以及 usage 中 token 计数口径上都可能存在偏差。对于依赖精确 token 计费或严格解析停止条件的应用，这些差异会直接导致行为不一致。因此文中所说的接口行为对齐测试，重点往往不在基本对话能否跑通，而是这些边缘行为的一致性。

何时该选这套方案

判断标准并不复杂：如果你的模型放不进单节点显存，或者单节点吞吐已经触顶，同时团队已经在用 EKS，那么这套预置容器能显著缩短从零到可用的时间。

反过来看，如果模型单卡就能装下、流量规模也不大，引入多节点只会徒增调度和运维开销。跨节点推理的收益来自规模，而不是来自架构本身的先进性。

另一个需要评估的维度是 GPU 机型的一致性。prefill 与 decode 对算力和带宽的偏好不同，混用异构机型虽然可行，但会让容量规划变得复杂。初期建议尽量保持节点规格可控，把调优变量降到最低。

EKS（Amazon Elastic Kubernetes Service） 是 AWS 提供的托管 Kubernetes 服务，控制平面由 AWS 维护，用户只需管理节点组或使用 Fargate 等无服务器算力。对于多节点 GPU 推理场景，EKS 的价值在于它已经具备成熟的调度、节点池管理、弹性伸缩和网络插件生态。

选择这套方案的一个隐含前提是团队已经具备 EKS 运维能力。如果团队此前没有 Kubernetes 经验，引入 EKS 本身的学习与治理成本可能超过多节点推理带来的收益。文中反复强调该方案把工程经验固化成容器镜像，其省时省力的前提正是调度、网络、存储这些底层能力已经由 EKS 承担。离开这个前提，容器封装带来的便利会被集群本身的运维复杂度抵消。因此判断是否适用时，需要把 EKS 熟练度作为与模型规模同等重要的前置条件来评估。

落地时的几个关键配置点

镜像版本与 Ray 版本需要匹配，预置容器虽然省去了组装工作，但版本约束依然存在，升级时要同步验证推理栈各组件。

网络带宽往往是被低估的瓶颈。KV cache 在节点间传输的量随并发和序列长度增长，如果节点间链路成为限制因素，加节点也换不来吞吐提升。

可观测性建议在部署阶段就纳入考量。多节点场景下，一次请求横跨多个组件的延迟拆解比单节点困难得多，提前埋点比事后排查省力得多。

这套方案本质上是把多节点推理的工程经验固化成容器镜像，让团队用配置换取时间。对于需要在自有基础设施上跑大模型的团队，这是一条值得评估的务实路线。