文档(金鹏): 2026-08-06 章节 48 篇文章摘要归档
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
This commit is contained in:
@@ -0,0 +1,766 @@
|
||||
# 【大模型基础设施工程】04：互联与网络——NVLink、InfiniBand、RoCE 与国产替代
|
||||
|
||||
> **来源**：土法炼钢兴趣小组的算法知识备份
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-04-22
|
||||
> **原文链接**：https://quant67.com/post/llm-infra/04-interconnect/04-interconnect.html
|
||||
|
||||
---
|
||||
|
||||
> 算力决定上限，__互联决定利用率__。
|
||||
>
|
||||
> —— 做过万卡训练的人都懂这句话
|
||||
|
||||
在 2023 年之前，很多训练团队把精力都放在"怎么把 GPU 堆多"。到了 2024—2026 年，业界共识变了：__GPU 本身已经不是瓶颈，网络才是__。同样一批 H100，接在 3.2 Tb/s 无损 RDMA 上，训练一个 70B 模型的 MFU（Model FLOPs Utilization）能做到 50%+；接在普通 100G 以太网上，可能只有 20%，甚至跑着跑着因为 PFC 死锁挂掉。
|
||||
|
||||
这一篇就围绕__互联网络__展开，分两条主线：
|
||||
|
||||
- __Scale-up__：机内、柜内，极致带宽、极低延迟，目标是"把一堆 GPU 变成一台巨型 GPU"。代表技术：NVLink / NVSwitch / NVL72 / Infinity Fabric / HCCS / CXL。
|
||||
- __Scale-out__：跨机、跨 Pod，横向扩展到万卡、十万卡。代表技术：InfiniBand、RoCEv2、UEC、Fat-Tree、Rail-optimized、Dragonfly。
|
||||
|
||||
我们会从物理层聊到拓扑层，从 AllReduce 聊到故障域，最后给出训练工程师视角下"集合通信打不满怎么办"的排查清单，以及 `nccl-tests` 的实操。
|
||||
|
||||
## 一、为什么 LLM 训练对网络这么敏感
|
||||
|
||||
### 1.1 万卡训练的流量特征
|
||||
|
||||
传统 HPC 里，通信占比高的是 CFD、分子动力学；传统数据中心里，流量是典型的 "南北向为主 + 东西向微服务"。__LLM 训练不是这两者__，它的流量画像非常独特：
|
||||
|
||||
1. __周期性、同步、大包、突发__：一个 step 内所有 GPU 同时发起 AllReduce / AllGather / ReduceScatter，瞬时把链路打满，下一秒又全部静默。
|
||||
2. __Bandwidth-bound__：梯度、激活、KV 的传输都是几 MB 到几 GB 的大块，对带宽敏感远大于对延迟敏感（小消息 latency 影响流水线气泡，但绝大多数算子是带宽受限）。
|
||||
3. __尾延迟决定全局__：一个 step 的结束时间 = `max(所有 rank 的完成时间)`。任何一条慢链路都拖慢整体，这就是万卡训练里常说的 __"straggler 问题"__。
|
||||
4. __长连接 + 零丢包容忍__：一次 AllReduce 丢一个包触发重传，整个 step 就塌了。所以 RDMA 网络必须是__无损__或__近似无损__的。
|
||||
|
||||
### 1.2 一次 step 里的通信量
|
||||
|
||||
以 GPT-3 175B、TP=8、PP=8、DP=128（总 8192 卡）为例，粗算一个 step 的通信量：
|
||||
|
||||
- __TP AllReduce__：Attention / MLP 后每层一次，175B 模型约 96 层，每次 AllReduce 的张量大小 ~ `batch × seq × hidden × 2B`（fp16），单次几十 MB。TP 发生在__机内 NVLink__。
|
||||
- __PP 点对点__：每个 micro-batch 发送 activation，几十 MB，跨机走 __RDMA__。
|
||||
- __DP AllReduce__：梯度规模 ~ 350 GB（fp16），ZeRO-1 下切成 DP 组；跨机跨 rail，走 __RDMA AllReduce__。
|
||||
|
||||
所以训练一次 step，机内 NVLink 跑 TB 级别流量，机间 RDMA 也跑几百 GB。任何一个维度"瘸腿"，利用率立刻掉一大截。
|
||||
|
||||
## 二、Scale-up：机内与柜内互联
|
||||
|
||||
机内互联的目标很朴素：__越像一块 GPU 越好__。这意味着：高带宽、低延迟、统一地址空间、原生支持 P2P 和集合通信硬件加速。
|
||||
|
||||
### 2.1 PCIe：通用但不够用
|
||||
|
||||
PCIe 是 CPU—GPU、GPU—NIC 之间绕不开的通道。它的带宽演进：
|
||||
|
||||
| 版本 | 单 lane 带宽 | x16 双向 | 落地年份 | 代表平台 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| PCIe 4.0 | 16 GT/s | 64 GB/s | 2017 | A100、Milan |
|
||||
| PCIe 5.0 | 32 GT/s | 128 GB/s | 2022 | H100、SPR、Genoa |
|
||||
| PCIe 6.0 | 64 GT/s（PAM4） | 256 GB/s | 2024—2025 | B200、Turin、GH200 |
|
||||
| PCIe 7.0 | 128 GT/s | 512 GB/s | 2027（规划） | — |
|
||||
|
||||
问题在于：__PCIe 5.0 x16 才 64 GB/s 单向__，而 H100 单卡 HBM 带宽已经 3 TB/s，NVLink 4 是 450 GB/s 单向。让 GPU 之间只走 PCIe，等于让法拉利走乡间小路。所以训练场景里，PCIe 主要用来接 CPU、NIC、NVMe，GPU 之间一定要走 NVLink / xGMI / HCCS 这种"专用高速通道"。
|
||||
|
||||
### 2.2 NVLink 与 NVSwitch：N 卡训练的护城河
|
||||
|
||||
NVLink 是 NVIDIA 自研的 GPU 间互联协议，和 PCIe 并行存在。演进如下：
|
||||
|
||||
| 代 | 首发 GPU | 单 link 双向 | 每 GPU 总带宽 | 关键特性 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| NVLink 1 | P100（2016） | 40 GB/s | 160 GB/s | 首次替代 PCIe P2P |
|
||||
| NVLink 2 | V100（2017） | 50 GB/s | 300 GB/s | 引入 NVSwitch（DGX-2） |
|
||||
| NVLink 3 | A100（2020） | 50 GB/s | 600 GB/s | 12 links |
|
||||
| NVLink 4 | H100（2022） | 50 GB/s | 900 GB/s | 18 links，SHARP in-network |
|
||||
| NVLink 5 | B200（2024） | 100 GB/s | 1.8 TB/s | 18 links × 100G PAM4 |
|
||||
|
||||
__NVSwitch__ 是把多块 GPU 连成 all-to-all 交换网的芯片。早期 DGX-2（V100 × 16）靠 6 颗 NVSwitch 做全连接；H100 HGX 8 卡靠 4 颗 NVSwitch v3；到了 B200，NVSwitch v4 芯片带宽 7.2 TB/s。
|
||||
|
||||
#### GB200 NVL72：把一个机柜变成一块 GPU
|
||||
|
||||
这是 2024—2026 年最重要的__产品级__变化。NVL72 的结构：
|
||||
|
||||
- 18 个 compute tray，每个 tray 放 2 颗 Grace CPU + 4 颗 B200 GPU（共 72 GPU + 36 CPU）
|
||||
- 9 个 NVSwitch tray，每个 tray 2 颗 NVSwitch v4
|
||||
- 所有 72 颗 GPU 之间__全 NVLink 互联__，任意两卡 P2P 带宽 1.8 TB/s
|
||||
- 铜缆背板（copper cable cartridge），省掉 retimer 和光模块
|
||||
- 整柜 120 kW，液冷必备
|
||||
|
||||
业务价值：__72 GPU 的 TP / EP 都能塞进一个 NVLink domain__。以前 TP 只能 8，现在可以 TP=16 甚至 TP=72；MoE 的 EP 也可以一柜内搞定，跨柜只走 DP 和 PP。训练 DeepSeek-R1 这种 671B MoE 模型，NVL72 几乎是天选硬件。
|
||||
|
||||
```
|
||||
NVL72 机柜示意（简化）
|
||||
┌──────────────────────────────────────────┐
|
||||
│ Compute Tray × 18（每 tray 4 × B200） │
|
||||
│ ┌───┐ ┌───┐ ┌───┐ ... ┌───┐ │
|
||||
│ │ G │ │ G │ │ G │ │ G │ │
|
||||
│ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ │
|
||||
│ └─────┴─────┴─────────┘ │
|
||||
│ NVLink5 Spine（Copper Cartridge） │
|
||||
│ ┌──────────────────────────────┐ │
|
||||
│ │ NVSwitch Tray × 9（18 芯片） │ │
|
||||
│ └──────────────────────────────┘ │
|
||||
└──────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
对应的 SVG 示意图见文末。
|
||||
|
||||
### 2.3 AMD Infinity Fabric（xGMI）
|
||||
|
||||
AMD MI300X / MI325X / MI350X 用的是 __Infinity Fabric__（IF），也叫 xGMI（外部 GMI）。MI300X 单卡 7 条 IF link，每条 128 GB/s 双向，合计 ~ 896 GB/s，和 H100 一个量级。
|
||||
|
||||
MI300X 8 卡平台是全 mesh 互联（每卡到其他 7 卡各一条 link），没有独立 switch 芯片。好处是简单、低功耗；坏处是__扩不到 72 卡那种 NVL 级别__。AMD 在 MI355 / MI400 代推出类似 NVL 的 __UALink__（Ultra Accelerator Link）联盟标准，对标 NVLink。
|
||||
|
||||
### 2.4 华为昇腾 HCCS
|
||||
|
||||
华为 Atlas 900 / CloudMatrix 里，昇腾 910B / 910C 之间走 __HCCS（Huawei Cache Coherent System）__：
|
||||
|
||||
- 910B：每卡 7 条 HCCS，每条 ~ 56 GB/s，合计 ~ 392 GB/s（单向）
|
||||
- 910C：带宽翻倍
|
||||
- 单节点 8 卡全 mesh
|
||||
- 跨节点经 __HCCN__（华为高速 RDMA 网卡），逻辑上把集合通信交给 HCCL 库（对标 NCCL）
|
||||
|
||||
2024 年华为发布 __CloudMatrix 384__：一个超节点 384 颗昇腾 910C，全高速互联，对标 NVL72 但卡数更多。代价是功耗巨大，整柜 500+ kW，基本是"液冷 + 自建数据中心"的配置。
|
||||
|
||||
### 2.5 CXL：内存池化对 LLM 的意义
|
||||
|
||||
CXL（Compute Express Link）跑在 PCIe PHY 上，三种语义：
|
||||
|
||||
- __CXL.io__：对齐 PCIe
|
||||
- __CXL.cache__：设备缓存宿主机内存
|
||||
- __CXL.mem__：宿主机访问设备内存（内存扩展 / 池化）
|
||||
|
||||
对 LLM 的直接意义有限但值得关注：
|
||||
|
||||
1. __推理侧 KV cache 溢出__：CXL memory 作为 HBM/DRAM 之下的第三层，用来装长上下文的 KV。
|
||||
2. __训练侧 optimizer state offload__：ZeRO-Infinity 已经在用 NVMe，CXL 内存比 NVMe 快两个数量级，未来可能替代部分 offload 场景。
|
||||
3. __CXL 3.0 fabric__：支持 switch 和多主机共享内存池，长期看有"训练数据随取随用"的想象空间。
|
||||
|
||||
但 2026 年实际生产里，CXL 对 LLM 还是__次要角色__，因为 HBM 自己在涨容量（HBM3e 192 GB、HBM4 288 GB），短期不缺内存。
|
||||
|
||||
## 三、Scale-out：机间互联
|
||||
|
||||
Scale-up 终点是一柜（NVL72 / CM384），再往外就必须 scale-out。机间互联的两大流派：__InfiniBand__ 与 __RoCEv2__。
|
||||
|
||||
### 3.1 InfiniBand：训练网络的"黄金标准"
|
||||
|
||||
InfiniBand 自带 lossless、credit-based flow control、硬件 RDMA，几乎为 HPC 而生。速率演进：
|
||||
|
||||
| 代 | 速率 | 带宽（4X） | 年份 |
|
||||
| --- | --- | --- | --- |
|
||||
| FDR | 14 Gbps | 56 Gb/s | 2011 |
|
||||
| EDR | 25 Gbps | 100 Gb/s | 2014 |
|
||||
| HDR | 50 Gbps | 200 Gb/s | 2018 |
|
||||
| NDR | 100 Gbps | 400 Gb/s | 2022 |
|
||||
| XDR | 200 Gbps | 800 Gb/s | 2024—2025 |
|
||||
| GDR | 400 Gbps | 1.6 Tb/s | 2027 规划 |
|
||||
|
||||
NVIDIA 通过收购 Mellanox，把 IB 生态完全握在手里：__ConnectX-7 / 8、Quantum-2 / 3 交换机、SHARP（在网计算）__。SHARP 尤其关键——它把 AllReduce 的 reduction 操作下沉到交换机做，树形累加，带宽和延迟都打骨折。
|
||||
|
||||
IB 的代价：__贵，而且锁死在 NVIDIA 生态__。一套 Quantum-2 800G 方案，每端口价格是等速以太网的 2—3 倍。
|
||||
|
||||
### 3.2 RoCEv2：大厂的务实选择
|
||||
|
||||
RoCE（RDMA over Converged Ethernet）v2 跑在 UDP/IP 上，能直接用现有以太网基础设施，只要交换机支持 PFC / ECN / DCQCN 就行。国内大厂（阿里、字节、腾讯、百度）主力都是 __RoCEv2 over 以太网__，理由：
|
||||
|
||||
- __省钱__：以太网交换机白牌化程度高，同速率比 IB 便宜 30%—50%
|
||||
- __生态解耦__：不依赖 NVIDIA，换 Broadcom / Marvell / 国产芯片都行
|
||||
- __复用运维栈__：BGP / VXLAN / 监控体系全部沿用
|
||||
- __易扩展__：万卡到十万卡，以太网的可扩展性更好
|
||||
|
||||
代价是__工程门槛高__：无损以太网不是"打开 PFC 就行"，需要全链路调优 buffer、拥塞控制、哈希，否则 PFC 死锁或风暴能让整个训练崩掉。
|
||||
|
||||
### 3.3 无损网络三件套：PFC / ECN / DCQCN
|
||||
|
||||
#### PFC（Priority-based Flow Control）
|
||||
|
||||
基于 802.1Qbb。某端口某优先级 buffer 快满了，向上游发 Pause 帧暂停该优先级流量。好处是__真正零丢包__；坏处是：
|
||||
|
||||
- __head-of-line blocking__：Pause 阻塞整条链路的该优先级
|
||||
- __死锁__：拓扑成环 + 流量成环 → 所有端口互相 Pause，全局冻结。训练场景里 rail-optimized 拓扑特别容易踩这个
|
||||
- __风暴__：一个慢节点把 Pause 传导到全网
|
||||
|
||||
所以 PFC 只能作为"兜底"，不能作为"常态"。
|
||||
|
||||
#### ECN（Explicit Congestion Notification）
|
||||
|
||||
IP 头里 2 个 bit，交换机排队超过阈值就标 CE（Congestion Experienced），接收端回 CNP（Congestion Notification Packet）给发送端。发送端收到 CNP 主动降速，__在丢包和 PFC 触发之前就把流量压下来__。ECN 才是常态工作机制。
|
||||
|
||||
#### DCQCN（Data Center QCN）
|
||||
|
||||
Mellanox / NVIDIA 提出的拥塞控制算法，结合 ECN 反馈做速率调节。关键参数（NIC 侧）：
|
||||
|
||||
- `Rai` / `Rhai`：加性增、乘性增的步长
|
||||
- `Alpha`：根据 CNP 频率估计拥塞程度
|
||||
- Timer：多久没收到 CNP 就加速恢复
|
||||
|
||||
DCQCN 的调参是门艺术：太激进导致抖动，太保守导致 throughput 上不去。阿里 HPN、字节 MegaScale 都有自研的拥塞控制（HPCC、Swift 等）作为替代。
|
||||
|
||||
### 3.4 800G 以太网与 UEC
|
||||
|
||||
2024—2026 年以太网侧最大的事：
|
||||
|
||||
1. __800G 商用落地__：Broadcom Tomahawk 5（51.2 Tb/s）、Marvell Teralynx 10、思科 Silicon One G200 全部支持 800G。
|
||||
2. __1.6T 规划中__：Tomahawk 6（102.4 Tb/s）2025—2026 出样。
|
||||
3. __UEC（Ultra Ethernet Consortium）成立__：AMD、Broadcom、Cisco、Arista、Meta、微软等发起，目标是把以太网重做成"训练原生"：packet spray、可选择丢包、in-network collective、更轻量的传输层（替代传统 RoCE 的 Go-Back-N）。
|
||||
|
||||
UEC 的潜台词就是"__我们不想一直给 NVIDIA IB 交保护费__"。预计 2025—2026 UEC 1.0 兼容网卡和交换机陆续上市，对 NVIDIA Spectrum-X 构成直接竞争。
|
||||
|
||||
### 3.5 NVIDIA 的反击：Spectrum-X
|
||||
|
||||
NVIDIA 当然不会放任以太网吃掉 IB 的份额，于是推出 __Spectrum-X__：Spectrum-4 交换机 + BlueField-3 / ConnectX-8 DPU/NIC，基于以太网但集成了：
|
||||
|
||||
- __adaptive routing__：流级别重新哈希，对抗 ECMP hash 冲突
|
||||
- __packet spray + reorder__：NIC 侧重排序，把多链路负载均衡做到极致
|
||||
- __拥塞控制协同__：交换机 telemetry 实时反馈到 NIC
|
||||
|
||||
本质上是"把 IB 的好处搬到以太网上"，抢以太网阵营的单。
|
||||
|
||||
## 四、拓扑：Fat-Tree、Rail-optimized、Dragonfly
|
||||
|
||||
拓扑决定了__对分带宽（bisection bandwidth）__ 和__最坏情况延迟__。
|
||||
|
||||
### 4.1 Fat-Tree / Clos
|
||||
|
||||
两层或三层 Clos 网络，是通用数据中心的默认拓扑：
|
||||
|
||||
```
|
||||
Spine 层（core switch）
|
||||
/ | | \
|
||||
Leaf Leaf Leaf Leaf
|
||||
/|\ /|\ /|\ /|\
|
||||
...服务器...
|
||||
```
|
||||
|
||||
- 理论上全对分无阻塞（非阻塞 fat-tree）
|
||||
- 扩展性好，常规 3 层可支撑十万卡级别
|
||||
- 问题：__ECMP hash 冲突__。两条大象流哈希到同一 uplink，链路利用率上不去
|
||||
|
||||
### 4.2 Rail-optimized（Meta / 字节 / 阿里都在用）
|
||||
|
||||
Rail-optimized 的核心想法：__按卡号分轨__。
|
||||
|
||||
每台 8 卡服务器的 GPU0 全部连到 rail-0 交换机，GPU1 连到 rail-1 交换机……共 8 条独立 rail。DP AllReduce 只在同 rail 内发生，机间只走本 rail 的带宽，完全避免跨 rail 的 ECMP 冲突。
|
||||
|
||||
```
|
||||
rail-0 switch rail-7 switch
|
||||
/ | | \ / | | \
|
||||
Server0 Server1 ... Server0 Server1 ...
|
||||
GPU0 GPU0 GPU7 GPU7
|
||||
```
|
||||
|
||||
优点：
|
||||
|
||||
- AllReduce 带宽稳定，逼近理论值
|
||||
- 故障域清晰（rail-x 挂了只影响 GPU-x）
|
||||
|
||||
缺点：
|
||||
|
||||
- 跨 rail 通信（PP、EP）要多跳
|
||||
- 拓扑感知必须做对，否则退化
|
||||
|
||||
阿里 HPN、Meta RSC、字节 MegaScale 集群基本都是 rail-optimized 变体。
|
||||
|
||||
### 4.3 Dragonfly
|
||||
|
||||
CRAY / HPE 在超算上用的拓扑，分 group，group 内全连接，group 间少量长链路。
|
||||
|
||||
- 优点：对分带宽高，全局跳数少（最多 3 跳）
|
||||
- 缺点：需要 adaptive routing + UGAL 调度，生态小众
|
||||
|
||||
国内训练场景里不常见，主要是 Frontier、Aurora 这种超算集群用。
|
||||
|
||||
### 4.4 Multi-rail
|
||||
|
||||
一台服务器接 4—8 张 NIC（现在 H100 / B200 标配 __1 GPU : 1 NIC__，每卡独立一张 400G / 800G NIC）。NCCL 会自动把 AllReduce 拆成 N 条流在 N 条 rail 上并发，总带宽线性叠加。
|
||||
|
||||
Multi-rail 的关键：
|
||||
|
||||
- __NUMA / PCIe 亲和__：NIC 必须和它服务的 GPU 挂在同一 PCIe Switch / CPU，否则走 QPI / UPI 过去带宽腰斩
|
||||
- __拓扑文件__：NCCL 的 `NCCL_TOPO_FILE` 要正确声明 GPU-NIC 关系
|
||||
|
||||
## 五、集合通信与网络的关系
|
||||
|
||||
### 5.1 AllReduce 是带宽受限的
|
||||
|
||||
Ring AllReduce 的数据量分析：
|
||||
|
||||
- N 卡、数据量 D、一次 Ring-AllReduce 总步骤 = `2(N-1)`
|
||||
- 每步传输 `D/N`，总传输量 `2D(N-1)/N ≈ 2D`
|
||||
- 理论最优时间 `T = 2D(N-1) / (N · B)`，其中 B 是单链路带宽
|
||||
|
||||
结论：__N 很大时，AllReduce 时间几乎只取决于 B__。这就是为啥大家拼命堆带宽而不是堆卡数——带宽不够，加卡只会让每卡 throughput 更低。
|
||||
|
||||
### 5.2 Tree / Double-binary tree / SHARP
|
||||
|
||||
- __Tree AllReduce__：延迟 O(log N)，适合小消息
|
||||
- __Double-binary tree__：NCCL 默认大消息策略，带宽利用率接近 ring，延迟 O(log N)
|
||||
- __SHARP__：IB 交换机做在网规约，一次 AllReduce 只需要"上树 + 下树"，延迟和带宽都显著改善
|
||||
|
||||
NCCL 2.18+ 默认自动选择，也可以 `NCCL_ALGO=Ring` / `Tree` / `CollnetChain` / `CollnetDirect` 手动指定。
|
||||
|
||||
### 5.3 计算通信重叠
|
||||
|
||||
训练框架（Megatron、DeepSpeed、FSDP）都会做 overlap：反向传播算出一层梯度立刻开始 AllReduce，下一层计算并行进行。前提是__网络 throughput 足够稳__，否则 overlap 窗口小于通信时间，优化失效。
|
||||
|
||||
## 六、万卡故障域
|
||||
|
||||
### 6.1 fail-stop vs fail-slow
|
||||
|
||||
- __fail-stop__：GPU 挂了、NIC 挂了、节点宕机——监控立刻能抓到，重启 / 换节点恢复
|
||||
- __fail-slow__：更可怕。一张 NIC 降速、一个 optic 模块误码率升高、一颗 NVSwitch 半死，__带宽从 400G 降到 200G 但不报错__。整个 step 被这一根慢链路拖慢 2 倍
|
||||
|
||||
fail-slow 的典型表现：某个 rank 的 AllReduce 时间突然从 50ms 涨到 200ms，且持续一段时间；NCCL 监控 per-rank 时间就能发现。
|
||||
|
||||
### 6.2 链路抖动
|
||||
|
||||
光模块温度波动、DSP 误码、SerDes 重训练都会导致短时抖动。无损网络下，抖动可能触发 PFC，进一步诱发风暴。缓解：
|
||||
|
||||
- 光模块选用长期稳定的 200G-per-lane 甚至 100G-per-lane（别追最新的 200G PAM4）
|
||||
- 交换机 buffer 调大，吸收瞬时突发
|
||||
- 分级 QoS，训练流量独占一个优先级类
|
||||
|
||||
### 6.3 hash 冲突与大象流
|
||||
|
||||
ECMP 基于五元组哈希，训练流都是长连接大象流，很容易两条流撞同一 uplink。缓解：
|
||||
|
||||
- __rail-optimized 从源头避免__
|
||||
- __adaptive routing__（Spectrum-X、IB）
|
||||
- __packet spray__（UEC）
|
||||
- __多 QP 打散__：NCCL 开多 QP（`NCCL_IB_QPS_PER_CONNECTION=4`），哈希变成 5 元组 × 4
|
||||
|
||||
### 6.4 Checkpoint 与故障域隔离
|
||||
|
||||
这是下一篇（05 / 10）的主题，这里只提一句：万卡集群的 MTBF 是按__小时__算的，Ckpt 间隔必须小于 MTBF，否则训练永远卡在回滚。
|
||||
|
||||
## 七、国产互联生态
|
||||
|
||||
### 7.1 网络设备
|
||||
|
||||
- __华为__：CloudEngine 16800 系列，400G / 800G 以太网，配合昇腾 HCCN NIC，支持 RoCEv2 无损
|
||||
- __锐捷网络__：RG-S6980、S8920 系列，阿里、字节都大量采购
|
||||
- __新华三（H3C）__：S12500G、S9825 系列，百度、腾讯用得多
|
||||
- __中兴__：ZXR10 9900X 系列
|
||||
|
||||
国产 51.2T 交换芯片（盛科、华为自研）已在 2025 年陆续上市，国产替代在__可用__级别，性能对标 Tomahawk 4—5。
|
||||
|
||||
### 7.2 华为 CloudMatrix 384
|
||||
|
||||
2024 年底发布，2025 年大规模部署：
|
||||
|
||||
- 384 颗昇腾 910C
|
||||
- 超节点内全高速光互联（华为自研光模块）
|
||||
- 对外接口兼容标准以太网 / RoCEv2
|
||||
- 单超节点算力 ~ 300 PFLOPS（fp16）
|
||||
|
||||
对标 NVL72（72 GPU），卡数更多、带宽略低、功耗更大。在国内外管制背景下是 DeepSeek、Kimi 等团队的重要备选。
|
||||
|
||||
### 7.3 腾讯星脉网络
|
||||
|
||||
腾讯自研，特点：
|
||||
|
||||
- 全自研交换机（基于 Tomahawk / 自研芯片）
|
||||
- 自研 __TiTa 拥塞控制__（替代 DCQCN），更快收敛
|
||||
- rail-optimized + 多平面
|
||||
- 支持万卡至十万卡
|
||||
|
||||
### 7.4 阿里 HPN（High Performance Network）
|
||||
|
||||
阿里云训练集群底座：
|
||||
|
||||
- 自研 __HPCC / Swift__ 拥塞控制
|
||||
- __双上联__：每台服务器双 NIC 接不同 leaf，一侧挂了另一侧接管，消除单点
|
||||
- __eRDMA__：在 VPC 里跑 RDMA，云上训练也能享受无损
|
||||
- PAI-DLC、通义训练都跑在 HPN 上
|
||||
|
||||
### 7.5 字节 MegaScale
|
||||
|
||||
《MegaScale》论文披露了字节的万卡方案：
|
||||
|
||||
- rail-optimized 3 层 Clos
|
||||
- 400G RoCEv2
|
||||
- 大量 fail-slow 检测探针
|
||||
- NCCL 深度魔改，感知拓扑选最优算法
|
||||
|
||||
## 八、SuperPod / SuperCluster：十万卡级别
|
||||
|
||||
### 8.1 NVIDIA DGX SuperPod
|
||||
|
||||
标准化万卡方案：
|
||||
|
||||
- 以 DGX H100 / B200 node 为单元
|
||||
- IB Quantum-2（NDR 400G）组 rail-optimized 3 层
|
||||
- SHARP in-network reduction
|
||||
- 配 BCM（Bright Cluster Manager）+ NVIDIA Base Command 软件栈
|
||||
|
||||
2024—2026 年 Blackwell 代：__GB200 NVL72 × N__ 组成 SuperPod，NVL72 间走 IB XDR 800G。
|
||||
|
||||
### 8.2 Meta Research SuperCluster（RSC）与 Grand Teton
|
||||
|
||||
Meta 训练 Llama 3 / 4 的基础设施：
|
||||
|
||||
- 两个 24k H100 集群（一个 RoCE、一个 IB，做 A/B 对比）
|
||||
- Grand Teton 整机柜设计，OCP 标准
|
||||
- __无损以太网 + rail-optimized + 自研调度__
|
||||
|
||||
结论是"两边都能跑 Llama 3，生态视角 RoCE 更划算"。
|
||||
|
||||
### 8.3 xAI Colossus：10 万卡
|
||||
|
||||
2024 年 Elon Musk 在孟菲斯建的超级集群：
|
||||
|
||||
- 100k H100 → 2025 扩到 200k H200 / B200
|
||||
- Spectrum-X 以太网 + NVL72
|
||||
- 号称 19 天从零部署完 10 万卡（实际是分阶段，但节奏极猛）
|
||||
|
||||
工程意义：__证明以太网阵营能打 10 万卡级别__。
|
||||
|
||||
### 8.4 国内超大集群
|
||||
|
||||
- 字节：北京怀来、山西、新疆万卡—十万卡级
|
||||
- 阿里：张北、乌兰察布，多个 HPN 万卡集群
|
||||
- 腾讯：星脉支持的万卡集群，训练混元
|
||||
- 华为云：乌兰察布 / 贵安，CloudMatrix 384 × N
|
||||
- 百度：阳泉百舸 4.0 万卡
|
||||
|
||||
## 九、光互联与 CPO
|
||||
|
||||
### 9.1 可插拔光模块的瓶颈
|
||||
|
||||
传统 QSFP-DD / OSFP 可插拔光模块，功耗和密度已经到极限：
|
||||
|
||||
- 800G OSFP 模块功耗 14—17 W，一个 51.2T 交换机光模块总功耗接近交换机本体
|
||||
- 前面板密度有限，再往上到 1.6T / 3.2T 已经插不下
|
||||
|
||||
### 9.2 CPO（Co-Packaged Optics）
|
||||
|
||||
CPO 的思路：__把光引擎贴到交换机 ASIC 旁边__，省掉 SerDes 跑前面板这段距离。
|
||||
|
||||
- 功耗降低 30%—50%
|
||||
- 密度翻倍
|
||||
- 代价：维修性差（坏一个要换整板），可靠性需要时间验证
|
||||
|
||||
Broadcom 2024 年发布 Tomahawk 5 Bailly CPO 版本；NVIDIA 2025 年宣布 Spectrum-X 和 Quantum-X 都会有 CPO 产品线；国内光迅、中际旭创、新易盛都在押注。
|
||||
|
||||
### 9.3 硅光（Silicon Photonics）
|
||||
|
||||
硅光是 CPO 的底层技术路线之一：用 CMOS 工艺做光调制器 / 探测器。代表公司：Intel（Silicon Photonics 已分拆）、Ayar Labs、Lightmatter、国内的光迅。
|
||||
|
||||
对训练的直接好处：__未来可能看到 GPU die 上直接出光__（optical I/O），NVLink 跨机柜不再需要铜缆 + 电—光转换。
|
||||
|
||||
## 十、训练工程师视角：集合通信打不满怎么办
|
||||
|
||||
### 10.1 排查清单
|
||||
|
||||
一个 step 的 AllReduce 时间比理论值高 20% 以上，按顺序查：
|
||||
|
||||
1. __NCCL 是不是用对了网络__
|
||||
|
||||
```
|
||||
export NCCL_DEBUG=INFO
|
||||
export NCCL_DEBUG_SUBSYS=INIT,GRAPH,NET
|
||||
```
|
||||
|
||||
看启动日志里 `NCCL INFO NET/IB : Using [0]mlx5_0:1/IB` 或 `NET/Socket`。如果是 Socket，说明 RDMA 根本没起来。
|
||||
|
||||
2. __GPU-NIC 亲和__
|
||||
|
||||
看 GPU 和 NIC 之间是 `PIX`（同 PCIe switch，最优）、`PXB`（跨 bridge）、`NODE`（同 NUMA）、`SYS`（跨 NUMA，最差）。跨 NUMA 的组合必须修正拓扑文件。
|
||||
|
||||
3. __多 QP 和 rail 数__
|
||||
|
||||
```
|
||||
export NCCL_IB_QPS_PER_CONNECTION=4
|
||||
export NCCL_IB_SPLIT_DATA_ON_QPS=1
|
||||
export NCCL_IB_HCA=mlx5_0,mlx5_1,mlx5_2,mlx5_3,mlx5_4,mlx5_5,mlx5_6,mlx5_7
|
||||
```
|
||||
|
||||
4. __算法选对__
|
||||
|
||||
```
|
||||
export NCCL_ALGO=Ring,Tree,CollnetChain,CollnetDirect
|
||||
export NCCL_PROTO=Simple,LL,LL128
|
||||
```
|
||||
|
||||
大消息用 Ring + Simple，小消息用 Tree + LL128。打开 NCCL autotune 后一般不用手调。
|
||||
|
||||
5. __PFC / ECN 配置__
|
||||
|
||||
交换机上 `show pfc statistics`、`show ecn statistics`，看有没有大量 Pause 帧或 CNP。正常训练应该只有少量 ECN，PFC 接近 0。
|
||||
|
||||
6. __慢节点检测__
|
||||
|
||||
写个 per-rank allreduce 时间统计，看有没有某一两个 rank 一直比别人慢。慢节点隔离出来单独测带宽。
|
||||
|
||||
### 10.2 NCCL 常用环境变量速查
|
||||
|
||||
| 变量 | 作用 |
|
||||
| --- | --- |
|
||||
| `NCCL_DEBUG=INFO/WARN` | 调试日志 |
|
||||
| `NCCL_DEBUG_SUBSYS=ALL` | 细分子系统日志 |
|
||||
| `NCCL_IB_HCA` | 指定使用的 IB HCA |
|
||||
| `NCCL_IB_GID_INDEX` | RoCEv2 下必须设，通常 3 |
|
||||
| `NCCL_SOCKET_IFNAME` | 控制面网卡 |
|
||||
| `NCCL_P2P_DISABLE` | 禁用 P2P（调试用） |
|
||||
| `NCCL_SHM_DISABLE` | 禁用 SHM |
|
||||
| `NCCL_NET_GDR_LEVEL` | GPUDirect RDMA 级别 |
|
||||
| `NCCL_BUFFSIZE` | NCCL 内部 buffer 大小 |
|
||||
| `NCCL_MIN_NCHANNELS` / `NCCL_MAX_NCHANNELS` | 并行 channel 数 |
|
||||
|
||||
### 10.3 nccl-tests 实操
|
||||
|
||||
这是工程师的万能基准测试工具。
|
||||
|
||||
```
|
||||
git clone https://github.com/NVIDIA/nccl-tests
|
||||
cd nccl-tests
|
||||
make MPI=1 CUDA_HOME=/usr/local/cuda NCCL_HOME=/usr/local/nccl
|
||||
|
||||
# 8 卡单机 AllReduce（默认 NVLink 带宽测试）
|
||||
./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8
|
||||
|
||||
# 跨机：16 节点 × 8 GPU = 128 卡
|
||||
mpirun -np 128 -H host1:8,host2:8,...,host16:8 \
|
||||
-x NCCL_DEBUG=INFO \
|
||||
-x NCCL_IB_HCA=mlx5_0,mlx5_1,mlx5_2,mlx5_3,mlx5_4,mlx5_5,mlx5_6,mlx5_7 \
|
||||
-x LD_LIBRARY_PATH \
|
||||
./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1
|
||||
```
|
||||
|
||||
关注两列：
|
||||
|
||||
- `busbw`：总线带宽，= `algbw × 2(N-1)/N`。对 ring AllReduce，__busbw 应该接近单链路带宽__
|
||||
- `time`：耗时
|
||||
|
||||
经验值参考（大消息 1 GB）：
|
||||
|
||||
| 场景 | 理论 busbw | 实测可达 |
|
||||
| --- | --- | --- |
|
||||
| H100 单机 NVLink4 | 450 GB/s | 380—420 GB/s |
|
||||
| B200 NVL72 内 | 900 GB/s | 750—850 GB/s |
|
||||
| H100 跨机 IB NDR × 8 rail | 400 GB/s | 320—380 GB/s |
|
||||
| H100 跨机 RoCEv2 400G × 8 | 400 GB/s | 280—360 GB/s（调优后） |
|
||||
|
||||
低于这个范围就说明有问题，按 10.1 排查。
|
||||
|
||||
### 10.4 拓扑感知：`NCCL_TOPO_FILE` 示例
|
||||
|
||||
NCCL 会自动探测拓扑，但云虚机 / 容器里经常探不准。手动写：
|
||||
|
||||
```
|
||||
<system version="1">
|
||||
<cpu numaid="0" affinity="ffff,00000000" arch="x86_64">
|
||||
<pci busid="0000:0a:00.0" class="0x060400" link_speed="32.0 GT/s" link_width="16">
|
||||
<pci busid="0000:0b:00.0" class="0x030200">
|
||||
<gpu dev="0" sm="90" rank="0"/>
|
||||
</pci>
|
||||
<pci busid="0000:0c:00.0" class="0x020000">
|
||||
<nic>
|
||||
<net name="mlx5_0" dev="0" speed="400000" port="1" latency="0" guid="..."/>
|
||||
</nic>
|
||||
</pci>
|
||||
</pci>
|
||||
</cpu>
|
||||
...
|
||||
</system>
|
||||
```
|
||||
|
||||
启动时 `NCCL_TOPO_FILE=/path/to/topo.xml`。现代 NCCL（2.18+）结合 `NCCL_GRAPH_FILE` 还可以进一步固化通信图。
|
||||
|
||||
## 十一、两张拓扑示意图
|
||||
|
||||
### 11.1 Fat-Tree vs Rail-optimized
|
||||
|
||||
|
||||
|
||||
### 11.2 NVL72 机柜示意
|
||||
|
||||
|
||||
|
||||
## 十二、进阶话题：GPUDirect、RDMA 编程与内核旁路
|
||||
|
||||
### 12.1 GPUDirect RDMA
|
||||
|
||||
传统数据路径：GPU HBM → 系统内存 → NIC DMA → 网络。两次拷贝，CPU 介入，带宽腰斩。
|
||||
|
||||
__GPUDirect RDMA__ 让 NIC 直接 DMA GPU 显存：
|
||||
|
||||
- 需要 NIC、GPU 挂在同一 PCIe Root Complex 或同一 PCIe Switch 下
|
||||
- 内核驱动 `nvidia-peermem`（取代老的 `nv_peer_mem`）把 GPU BAR 映射给 NIC
|
||||
- 对应 NCCL 环境变量 `NCCL_NET_GDR_LEVEL=PIX`（同 switch 才启用）或 `=SYS`（强制启用）
|
||||
|
||||
启用后跨机 AllReduce 带宽能再涨 30%—50%，是__训练必开__项。
|
||||
|
||||
### 12.2 GPUDirect Storage（GDS）
|
||||
|
||||
`cuFile` API，让 NVMe 直接 DMA GPU 显存。训练里用得不多（数据 pipeline 有 CPU 侧 DataLoader 处理），但推理侧大模型权重加载、KV offload 到 NVMe 时很有用。
|
||||
|
||||
### 12.3 用 `ibv_*` 直接写 RDMA
|
||||
|
||||
多数情况下不需要，但排障时有用。一个最小化的 WRITE 操作：
|
||||
|
||||
```
|
||||
struct ibv_send_wr wr = {};
|
||||
struct ibv_sge sge = {
|
||||
.addr = (uintptr_t)local_buf,
|
||||
.length = size,
|
||||
.lkey = mr->lkey,
|
||||
};
|
||||
wr.wr_id = 0;
|
||||
wr.sg_list = &sge;
|
||||
wr.num_sge = 1;
|
||||
wr.opcode = IBV_WR_RDMA_WRITE;
|
||||
wr.send_flags = IBV_SEND_SIGNALED;
|
||||
wr.wr.rdma.remote_addr = remote_addr;
|
||||
wr.wr.rdma.rkey = remote_rkey;
|
||||
|
||||
struct ibv_send_wr *bad;
|
||||
ibv_post_send(qp, &wr, &bad);
|
||||
|
||||
struct ibv_wc wc;
|
||||
while (ibv_poll_cq(cq, 1, &wc) == 0) {}
|
||||
if (wc.status != IBV_WC_SUCCESS) { /* 错误处理 */ }
|
||||
```
|
||||
|
||||
排障时可以用 `ib_write_bw` / `ib_read_bw` 直测链路：
|
||||
|
||||
```
|
||||
# 服务器端
|
||||
ib_write_bw -d mlx5_0 -F -x 3 --report_gbits
|
||||
|
||||
# 客户端
|
||||
ib_write_bw -d mlx5_0 -F -x 3 --report_gbits <server_ip>
|
||||
```
|
||||
|
||||
正常 400G IB 应该能跑到 395+ Gb/s，低于 380 就要查 PCIe 亲和或光模块。
|
||||
|
||||
### 12.4 DPU / IPU 的角色
|
||||
|
||||
BlueField-3 / Pensando / AWS Nitro 这些 DPU，在 AI 训练集群里主要做：
|
||||
|
||||
1. __RDMA 卸载__：本来就是 NIC 功能
|
||||
2. __虚拟化__：多租户云训练里，把 VPC、overlay、安全组全部卸载到 DPU，让 CPU 和 GPU 专心算
|
||||
3. __存储加速__：NVMe-oF initiator 在 DPU 上跑
|
||||
4. __训练观测__：DPU 天然在网卡侧，telemetry、packet capture 都最合适
|
||||
|
||||
阿里 eRDMA、AWS EFA 都高度依赖 DPU。
|
||||
|
||||
## 十三、真实案例：一次万卡训练的网络复盘
|
||||
|
||||
这一节把前面所有技术点串起来，讲一个真实（虚构但贴近行业）的案例：某团队用 4096 卡 H100 训练一个 100B 模型，MFU 迟迟上不去。
|
||||
|
||||
### 13.1 现象
|
||||
|
||||
- 单机 8 卡 nccl-tests AllReduce：400 GB/s（正常）
|
||||
- 跨机 16 机 128 卡 AllReduce：预期 ~ 350 GB/s，实测 180 GB/s
|
||||
- 训练 MFU 只有 28%，期望 45%+
|
||||
|
||||
### 13.2 排查步骤
|
||||
|
||||
__Step 1：看 NCCL 日志__
|
||||
|
||||
```
|
||||
export NCCL_DEBUG=INFO
|
||||
export NCCL_DEBUG_SUBSYS=NET,GRAPH
|
||||
```
|
||||
|
||||
日志里发现：
|
||||
|
||||
```
|
||||
NCCL INFO NET/IB : Using [0]mlx5_0:1/IB [1]mlx5_1:1/IB ... [7]mlx5_7:1/IB
|
||||
NCCL INFO Channel 00 : 0[0] -> 1[0] via NET/IB/0
|
||||
```
|
||||
|
||||
8 张 NIC 都识别到了，OK。
|
||||
|
||||
__Step 2：查 GPU-NIC 亲和__
|
||||
|
||||
```
|
||||
nvidia-smi topo -m
|
||||
```
|
||||
|
||||
发现 GPU4—GPU7 和对应 NIC 是 `SYS`（跨 NUMA），而 GPU0—GPU3 是 `PIX`（同 PCIe switch）。__根因 1__：服务器 BIOS 里 PCIe Root Complex 划分不对，NIC 全部挂在 Socket 0。
|
||||
|
||||
__Step 3：改硬件或改拓扑文件__
|
||||
|
||||
硬件不能动，只能接受跨 NUMA。但发现系统没有加载 `nvidia-peermem`：
|
||||
|
||||
```
|
||||
lsmod | grep peermem
|
||||
# 空
|
||||
modprobe nvidia-peermem
|
||||
```
|
||||
|
||||
__根因 2__：GPUDirect RDMA 没启用，数据绕了一圈 CPU。
|
||||
|
||||
__Step 4：检查交换机 ECN / PFC__
|
||||
|
||||
```
|
||||
show interface counters errors
|
||||
show pfc statistics interface Ethernet1/1
|
||||
```
|
||||
|
||||
发现某几个 leaf 的 PFC Pause 计数每秒上万，__根因 3__：拥塞控制没调好，训练流量经常触发 PFC。
|
||||
|
||||
__Step 5：查 QP 和 channel 数__
|
||||
|
||||
```
|
||||
NCCL_IB_QPS_PER_CONNECTION=1（默认）
|
||||
```
|
||||
|
||||
多 rail 下单 QP 容易哈希冲突，改成：
|
||||
|
||||
```
|
||||
export NCCL_IB_QPS_PER_CONNECTION=4
|
||||
export NCCL_IB_SPLIT_DATA_ON_QPS=1
|
||||
```
|
||||
|
||||
### 13.3 修复后
|
||||
|
||||
- 加载 `nvidia-peermem`：busbw 从 180 → 260 GB/s
|
||||
- 调 DCQCN + 降 PFC 阈值：→ 300 GB/s
|
||||
- 开多 QP + packet spray：→ 345 GB/s
|
||||
- 修拓扑文件 + NUMA pin：→ 360 GB/s
|
||||
|
||||
MFU 从 28% 涨到 46%。训练时长从 90 天缩到 55 天。
|
||||
|
||||
### 13.4 启示
|
||||
|
||||
这个案例里，没有一个"致命 bug"，全是几个百分点的小问题叠加。万卡训练的网络调优就是这样——__每个环节省 10%，整体翻倍__。所以基建团队必须对 NCCL、NIC、交换机、拓扑、NUMA 全栈都懂。
|
||||
|
||||
## 十四、展望 2026—2028
|
||||
|
||||
1. __NVLink 走出机柜__：NVIDIA 路线图里 NVLink Fusion / NVL576，用光互联把多个 NVL72 连成更大的 scale-up 域
|
||||
2. __UALink 1.0 出货__：AMD / Broadcom / Cisco 阵营推出替代 NVLink 的开放标准
|
||||
3. __UEC 1.0 大规模部署__：预计 2026—2027 年成为以太网训练的事实标准
|
||||
4. __CPO 商用__：800G → 1.6T 迭代中，CPO 从试点走向规模部署
|
||||
5. __光 I/O 进芯片__：Lightmatter、Ayar Labs 的 optical I/O 可能首次出现在商用 AI 芯片上
|
||||
6. __国产超节点 1000+ 卡__：华为 CloudMatrix 下一代、寒武纪、壁仞可能推出千卡级超节点
|
||||
7. __跨 DC 训练__：Google Gemini Ultra 已经在做跨数据中心训练，DCI（DC Interconnect）成为新战场
|
||||
|
||||
网络演进的速度会比过去五年更快——因为 GPU 单卡算力增长在放缓，scale-up / scale-out 的想象力变成了整个行业的新增长点。
|
||||
|
||||
## 十五、选型决策速查
|
||||
|
||||
训练团队做网络选型时，建议按这个决策流：
|
||||
|
||||
1. __规模 ≤ 1k 卡，预算紧__：单柜或 2—3 机柜，IB NDR 400G × 8 rail，省事、生态稳
|
||||
2. __规模 1k—1 万卡，走公有云__：用云商自研网络（阿里 HPN、腾讯星脉、AWS EFA、Azure InfiniBand），不要自己折腾
|
||||
3. __规模 1 万—10 万卡，自建__：rail-optimized 3 层 Clos + 800G RoCEv2 + 自研拥塞控制；或 Spectrum-X；IB 仅在成本允许时考虑
|
||||
4. __规模 ≥ 10 万卡__：必须多平面 / 多池，单池 1—2 万卡，池间走骨干或分层调度
|
||||
5. __国产化路线__：昇腾 CloudMatrix 384 + 华为 / 锐捷 400G / 800G 以太网，HCCL + 自研 RoCEv2 栈
|
||||
6. __推理集群__：KV cache 以 intra-node 为主，对跨机带宽要求远低于训练；可以用 200G RoCE 或甚至 100G
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. NVIDIA, _NVLink and NVSwitch Architecture Whitepaper_, 2022—2024
|
||||
2. NVIDIA, _GB200 NVL72 Datasheet / System Guide_, 2024
|
||||
3. NVIDIA, _Spectrum-X Platform Whitepaper_, 2023
|
||||
4. NVIDIA, _nccl-tests_ 仓库：https://github.com/NVIDIA/nccl-tests
|
||||
5. Mellanox, _DCQCN: Data Center Quantized Congestion Notification_, SIGCOMM 2015
|
||||
6. Alibaba, _HPN: A Data Center Network for Large Language Model Training_, SIGCOMM 2024
|
||||
7. ByteDance, _MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs_, NSDI 2024
|
||||
8. Meta, _RDMA over Ethernet for Distributed AI Training at Meta Scale_, SIGCOMM 2024
|
||||
9. Tencent, _Tencent Xingmai (Starlink) Network_, 2023—2024 技术博客
|
||||
10. AMD, _Infinity Fabric / xGMI Documentation_, MI300X 平台
|
||||
11. Huawei, _CloudMatrix 384 超节点白皮书_, 2024
|
||||
12. Ultra Ethernet Consortium, _UEC Specification 1.0 (Draft)_, 2024—2025
|
||||
13. CXL Consortium, _CXL 3.0 Specification_, 2023
|
||||
14. Broadcom, _Tomahawk 5 Product Brief_, 2023
|
||||
15. xAI, _Colossus Cluster Overview_, 2024—2025
|
||||
Reference in New Issue
Block a user