基于K8s的云原生AI基础设施：架构、部署与实践【008】-AI算力的高性能传输

在 AI 算力集群中，GPU 提供的是计算能力，而高性能网络决定的是这些计算资源能否在多节点之间高效协同。一旦进入多机训练、参数同步、分布式推理或高吞吐模型服务场景，节点之间的数据交换很快就会成为瓶颈。RoCE / RDMA 之所以重要，正是因为它为这类场景提供了一条更高带宽、更低时延的通信通道。

但在 Kubernetes 里，宿主机上“有 RDMA 网卡”并不等于 Pod 就能直接使用它。对集群来说，这些 HCA 设备首先必须被识别为节点能力，然后再被注册成 kubelet 可感知的扩展资源，最终才能被工作负载通过 resources.requests/limits 显式申请。Kubernetes 官方对 Device Plugin 的定义非常直接：它就是用来把 GPU、NIC、InfiniBand 适配器这类需要厂商特定初始化的硬件资源注册给 kubelet，并作为扩展资源暴露给调度系统。

因此，这一章关心的并不是“如何安装一个插件”，而是一个更贴近 AI 平台的问题：如何把宿主机上的 RoCE / RDMA 设备，从“节点硬件”变成“AI 工作负载可以申请和使用的集群资源”。

1. 将 RDMA 纳入 Kubernetes 调度体系

一旦进入多机训练、数据并行同步、流水并行或跨节点推理场景，节点之间的通信链路就不再只是辅助条件，而会直接影响整体吞吐、时延和扩展效率。

在这类场景中，RoCE / RDMA 的意义不再只是“网络更快”，而是为分布式 AI 工作负载提供更高效的数据交换通道。NCCL 官方文档也明确区分了单机内与跨节点通信路径：前者优先利用 NVLink、PCIe 和 shared memory，后者则依赖 sockets 或 InfiniBand verbs。问题在于，Kubernetes 默认并不会自动把 HCA 当成“可以调度的资源”。

如果没有 Device Plugin，这些设备只存在于宿主机层，调度器不知道哪些节点有 RDMA，Pod 也无法通过标准方式显式申请它们。Device Plugin 框架存在的意义，就是把这类硬件广告给 kubelet，并最终体现在 Node Status 中。

2. 如何找到 RDMA 能力的物理节点

在部署 Device Plugin 之前，第一步是先确认节点本身已经具备可用的 RDMA 运行条件。如果宿主机上的 OFED 驱动、RDMA 子系统、链路状态本身就不正常，那么后面的 Kubernetes 资源暴露都没有意义。这一阶段建议重点确认三类信息：

第一，驱动和 RDMA 子系统是否正常，例如 ofed_info -s、rdma link show、ibdev2netdev。 第二，节点上到底有哪些 RDMA capable 设备，例如 lspci -nn | grep -i Mellanox、ls /sys/class/infiniband。 第三，RoCE 相关链路与 GID 信息是否正确，例如 ibv_devinfo -d mlx5_0 -v、show_gids、/sys/class/infiniband/.../gid_attrs。

这一步的目标只有一个：**先证明宿主机层的 RDMA 设备、网口、驱动和链路都已经准备好。**否则，后面的 Kubernetes 资源纳管只是“把错误包装成了资源”。

**# 1. 通过以下命令确认主机是否已经正确安装OFED驱动
ofed_info -s**
MLNX_OFED_LINUX-23.10-3.2.2.0:

# 2. 通过以下命令确认RDMA环境是否Ready
**rdma link show**
link mlx5_0/1 state ACTIVE physical_state LINK_UP netdev ens18np0 
link mlx5_3/1 state ACTIVE physical_state LINK_UP netdev ens21np0 
link mlx5_4/1 state ACTIVE physical_state LINK_UP netdev ens20np0 
link mlx5_bond_0/1 state ACTIVE physical_state LINK_UP netdev ens67f0np0 

**ibdev2netdev**
mlx5_0 port 1 ==> ens18np0 (Up)
mlx5_3 port 1 ==> ens21np0 (Up)
mlx5_4 port 1 ==> ens20np0 (Up)
mlx5_bond_0 port 1 ==> bond0 (Up)

# 3.通过macvlan暴露RoCE网卡时，需要确认主机上的RDMA子系统工作在Shared模式下
**rdma system**
netns shared

# 4.确认RDMA网卡信息，用于后续device plugin发现设备资源
lspci -nn | grep -i Mellanox
4d:00.0 Ethernet controller [0200]: Mellanox Technologies MT2910 Family [ConnectX-7] [15b3:1021]
a7:00.0 Ethernet controller [0200]: Mellanox Technologies MT27800 Family [ConnectX-5] [15b3:1017]
a7:00.1 Ethernet controller [0200]: Mellanox Technologies MT27800 Family [ConnectX-5] [15b3:1017]
b7:00.0 Ethernet controller [0200]: Mellanox Technologies MT2910 Family [ConnectX-7] [15b3:1021]
cd:00.0 Ethernet controller [0200]: Mellanox Technologies MT2910 Family [ConnectX-7] [15b3:1021]

# 5.**查看节点有没有RDMA子系统（最直观）**
ls /sys/class/infiniband
mlx5_0  mlx5_3  mlx5_4  mlx5_bond_0
这说明：你的服务器上有至少 4 个 RDMA-capable 设备：
    - mlx5_0
    - mlx5_3
    - mlx5_4
    - mlx5_bond_0（这是一个 bond 口，对应多个物理口绑定）

# 6.物理机测试验证
**# 连通性测试**
	# Server端
ibv_rc_pingpong -d mlx5_0 -g 3 -p 18515

	# Client端
ibv_rc_pingpong -d mlx5_0 -g 3 10.8.10.5 -p 18515 
  local address:  LID 0x0000, QPN 0x000137, PSN 0x163095, GID fe80::a288:c2ff:fef2:7cd6
  remote address: LID 0x0000, QPN 0x000137, PSN 0xbe8a3c, GID fe80::a288:c2ff:fef1:6582
8192000 bytes in 0.01 seconds = 7127.35 Mbit/sec
1000 iters in 0.01 seconds = 9.19 usec/iter

**# 带宽测试**
	# Server端
	ib_write_bw -d mlx5_0 -F --report_gbits -p 18515 -q 32 -s 65536

	# Client端
	ib_write_bw -d mlx5_0 -F --report_gbits -p 18515 -q 32 10.8.10.5 -s 65536
---------------------------------------------------------------------------------------
                    RDMA_Write BW Test
 Dual-port       : OFF          Device         : mlx5_0
 Number of qps   : 32           Transport type : IB
 Connection type : RC           Using SRQ      : OFF
 PCIe relax order: ON
 ibv_wr* API     : ON
 TX depth        : 128
 CQ Moderation   : 1
 Mtu             : 4096[B]
 Link type       : Ethernet
 GID index       : 3
 Max inline data : 0[B]
 rdma_cm QPs     : OFF
 Data ex. method : Ethernet
---------------------------------------------------------------------------------------
 local address: LID 0000 QPN 0x016c PSN 0x8b924b RKey 0x1ffec2 VAddr 0x007f2cb3e2e000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:04
 local address: LID 0000 QPN 0x016d PSN 0xc815d9 RKey 0x1ffec2 VAddr 0x007f2cb3e3e000
 ......
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:04
 local address: LID 0000 QPN 0x0174 PSN 0xe05637 RKey 0x1ffec2 VAddr 0x007f2cb3eae000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:04
 local address: LID 0000 QPN 0x0175 PSN 0x749ced RKey 0x1ffec2 VAddr 0x007f2cb3ebe000
......
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:05
 remote address: LID 0000 QPN 0x0193 PSN 0xb6181f RKey 0x1ffec1 VAddr 0x007efcf187c000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:05
 remote address: LID 0000 QPN 0x0194 PSN 0x582635 RKey 0x1ffec1 VAddr 0x007efcf188c000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:05
 remote address: LID 0000 QPN 0x0195 PSN 0xcef0a7 RKey 0x1ffec1 VAddr 0x007efcf189c000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:05
 remote address: LID 0000 QPN 0x0196 PSN 0x91a80a RKey 0x1ffec1 VAddr 0x007efcf18ac000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:05
---------------------------------------------------------------------------------------
 #bytes     #iterations    BW peak[Gb/sec]    BW average[Gb/sec]   MsgRate[Mpps]

 65536      160000           381.64             375.56             0.716328
---------------------------------------------------------------------------------------

3. 如何让K8s识别哪些节点支持 RDMA

仅仅宿主机“有 RDMA”还不够，调度层还需要知道：哪些节点具备 RDMA 能力。这一步常见的做法有两种：自动发现和手工打标。

3.1 用 NFD 自动发现

Node Feature Discovery 不是 RDMA 的必需组件，但它非常适合做“节点能力识别”这件事。NFD 会把节点特征写成标签，其中也包含 RDMA 相关的能力标签，例如：

  • custom-rdma.capable
  • custom-rdma.enabled

前者表示节点存在 RDMA capable 设备，后者表示运行 RDMA 所需模块已经就绪。所以，如果你的平台希望根据节点能力自动调度，或者不想手工维护大量 RDMA 标签，那么 NFD 是更合适的做法。

3.2 手工打标

如果当前阶段只是快速验证，也可以直接手工打标签，例如：

kubectl label node gpu-worker-1 rdma-node=true
kubectl label node gpu-worker-2 rdma-node=true
kubectl label node gpu-worker-3 rdma-node=true

4. 把 HCA 暴露成 Kubernetes 扩展资源

节点具备 RDMA 能力之后，下一步才进入 Kubernetes 资源接入本身。这里使用的是 k8s-rdma-shared-dev-plugin。它是一个支持 IB 和 RoCE HCA 的简单 RDMA Device Plugin，以 DaemonSet 方式运行，并通过 ConfigMap 描述设备资源池。从 Kubernetes 视角看，这个插件真正做的事情只有一件：把宿主机上的 RDMA 设备注册成 kubelet 可感知的扩展资源。

这也是后续 Pod 能通过 resources.requests/limits 申请 RDMA 能力的基础。Device Plugin 的资源会出现在节点的 capacity/allocatable 中，并通过扩展资源名暴露。部署动作本身并不复杂，常见步骤如下：

# 克隆Plugin仓库
git clone <https://github.com/Mellanox/k8s-rdma-shared-dev-plugin.git>

# 通过**Kustomize**安装RDMA Device Plugin
cd k8s-rdma-shared-dev-plugin/deployment/k8s/base
kubectl apply -k .

# 检查
kubectl get pods -n kube-system -o wide | grep rdma

# 查此节点上跟RDMA相关的“可用资源种类&数量
sudo apt install -y jq

kubectl get node gpu-worker-4 -o json | jq '.status.capacity | with_entries(select(.key|startswith("rdma/")))'

{
  "rdma/hca_ens18": "100",
  "rdma/hca_ens20": "100",
  "rdma/hca_ens21": "100",
}
  
kubectl get node gpu-worker-4 -o jsonpath='{.status.capacity}' | jq

{
  "cpu": "128",
  "ephemeral-storage": "456694032Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "mars-tech.com/gpu": "8",
  "mars-tech.com/vfio-gpu": "0",
  "memory": "1056477320Ki",
  "pods": "110",
  "rdma/hca_ens18": "100",
  "rdma/hca_ens20": "100",
  "rdma/hca_ens21": "100",
}

对 k8s-rdma-shared-dev-plugin 来说，最关键的不是“插件有没有跑起来”，而是 ConfigMap 里如何描述资源池。通常包括resourceName、resourcePrefix、rdmaHcaMax 以及 selectors，其中 selectors 又支持 ifNames、vendors、deviceIDs 等选择条件。结合实际的环境通常会**按物理网口组织 RDMA 资源池。**例如：

  • ens18np0 → rdma/hca_ens18
  • ens20np0 → rdma/hca_ens20
  • ens21np0 → rdma/hca_ens21

正如前面检查的的结果，你能在节点上查看到跟RDMA相关的“可用资源种类&数量的前提是需要对configmap有一个基本的配置，样例如下。

apiVersion: v1
kind: ConfigMap
metadata:
  name: rdma-devices
  namespace: kube-system
data:
  config.json: |
    {
      "periodicUpdateInterval": 300,
      "configList": [
        {
          "resourceName": "hca_ens18",
          "resourcePrefix": "rdma",
          "rdmaHcaMax": 100,
          "selectors": {
            "ifNames": ["ens18np0"]
          }
        },
        {
          "resourceName": "hca_ens20",
          "resourcePrefix": "rdma",
          "rdmaHcaMax": 100,
          "selectors": {
            "ifNames": ["ens20np0"]
          }
        },
        {
          "resourceName": "hca_ens21",
          "resourcePrefix": "rdma",
          "rdmaHcaMax": 100,
          "selectors": {
            "ifNames": ["ens21np0"]
          }
        }
      ]
    }

**字段解释**
- resourceName:
    - 暴露给 kubelet 的资源名的一部分，最终在节点上会看到：
        - rdma/hca_ens18
        - rdma/hca_ens20
        - rdma/hca_ens21
- resourcePrefix: "rdma"：
    - 资源前缀，和上面拼在一起形成 rdma/hca_ens18。
- rdmaHcaMax: 100：
    - 这块 HCA **最多可以被切成几个“虚拟 slice”共享给 Pod**。
    - 不是带宽，也不是 Queue Pair 数量，而只是一个“计数上限”。
    - 例如 100 就表示：最多有 100 个 Pod 可以各自申请 rdma/hca_ens18: 1。
- selectors.ifNames:
    - 按网卡名选择设备，插件会去找：
        - 和 ens18np0 绑定的那个 RDMA HCA
        - 和 ens20np0 绑定的那个 HCA
        - 和 ens21np0 绑定的那个 HCA

5. AI 工作负载如何申请 RDMA 资源

Device Plugin 部署成功之后，真正的交付点不在节点，而在工作负载。如果 Pod 不去显式申请这些扩展资源，那么节点即使已经上报了 rdma/...，对业务来说也还是“看得见但用不到”。Kubernetes 对设备类资源的使用方式是统一的：一旦设备被 Device Plugin 注册成扩展资源，Pod 就需要通过 resources.requests/limits 去申请。这和 GPU 等其他设备资源的用法是一样的。因此，一个 AI 工作负载真正使用 RDMA 的最小闭环应该是：

  • Pod 调度到具备 RDMA 能力的节点
  • Pod 在 resources.requests/limits 中声明对应的 rdma/... 资源
  • 容器内出现 /dev/infiniband、mlx5_* 等设备信息
  • 应用在运行时真正选中这些 HCA

另外，对 AI 训练/推理工作负载来说，Device Plugin 解决的是“HCA 能否进入容器并被工作负载申请”；而具体由 NCCL/UCX 使用哪块 HCA，则属于应用和通信栈的运行时选择问题。NCCL 官方也明确提供了 NCCL_IB_HCA 这类环境变量来限制或指定 HCA。

# 创建位于指定节点的rdma-pod4
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: rdma-pod4
  namespace: demo
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      { "name": "compute-a-net", "namespace": "nad" }
    ]'
spec:
  nodeName: gpu-worker-4
  containers:
  - name: tester
    image: x.x.x.x:xxxx/linux/rdma-test-ubuntu:22.04
    command: ["bash", "-c", "sleep infinity"]
    securityContext:
      capabilities:
        add: ["IPC_LOCK"]
    resources:
      limits:
        rdma/hca_ens20: "1"
      requests:
        rdma/hca_ens20: "1"
EOF

kubectl get pod rdma-pod4 -n default -o wide
kubectl exec -it rdma-pod4 -n default -- ip a

# 创建位于指定节点的rdma-pod5
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: rdma-pod5
  namespace: demo
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      { "name": "compute-a-net", "namespace": "nad" }
    ]'
spec:
  nodeName: gpu-worker-5
  containers:
  - name: tester
    image: x.x.x.x:xxxx/linux/rdma-test-ubuntu:22.04
    command: ["bash", "-c", "sleep infinity"]
    securityContext:
      capabilities:
        add: ["IPC_LOCK"]
    resources:
      limits:
        rdma/hca_ens20: "1"
      requests:
        rdma/hca_ens20: "1"
EOF

kubectl get pod rdma-pod5 -n default -o wide
kubectl exec -it rdma-pod5 -n default -- ip a

# 确保 RDMA 设备真的被 device plugin 透传进入Pod
kubectl exec -it rdma-pod4 -n demo -- bash
# 如果测试image没有安装，需要在容器里安装，才能使用测试命令。
apt-get update 
apt-get install -y ibverbs-utils
apt-get install perftest

# 容器里执行：
root@rdma-pod4:/# ulimit -l
unlimited
root@rdma-pod4:/# ls -l /dev/infiniband
total 0
crw------- 1 root root 231,  64 Nov 30 08:54 issm0
crw-rw-rw- 1 root root  10,  57 Nov 30 08:54 rdma_cm
crw------- 1 root root 231,   0 Nov 30 08:54 umad0
crw-rw-rw- 1 root root 231, 192 Nov 30 08:54 uverbs0
root@rdma-pod4:/# 

    device                 node GUID
    ------              ----------------
    mlx5_0              a088c20300f27cd6
root@rdma-pod4:/# ibv_devinfo | head -20
hca_id: mlx5_0
        transport:                      InfiniBand (0)
        fw_ver:                         28.39.3560
        node_guid:                      a088:c203:00f2:7cd6
        sys_image_guid:                 a088:c203:00f2:7cd6
        vendor_id:                      0x02c9
        vendor_part_id:                 4129
        hw_ver:                         0x0
        board_id:                       MT_0000000838
        phys_port_cnt:                  1
                port:   1
                        state:                  PORT_ACTIVE (4)
                        max_mtu:                4096 (5)
                        active_mtu:             4096 (5)
                        sm_lid:                 0
                        port_lid:               0
                        port_lmc:               0x00
                        link_layer:             Ethernet

正常情况下你应该能看到类似：
	•	/dev/infiniband/rdma_cm 存在
	•	ibv_devices 里有 mlx5_0 之类的设备
	•	ibv_devinfo 里 link_layer: Ethernet（说明是 RoCE）

6. Pod 内验证与跨节点测试

节点有资源，不等于 Pod 真能用。所以我们需要继续验证：

6.1 容器内检查设备是否可见

这一阶段重点检查，如果容器内能看到：

  • /dev/infiniband/rdma_cm
  • uverbs0
  • mlx5_0
  • link_layer: Ethernet

那就说明：

  • RDMA 设备已经进入容器
  • verbs 层工具链可用
  • 当前链路确实是 RoCE

这是“资源上报成功”之后的第一层验证。

6.2 跨节点连通性测试

ibv_rc_pingpong 解决的是：**两个 Pod 之间是否真的能通过 RDMA 建立 RC 通信。**这一步能跑通，说明容器内部设备可见、GID 选择、链路可达性这些基础条件都已经成立。

# pod4为server端
kubectl exec -it rdma-pod4 -n demo -- bash
ibv_rc_pingpong -d mlx5_0 -g 4 -p 18515

# pod5为client端
kubectl exec -it rdma-pod5 -n demo -- bash
ibv_rc_pingpong -d mlx5_0 -g 4 10.8.10.200 -p 18515

  local address:  LID 0x0000, QPN 0x000199, PSN 0x57ddb2, GID ::ffff:10.8.10.201
  remote address: LID 0x0000, QPN 0x00018e, PSN 0x645178, GID ::ffff:10.8.10.200
8192000 bytes in 0.01 seconds = 7395.17 Mbit/sec
1000 iters in 0.01 seconds = 8.86 usec/iter

6.3 带宽测试

ib_write_bw 进入的是数据面验证。它可以证明容器里的 RDMA 路径不是“能握手而已”，而是已经具备高吞吐传输能力。

**# pod4为server端**
root@rdma-pod4:/# ib_write_bw -d mlx5_0 -F --report_gbits -p 18515 -q 32 -s 65536 -x 4

**# pod5为client端**
root@rdma-pod-5:/# ib_write_bw -d mlx5_0 -F --report_gbits -p 18515 -q 32 -s 65536 -x 4 10.8.10.200
---------------------------------------------------------------------------------------
                    RDMA_Write BW Test
 Dual-port       : OFF          Device         : mlx5_0
 Number of qps   : 32           Transport type : IB
 Connection type : RC           Using SRQ      : OFF
 PCIe relax order: ON
 ibv_wr* API     : ON
 TX depth        : 128
 CQ Moderation   : 1
 Mtu             : 4096[B]
 Link type       : Ethernet
 GID index       : 4
 Max inline data : 0[B]
 rdma_cm QPs     : OFF
 Data ex. method : Ethernet
---------------------------------------------------------------------------------------
 local address: LID 0000 QPN 0x01da PSN 0xd4f36c RKey 0x1ffe00 VAddr 0x007fc8b47fe000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:201
 local address: LID 0000 QPN 0x01f0 PSN 0x4455d4 RKey 0x1ffe00 VAddr 0x007fc8b495e000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:201
 local address: LID 0000 QPN 0x01f1 PSN 0xa4516 RKey 0x1ffe00 VAddr 0x007fc8b496e000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:201
 local address: LID 0000 QPN 0x01f2 PSN 0xe9ec29 RKey 0x1ffe00 VAddr 0x007fc8b497e000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:201
 ... ...
 remote address: LID 0000 QPN 0x01ed PSN 0xb26cbf RKey 0x1ffe00 VAddr 0x007f11aa84c000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:200
 remote address: LID 0000 QPN 0x01ee PSN 0x818179 RKey 0x1ffe00 VAddr 0x007f11aa85c000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:10:200
---------------------------------------------------------------------------------------
 #bytes     #iterations    BW peak[Gb/sec]    BW average[Gb/sec]   MsgRate[Mpps]
 65536      160000           380.18             364.42             0.695085
---------------------------------------------------------------------------------------

6.4 写延迟测试

**server端** 
root@rdma-pod4:/# ib_write_lat -d mlx5_0 -i 1 -x 4

---------------------------------------------------------------------------------------
                    RDMA_Write Latency Test
 Dual-port       : OFF          Device         : mlx5_0
 Number of qps   : 1            Transport type : IB
 Connection type : RC           Using SRQ      : OFF
 PCIe relax order: OFF
 ibv_wr* API     : ON
 TX depth        : 1
 Mtu             : 4096[B]
 Link type       : Ethernet
 GID index       : 4
 Max inline data : 220[B]
 rdma_cm QPs     : OFF
 Data ex. method : Ethernet
---------------------------------------------------------------------------------------
 local address: LID 0000 QPN 0x191d PSN 0xd5f9fa RKey 0x1fd493 VAddr 0x0055daef480000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:20:71
 remote address: LID 0000 QPN 0x191c PSN 0x9b316 RKey 0x1f40ff VAddr 0x005622361eb000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:20:71
---------------------------------------------------------------------------------------
 #bytes #iterations    t_min[usec]    t_max[usec]  t_typical[usec]    t_avg[usec]    t_stdev[usec]   99% percentile[usec]   99.9% percentile[usec] 
Conflicting CPU frequency values detected: 2700.000000 != 1000.869000. CPU Frequency is not max.
Conflicting CPU frequency values detected: 2700.000000 != 1000.000000. CPU Frequency is not max.
 2       1000          1.39           3.81         1.50                1.50             0.05            1.61        3.81   
---------------------------------------------------------------------------------------

**client端**
root@rdma-pod-5:/# ib_write_lat -d mlx5_0 -i 1 -x 4 10.8.20.71
---------------------------------------------------------------------------------------
                    RDMA_Write Latency Test
 Dual-port       : OFF          Device         : mlx5_0
 Number of qps   : 1            Transport type : IB
 Connection type : RC           Using SRQ      : OFF
 PCIe relax order: OFF
 ibv_wr* API     : ON
 TX depth        : 1
 Mtu             : 4096[B]
 Link type       : Ethernet
 GID index       : 4
 Max inline data : 220[B]
 rdma_cm QPs     : OFF
 Data ex. method : Ethernet
---------------------------------------------------------------------------------------
 local address: LID 0000 QPN 0x280d PSN 0x8ad71e RKey 0x1f09c8 VAddr 0x0055a98fd11000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:20:72
 remote address: LID 0000 QPN 0x191e PSN 0x72e8e0 RKey 0x1fd493 VAddr 0x005603e30dc000
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:08:20:71
---------------------------------------------------------------------------------------
 #bytes #iterations    t_min[usec]    t_max[usec]  t_typical[usec]    t_avg[usec]    t_stdev[usec]   99% percentile[usec]   99.9% percentile[usec] 
Conflicting CPU frequency values detected: 2700.000000 != 985.928000. CPU Frequency is not max.
Conflicting CPU frequency values detected: 2700.001000 != 975.996000. CPU Frequency is not max.
 2       1000          2.57           3.48         2.59                2.60             0.03            2.66                    3.48   
---------------------------------------------------------------------------------------

如果说前面的 Multus 章节解决的是“Pod 是否需要额外网络接口”，那么这一小节解决的就是另一件事：Kubernetes 如何把宿主机上的 RoCE / RDMA 设备，从节点硬件，变成 AI 工作负载可以申请和使用的集群资源。

Leave a Reply