Kubernetes RDMA 概述与实战(大模型场景)-EW帮帮网

一、背景

近年来，人工智能（AI）领域见证了模型规模的指数级增长，特别是大型语言模型（LLM）的发展，其参数量已从数十亿扩展至数万亿级别。这种规模的增长使得单一计算节点无法满足训练和推理的需求，分布式计算成为必然选择，通常涉及跨越数百甚至数千个图形处理单元（GPU）或张量处理单元（TPU）节点进行协同工作。

在这种大规模分布式环境中，节点间的通信效率成为决定整体性能的关键因素。无论是训练过程中频繁的梯度同步（例如，通过 All-Reduce 操作）和参数交换，还是大规模推理服务中对低延迟、高吞吐量的严苛要求，都对底层网络基础设施提出了前所未有的挑战。传统的基于 TCP/IP 协议栈的网络通信方式，由于其固有的协议处理开销、多次内存拷贝以及内核介入，在高负载、低延迟要求的场景下往往会成为性能瓶颈，导致计算资源闲置，延长训练时间，影响推理服务的响应速度。

1.1 RDMA：高性能网络的解决方案

为了克服传统网络的局限性，远程直接内存访问（RDMA, Remote Direct Memory Access）技术应运而生。RDMA 的核心优势在于允许一台计算机的内存直接访问另一台计算机的内存，而无需涉及双方的操作系统内核或 CPU 介入数据传输路径。通过“零拷贝”（Zero-Copy）、“内核旁路”（Kernel Bypass）和“CPU 卸载”（CPU Offload）等机制，RDMA 能够显著降低网络通信延迟至微秒级，并提供接近物理链路速率的高带宽。这使得 RDMA 成为高性能计算（HPC）和大规模 AI/ML 等数据密集型应用场景下的理想网络技术。

1.2 Kubernetes：可扩展工作负载的事实标准

与此同时，Kubernetes 已成为容器化应用编排的事实标准，为部署、扩展和管理大规模应用提供了强大的平台。随着 AI/ML 工作负载日益复杂化，越来越多的组织选择在 Kubernetes 上运行 LLM 的训练和推理任务，以利用其自动化、弹性和资源管理能力。

然而，将 RDMA 这类需要特定硬件支持和底层配置的高性能技术融入 Kubernetes 的抽象模型中，本身就是一个挑战。Kubernetes 的设计初衷是提供硬件无关的抽象，而 RDMA 则要求对底层硬件（如 RDMA 网卡）有更直接的访问和控制。

二、RDMA 技术基础

理解 RDMA 如何在 Kubernetes 中加速大模型，首先需要掌握其核心技术原理和优势。RDMA 通过一系列机制绕开了传统网络协议栈的瓶颈，实现了高效的远程内存访问。

2.1 核心概念：零拷贝、内核旁路与 CPU 卸载

RDMA 的高性能主要源于以下三个核心概念：

零拷贝 (Zero-Copy): 在传统网络传输中，数据需要在应用程序内存和操作系统内核的网络缓冲区之间进行多次复制。RDMA 允许网络适配器（RNIC）直接在不同机器的应用程序内存缓冲区之间传输数据，完全消除了这些中间拷贝环节。相比之下，TCP/IP 协议栈通常涉及多次数据拷贝。零拷贝显著降低了数据传输的延迟，并减少了 CPU 和内存带宽的消耗。
内核旁路 (Kernel Bypass): RDMA 操作绕过了主机操作系统的网络协议栈。应用程序可以通过用户态驱动库（如 libibverbs）直接与 RNIC 交互，提交数据传输请求，而无需陷入内核态。这避免了用户态和内核态之间的上下文切换开销，进一步降低了延迟。
CPU 卸载 (CPU Offload) / 远端 CPU 无关: RDMA 操作将数据传输的处理任务从 CPU 卸载到了 RNIC 硬件上。对于远端的接收方而言，其 CPU 完全不参与传入的 RDMA 读写操作的处理过程。数据由 RNIC 直接写入目标内存地址，不会中断远端 CPU 的正常执行，也不会污染其缓存。本地 CPU 仅需发起传输请求，无需处理数据的字节级移动。

这些机制共同作用，使得 RDMA 能够将网络处理的重心从软件（CPU 和内核）转移到专门设计的硬件（RNIC）上，这是其相比传统网络获得巨大性能优势的根本原因。

2.2 RDMA 工作原理：硬件角色、内存注册与操作

实现 RDMA 需要硬件和软件的协同工作：

RDMA 网络适配器 (RNIC) 角色: RDMA 依赖于支持该技术的专用网络接口卡（RNIC）。这些 RNIC 具备处理直接内存访问、维护连接状态、执行传输协议卸载等硬件能力。常见的 RNIC 包括 NVIDIA（原 Mellanox）的 ConnectX 系列网卡。
内存注册 (Memory Registration / Pinning): 由于 RDMA 需要直接访问物理内存，应用程序必须在使用 RDMA 传输数据前，将相关的内存区域进行“注册”或“钉住”（Pinning）。内存注册确保了操作系统不会将这部分内存交换到磁盘（page out），并为 RNIC 提供了稳定、可直接访问的物理内存地址。注册过程通常涉及保护域（Protection Domain, PD）和内存区域（Memory Region, MR）的创建和管理。虽然内存注册是 RDMA 实现直接访问的关键机制，但它也引入了额外的编程复杂性。与使用操作系统管理的虚拟内存的标准套接字编程相比，RDMA 应用需要显式地管理这些固定内存区域，增加了额外的步骤（如创建 PD、MR、获取 rkey）和潜在的故障点。
关键操作: RDMA 定义了一系列操作原语，其中最核心的是：
- RDMA 写 (RDMA Write): 一种“单边”（One-sided）操作，发起方（Initiator）指定远程内存地址，并将数据直接写入该地址，无需接收方应用程序的显式接收动作。
- RDMA 读 (RDMA Read): 另一种单边操作，发起方指定远程内存地址，并直接从中读取数据，同样无需接收方应用程序的介入。
- 发送/接收 (Send/Receive): 这是“双边”（Two-sided）操作，需要发送方和接收方进行协调（接收方需要预先发布接收请求）。虽然需要协调，但仍然受益于 RDMA 的硬件卸载和低开销传输。
- 编程接口: 实现这些操作通常需要使用 RDMA 编程库（如 libibverbs），涉及队列对（Queue Pair, QP）和完成队列（Completion Queue, CQ）等核心数据结构的管理。

2.3 主要协议：InfiniBand vs. RoCE vs. iWARP

实现 RDMA 功能可以通过多种底层网络协议：

InfiniBand (IB): InfiniBand 是一种从头开始设计的高性能网络技术，原生支持 RDMA。它通常用于 HPC 集群和需要极致性能的场景。部署 InfiniBand 需要专用的 IB 交换机和适配器卡，构成一个独立的网络结构。
RoCE (RDMA over Converged Ethernet): RoCE 协议允许在标准的以太网基础设施上运行 RDMA 操作。它有两个主要版本：
- RoCE v1：工作在以太网链路层，要求底层网络是无损的（通常通过基于优先级的流控 PFC 实现）。
- RoCE v2：工作在 UDP/IP 之上，因此是可路由的，并且可以在有损或无损的以太网上运行。RoCE 的主要优势在于能够利用现有的、广泛部署的以太网设备。
iWARP (Internet Wide Area RDMA Protocol): iWARP 是另一种在 TCP/IP 上实现 RDMA 的协议。它提供了较好的兼容性，因为可以运行在任何支持 TCP/IP 的网络上，但相对于 RoCE 和 InfiniBand，其协议开销通常更高，可能导致延迟增加和性能下降。

选择 InfiniBand 还是 RoCE 对基础设施有显著影响。InfiniBand 可能在专用环境中提供最佳性能和最低延迟，但需要投资建设独立的网络。RoCE 则允许在现有的以太网设施上实现 RDMA，更具成本效益和灵活性，但可能需要仔细的网络配置（如为 RoCE v1 配置无损网络，或为 RoCE v2 调整拥塞控制机制）以获得理想性能。

2.4 量化优势：低延迟与高带宽

RDMA 的核心优势最终体现在其卓越的性能指标上：

超低延迟: 通过零拷贝、内核旁路和 CPU 卸载，RDMA 将端到端的通信延迟显著降低到微秒（µs）级别。这对于需要快速响应和频繁小消息交换的应用（如梯度同步、分布式事务）至关重要。
极高带宽: 绕过软件协议栈的处理瓶颈，RDMA 能够实现非常高的网络吞吐量，通常可以接近物理链路的线速，例如 100 Gbps、200 Gbps 甚至 400 Gbps 及以上。相比之下，TCP/IP 在高速链路下性能可能会因为 CPU 处理能力或协议开销而饱和。

三、大模型工作负载中的网络通信瓶颈

虽然 RDMA 提供了强大的网络性能，但理解它为何对大模型训练和推理如此重要，需要先分析这些工作负载中存在的具体网络瓶颈。

3.1 分布式训练的挑战

训练大型模型，尤其是 LLM，通常采用分布式策略，将计算任务分散到大量 GPU 或 TPU 上。这个过程对网络通信提出了极高的要求：

规模与数据量: 训练可能涉及数千个计算单元，模型参数和中间数据（如激活值）规模巨大。例如，训练像 GPT-3 这样的 175B 参数模型，在反向传播过程中需要交换 PB 级别的数据。
梯度同步: 同步数据并行（Synchronous Data Parallelism）是最常见的分布式训练方法之一。在这种模式下，每个工作节点（Worker）处理一部分数据，计算梯度，然后在每一步（Iteration）都需要通过集体通信操作（如 All-Reduce）聚合所有节点的梯度，以保证模型参数的一致性更新。All-Reduce 操作对网络的延迟和带宽都极为敏感，频繁的全局同步使其成为主要的性能瓶颈。
参数交换: 除了数据并行，模型并行（Model Parallelism）、流水线并行（Pipeline Parallelism）和张量并行（Tensor Parallelism）等更复杂的并行策略也被广泛采用，以适应更大规模的模型。这些策略虽然可能减少单个节点上的内存压力，但往往引入更复杂的节点间通信模式，例如交换激活值、部分梯度或模型分片（Shards）。这种对高性能互连的依赖性甚至超过了纯粹的数据并行。
TCP/IP 开销: 在大规模、高频率的通信场景下，标准 TCP/IP 协议栈的开销变得不可忽视。协议处理、多次内存拷贝、上下文切换以及潜在的网络拥塞都会显著增加通信时间，限制整体训练速度。
掉队者 (Stragglers): 在同步训练中，任何一个工作节点的延迟（可能由网络波动、计算缓慢或硬件差异引起）都会拖慢整个训练集群的进度，因为所有节点必须等待最慢的节点完成梯度计算和同步。高效、低延迟的网络有助于减少掉队现象。
框架依赖: 主流的深度学习框架，如 PyTorch（使用 DistributedDataParallel (DDP) 或 Fully Sharded Data Parallel (FSDP)）和 TensorFlow（使用 MirroredStrategy 或 MultiWorkerMirroredStrategy），都依赖底层的通信库（如 NVIDIA Collective Communications Library (NCCL), Gloo, Message Passing Interface (MPI)）来执行分布式操作。这些通信库能够充分利用 RDMA 提供的低延迟、高带宽特性来加速集体通信。

3.2 高吞吐、低延迟推理的挑战

将训练好的大模型部署为在线服务，用于推理（Inference），同样面临网络相关的挑战，尽管侧重点有所不同：

实时性要求: 许多 LLM 应用，如交互式聊天机器人、实时推荐系统等，对响应延迟有严格要求。关键指标包括首个令牌生成时间（Time-to-First-Token, TTFT）和令牌间延迟（Inter-Token Latency, ITL）。低延迟网络有助于缩短这些时间，提升用户体验。
可扩展性: 推理服务的负载通常具有波动性，需要系统能够快速扩展以应对用户需求的峰值，同时保持稳定的性能。高吞吐量（每秒处理的请求数或生成的令牌数）对于满足大规模用户需求和控制服务成本至关重要。
模型大小与内存: 即便用于推理，大型模型也可能需要占用大量内存，有时甚至需要跨多个 GPU 或多个节点进行部署（例如使用张量并行）。这种分布式推理场景下，GPU 间的通信效率直接影响推理速度。
Prefill 与 Decode 阶段: LLM 推理包含两个主要阶段：Prefill 阶段处理输入提示（Prompt），计算量较大；Decode 阶段自回归地逐个生成输出令牌，对内存带宽更敏感。这两个阶段的计算特性不同，将它们混合在同一批次或同一硬件上处理可能导致资源竞争和性能下降。高效管理键值缓存（KV Cache）对于优化 Decode 阶段至关重要。
网络影响: 虽然推理通常被认为是计算密集型（Prefill）或内存带宽密集型（Decode）任务，但在以下场景中，网络性能仍然扮演着重要角色：
- 分布式推理: 当模型通过张量并行等方式分布在多个节点上时，节点间的参数或中间结果传递需要低延迟网络。
- 模型加载: 从存储系统加载庞大的模型文件到 GPU 内存可能耗时较长，高速网络（如基于 RDMA 的存储访问）可以加速这一过程。
- 解耦式推理架构 (Disaggregated Inference): 将 Prefill 和 Decode 阶段部署到不同的硬件池或节点上，以优化资源利用率。这种架构需要通过网络高效地传输状态信息（如 KV Cache），RDMA 的低延迟特性在此类场景下具有优势。
- 分布式 KV 缓存: 跨节点管理或卸载 KV 缓存也可能涉及网络传输。

分析训练和推理的瓶颈可以看出，尽管具体表现形式不同（训练侧重于大规模、高频的集体通信效率，推理侧重于单次请求的低延迟和整体吞吐量），两者都对底层网络的低延迟和高带宽提出了强烈需求。这使得 RDMA 成为一个能够同时优化 LLM 生命周期中这两个关键阶段的有吸引力的技术选项。此外，随着推理架构日益复杂和分布式化（如解耦式推理、专家混合模型路由、分布式 KV 缓存），对低延迟互连的需求预计将进一步增加，使得 RDMA 在推理场景中的重要性日益凸显。

四、Kubernetes RDMA 实战

4.1 前置硬件

4.2 Kubernetes设备插件

## 安装rdma 设备插件 k8s-rdma-shared-dev-plugin
git clone https://github.com/Mellanox/k8s-rdma-shared-dev-plugin
cd deployment/k8s/base
kubectl apply -k .

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  config.json: |
    {
        "periodicUpdateInterval": 300,
        "configList": [
            {
                "resourceName": "hca_shared_devices_a",
                "resourcePrefix": "rdma",
                "rdmaHcaMax": 200,
                "selectors": {
                    "ifNames": ["ibs108"]
                }
            }
        ]
    }
kind: ConfigMap
metadata:
  name: rdma-devices
  namespace: kube-system
EOF

kubectl get node te1 -o jsonpath='{.status.capacity}' | jq

补充 selectors说明

"selectors": {
    "ifNames": ["ib0"],
    "vendors": ["15b3"],
    "devices": ["1017"],
    "drivers": ["mlx5_core"],
    "pfNames": ["ens3f0"],
    "linkTypes": ["infiniband"],
    "rootDevices": ["0000:81:00.0"]
}

lspci -nn | grep -i Mellanox

解读:
[15b3:101b] 这部分就是你需要的信息。
vendors: 厂商 ID 是 15b3。
deviceIDs: 设备 ID 是 101b。

# 查询 ifNames
ibdev2netdev

解读:
ifNames: 这里的 ibs108 
就是可以用于 selector 的接口名

#查询 linkTypes
ibstat mlx5_0

解读:
Link layer: InfiniBand 表示 linkTypes 是 IB。
如果是 Ethernet，则对应 ETH

4.3 Pod调度分配 rdma 网卡

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nccl-test
  namespace: default
spec:
  selector:
    matchLabels:
      app: nccl-test
  template:
    metadata:
      labels:
        app: nccl-test
    spec:
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Exists"
        effect: "NoSchedule"
      hostNetwork: true
      hostPID: true
      containers:
      - name: nccl-test
        image: nvcr.io/nvidia/hpc-benchmarks:25.04
        command: ["/bin/bash", "-c"]
        args:
          - |
            echo "Pod is ready. Use kubectl exec to run NCCL tests interactively, e.g. all_reduce_perf";
            sleep infinity
        resources:
          limits:
            nvidia.com/gpu: 1
            rdma/hca_shared_devices_a: 1
          requests:
            nvidia.com/gpu: 1
            rdma/hca_shared_devices_a: 1
        securityContext:
          capabilities:
            add: ["IPC_LOCK"]
        volumeMounts:
        - name: infiniband
          mountPath: /dev/infiniband
        - name: sys-infiniband
          mountPath: /sys/class/infiniband
      volumes:
      - name: infiniband
        hostPath:
          path: /dev/infiniband
      - name: sys-infiniband
        hostPath:
          path: /sys/class/infiniband
EOF

nvcr.io/nvidia/hpc-benchmarks:25.04
kubectl -n kube-system rollout restart ds nccl-test-daemonset

4.4 测试rdma 网络性能

kubectl exec -it nccl-test-bm4lj -- ls /usr/local/bin | grep "perf"

单机测试:

跨节点测试:

## 需要配置免密
## 安装ssh相关依赖
unset http_proxy https_proxy all_proxy
apt-get update && apt-get install -y openssh-server
apt-get install -y iputils-ping
apt-get install -y ibverbs-utils


# 容器1 / 容器2  都需要配置
sed -i 's/^#\?Port .*/Port 2222/' /etc/ssh/sshd_config
sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config
service ssh restart

# 配置密码
passwd

## 免密 node1 / node2 相互免密
cd ~/.ssh
ssh-keygen -t rsa
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/aut
ssh-copy-id -i ~/.ssh/id_rsa.pub -p 2222 root@10.1.4.72
ssh-copy-id -i ~/.ssh/id_rsa.pub -p 2222 root@10.1.4.74

## 测试
ssh -p 2222 root@10.1.4.74 hostname

## 跨节点测试
cat > /workspace/hostfile <<EOF
10.1.4.72 slots=4
10.1.4.74 slots=4
EOF

export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH
export NCCL_DEBUG="INFO"
export NCCL_SOCKET_IFNAME="ibs108"
export NCCL_IB_HCA="mlx5_0"
export NCCL_IB_TIMEOUT=22
export NCCL_NET_GDR_LEVEL=5

mpirun -np 8 --allow-run-as-root \
    --hostfile /workspace/hostfile \
    --map-by ppr:4:node:PE=$OMP_NUM_THREADS \
    --rank-by node \
    --bind-to core \
    \
    -x LD_LIBRARY_PATH \
    -x NCCL_DEBUG \
    -x NCCL_SOCKET_IFNAME \
    -x NCCL_IB_HCA \
    -x NCCL_IB_TIMEOUT \
    -x NCCL_NET_GDR_LEVEL \
    \
    --mca plm_rsh_agent "ssh -p 2222" \
    --mca pml ucx \
    --mca btl ^openib,tcp,vader,self \
    --mca oob_tcp_if_include ibs108 \
    \
    /usr/local/bin/all_reduce_perf -b 8 -e 8G -f 2 -g 1