# AWS EFA v2 上的分离式大模型推理验证框架：从 NCCL 到 SGLang PD 的端到端实践

> 一套面向生产环境的基础设施验证方案，涵盖从底层 RDMA 网络测试到 SGLang Prefill-Decode 分离部署的完整链路，为在 AWS EKS 上部署高性能 LLM 推理服务提供可复现的基准测试方法

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-04-29T06:40:20.000Z
- 最近活动: 2026-04-29T06:49:11.696Z
- 热度: 158.8
- 关键词: EFA, RDMA, 分离式推理, SGLang, Mooncake, NCCL, AWS, EKS, KV Cache, Prefill-Decode, UCCL-EP, LLM推理优化
- 页面链接: https://www.zingnex.cn/forum/thread/aws-efa-v2-nccl-sglang-pd
- Canonical: https://www.zingnex.cn/forum/thread/aws-efa-v2-nccl-sglang-pd
- Markdown 来源: ingested_event

---

# AWS EFA v2 上的分离式大模型推理验证框架：从 NCCL 到 SGLang PD 的端到端实践\n\n随着大语言模型规模持续增长，传统的单节点推理部署模式面临显存瓶颈和吞吐量限制。分离式推理（Disaggregated Inference）架构通过将 Prefill 阶段（计算密集型）与 Decode 阶段（内存带宽密集型）分布在不同节点上执行，成为提升推理效率的重要方向。然而，这种架构对底层网络基础设施提出了极高要求——节点间需要低延迟、高吞吐的 KV Cache 传输能力。\n\n本文介绍一套完整的端到端验证框架，专门针对 AWS EKS 环境配合 EFA v2（Elastic Fabric Adapter）RDMA 网络，验证从底层网络性能到上层推理服务的全链路可行性。该框架由 KevinZhao 开源发布，为计划在 AWS 上部署生产级分离式 LLM 推理服务的团队提供可复现的测试方法和性能基准。\n\n## 分离式推理的技术背景与挑战\n\n现代 LLM 推理通常分为两个计算阶段。Prefill 阶段需要处理完整的输入序列，计算量与序列长度的平方成正比，属于计算密集型任务。Decode 阶段则逐个生成 token，受限于内存带宽而非计算能力。传统部署将两个阶段放在同一 GPU 上，导致资源利用不均衡——Prefill 时计算单元满载而内存空闲，Decode 时则相反。\n\n分离式架构将两个阶段解耦到独立节点，通过高速网络传输中间状态（KV Cache）。这种设计允许分别为两个阶段优化硬件配置：Prefill 节点可使用高算力配置，Decode 节点则侧重内存带宽。但要实现这一架构，必须解决两个核心挑战：节点间 KV Cache 传输的延迟必须足够低，且带宽必须足够高，否则网络通信将成为新的瓶颈。\n\nAWS 的 EFA v2 提供了一种基于 RDMA 的高性能网络方案，单节点可配置多达 32 个 EFA NIC，理论带宽远超传统 TCP/IP 网络。然而，从底层硬件到上层应用存在多层软件栈，每一层都可能引入性能损耗，因此需要系统性的验证方法。\n\n## 四层递进式验证架构\n\n该验证框架采用分阶段递进设计，从底层网络到上层应用逐步验证，每层都有明确的测试目标和通过标准。这种结构化方法帮助团队快速定位性能瓶颈所在层级。\n\n### 第一阶段：NCCL 基础网络性能测试\n\n验证工作的起点是确认 EFA 网络的基础性能。使用 NCCL（NVIDIA Collective Communications Library）测试 all-reduce 和 all-to-all 操作的带宽表现。测试配置采用两台 p5.48xlarge 实例（各配备 8 块 H100 GPU 和 32 个 EFA NIC）。\n\n实测结果显示 all-reduce 操作达到 476.91 GB/s 的总线带宽（测试数据量 8GB），超过 320 GB/s 的目标阈值。这一结果验证了 EFA v2 作为 RDMA 基础设施的基本可用性，为后续测试奠定基础。测试通过 MPI Operator 在 Kubernetes 上编排，使用自定义 Docker 镜像集成 CUDA 12.6、EFA 1.47 和 NCCL 2.23。\n\n### 第二阶段：UCCL-EP 低延迟通信验证\n\n在确认基础网络能力后，第二阶段验证 UCCL-EP（Unified Collective Communication Library - Expert Parallel）的低延迟 dispatch 和 combine 操作。这是专家并行（MoE）模型的关键通信模式，也是分离式推理中 KV Cache 传输的底层依赖。\n\n测试运行 16 个 rank，全部通过上游的 test_low_latency.py 正确性验证。性能方面，dispatch 和 combine 操作达到约 7 GB/s 每 rank 的吞吐。虽然这一数字距离理论峰值仍有优化空间，但已满足初步功能验证要求。该阶段同样以 MPIJob 形式运行在 EKS 上，使用专门构建的 UCCL-EP + DeepEP 容器镜像。\n\n### 第三阶段：Mooncake KV 传输引擎测试\n\n第三阶段进入实际的 KV Cache 传输验证，使用 Mooncake 项目的 Transfer Engine 和 NIXL（NVIDIA Inference Xfer Library）。Mooncake 是专为分离式推理设计的分布式传输引擎，支持高效的 KV Cache 跨节点迁移。\n\n当前该阶段仅完成冒烟测试，DRAM 到 DRAM 的写入吞吐测得 19.31 GB/s，距离 150 GB/s 的目标存在差距。这一结果提示需要进一步调优传输参数或检查 EFA 配置。尽管如此，基础功能通路已验证可行，为后续深度优化提供了起点。\n\n### 第四阶段：SGLang 端到端推理验证\n\n最终阶段整合所有组件，运行 SGLang 的 Prefill-Decode 分离部署（PD 分离）。配置为 1 个 Prefill 节点对 1 个 Decode 节点（1P:1D），通过 Mooncake 在 EFA 上传输 KV Cache。\n\n测试关注三个关键指标：首 token 生成时间（TTFT）、单 token 生成时间（TPOT）和整体吞吐（OTPS）。初步结果显示 TPOT 降至单节点基线的 0.53 倍，表明确实获得了预期的 Decode 加速效果。但 TTFT 升高至基线的 7.7 倍，说明 Prefill 阶段的跨节点开销或请求调度策略需要优化。测试在无限请求率（request-rate=inf）模式下进行，作者建议后续进行速率受限的重新测试以获得更准确的性能评估。\n\n## 基础设施与部署要点\n\n该验证框架完全基于 Kubernetes 和基础设施即代码理念构建。核心依赖包括：\n\n- **EKS 集群**：版本 1.35+，配置 p5.48xlarge GPU 节点组\n- **NVIDIA GPU Operator**：v24.9.2，提供设备插件和 CDI 支持\n- **MPI Operator**：v0.6.0，用于编排 NCCL 和 UCCL-EP 测试\n- **LeaderWorkerSet (LWS)**：v0.7.0，支持 SGLang PD 分离部署的领导者-工作者模式\n- **辅助基础设施**：包括 ECR 镜像仓库、S3 存储、SSM 会话管理\n\n项目提供五个专用容器镜像，分别对应各阶段测试需求：基础 CUDA+EFA 环境、NCCL 测试、UCCL-EP、Mooncake+NIXL、以及 SGLang+Mooncake 集成环境。镜像构建建议在专门的 EC2 实例（m7i.4xlarge 或更高）上执行，避免本地网络瓶颈。\n\n## 运行手册与最佳实践\n\n项目根目录的 RUNBOOK.md 记录了真实测试执行的完整日志，包括遇到的每个失败和修复方法。这种透明的问题记录对新用户极具价值，可以帮助避开已知的配置陷阱。\n\n典型的工作流程从环境配置开始：复制 .env.example 并填入 AWS 账户、区域、实例 ID 等参数。然后按顺序构建五个 Docker 镜像，创建 Kubernetes 命名空间和服务账号，最后逐阶段执行测试。每个阶段目录包含独立的 README.md，详细说明 kubectl apply 的具体命令。\n\n对于计划基于该框架进行生产验证的团队，建议关注以下几点：首先确保 EFA 驱动和 OFI（OpenFabrics Interfaces）层正确配置；其次监控各阶段测试的带宽利用率，识别潜在的网络瓶颈；最后根据实际模型大小调整 KV Cache 传输的 buffer 配置。\n\n## 项目价值与适用场景\n\n这套验证框架的最大价值在于提供了**可复现、分阶段**的测试方法。对于考虑在 AWS 上部署分离式 LLM 推理的团队，它降低了技术验证的门槛，避免了从零开始搭建测试环境的重复劳动。\n\n适用场景包括：评估 EFA v2 对特定模型工作负载的适用性、验证 SGLang PD 分离架构的性能收益、建立 NCCL/UCCL-EP/Mooncake 各层软件栈的基线性能指标，以及作为 CI/CD 流水线中的回归测试套件。\n\n需要注意的是，该框架专注于" plumbing（管道）"而非" application（应用）"层——它不提供针对特定模型的优化建议，而是确保底层基础设施能够支撑分离式架构的运行。团队仍需根据实际业务需求进行模型特定的调优。\n\n## 总结与展望\n\n分离式 LLM 推理代表了推理架构演进的重要方向，而高性能 RDMA 网络是其落地的关键支撑。efa-validation 项目通过四层递进测试，为 AWS EFA v2 上的分离式推理部署提供了系统性的验证方法。\n\n当前项目状态显示 NCCL 和 UCCL-EP 阶段已通过验证，Mooncake 传输和 SGLang 端到端测试完成初步冒烟测试但仍有优化空间。这一状态反映了分离式推理技术栈的成熟度现状——底层网络基础设施已就绪，上层应用框架仍在快速迭代中。\n\n对于关注 LLM 推理基础设施的工程师和架构师，该项目提供了宝贵的实践参考。随着 Mooncake 和 SGLang 的持续更新，以及 EFA 驱动和 UCCL-EP 的性能优化，分离式架构的生产就绪度将进一步提升。