网络架构与 RDMA——让 GPU 之间的通信更快 / Network Architecture and RDMA for Faster GPU Communication
📅 创建时间：2026-06-03 🏷️ 标签：#AI-Infra #集群侧 #网络 #RDMA #RoCE #InfiniBand #网络优化 📚 前置知识：[[01-gpu-cluster-hardware]]（GPU 集群硬件架构）[[../training-infra/04-mixed-precision]]（NCCL 通信基础） 📚 相关知识：[[07-nccl-cluster-networking]]（NCCL 集群组网）[[04-job-scheduling]]（作业调度）
场景：跨节点 AllReduce 从 50ms 降到了 5ms——只改了一个网络配置
┌─────────────────────────────────────────────────────────────┐
│ │
│ ML 工程师的困惑： │
│ │
│ 同样 64 节点、同样 512 张卡、同样 TP=8/DP=64 配置： │
│ │
│ 集群 A：AllReduce 延迟 50ms，MFU 35% │
│ 集群 B：AllReduce 延迟 5ms，MFU 58% │
│ │
│ 差异原因： │
│ → 两集群 GPU 完全相同（H100） │
│ → 两集群作业配置完全相同 │
│ → 唯一差异：网络配置 │
│ │
│ 集群 A：RoCE v2，但没有开启 PFC（Priority Flow Control） │
│ 集群 B：RoCE v2，开启了 PFC，配置了 DCQCN 拥塞控制 │
│ │
│ 教训：网络配置的差距，可以在硬件相同的情况下 │
│ 造成 2-3 倍的性能差异。 │
│ │
└─────────────────────────────────────────────────────────────┘第1节：为什么 GPU 集群需要 RDMA
传统 TCP/IP 通信的瓶颈
┌─────────────────────────────────────────────────────────────┐
│ 传统 TCP/IP 通信 vs RDMA │
├─────────────────────────────────────────────────────────────┤
│ │
│ 传统 TCP/IP（CPU 参与模式）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GPU A HBM ──DMA──► CPU A 内存 ──Kernel──► 网卡 │ │
│ │ ↑ ↑ │ │
│ │ CPU参与 Kernel参与 │ │
│ │ （多次内存拷贝） （协议栈处理） │ │
│ │ │ │ │
│ │ 网卡 ──wire──► 网卡 │ │
│ │ │ │ │
│ │ CPU B 内存 ──Kernel──► GPU B HBM │ │
│ │ ↑ ↑ │ │
│ │ CPU参与 CPU参与 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 延迟拆解（跨节点 GPU 到 GPU）： │
│ → HBM → CPU 内存：~1 μs │
│ → CPU 内存 → 网卡（DMA）：~2 μs │
│ → TCP/IP 协议栈处理：~5-10 μs（CPU 中断 + 内核拷贝） │
│ → 网络传输：~2 μs（IB/RoCE 200 Gbps） │
│ → 合计：~10-15 μs │
│ │
│ RDMA（绕过 CPU 模式）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GPU A HBM ──────DMA───────► 网卡 ──wire──► 网卡 │ │
│ │ GPU B HBM ◄─────DMA───────► (直接访问 HBM) │ │
│ │ ↑ │ │
│ │ 只有 DMA 参与，无 CPU 介入 │ │
│ └─────────────────────────────────────────────────────┘ │
│ 延迟：~3-5 μs（减少 60-70%） │
│ │
└─────────────────────────────────────────────────────────────┘RDMA 的两种主流实现
┌─────────────────────────────────────────────────────────────┐
│ InfiniBand vs RoCE v2 │
├─────────────────────────────────────────────────────────────┤
│ │
│ InfiniBand（IB）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ → 自成体系的专用网络（不是以太网） │ │
│ │ → 物理层 + 传输层都是 IB 自有协议 │ │
│ │ → 天然无损（IB 传输层保证） │ │
│ │ → 需要独立布线（光纤 + IB 交换机） │ │
│ │ → 典型设备：Mellanox QM8700 系列 │ │
│ │ → 成本：高（但性能最优） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ RoCE v2（RDMA over Converged Ethernet）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ → 运行在标准以太网上（复用现有网络基础设施） │ │
│ │ → RDMA 在 UDP 之上（RoCE v2） │ │
│ │ → 需要无损以太网（否则丢包导致 RDMA 性能下降） │ │
│ │ → 依赖 DCQCN + PFC 机制保证无损 │ │
│ │ → 成本：中（复用以太网交换机） │ │
│ │ → 典型设备：支持 RoCE 的 Cisco/Mellanox 以太网交换机│ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 选择建议： │
│ → 超大规模训练集群（1000+ GPU）：IB（性能优先） │
│ → 企业级混合云（100-500 GPU）：RoCE v2（成本优先） │
│ → 科研 HPC（多租户，预算有限）：RoCE v2 │
│ │
└─────────────────────────────────────────────────────────────┘第2节：RoCE v2 的无损网络机制
PFC（Priority Flow Control）
┌─────────────────────────────────────────────────────────────┐
│ PFC：链路层的拥塞控制 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 问题：以太网是"尽力而为"的网络，会丢包 │
│ → RDMA 对丢包极其敏感（重传代价极高） │
│ → 必须让以太网变成"无损"网络 │
│ │
│ PFC 工作原理（802.1Qbb）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Switch │ │
│ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │
│ │ │Pri 0 │ │Pri 1 │ │Pri 2 │ │Pri 3 │ ... │ │
│ │ │ (存储)│ │ (默认)│ │(RoCE)│ │ (其他)│ │ │
│ │ └──────┘ └──────┘ └──────┘ └──────┘ │ │
│ │ ↑ ↑ │ │
│ │ PAUSE XON │ │
│ │ (拥塞时) (恢复时) │ │
│ │ │ │ │ │
│ │ └────────────┴───── 逐跳控制 ──────────────────── │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ PFC 工作流程： │
│ 1. Switch Port A 接收到太多 RoCE 流量（队列积压） │
│ 2. Switch 发送 PFC PAUSE 帧给上游设备（Pause 特定优先级）│
│ 3. 上游设备暂停发送，队列消化 │
│ 4. 队列清空后，Switch 发送 PFC XON，上游恢复发送 │
│ │
│ ⚠️ PFC 的问题（Head-of-Line Blocking）： │
│ → Pause 一个优先级时，该链路上所有流量都被暂停 │
│ → 可能导致其他流量的不公平等待 │
│ → 配置不当会引发 PFC 风暴（PFC Storm）——整个网络冻结 │
│ │
└─────────────────────────────────────────────────────────────┘DCQCN（Data Center Quantized Congestion Notification）
┌─────────────────────────────────────────────────────────────┐
│ DCQCN：端到端的拥塞控制 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 问题：PFC 只在链路层工作，跨交换机丢包仍然可能发生 │
│ → 需要端到端（发送端 → 接收端 → 交换机）的拥塞控制 │
│ │
│ DCQCN 三方协作： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ [发送端] [交换机] [接收端] │ │
│ │ │ │
│ │ │ │ │ │ │
│ │ │───RoCE 数据────►│ │ │ │
│ │ │ │ Congestion │ │ │
│ │ │ │ Notification │ │ │
│ │ │◄─────────────────│ Packet (CNP) │ │ │
│ │ │ │ │ │ │
│ │ │ │ │──RoCE ACK─►│ │
│ │ │ │ │ │ │
│ │ │◄─────────────────┴──────────────────┘ │ │
│ │ │ CNP 到达，速率降低 │ │
│ │ │ │ │ │
│ │ │────RoCE 数据（降低速率）──►│ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ DCQCN 算法： │
│ → 交换机检测到 ECN 标记（ Explicit Congestion Notification）│
│ → 交换机发送 CNP 给发送端 │
│ → 发送端按 DCQCN 算法降低发送速率 │
│ → 随时间推移逐步恢复速率（探测瓶颈是否解除） │
│ │
│ 关键参数（需要调优）： │
│ → DCQCN alpha（速率恢复因子）：太大 → 震荡；太小 → 恢复慢│
│ → DCQCN g（平滑因子）：控制速率变化的速度 │
│ → ECN 阈值：触发 CNP 的队列深度 │
│ │
└─────────────────────────────────────────────────────────────┘RoCE v2 完整配置检查清单
┌─────────────────────────────────────────────────────────────┐
│ RoCE v2 生产环境配置检查清单 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 交换机侧配置： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ # DCBX（Data Center Bridging Exchange） │ │
│ │ dcbx mode ieee │ │
│ │ dcb app-pfc control:0 # 启用 PFC │ │
│ │ dcb app-pfc traffic:2 # RoCE 使用 Priority 2 │ │
│ │ dcb app-cee ets:control:0,data:2 # 带宽分配 │ │
│ │ # ECN（Explicit Congestion Notification） │ │
│ │ switchportCongestion [port] marking:enabled │ │
│ │ switchportCongestion [port] min:10 max:50 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 2. 网卡侧配置（mst追星）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ # 查看 Mellanox 网卡状态 │ │
│ │ $ mst status │ │
│ │ $ mlxconfig -d mlx5_0 q | grep RoCE │ │
│ │ │ │
│ │ # 启用 RoCE v2（通常是默认的） │ │
│ │ $ mlxconfig -d mlx5_0 s RoCE=2 │ │
│ │ │ │
│ │ # 设置 RoCE 优先级（对应交换机的 Priority 2） │ │
│ │ $ mlxconfig -d mlx5_0 s ROCE_DSCP_QOS_MODE=2 │ │
│ │ │ │
│ │ # 验证配置 │ │
│ │ $ mlxconfig -d mlx5_0 q | grep RoCE │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 3. 验证无损网络： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ # 测试 PFC 是否生效 │ │
│ │ $ ibdev2netdev │ │
│ │ mlx5_0: eth0 ← 发送端 │ │
│ │ │ │
│ │ # 在交换机侧抓包，检查 ECN 标记 │ │
│ │ $ tcpdump -i eth0 'ip[1] & 0x03 == 0x03' │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘第3节：GPUDirect RDMA 与存储网络
GPUDirect RDMA 的三层实现
┌─────────────────────────────────────────────────────────────┐
│ GPUDirect RDMA 的三个层次 │
├─────────────────────────────────────────────────────────────┤
│ │
│ L1：GPUDirect RDMA（网卡 ↔ GPU） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GPU HBM ←────RDMA────► 网卡 ←────wire────► 网卡 │ │
│ │ 无需 CPU 介入，网卡直接从 GPU 内存收发数据 │ │
│ │ 适用：跨节点 GPU 通信（NCCL AllReduce） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ L2：GPUDirect Storage（GPU ↔ 存储） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GPU HBM ←──DMA──► 网卡 ←──RDMA──► 存储服务器 │ │
│ │ Checkpoint 直接从 GPU 写入存储，无需 CPU 中转 │ │
│ │ 适用：大模型 Checkpoint（TB 级数据） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ L3：GPUDirect Async（GPU ↔ GPU，跨节点） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GPU A ←───NVLink────► IB 网卡 A │ │
│ │ ←────wire────► │ │
│ │ GPU B ←───NVLink────► IB 网卡 B │ │
│ │ GPU 之间通过 NVLink + IB 形成端到端 RDMA │ │
│ │ 适用：超大规模 NCCL 通信 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 验证 GPUDirect RDMA 是否工作： │
│ $ nvidia-smi nvlink -s # 查看 NVLink 状态 │
│ $ ibstatus mlx5_0 # 查看 IB 网卡状态 │
│ $ nvidia-smi topo -m # 查看 GPU-NIC 拓扑关系 │
│ │
└─────────────────────────────────────────────────────────────┘GPUDirect Storage：Checkpoint 加速
┌─────────────────────────────────────────────────────────────┐
│ GPUDirect Storage 对 Checkpoint 的加速 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 传统 Checkpoint 写入（CPU 中转）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GPU HBM ──DMA──► CPU 内存 ──TCP──► 存储服务器 │ │
│ │ ↑ ↑ │ │
│ │ 慢速 CPU 瓶颈 │ │
│ │ 405B 模型 Checkpoint：~15 分钟（传统方式） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ GPUDirect Storage（直接写入）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GPU HBM ────RDMA───► 网卡 ──wire──► 存储服务器 │ │
│ │ ↑ │ │
│ │ CPU 不参与 │ │
│ │ 405B 模型 Checkpoint：~2-3 分钟（GPUDirect Storage） │ │
│ │ 加速：5-7x │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 前提条件： │
│ → NVIDIA BlueField-2/3 DPU（带 GPUDirect Storage 固件） │
│ → 存储服务器支持 RDMA（S3 with RDMA / Lustre with RDMA） │
│ → 启用：export NCCL_NET_GDR_LEVEL=SYS（或 PIX） │
│ │
│ ⚠️ 注意： │
│ → 需要 BlueField DPU，成本较高 │
│ → 存储网络和计算网络需要分离（或 QoS 隔离） │
│ → S3 over RDMA 需要特定存储后端 │
│ │
└─────────────────────────────────────────────────────────────┘第4节：网络拓扑设计
Fat-Tree vs Dragonfly 对比
┌─────────────────────────────────────────────────────────────┐
│ 数据中心网络拓扑对比 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Fat-Tree（传统数据中心拓扑）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ [Core Switch] │ │
│ │ / \ │ │
│ │ [Agg 1] [Agg 2] │ │
│ │ / \ / \ │ │
│ │ [ToR1] [ToR2] [ToR3] [ToR4] │ │
│ │ | | | | │ │
│ │ Node Node Node Node │ │
│ │ │ │
│ │ 特点：任意两点间有多条路径，带宽保证好 │ │
│ │ 缺点：交换机层数多，延迟较高 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Dragonfly（现代 HPC 拓扑）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ┌─────┐ │ │
│ │ ────►│Group│◄──── Global Link ───────── │ │
│ │ │ A │──── (高带宽光纤) │ │ │
│ │ ────►└─────┘◄─────────────────────┘ │ │
│ │ │ │ │
│ │ ┌────┴────┐ │ │
│ │ │Router Hub│ Group 内全互联 │ │
│ │ └────┬────┘ │ │
│ │ │ │ │
│ │ [Node × p] × [a] │ │
│ │ │ │
│ │ 特点：全局链路少，延迟低（全局跳转 ≤ 2 跳） │ │
│ │ 缺点：全局链路是瓶颈，部分通信必须走全局链路 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 集群网络选择： │
│ → 通用数据中心（多种业务混合）：Fat-Tree │
│ → 专注 HPC/AI 训练（带宽敏感）：Dragonfly │
│ │
└─────────────────────────────────────────────────────────────┘网络 QoS 配置
┌─────────────────────────────────────────────────────────────┐
│ GPU 集群网络 QoS 配置 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 问题：集群中多种流量竞争网络带宽 │
│ → NCCL 训练流量（高优先级，低延迟） │
│ → Checkpoint 写入流量（高吞吐，可延迟） │
│ → 管理/监控流量（低带宽，不紧急） │
│ → 用户数据传输（中等） │
│ │
│ 优先级划分： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Priority 0：管理/SSH/监控（最高优先级，带宽保证） │ │
│ │ Priority 1：NCCL 训练流量（低延迟，带宽保证） │ │
│ │ Priority 2：RoCE 控制面（CNP/PFC，重要） │ │
│ │ Priority 3：Checkpoint/存储流量（尽力而为） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 交换机 QoS 配置示例（华为）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ qos queue 0 pq weight 10 # 管理流量，保证 10% │ │
│ │ qos queue 1 pq weight 40 # NCCL 流量，保证 40% │ │
│ │ qos queue 2 pq weight 10 # RoCE 控制面 │ │
│ │ qos queue 3 wfq weight 40 # Checkpoint，尽量用剩余│ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 效果： │
│ → 即使 Checkpoint 打满带宽，NCCL 训练流量仍有保障 │
│ → 训练 MFU 不会因 Checkpoint 写入而下降 │
│ │
└─────────────────────────────────────────────────────────────┘第5节：网络故障排查
网络问题诊断流程
┌─────────────────────────────────────────────────────────────┐
│ GPU 集群网络故障排查流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Step 1：物理层检查 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ # 检查 IB 网卡状态 │ │
│ │ $ ibstat mlx5_0 │ │
│ │ # 预期：PortState: Active, PortPhysicalState: LinkUp │ │
│ │ │ │
│ │ # 检查光模块和线缆 │ │
│ │ $ iblinkinfo │ │
│ │ # 预期：所有端口正常，没有 Down 的链路 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Step 2：RDMA 基础验证 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ # 基础连通性测试 │ │
│ │ $ ibping -S 0 -C 0 # Server 端 │ │
│ │ $ ibping -G 0 -C 1 # Client 端，指定目标 GUID │ │
│ │ # 预期：100% 丢包率 = 连通性有问题 │ │
│ │ │ │
│ │ # 带宽基准测试 │ │
│ │ $ ib_write_bw -d mlx5_0 # 单向带宽测试 │ │
│ │ $ ib_send_bw # 延迟测试 │ │
│ │ # 预期：接近物理带宽上限（200 Gbps × 2 = 50 GB/s）│ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Step 3：RoCE 特定检查 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ # 检查 ECN 是否启用（交换机侧） │ │
│ │ $ show interface Ethernet X/Y congestion-control │ │
│ │ # 预期：ECN enabled │ │
│ │ │ │
│ │ # 检查 PFC 是否启用 │ │
│ │ $ show interface Ethernet X/Y priority-flow-control│ │
│ │ # 预期：Priority 2 enabled（RoCE 流量） │ │
│ │ │ │
│ │ # 检查 CNP 是否在发送（活跃拥塞控制） │ │
│ │ $ perfquery -r -G mlx5_0 0 # 查看 CNP 计数器 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Step 4：NCCL 级别验证（参考 [[07-nccl-cluster-networking]]）│
│ ┌─────────────────────────────────────────────────────┐ │
│ │ $ NCCL_DEBUG=INFO python -c "import torch; ..." │ │
│ │ # 检查 NCCL 初始化时是否识别到 IB │ │
│ │ # 预期：NCCL INFO ... NET/IB ... found 4 transports │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘常见 RoCE 问题与解决
┌─────────────────────────────────────────────────────────────┐
│ RoCE 常见问题速查表 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 问题：NCCL 初始化失败，显示 NET/IB not found │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 原因：IB/RoCE 驱动未安装或版本不匹配 │ │
│ │ 解决：安装 MLNX_OFED（OFED for NVIDIA网络） │ │
│ │ $ wget package.rpm && rpm -ivh MLNX_OFED*.rpm │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 问题：RoCE 带宽远低于预期（应该 50 GB/s，只有 10 GB/s） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 原因 1：PFC 未启用，以太网丢包严重 │ │
│ │ 原因 2：ECN 阈值设置不当，CNP 没有触发 │ │
│ │ 原因 3：DCQCN 参数配置错误（恢复过快或过慢） │ │
│ │ 解决：检查交换机的 PFC/ECN 配置，对比参考配置 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 问题：GPUDirect RDMA 不生效 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 原因 1：GPU 和网卡的 PCIe 拓扑不对（不在同一 switch）│ │
│ │ 解决：检查 nvidia-smi topo -m，确保 GPU-IB 在 PIX/PHB│ │
│ │ 原因 2：NCCL_NET_GDR_LEVEL 未设置 │ │
│ │ 解决：export NCCL_NET_GDR_LEVEL=PIX │ │
│ │ 原因 3：BlueField 固件版本不兼容 │ │
│ │ 解决：升级 BlueField DPU 固件 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 问题：NCCL timeout（P2P 连接失败） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 原因：防火墙阻止了 IB 端口 │ │
│ │ 解决：检查 iptables / ufw，开放 IB 端口 │ │
│ │ $ iptables -L # 查找 DROP 规则 │ │
│ │ $ ibportstate -C 0 <lid> <port> # 检查端口状态 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘升华：网络是集群的"血管"
┌─────────────────────────────────────────────────────────────┐
│ 网络工程的哲学 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 网络是最容易被忽视的瓶颈： │
│ → GPU 和存储的升级肉眼可见，网络升级没人注意 │
│ → 但网络带宽不足可以让所有 GPU 闲置等数据 │
│ │
│ 2. RoCE 的配置是一套系统： │
│ → PFC + DCQCN + ECN + QoS 缺一不可 │
│ → 任何一个环节配置错误都会导致性能下降或网络故障 │
│ → 配置错误可能引发 PFC Storm——整个网络瘫痪 │
│ │
│ 3. GPUDirect 是网络与计算的深度融合： │
│ → GPU 显存直接和网卡通信，绕过 CPU │
│ → 这是未来趋势：计算和网络越来越难以分离 │
│ │
│ 一句话总结： │
│ GPU 集群的网络就像人体的血管： │
│ 平时感觉不到，一旦堵塞，全身上下都会出问题。 │
│ 网络配置正确，是所有上层应用（NCCL、存储）正常工作的前提。 │
│ │
└─────────────────────────────────────────────────────────────┘"AI 可查 vs 必须理解"清单
AI 可查：
✅ Mellanox OFED 驱动安装的具体步骤
✅ 特定型号交换机的 PFC/ECN 配置命令
✅ DCQCN 算法 alpha 和 g 参数的数学推导
✅ BlueField DPU 固件升级的具体步骤
必须理解：
🔴 TCP/IP vs RDMA 的性能差异（CPU 介入 vs DMA 直接访问）
🔴 InfiniBand vs RoCE v2 的核心差异（无损保证方式）
🔴 PFC 和 DCQCN 的协作机制（链路层 vs 端到端）
🔴 GPUDirect RDMA 的三个层次（通信 / 存储 / 异步）
🔴 RoCE 生产环境的配置检查清单（PFC + ECN + QoS）
🔴 为什么"只改了一个网络配置"就能让 MFU 提升 20%学习状态：🟡 开始学习