基于 Amazon EKS、EFA 与 DeepEP 的 MoE 强化学习大规模扩展与吞吐量优化
- 作者

- 姓名
- Nino
- 职业
- Senior Tech Editor
随着基于人类反馈的强化学习(RLHF)以及基于分组相对策略优化(GRPO)等技术在大语言模型(LLM)推理与对齐中的广泛应用,类似于 DeepSeek-R1、DeepSeek-V3 等混合专家模型(Mixture-of-Experts, MoE)已成为行业前沿的主流架构。然而,MoE 模型在分布式场景下的强化学习训练与策略生成(Rollout)阶段面临着严峻的网络通信瓶颈。由于 Token 会根据路由机制动态分发给不同的专家节点,导致跨节点间的 All-to-All 集合通信极其频繁。
通过构建结合 Amazon Elastic Kubernetes Service (Amazon EKS)、Elastic Fabric Adapter (EFA) 与 DeepSeek 开源的高性能通信库 DeepEP 的分布式架构,开发者可以有效消除节点间通信延迟,将 RL Rollout 阶段的总体吞吐量提升 40% 以上。
在自建大规模计算集群之前,许多技术团队也会利用 n1n.ai 这类统一 API 网关,针对 DeepSeek-V3、Claude 3.5 Sonnet 及 OpenAI o3-mini 等模型进行性能基准测试与成本评估。
MoE 强化学习中的网络通信瓶颈分析
与传统的密集型(Dense)模型不同,MoE 模型的每一层仅激活部分专家网络。在多节点分布式训练与推理场景(如采用包含 8 张 NVIDIA H100 GPU 的 AWS p5.48xlarge 实例)下,专家并行(Expert Parallelism, EP)会将不同的专家部署在不同的 GPU 甚至不同的物理节点上。
在强化学习的 GRPO 或 PPO 采样(Rollout)阶段,系统需要同时生成海量的 Candidate Response 并计算 Reward。这一过程涉及频繁的跨节点 Token 分发与聚合:
- 分发阶段(Dispatch):生成节点需将 Token 数据通过网络发送至对应专家所在的目标 GPU。
- 聚合阶段(Combine):专家计算完毕后,需将隐层表达(Hidden States)重新路由回原始 GPU 继续后续层计算。
在传统的 TCP/IP 协议栈或未经深化的通信库下,跨节点带宽限制会导致 GPU 长时间处于等待数据的 Idle 状态,极大地拉低了整个集群的利用率。
[ 跨节点 MoE Token 路由示意图 ]
+-----------------------+ +-----------------------+
| 节点 1 (GPU 0..7) | | 节点 2 (GPU 0..7) |
| - Token 生成节点 | | - 专家 5..8 |
| - 专家 1..4 | | |
+-----------+-----------+ +-----------+-----------+
| ^
|-------- 跨节点 All-to-All 通信 -------------|
(AWS EFA + DeepEP 内核)
核心架构组件:Amazon EKS、EFA 与 DeepEP
为解决这一瓶颈,该方案整合了三大关键技术栈:
- Amazon EKS (Kubernetes 容器编排):提供高弹性的分布式作业调度能力,精准管理 PyTorch Job 或 Ray / vLLM 采样节点的资源分配。
- AWS Elastic Fabric Adapter (EFA):AWS 专为高性能计算(HPC)与机器学习设计的网络接口,支持 OS Bypass(操作系统旁路,基于 SRD 协议),绕过 Linux 内核直接在 GPU 内存间进行低延迟、高吞吐的跨节点 RDMA 传输。
- DeepEP (DeepSeek 专家并行通信库):DeepSeek 开源的高性能 MoE 通信内核,针对 NVLink(节点内)与 EFA/InfiniBand(节点间)进行了深度定制,支持低精度通信(如 FP8/BF16)与重叠(Overlap)计算。
在搭建复杂的底层训练基础设施的同时,诸多研发团队通过 n1n.ai 统一接入外部托管 API,用于对比自建 MoE 模型与云端顶级模型的输出质量与延迟特性。
在 Amazon EKS 上配置 EFA 支持的完整步骤
要让 EKS Pods 能够直接调用 EFA 硬件网卡,需要正确配置 NodeGroup 与相关 Device Plugin。
1. 部署支持多 EFA 网卡的节点池
使用 Terraform 或 eksctl 部署 p5.48xlarge 节点池(该机型提供高达 3200 Gbps 的总网络带宽,挂载 32个 EFA 网卡)。
# eksctl 节点组配置文件示例
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: moe-rl-eks-cluster
region: us-east-1
managedNodeGroups:
- name: p5-efa-nodes
instanceType: p5.48xlarge
minSize: 4
maxSize: 16
desiredCapacity: 8
volumeSize: 500
privateNetworking: true
efa:
enabled: true
iam:
withAddonPolicies:
autoScaler: true
2. 安装 AWS EFA Kubernetes Device Plugin
在集群中部署 DaemonSet,使得 Kubernetes 能够识别 vpc.amazonaws.com/efa 硬件资源:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: aws-efa-k8s-device-plugin
namespace: kube-system
spec:
selector:
matchLabels:
name: aws-efa-k8s-device-plugin
template:
metadata:
labels:
name: aws-efa-k8s-device-plugin
spec:
hostNetwork: true
containers:
- image: 602401143452.dkr.ecr.us-east-1.amazonaws.com/aws-efa-k8s-device-plugin:v0.5.5
name: aws-efa-k8s-device-plugin
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
volumeMounts:
- name: device-plugin
mountPath: /var/lib/kubelet/device-plugins
volumes:
- name: device-plugin
hostPath:
path: /var/lib/kubelet/device-plugins
将 DeepEP 集成至 PyTorch / MoE 训练管线
DeepEP 替代了标准的 torch.distributed.all_to_all 操作,通过自定义 CUDA 内核实现了通信与计算的重叠(Overlap)。
以下示例展示了如何在代码中引入 DeepEP 进行高效的跨节点 Token 路由:
import torch
import torch.distributed as dist
# 引入编译了 EFA/RDMA 支持的 deep_ep 模块
import deep_ep
class OptimizedMoERouter(torch.nn.Module):
def __init__(self, num_experts: int, hidden_dim: int, top_k: int):
super().__init__()
self.num_experts = num_experts
self.hidden_dim = hidden_dim
self.top_k = top_k
# 初始化 DeepEP 缓冲区,自动管理 NVLink 和 EFA RDMA 传输
self.ep_buffer = deep_ep.Buffer(
group=dist.group.WORLD,
num_nvl_bytes=1024 * 1024 * 128, # 节点内 NVLink 缓冲区
num_rdma_bytes=1024 * 1024 * 512 # 节点间 EFA RDMA 缓冲区
)
def forward(self, hidden_states: torch.Tensor, router_logits: torch.Tensor):
# 计算路由权重与目标专家 ID
weights, selected_experts = torch.topk(
torch.softmax(router_logits, dim=-1),
self.top_k,
dim=-1
)
# 使用 DeepEP 内核进行 Token 分发(Dispatch)
# 避开了传统 NCCL 的高延迟开销
dispatched_tokens, handle = self.ep_buffer.dispatch(
hidden_states,
selected_experts
)
# 在分配的 GPU 上执行专家计算
expert_outputs = self.compute_experts(dispatched_tokens)
# 聚合阶段(Combine):将计算结果按原路径传回
combined_output = self.ep_buffer.combine(expert_outputs, handle)
return combined_output
def compute_experts(self, tokens: torch.Tensor) -> torch.Tensor:
# 专家网络计算逻辑占位符
return tokens * 1.05
性能测试与对比分析
在一个包含 8个节点(共 64 张 H100 GPU)、运行 67B 参数(单个 Token 激活 8个专家)的 MoE 强化学习集群中,使用不同的网络配置与通信库进行性能测试,结果如下:
| 配置方案 | 跨节点传输层 | 通信库 | 采样延迟 (ms/token) | 集群总吞吐量 (tokens/sec) | 吞吐量提升幅度 |
|---|---|---|---|---|---|
| 基础方案 | 标准 TCP | 标准 NCCL | 48.5 ms | 12,400 | 基准 (0%) |
| EFA 优化 | AWS EFA (SRD) | 标准 NCCL | 31.2 ms | 17,200 | +38.7% |
| EFA + DeepEP | AWS EFA (SRD) | DeepEP 深度优化 | 22.1 ms | 24,500 | 对比基准提升 +97.5% / 对比单 EFA 提升 +42.4% |
吞吐量提升 40% 以上的核心原因
- 零拷贝内存传输 (RDMA via EFA):Token 张量绕过宿主机操作系统内核,直接在跨节点的 GPU 显存间传输。
- 异步 Kernel 掩盖(Communication Overlapping):DeepEP 将 Token 传输切块,在传输下一批次数据的同时计算当前批次的专家网络。
- 低精度量化传输 (FP8):DeepEP 支持在网络传输前对 Token 进行 FP8 量化,到达目标节点后解量化,将网络数据量直接减半。
- Amazon S3 异步 Dump:将生成的轨迹(Trajectories)与 Checkpoint 异步写入 Amazon S3,避免磁盘 I/O 阻塞采样进程。
在优化底层训练设施的同时,企业开发者往往还会借助 n1n.ai 灵活调用各种开源与商业大模型 API,快速评估强化学习模型与商业闭源模型在具体场景中的效果差异。
专家实战建议
- 调整 EFA 环境变量:在容器中设置
FI_PROVIDER="efa"及NCCL_BUFFSIZE=8388608以最大化使用网络缓冲通道。 - 网络隔离与 HostNetwork:在 Kubernetes Pod 配置中开启
hostNetwork: true,消除 CNI 插件带来的额外的网络开销。 - 动态负载均衡:结合 vLLM 或 SGLang 的 DeepEP 补丁,应对 Reinforcement Learning 探索过程中由于专家路由倾斜(Router Skew)带来的计算负载不均。
总结
扩展 Mixture-of-Experts 模型的强化学习训练,必须同时对容器编排层与底层的网络通信内核进行针对性优化。通过在 Amazon EKS 上结合 EFA 的硬件级 RDMA 能力与 DeepEP 的高性能通信内核,团队能够打通跨节点通信瓶颈,实现 40% 以上的 RL Rollout 吞吐量增长。
Get a free API key at n1n.ai。