Fleet Foundations
单节点性能工程聚焦于存储层次结构的延迟与 roofline 脊点。当任务跨越多台机器时，网络延迟取代缓存延迟，组件故障成为统计意义上的必然，互连带宽决定扩展效率。本附录汇集支撑本书多节点章节的 fleet 规模常数、规模定律与热限制，为读者提供推理集群级基础设施所需的物理基线。以 C³ 术语而言，这些数值定义了计算容量、通信带宽与协同开销成为可测量量的物理尺度。
How to Use This Appendix
本附录旨在将 fleet 规模的设计问题转化为具体的物理约束，并识别可用的优化杠杆。
The Three System Paradigms
大规模机器学习基础设施从两条截然不同的计算谱系继承了设计 DNA——然后打破了二者的假设。理解机器学习系统从高性能计算（HPC）与仓库级计算（WSC）分别借用了什么，是选择正确设计取舍的前提。把机器学习训练视为“仅仅是 HPC”的架构师，将构建无法容忍故障的基础设施；把训练视为“仅仅是 Web 服务”的架构师，将构建无法维持同步训练所要求的紧密耦合的基础设施。
High-performance computing
HPC 系统源自超级计算机传统。其设计理念是在紧密耦合的仿真中最大化 FLOP/s——天气建模、分子动力学、核物理。每个节点都至关重要：它们使用专用互连（InfiniBand）、低延迟 fabric 与同质硬件。容错遵循 Checkpoint/Restart 模型：若某个节点故障，整个任务停止，回滚至最近一次检查点，并从头开始重新执行。调度是批处理导向（Slurm），任务请求刚性的资源形态（“512 个节点运行 24 小时”）。节点是 pets——各自重要、各自被跟踪。
Warehouse-scale computing
WSC 系统源自 Web 服务传统。其设计理念是在 loosely coupled 的服务之间最大化每秒查询数——搜索、邮件、社交媒体。硬件是商用以太网，不同代际并存，节点异构。容错遵循 Redundancy 模型：若某个节点故障，负载均衡器将流量重定向到另一个副本。用户从无察觉。调度是动态的（Kubernetes、Borg），具备弹性 bin-packing。节点是 cattle——可互换且可牺牲。
The ML fleet: A hybrid architecture
机器学习系统需要 HPC 的计算吞吐（以同步梯度更新训练大规模模型），但必须以 WSC 的规模与不可靠性运行（数千个加速器连续运行数周）。这形成了一个从两种传统中分别选择性借鉴的混合架构。
训练工作负载像 HPC 一样同步且带宽饥渴，但像 WSC 一样长时运行且容错。推理工作负载像 WSC 一样对延迟敏感，但像 HPC 一样计算密集。网络是融合：控制面使用 TCP/IP，数据面使用 InfiniBand 或 NVLink。容错采用 Elastic Training 策略：训练任务可以缩小、扩大、暂停或恢复，而无需完全重启。调度将 gang allocation（训练的全有或全无）与动态抢占和替换相结合。
表 1 总结了三个范式之间的设计取舍。关键洞见是：ML fleet 无法整体照搬 HPC 或 WSC 的模式；必须根据工作负载阶段从两者中分别选择性组合元素。
| 维度 | HPC（超级计算机） | WSC（Web Cloud） | ML Fleet（AI 集群） |
|---|---|---|---|
| 理念 | 最大化 FLOP/s | 最大化 QPS | 每美元/瓦特最大化模型质量 |
| 耦合 | 紧密（MPI） | 松散（RPC/HTTP) | 混合（NCCL + RPC) |
| 状态 | 有状态（RAM） | Stateless（DB-backed) | 半有状态（Checkpoints + KV Cache) |
| 网络 | 延迟优化 | 带宽优化 | 对二分带宽敏感 |
| 瓶颈 | Compute 吞吐（FLOP/s) | I/O（Disk/Net) | 内存带宽（HBM） |
| 故障模型 | Checkpoint/Restart | 冗余/副本 | 弹性缩小/扩大 |
| 调度 | 批处理（Slurm） | 编排（K8s） | Gang + 抢占 |
| 节点模型 | Pets（受跟踪） | Cattle（可牺牲） | 任务期间为 pets，任务间为 cattle |
基础回顾
以下内容提供了贯穿分布式系统章节的关键基础概念的紧凑参考。
- 铁律 (\(T \approx D_{\text{vol}}/\text{BW} + O/(R_{\text{peak}} \cdot \eta_{\text{hw}}) + L_{\text{lat}}\))：性能受数据移动或计算限制。在 fleet 规模下，数据移动项扩展为包含节点间通信，而不仅是内存带宽。
- Roofline 模型：利用算术强度区分 compute-bound 与 memory-bound 工作负载。在 fleet 规模下，还会出现第三个上限：Network-Bound 工作负载，其性能受节点间带宽限制。
- Amdahl 定律：将强扩展加速上限限制在 \(1/s\) (Amdahl 1967年)。在 fleet 规模下，“串行比例”不仅包含顺序代码，还包括同步屏障、集合通信与流水线气泡。
- 训练状态规则：常见混合精度 Adam 检查点状态约为每个参数 14 字节（BF16 权重、FP32 主权重与 Adam 动量），在框架元数据与实现特定附加项之前。在 fleet 规模下，这决定了模型状态如何在节点间划分（ZeRO、张量并行、流水线并行）。
- Little 定律 (\(Q_{\text{req}} = \lambda_{\text{arr}} T_{\text{lat}}\))：用于规划推理基础设施，其中 \(\lambda_{\text{arr}}\) 为请求到达率，\(Q_{\text{req}}\) 为预期并发请求数 (Little 1961年)。在 fleet 规模下，它决定负载均衡器背后需要多少服务副本。
从单机器到 fleet 规模的推理转变，需要以网络拓扑、故障概率与协同开销等新维度扩展这些模型。下一节的数值为这一扩展提供定量基础。
Every Fleet Engineer Should Know Numbers
正如单机器分析依赖一组核心数值，fleet 规模工程也由一组可预测的比例与扩展行为所支配。单机器数值在每个节点内部仍然适用，但节点之间的空间由另一组数值支配。虽然绝对值随硬件代际演变，但通信层级之间的比例与故障率的比例扩展行为依然异常稳定。这些比例与扩展趋势作为结构性不变量，而具体数值则提供数值层面的合理性校验。
Systems Perspective 1.1: 面向 fleet 推理的节点级数值
Systems Perspective 1.2: 最重要的三个 fleet 数值
- 带宽差距：节点内 NVLink 每个方向的带宽比节点间 InfiniBand NDR 端口快约 9× 倍。该比例决定了并行边界应位于何处——节点内的模型并行，节点间的数据并行。
- MTBF 扩展：集群的平均故障间隔时间是单组件 MTBF 除以组件数量（\(1/N\) 扩展）。在 100,000 GPU 上，预计每 30 minutes 发生一次故障。
- 有效利用率：在 MFU、扩展效率与开销损失叠加之后，具备 1,024 GPUs 的集群大约交付 20.5 percent 的峰值 FLOP/s 作为有效训练工作。
每位集群工程师都应记住的数字（速查表） 将 fleet 规模数值集中在一处。用于粗略估算时请使用它；在设计或调试时则使用各小节中的详细表格。
| 类别 | 数值 | 用途 |
|---|---|---|
| 通信 | NVLink 单向带宽 ~9× IB NDR | 并行边界（节点内 vs. 跨节点） |
| 通信 | IB NDR ~50 GB/s，单向 ~5 μs | 节点间带宽与延迟 |
| 计算 | MFU 30–50%，\(\eta_{\text{scaling}}\) ~50% @ 1K，~35% @ 8K | 有效 FLOP/s 与扩展合理性检查 |
| 协同 | MTBF 8K：~366.2 min；100K：~30 min | 故障预期与检查点节奏 |
| 协同 | 175B 检查点 ~2450 GB（14 B/参数常见 Adam 状态） | 恢复与存储容量估算 |
| 协同 | 扣除开销后吞吐 ~77% | 墙钟利用率 |
| 功耗与可持续性 | AI 机柜 ~70 kW；风冷上限 ~30 kW | 冷却可行性（超过风冷上限需液冷） |
| 功耗与可持续性 | 液冷 PUE ~1.06，典型 ~1.40；H100 700 W -> 10,000 ≈ 7 MW IT \(\times\) PUE | 设施负载与碳排（详见 节 1.4） |
不变量：不会改变的比例
这些关系受物理定律或架构约束——到 2035 年依然成立。
网络层级比例
节点内通信与节点间通信之间的带宽差距是一项架构不变量。芯片到芯片的链路（NVLink、ICI）通过共享基板上的短而宽的专用路径互联；节点间链路（InfiniBand、Ethernet）则必须穿越线缆、交换机和协议栈。这种结构性差异保证节点内带宽始终比节点间带宽高出一个数量级。
目前，NVLink 4.0 的单向带宽比 InfiniBand NDR 端口高出 9×。即便两项技术都在进步，这一比例依然保持，因为两者都受同一物理约束：信号速率、通道数量和连接器密度。该比例是并行策略中最重要的数字：任何需要超过节点间链路所能提供带宽的操作，都必须限制在单个节点内。
故障扩展定律
在恒定故障率假设下，对于 \(N\) 个独立组件，系统 MTBF（公式 1）与组件数量成反比：
\[ \text{MTBF}_{\text{system}} = \frac{\text{MTBF}_{\text{component}}}{N} \tag{1}\]
这是纯粹的算术关系，而非近似。集群规模翻倍，故障间隔时间减半。当 100,000 GPU 的每 GPU 平均失效时间（MTTF）为 50,000 hours 时，集群每 30 minutes 就会发生一次 GPU 故障。没有任何容错策略能够避免这一点——真正的问题在于系统恢复得有多快。
AllReduce 开销扩展
带宽最优的 Ring AllReduce 算法为每位参与者传输 \(2(N-1)M/N\) 字节，其中 \(M\) 为消息大小，\(N\) 为参与者数量 (Patarasuk 和 Yuan 2009年)。当 \(N\) 增大时，该值趋近于每 GPU \(2M\)，因此每 GPU 的带宽项几乎与 GPU 数量无关；集群的聚合流量仍随参与者数量增长。这正是 Ring AllReduce 在带宽项上扩展良好的原因。然而，延迟项随 \(2(N-1) \times \alpha\) 增长，使得延迟成为大环上小消息的瓶颈。这一权衡促使采用分层 AllReduce 策略：节点内使用 Ring AllReduce，节点间使用 Tree AllReduce。
通信数字
通信决定了并行的边界。这些表格量化了网络层级每一层的带宽与延迟，从最快的节点内链路到最慢的广域连接。对于任何分布式机器学习操作，关键问题都是它的通信跨越了哪一层网络。
通信带宽层级 列出了决定张量、流水线和数据并行流量应保留在哪一层的带宽层级。
| 互连 | 带宽 | 典型用途 |
|---|---|---|
| NVLink 4.0 (H100) | 450 GB/s | 节点内的张量/流水线并行 |
| TPU v5p ICI | 1,200 GB/s | 机内模型并行（Google） |
| PCIe Gen5 x16 | 64 GB/s | CPU-GPU 数据传输、NIC 挂载 |
| IB GXDR (1.6 Tbps) | 200 GB/s | 下一代节点间互连（2026 年起） |
| IB XDR (800 Gbps) | 100 GB/s | 节点间标准（2025 年起） |
| IB NDR (400 Gbps) | 50 GB/s | 当前 AI 集群节点间标准 |
| IB HDR (200 Gbps) | 25 GB/s | 上一代节点间互连 |
| RoCE v2 (100 GbE) | 12.5 GB/s | 预算型集群、推理集群 |
跨互连层级的单向延迟（通信延迟层级）决定同步集合操作是否可行。
| 互连 | 单向延迟 | 含义 |
|---|---|---|
| InfiniBand NDR | ~5 μs | 足够支持同步 AllReduce |
| InfiniBand HDR | ~7 μs | 适用于大多数训练拓扑 |
| RoCE v2 | ~10 μs | 适用于数据并行 |
| TCP/IP (Ethernet) | ~50 μs | 对同步训练来说太慢 |
| 跨数据中心 | ~40,000 \(\mu\)s (40 ms) | 物理下限；仅支持异步训练 |
这些延迟边界说明了为什么同步梯度同步需要 InfiniBand 或 RoCE 这类低延迟网络，而跨数据中心训练必须依赖异步执行或流水线边界。
计算数字
原始峰值 FLOP/s 是集群容量规划的必要但具有误导性的指标。两项相乘损失——MFU 与扩展效率——会大幅降低有效吞吐量。理解这些损失，能把集群规模规划从“拍脑袋估算”转变为工程决策。
MFU 衡量训练工作负载实际达到的峰值 FLOP/s 的分数。当前硬件上优化良好的大模型训练可实现 30–50 percent MFU。该差距源于内存停顿、内核启动开销、流水线气泡以及次优的算子融合。MFU 低于该范围低端意味着存在优化空间；MFU 高于高端则表明硬件利用率极佳。
扩展效率（\(\eta_{\text{scaling}}\)）衡量随着加速器数量增加，有多少有用的计算得以保留。经验扩展效率（按集群规模的扩展效率）展示了吞吐量随集群规模扩大的退化情况。
| 集群规模 | 扩展效率（\(\eta_{\text{scaling}}\)） | 含义 |
|---|---|---|
| 32 GPU | ~90% | 接近线性扩展；通信开销可忽略 |
| 256 GPU | ~70% | 通信开始侵蚀吞吐量 |
| 1,024 GPU | ~50% | 开销显著；优化至关重要 |
| 8,192 GPU | ~35% | 集群规模级；65% 的计算资源是开销 |
这种效率退化凸显了为何在数千 GPU 以上扩展，必须优化集合通信算法与拓扑布局，以保护计算 MFU。
协同数字
在集群规模级，协同——故障恢复、检查点与维护——会消耗可观的墙钟时间。这些数字量化了维持大规模集群运行的成本。
按集群规模的故障率
集群 MTBF 扩展（表 2，按每 GPU MTTF 为 50,000 hours 计算）决定了所需的检查点频率。
| 集群规模 | 仅 GPU 的 MTBF | 分钟 | \(\Pr(\text{failure})\) 内 24 小时 |
|---|---|---|---|
| 256 个 GPU | 195.3 h | 11,718.8 min | 11.6% |
| 2,048 个 GPU | 24.4 h | 1,464.8 min | 62.6% |
| 8,192 个 GPU | 6.1 h | 366.2 min | 98% |
| 100,000 个 GPU | 0.50 h | 30 min | 100% |
在 8,192 个 GPU 及以上规模，故障已不再是边缘情况。8,192 个 GPU 的仅 GPU MTBF 约为 366.2 min，24 小时内至少发生一次 GPU 故障的概率为 98 percent。在集群规模下，容错并非可选项；它是完成任何长运行训练任务的先决条件。 容错 详细涵盖相关机制。
检查点大小
检查点是主要的恢复机制，其成本取决于模型大小。 表 3 展示了常见混合精度 Adam 训练检查点的大小（每个参数 14 字节：2B 的 BF16 权重和 12B 的 FP32 主权重 + 动量 + 方差）。梯度通常是瞬态的，恢复时重新计算，而不是作为持久检查点状态序列化。
| 模型规模 | 检查点大小 | 100 GB/s 处的写入时间 |
|---|---|---|
| 7B 参数 | 98 GB | 0.98 s |
| 70B 参数 | 980 GB | 9.8 s |
| 175B 参数 | 2,450 GB | 24.5 s |
| 1T 参数 | 14 TB | 2.3 min |
开销预算
故障恢复与检查点只是墙钟预算的一部分。在集群规模下， 表 4 将开销划分为四类周期性开销，这些开销消耗的是未用于有效训练的时间：
| 开销类别 | 典型预算 | 杠杆 |
|---|---|---|
| 流水线气泡 | ~5% | 增加流水线阶段的微批次数量 |
| 检查点 | ~3% | 异步检查点、更快的存储 |
| 故障恢复 | ~10% | 更快的检测、弹性重调度 |
| 维护窗口 | ~5% | 滚动升级、在线迁移 |
功耗与可持续性数据
集群规模的容量规划与可持续性报告需要用到几个每位集群工程师都应掌握的功耗数据。在集群规模下，关键数据是 机柜功率密度、电能利用效率（PUE） 和 风冷上限——它们决定了哪些地点具备建设条件，以及设施负载将达到多少。 表 5 汇总了这些参考值：
| 物理量 | 典型值 | 用途 |
|---|---|---|
| 传统机柜 | 12 kW | 非 AI 数据中心的基准 |
| AI 机柜（当前一代） | 70 kW | 需要液冷 |
| AI 机柜（高密度） | 100 kW | 芯片直冷式液冷 |
| 风冷上限 | 每机柜约 30 kW | 物理上限；超过此值必须采用液冷 |
| PUE（液冷 AI） | 约 1.06 | 最佳情况：设施负载 ≈ IT 负载 |
| PUE（最佳风冷） | 约 1.12 | 超大规模数据中心的最佳实践 |
| PUE（行业平均） | 约 1.40 | 检查成本与碳排放估算的合理性 |
| H100 TDP | 每 GPU 700 W | IT 负载：10,000 \(\times\) 700 W = 7 MW |
经验法则：IT 负载（MW）=（GPU 数量 \(\times\) 每个 GPU 的热设计功耗（TDP））/\(10^6\)；设施负载 = IT 负载 \(\times\) PUE。一个配备 10,000 个 GPU 的 H100 集群，每个 GPU 的功耗为 700 W，其 IT 负载为 7 MW；当 PUE 为 1.40 时，设施总功耗为 9.8 MW。关于碳排放与成本，参见 节 1.4 和 Sustainable AI。
当前硬件参考（约 2025–2026 年）
这些数值（集群级硬件参考（约 2025--2026 年））反映了当前一代集群规模硬件的情况。可将其用于粗略估算，但预计这些指标会以约 2\(\times\) 的幅度每 2–3 年改善一次。
| 规格 | NVIDIA B200 | AMD MI300X | Google TPU v6e |
|---|---|---|---|
| BF16/FP16 峰值 | 2,250 TFLOP/s | 1,307 TFLOP/s | 918 TFLOP/s |
| 显存带宽 | 8 TB/s | 5.30 TB/s | 1.64 TB/s |
| HBM 容量 | 180 GB | 192 GB | 32 GB |
| 节点内互联 | 1,800 GB/s (NVLink 5.0) | ~890 GB/s (Infinity Fabric) | 800 GB/s 双向 (ICI) (Google Cloud 2026年) |
| TDP | 1000 W | 750 W | ~600 W（估算） |
就规模背景而言，一台 DGX H100 SuperPOD 包含 32 个 DGX H100 节点（256 个 H100 GPU）。Meta 宣布了两座基于 Grand Teton 硬件平台的 24,576-H100 数据中心级集群。Google 的张量处理单元（TPU）v5p 机舱可扩展至 8,960 片。截至 2025 年，已宣布的最大集群超过 100,000 个加速器。
扩展物理
上一节中的数字描述了硬件能够做什么。扩展物理描述的是当投入更多硬件时发生了什么。推理从单个加速器的上限——顶线——开始，然后追问在加入更多设备时什么会幸存下来，由三个模型支配：扩展至集群开销的 Amdahl 定律、通信与计算的比值，以及弱扩展行为。
单个加速器的顶线
集群性能建立在单加速器性能之上，而单个加速器受两种资源之一约束：其算术单元维持的速率（峰值 FLOP/s），或其内存交付操作数的速率（HBM 带宽）。究竟哪一种约束某个内核，取决于其算术强度 \(I\)，即每从内存移动一个字节所执行的有效运算数，如 公式 2 所定义：
\[ I = \frac{\text{FLOPs}}{\text{bytes moved}} \tag{2}\]
强度是工作负载的属性，而非硬件的属性。大型矩阵乘法具有高强度，因为从内存加载的每个权重都会在许多乘加运算中被复用；逐元素运算或单个 token 的生成具有低强度，因为每个加载值只在一到两次运算中被使用，随后就必须再次取回。
顶线模型 (Williams 等 2009年) 将强度转化为性能上限。公式 3 指出，可达到的吞吐量是计算上限与带宽受限斜率两者中的较小者：
\[ R_{\text{attain}} = \min\!\left(R_{\text{peak}},\; I \times \text{BW}\right) \tag{3}\]
以强度为横轴作图，公式 3 描绘出一条顶线：左侧是一条上升的带宽受限直线，右侧是一条平坦的计算上限。两者在脊点 相交，即工作负载首次使算术单元饱和的强度，由 公式 4 定义：
\[ I_{\text{ridge}} = \frac{R_{\text{peak}}}{\text{BW}} \tag{4}\]
强度为 \(I < I_{\text{ridge}}\) 的工作负载受内存约束：它位于斜线上，更快的算术单元不会带来任何改变，因为操作数无法及时送达。强度为 \(I > I_{\text{ridge}}\) 的工作负载受计算约束：它位于平坦的顶线之下，受算术单元本身所限。
对于 H100——BF16 峰值 989 TFLOP/s，HBM 带宽 3.35 TB/s——其脊点为 295.2 FLOP/byte。工作负载必须为每个取回的字节执行数百次运算，才足以让算术单元保持忙碌。
自回归解码远低于这条顶线，这正是它成为定义性服务瓶颈的原因。生成一个 token 需要从 HBM 中恰好读取一次模型的全部权重——16.1 GB 参数为 8B 的 BF16 模型——以完成约 16.1 GFLOP 的矩阵运算，强度为 1 FLOP/byte。该强度远低于脊点，因此单流解码完全受带宽约束：吞吐量为权重读取速率，约 208.6 tokens/s，无论加速器宣称的计算能力有多大。服务系统正是通过批处理大量请求来抬高这一强度，将每个权重读取分摊到批内每条序列，从而把解码推向计算顶线。
顶线是一条单加速器定律，但其逻辑才是可扩展的部分。在集群层面，约束带宽的不再是 HBM，而是互连结构，而所移动的字节是穿越网络的梯度与激活值。网络字节数与本地算术运算量之比即通信—计算比（节 1.3.3）：这是集群的顶线，也是本节其余部分采用的视角。
配置了 4,096 个 GPU 的训练任务所实现的吞吐量，仅为以下倍数：2.5×，其参照基准是使用 1,024 个 GPU 的运行。该观察结果意味着，在较大规模下，扩展效率约为 31.2 percent，因此，扩展物理规律提供了诊断工具，用于判断系统是否达到了物理规律允许的性能，或是否存在需要修复的工程问题。
集群规模下的 Amdahl 定律
Amdahl 定律指出，并行系统的最大加速比受其串行比例 \(s\) 限制。在集群规模下，“串行比例”不仅指顺序执行的代码——还包括所有迫使全部 \(N\) 个 GPU 等待的操作：
- 全归约同步：所有 GPU 都必须完成梯度计算，任一 GPU 才能继续执行。
- 流水线气泡：流水线并行的预热和冷却阶段会使部分流水线阶段处于空闲状态。
- 检查点写入：即使是异步检查点也会争用存储带宽。
- Python 层开销：训练循环中的单线程操作（数据加载、指标记录）。
为观察集群规模层面的影响，考虑一项训练任务，其中 10 percent 的墙上时钟时间用于同步、通信及其他串行开销。Amdahl 定律给出如下加速比：
- 使用 32 个 GPU：7.8× 加速比（约 24 percent 的扩展效率）
- 使用 256 个 GPU：9.7× 加速比（收益递减开始出现）
- 使用 1,024 个 GPU：9.9× 加速比（接近上限）
- 使用 8,192 个 GPU：10× 加速比（几乎达到 Amdahl 极限）
- 使用 \(N \to \infty\)：加速比上限为 10×
仅存在 10 percent 的串行开销时，无论硬件如何扩展，都无法为这项固定任务带来超过 10× 的加速比。这正是集群规模训练不会简单地在同一问题上增加更多 GPU，而是扩展问题本身（弱扩展）以保持串行部分相对总工作量较小的原因。
Systems Perspective 1.3: 复合开销陷阱
通信—计算比
任何分布式训练策略都必须判断同步点之间的计算是否足够长，从而掩盖通信开销。公式 5 定义了通信—计算比（\(\rho\)），直接回答这一问题：
\[ \rho = \frac{T_{\text{comm}}(N)}{T_{\text{compute}}/N} \tag{5}\]
当 \(\rho < 1\) 时，计算占主导，通信可以与之重叠。当 \(\rho > 1\) 时，系统处于通信受限 状态——GPU 更多时间用于等待数据，而非计算数据。
各代表性场景的通信—计算比（通信—计算比（ρ））揭示了并行策略必须与负载相匹配的原因。
| 场景 | \(T_{\text{comm}}(N)\) | \(T_{\text{compute}}/N\) | \(\rho\) |
|---|---|---|---|
| 数据并行，7B 模型，256 | 560.4 ms（IB NDR 上的 AllReduce） | ~5 s（前向+后向） | 0.11 |
| 数据并行，350M 模型，256 | 29.6 ms（IB NDR 上的 AllReduce） | ~10 ms（前向+后向） | 3 |
| 理想单向 16 MB 传输（NVLink） | ~0.04 ms（仅带宽下界） | ~1 ms（一层） | 0.036 |
7B 模型在 256 上实现 \(\rho =\) 0.11——通信耗时约为计算的 11.2 percent，可部分重叠。同一集群上的 350M 模型具有 \(\rho =\) 3——通信占主导，该配置处于通信受限状态。解决方案要么减少 GPU 数量（降低 AllReduce 中的 \(N\)），要么增加每步计算量（更大的批大小、梯度累积）。
对于单个 16 MB 点对点传输载荷，理想带宽下界为 \(\rho =\) 0.036。这并非张量并行集合模型，也无法单独判定某实现是计算受限还是通信受限。
集群规模弱扩展
Amdahl 定律描绘的图景较为悲观，因为它假设问题规模固定。实际上，集群规模训练常遵循弱扩展：问题规模（令牌、数据、模型参数）随 GPU 数量成比例增长。Gustafson 定律刻画了这一更为乐观的观点 (Gustafson 1988年)。
集群规模机器学习的关键洞见在于，弱扩展不仅是一种数学上的便利——它反映了现实。工程师不会用 8,192 个 GPU 更快地训练 7B 模型；他们用它来在合理时间内训练 70B 或 700B 模型。随着模型和训练批次的增大，工程师往往增加同步点之间的计算量。对于稠密 Transformer，计算量通常估计为约 6\(\times\) 参数 \(\times\) 令牌，而梯度通信随参数字节数增长，因此通信—计算比 \(\rho\) 取决于批大小、序列长度、累积和并行布局，而非仅取决于参数数量。
Systems Perspective 1.4: 集群利用率复合损失
\[R_{\text{eff}} = N R_{\text{peak}} \times \text{MFU} \times \eta_{\text{scaling}} \times \eta_{\text{operational}}\]
\[= 1,012,736 TFLOP/s \times 0.50 \times 0.50 \times 0.82 \approx 207,610.9 \text{ TFLOP/s}\]
该集群交付其峰值 FLOP/s 的 20.5 percent 作为有用的训练工作。剩余的 79.5 percent 可由 50 percent MFU、50 percent 扩展效率和 82 percent 运行有效吞吐这三个保留因子解释。
这些损失反映集群规模计算的物理特性，而非工程上的失败。每增加一个 GPU 所带来的边际有用工作都更少，但总吞吐量仍远高于较小集群所能达到的水平。目标并非达到 100 percent 的利用率；目标是在任何较小配置所能达到的速度之外，更快地交付训练完成的模型。
热与功率的物理原理
计算性能最终会转化为热量，而热量必须被散去。在集群规模下，热与功率约束并非次要问题——它们决定了哪些地点具备建设条件、加速器的部署密度可以有多高，以及运营成本将是多少。一个架构合理但散热不可行的集群无法建成。
一个集群设计若采用 10,000 个 H100 GPU，每个功耗为 700 W——即 IT 负载为 7 MW——且 PUE 为 1.40，则设施总负载将达到 9.8 MW。这相当于一个小城镇的电力负载。在优化软件之前，必须先确保供电与散热在物理上可行。
功率密度墙
从传统数据中心工作负载向 AI 训练的转变引发了功率密度危机。表 6 量化了这一差距。
| 配置 | 每机架功率 | 冷却要求 |
|---|---|---|
| 传统数据中心 | 12 kW | 标准风冷即可满足要求 |
| AI 集群（当前代） | 70 kW | 需要液冷 |
| AI 集群（高密度） | 100 kW | 需要芯片直接液冷 |
| 风冷上限 | ~30 kW | 强制空气对流的物理上限 |
机架功率密度从传统工作负载到 AI 工作负载提升了 5.8×，这不仅是一项工程挑战——它还构成了设施设计的根本性约束。为 12 kW 机架设计的现有数据中心无法简单地通过“改造”部署 AI 硬件。配电系统、冷却基础设施和楼面承重都必须重新设计。因此，新的 AI 数据中心从零开始建设，并以液冷作为基本设计前提。
大规模条件下的能耗层级
PUE 衡量设施的额外能耗：设施总能耗除以 IT 设备能耗 (The Green Grid 2007年; Uptime Institute 2022年)。PUE 为 1.0 意味着设施的全部能源都供给 IT 设备；高于 1.0 的部分表示冷却、电力转换、照明及其他设施系统的额外能耗。
表 7 比较了不同代际数据中心和不同冷却技术的 PUE。
| 数据中心类型 | PUE | 每 MW IT 负载的额外功耗 |
|---|---|---|
| 液冷 AI 数据中心 | 1.06 | 60 kW 冷却 + 基础设施 |
| 一流水平的风冷数据中心 | 1.12 | 120 kW 额外功耗 |
| 行业平均水平 | 1.40 | 400 kW 额外功耗 |
| 老旧企业数据中心 | 1.58 | 580 kW 额外功耗 |
在集群规模的成本计算中，PUE 是电费的直接乘数。10 MW 的 IT 负载在老旧数据中心（PUE 为 1.58）中需要 15.8 MW 的总功率，而相同负载在液冷设施（PUE 为 1.06）中仅需 10.6 MW——节省了 5.2 MW。按典型的商业电价计算，这一差异相当于每年数百万美元。Sustainable AI 全面讨论了对可持续性的影响。
摘要
Key Takeaways: 集群规模改变了每一项约束
- 三种范式，一套混合架构：ML 集群将 HPC 的紧密耦合（用于训练）与 WSC 的弹性容错（用于推理）结合起来，形成一种无法整体沿用任一前序范式的新架构范式。
- 带宽差距：NVLink 在每个方向上比 InfiniBand NDR 提供约 9× 的更高带宽。这一不变的比例决定了并行放置方式：张量并行置于节点内部，数据并行置于节点之间。
- 规模化后故障成为常态：集群 MTBF 按 \(1/N\) 缩放。在 8,192 个 GPU 的规模下，预计每 366.2 minutes 发生一次 GPU 故障，24 小时内故障概率为 98.04 percent。容错并非可选项——它是完成任何集群规模训练任务的前提。
- 复合利用率损失：当 MFU（约 50 percent）、扩展效率（约 50 percent）和运行有效吞吐（82 percent）的互不重叠因子相乘后，1,024 GPU 集群的峰值 FLOP/s 中仅约 20.5 percent 属于有效工作。
- 功率密度要求液冷：AI 机架的功耗是传统机架的 5.8×。当每机架超过 ~30 kW 时，风冷失效，因此液冷是现代 AI 集群的物理性要求。
- 通信—计算比（\(\rho\)）决定扩展策略：当 \(\rho > 1\) 时，GPU 因等待数据而空闲——减少并行度或增加每步计算量。当 \(\rho \ll 1\) 时，通信可以被完全重叠。
- 弱扩展是集群规模的范式：工程师不会用更多 GPU 更快地求解同一问题（强扩展），而是用更多 GPU 在合理时间内求解更大的问题。这保持了较小的串行占比和较高的利用率。