最新n1n v2.0.1 正式上线!企业级大模型接口聚合平台 (LLM API Gateway),为您接入 500+ AI Models,价格低至 1 折, 立即尝试

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

作者
  • avatar
    姓名
    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 分发与聚合:

  1. 分发阶段(Dispatch):生成节点需将 Token 数据通过网络发送至对应专家所在的目标 GPU。
  2. 聚合阶段(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

为解决这一瓶颈,该方案整合了三大关键技术栈:

  1. Amazon EKS (Kubernetes 容器编排):提供高弹性的分布式作业调度能力,精准管理 PyTorch Job 或 Ray / vLLM 采样节点的资源分配。
  2. AWS Elastic Fabric Adapter (EFA):AWS 专为高性能计算(HPC)与机器学习设计的网络接口,支持 OS Bypass(操作系统旁路,基于 SRD 协议),绕过 Linux 内核直接在 GPU 内存间进行低延迟、高吞吐的跨节点 RDMA 传输。
  3. 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标准 NCCL48.5 ms12,400基准 (0%)
EFA 优化AWS EFA (SRD)标准 NCCL31.2 ms17,200+38.7%
EFA + DeepEPAWS EFA (SRD)DeepEP 深度优化22.1 ms24,500对比基准提升 +97.5% / 对比单 EFA 提升 +42.4%

吞吐量提升 40% 以上的核心原因

  1. 零拷贝内存传输 (RDMA via EFA):Token 张量绕过宿主机操作系统内核,直接在跨节点的 GPU 显存间传输。
  2. 异步 Kernel 掩盖(Communication Overlapping):DeepEP 将 Token 传输切块,在传输下一批次数据的同时计算当前批次的专家网络。
  3. 低精度量化传输 (FP8):DeepEP 支持在网络传输前对 Token 进行 FP8 量化,到达目标节点后解量化,将网络数据量直接减半。
  4. 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。