AI 基建
0%
第九部分 · 基础设施与算力 · 第 62 章

加速器与网络

作者Changkun Ou
阅读时长约 15 分钟

加速器规格不能预测应用性能。峰值算力、内存容量和链路速率,只是特定约定下特定操作的上限。有意义的性能结论还必须说明工作负载、张量形状、精度、软件栈、拓扑和测量方法。任何一项发生变化,瓶颈都可能转移。

本章建立一套用于分析这种转移的硬件模型。我们从一块加速器内部出发,沿着内存和互连追踪数据,最后说明如何测量完整系统。并行算法见 第 10 章;集群控制、检查点和数据平面属于 第 65 章

加速器究竟加速什么

加速器并不是一个巨大的算术单元。主机 CPU 启动程序、处理操作系统工作,并发起设备内核。设备内部则组合了通用并行执行单元、内存控制器、缓存和专用矩阵引擎。在 NVIDIA GPU 上,线程组按照单指令多线程(single-instruction, multiple-thread,SIMT)编程模型执行。其他厂商采用不同的名称与执行细节,因此不能把 SIMT 当成通用的加速器指令集 (NVIDIA 2026)。

矩阵引擎执行分块矩阵乘加。不同架构的分块形状、接受的输入格式、累加精度和指令语义并不相同。脉动阵列是一种可能的数据流设计,其中数值按节拍在处理单元网格中传递。Google 第一代 TPU 使用了公开记录的脉动矩阵单元,但这个事实不能证明所有 GPU 矩阵引擎或后续加速器都采用相同的物理实现 (Kung 1982; Jouppi et al. 2017)。

内核是把硬件变成实际工作的可执行单元。性能取决于张量维度是否适合可用的分块形状、内存访问是否合并、分支是否发散,以及是否有足够多彼此独立的工作占满设备。低精度输入可以减少存储与流量,原生低精度矩阵指令也可以提高峰值算力,但这些收益需要内核和形状与之匹配。精度转换、缩放、非矩阵运算和数值保护仍然会产生真实成本 (Micikevicius et al. 2022)。同样,只有工作负载确实采用了规定的稀疏模式和受支持的指令路径,结构化稀疏峰值才有意义。稠密峰值与稀疏峰值不能互换。

屋顶线是上界,不是诊断

屋顶线模型在一个明确指定的内存边界上,把算术运算与数据移动联系起来 (Williams et al. 2009)。其中,FF 表示内核执行的浮点运算次数,QQ 表示跨越该边界传输的字节数。两者之比为

I=FQI=\frac{F}{Q}

其中,II 是以每字节 FLOPs 表示的算术强度。PpeakP_{\mathrm{peak}} 表示所选指令和精度下的峰值算术吞吐量,BmemB_{\mathrm{mem}} 表示同一边界上的可持续带宽。由此得到上界

Pachievedmin ⁣(Ppeak,  IBmem).P_{\mathrm{achieved}} \le \min\!\left(P_{\mathrm{peak}},\;I B_{\mathrm{mem}}\right).

两个上限在屋脊点相交,其中 II^* 表示算术强度的分界值:

I=PpeakBmem.I^*=\frac{P_{\mathrm{peak}}}{B_{\mathrm{mem}}}.

低于 II^* 时,数据移动限制吞吐量;高于 II^* 时,算术上限可能变得更严格。但这并不意味着运行时吞吐量就等于这个上界。内核启动成本、依赖关系、占用率、缓存未命中、负载不均、功耗限制和不受支持的分块形状,都会让实际吞吐量低于上界。

字节数同样必须绑定到明确边界。若按高带宽内存(HBM)统计流量,一个内核可能具有很高的算术强度;若按某级缓存统计,强度却可能很低。报告中应说明 QQ 指的是 HBM 流量、主机与设备之间的流量,还是网络流量,并使用实测的可持续带宽,不能悄悄用厂商峰值代替。

容量、带宽、延迟与流量

在典型 GPU 内部,数据会在寄存器、由软件管理的共享内存、缓存和设备内存之间移动。封装在加速器旁的 高带宽内存(HBM),也就是高带宽内存,提供大容量的设备内存池。这些层级承担不同职责:

  • 容量决定权重、梯度、优化器状态、激活值、临时工作区、集合通信缓冲区和分配器余量能否全部容纳。服务还要加上 第 31 章 所述的 KV 缓存。
  • 带宽限制在给定访问模式下,每秒有多少字节能够跨越某个边界。
  • 延迟是依赖访问的结果可以使用之前需要等待的时间。并行性可以隐藏部分延迟,却无法绕过尚未满足的依赖。
  • 流量是程序实际导致移动的字节数。内核融合、重计算、分片、缓存和数据布局都能改变流量,而链路的额定带宽可以保持不变。

容量不等于带宽,二者也都不等于利用率。一项工作负载可能完全放得进 HBM,却因为反复流式读取数据而运行缓慢;另一项工作负载在同样的 HBM 配置上仍可能受算力限制。比较结果之前,必须明确流量在哪一层计数。

数据继续向外移动时,也要保持同样的谨慎。下面的交互图展示的是概念层级,并非实测比例。不同系统的域大小、方向性、端点注入能力和可持续吞吐量各不相同。

图 62.1. 数据从矩阵引擎到另一块加速器,需要跨越多道边界。图中速率仅作示意;实际部署时应逐层测量。

互连是一套分层协议栈

“网络”这个词掩盖了三个彼此独立的设计层:

  1. 物理拓扑。 链路和交换机决定跳数、路径多样性、故障域、端点注入、对分带宽和超额订阅。即使端点链路很快,超额订阅的交换结构也不会因此变成无阻塞网络。
  2. 传输层。 PCIe 和 NVLink 在部分系统内部传输数据;InfiniBand 或采用 RoCE 的以太网则承担 scale-out 交换结构上的传输。每种传输覆盖的物理范围取决于具体产品。有些 NVSwitch 系统只连接一台小型服务器,新一代设计则能把 NVLink 域扩展到整个机架 (NVIDIA 2026)。
  3. 集合通信库。 NCCL 等软件把逻辑操作映射到现有路径与算法。它能感知拓扑,却无法凭空创造对分带宽,也无法修复糟糕的 rank 放置 (NVIDIA 2026)。

远程直接内存访问(RDMA),也就是远程直接内存访问,允许网络适配器直接在已注册的内存区域之间传输数据,不让主机 CPU 进入数据路径。RoCE 在以太网上提供 RDMA 语义,InfiniBand 则在自己的网络协议栈中提供这些语义。GPU-direct 变体可以把 GPU 内存暴露给对端设备,但内存注册、PCIe 布局、驱动程序和同步仍然重要 (NVIDIA 2026)。“绕过 CPU”描述的是数据路径,并不表示系统无需 CPU 完成设置或控制工作。

因此,scale-up 和 scale-out 是有用的描述,却不是“节点内”和“节点外”的固定同义词。应记录真实的端点与交换机。不要把双向汇总的 NVLink 数字与单向 NIC 速率比较,也不要把交换机总带宽与单设备注入带宽混为一谈。

集合通信既有语义,也有算法

集合通信的语义规定一组 rank 最终各自收到什么:

  • 广播(broadcast): 把一个根 rank 的缓冲区复制到所有 rank;
  • 全归约(all-reduce): 合并所有 rank 的数值,再把结果返回给每个 rank;
  • 全收集(all-gather): 在每个 rank 上拼接所有 rank 的分片;
  • 归约散布(reduce-scatter): 合并数值,并让每个 rank 保留一个结果分片;
  • 全交换(all-to-all): 每个 rank 都向其他每个 rank 发送不同的分片。

这些语义并不决定算法。全归约可以使用环、树、分层组合或其他调度方式。集合通信库还可以把一项语义操作拆成多个阶段。在归约与布局一致时,归约散布后接全收集,等价于全归约 (NVIDIA 2026)。

一个简单的延迟与带宽模型可以显出其中的取舍。对于包含 nn 字节的消息,

Tmsg(n)=α+nβ,T_{\mathrm{msg}}(n)=\alpha+n\beta,

其中,α\alpha 是每条消息的启动延迟,β\beta 是每字节所需秒数,也就是有效带宽的倒数。在由 pp 个 rank、等速链路组成,且没有争用和重叠的理想化环中,一次大消息全归约的时间近似为

Tring(n,p)2(p1)α+2(p1)pnβ.T_{\mathrm{ring}}(n,p)\approx 2(p-1)\alpha+\frac{2(p-1)}{p}n\beta.

对于大消息,环算法具有较高的带宽效率,因为每个 rank 大约传输 2(p1)n/p2(p-1)n/p 字节;但它包含 2(p1)2(p-1) 个阶段,所以小消息的启动成本很高 (Patarasuk and Yuan 2009)。树算法会改变延迟项与流量模式。实际结果还会受到协议选择、分块、归约计算、路由、拥塞和链路不均的影响。

只有依赖图暴露出独立工作,而且运行时成功地并发调度两者,通信才能与计算重叠。分桶大小、内核持续时间、流优先级、内存压力和并发流量都会改变可重叠窗口。这里,TcompT_{\mathrm{comp}} 表示独立测得的计算时间,TcommT_{\mathrm{comm}} 表示独立测得的通信时间,ToverlapT_{\mathrm{overlap}} 表示两者重叠的时间。核算恒等式

Tstep=Tcomp+TcommToverlap,0Toverlapmin(Tcomp,Tcomm)T_{\mathrm{step}}=T_{\mathrm{comp}}+T_{\mathrm{comm}}-T_{\mathrm{overlap}}, \qquad 0\le T_{\mathrm{overlap}}\le \min(T_{\mathrm{comp}},T_{\mathrm{comm}})

把条件明确写了出来。剖析结果可能显示,某次集合通信在一个模型形状中完全隐藏,却在批次大小、放置方式或软件改变后暴露出来。

要放置的是通信图,不是缩写

每种并行方法都会产生不同的通信图。下表列出的是常见模式,不是固定的操作次数。

方法 常见流量 放置问题
张量并行 取决于具体形式,每层可能出现全归约、归约散布、全收集或点对点流量 频繁的激活流量能否放进实测的 scale-up 域,同时又不让小消息延迟成为主导因素?
序列并行 在跨越序列维度的操作前后交换激活分片 节省的内存能否抵偿新增的集合通信和布局变化?
上下文并行 在上下文分片间交换注意力键值或部分结果 序列长度、因果负载均衡,以及环或全交换流量应如何映射到拓扑?
专家并行 用全交换完成分发与合并 放置与容量能否承受倾斜的专家负载和突发的对分带宽需求?
数据并行 通常可与计算重叠的分桶梯度归约 能否负担一份完整模型副本?哪些分桶会暴露通信?
完全分片数据并行 参数全收集与梯度归约散布,优化器状态也进行分片 更低的内存占用,是否足以补偿重复的参数流量和预取缓冲区?
流水线并行 每个微批次都要在阶段边界传递前向激活和反向梯度 阶段平衡、边界张量大小与流水线气泡,是否足以支持增加更多阶段?

Megatron 最初的张量并行布局是一个重要案例,不是普遍规律。在它采用的 Transformer 形式中,每一层的前向传播使用两次全归约,反向传播也包含相应的归约 (Shoeybi et al. 2019)。后续组合会改变操作与重叠调度。数据并行系统可以使用全归约,也可以在 ZeRO 和完全分片设计下使用归约散布与全收集 (Rajbhandari et al. 2020)。流水线流量会随微批次重复出现,而不是每步只交接一次 (Narayanan et al. 2021)。专家并行及其全交换行为见 第 9 章

实用的映射方法会测量或估算每条边的字节数、频率、延迟敏感度、节省的内存和可用重叠窗口,再把最重或对延迟最敏感的网格维度映射到足够快的物理维度。“TP 放在内部、DP 放在外部”只是一条常用的起始经验,并不是证明。面对机架级交换结构、非对称网络,或以上下文流量和专家流量为主的工作负载时,尤其不能把它当成定律。

TPU v4:一个边界明确的案例

张量处理器(TPU) pod,也就是由 Google 张量处理单元组成的集群,说明拓扑结论为什么必须标明硬件代际。TPU v4 使用 芯片间互连(ICI),也就是连接 TPU 芯片的芯片间互连,并借助光路交换机配置三维环面切片。扭转环面只是其中一种受支持的选择,交换机还能在部分组件不可用时重新配置路径 (Jouppi et al. 2023)。这个结论只适用于 TPU v4,并不表示每一代 TPU pod 都使用同一种环面。

GSPMD 是一套编译器分区系统。它把用户给出的分片注解传播到计算图中,并以逻辑设备网格为目标 (Xu et al. 2021)。它不会自行让物理拓扑变快,也无法消除多跳通信。同样,图形处理器(GPU) 集群,也就是使用图形处理器作为加速器的集群,可以在 PCIe、NVLink、InfiniBand 或以太网上暴露多个逻辑网格。两种情况下,编译器和运行时都需要准确的物理映射。

这里的结论只针对具体代际:必须把加速器架构、逻辑分片和物理拓扑放在一起理解。

精度与可移植性是两份不同的契约

精度改变的不只是一个数字。输入存储、乘法、累加精度、输出格式、缩放策略和归约精度都可能不同。例如,FP8 定义了 E4M3 和 E5M2 两种交换格式,但准确的训练方案还需要确定哪些张量采用这些格式,以及哪些位置需要更宽的累加精度或缩放 (Micikevicius et al. 2022)。比较峰值时,必须采用同一种稠密或结构化稀疏约定,并确认工作负载实际使用了对应的指令路径。数值与内核方面的后果见 第 34 章

可移植性同样分为多层:源码兼容、数值正确、功能可用和性能可移植。一个框架后端也许能让同一模型在两类加速器上运行,但自定义内核、集合通信算法、受支持格式和最佳张量形状仍可能不同。应把模型与分片意图放在厂商适配层之上,隔离自定义内核,并在每个目标上重复同一套正确性与性能矩阵。

MFU 是一个核算比率

模型 FLOPs 利用率(MFU)把有用模型工作的解析估算值,与所选硬件峰值进行比较 (Chowdhery et al. 2023)。其中,FmodelF_{\mathrm{model}} 是每个全局步骤中有用模型 FLOPs 的估算值,NdeviceN_{\mathrm{device}} 是加速器数量,PpeakP_{\mathrm{peak}} 是所声明精度及稠密或稀疏路径下的单设备理论峰值 FLOP/s,tstept_{\mathrm{step}} 是实测的每步秒数。比率为

MFU=FmodelNdevicePpeaktstep.\mathrm{MFU}= \frac{F_{\mathrm{model}}} {N_{\mathrm{device}}P_{\mathrm{peak}}t_{\mathrm{step}}}.

发布 MFU 时,应同时公开 FLOP 计数约定、全局批次与序列形状、用于峰值计算的声明精度、加速器数量和计时边界。使用稠密峰值计算的 MFU,不能与使用结构化稀疏峰值计算的 MFU 直接比较。稀疏模型和混合专家模型还需要说明活跃参数和路由词元的明确约定。

硬件 FLOPs 利用率(HFU)使用已执行算术量的估算值作为分子,其中可能包含重物化,也称为激活重计算。如果核算口径一致,重物化会让 HFU 高于 MFU,因为硬件重复执行了部分前向工作。二者都不是硬件计数器,MFU 也不是诊断结果。MFU 偏低可能源于内存流量、暴露的集合通信、流水线气泡、小内核、输入停顿、热降频、故障,或不一致的 FLOP 估算。应同时报告每秒词元数、步时分布、实际内存与集合通信带宽、内核时间线、功耗、时钟频率和错误遥测。

从组件一直测到完整运行

应按证据阶梯逐层测量。完整模型基准只能说明某处发生了变化,组件测量才能定位变化落在哪一道边界。

测量速度之前,先确认设备数量、内存容量、ECC 状态、链路状态、时钟频率、功耗上限和拓扑。
用具有代表性的大小,测量可持续 HBM 带宽、缓存敏感内核、主机到设备复制和点对点路径。
针对不同消息大小、组形状、rank 放置和并发组,扫描全归约、归约散布、全收集和全交换。
运行具有代表性的张量维度与精度,并保留内核、启动、内存和同步时间线。
测量真实的批次、序列分布、分片方案、每秒词元数、MFU 口径,以及收敛或质量边界。
运行足够长的时间,以观察尾部、拥塞、功耗与温度漂移、链路降级、故障恢复和检查点开销。
图 62.2. 只有把组件上限与端到端行为和长期运行连接起来,性能结论才可信。

每项基准都应记录硬件 SKU 与修订版本;驱动程序与固件;编译器、框架和集合通信库版本;精度与稀疏模式;张量维度;批次与序列分布;消息大小;物理拓扑与超额订阅;rank 放置;算法与协议;预热轮次和测量轮次;单向还是双向口径;p50、p95 和 p99;并发流;以及功耗与温度。单节点微基准不能证明集群扩展能力。

运行记录应保留足够的上下文,以便复现与比较结果:

accelerator_system:
  hardware: {device: ..., count: ..., memory: ..., power_limit: ...}
  software: {driver: ..., firmware: ..., compiler: ..., framework: ..., collective_library: ...}
  workload: {model_revision: ..., batch: ..., sequence_distribution: ..., precision: ..., flop_convention: ...}
  topology: {scale_up_domain: ..., scale_out_fabric: ..., oversubscription: ..., rank_placement: ...}
  measurements: {window: ..., warmup: ..., repetitions: ..., throughput: ..., mfu: ..., latency_percentiles: ...}
  health: {link_errors: ..., ecc: ..., device_errors: ..., clocks: ..., power: ..., temperature: ...}

应把这些记录与同步的作业、rank、节点、加速器、NIC、交换机、机架供电和冷却域标识符关联起来。集合通信超时可能源于软件排序错误、rank 失效、链路降级或拥塞,单一利用率计数器无法区分这些原因。可靠性和静默故障见 第 69 章;设施供电与冷却约束见 第 68 章

回归场景

  • 小消息延迟: 逐步减小消息,直到启动成本占据主导,并验证所选集合通信算法与 p99 仍然可以接受。
  • 大消息带宽: 扫描超过缓存容量的消息,确认可持续带宽而不是峰值带宽,且不能假定集群会线性扩展。
  • 超额订阅上行链路: 把相互通信的 rank 放在受限切面的两侧,并验证准入、路由和性能告警。
  • 链路降级: 降低一条路径的速率或移除该路径,确认拓扑发现、重新路由行为及其造成的尾部延迟。
  • rank 放置变化: 在同一硬件上重新排列 rank,并检测通信切面变大造成的性能回归。
  • 集合通信超时: 在测试作业中停止一个 rank 或故意违反集合通信顺序,并验证失败有界、能够诊断且完成清理。
  • 静默数据损坏: 注入可检测的故障,确认端到端校验、隔离与恢复都生效,不能只依赖设备告警。
  • 热降频: 运行长时间测试或采用受控功耗上限,确认时钟、功耗、温度、吞吐量和调度器证据始终保持关联。
  • 软件变更: 修改一个驱动、编译器、内核或集合通信库版本,再以相同形状、放置和统计比较重跑测试。
  • 容量边界: 逐步接近内存预算,并计入临时缓冲区和分配器余量,验证确定性的准入或失败行为。这个场景与 第 32 章 相连。
争议所在

scale-up 边界正在变化。机架级交换结构可以扩大频繁模型并行流量仍可承受的范围,但也会改变成本、功率密度、故障域和软件假设。scale-out 交换结构同样在进步,而并行方法也在减少、重塑或隐藏流量。不存在张量并行必须在某个固定设备数停止的永恒规则。答案是工作负载与实际部署系统的实测属性。

下层约束

硬件确实会限制上层算法,但它通过一组约束共同限制,而不是只靠一个带宽比率:可用内存、可持续本地流量、集合通信延迟、对分带宽、拓扑、功耗和故障域。第 10 章 选择的映射必须同时满足这些条件。随后,操作系统和调度器还要按照 第 32 章 的要求,保留设备局部性和内存余量。在实测通信图能够放进物理机器之前,纸面上的并行方案只是一项假设。

这套方法可以浓缩成四步:指明边界、定义口径、测量真实形状,并保留上下文。只有完成这四步,峰值 FLOPs、链路速率和 MFU 才有明确含义。

延伸阅读

  • Williams et al., “Roofline: An Insightful Visual Performance Model for Multicore Architectures” (以运算强度解释计算受限与带宽受限性能的模型), 2009. osti.gov
    Roofline 将可达性能与运算强度、峰值算术速率和可持续内存带宽联系起来。
  • Kung, “Why Systolic Architectures?,” 1982. eecs.harvard.edu
    Kung 将脉动阵列解释为一种规则阵列:数据有节奏地流过处理单元,从而利用并行性与局部性。
  • Jouppi et al., “In-Datacenter Performance Analysis of a Tensor Processing Unit,” 2017. research.google
    本文记录了首代量产 TPU,包括其软件管理内存与 256 乘 256 矩阵乘法单元。
  • NVIDIA, “CUDA Programming Guide” (持续更新的官方编程模型文档), 2026. docs.nvidia.com
    CUDA 指南定义了主机与设备模型、SIMT 执行、内存空间及架构特定的加速器功能。
  • Micikevicius et al., “FP8 Formats for Deep Learning” (E4M3 与 E5M2 格式,以及包含 175B 参数语言模型的实验), 2022. arXiv:2209.05433
    本文规定 E4M3 与 E5M2 两种 FP8 交换格式,并在多类神经网络上评估相应训练方案。
  • Patarasuk & Yuan, “Bandwidth Optimal All-Reduce Algorithms for Clusters of Workstations,” 2009. cs.fsu.edu
    本文推导通信下界,并在明确的拓扑假设下给出适用于大消息的带宽最优环形全归约。
  • NVIDIA, “NCCL User Guide: Collective Operations” (持续更新的官方集合通信语义文档), 2026. docs.nvidia.com
    NCCL 指南定义了 GPU 集合通信语义,包括全归约、全收集、归约散播、广播与全交换。
  • NVIDIA, “GPUDirect RDMA Documentation” (GPU 对等设备 DMA 路径和内存注册的官方文档), 2026. docs.nvidia.com
    该指南说明对 GPU 内存进行对等设备直接访问所需的注册、拓扑、驱动与同步条件。
  • NVIDIA, “NVL72 AI Factory: System Hardware and Components” (机架级 NVLink 域的官方参考架构), 2026. docs.nvidia.com
    该参考架构记录了一个 72 GPU 的机架级 NVLink 域,说明纵向扩展并不必然局限于单台服务器。
  • Shoeybi et al., “Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism,” 2019. arXiv:1909.08053
    Megatron-LM 提出 Transformer 训练的层内张量并行方案,并测量其通信与扩展行为。
  • Narayanan et al., “Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM” (GPU 集群上的 3D 并行), 2021. arXiv:2104.04473
    本文组合张量、流水线与数据并行,并分析大规模 Transformer 训练的流水线调度。
  • Rajbhandari et al., “ZeRO: Memory Optimizations Toward Training Trillion Parameter Models,” 2020. arXiv:1910.02054
    ZeRO 对优化器状态、梯度与参数进行分片,在改变通信调度的同时消除数据并行的内存冗余。
  • Xu et al., “GSPMD: General and Scalable Parallelization for ML Computation Graphs” (作为 JAX pjit 底层机制的 XLA 与 TPU 分片标注), 2021. arXiv:2105.04663
    GSPMD 在计算图中传播张量分片标注,并生成分区后的单程序多数据程序。
  • Jouppi et al., “TPU v4: An Optically Reconfigurable Supercomputer for Machine Learning with Hardware Support for Embeddings” (利用光路交换改变机器学习系统拓扑的已部署实例), 2023. arXiv:2304.01433
    TPU v4 使用光路交换机配置和重配置大型加速器互连。
  • Chowdhery et al., “PaLM: Scaling Language Modeling with Pathways,” 2023. jmlr.org
    PaLM 论文将模型 FLOPs 利用率定义为模型级效率指标,并在有用工作口径中排除重物化计算。

评论

登录后评论