在万卡以上规模的大模型训练基础设施中，GPU 内部通信与跨机柜网络之间的带宽鸿沟往往决定了分布式训练的实际效率上限。NVIDIA GB200 NVL72 以机柜级 NVLink 域为基本单元，通过 72 颗 Blackwell GPU 的全互联拓扑将内部通信带宽推升至 130 TB/s 的量级，而跨机柜扩展则依赖 InfiniBand fabric 承接多机柜协同工作。这一架构与 Anthropic 在 Colossus2 项目中呈现的扩展路径高度吻合，为张量并行分区、热功耗管理与集群调度提供了全新的设计边界。
一、GB200 NVL72 硬件架构的核心参数
GB200 NVL72 是 NVIDIA 面向万亿参数模型推出的机柜级超级系统，其核心构成单元为 GB200 Grace Blackwell Superchip。每块 Superchip 集成两颗 Blackwell Tensor Core GPU 与一颗 Grace CPU，通过 NVLink-Chip-to-Chip（C2C）接口提供 900 GB/s 的双向带宽，在应用层呈现为统一内存空间。18 个计算节点构成完整的 NVL72 机柜，每个计算节点包含两颗 Superchip，即每机柜总计 72 颗 GPU。
机柜内部通信完全依赖 NVLink Switch System：9 个 NVLink Switch Tray 各自提供 144 个 100 GB/s 的 NVLink 端口，覆盖全部 72 颗 GPU 上的 18 个 NVLink 端口，实现全互联拓扑。第五代 NVLink 的单 GPU 双向带宽为 1.8 TB/s，是 PCIe Gen5 的 14 倍；整个 NVLink 域的聚合带宽达到 130 TB/s，单机柜即可提供约 1.8 exaFLOPs 的 AI 计算吞吐量。
值得关注的是，第五代 NVLink 支持将最多 576 颗 GPU 纳入单一 NVLink 域，总带宽超过 1 PB/s。这为未来更大规模的机柜集群提供了 scale-up 扩展空间，但实际部署中绝大多数场景仍以单机柜 72 GPU 为边界向外延展。
二、跨机柜互联：InfiniBand fabric 的角色定位
在单机柜 72 GPU 的 NVLink 域之外，跨机柜通信由 InfiniBand 网络承接。设计这种双层网络拓扑时，必须明确一个基本原则：单机柜训练受限于 NVLink，多机柜训练受限于 InfiniBand fabric。
InfiniBand 侧通常部署 NDR（Network Data Router）400 Gb/s 或 XDR 800 Gb/s 的 NIC。以 400 Gbps NDR 为例，单链路提供约 50 GB/s 的双向带宽；相比之下，单颗 GPU 的 NVLink 带宽高达 1.8 TB/s，两者之间存在约 36 倍的带宽差距。这意味着跨机柜通信的 all-reduce、all-gather 等集合通信操作将成为多机柜训练的瓶颈节点。
在 Colossus2 规模的部署中，InfiniBand 网络通常采用 rail-optimized fat-tree 拓扑设计，即每台服务器的 InfiniBand NIC 连接到多个 InfiniBand 叶子交换机，使得不同 GPU 在发起跨机柜通信时能够利用多个独立网络平面并行传输数据。对于 MoE（Mixture of Experts）模型，专家并行（Expert Parallelism）的跨机柜激活通信特别适合这种多平面路由策略，可显著降低单一 InfiniBand 链路的饱和概率。
实际部署中，建议在 InfiniBand fabric 层面配置拥塞控制机制（Priority Flow Control 或 ECN），防止跨机柜集合通信突发时造成头端阻塞（HOL blocking）。典型参数配置如下：PFC pause frames 阈值设为 64 KB，ECN marking probability 在 5% 负载以下保持零触发，50% 负载时逐步提升至 20%，以保障集合通信流量获得优先转发。
三、张量并行分区策略：NVLink 域内优化
张量并行（Tensor Parallelism）将单一模型层的权重和激活按行或列切分到不同 GPU，每次前反向传播都需要在参与切分的 GPU 之间进行 all-reduce 通信。对于 GB200 NVL72，这种 all-reduce 通信在单机柜边界内可以完全利用 NVLink 的 130 TB/s 聚合带宽完成，大幅降低通信延迟。
在 NVL72 机柜内实施张量并行时，建议将张量并行度控制在 72 以内，即所有通信均可在 NVLink 域内完成。具体而言，对于标准 Transformer 层，建议将张量并行度设为 8 或 16（对应列切分），配合流水线并行（Pipeline Parallelism）将不同层分配到不同计算节点。Megatron-LM 框架在 GB200 上的实测表明，8 路张量并行时单步迭代效率约为单 GPU 的 92%，而 16 路张量并行时降至约 85%，主要原因是 all-reduce 通信量随并行度线性增长。
对于 MoE 模型，额外的专家并行维度应在跨机柜 InfiniBand 层面展开。以 1.8T 参数的 GPT-MoE 为参考，若模型包含 128 个专家，建议将其中 8–16 个专家的张量并行切分保留在机柜内部，其余专家通过 InfiniBand 进行跨机柜路由。此时，每个 token 的专家激活路径将产生约 1–2 次跨机柜通信，InfiniBand 链路利用率应控制在 40% 以下以确保延迟可接受。
张量并行实施中还需关注梯度同步策略。传统同步梯度更新（Synchronous SGD）在跨机柜场景下的通信 - 计算比接近 1:1，效率较低。建议在 Colossus2 规模集群中采用分阶段梯度同步：将单机柜内 72 GPU 的梯度 all-reduce 限制在 NVLink 域内完成，每隔 N 步（建议 N=4–8）才触发跨机柜的 InfiniBand 同步，由此将跨机柜通信频率降低至原来的 1/N，配合 InfiniBand 的 400 Gb/s 带宽可获得可接受的同步精度损失。
四、热功耗管理：液冷系统的关键参数
GB200 NVL72 采用全液冷设计，冷板覆盖每颗 GPU 和 Grace CPU，热交换通过机柜级液冷分配单元（CDU）完成。相比上一代 HGX H100 的气冷方案，液冷系统可实现 25 倍更低的冷却能耗，这一数字在万卡集群尺度上具有决定性意义。
单机柜典型热设计功耗（TDP）约为 120–130 kW，其中 GPU 部分占比约 70–75%。液冷系统进水温度通常设置为 25–28°C，出水温度控制在 40–45°C 以内，以保证冷板侧温差不超过 15°C。CDU 的制冷量应按单机柜峰值功耗的 1.15 倍配置，以应对瞬态负载波动。
在实际部署中，热功耗管理需要与 GPU 利用率动态关联。训练任务在 all-reduce 通信阶段 GPU 利用率会出现短暂下降，此时机柜热负载随之降低；进入计算密集的前反向传播阶段时，GPU 活跃度上升，热功耗随之增加。建议在集群调度层面引入基于实时功耗的 DVFS（动态电压频率调节）策略：当 InfiniBand 侧触发跨机柜通信时适当降低 GPU 频率 5–10%，在不显著影响训练吞吐的前提下降低峰值热负荷，为液冷系统留出更多余量。
另一个关键热管理参数是机柜进风口温度上限。NVIDIA 规范要求 GB200 NVL72 环境工作温度不超过 27°C（海拔修正后更低），这意味着数据中心需要常年维持 20–25°C 的冷冻水供水温度。对于非标准数据中心改造场景，建议部署额外的冷却盘管或直接液冷接口，并将 CDU 的冷却能力与 PUE 目标绑定：若目标 PUE 为 1.1，则 CDU 效率需不低于 95%，这要求冷却水流量维持在每分钟 40–50 升每机柜的量级。
五、集群调度与故障隔离的工程建议
在 Colossus2 规模的 GB200 NVL72 集群中，单机柜即为最小调度单元。建议采用两级调度架构：集群调度器（如 Kubernetes + GPU Operator）负责跨机柜任务分配，机柜内的 NVLink 域调度由通信库（如 NCCL）配合拓扑感知插件完成。
NVLink 域内故障隔离需要特别注意：单颗 GPU 故障不应导致整台机柜下线。在 NCCL 2.19 及以上版本中，可通过 ncclSetBufferRegisterFn 接口为每个张量并行组配置独立的 ring topology，当检测到 GPU 故障时自动触发 ring 重构，跳过故障节点并重新建立 all-reduce 拓扑。重构延迟通常在 500 ms 以内，对万卡训练的端到端吞吐影响小于 0.1%。
InfiniBand 侧的多平面冗余设计同样关键。建议为每台服务器配置双 InfiniBand NIC，分别连接到两个独立的 InfiniBand 叶子交换机平面。当某一平面出现链路故障时，通信库应具备将流量无缝迁移至另一平面的能力。NVIDIA UFM（Unified Fabric Manager）可实时监控 InfiniBand fabric 的链路状态，并在故障发生后 30 秒内触发告警与自动路由更新。
在多机柜训练任务的 checkpoint 保存策略上，建议以单机柜 72 GPU 为单位进行分片保存，而非等待全局同步后统一写入存储。这是因为跨机柜的 all-reduce 完成后立即进行 checkpoint 可避免后续 GPU 间的依赖关系导致的等待。典型 checkpoint 间隔为 100–500 步，保存至分布式对象存储（如 Amazon S3 或 MinIO），每个 72 GPU 机柜的 checkpoint 数据量约为 800–1200 GB，建议利用 NVMe 本地缓存层先行暂存，再异步上传至后端存储。
六、可落地的核心参数速查
在规划 GB200 NVL72 集群扩展时，以下参数可作为初始配置的参考基准：
张量并行维度选择上，单机柜内推荐 8 路或 16 路张量并行；超过 16 路时需评估 all-reduce 通信对 GPU 利用率的侵蚀。以 Transformer 标准层为例，8 路张量并行的通信 - 计算时间比约为 0.12，而 32 路将上升至 0.35 以上。
InfiniBand 链路利用率警戒线设在 40% 以下。若实测跨机柜 all-gather 期间链路利用率持续超过 50%，应考虑增加 InfiniBand NIC 数量或调整张量并行与专家并行的比例分配。
液冷系统 CDU 制冷量按单机柜峰值功耗 130 kW 的 1.15 倍配置，即约 150 kW 制冷量。进水温度 25–27°C，出水温度不超过 43°C，冷却水流量不低于 42 L/min。
梯度同步间隔 N 设为 4–8，视模型收敛稳定性而定。建议在第一个 10k 步内以 N=4 验证收敛曲线，之后根据验证集损失走势调整至 N=6 或 N=8。
Checkpoint 保存以 72 GPU 机柜为单位分片，建议本地 NVMe 缓存容量不低于 2 TB，配合 100 Gbps 以太网回传至对象存储。
资料来源
- NVIDIA 官方技术博客：GB200 NVL72 Delivers Trillion-Parameter LLM Training and Real-Time Inference（developer.nvidia.com/blog）
- NDR/XDR InfiniBand 集群设计参考：Fibermall NVIDIA GB200 NVL72 技术指南（fibermall.com）
- GPU 互联架构分析：Introl NVLink Scale-Up Networking（introl.com/blog）
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。