强化学习训练上云：分布式 GPU 集群的容器化实践

原创

hollyx

发布于 2026-08-10 17:45:04

1940

摘要：

本文以腾讯云容器服务 TKE 为平台，从 RDMA 高性能网络配置、LeaderWorkerSet 多机部署到 CFS Turbo Checkpoint 存储挂载，系统讲解强化学习分布式训练的完整落地流程，帮助工程师快速构建生产级 GPU 训练集群。

一、强化学习训练的算力需求特征

强化学习作为人工智能的重要分支，在自动驾驶、游戏 AI、机器人控制、大语言模型对齐等领域发挥着越来越重要的作用。与传统监督学习不同，强化学习通过与环境的持续交互来优化策略，这一过程通常需要海量的试错迭代。每一次迭代都涉及环境模拟、动作选择、奖励计算和策略更新等多个步骤，对计算资源提出了极高的要求。

大规模强化学习训练的核心特征是长时间运行和高通信密度。一个典型的训练任务可能需要连续运行数天甚至数周，期间不能出现中断。任何硬件故障或软件异常都可能导致数天的训练成果付诸东流。同时，在多节点分布式训练中，各个 GPU 之间需要频繁交换梯度信息和状态数据，节点间的通信效率直接影响整体训练速度。

GPU 显存容量和网络带宽是制约训练规模的两大瓶颈。随着模型参数量的增长，单张 GPU 的显存往往无法容纳完整的模型权重和中间激活值，必须采用模型并行策略将模型切分到多张 GPU 上。这种情况下，GPU 之间的数据传输量巨大，如果网络带宽不足，GPU 将花费大量时间等待数据到达，造成昂贵的算力资源闲置。

二、容器化训练集群的架构设计

2.1 统一的异构资源管理

TKE 面向大规模 AI 模型训练集群提供了统一的异构资源管理方式。在实际的训练场景中，集群内可能同时存在多种类型的 GPU 卡，包括不同代际的 NVIDIA GPU 以及国产加速卡。TKE 通过设备插件和资源调度器的协同工作，将这些异构算力统一抽象为标准化的 Kubernetes 资源，用户无需关心底层硬件的差异即可提交训练任务。

这种统一管理方式带来了显著的运维优势。训练任务的提交和调度通过标准的 Kubernetes API 完成，与传统的 Slurm 等作业调度系统相比，降低了学习成本和集成复杂度。同时，Kubernetes 的原生能力如自动重启、健康检查、日志收集等都可以直接应用于训练任务的管理。

2.2 高速互联网络保障通信效率

RDMA 高性能网络的支持是 TKE 保障分布式训练效率的关键能力之一。通过 RDMA 技术，训练节点之间可以实现低延迟、高吞吐的数据传输，显著缩短梯度同步的时间。TKE 的 RDMA 方案具有统一 GID Index、NUMA 亲和调度等产品化特性，简化了 RDMA 网络的部署和使用。

在具体的训练框架层面，NCCL 作为 NVIDIA 提供的集合通信库，已经内置了对 RDMA 的支持。当训练框架如 PyTorch 调用 NCCL 进行 AllReduce 等操作时，底层会自动选择最优的通信路径。如果检测到 RDMA 设备可用，NCCL 会优先使用 RDMA 进行数据传输，充分发挥硬件的性能潜力。

2.3 拓扑感知的智能调度

分布式训练任务的性能不仅取决于单个节点的计算能力，还受到节点间网络拓扑的影响。TKE 针对分布式作业优化了资源分配和拓扑感知调度能力。当调度器为一个多节点训练任务分配资源时，会优先选择网络距离更近、带宽更高的节点组合，减少跨交换机或跨机架的通信开销。

对于需要多机协同的大规模训练，TKE 支持 LeaderWorkerSet 等工作负载类型。Leader Pod 负责协调整个训练作业的启动和监控，Worker Pod 承担实际的计算任务。这种架构确保了分布式训练任务的有序执行和统一管理。

三、快速上手：部署分布式强化学习训练集群

3.1 第一步：创建支持 RDMA 的高性能计算节点池

RDMA 网络需要 HCCPNV 系列高性能计算实例支持。以 HCCPNV6.96XLARGE2304 为例，该机型配备 8 张 H20 GPU、3.2 Tbps RDMA 带宽、384 核 CPU 和 2304 GB 内存，适合双机或多机部署满血版大模型训练。

在 TKE 控制台创建原生节点池时，需要进行以下关键配置：

# 节点池高级设置
labels:
  feature.node.kubernetes.io/tke-shared-rdma: "true"
annotations:
  kubelet.config.kubernetes.io/topology-manager-policy: "best-effort"

topology-manager-policy: best-effort 启用 NUMA 亲和调度，确保 GPU 和 RDMA 网卡在同一 NUMA 节点上，避免跨 NUMA 访问带来的性能损耗。

3.2 第二步：安装 rdma-agent 组件

rdma-agent 是 TKE 提供的一键式 RDMA 共享组件，负责 RDMA 设备的发现、注册和共享。在 TKE 控制台的「组件管理」中勾选 rdma-agent 即可完成安装。组件默认部署在所有添加了 feature.node.kubernetes.io/tke-shared-rdma=true 标签的节点上。

也可以通过命令行安装：

kubectl apply -f https://tke-examples.sh.tencentyun.com/rdma-agent/rbac.yaml
kubectl apply -f https://tke-examples.sh.tencentyun.com/rdma-agent/csidriver.yaml
kubectl apply -f https://tke-examples.sh.tencentyun.com/rdma-agent/daemonset.yaml

3.3 第三步：部署 LeaderWorkerSet 多机训练任务

LeaderWorkerSet（LWS）是 Kubernetes 社区推出的分布式作业编排 API，TKE 已将其集成到应用市场中。以下是一个 2 节点 × 8 GPU 的 PyTorch 分布式训练示例：

apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: rlhf-training
spec:
  replicas: 1
  leaderWorkerTemplate:
    size: 2
    restartPolicy: RecreateGroupOnPodRestart
    leaderTemplate:
      metadata:
        labels:
          role: leader
      spec:
        hostNetwork: true
        hostIPC: true
        containers:
          - name: trainer
            image: nvcr.io/nvidia/pytorch:24.04-py3
            command: ["torchrun"]
            args:
              - "--nnodes=2"
              - "--nproc_per_node=8"
              - "--rdzv_backend=c10d"
              - "--rdzv_endpoint=$(LWS_LEADER_ADDRESS):29500"
              - "/workspace/train.py"
              - "--deepspeed"
              - "--deepspeed_config=/workspace/ds_config.json"
            env:
              - name: NCCL_IB_HCA
                value: "mlx5"
              - name: NCCL_IB_GID_INDEX
                value: "3"
              - name: NCCL_NET_GDR_LEVEL
                value: "5"
              - name: NCCL_DEBUG
                value: "WARN"
            resources:
              limits:
                nvidia.com/gpu: "8"
                rdma/rdma_shared_device_a: "1"
            volumeMounts:
              - name: dshm
                mountPath: /dev/shm
              - name: checkpoints
                mountPath: /checkpoints
        volumes:
          - name: dshm
            emptyDir:
              medium: Memory
              sizeLimit: 64Gi
          - name: checkpoints
            persistentVolumeClaim:
              claimName: cfs-turbo-checkpoint-pvc
    workerTemplate:
      spec:
        hostNetwork: true
        hostIPC: true
        containers:
          - name: trainer
            image: nvcr.io/nvidia/pytorch:24.04-py3
            command: ["torchrun"]
            args:
              - "--nnodes=2"
              - "--nproc_per_node=8"
              - "--rdzv_backend=c10d"
              - "--rdzv_endpoint=$(LWS_LEADER_ADDRESS):29500"
              - "/workspace/train.py"
            env:
              - name: NCCL_IB_HCA
                value: "mlx5"
              - name: NCCL_IB_GID_INDEX
                value: "3"
              - name: NCCL_NET_GDR_LEVEL
                value: "5"
            resources:
              limits:
                nvidia.com/gpu: "8"
                rdma/rdma_shared_device_a: "1"
            volumeMounts:
              - name: dshm
                mountPath: /dev/shm
              - name: checkpoints
                mountPath: /checkpoints
        volumes:
          - name: dshm
            emptyDir:
              medium: Memory
              sizeLimit: 64Gi
          - name: checkpoints
            persistentVolumeClaim:
              claimName: cfs-turbo-checkpoint-pvc

关键配置说明：

配置项	作用
`hostNetwork: true`	使用宿主机网络，RDMA 生效的必要条件
`hostIPC: true`	启用进程间通信共享，NCCL 多进程通信所需
`rdma/rdma_shared_device_a: 1`	申请 RDMA 共享设备资源
`NCCL_IB_GID_INDEX: 3`	RoCEv2 GID 索引，RDMA over Converged Ethernet 必需
`NCCL_NET_GDR_LEVEL: 5`	启用 GPUDirect RDMA，绕过 CPU 直接在 GPU 和网卡间传输数据
`$(LWS_LEADER_ADDRESS)`	LWS 自动注入的环境变量，指向 Leader Pod 的 DNS 名称
`RecreateGroupOnPodRestart`	任意 Pod 失败时整组重建，保证训练一致性

3.4 第四步：挂载 CFS Turbo 共享存储用于 Checkpoint

强化学习训练过程中需要定期保存 Checkpoint，以防止故障导致训练进度丢失。CFS Turbo 并行文件系统提供千万级 IOPS 和微秒级延迟，适合多节点并发读写 Checkpoint 文件。

首先创建静态 PV（CFS Turbo 仅支持静态供给）：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-cfs-turbo-checkpoint
spec:
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 10Gi
  csi:
    driver: com.tencent.cloud.csi.cfsturbo
    volumeHandle: pv-cfs-turbo-checkpoint
    volumeAttributes:
      proto: lustre          # 固定值，不可修改
      rootdir: /cfs          # 固定值，不可修改
      fsid: "<FSID>"         # 文件系统 FSID（非 CFS ID，见挂载点信息）
      host: "<MOUNT_IP>"     # 文件系统挂载点 IP
      path: /checkpoint      # 子目录，需确保在文件系统中存在
  storageClassName: ""       # CFS Turbo 不支持动态供给，必须为空

然后创建 PVC 绑定 PV：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cfs-turbo-checkpoint-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  volumeName: pv-cfs-turbo-checkpoint
  storageClassName: ""

部署后可以通过以下命令验证挂载情况：

kubectl exec -it <pod-name> -- df -h | grep checkpoint

3.5 第五步：监控训练任务状态

LeaderWorkerSet 提供了丰富的状态查询能力：

# 查看 LWS 整体状态
kubectl get lws rlhf-training

# 查看 Leader 和 Worker Pod
kubectl get pods -l leaderworkerset.sigs.k8s.io/name=rlhf-training

# 查看 Leader Pod 日志
kubectl logs rlhf-training-0

# 查看 Worker Pod 日志
kubectl logs rlhf-training-0-1

# 查看训练任务详情
kubectl describe lws rlhf-training

四、典型场景与客户实践

4.1 大语言模型的 RLHF 训练

基于人类反馈的强化学习（RLHF）是大语言模型对齐的关键技术。RLHF 训练通常包含三个主要阶段：监督微调（SFT）、奖励模型训练（RM）和强化学习优化（PPO/GRPO）。每个阶段都需要大量的 GPU 资源和复杂的分布式协调。

以 OpenRLHF 框架为例，Actor、Critic、Reward、Reference 四个模型可以分别部署在不同的 GPU 组上，通过 Ray 进行分布式调度。TKE 的容器化方案使得这四个阶段可以在同一个集群中无缝衔接——利用 CFS Turbo 共享存储在不同阶段之间传递模型权重，利用 LeaderWorkerSet 管理每个阶段的分布式训练任务，利用 qGPU 共享技术在训练间隙运行推理评估任务提升 GPU 利用率。

4.2 腾讯内部大规模强化学习实践

腾讯内部某业务基于 TKE 构建了大规模强化学习训练平台，支撑了多个核心业务的 AI 研发需求。该平台采用 Actor-Learner 架构，其中 Actor 进程负责产生观测数据，Learner 进程负责梯度更新，ModelPool 负责模型中转，Manager 负责训练管理和 Checkpoint 保存。

在传统手工管理模式下，单次全量实验需要数万个 CPU 核心和数百个 GPU 卡，持续一到两周，资源利用率极低。迁移到 TKE 后，通过容器镜像管理代码版本、通过 kubectl 一键启停训练任务、通过弹性伸缩组按需购买和退还资源，综合成本降低了约三分之二。训练任务从面向机器变为面向资源，工程师只需声明每个角色需要的 CPU、内存和 GPU 数量，Kubernetes 调度器自动选择合适的节点运行。

强化学习训练需要海量并行计算，传统基础设施难以弹性应对。TKE 用分布式 GPU 集群和弹性伸缩能力，让每一次仿真迭代都跑在最优算力上，加速 AI 从训练到落地的全链路 → https://cloud.tencent.com/product/tke

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

实践