厂商集群拓扑深度剖析
关联：总览.md — 名词定义 | fat-tree.md — Fat-tree 详解 | torus.md — Torus 详解
本文分析各 AI 芯片厂商的实际集群拓扑设计：设计哲学、层级结构、关键参数、实测数据。
厂商集群互联拓扑层级对比
| 厂商 | 节点内拓扑 | 互联协议 | 集群级拓扑 | 带宽断崖 |
|---|---|---|---|---|
| NVIDIA | NVSwitch Full Mesh（H100: 8 GPU 900 GB/s, NVL72: 72 GPU 1800 GB/s） | ConnectX-7/8 NIC, IB NDR/XDR 400-800 Gbps | Rail-Optimized Fat-tree, 100K+ GPU, SHARP 网内计算 | 18-36x |
| Google TPU | 无"节点"概念，所有芯片 ICI 直连（2.4-9.6 Tbps/chip） | ICI 自研，跨 rack 用 OCS 光路 | 3D Torus + OCS（v5p: 8960, Ironwood: 9216） | 无断崖 |
| Meta | NVLink + NVSwitch（Grand Teton: 8 GPU 900 GB/s） | RoCE v2 400GbE，成本低 30-50% | 5-tier Clos Spine-Leaf, 35K+ GPU | ~18x |
| AMD | IF4 Ring 8 XCD（MI300X: 相邻 200 GB/s, RCCL 实测 750-800 GB/s） | PCIe Gen5 / 以太网 ~63 GB/s | HPE Slingshot Dragonfly（El Capitan: 44,544 MI300A） | ~32x |
| Intel Gaudi | RoCEv2 Full Mesh（21 端口 scale-up, 8 芯片 4.2 Tbps） | RoCEv2 200GbE（3 端口 scale-out, 统一协议） | Fat-tree 以太网 | 7:1 |
| 华为昇腾 | HCCS/UB Full Mesh（910B: 8×~400 GB/s, CM384: 384×2.8 Tbps 全光） | RoCEv2 400 Gbps | CloudEngine Spine-Leaf, CE16800 | 待测 |
NVIDIA：NVSwitch 全互联 + Fat-tree 集群
设计哲学
节点内不惜成本追求全互联，节点间使用成熟的 Fat-tree。
NVIDIA 的拓扑策略基于一个核心判断：TP（张量并行）的通信量最大且对延迟最敏感，必须在全互联域内完成。节点间通信（DP/PP/EP）的容忍度更高，用 Fat-tree 的成熟生态即可。
节点内拓扑：NVSwitch 全互联
DGX H100（8 GPU）：
每颗 H100 有 18 条 NVLink 4.0 链路（每条 25 GB/s 单向，50 GB/s 双向），分配到 4 颗 NVSwitch 3.0（每颗连接 4-5 条链路），总双向带宽 900 GB/s/GPU（= 18 × 50 GB/s）。
NVSwitch 3.0 每颗有 64 个 NVLink 端口，4 颗 NVSwitch 交叉连接 8 个 GPU，形成逻辑全互联——任意 GPU 对之间可通过任何 NVSwitch 转发。
GB200 NVL72（72 GPU）：
| 参数 | 值 |
|---|---|
| GPU 数 | 72（36 Grace-Blackwell Superchip，每个含 2 B200） |
| NVSwitch 数 | 18（NVSwitch 4.0，每颗 72 NVLink 端口） |
| 每 GPU NVLink 链路 | 18（NVLink 5.0，50 GB/s/link） |
| 每 GPU 双向带宽 | 1,800 GB/s |
| 物理构成 | 1 rack: 18 compute trays × 4 GPUs/tray + 9 NVLink Switch trays |
为什么是 72 而非 64 或 128：72 = 36 Superchip × 2 GPUs，受 Grace-Blackwell Superchip 的 D2D 链路和机架物理空间限制。NVSwitch 4.0 有 72 个 NVLink 端口，18 颗提供 1296 端口，恰好连接 72 GPU × 18 links/GPU。128 GPU 需要更多 NVSwitch，功耗和散热超出单 rack 承受能力。
| 系统 | 规模 | 实现方式 | 每 GPU 带宽 |
|---|---|---|---|
| DGX A100 | 8 GPU | 6× NVSwitch 2.0 | 600 GB/s 双向 |
| DGX H100 | 8 GPU | 4× NVSwitch 3.0 | 900 GB/s 双向 |
| GB200 NVL72 | 72 GPU | 18× NVSwitch 4.0 | 1,800 GB/s 双向 |
节点间拓扑：Rail-Optimized Fat-tree
SuperPOD 架构（H100 版本）：
| 层级 | 组件 | 连接方式 |
|---|---|---|
| 节点内 | 8 GPU + 4 NVSwitch | NVLink 4.0 全互联，900 GB/s/GPU |
| 节点间（同 Rail） | 所有节点的 GPU_i -> ToR Rail-i | ConnectX-7 400Gbps IB NDR |
| 跨 Rail | ToR -> Spine 交换机 | IB NDR 400Gbps |
| 跨 SuperPOD | Spine -> Core 交换机 | IB NDR 400Gbps |
Rail-Optimized 设计要点：
- 每个 DGX H100 的 8 个 GPU 各有一个 ConnectX-7 NIC（400Gbps）
- 同编号 GPU 连接到同一 ToR（称为一个 Rail）
- DP AllReduce 天然在 Rail 内完成，不需要 Spine 层
- Spine 层只处理 TP/PP 跨节点通信和少量跨 Rail 流量
带宽断崖：NVLink 900 GB/s vs IB 400Gbps (50 GB/s) = 18:1 带宽比。这是并行策略映射的核心约束——TP 必须在 NVLink 域内，PP/DP 走网络。NVL72 的断崖更大：NVLink 1,800 GB/s vs 网络 ~400Gbps = 36:1。
来源：NVIDIA DGX SuperPOD Reference Architecture
SHARP 网内计算
NVIDIA SHARP 在 InfiniBand Quantum 交换机上实现网内 AllReduce：
| 指标 | 无 SHARP | 有 SHARP |
|---|---|---|
| AllReduce 延迟 | $2 \log_2 N \cdot \alpha$ | $\log_2 N \cdot \alpha$ |
| 网络总传输量 | $2 \cdot \frac{N-1}{N} \cdot M$ | $\frac{N-1}{N} \cdot M$ |
| 实测改善 | 基准 | 延迟降低 2x，有效带宽提升 30-50% |
SHARP 要求 Mellanox/NVIDIA Quantum 系列 IB 交换机，这是 NVIDIA IB 生态的护城河之一。
实测数据
| 配置 | 消息大小 | AllReduce 带宽 | 来源 |
|---|---|---|---|
| 8× H100 节点内 NVLink | 1 GB | ~450 GB/s (bus BW) | NVIDIA 官方 benchmark |
| 32× H100 跨 4 节点 IB NDR | 1 GB | ~380 Gbps (per GPU) | 公开 nccl-tests 结果 |
| NVL72 节点内 NVLink | 1 GB | ~839 GB/s (bus BW) | CoreWeave nccl-tests |
| NVL72 AllGather | 1 GB | ~1,600 GB/s (bus BW) | CoreWeave nccl-tests |
典型集群
| 集群 | 规模 | 节点内 | 节点间 |
|---|---|---|---|
| NVIDIA Eos | 10,752 H100 | NVSwitch 全互联 | IB NDR Fat-tree |
| xAI Colossus | 100,000 H100 | NVSwitch 全互联 | IB Fat-tree |
| CoreWeave | 1,440 B200 | NVL72 | IB XDR + SHARP |
| Meta RSC | 16,384 A100 | NVSwitch 全互联 | IB HDR Fat-tree |
| Oracle OCI | ~16,000 H100 | NVSwitch 全互联 | IB NDR Fat-tree |
Google TPU：3D Torus 单拓扑到底
设计哲学
与 NVIDIA 的"节点内全互联 + 节点间交换"分层相反，Google 用单一 Torus 拓扑贯穿整个 Pod。
所有 TPU 芯片地位平等，不区分"节点内"和"节点间"。跨机架使用 OCS 光路交换将电信号转为光信号传输，逻辑上仍是 Torus 的一部分。
这是因为 Google 自研 TPU 芯片，可以在芯片上集成 ICI（Inter-Chip Interconnect）端口，直接构建 Torus 而无需外部交换机。
TPU 代际演进
| 代际 | 拓扑 | 维度配置 | Pod 规模 | 每芯片 ICI 带宽 | 关键变化 |
|---|---|---|---|---|---|
| v2 (2017) | 2D Torus | 16×16 | 256 | ~500 Gbps | 首个 TPU Pod |
| v3 (2018) | 2D Torus | ~32×32 | 1,024 | ~656 Gbps | 规模 4x |
| v4 (2020) | 3D Torus | 4×4×4 cube, OCS 重配 | 4,096 | ~2.4 Tbps | 加入 OCS 层 |
| v5p (2023) | 3D Torus | 16×20×28 | 8,960 | ~4.8 Tbps | 最大 Torus Pod |
| Trillium v6e (2024) | 2D Torus | 16×16 | 256 | ~6.4 Tbps | 回退 2D，带宽提升 |
| Ironwood v7 (2025) | 3D Torus | 多维 | 9,216 | ~9.6 Tbps | 最大 ICI 带宽 |
来源：TPU v4, ISCA 2023、Google Cloud TPU v5p
TPU v4 深度分析
架构：4×4×4 cube + OCS 重配
- 每颗 TPU v4 有 6 个 ICI 端口（3 维 × 2 方向），每端口 ~400 Gbps，总 ~2.4 Tbps
- 基本构建块为 4×4×4 cube（64 chips），在物理上对应一个 rack
- cube 间通过 OCS 光路交换动态连接，可灵活组合为不同形状的 Torus（如 8×8×64, 4×16×64 等）
OCS 层设计：
- 每个 4×4 "slice" 有 16 颗芯片的 Z 维出口端口
- OCS 将这些端口动态连接到其他 slice 的对应端口
- 支持将 4096 芯片灵活划分为多个独立 Torus 子集群
- 例如：一个物理 SuperPod 可同时运行一个 4×4×128 (2048 chips) 和两个 4×4×64 (1024 chips) 的独立作业
Trillium v6e 回退 2D 的原因
- 每芯片 ICI 带宽提升至 ~6.4 Tbps，4 个 ICI 端口（2D × 2 方向）
- 回到 2D Torus（16×16 = 256 chips/pod），将大规模扩展完全交给 Orbiter 跨 Pod OCS
- 设计哲学转变：Pod 内用高带宽小规模 Torus，Pod 间用 OCS 弹性扩展
与 NVIDIA 方案对比
| 维度 | NVIDIA | Google TPU |
|---|---|---|
| 节点内拓扑 | Full Mesh (NVSwitch) | 无"节点内"概念 |
| 节点间拓扑 | Fat-tree (IB) | 同一 Torus |
| 带宽断崖 | 18-36x (NVLink vs IB) | 无断崖（所有 ICI 链路相同） |
| 交换机 | 需要大量 IB 交换机 | 无交换机（直连 Torus） |
| 灵活性 | 标准化、多厂商 | 自研、定制化 |
| AllToAll 效率 | 高（Fat-tree 全割集带宽） | 低（Torus 割集带宽不足） |
| 网络成本占 TCO | 30-40% | <10% |
Meta：RoCE 以太网 Fat-tree
设计哲学
Meta 是唯一在大规模 AI 训练集群上主动选择 RoCE 而非 InfiniBand 的主要厂商。
动机（来源：Meta Engineering Blog、SIGCOMM 2024）：
- 供应商多样性：避免锁定 NVIDIA/Mellanox 交换机生态
- 运维一致性：AI 训练流量与存储、管理流量共用同一以太网基础设施
- 成本：以太网交换机比 IB 交换机便宜 30-50%
- 开源控制：使用 Arista/Broadcom 交换机 + 自研 SDN 控制器
网络架构
| 参数 | 值 |
|---|---|
| 拓扑 | 5-tier Clos（Spine-Leaf 扩展到 5 级） |
| 过订阅比 | 1:1（全带宽无阻塞） |
| 拥塞控制 | PFC + ECN + DCQCN + E-ECMP |
| 负载均衡 | ECMP + 自适应包喷射 (packet spraying) |
| 交换机 | Arista 7800R3 (Spine) + 7060X5 (Leaf) |
| 单 GPU 上行带宽 | 400GbE × 1 NIC |
5-tier 而非 3-tier 的原因：35K+ GPU 需要的端口数超过了 3-tier Fat-tree 在 400GbE 交换机下的容量。5-tier（Leaf -> T1 Spine -> T2 Spine -> T3 Spine -> T4 Spine）提供了足够的端口密度。
RoCE vs InfiniBand 的工程权衡
| 维度 | RoCE (Meta) | InfiniBand (NVIDIA) |
|---|---|---|
| 交换机成本 | ~$625-860/port | ~$940-1170/port |
| 拥塞控制 | 软件实现 (DCQCN) | 硬件实现 (Credit-based) |
| 无损保证 | 需要 PFC + ECN 调优 | 原生信用流控 |
| 网内计算 | 无 | SHARP |
| 生态锁定 | 多厂商 (Arista/Broadcom/Cisco) | 单厂商 (NVIDIA/Mellanox) |
E-ECMP（Enhanced ECMP）：Meta 在标准 ECMP 基础上开发了增强版负载均衡，结合自适应包喷射（packet spraying），在 Elephant flow（如 AllReduce 大消息）场景下将链路利用率从 ~60% 提升至 ~90%。
Llama 3 训练实测：Meta 在 16,384 颗 H100 上训练 Llama 3 405B，报告整体 MFU 达 38-43%。网络是主要瓶颈——跨节点 AllReduce 占 DP 通信时间的 ~30%。
来源：Meta, "The Llama 3 Herd of Models"
典型集群
| 集群 | 规模 | 节点 | 网络 |
|---|---|---|---|
| Meta RSC v1 | 6,144 A100 | Grand Teton | IB HDR Fat-tree |
| Meta RSC v2 | 16,384 A100 | Grand Teton | IB HDR Fat-tree |
| Meta AI Cluster | 35,000+ H100 | Grand Teton v2 | RoCE 400GbE 5-tier Clos |
AMD：封装内环形 + Dragonfly 集群
MI300X 封装内拓扑
MI300X 的 8 个计算 Die (XCD) 排列在中央 IOD（I/O Die）周围，通过 Infinity Fabric 4 (IF4) 以环形连接。
| 参数 | 值 |
|---|---|
| XCD 数 | 8 |
| 连接方式 | 环形（每 XCD 连接相邻 2 个 XCD） |
| 相邻 XCD 间带宽 | ~200 GB/s |
| 2-hop XCD 间带宽 | ~50-70 GB/s（经中间 XCD 转发） |
| 总封装内带宽 | ~896 GB/s 聚合 |
来源：Chips and Cheese, MI300X IF Topology Analysis
与 NVIDIA NVSwitch 的关键差异：NVSwitch 实现全互联（任意 GPU 对等带宽），MI300X 的环形导致非相邻 Die 间带宽显著衰减。RCCL 需要感知拓扑来优化通信路径。
8-GPU 系统实测：MI300X 8-GPU 节点 RCCL AllReduce 实测带宽约 750-800 GB/s (bus BW)，接近理论峰值 ~896 GB/s 的 84-89%。
跨封装互联
MI300X 跨封装（多 GPU 服务器间）通过 PCIe Gen5 x16（~63 GB/s）或 Infinity Fabric over PCIe，远低于 NVLink。这是 AMD 方案在 TP 场景的主要短板。
集群级拓扑
AMD GPU 没有自研集群互联，依赖第三方网络：
| 集群 | 规模 | 互联 | 拓扑 |
|---|---|---|---|
| El Capitan (LLNL) | 44,544 MI300A | HPE Slingshot-11 | Dragonfly |
| Frontier (ORNL) | 37,888 MI250X | HPE Slingshot-11 | Dragonfly |
AMD GPU 集群倾向使用 Dragonfly 而非 Fat-tree，原因是这些系统由 HPE Cray 集成，Slingshot 是 HPE 的自研互联产品。
Intel Gaudi：统一 RoCEv2 拓扑
设计哲学
Gaudi 是唯一不区分节点内/节点间互联协议的方案——全部使用 RoCEv2。
Gaudi3 架构
| 参数 | 值 |
|---|---|
| 每芯片 RoCEv2 端口 | 24 × 200Gbps |
| 片上以太网交换引擎 | 内置 |
| 端口分配 | 21 端口节点内 (scale-up) + 3 端口节点间 (scale-out) |
| 节点内连接 | 8 芯片用 21 端口/芯片构成全互联 Mesh（每对 3 条链路） |
| 节点间连接 | 3 端口/芯片连接外部以太网交换机 |
| 每芯片聚合带宽 | 4.8 Tbps (24 × 200G) |
| 节点内带宽 | 4.2 Tbps/芯片 (21 × 200G) |
| 节点间带宽 | 600 Gbps/芯片 (3 × 200G) |
21/3 端口分配决定了 7:1 的带宽断崖（4.2 Tbps vs 0.6 Tbps）——虽然协议相同（都是 RoCEv2），但物理端口数量的不对称仍然造成了带宽层级差异。
统一协议的权衡
| 维度 | 优势 | 劣势 |
|---|---|---|
| 协议统一 | 节点内外同一协议，运维简单 | - |
| 扩展平滑性 | 从 8 到数百芯片的通信模式一致 | - |
| 带宽断崖 | - | 21/3 端口分配仍导致 7:1 带宽比 |
| 节点内带宽 | - | 聚合 ~525 GB/s (双向)，低于 NVLink 900-1800 GB/s |
华为昇腾：HCCS 全互联 + UB-Mesh
设计哲学演进
华为互联方案经历了三代技术路线：
| 阶段 | 产品 | 节点内互联 | 规模 |
|---|---|---|---|
| 第一代 | Ascend 910B | HCCS (电互联) | 8 NPU 全互联 |
| 第二代 | CloudMatrix 384 | UB 全光互联 (L1/L2 交换) | 384 NPU |
| 第三代 | UB-Mesh | 分层 nD 全互联 | 8K+ NPU |
UB（Ultra Bus / Unified Bus） 是华为自研互联协议，设计目标是统一替代 PCIe、CXL、NVLink 和 TCP/IP。华为在 Hot Chips 2025 宣布计划开源 UB-Mesh。
Ascend 910C UB 端口规格
每颗 Ascend 910C 是双 Die 封装（两个 910B Die 集成在同一基板上）：
| 参数 | 值 |
|---|---|
| Die 数 | 2 |
| UB 链路/Die | 7 × 224 Gbps（原始 SerDes 速率） |
| 总 UB 带宽/芯片 | ~2.8 Tbps（14 链路 × ~200 Gbps 有效速率） |
| 光模块 | 14 × 400G LPO 光收发器/芯片 |
注意单位：Huawei 的 2.8 Tbps 使用"比特"单位；NVIDIA NVLink 5.0 的 1.8 TB/s 使用"字节"单位（= 14.4 Tbps）。换算后 NVLink 5.0 单芯片带宽约为 UB 的 5 倍，华为以规模优势（384 NPU vs 72 GPU）补偿单芯片带宽差距。
来源：UB-Mesh arxiv 2503.20377、SemiAnalysis CloudMatrix 384
CloudMatrix 384 物理架构
CloudMatrix 384 是 UB-Mesh 单 Pod 实现，包含 384 颗 Ascend 910C NPU 和 192 颗鲲鹏 CPU：
| 组件 | 数量 | 说明 |
|---|---|---|
| 计算机架 | 12 | 每机架 32 NPU（4 节点 × 8 NPU/节点） |
| 通信机架 | 4 | 容纳 L2 UB 交换芯片 |
| 总机架数 | 16 | |
| 400G 光模块总量 | 6,912 | UB 平面 5,376 个 + RDMA/VPC 其余 |
两级非阻塞交换架构：
每颗 NPU（14 个 400G 光口）-> 本节点 L1 UB 交换机（7 颗）-> 通信机架 L2 UB 交换机（7 子平面 × 16 芯片/平面，每芯片 48 端口）
关键性能指标（来源：arxiv 2506.12708）：
- 跨节点带宽衰减 <3%（相对节点内）
- 跨节点延迟增加 <1 μs
- 支持 EP320（跨 320 颗 NPU 的 Expert Parallelism）
UB-Mesh 分层架构（8K+ NPU）
| 维度 | 规模 | 互联介质 |
|---|---|---|
| 1D-2D（机架内） | 64 NPU (8×8 全互联) | 无源铜缆（~1m） |
| 3D-4D（Pod 内） | 1,024 NPU/Pod (16 机架) | 有源铜缆/光纤 |
| 5D+（跨 Pod） | 8K+ NPU | Clos 骨干 |
UB-Mesh vs Clos 声明的优势（来源：论文 Table 2）：
- 少用 98% 的高基数交换机
- 少用 93% 的光模块
- 成本效率提升 2.04×
- 训练吞吐达 Clos 方案的 93-96%
推理性能基准
DeepSeek-R1 671B INT8 推理（384 NPU 全系统，来源：arxiv 2506.12708）：
| 指标 | 数值 |
|---|---|
| Prefill 速度 | 6,688 tokens/s/NPU |
| Decode 速度 | 1,943 tokens/s/NPU（TPOT <50 ms） |
| Expert Parallelism 规模 | EP320 |
与 NVIDIA NVL72 的对比
| 指标 | 华为 CloudMatrix 384 | NVIDIA GB200 NVL72 |
|---|---|---|
| 加速器数 | 384 NPU | 72 GPU |
| 每芯片互联带宽 | 2.8 Tbps | 14.4 Tbps (= 1.8 TB/s) |
| 全互联域规模 | 384 NPU | 72 GPU |
| 互联介质 | 全光（400G LPO） | 电气 NVLink + 光 NVSwitch 背板 |
| 系统 BF16 算力 | 300 PFLOPS | 180 PFLOPS |
| 机架数 | 16 | 1 |
厂商拓扑决策总结
| 厂商 | 节点内 | 节点间 | 设计驱动力 |
|---|---|---|---|
| NVIDIA | Full Mesh (NVSwitch) | Fat-tree (IB) | 最大化 TP 带宽 |
| 无"节点"概念 | 3D Torus (ICI) | 自研芯片，消除带宽断崖 | |
| Meta | Full Mesh (NVSwitch) | 5-tier Clos (RoCE) | 供应商多样性，运维统一 |
| AMD | Ring (IF4) | Dragonfly (Slingshot) | 依赖 HPE 集成 |
| Intel | Full Mesh (RoCEv2, 21 端口) | Fat-tree (RoCEv2, 3 端口) | 统一协议，7:1 带宽比 |
| 华为 | HCCS(910B)/UB L1-L2 交换(CM384) | Spine-Leaf (RoCE) | 910B: 8 芯片；CM384: 384 NPU，光互联跨机架 |
核心洞察：
-
只有 Google 真正消除了带宽断崖——因为自研芯片可以集成 ICI，用同一互联贯穿全 Pod。Intel Gaudi 虽然协议统一（都是 RoCEv2），但 21/3 端口分配仍造成 7:1 带宽比。
-
Fat-tree 是商用 GPU 集群的唯一选择——使用 NVIDIA/AMD GPU 的厂商只能选择交换网络拓扑（Fat-tree/Clos），因为 GPU 的网络端口是标准 PCIe/以太网/IB，不支持直连 Torus。
-
Dragonfly 只在 HPC 超算中出现——El Capitan、Frontier 等系统使用 Dragonfly 是因为 HPE Cray 集成商的 Slingshot 互联，不代表 AI 行业趋势。
-
RoCE vs IB 是成本-性能的权衡——Meta 和华为选择 RoCE 看重成本和生态多样性，NVIDIA 推 IB 看重性能（SHARP、硬件流控）。长期趋势偏向以太网（Ultra Ethernet Consortium 正在标准化 AI 训练场景的以太网优化）。
-
全互联域规模竞赛加剧——从 NVL72（72 GPU）到华为 CloudMatrix 384（384 NPU），全互联域的规模正在快速扩大。更大的全互联域意味着更大的 TP 组，可直接容纳更大模型的 TP 分片而无需跨越带宽断崖。
参考文献
厂商文档
| 资料 | 来源 | 关键内容 |
|---|---|---|
| NVIDIA DGX H100 Whitepaper | NVIDIA | NVSwitch 3.0 全互联设计 |
| NVIDIA GB200 NVL72 | NVIDIA | 72 GPU NVLink 5.0 域 |
| NVIDIA SuperPOD Architecture | NVIDIA | Rail-Optimized Fat-tree |
| NVIDIA SHARP | NVIDIA | 网内计算 |
| Google Cloud TPU v5p | 3D Torus 规格 | |
| Intel Gaudi3 White Paper | Intel | Gaudi3 24 端口 21/3 分配 |
| HPE Slingshot | HPE | Dragonfly+ 互联 |
| 华为 CloudMatrix 384 | 华为 | 384 NPU 全光互联 |
| SemiAnalysis: CloudMatrix 384 | SemiAnalysis | L1/L2 交换架构深度分析 |
论文
| 论文 | 会议 | 核心贡献 |
|---|---|---|
| Jouppi et al., "TPU v4" | ISCA 2023 | 3D Torus + OCS 设计 |
| Meta, "RoCE at Scale" | SIGCOMM 2024 | RoCE 万卡级实践 |
| Mudigere et al., "DLRM Training" | ISCA 2022 | Rail-Optimized 部署 |
| Meta, "The Llama 3 Herd of Models" | arXiv 2024 | 16K GPU 训练实测 MFU 38-43% |
| CloudMatrix384 LLM Serving | arXiv 2025 | DeepSeek-R1 推理基准 |
| UB-Mesh: nD-FullMesh | arXiv 2025 | UB-Mesh 分层架构，8K+ NPU 设计 |
| Chips and Cheese - MI300X | Chips and Cheese | MI300X IF4 环形拓扑带宽分析 |
| CoreWeave nccl-tests | CoreWeave | NVL72 AllReduce 实测数据 |