哈佛-CS249r-机器学习系统第二卷-一-

哈佛 CS249r：机器学习系统第二卷（一）

原文：Machine-Learning-Systems-Vol2

译者：飞龙

协议：CC BY-NC-SA 4.0

哈佛 CS249r：机器学习系统第二卷

献词

献给 Kari，她给了我写作此书所需的时间，从未索要回来。也献给 Nora 和 Maya，她们是这一切变得有意义的原因。

作者的话

当新模型发布时，全世界的目光都聚焦于模型本身。几乎没有人关注背后的集群舰队。

然而，在每一个前沿模型的背后，都矗立着成万上万的加速器，它们通过网络严格同步运作——一个缓慢的链路就能拖垮整个训练任务；由移动兆瓦级热量的系统进行冷却；由将故障视为计划内事件而非异常的协议维持生存。这一切都无法塞进发布公告里。模型得到了论文，集群舰队顶多只能得到一个脚注，甚至连脚注都没有。

本书旨在论证：舰队值得的不止是一个脚注。我们以前构建过庞大的分布式系统，但从未有过像这样的系统，因为其他系统从未需要同时在两件事上都“正确”。电话网络必须保持可用；它从未需要收敛。互联网必须投递数据包；它从未需要保持包内梯度的完整。舰队必须两者兼顾。它必须像任何分布式系统一样移动数据，同时在移动过程中保持学习的数学特性完好无损。节点掉线不仅损耗算力；它还可能破坏训练步骤所依赖的同步机制，而单个步骤的损坏就能毁掉数天的工作成果。这种计算与统计的双重义务，在规模堪比小型校园的层面上持续维持，正是本书所要呈现的工程图景。

这种义务并不随训练结束而终结。无法训练的模型只是个想法，而非系统。无法服务的模型只是个研究成果，而非产品。无法治理的模型只是个负债，而非资产。在每一个阶段——从首个分配的节点到最后一个被服务的请求——舰队决定了什么是可能的，什么只停留在想象中。

每一章背后的问题很容易提出，却难以回答：究竟需要什么，才能构建不止一个、而是一千个机器学习系统，让它们协同工作，并负责任地运行它们。我相信，这是这一代人面临的一个决定性工程问题，而那些承担这一使命、却鲜少登上头条的人们，值得拥有一本将其视为核心课题的书。

— Vijay Janapa Reddi

马萨诸塞州，剑桥

2026 年

本书适读对象

本书面向所有在单机上理解机器学习、如今却面临如何使其大规模落地挑战的读者。规模带来的问题，绝非单节点问题的简单放大。它们在质上截然不同：网络会分区，硬件故障成为统计上的必然，而每个设计决策的社会影响都会被百万级用户放大。

涵盖范围从 AI 数据中心物理底座的设计，到突破单加速器极限扩展训练，再到当生产舰队面向全球用户群服务时会发生什么的推理。全书始终聚焦于分布式的物理本质——那些无论框架、模型或时代如何更迭，都统治着舰队级 ML 系统的不变量。

为何需要舰队级教材

2012 年，在两块 GPU 上训练 AlexNet 需要五到六天（Krizhevsky 等，2012）。到 2023 年，公开的 GPT-4 级别估算显示，前沿训练约需 25,000 块 GPU 运行约三个月（SemiAnalysis 2023）；OpenAI 并未披露实际硬件配置（OpenAI 等，2023）。这并非同一个工程问题的放大版。这是一个范畴上完全不同的工程问题。

在单机上，性能受限于“内存墙”——处理器速度与内存带宽之间的鸿沟。在分布式集群中，一堵新墙浮现：“分割带宽墙”，即网络拓扑中最小分割带宽限制了系统总吞吐。数据不再仅在本地层级间流动；它穿越光纤结构，受限于机架间、跨大陆的光速。在单机上罕见到可视为异常的硬件故障，在舰队规模下成为常态统计事件。不为故障做计划的训练作业，必将失败。

这些不是运维烦恼。它们是物理约束——与内存墙、阿姆达尔定律、数据移动能耗一样基本且永恒。它们要求建立自己的工程学科，拥有自己的不变量：

分割带宽定理：分布式系统的性能受限于网络拓扑中最小的分割带宽。
舰队定律：每个训练步骤都要支付一笔通信税，随集群规模增长而增加，而单节点计算却在缩减。
Young-Daly 检查点定律：最优检查点间隔在写入状态的成本与因故障导致的预期工作损失成本之间取得平衡。
服务成本主导定律：对于高流量生产模型，累计推理运营支出可能超过一次性训练成本，使服务效率成为全生命周期的优化目标。
公平性不可能定律：当不同群体的基础比率不同时，没有任何系统能同时满足校准、机会均等和人口统计学均等。

如果单机 ML 系统工程问的是“单台机器能构建什么？”，那么舰队级 ML 系统工程问的则是“一千台机器能共同构建什么，以及在可靠性、效率和社会层面要付出什么代价？”

正是最后这个从句，将舰队级工程区分开来。单台机器影响其用户；舰队影响其输出触及的每一个人，每秒数百万次决策。在该规模下，可靠性、效率和公平性不再是功能特性，而成为如带宽、功耗般具备约束力的工程约束。一个能扩展却不可信的系统，未被工程化，仅被放大而已。

本书提供了这一基石。它遵循 Hennessy 和 Patterson 的教学范式，将定量的、原则优先的方法延伸至分布式规模（Hennessy 和 Patterson，2011；Hennessy 和 Patterson，2019；Patterson 和 Hennessy，2017）。正如他们的著作教会一代人从第一性原理推理处理器性能，本书教导读者推理舰队性能——用度量取代对分布式系统的直觉，用工程取代临时抱佛脚式的扩展。

《机器学习系统导论》教授了砖块：张量、内核、内存层级和优化循环，它们组成了任何单节点系统。舰队不是由更多砖块堆砌而成。它是一个乐团。独奏家能演奏出非凡优美的乐章，但乐团绝非仅仅许多音乐家同时演奏。它需要指挥、乐谱、精准的同步，以及在演奏者掉链子时优雅恢复的能力。音乐厅的声学特性以单个乐器无法控制的方式塑造声音。支配乐团表现的原则——协调、通信延迟、容错、表演空间的物理特性——与支配独奏者的原则在范畴上截然不同。ML 舰队的工作原理相同。训练集群、服务舰队和边缘部署是截然不同的系统，但它们之下坐落着相同的基石：并行策略、集体通信原语、检查点协议、调度算法，以及吞吐量、延迟、容错与成本之间的权衡。

本书内容概览

本书聚焦于 机器学习舰队：一种仓库级计算机，其中网络即总线、功率密度即速度极限、故障并非例外而是统计上的必然。这是现代 ML 计算的基本单元，在此处，过大无法由单一设备承载的模型跨越数千个加速器进行训练，服务于数百万用户，并受制于横跨工程、经济与社会的诸多约束。

内容组织为四个部分：

第一部分：舰队 从底层构建 AI 数据中心的物理基底：分布式 ML 系统全景、算力基础设施的芯片与散热、连接数千个加速器的网络架构，以及为训练流水线供给数据的可扩展数据存储。
第二部分：分布式 ML 确立超越单机的分布逻辑：面向无法由单一设备容纳的模型的并行策略（数据、张量和流水线）、同步梯度的集体通信原语、在故障成为常态时保障可靠性的容错机制，以及管理舰队的编排系统。
第三部分：大规模部署 将训练好的模型从集群推向世界：面向效率的性能工程、大规模推理服务、面向资源受限设备的边缘智能，以及管理生产舰队所需的运营全生命周期。
第四部分：负责任的舰队 直面决定舰队是服务用户还是危害用户的诸力量：安全与隐私、鲁棒系统设计、环境可持续性，以及负责任工程——这些约束与功率密度或剖分带宽一样基础。

这四部分勾勒出一条贯穿 舰队栈 的路径，该分层抽象将经典 ML 系统栈延伸至分布式规模。底层为 设施与加速器 与 网络与存储，构成物理基底。向上为 分布式执行 与 可靠性与控制，管理并行作业、通信、调度与恢复。再往上为 运行时与服务 与运营，将模型交付用户并管理生产全生命周期。顶层为保障与 治理与可持续性，将信任、风险、策略与环境成本转化为工程约束。每层向上提供抽象、向下消费底层。底层的工程决策约束了顶层的可能性。

全书贯穿始终的页边图标会高亮显示每章所涉及的层级，在每章开头提供导航提示：

上述完整栈展示了每行及其范围，按本书的四个部分分组。罗马数字（I–IV）标记这些部分；行强度标记重点。栈全程使用第二卷的一个强调色，因此是深浅（而非色相）传递章节聚焦信号。

书中的页边图标中，每层的强度反映了该章与该层级的关联程度——越亮（强度越高）表示该章的主要关注点；越暗（强度越低）表示随着约束向上传播的上下文相关性。以三章为例，说明重点如何转移：

在“算力基础设施”一章，底层占主导，因为该章关注芯片、电源、散热与物理部署。在“分布式训练”一章，分布式执行 最亮，而 可靠性与控制 依然清晰可见，因为大规模训练运行依赖调度与恢复。在“负责任的 AI”一章，治理与可持续性 为主，保障依然强劲，因为问责制依赖可衡量的信任与风险控制。同一栈，三个不同故事：一层的决策会在其上下层产生涟漪效应。

无论何处，只要用肉眼一眼看懂关系最快，页边就会放置小型视觉注释。它们是阅读辅助，而非供后引用的图表。在舰队规模下，这种视觉语法让带宽缺口、故障波及半径、检查点比率、边缘能耗权衡一目了然，且不打断论述。当微型图使用对数坐标时，会在图内标明。

各部分层层递进，建议按顺序阅读。下文的阅读路径为有特定目标的读者提供备选方案。

建议阅读路径

不同背景和目标的读者可从以下几条路径中选择：

完整路径 按顺序阅读所有章节，遵循支配 ML 舰队的约束因果链。物理芯片与散热极限决定数据中心布线，进而决定数据如何供给。硬件就绪后，算法将数学运算划分其上，要求精确的网络路由机制与应对不可避免硬件损耗的生存能力。这支幸存的舰队必须经过调度、调优并扩展以服务数百万用户。最终，如此规模的部署要求严谨的运营框架，这与保卫系统、确保其负责任地服务社会密不可分。此路径从分布式第一性原理发展出每个概念。

基础设施路径 聚焦物理舰队与编排。读者应重点关注第一部分（算力基础设施、网络架构、可扩展数据存储）与舰队编排。此路径构建对物理与运营基底的深度理解。

扩展路径 深入分布式训练。读者可略读第一部分以获取基础设施词汇，然后聚焦分布式训练、集体通信、容错与性能工程。

生产路径 覆盖部署与运营。读完引言后，转至大规模推理、大规模运营、边缘智能与负责任的舰队章节。此路径涵盖从服务架构到治理的所有内容。

约定

本书使用一小组排版约定来标识每段文字的功能。

粗体标记首次定义

正文中以粗体出现的术语，即为其在本卷中的正式首次引入。每个术语仅获此待遇一次。后续出现不再加粗；届时该术语已成为本章承继的工作词汇一部分。

每个机器学习系统都有 双重使命：必须同时管理统计不确定性与物理约束。

粗体是一种契约：记下这个术语，它会反复出现。书末的匹配索引条目指向定义处，提供回溯途径。

粗体还有一种结构性角色：作为突出框内条目或摘要要点开头的功能性标签——例如 建议：、权衡： 或 结果：。在此语境下，粗体是脚手架而非首次定义。

斜体承担特定修辞任务

斜体不用于一般强调。本书中每一处斜体都执行少数特定任务之一：

直接对立：训练对推理，逻辑对物理。

正文内容

作为物理、数学或逻辑定律陈述的“不可能”：“物理学禁止亚 10 毫秒系统使用遥远的云基础设施。”
词汇本位用法：“术语梯度指的是偏导数向量。”
论点点睛之笔：一个斜体句子，捕捉某个章节的核心洞见，例如 Data is Source Code.

斜体单词承担上述职责之一。非斜体单词不带有隐含的强调意味。

标注框拥有与其职责相匹配的视觉标识

标注框不是装饰。每种类型都标示一种特定类型的内容，因此视觉标识会在读者阅读前宣告该框包含什么。

| 标注框 | 包含内容 |

| --- | --- |

| 定义 | 关键术语的正式定义，包含其意义、与近邻概念的区别，以及常见误区 |

| 示例 | 历史案例或具体场景，结构为背景、洞见和系统教训 |

| 视角 | 丰富周围论证的分析性观察或数学细微差别 |

| 笔记本 | 逐步演示的计算过程，数值根据本书常量内联计算而得；中间表格和方程即是数学本身 |

| 检查点 | 用于验证对前一节理解程度的自测问题 |

| 实战故事 | 真实的生产故障，结构为背景、故障、后果和教训 |

| 灯塔 | 由档案（参数、FLOPs、主要约束）刻画的反复出现的工作负载，作为跨多章的锚定案例研究 |

| 原则 | 书中确立的典范原则或不变量，供后续章节引用 |

| 定理 | 有方程支撑的正式结果或界限，陈述其条件并在后续定量分析中应用 |

| 要点 | 一章中四到七个最重要的结果，以总结形式呈现 |

| 章节衔接 | 从刚结束的章节到即将开始的章节的桥梁，点出下一章将解决的开放性问题 |

当标注框包含表格、图表或方程时，该工件是标注框教学单元的一部分，而非装饰。灯塔的档案就是其刻画。笔记本的中间表格就是演算数学。将这些作为分离的工件阅读会失去教学脉络。相比之下，独立参考表格位于段落之间，作为编号工件，读者可通过 @tbl- 引用返回查阅；每卷末尾的表格列表收录了它们。两种形式均有效；视觉标记（标注框 vs. 独立）告知读者他们正在查看哪一种。

一个学习平台

无论读者选择哪条路径，本书都是更广泛学习生态系统的一个组成部分。完整文本、交互式 Colab 笔记本、讲座幻灯片、练习、动手实验，以及每章的补充材料，均可在 mlsysbook.ai 免费获取。

一本开源教材

本书在开放环境中构建。其全文、图表和构建系统位于 mlsysbook.ai/git，欢迎每位读者贡献。

这是一个深思熟虑的选择。如果 AI 工程要成为一门共享的学科，而非孤立实践的集合，其基础文本必须人人可及。ML 系统是一个由全球产业界、学术界和开源社区的从业者共同塑造的领域。覆盖该领域的教材应反映这种广度，并对所有人开放，无论地域或机构隶属关系。

读者的贡献，无论是修正错误、建议更清晰的解释、增加演示案例，还是提出新内容，都实质性地改进了每一章。鼓励发现可改进之处的读者提出 Issue 或提交 Pull Request。本书因读者参与构建而日益完善。

先修要求

读者应具备以下背景：

单机 ML 系统：理解 ML 工作流、神经网络训练、模型优化及单机部署。读者应能舒适地推理内存层级、计算图和硬软件交互。
编程：精通 Python，包括函数、类及使用 NumPy 进行数据操作。熟悉至少一种 ML 框架（PyTorch、TensorFlow 或 JAX）。
数学：熟悉本科水平的线性代数、基础微积分和概率论。

以下背景有帮助但非必需：

分布式系统：熟悉网络概念（TCP/IP、带宽、延迟）、并行性和基础分布式计算，能加深对车队基础设施和训练章节的理解。
云基础设施：具有容器编排（Kubernetes、Docker）或集群调度器（Slurm）经验，能提供有用的运维背景。
生产工程：理解监控、可观测性和站点可靠性实践，将丰富部署和运维章节的阅读体验。

超越本书

本书涵盖了当今存在的机器学习车队：仓库规模的训练集群、全球服务基础设施，以及大规模运营的治理挑战。处于研究前沿的主题——包括全自动车队管理、下一代互联、大规模神经形态计算，以及车队级安全属性的形式化验证——超出了本书范围，但代表了活跃的研究领域。

在课程中使用本书

本书源自哈佛大学的 CS249r 课程和 TinyML edX 专业证书项目。教学实践强化了一个延伸至车队规模的洞见：同一物理法则支配层级的每一层。带宽、能量和故障既设定了微控制器的极限，也设定了数据中心的极限。随规模变化的不是物理，而是哪个极限成为瓶颈，而一个新的瓶颈限制即是一个新的工程问题。在单机上，内存墙占主导。跨越车队时，分割带宽和常规硬件故障接管控制权，曾经罕见的例外成为整个系统设计的核心约束。物理是连续的；工程则不然。

本书旨在支持涵盖完整分布式 ML 系统栈的一学期进阶课程。授课教师也可选择单独部分用于较短模块：

第一、二篇（车队与分布式 ML）适合分布式训练基础设施的进阶半学期课程。
第三、四篇（大规模部署与负责任的车队）适合大规模生产 ML 的应用型半学期课程。

对于概览课程或高管项目，四篇的引言及其支配原则本身即可提供车队规模 ML 系统定量定律的浓缩概览。

进阶课程序列的幻灯片、作业和教师材料可在 mlsysbook.ai 获取。

版权与许可

起源

致谢

早期关于 TinyML 的教学源于这样一个认识：约束毫瓦级设备的因素，同样也约束着数据中心加速器。而本书则源于另一个不同的认识，这个认识来自我作为访问研究员在 Google 从事 ML Fleet Efficiency（机器学习集群效率）工作的经历。Peter Mattson 是 MLPerf 的合作者，是他让这个机会成为可能。在那里所见所闻改变了我对 ML 系统的看法：将成千上万个加速器协调成一个单一的连贯系统所需的工程，本身就是一门独立的学科，而这门学科却没有教科书。

那项工作让我接触到了 ML Productivity Goodput (MPG，机器学习生产力良率) 指标、前所未见规模的集群级异构性，以及将故障视为统计上的必然而非例外的日常现实。从业者所知与书面记录之间的鸿沟是巨大的。构建这些系统的研究人员发表了各自的成果，但将这些成果串联起来的纽带、使它们融会贯通成为一门学科的原则，仅存在于从事这项工作的人们脑海中。本书旨在记录这些连接的纽带。

合作者与同事

我对集群级系统的大部分认知，源自 Google 的 ML Fleet Efficiency 团队：Arissa Wongpanich、Tayo Oguntebi、Jose Baiocchi Paredes、Yu Emma Wang、Phitchaya Mangpo Phothilimthana、Ritwika Mitra 和 Zongwei Zhou。Naveen Kumar 领导了这项工作，他对集群级优化的思考方式至今仍在塑造我的认知。Robert Hundt 深化了我对规模化性能工程的理解。Naveen 和 Robert 共同让我从内部视角看清了何为集群级效率。David Kanter 延续了 MLPerf 的合作，我们关于分布式系统基准测试的讨论，磨练了贯穿全书各章的定量方法论。Greg Diamos 在缩放定律及其起源方面提供了宝贵视角，早期大规模分布式训练的部分开创性工作正是在百度成型。

参考文献中引用论文的研究人员理应获得特别致敬。是那些构建系统、测量故障、发表所学的从业者和研究人员发现了本书所教授的原则，而非为这本教科书而发明它们。本书将他们的工作综合为一个连贯的叙事。这份债务归功于他们。

支持

Harvard Data Science Initiative（哈佛数据科学倡议）、Harvard Extension School（哈佛大学延伸教育学院）和 National Science Foundation（美国国家科学基金会）支持了这项工作；Edge AI Foundation 和 ICTP 支持了教育推广和奖学金；我们的行业合作伙伴提供了基础设施和工具，使实际实验成为可能。

在 MIT Press，Susan Hartman 从一开始就相信这个项目，并指导两卷书从开源实验走向正式出版教材。她的编辑判断和支持让这本书成为现实。我同样感谢 MIT Press 同意为本书保留开放获取。一本关于由开源社区塑造的学科的教科书，理应让该社区的每个人都能获取。

要查看所有 GitHub 贡献者的完整且最新名单，请访问在线版本 mlsysbook.ai。有意贡献者请参阅我们的 GitHub 仓库。

每一个 GitHub Star 都是一个信号，表明有人关心这份材料、正在从中学习、并相信这项工作意义重大。在线学习者社区提出的问题、他们的好奇心、以及他们愿意为一本未完成的教科书投入精力，在项目规模令人望而却步时，支撑着项目持续前行。

最后，我要感谢我的妻子和孩子。我挤占了本属于他们的时间来写作这本书：消失在修订中的周末、延续至午夜后的夜晚、人虽在但心不在焉的清晨。他们从未抱怨。他们询问写作进展、给我端来咖啡、给我留出完成的空间。本书的任何价值，都源于他们的耐心和支持。

关于 AI 协助的说明

本书每一章均由我亲自调研、撰写和反复重写。同时，我也全程使用了 AI 工具。以下内容不仅是 MIT Press 要求使用 AI 的作者进行披露，更是我对本书坚持的标准的阐述，以及对当工具具备如此能力时“作者身份”含义的主张。

该标准是可追溯性。书中每一个定量论点均源于随书附带源代码的 Python 计算单元。每一处引用均经核实对应其原始出处。每一个交叉引用均指向稳定锚点。正文中的每一个数字均由为本教材专门开发的基础设施建模引擎计算得出——而非手工录入。一套预提交测试套件——包含三十余项自动化检查，涵盖单位一致性、内联引用解析、交叉引用完整性、符号规范性和引用卫生——在每次提交时强制执行这些不变量。AI 工具使这一严谨性的部分机械化成为可能；执行基础设施则对其进行认证。

作者身份即思考。哪些概念该收入本书，哪些不该。如何安排章节顺序，使每个概念的呈现都在读者具备理解工具之后。选取哪些贯穿始终的工作示例，计算哪些数字，以便读者独立验证论证。每个解释的深度定位——既要足够严谨以满足研究生工程师，又要足够具体以适应初次接触系统思维的学生。预判学生会在何处卡住，因为我讲授过这门课程并眼见他们卡住。这些是工具无法做出的判断，因为它们需要了解读者。我全程使用 AI 工具来头脑风暴框架、探索替代方案、压力测试我的推理。选择权在我。

实践中，AI 在编写代码方面切实有用——计算单元、预提交检查、本质上即程序的工作示例。它帮助我调研文献（随后我阅读原文）、起草段落（随后我大幅重写），并审计手稿在数百个交叉引用、数千个索引条目和数万行正文中的一致性。贯穿始终的模式相同：工具提议，人类裁决。

这一模式早于当下。1683 年，Joseph Moxon 使用其所描述的印刷机，印制了首部英文印刷手册《印刷全术机械练习》。三个世纪后，Donald Knuth 用 TeX（他为让自己的书得以存在而创建的排版系统）撰写了《The TeXbook》。一本关于 ML 系统基础设施的书，若不用其所描述的基础设施来撰写，将是自相矛盾。工具制造者以工具记录工具。

我在第 1.4.1 节描述的可靠性鸿沟——即集群级 ML 系统无法做到零故障，只能通过工程手段实现恢复——同样适用于 AI 辅助写作。我对本书坚持的标准，也是我希望你们对交付的每个系统提出的要求：工具可以提议，但只有工程师能裁决。MIT Press 不将 AI 工具列为作者，因为它们无法为其工作承担伦理和法律责任。每个工程系统亦复如是。作者身份即承担该责任，而这属于人类。

符号约定

PARTIAL FILE: 不要单独渲染。由 contents/vol1/frontmatter/notation.qmd（vol1 包装）和 contents/vol2/frontmatter/notation.qmd（vol2 包装，然后链接 contents/vol2/frontmatter/_notation_distributed.qmd 用于仅 vol2 内容）包含。编辑此文件会根据设计同时出现在两个卷中。不要添加 YAML 头。不要添加 Markdown setext 下划线。不要添加 H1。章节的 H1 位于每个包装中，这样 Quatro 才能提取它用于侧边栏、浏览器标签和标题块。

机器学习系统跨越 机器学习（计算机科学/统计学）和系统（计算机架构/硬件）。每个领域独立发展了其符号，许多符号根据使用它们的社区、论文或文献而具有不同的含义。这种冲突在学科融合时会造成真正的混淆。以下约定建立了单一符号以消除歧义。

考虑一个简单的陈述：“增加 B 会提升吞吐量。” 对机器学习研究者，B 表示批量大小。对硬件工程师，B 表示带宽。这两种解释在各自领域都是正确的，但在机器学习系统中我们需要在同一方程中同时包含这两个概念——因此需要一个单一且一致的约定。

机器学习系统的铁律

本书的基本性能方程，在开篇章节中引入，为：

T = \frac{D_{\text{vol}}}{\text{BW}} + \frac{O}{R_{\text{peak}} \cdot \eta_{\text{hw}}} + L_{\text{lat}}

每个变量都是经过精心选择，以避免与标准机器学习术语冲突。

| 符号 | 定义 | 单位 | 为什么选择此符号？ |

| --- | --- | --- | --- |

| T | 时间 | 秒 | 无歧义。操作的墙钟时间。 |

| D_vol | 数据量 | 字节 | 避免与 D（数据集大小）冲突。在缩放定律中，D 表示训练令牌。这里我们需要通过内存移动的字节数。下标用于消歧。 |

| BW | 带宽 | 字节/秒 | 避免与 B（批量大小）冲突。物理学使用 B 表示带宽，但每篇机器学习论文使用 B 表示批量大小。我们保留机器学习的约定。 |

| O | 操作 | FLOPs | 总的浮点运算次数。在方程中表达清晰（相对于 “Ops”）。 |

| η_hw | 效率 | — | 硬件利用率（0 ≤ η_hw ≤ 1）。避免与学习率（η）冲突。 |

| L_lat | 延迟 | 秒 | 避免与 ℒ（损失）冲突。固定开销时间（内核启动、网络往返时间）。下标用于与损失函数区分。 |

这些选择为何重要

如果没有仔细的符号选择，句子会变得模糊：

“减少 D 能提升性能。”

这句话有两种可能的解释：

减少 数据集大小（更少的训练样本）可能加快训练速度，但可能降低准确率。
减少 移动的数据量（例如，通过压缩或量化）可以加速推理，准确率的影响取决于技术和校准。

使用我们的符号，我们可以精确地表达：

“通过 FP32 到 INT8 量化减少 D_vol 将参数内存流量降至四分之一，而 D（训练数据）保持不变。”

我们的符号使这种歧义变得明确：“BW 限制吞吐量” 是无歧义的。

带下标的变体

当一个多字母量名称带有描述性下标（例如，区分存储带宽和网络带宽时），将根和下标都包裹在 \text{} 中：

BW_disk, BW_network, BW_accelerator
D_vol, R_peak, L_lat, η_hw
E_move, E_compute, E_total

如果不使用 \text{}, 数学模式会将每个字母渲染为斜体变量，间距会塌缩，看起来像一个乘积，而不是一个标签。

退化方程

机器学习系统的沉默失效模式由开篇章节引入的退化方程捕获。以下一些符号（如 τ）出现在章节正文中，而不是在块方程本身中；将它们集中定义，当它们出现时能保持标准形式无歧义。

Accuracy(t) ≈ Accuracy_0 − λ ⋅ 𝒟(P[t]∥P[0])

| 符号 | 定义 | 单位/类型 | 说明 |

| --- | --- | --- | --- |

| λ | 敏感度 | 标量 | 模型对分布偏移的敏感度。取决于架构。（非波长。） |

| P[t] | 当前分布 | 分布 | 时间 t 的数据分布。（非参数——请使用 P 表示参数数量。） |

| P[0] | 训练分布 | 分布 | 训练时的数据分布。 |

| τ | 漂移阈值 | 标量 > 0 | 当 𝒟(P[t]∥P[0]) > τ 时触发重新训练。 |

能量推论

机器学习工作负载的能源成本源自机器学习系统的铁律，并可分解为：

E_total ≈ D_vol × E_move + O × E_compute

| 符号 | 定义 | 单位 | 说明 |

| --- | --- | --- | --- |

| E_total | 总能量 | 焦耳 | 机器学习工作负载消耗的总能量，分解为数据移动和计算项。 |

深度学习符号

我们遵循标准的深度学习惯例（Goodfellow et al. 2016），并对系统变量进行显式消歧。

| 符号 | 定义 | 维度/类型 |

| --- | --- | --- |

| B | 批量大小 | 整数。并行处理的样本数量。（永不表示带宽。） |

| P | 参数 | 整数。模型中可训练权重的总数。（永不表示峰值 FLOP/s。） |

| D | 数据集大小 | 整数。训练样本或令牌的数量。（永不表示以字节为单位的数据量——请使用 D_vol。） |

| S | 序列长度 | 整数。令牌或时间步的数量。 |

| d | 隐藏维度 | 整数。隐藏状态向量的大小。 |

| d_head | 注意力头维度 | 整数。注意力层中每个头的隐藏维度。 |

| N_L | 层数 | 整数。网络中的总层数。 |

| N_heads | 注意力头数 | 整数。多头注意力层中的注意力头数。 |

| H_KV | 键值头数 | 整数。分组查询或多查询注意力中的键值头数。 |

| ℓ | 层索引 | 整数。层的索引。使用 вместо 裸 L 来索引层，因为 L 与损失和延迟冲突。 |

| ℒ | 损失函数 | 标量。训练过程中最小化的目标函数。 |

| η | 学习率 | 标量。优化器的步长。（永不裸用于硬件效率——请使用 η_hw。） |

| θ | 模型权重 | 向量/矩阵。所有可学习参数的集合。 |

分布式系统符号约定

分布式系统工作引入了第二层符号体系，用于协调、通信和可靠性。下表中的某些符号专门保留用于同步、修复和梯度定标上下文；集中定义它们可确保这些符号出现时其规范形式明确无歧。核心方程是集群定律（分布式步时间定律）：

\[T_{\text{step}}(N) = \frac{T_{\text{compute}}}{N} + T_{\text{comm}}(N) + T_{\text{sync}}(N) - T_{\text{overlap}} \]

| 符号 | 定义 | 单位 | 备注 |

| --- | --- | --- | --- |

| N | 设备数量 | 整数 | 分布式作业中的加速器数量。（非参数量——参数量请用 P。） |

性能、服务与内存符号约定

可复用的性能和服务量遵循与铁律相同的防冲突规则。速率使用 R 或描述性的希腊符号；请求计数使用 Q_req 而非重载 N；队列利用率使用下标 ρ，以便裸 ρ 可保留供其他比率模型使用。

| 符号 | 定义 | 单位/类型 | 备注 |

| --- | --- | --- | --- |

| MFU | 模型 FLOPs 利用率 | 无量纲 | 有效模型 FLOP/s 除以可用峰值 FLOP/s。文本首字母缩写避免了重载 η。 |

| r_comp | 压缩比 | 无量纲 | 未压缩大小除以压缩大小。压缩后的载荷大小为 M / r_comp；下标避免了裸 C 的冲突。 |

概率与分布符号约定

| 符号 | 定义 | 备注 |

| --- | --- | --- |

| p(x) | 分布 | 随机变量的概率质量/密度。泛指分布时使用小写 p(·)，以避免与 P（参数量）冲突。 |

| p(y ∣ x) | 条件分布 | 条件概率/密度。泛指标签关系时使用此形式；保留 P[0] 和 P[t] 用于降级方程的训练/当前分布。 |

| Pr(E) | 事件概率 | 事件 E 的概率。用于事件陈述，如 Pr(batch = 0)；分布请使用 p(x) 和 p(y ∣ x)。 |

局部矩阵代数约定

当方程显式引入矩阵时（例如 GEMM C = αAB + βC），局部矩阵代数可使用 A、B 和 C 作为操作数。这是局部线性代数约定，并非将 B 全局覆盖为批大小。

单位与精度

物理单位：本书全篇使用 SI（公制）单位，包括米、千克、秒、瓦特和 °C，符合标准工程与科学实践。若源数据原为英制单位报告，我们将其换算为 SI 并在括号中注明原始值。数字与单位之间始终以空格分隔（例如 100 ms、2 TB/s）。
数据与内存：我们仅使用十进制 SI 前缀：KB = 10³ bytes，MB = 10⁶，GB = 10⁹，TB = 10¹²。正文中不使用二进制前缀单位；所有容量、吞吐量和模型大小均以十进制单位报告（例如 80 GB、2 TB/s、102 MB）。
计算：我们区分操作计数与速率。总工作量用 FLOPs 表示（例如 GFLOPs、TFLOPs），吞吐量用带十进制前缀的 FLOP/s 表示（例如 GFLOP/s、TFLOP/s）。
- 1 TFLOP = 10¹² FLOPs
- 1 TFLOP/s = 10¹² FLOPs per second
- 算术强度按惯例使用 FLOP/byte 作为单位比率（每移动一字节的浮点运算次数）。这是一个比率单位，而非总工作量符号或吞吐量符号。
货币：美元金额使用美元符号（$）；除非另有说明，美元计价成本均为美元（USD）。
精度：
- FP64：双精度（8 字节）
- FP32：单精度（4 字节）
- TF32：TensorFloat-32（19 位计算格式，通常按 FP32 存储）
- FP16：半精度（2 字节，标准范围）
- BF16：Brain float（2 字节，宽动态范围）
- FP8：四分之一精度（1 字节，E4M3 或 E5M2 格式）
- FP4：4 位浮点格式
- INT8：8 位整数（1 字节）
- INT4：4 位整数；更低整数精度遵循相同的大写 INTn 模式（例如 INT3、INT2）

快速参考：冲突消解

ML 系统文献中的常见冲突点包括：

| 符号 | ML 含义 | 系统含义 | 本约定 |

| --- | --- | --- | --- |

| B | 批大小 | 带宽 | 批大小。带宽请用 BW。 |

| P | 参数量 | 峰值 FLOP/s | 参数量。峰值速率请用 R_peak。 |

| D | 数据集大小 | 数据量 | 数据集大小。移动字节数请用 D_vol。 |

| L | 损失 | 延迟 | 损失（ℒ）。延迟请用 L_lat。 |

| η | 学习率 | 效率 | 学习率。硬件效率请用 η_hw。 |

通用原则：单字母符号优先遵循 ML 约定；系统概念采用下标或多字母符号。这反映了主要受众（学习系统的 ML 从业者）并保持与海量 ML 文献的兼容性。

时序组件

| 符号 | 定义 | 单位 | 备注 |

| :--- | :--- | :--- | :--- |

| ρ | 通信计算比 | 无量纲 | ρ = T_comm(N) / (T_compute / N)。接近或超过 1 的值表明为通信瓶颈扩展。 |

通信模型

网络通信时间分解为固定延迟和与带宽相关的传输：

\[ T(n) = \alpha + \frac{n}{\beta} \]

| 符号 | 定义 | 单位 | 备注 |

| :--- | :--- | :--- | :--- |

| T(n) | 通信时间 | 秒 | 跨单链路传输大小为 n 的消息所需的挂钟时间。 |

| α | 网络延迟 | 秒 | 固定的每消息开销。（非学习率——上下文消歧。） |

| β | 链路带宽 | 字节/秒 | 每链路的有效吞吐量。 |

| n | 消息大小 | 字节 | 有效载荷大小（例如梯度张量）。 |

| n^(\*) | 交叉点 | 字节 | n^(\*) = α ⋅ β。低于 n^(\*)：延迟瓶颈。高于：带宽瓶颈。 |

LogGP 扩展

LogGP 通过分离网络延迟、处理器开销和长消息注入间隙来细化 α-β 模型。标准名称很短，但本书对最高碰撞项使用描述性下标。

| 符号 | 定义 | 单位 | 备注 |

| :--- | :--- | :--- | :--- |

| g | 消息注入间隙 | 秒 | 连续消息注入之间的最小间隔。 |

| G | 长消息每字节间隙 | 秒/字节 | 每字节长消息间隙；区别于 β 链路带宽。 |

扩展效率

\[ \eta_{\text{scaling}} = \frac{T_1}{N \times T_N} \le 1 \]

| 符号 | 定义 | 单位 | 备注 |

| :--- | :--- | :--- | :--- |

| T_1 | 单设备时间 | 秒 | 单设备基准挂钟时间。 |

| T_N | N 设备时间 | 秒 | N 个设备上的挂钟时间。 |

故障容忍与可靠性

系统可靠性随规模下降。假设具有指数故障分布的独立组件，N 个组件的系统可靠性为：

\[ R_{\text{system}}(t) = e^{-N \lambda t} \]

聚合指数使用系统级速率 N λ，其中 λ 为独立、同类组件假设下的单组件故障率。指数 N λ t 无量纲，因此 t 必须使用与 λ 相同的时间单位（小时，当 λ 来自下文 FIT 推导速率时）。

最优检查点间隔平衡 I/O 成本与重算成本：

\[ \tau_{\text{opt}} = \sqrt{2 \cdot T_{\text{write}} \cdot \text{MTBF}_{\text{system}}} \]

该公式使用系统级 MTBF（整个作业的故障间隔），而非组件 MTBF；代入单组件值会导致 τ_opt 被 √N 倍高估。为保持量纲一致，T_write 和 MTBF_system 必须使用相同时间单位。行业标准 MTBF 以小时为单位；要与秒级写入时间结合，需换算：MTBF[秒] = MTBF[小时] × 3600。结果 τ_opt 继承输入所选的时间单位。

| 符号 | 定义 | 单位 | 备注 |

| :--- | :--- | :--- | :--- |

| λ | 单组件故障率 | 次/小时 | 单组件故障率；独立同类组件下系统级速率为 N λ。行业标准报告单位为 FIT（每 10⁹ 设备小时故障数）：λ_hour = FIT × 10^(-9)。（非敏感度——上下文消歧。） |

并行维度

3D 并行跨三个正交维度划分训练工作负载：

\[ N_{\text{total}} = d \times p \times t \]

| 符号 | 定义 | 单位 | 备注 |

| :--- | :--- | :--- | :--- |

| d | 数据并行 | 整数 | 模型副本数。（亦指隐藏维度——上下文消歧。） |

| p | 物理流水线阶段 | 整数 | 模型深度划分中的物理流水线阶段数。 |

| t | 张量并行 | 整数 | 层内划分度（模型宽度）。（亦指时间——上下文消歧。） |

| m | 微批次数量 | 整数 | 用于填充和排空流水线的微批次数。 |

| V | 每设备虚拟流水线阶段 | 整数 | 分配给每个物理流水线阶段的交错虚拟块数。 |

| M | 消息有效载荷大小 | 字节 | 待通信的梯度、模型状态、激活值或压缩消息载荷总大小。 |

集群容量因子

集群级容量计算将本地模型效率、扩展效率和运行有效吞吐率复合在一起。

| 符号 | 定义 | 单位 | 备注 |

| :--- | :--- | :--- | :--- |

压缩经济学

压缩模型对比编解码开销与减少载荷所节省的通信时间。

| 符号 | 定义 | 单位 | 备注 |

| :--- | :--- | :--- | :--- |

简介

目的

为何在单机上行之有效的工程原则，在生产规模下会失效？

大规模机器学习拥有其自身的物理规律。在单节点上，性能受制于内存墙：数据必须足够快地到达加速器，以保持计算单元忙碌。在分布式集群中，同一个问题跨越了机器边界。数据必须在机架间通过网络链路移动，而最慢的共享交叉点可能限制整个作业。硬件故障的性质也发生了改变。单加速器训练作业失败只是不便；但在一个包含 10,000 个节点的集群中，单个节点故障可能会使本章定义的机器学习舰队停摆。这种断裂解释了为何精通单机 ML 已不再足够：规模不是“更多的相同”，而是根本不同的工程地形，需要不同的原则、不同的架构，以及对系统为何工作的不同思考方式。该地形承载着小模型不具备的社会维度，因为其影响被这些系统服务的数十亿用户所放大：当本地模型表现出偏见时，危害是可控的；当基础模型表现出偏见时，它会蔓延至数字生活的方方面面。用 C³ 术语来说，本书构建的学科是分布物理学，在那里计算、通信和协调将算法选择转化为拓扑、容错、安全和治理问题。第二卷的每一部分都介绍了该演进中某一层的原则：舰队基础、分布式执行、大规模部署和负责任运营。后续章节将随着系统增长回顾这些第二卷原则，而不会将它们归并到第一卷的原则集中。

解释计算、通信和协调如何在生产舰队中取代单节点的数据-算法-机器约束
应用舰队定律估算协调税并分类扩展机制
当可靠性、网络带宽、电力或治理约束主导增长时，分析缩放定律极限
使用可靠性缺口、一致性-可用性权衡、通信强度和常规故障率诊断舰队规模分布风险
跨物理基础设施、运营控制和社会治理综合舰队栈设计原则

规模时刻

单加速器上的机器学习由局部内存层级和算术强度管辖：即硅的物理学。第一卷留下的边界，在局部机器不再是系统之时显现。当模型从研究原型走向全球服务时，约束边界向外移动至机架、网络、电力供应和恢复机制。这种变化不是平滑的外推；它是规模时刻。

规模时刻是当模型跨越三面基本墙——内存、网络和能量——时发生的物理和运营转型。这三面墙是本卷导航的标准三元组。在单个加速器上，内存墙起约束作用；当我们从单 GPU 移至包含数千个节点的机器学习舰队时，网络墙取代局部内存墙成为主要性能瓶颈。其硬性限制是剖分带宽（将舰队分割的最窄切面上的聚合带宽）和光速延迟。服务数十亿用户随后撞上能量墙，使热力学效率成为一级工程需求。跨越这些墙在它们旁边打开了一道可靠性鸿沟，使硬件故障成为常态而非罕见例外。

根据公开和第三方估算，2012 年至 2020 年代中期，训练算力从 AlexNet 的约 10¹⁸ FLOPs 增长至领先大模型接近 10²⁵ FLOPs，大约七个数量级。这种差异是质的，而非仅仅是量的：计算、通信和协调现在将算法选择转化为拓扑、容错、安全和治理问题。

舰队可靠性随节点数增加而崩溃。

考虑一个使用假设的 25,000 张 A100 级 GPU 集群运行 90 天的 GPT-4 级训练场景。这些数值仅为说明性用途，并非由 OpenAI 披露 (OpenAI et al. 2023)。在该规模集群中，区间 t 内至少发生一次故障的概率 Pr(failure before t) = 1 - e^(-t/MTBF[system]) 成为约束条件。下面的工作示例建立了单个集群的算术；第 E.1.2 节形式化了管辖多千 GPU 舰队故障率的 MTBF 级联，以便读者预测任意舰队规模的中断节奏。

符号与记法

传输与压缩时序

| 符号 | 定义 | 单位 | 备注 |

| --- | --- | --- | --- |

大规模服务内存

| 符号 | 定义 | 单位 | 备注 |

| --- | --- | --- | --- |

| M[KV] | KV 缓存内存 | 字节 | 自回归服务的键值缓存占用。 |

附加冲突点

分布式上下文引入了除基础记法中所述之外的进一步符号冲突：

| 符号 | ML 含义 | 分布式含义 | 本约定 |

| --- | --- | --- | --- |

| N | — | 设备数量 | 设备数量 在分布式上下文中（加速器，而非宿主节点）。 |

| α | — | 网络延迟 | 网络延迟 在 α-β 模型中。上下文消歧。 |

| λ | 灵敏度 | 故障率 | 上下文相关。退化中的灵敏度；可靠性中的故障率。 |

| t | — | 张量并行度/时间 | 上下文相关。3D 记法中的张量并行度；可靠性中的时间。 |

附加单位

网络吞吐量：根据惯例以字节/秒 (GB/s, TB/s) 和比特/秒 (Gbps) 双重报告。InfiniBand 和以太网规范使用 Gbps；应用层吞吐量使用 GB/s。我们在首次使用时注明惯例。
可持续性语境中的功率：当周围章节涉及功率或能量时，物理功率可使用显式下标 P[...] 变量（例如 P[IT]、P[dynamic]、P[average]）。裸 P 保留用于参数计数。

问题：一个 GPT-4 级别模型的训练运行使用 25,000 块 GPU。如果每块独立 GPU 的平均故障间隔时间（MTBF）为 50,000 小时（用于车队级可靠性示例的标准数据中心级数据），训练任务会多久因硬件故障而中断一次？

数学计算：

系统 MTBF：系统 MTBF 等于组件 MTBF 除以独立 GPU 的数量。按本场景数值，50,000 小时除以 25,000 块 GPU 约为 2 小时。
每日故障率：24 小时除以 2 小时，约为每天 12 次故障。
年度总故障数：25,000 块 GPU 乘以（8,760 小时除以 50,000 小时），约为每年 4,380 次故障。

系统洞察：在此模式下，系统始终处于部分故障状态。传统的软件恢复（人工重启）不再奏效；系统必须将容错架构为一等公民。硬件不再能被视为可靠的抽象层；它是一种概率性资源，需要持续、自动化的状态保存（检查点）。

Meta 发布的 Llama 3 训练运行展示了真实大规模系统中相同的可靠性算术。

背景：Meta 报告在 16,384 块 H100 GPU 上训练 Llama 3 405B，进行为期 54 天的预训练运行（Dubey 等人 2024）。

故障模式：在这个规模下，故障并非罕见的干扰。该运行经历了 419 次意外中断，平均每隔几小时就会发生一次中断。

后果：在这个规模下训练变成了一场持续恢复的演练：检查点、自动化诊断和重启工作流决定了集群是产出有用的模型进度，还是在等待人工干预中白白消耗时间。

系统教训：规模时刻将可靠性从硬件规格转变为分布式系统设计需求。车队级模型的训练，既依赖于恢复机制，也依赖于优化器。

定义 Llama 3 运行的恢复机制之所以存在，是因为集群规模激增；要理解为何现在的运行需要数百次重启周期，有助于追溯将车队推向这一规模的算力轨迹。机器学习的历史由规模定义：每一次重大的能力飞跃，都源于在以前不可能的规模上应用计算的能力，这使得系统工程成为 AI 进步的核心。

算力需求呈指数级增长。AlexNet 在两块 GTX 580 GPU 上训练约 5–6 天（Krizhevsky 等人 2012）。BERT 需要 64 个张量处理单元（TPU）芯片训练 4 天，约 6,144 芯片小时（Devlin 等人 2019）。

GPT-3 在微软高带宽集群的 V100 GPU 上训练，消耗估计 3.14 × 10²³ FLOPs（Brown 等人 2020）。这一时代的微软周边基础设施达到约 10,000 块 GPU，这是图 1.1 中使用的集群规模锚点。PaLM 在 6,144 个 TPU v4 芯片上训练约 60 天，消耗约 10²⁴ FLOPs（Chowdhery 等人 2022）。OpenAI 的 GPT-4 报告未披露模型规模、训练硬件或训练算力，因此本节中的 GPT-4 级场景应视为说明性示例，而非已发布的配置（OpenAI 等人 2023）。这些示例处于早期算力趋势研究记录的快速训练算力增长趋势中（Amodei 和 Hernandez 2018；Sevilla 等人 2022）。表 1.1 明确展示了这种规模转变：训练预算从单机实验转移到分布式系统，其中硬件数量、时钟墙时间和运维协调成为模型设计的一部分。

| :--- | :--- | :--- | :--- | :--- |

| AlexNet | 2012 | 2 个 GPU | 5–6 天 | ~10¹⁸ |

| BERT-Large | 2018 | 64 个 TPU | 4 天 | ~10²⁰ |

| GPT-3 | 2020 | 1,024 个 V100 GPU（运行估算） | 至少 29 天 | 3.14 × 10²³ FLOPs |

| PaLM | 2022 | 6,144 个 TPU | ~60 天 | ~10²⁴ |

表 1.1：训练算力演进：跨已发布里程碑及一个说明性 GPT-4 级场景的硬件规模与训练时长增长，展示了为何当训练预算从 10¹⁸ 量级跃升至最大规模训练运行时，分布式系统变得至关重要。

训练算力只是其中一个维度。图 1.1 通过绘制过去十年训练里程碑模型所用加速器数量，追踪了集群规模本身的相关增长。

图 1.1：集群规模爆炸：2012–2024 年训练里程碑模型所用加速器数量。已发布论文的实测数值显示为实心圆；GPT-3 估算值（空心标记）反映了基于微软基础设施公告的大致集群规模，而非精确的已发布数值。虚线趋势线表明集群规模约以每年 2 倍的速度增长，这一速率超越了摩尔定律，并驱动了全书开发的基础设施挑战。

图 1.1 显示，集群规模在十多年间增长了约四个数量级，从 AlexNet 的两块 GPU 增至 Llama 3 的 16,000 多块 H100。这一实证轨迹是规模时刻的基石：领先模型所需的加速器车队规模远超早期深度学习里程碑。然而，曲线本身并不能解释哪个约束最先失效。大语言模型训练、推荐系统服务和联邦移动学习都会遭遇车队规模，但各自考验的是系统的不同部分。

灯塔原型是贯穿全书使规模时刻具体化的典范工作负载。此时，它们的作用是表明“更多机器”并非单一工程问题：主导约束取决于什么必须跨越车队边界。完整名单及 C³ 分类映射与约束绑定分析见第 1.6.1 节。

原型 A（GPT-4/Llama-3）：超大语言模型从单设备内存瓶颈转向多节点模型并行与流水线并行，使通信成为瓶颈。
原型 B（大规模 DLRM）：深度学习推荐模型（DLRM）工作负载从在本地内存中容纳嵌入表转向跨数百个节点进行嵌入分片，使稀疏全对全流量成为瓶颈。
原型 C（联邦 MobileNet）：移动端推理和设备端适应从单设备转向跨数十亿设备的联邦学习，使不可靠客户端、隐私约束和落后者成为瓶颈。

舰队堆栈：一种层次化架构

这些原型将增长曲线转化为一个工程问题。加速器数量的相同增加可能会产生网络墙、嵌入分片瓶颈，或一组不可靠的边缘参与者。虽然原型将注意力集中在工作负载上，但一套并行的系统透镜则对基础设施起到同样的作用，将注意力引向数据中心物理、网络拓扑和分布式一致性。联邦学习²的兴起进一步多元化了这种格局，使得机器学习从一个由算法主导的学科转变为由系统工程决定成败的领域。一个无法扩展的复杂算法往往不如一个在可扩展基础设施上高效部署的简单算法具有更大的实际价值。

规模不连续性

从单机到分布式训练的过渡会引入系统行为的质变。图 1.2 对比了两种状态：单机世界由内存墙主导；舰队规模世界由通信主导、常规故障和治理复杂性主导。

图 1.2：规模不连续性：单机系统（左）受局部内存带宽支配，运行时无需节点间协调，故障罕见，且只有一个治理点。舰队规模系统（右）引入通信主导、常规硬件故障和治理复杂性作为一级工程约束。

图 1.2 所捕捉到的不连续性是质变的，而不仅仅是量变的：在舰队规模下，约束的束缚点从硅片转移到了网络结构，工程学科也从优化转向了韧性。计算单位不再是单个服务器，而是机器学习舰队：一个由数千个相互连接的加速器、存储阵列和网络结构组成的庞大分布式系统，必须作为一个单一的连贯引擎来运作。

机器学习舰队是一个分布式系统，由数千个相互连接的加速器、存储阵列和网络结构组成，旨在作为一个单一的连贯计算机运行。

意义：它在所有节点之间协调同步状态，其中总时间 T 由最慢的工作者（滞后者）决定。它需要随着舰队聚合计算能力（R[peak]）增长的双向带宽（BW[bisect]）。
区别：与传统集群（例如 Spark、MapReduce）不同，传统集群管理的是独立的异步作业，而机器学习舰队在同步紧耦合（Synchronous Tight Coupling）下运行：所有工作节点必须在任何一个节点前进之前到达训练步骤的同步点，因此需要近乎完美的可靠性来维持吞吐量。
常见误区：一个常见的误解是认为机器学习舰队只是“更多的服务器”。实际上，它是一种规模级计算机（WSC），其中网络充当系统总线，编排器充当操作系统。

当系统规模超越单个节点时，一个根本的物理约束浮现出来：双向带宽墙³，它限制了数据穿越网络中点的速度。在舰队规模下，网络常常决定模型吞吐量，而非计算能力。

在单个 GPU 上，训练是确定性的：相同的代码、数据和随机种子会产生完全相同的结果。但在数千个 GPU 的规模下，会出现新的现象。网络分区可能将集群分割成独立训练的组，导致模型发散。滞后者（由于硬件差异或热限制导致数据处理速度慢于同伴的工作节点）可能成为整个训练运行的瓶颈。每台机器每年发生一次的硬件故障⁴，在操作 10,000 台机器时会变成日常事件。系统必须频繁进行检查点，以至于丢失一天的进展变得可以接受，而非灾难性。

这些由规模引发的挑战推动了大型 AI 组织对基础设施的投资。Meta 的研究超级集群（RSC）于 2022 年宣布，包含 16,000 块 NVIDIA A100 GPU，通过 200 Gb/s InfiniBand⁵ 网络互连（AI 2022）。Google 的 TPU v4 Pod 包含 4,096 块芯片，总计算能力达到 1.1 EFLOP/s（Zu et al. 2024）。微软为 OpenAI 构建的 Azure 超级计算机在 2020 年达到超过 10,000 块 GPU，随后 Azure AI 数据中心的公告描述了数万 GPU 级别的训练结构（Langston 2020）。模型的规模决定了基础设施的规模。附录 D.1 列出了这些互连带宽常量，并将其输入到 α-β 通信模型中，使读者能够将链路的带宽和延迟转换为预测的传输成本。

规模时刻阐明了为什么：计算需求的指数增长迫使机器学习系统超越任何单机范围，从而产生通信主导、常规故障和治理义务。接下来的问题是如何组织工程响应。专为独立任务设计的分布式系统框架无法满足机器学习训练所需的紧密耦合；因此需要一种不同的架构层次结构。

舰队堆栈：一种层次化架构

Apache Spark (Zaharia et al. 2016) 处理独立的数据分区；网络微服务处理孤立的请求。机器学习舰队既不做前者也不做后者。其工作负载要求每隔几百毫秒在数千个加速器上进行同步状态更新，这种耦合强度是现有分布式框架从未设计用于维持的。机器学习系统的工作负载特征从根本上不同于传统分布式系统，尽管底层硬件（网络、计算、存储）是相同的。为了系统地阐释这些差异，本书将规模的工程核心形式化为一个四层堆栈——舰队堆栈，它将原始集群资源转化为全球规模的人工智能应用。

图 1.3 可视化了从单节点到舰队的过渡。图的左侧总结了单节点制度：1–8 个加速器通过共享内存连接，此时的束缚约束是内存墙。伸缩箭头跨入分布式舰队制度，此时数千个节点通过高速交换结构协同工作，瓶颈转移到双向带宽墙：网络拥塞和消息传递延迟成为主导因素。

图 1.3：机器学习系统的缩放制度：机器学习工程被划分为两个不同的物理制度。单节点系统受局部内存带宽（内存墙）限制；分布式舰队受网络通信（双向带宽墙）限制。掌握节点内数据移动是分布式扩展的先决条件。

图 1.3 中的堆栈架构在规模扩展时不会变化：每个机器学习系统仍然包含硬件、系统外壳、工作负载和使命。什么发生了变化是每一层的物理特性。请自下而上阅读图像。在底部行，硬件（单节点内 NVLink 带宽达 900 GB/s）变为基础设施（跨机架的 InfiniBand RDMA 结构，每链路带宽 400 Gb/s），瓶颈从内存墙转移到了双向带宽墙。向上一行，系统软件（管理 PCIe DMA 的单个 CUDA 运行时）变为分布式（NCCL 和 RDMA 库在结构中协调数千个进程）。

上层两层经历了同样深刻的变革

ML 框架（在单节点上执行训练循环的 PyTorch 或 JAX）变为服务/运维（编排和持续集成/持续部署 (CI/CD) 流水线，用于调度分布式作业和管理滚动部署）。在顶层，应用（单个训练脚本或推理服务）变为治理（负责任 AI 政策、安全审计和多租户访问控制），因为舰队规模部署引入了单机环境中不存在的组织层面顾虑。四层构成了舰队栈：

基础设施（硬件，引擎）：物理基座。该层定义了舰队的原始能力：单节点 R[峰值] 和 BW，通过 InfiniBand RDMA 网络互联。本介绍中反复出现的硬件锚点是 NVIDIA H100，它作为具体的参考加速器，而非抽象的占位符。
分发层（系统，底盘）：通信底座。该层定义了集群包络：NCCL，在 GPU 网络上实现归约和广播的集合通信库；协调数千个加速器的 RDMA 集合通信；剖分带宽；电源使用效率 (PUE)，即 IT 负载之上的设施能耗开销；以及故障率 (MTBF)。
服务/运维（工作负载，路由）：编排层。该层通过部署流水线和调度，管理跨集群分片的数学工作负载（O、D[数据量]、CI），其中 O 为本地操作计数，D[数据量] 为数据体量，CI 预览通信强度比率：每本地 FLOP 的网络字节数。我们使用灯塔工作负载，如 GPT-4 和 DLRM。
治理（使命，目的地）：使命语境。这是栈的顶层，负责任 AI 政策、安全性和多租户访问控制在此塑造舰队级行为。一项使命（如前沿模型训练）引入高层需求（例如“99.99% 服务可用性”），这些需求决定了下方每一层的配置。

这一层级确保每项分布式工程决策都植根于其“使命语境”。例如，前沿训练使命从卷册规范名册 (第 1.6.1 节) 中实例化原型 A (GPT-4/Llama-3)，并在 H100 硬件集群上运行。通过标准化这些主角，我们确保“规模物理学”可在每一章中追溯。

传统舰队与 ML 舰队的动态对比

传统系统（例如搜索引擎或银行数据库）针对独立的异步任务进行优化。Web 服务器处理数百万个请求，每个请求相互隔离。当一个请求失败时，其他请求继续进行。这种模式以 MapReduce (Dean and Ghemawat 2004) 等系统为例，通过将数据分区为仅需最少协调的独立块来实现规模扩展。

相比之下，机器学习舰队在 同步紧耦合 下运行。虽然参数服务器架构 (Li et al. 2014) 引入了管理分布式状态的方法，但大型同步模型通常需要更紧密的同步以维持性能。迭代有状态性使得 ML 训练重复数百万次相同的数学运算，同时更新一个巨大的共享状态——模型权重，而不是处理独立的一次性作业。屏障同步意味着同步训练步骤中 10,000 个 GPU 必须等待最慢的工作节点，然后才能继续，因此单个节点 10% 的性能下降会使整个集群的吞吐量降低 10%。剖分带宽主导地位使 ML 训练成为带宽受限而非用户延迟受限，因为每秒必须有 GB 级的梯度数据跨越网络，并需要传统数据中心很少实现的非阻塞拓扑。

图 1.4 直观地说明了这种对比：在 MapReduce 中，工作节点独立写入共享存储，拖后腿的节点仅延迟其自身分区；而在 ML 舰队中，每个工作节点必须在训练步骤继续前到达 AllReduce 屏障。

图 1.4：屏障同步 vs. 独立任务：MapReduce 工作节点（左）独立运行，无需协调即可将结果写入共享存储。拖后腿的节点仅延迟其自身输出。ML 舰队工作节点（右）必须在每个训练步骤的 AllReduce 屏障处同步梯度，这意味着单个 10% 的拖后腿节点会使整个集群减慢 10%。

图 1.4 中的屏障同步模式解释了 为什么 ML 舰队无法借用 MapReduce 的容错策略：在屏障耦合系统中，每个工作节点的进度都取决于其他每个工作节点的健康状况。

这些问题检查舰队思维是否清晰：

向仓库级计算机的转变

ML 舰队要求采用 仓库级计算机 (WSC)⁶ 视角。在传统计算中，数据中心是容纳许多计算机的建筑。在 ML 舰队中，数据中心就是那台计算机。

网络结构：系统总线。
分布式存储：本地磁盘。
舰队编排器：操作系统。

掌握这些材料要求完成这一思维转变：工程师不再是为 CPU 编写代码，而是为跨越数千个机柜、功率达 100 兆瓦的计算机编写逻辑。仓库级计算机是大模型的常见范式，而 晶圆级引擎 等替代架构试图将这一整个层级折叠回单块硅片，用片上通信的极致带宽换取分布式集群的模块化。

梯度同步成为分布式训练的决定性成本。

通信成为主导因素

这些工作负载特征在规模化时产生了两个进一步后果，均是规模临界点引入的标准三元组的表达：通信成为主导成本（网络墙），故障变成常态（随之而来的可靠性鸿沟）。小规模时，计算占主导。在单 GPU 上训练模型花费大部分时间执行矩阵乘法。通信开销仅占总时间的一小部分。

大规模时，通信占主导。分布式训练要求每个批次后跨工作节点同步梯度。对于拥有 1750 亿参数的模型，FP32 梯度在应用任何集合算法前约占 700 GB。在环形全归约中，每个工作节点发送和接收的数据量约为梯度张量大小的 2*(N-1)/N 倍，因为每个梯度字节绕环大约传输两次，一次用于归约，一次用于广播回传；第 6 章推导了该因子。网络流量因此取决于精度、工作节点数量和集合实现，在较慢的互联互通上，通信可能消耗每次迭代的大部分时间，而非可忽略不计的一部分。

这个比率解释了 为什么 分布式训练系统如此激进地优化通信。Horovod 使用环形 All-Reduce、NCCL 集成和张量融合来改进集体通信（Sergeev 和 Balso 2018）；Megatron-LM 应用模型并行性（Shoeybi 等人 2019）；而 ZeRO 减少内存冗余（Rajbhandari 等人 2020）。就本论点而言，重要的映射是基于角色的：Horovod 代表集体运行时，NCCL 代表 GPU 通信后端，Tensor Fusion 代表梯度融合路径，Megatron-LM 代表模型分区，而 ZeRO 代表优化器状态分片。在机群规模下，这些技术是可行性的必要条件，而非可选的性能改进。

故障成为常态

在规模时刻建立的可靠性算术已经显示了第二个后果：拥有数千个 GPU 时，硬件每隔几小时就会发生故障，人工干预变得不可能，系统必须通过频繁的检查点、冗余工作器和自动恢复来实现自我修复。形式化的可用性模型及其架构后果将在第 1.4.1 节中说明。

通信主导和常规故障是规模时刻的后果，但它们并不能解释什么推动了机群规模的 relentless（不懈）增长。答案在于一组经验关系，这些关系将模型质量与资源投资联系起来，使得仓库规模基础设施成为经济必要，而非工程奢侈。

AI 扩展定律

训练 GPT-3 消耗了大约 3 × 10²³ 次浮点运算（Brown 等人 2020）。公开的 GPT-4 级训练估计通常在 10²⁵ FLOPs 量级，尽管 OpenAI 未披露实际训练计算或硬件配置（OpenAI 等人 2023）。这些估计在此很重要，因为每个数量级的计算增加都需要相应地扩展机器学习机群。

这种模式不是巧合。Richard Sutton 的“苦涩教训”阐述了基本原理：机器学习中的性能主要由在巨大规模上应用通用方法驱动，而不是将人类知识编码进算法中（Sutton 2019）。扩展定律将此观察定量化：模型损失随着计算、数据集大小和参数的幂律函数亚线性改善，ℒ(X) ∝ X^(−α[scale])（Kaplan 等人 2020）。因此，每次等大小的损失改善需要不成比例地更多资源，这是一个系统后果，本书稍后将其命名为通用扩展定律。每个扩展维度（参数、数据和计算）以不同方式与基础设施约束相互作用，使得多维效率优化在生产规模下成为必需。

扩展定律的经验证据

自 2010 年代末以来，AI 能力的快速演变体现了这种扩展轨迹。GPT-1（2018）包含 1.17 亿参数并执行基本句子补全。GPT-2（2019）扩展到 15 亿参数并实现了连贯的段落生成。

GPT-3（2020）扩展到 1750 亿参数并在多样化领域实现了复杂的文本生成。每次模型规模的增加都带来了显著提升的能力，但伴随着指数级增长的成本。

这种模式不仅限于语言模型。在计算机视觉领域，参数数量从 AlexNet（2012）到大型视觉变换器大约增加了一个数量级，每一代都以更高的准确度换取与计算和训练数据成正比的增加，这种耦合迫使视觉训练转向多加速器基础设施。

扩展假设支撑着这一进步：更大的模型捕捉更复杂的数据模式，从而提高准确性和泛化能力。然而，这种轨迹引入了关键的资源约束。训练 GPT-3 所需的约 3.14 × 10²³ 次浮点运算，相当于让消费级游戏电脑连续运行数百年，伴随着巨大的财务和环境成本。

这些资源需求揭示了 为什么 扩展定律对于高效资源分配是必要的。图 1.5 追踪了如何训练大型模型的计算需求以不可持续的速度增长，增长速度快于摩尔定律在硬件上的改进。

![](https://github.com/OpenDocCN/dsai-notes-pt3-zh/tree/master/docs/hav-cs249r-mlsys-vol2/img/file11.png)

图 1.5：模型训练计算趋势：训练计算呈指数增长，在深度学习时代加速显著。拟合趋势表明，在 2010 年之前每年大约增长 1.4 倍，而在深度学习时代内每年大约增长 4 倍，两者均远高于摩尔定律（~2 年）。最陡峭的阶段更是如此：在 2012–2019 前沿子集中，计算大约每 3.4 个月翻一番。这一轨迹解释了 为什么 效率已成为战略必要，而非可选的优化。

这些扩展关系提供了一个量化框架，用于在权衡中导航。模型性能遵循幂律关系，其中改善是一致的但表现出递减收益。因此，最优资源分配因此需要协调模型大小、数据集大小和计算预算，而不是孤立地扩展任何单一维度。驱动这些工作负载资源需求的计算特性决定了 它们如何 压迫分布式基础设施。

Transformer 通过自注意力机制处理序列，该机制计算所有标记对之间的关系。这种架构的计算成本与序列长度的平方成正比（𝒪(S²)，其中 S 为序列长度），使得资源分配对语言模型尤为关键。“FLOPs”（浮点运算）一词量化总计算工作量，而“标记”代表模型在训练过程中处理的单个文本单元（通常是子词）。

计算最优资源分配

对大型语言模型（LLMs）的实证研究揭示了一个关键见解。对于任何固定的计算预算，存在一种模型大小和数据集大小（以标记[⁷] 为单位）之间的最优平衡，该平衡能最小化训练损失。

图 1.6 通过三个相关视图阐述了这一原则。左侧面板显示了等 FLOP 曲线，每条曲线对应变换器训练期间的恒定浮点运算次数（FLOPs[⁸]）。这些曲线中的谷值标识了每个计算预算下最模型大小。中间和右侧面板揭示了随着计算预算增加，最优参数数量和标记数量如何可预测地缩放，证实了计算最优训练需要协调扩展。标注的标记将这些拟合外推到接近 10²⁴ FLOPs 的前沿规模预算，在此预算下，计算最优点大约落在在 1.4 万亿标记上训练的 630 亿参数上。这一配对正是 Chinchilla 比例——大约每参数 20 个标记——的体现：参数和标记一起增长，而不是任何一个维度抢先跑 ahead。

![](https://github.com/OpenDocCN/dsai-notes-pt3-zh/tree/master/docs/hav-cs249r-mlsys-vol2/img/file12.png)

图 1.6：最优算力分配：对于固定的计算预算，语言模型的性能取决于模型规模与训练数据规模的平衡；左侧面板展示了不同参数量下的训练损失，确定了每个 FLOP 级别的效率最佳点。中间和右侧面板量化了最优参数量和 Token 需求如何随算力增加而可预测地缩放，证明了需要协同缩放模型和数据，以最大化大语言模型的资源利用率。

Kaplan 等人（2020）证明了基于 Transformer 的语言模型损失与模型参数、数据集大小（以 Token 计）以及总计算预算遵循可预测的幂律关系。这一结果并非允许盲目增加每个维度；它表明模型质量取决于这些资源间的协同分配，这一点后来由 Chinchilla 的算力最优缩放分析进一步明确（Hoffmann 等人 2022）。

图 1.7 展示了参数量从 10³ 到 10⁹ 的模型的测试损失曲线，揭示了两个洞见。更大的模型实现了更优的样本效率，用更少的训练 Token 即可达到目标性能水平。随着计算资源增加，最优模型规模相应增长，当算力分配高效时，损失会可预测地下降。

图 1.7：缩放定律与算力最优性：更大的模型配合增加的训练数据和算力始终能获得更好的性能，但收益递减要求训练时进行谨慎的资源分配。最优模型规模和训练时长取决于可用的算力预算，这由不同参数规模和训练 Token 数下损失曲线的收敛所证明。

最优算力分配遵循 Chinchilla 的结论，即模型规模和训练 Token 应近似成比例缩放以实现算力最优训练，比率约为每参数 20 个训练 Token（Hoffmann 等人 2022）。这修正了早期倾向于增大模型规模同时使用相对较少 Token 训练的指导原则。

这些假设假定完美的算力利用率，而在分布式训练中这一假设不再成立。通信开销随系统规模不利地缩放，造成带宽瓶颈，降低有效利用率。在数千 GPU 规模下，利用率取决于分区和互联：Narayanan 等人（2021）报告 Megatron-LM 在 3,072 块 A100 GPU 上运行达到了峰值设备吞吐量的 52%，并指出较慢的互联或通信密集型分区会阻碍扩展。

数学基础与运行机制

幂律关系用数学方式表达缩放行为，尽管对于系统设计而言，理解这些模式背后的直觉比精确公式化更重要。本节方程解释了为何同一机群会因算力和数据的分配方式、收益递减的起始点、以及系统在回答前花费多少计算量，而进入不同的运行机制。

缩放定律正式表达为幂律关系。通用公式为：

ℒ(*X*) = *A*[ℒ]*X*^(−*α*[scale]) + *C*[ℒ]

其中损失 ℒ 随资源量 X 增加而按幂律衰减，衰减率为 α[scale]，外加基线常数 C[ℒ]。此处，ℒ(X) 表示以参数、Token 或算力等资源量 X 所达到的损失；A[ℒ] 和 C[ℒ] 为任务相关常数；α[scale] 为表征性能提升速率的缩放指数。α[scale] 值越大，意味着相对于缩放的性能提升越高效。

这些预测在多种模型配置中获得了强有力的实证支持。图 1.8 展示了早停测试损失如何随数据集大小和模型大小可预测地变化，证实了通过适当参数化，不同配置下的学习曲线是对齐的。

资源受限缩放机制

在实践中应用缩放定律是一种稀缺性诊断：有用的问题是哪种资源最先阻碍了平衡增长。算力预算、数据可用性和模型规模构成了三种具有不同最优响应的机制。

缩放机制分为计算稀缺、数据稀缺或平衡。

三种机制决定了适当的缩放响应：

计算受限机制：算力稀缺尽管训练数据充足却限制了缩放潜力，因此学术机构、初创公司和时间受限的团队通常训练更小的模型但延长训练时间，以最大化利用率。
数据受限机制：当计算资源超过可用数据集所能支持的程度时出现数据稀缺，因此处于专业、专有或隐私受限领域的团队通常训练更大的模型但减少优化步数，以从有限样本中提取更多信息。
最优机制：平衡的算力和数据遵循算力最优缩放定律，DeepMind 的 Chinchilla 模型通过模型规模和训练数据的成比例缩放，超越了大得多的模型，证明了这一点（Hoffmann 等人 2022）。

识别特定项目所处的机制可防止常见的低效：训练数据不足的过参数化模型，或浪费可用算力的欠参数化模型。

图 1.8：不同模型规模下的损失与数据集大小关系：测试损失曲线展示了不同规模模型（393K 至 708M 参数）如何从增加的训练数据中受益。更大的模型实现更低损失，但所有曲线在高 Token 计数下均表现出收益递减。

性能提升遵循可预测模式，但相关的设计动作随资源可用性以及在 ML 生命周期中投入算力的时点而变化。对系统设计而言还有两个关键区别：性能如何随数据集大小变化，以及在生命周期的何时应用额外算力。

数据集大小本身经历三个阶段（图 1.9）。样本很少时，泛化误差高且不稳定；随着数据增长，误差沿幂律可预测地下降，这是额外数据购买效用最大的阶段；最终在噪声底部饱和，更多数据带来的增益可忽略。系统层面的后果是，有限的高质量数据而非算力，一旦模型进入饱和机制，就会成为约束性瓶颈，这也是数据效率补充暴力缩放的原因。第 5 章将阐述这种饱和如何重塑训练数据管线和预算。

图 1.9：数据缩放机制：泛化误差作为数据集大小的函数表现出三个截然不同的阶段。小数据机制显示高方差；幂律机制展示可预测的误差降低；不可约误差机制代表根本的噪声底部。

生命周期的区分指出了集群可以投入算力的三个节点，如图 1.10 所追踪的：预训练，即实现扩展定律所需的、对故障敏感的长时间运行；后训练适配，即微调和偏好优化用许多较小、协调开销大的任务取代一次大规模运行；以及测试时计算，即每个查询额外的推理步骤以服务延迟和吞吐量换取准确性。每一个阶段都将约束瓶颈转移到了集群的不同部分，因此完整的处理方案属于其各自的工作负载：第 5 章针对预训练和后训练运行，第 10 章针对服务时的测试时计算。对于资源受限的部署，后训练和测试时扩展往往比从头重新训练模型更切合实际。

图 1.10：三个扩展阶段：智能（能力）通过连续的扩展机制得到提升。预训练随算力和数据扩展。后训练（基于人类反馈的强化学习，指令微调）优化行为。测试时扩展（思维链，搜索）在推理阶段榨取额外能力。

系统设计中的实际应用

当 OpenAI 确定 GPT-3 规模时，并未进行详尽的架构搜索；而是从较小规模实验中外推扩展曲线，以预先选定模型规模和 Token 预算。该决策是扩展定律如何指导实际系统设计和资源规划的最清晰例证。在定义明确的操作机制下，模型性能主要取决于规模而非独特的架构创新，尽管边际效应递减意味着每一次额外的改进都需要指数级增加的资源，以换取逐渐减小的收益。

具体而言，作者在当时可用的指导下（Brown 等人 2020；Kaplan 等人 2020）利用扩展定律外推来选择模型规模和训练数据。他们将成熟的 Transformer 架构扩展至 1750 亿参数和约 3000 亿 Token，从而能够提前预测模型性能和资源需求；后来 Chinchilla 的结果表明，相对于计算最优 Token 分配，该点是训练不足的（Hoffmann 等人 2022）。

扩展定律具有多种实际功能。在资源预算期间，经验扩展曲线有助于在固定计算预算下估算模型规模、数据集扩展和训练时长的投资回报。扩展趋势还揭示了架构变更何时能产生相对于单纯扩展收益的显著改进，从而减少详尽架构搜索的需求。当模型家族表现出良好的扩展行为时，扩展现有架构通常比转向未经验证的设计更有效。

同一原则在资源受限环境下反向适用。在边缘和嵌入式环境中，扩展定律使设计者能够选择在部署约束内提供可接受精度的较小配置。通过量化规模-性能权衡，这些定律指出了何时暴力扩展变得低效，并指向模型压缩、知识迁移和硬件感知设计。

扩展定律还充当诊断工具。尽管资源增加但性能停滞，可能表明维度饱和（数据量相对于模型规模不足）或计算利用率低效。这种诊断能力使扩展定律既具有预测性又具有指导性：它们预测目标能力所需的资源，并揭示系统为何偏离其预测轨迹。

可持续性与成本影响

扩展定律揭示了性能路径，同时暴露了快速升级的资源需求。随着模型扩大，训练和部署成本呈不成比例增长，在性能收益与系统效率之间制造张力。训练最大模型需要由成百上千个加速器组成的分布式基础设施，消耗数万 GPU-天和数百万千瓦时电力。第 5 章探讨了分布式训练如何在通信开销、同步和扩展效率方面引入额外复杂性。

大模型还需要大量高质量数据集以发挥潜力。随着模型逼近可用高质量数据的饱和点，特别是在自然语言处理领域，数据扩展带来的性能收益可能变得微乎其微。因此，数据效率是暴力扩展的必要补充。

这些成本中最尖锐的是环境成本，而它取决于集群运营商实际做出的一个决策：在哪里部署集群。同样的训练运行，取决于电网位置，二氧化碳排放量相差约 40 倍：从魁北克水电的 ~20 g CO2/kWh 到波兰燃煤的 ~800 g CO2/kWh⁹。这一单一的选址决策，加上将工作负载调度至低碳时段的作业调度，使得数据中心选址成为一项首要的基础设施决策，而非事后诸葛亮。财务成本同步变动：训练一个大型基础模型耗资数百万美元，这限制了谁能进行大规模研究。第 15 章展开完整的能源与碳核算，将这些压力转化为设计约束。

扩展定律不保证无限改进。每一步性能增益都必须与其资源成本权衡。随着系统逼近实际扩展极限，重点从单纯扩展转向高效扩展：在性能、成本、能耗和环境影响之间取得平衡¹⁰。

扩展定律失效条件

扩展定律在特定操作机制内成立，但在边界处失效。随着系统扩展，它们会遇到平滑、可预测扩展假设不再适用的条件。这些失效点暴露出需要改进设计方法的低效率。

大多数失效共享同一个根本原因：某一维度的增长超越了其他维度。Hoffmann 等人（2022）表明，许多大语言模型训练不足是因为模型规模增长快于训练 Token 预算，且计算最优训练要求参数和 Token 共同扩展。同类不平衡以其他形式出现。未针对更大模型重新调整的调度和学习率，使模型尽管投入了基础设施却无法发挥潜力；有限的高质量数据最终产生边际效用递减，导致更大模型开始记忆而非泛化；内存带宽、互联容量和 I/O 吞吐量的硬件上限，限制了万亿参数模型的分布式程度。在极端情况下，即使是平衡扩展也会触及训练分布所能教授内容的极限：基准数字持续上升而泛化能力不再提升，模型对对抗性或分布外输入变得脆弱。表 1.2 组织了这些失效模式，将每种失效类型映射到其根本原因和典型场景，以便从业者在投入预算前预判低效率。

| --- | --- | --- | --- |

| --- | --- | --- | --- |

| 训练数据规模 || 递减收益 || 新信息或多样化信息的饱和 || 网络文本扩展超出有用阈值 |

| 计算预算 || 资源利用不足 || 训练步数不足或使用效率低下 || 训练时长被截断的大模型 |

| 不平衡扩展 || 低效 || 模型/数据/计算的不协调增长 || 在没有更多数据或时间的情况下将模型规模翻倍 |

| 所有维度 || 语义饱和 || 领域内可学习模式的耗尽 || 尽管扩展了所有输入，但不再有收益 |

表 1.2：扩展失效类型：模型规模、训练数据规模和计算资源的不平衡扩展会导致特定的失效模式，例如过拟合或递减收益，影响系统性能和效率。该表对这些失效进行分类，确定其根本原因，并提供具有代表性的场景，以指导更有效的系统设计和资源分配。

这些问题旨在检查缩放定律是否被用作资源分配工具：

这些失效点表明，缩放定律描述的是特定条件下的经验规律，而这些条件在大规模下变得难以维持。辨别缩放在何处以及为何不再有效，将推动开发出不再单纯依赖规模扩大而能提升性能的策略。

将效率与扩展相结合

缩放定律揭示了墙壁；效率工程则开辟了绕过它们的路径。数据饱和、基础设施瓶颈和递减收益给暴力扩展所能达到的极限设定了硬性约束。然而，这些相同的约束也指向了沿三个相互关联维度的解决方案：

算法效率：稀疏性和蒸馏等技术能提取每 FLOP 更多的能力。
数据效率：课程学习和主动选择能从每个训练样本中提取更多信息。
系统效率：通信隐藏和流水线重叠能提取每个加速器更高的利用率。

每个维度都针对表 1.2 中的不同失效条件，并且在后续章节中均有详细论述。

缩放定律和效率技术决定了大模型需要多少计算以及集群利用得多好。然而，它们并未解决集群本身施加的物理和逻辑约束。硬件会故障，带宽会饱和，分布式系统面临根本性的不可能结果（如 CAP 定理），规模化的社会影响要求治理。这些约束无法通过优化消除；必须通过工程手段绕过它们。

规模的约束

这三堵墙描述了性能受限的地方；它们背后的约束则更为广泛。机器学习集群在三类不可消除的约束下运行：物理约束（内存墙、网络墙、能源墙本身，加上随着集群规模增长而出现的可靠性鸿沟）、逻辑约束（分布式系统面临 CAP 定理等不可能结果）、社会约束（规模放大了每一个技术决策的影响）。理解这些约束是后续诊断框架的前提。

可靠性鸿沟

在传统软件中，我们将硬件视为可靠的抽象层。单台服务器通常具有“四个九”（99.99%）的可用性，意味着每年故障时间约为 53 分钟。然而，机器学习集群运行在一种规模下，这种抽象不再成立，从而打开了可靠性鸿沟：在孤立状态下可靠的硬件，作为集群却变得不可靠。当一个集群协调 25,000 块 GPU 时，公式 1.1 将各个组件的概率相乘，得出整个系统处于健康状态的概率 (R_system(t))：

R_system(t) = (R_component(t))^N = e^(-N*lambda*t) (1.1)

此处，N 是集群中独立组件的数量，lambda 是单个组件的单位时间故障率，t 是时间窗口，R_component(t) 是单个组件在该窗口内存活的概率。工程启示在于指数部分：每增加一个组件，故障机会就会成倍增加，因此可靠性工程变成了一个扩展问题，而非善后任务。

如果集群中每个节点的可靠性为 99.9%，那么一个 1,000 节点的集群仅有 36.8% 的时间处于健康状态。将其扩展到 10,000 节点的集群，整个系统在任何给定秒数内处于健康状态的概率降至 0.0045%。图 1.11 追踪了两种单节点可靠性水平下，从 1 到 10,000 块 GPU 的集群规模的这种指数衰减。

图 1.11：可靠性崩溃：两种单节点可靠性水平下的集群可用性随集群规模变化的函数曲线。在单节点可靠性 99.9%（蓝线）时，1,000 GPU 集群仅保留 36.8% 的集群可用性；在 10,000 GPU 规模下，可用性崩溃至接近零。即使单节点可靠性为 99.99%（绿线），在 10,000 GPU 规模下也会降至 36.8%。

图 1.11 中的指数衰减使得架构后果不可避免：任何程度的单节点改进都无法在大规模下维持全集群的可用性。此处我们用单个单节点可靠性数值确立了这一概念；E.1 节推导了读者所需的完整故障概率级联和集群级可用性公式，以确定检查点间隔和冗余大小。工程教训是故障是常态。在大规模下，弹性取代预防成为主要目标：系统用绝对正常运行时间换取恢复速度、检查点质量和自动化修复。第 7 章的核心挑战正是从“让每个组件保持运行”转向“确保组件故障时集群能自我修复”。

通信强度（CI 比率）

如果单机铁律支配着系统如何执行，那么通信强度 (CI) 则决定了系统在哪里停滞。在单个加速器上，屋顶模型决定内核是计算受限还是内存受限。在集群规模下，这种分析上升到了网络层面。

公式 1.2 将通信强度定义为跨网络移动的数据量与本地执行的操作数之比：

CI = 传输字节数 (网络) / 执行 FLOPs 数 (本地) (1.2)

超过通信强度悬崖后，增加 GPU 将不再有帮助。

低通信强度 (CI < 0.01) 描述的是计算密集型工作负载，其 GPU 花费大部分时间进行数学运算，因此扩展相对容易。高通信强度 (CI > 0.1) 描述的是网络受限型工作负载，受限于剖分带宽，此时增加更多 GPU 可能会减慢训练速度，而非加快它。

通信与扩展优化

通信与扩展优化，从梯度稀疏化（减少发送的梯度字节数）到 3D 并行性（将数据、张量和流水线维度划分到不同的互连层级），旨在降低暴露的通信强度，使机器学习机群能作为一台巨大的单一计算机运行，而不是一堆等待网络传输的空闲处理器的集合。我们在此定义该比率并进行定性应用；第 C.3.3 节通过具体场景推演通信强度，并展示了带宽饱和点——在此点增加加速器将不再提升性能。

以下问题旨在检验规模思维是否已从本地执行转向分布式约束：

为何分布式很难

规模强制分布式：没有任何单台机器能为最大模型提供所需算力，也没有任何集中式系统能收集全球用户群产生的所有数据源。然而，跨有限带宽网络连接的物理分离机器协调计算，会产生工程手段无法消除的约束。

第一个压力源出现在数据中心内部，同步训练必须在分区和故障下选择保留多少一致性。第二个压力源出现在边缘，设备本身不可靠、受功耗限制且受策略约束。

CAP 定理的现实

CAP 定理¹¹ 确立了分布式系统最多只能同时满足三个属性中的两个：一致性、可用性 和 分区容错性。机器学习机群面临这三重约束，被迫做出显式权衡。

分布式机器学习系统根据需求做出不同的权衡。同步训练选择一致性：所有工作节点看到相同的模型状态，但若任何工作节点不可达，训练将停止。异步训练选择可用性：即使有落后者，训练仍继续，但工作节点可能在过时的模型版本上运行。联邦学习通常选择可用性与最终一致性，为边缘设备上的持续运行接受暂时的差异。

边缘分布式的复杂性

前文讨论的协调挑战假设为数据中心分布式，即机器运行在受管设施中。在网络边缘，这些挑战在各个维度上都会加剧。

数十亿部智能手机和物联网设备运行在不可控环境中，面临连接不可靠、功率有限的问题。隐私、同意或策略约束可能阻止原始数据离开设备，使联邦学习成为一种自然架构（McMahan et al. 2017）。间歇性连接迫使系统容忍跨越数天的异步更新。这些约束要求采用根本不同于数据中心机器学习的架构方法（差分隐私、设备端推理和模型压缩）。

当机器学习系统以数十亿用户的规模运行时，其社会影响要求超越技术卓越的考量。治理成为一项工程需求。

为何治理在大规模下至关重要

在机群规模下，技术缺陷即社会风险。

规模与分布将影响力放大至工程范畴之外。当系统服务数十亿用户时，一个技术缺陷就变成了社会风险。这种放大效应产生了小规模系统可安全忽略的治理要求。我们将治理定位为机器学习机群的控制平面，而非一套外部规则。

该控制平面首要任务是保卫机群。机器学习系统面临独特的安全威胁，这些威胁在生产规模下会加剧。模型提取攻击通过 API 查询窃取专有知识产权。数据投毒向模型植入后门，在特定输入触发前保持潜伏。在机群规模下，这些威胁成为复杂攻击者极具经济吸引力的目标。保卫机群需要系统性方法：访问控制、差分隐私¹² 和持续行为监控，这远超传统的边界安全。

同一个控制平面还必须使机群可审计。大规模运行的系统会引来监管关注。欧盟 AI 法案 等监管制度和地方隐私法使可审计性成为许多部署的架构要求。证明在 10,000 块 GPU 上训练的模型未摄入违禁数据，需要端到端的数据血统追踪。为亚毫秒级推荐生成人类可解释的说明，需要在服务架构中设计相应技术。满足这些要求需要从第一天起就将技术能力（审计追踪、偏见测试和同意管理）构建进基础设施。

除了法律合规，机器学习机群还承担着伦理义务。推荐算法塑造公共话语；招聘算法影响生计。这些系统不会像崩溃日志那样大声报错；它们通过偏见和极化无声地失效。负责任的 AI 是一项工程实践，将公平性、透明度和问责制视为不变量：一旦违反，应触发全系统停机的硬性约束。

C³ 分类法：规模的基石

刚才勘察的物理、逻辑和社会约束，均表现为浪费的挂钟时间，因此驾驭它们需要一种诊断手段，以指出这些时间究竟去向何处。单机分析的基石是数据·算法·机器（D·A·M）分类法，附录 A 将其作为完整的诊断框架加以展开。数据是系统学习的信息来源，当 I/O 管线无法以足够速度喂饱处理器时，性能即成为数据受限型。算法是被执行的数学逻辑，当算术单元成为限制因素时，性能即成为计算受限型。机器是物理硬件底座，当内存带宽或容量限制吞吐量时，性能即成为内存受限型。

从单机扩展到机群，引入了三种争夺挂钟时间的新基础资源。如果说经典的三堵墙指出了机群在何处受限，那么这三种资源则指出了机群的时间花在何处。C³ 分类法 将 D·A·M 视角延伸至机群，标识出机器学习机群的物理与逻辑边界。

计算（C₁，数学运算） 是在单个加速器上执行矩阵运算的本地过程，目标是让数学引擎保持峰值利用率运行。
通信（C₂，网络传输） 是数据跨网络结构的移动，受制于分割带宽和光速。
协调（C₃，逻辑控制） 是跨数千节点同步管理状态的过程，集合算法、容错和分布式共识决定了 N 个独立节点能以多高效率协同为单一计算机。

这三个维度构成了分布式效率三元组。若机群在通信或协调上花费过多时间，昂贵的计算产能将闲置。核心挑战在于设计机群，以最小化 C³ 差距：理论硬件峰值与实际分布式吞吐量之间的差值。此处引入三个维度作为框架工具；附录 B 将展开完整分类法，以及让读者能将瓶颈定位到三个 C 之一的诊断结构。

投影：从 D·A·M 到 C³

D·A·M 分类法描述了 workload：我们系统中的名词（我们拥有的数据、我们想要运行的算法、我们购买的机器）。C³ 分类法描述了 execution tax：舰队的动词（计算数学、传输结果、协调状态）。Appendix A 回顾了单节点 D·A·M 视角；C³ 分类法将该工作负载映射到分布式舰队上。将算法跨节点展开会产生通信，例如 AllReduce 操作用于同步梯度。将数据跨节点展开需要通过分布式采样器和检查点进行协调。舰队中的机器故障需要通过容错和慢节点缓解进行协调。

这两套分类法的交叉定义了舰队规模机器学习系统工程的完整设计空间。我们不是单独解决 D·A·M 或 C³ in isolation，而是解决它们的 cross-products。

The fleet law

C³ 分类法为每一次分布式训练步骤提供了一个诊断方程。要在大规模上推理性能，必须把单个组件的效率与整个系统的效率区分开来。在单机上，执行时间通常遵循性能铁律，T ≈ D[vol]/BW + O/(R[peak]η[hw]) + L[lat]，分解为数据移动、计算和开销。在舰队规模上，这种单机视角已不再足够：我们关心的是舰队随时间和能量的效率，并出现了并行分解。Equation 1.3 给出了 Fleet Law（分布式步骤时间法则），将分布式执行分解为其典型的分布式步骤组成部分：

T_step(N) = T_compute/N + T_comm(N) + T_sync(N) - T_overlap (1.3)

其中 T[compute]/N 是在将工作分配到 N 台设备后理想化的本地算术时间，Tcomm 是跨网络传输数据的时间（梯度同步、参数广播），Tsync 是同步逻辑消耗的时间（屏障、调度决策、故障恢复），T[overlap] 是被有用计算隐藏的通信时间。Equation 1.4 将此分解重新表述为计算时间比例，定义为有用数学占据的墙钟时间比例：

f_compute = (T_compute/N) / T_step(N) (1.4)

此分解是一个诊断工具。当 f[compute] 低于 0.5 时，超过一半的舰队昂贵硅芯片处于闲置状态。C³ 分类法识别出时间流向的 where：如果 Tcomm 主导，则升级互连或让通信与计算重叠；如果 Tsync 主导，则考虑异步方法或降低屏障频率；如果 T[compute]/N 主导，则舰队正在发挥作用。关键是 Displacement of Overhead 表明开销 cannot 被消除，只能在三个 C 之间重新定位。异步训练消除协调屏障却引入梯度陈旧；流水线并行减少通信量却增加气泡时间。分布式系统没有免费的午餐。

Google 的 ML Productivity Goodput 指标提供了该框架在生产规模上的具体实现。Goodput 将端到端训练生产力分解为三个乘法因子：Program Goodput (η[program])，衡量代码使用硬件（计算）的效率；Runtime Goodput (η[runtime])，捕获通信停滞和故障导致的损失（通信）；以及 Scheduling Goodput (η[scheduling])，捕获因抢占和重新配置导致的浪费时间（协调）。C³ 分类法是理论框架；Goodput 是生产团队的衡量方式。

Figure 1.12 将 C³ 框架可视化为三栏布局，Compute、Communication、Coordination 各占一栏，栏间的空隙突出显示维度交汇处出现的瓶颈。同一框架也可以画成三角形，顶点对应三种资源，边对应权衡，中心体现开销置换——即在独立机器上分布计算的不可避免后果。

Figure 1.12: The C³ Taxonomy：每个分布式机器学习系统将墙钟时间划分为三个不可约的维度：Compute（有用的数学）、Communication（网络数据移动）和 Coordination（同步逻辑）。图中将每个维度列为子主题的栏目，邻接维度之间的瓶颈在栏间空隙中标出。框架的底层主张——开销置换——断言开销不能被消除，只能被重新定位；这就是本书所有性能分析的诊断视角。

舰队法是时间侧的诊断工具，用于评估舰队在时间和能量上的效率：它询问在考虑通信、同步和重叠后，每一步分布式步骤中还有多少是有用的计算。Section B.3 完整推导并将每一项归因于物理原因。

The energy-scale invariant

舰队法管控时间，Energy-Scale Invariant 管控舰队的可持续性和经济可行性。大规模下，每一步训练都是一次热力学事件。Equation 1.5 定义了 fleet energy productivity (ρ[energy])，单位为 FLOP/J，衡量有用工作占总能耗的比例：

ρ_energy = O_useful / (E_compute + E_cooling + E_network) (1.5)

其中 O[useful] 为有用的 FLOP 工作，E[network] 随着我们在光纤结构上传输 TB 级数据而常常占据总预算的不可忽视比例。掌握规模需要在两条法则的帕累托前沿上进行优化：在最小化 T[step] 的同时最大化 ρ[energy]。我们在此引入不变量；Section C.4.2 详细说明规模下的能量层级以及约束 ρ[energy] 能被提升的热力学限制。

能量侧指标只是扩展诊断的一半。生产团队同样需要一个时间侧的效率标量，用以判断额外设备是缩短训练步骤还是仅增加协调开销。

舰队的 scaling 效率 (η[scaling]) 是理想并行步骤时间与实际步骤时间的比值：

η_scaling = T_1 / (N × T_N)

其中 T[1] 为单设备完成相同工作所需时间，T[N] = Tstep 为 N 设备上的步骤时间。Section B.3.1 提供了组件分解技术及分步示例，帮助读者数值化计算 η[scaling]。

舰队法是阿姆达尔定律的专门形式。分布式系统的最大加速受限于最紧耦合的组件，通常是网络同步。如果模型有 20% 的时间在等待网络（Tcomm），无论增加多少更快的 GPU，都不可能超过 5 倍加速。规模的瓶颈在于协调，而不是计算本身。

同时应用这两条法则到 GPT-3 级别的同步估计，使得协调税和其热力学对应在同一套缩放方程的条款中显现：同一个 Ring AllReduce 不仅让加速器失去时间，也在每一步燃烧能量。

大规模下，每个步骤仅约 4% 的时间用于计算；同步占据主导地位。

问题：当在由 100 Gb/s 以太网与 200 Gb/s InfiniBand 连接的集群上训练 GPT-3（1750 亿参数）时，会产生怎样的扩展效率和能耗成本？

物理层面：要同步 1750 亿个参数（FP16），Ring AllReduce 必须让每个参与的加速器端点在每次迭代中移动约 700 GB 的数据。

分析：舰队定律揭示了通信税。

InfiniBand（200 Gb/s）：高带宽和低延迟带来的扩展效率仅为 4.1%，这意味着加速器每 100 秒仅计算 4.1 秒，其余时间被同步消耗。
以太网（100 Gb/s）：较低的带宽和较高的开销使扩展效率进一步降至 2.1%，导致加速器每 100 秒仅有约 2.1 秒处于高效工作状态。

能耗：能量墙是同步的热力学成本。每个端点的梯度同步在网络结构中消耗约 84 J（按 15 pJ/bit 计）。在包含 1,000,000 步的训练运行中，仅端点网络数据移动就占用约 84 MJ 能量，这还未乘以参与的加速器数量。

系统洞见：规模使网络成为主要的“处理器”。如果网络效率低下，GPU 将空闲等待，浪费数百万美元的算力。此外，数据移动的热力学成本（能量墙）意味着，若无通信隐藏和压缩，“增加更多 GPU”并非可持续的扩展策略。

基础概念

舰队栈是本书的组织脊柱。前文引入的 C³ 分类法（图 1.12）为单个分布式步骤提供了局部诊断视角：哪里的墙钟时间花在了计算、通信和协调上。扩展定律预测目标能力水平需要多少计算，而治理约束定义了舰队绝不能做什么。这些视角支撑栈而非与之竞争。当章节需要追踪变化如何传播时，我们将使用大规模 AI 三元组；当需要分配责任时，我们将使用五大支柱图谱。依赖顺序源自舰队栈。图 1.13 将本书的复杂性组织为舰队栈，一个四层框架，底层的工程决策约束着顶层的可能性。

图 1.13：舰队栈：本书的组织框架。我们从基础设施层（计算、网络、数据）构建，向上经过分发层（并行、通信、容错）和服务层（推理、性能、边缘、运维），到达治理层（安全、鲁棒性、可持续性、负责任工程）。底层的工程决策约束着顶层的可能性。

这种分层递进构建了教材的四个部分：物理底座、分发逻辑、大规模部署和负责任的舰队。详细的章节映射见第 1.7 节；此处栈确立了依赖顺序。

大规模 AI 三元组是栈内的依赖提醒。每个机器学习系统包含三个相互依赖的组件：指导行为的数据、学习模式的算法，以及同时支撑训练和推理的计算基础设施。在生产规模下，这些相互依赖关系加剧。一个大约 10²⁵ FLOPs 量级的 GPT-4 级场景，需要能在数万张 GPU 间高效同步梯度的基础设施。此规模的训练数据要求分布式存储系统具备针对 ML 工作负载优化的访问模式。图 1.14 可视化了数据、算法和基础设施间的依赖关系，揭示了 ML 系统工程师必须面对的优化格局。

图 1.14：大规模 AI 三元组：每个 ML 系统的三个相互依赖组件。在生产规模下，每个组件的需求都会加剧：数据管线必须以一致的质量处理 PB 级数据；算法可能需要 10²⁵ FLOPs 进行大模型训练；而基础设施必须在保持容错的前提下协调数千个加速器。任一顶点的变化都会级联传播至其他顶点，构成了定义 ML 系统工程的多维优化挑战。

五大支柱框架将这些层级约束转化为所有权域。数据工程定义舰队必须摄入、转换和服务什么；模型开发定义消费大规模数据的架构和训练流程。优化随后将模型与其部署约束连接起来，当延迟、内存或功耗预算成为瓶颈时，对工作负载进行压缩或加速。部署基础设施提供云平台、网络结构和存储层级，使舰队可运行。运维（MLOps）通过测量部署系统在生产数据和硬件条件变化时是否保持可靠、安全和有效，闭合了回路。

生产框架之所以重要，是因为每个框架都用不同的名称和所有权边界实现相同的抽象原语。表 1.3 提供了跨框架映射，作为舰队栈各处开发原语的翻译辅助，而非工具排名。

|---|---|---|---|---|---|

表 1.3：框架罗塞塔石碑：主要框架中抽象分布式 ML 原语到其具体实现的映射。这些原语在成为约束条件的地方被开发，包括分布式训练（第 5 章）、集合通信（第 6 章）、推理（第 10 章）和运维（第 12 章）。

这些基元贯穿全书；该表是一个供随时查阅的参考，用于在每个基元被引入时回顾，而非当前需要死记硬背的大纲。六大系统工程原则为单个设计决策提供了标准：优先仪表化、为 10 倍余量设计、预期瓶颈会迁移、将故障视为稳态、跨车队累积微小效率增益、以及软硬件协同设计。在车队规模下，关于性能或可靠性的断言只有在经过仪表化时才有用，因为根因可能潜藏在模型、调度器、网络、存储层或服务路径中。这种度量规范支撑 10 倍设计：原型在展现出剩余余量所在之前，尚不算架构。随着规模增长，瓶颈从本地算力向通信与协调迁移，硬件故障成为常态，微小的效率增益因在车队中重复发生而变得显著。硬件协同设计遵循同一逻辑，因为网络拓扑、存储层级和加速器选择决定了哪些算法保持实用。这些是车队工程师应用的实践；全书最后将其提炼为分布式机器学习系统的持久原则。

这些框架共同假设读者熟悉单机机器学习系统：如何在单个设备上训练、优化和部署模型。本书教导工程师如何在全球机器学习车队中对其进行扩展、分发和治理。

三大系统原型

抽象框架通过具体工作负载变得具体。本书在每一章中贯穿追踪三大规模灯塔。每个原型占据 C³ 分类法的一个独特角落，以根本不同的方式分别施压通信、协调或算力，确保每条原则都在真实车队工程的多样性中接受检验。

原型 A（GPT-4/Llama-3）

GPT-4 和 Llama-3 是自回归 Transformer 架构，逐个 Token 生成文本。在单加速器规模下，自回归语言模型是内存带宽探针；在数千亿参数规模下，以及在某些专有系统中可能更大的规模下，这些模型定义了吞吐量受限 regime：训练要求在数千至数万个加速器上分布式维持 ExaFLOP/s 级算力，而服务则需要足够的内存带宽以加载数十亿权重来生成每个 Token。车队挑战在于：使用 3D 并行（数据、张量和流水线）将超大模型跨加速器车队分区，同时避免网络结构成为绑定瓶颈。在 C³ 分类法中，原型 A 由通信主导——集群间的梯度同步和激活传输消耗的墙钟时间多于算术运算本身。

原型 B（大规模 DLRM）

DLRM 是 Meta 用于个性化内容排序的生产架构。与由稠密矩阵乘法主导的 LLM 不同，推荐模型的容量源自海量嵌入表——将数十亿用户和物品特征映射为稠密向量的稀疏查找结构。单个生产 DLRM 实例可能包含 10 TB 或更多的嵌入参数，远超任何单个加速器的内存。车队挑战在于：跨数百个节点分片这些嵌入表，同时以 <100 ms 尾延迟处理每秒百万级查询 (QPS)，并在嵌入分片与稠密层之间管理 𝒪(N²) 级全对全通信竞争。在 C³ 分类法中，原型 B 施压协调：稀疏特征路由、分片放置、请求调度和嵌入更新一致性，决定全对全流量能否在尾延迟预算内得到服务。

原型 C（联邦 MobileNet）

MobileNet 是一系列高效卷积神经网络，专为在严苛功耗和内存预算下的设备端推理而设计。在联邦学习设置中，MobileNet 实例在数百万异构边缘设备（智能手机、物联网传感器、医疗穿戴设备）上本地训练，原始数据绝不离开设备。约束模式与数据中心原型定性不同：算力预算以毫瓦而非兆瓦计量，且隐私或政策约束可能禁止中心化数据聚合。在 C³ 分类法中，原型 C 由单设备级算力主导：每个本地训练步骤受边缘设备毫瓦级硅封装的算力约束，而非车队级网络带宽或协调协议约束。车队挑战在于：使用联邦平均法跨数百万此类算力受限、不可靠的设备协调模型更新，该方法在协调器处周期性平均设备更新，同时尽管数据分布非独立同分布 (i.i.d.) 且连接间歇性，仍保持收敛保证。

将这三个原型视为约束探针，而非模型家族目录。LLM 案例询问稠密同步能否让数千加速器保持有效利用，DLRM 案例询问稀疏特征路由能否满足尾延迟预算，联邦 MobileNet 案例询问本地设备约束能否被协调为统计上连贯的更新。表 1.4 总结了本书贯穿追踪的三种规范工作负载。

| 原型 | C³ 主导约束 | 车队挑战 |

|---------------|----------------------------|---------------------|

| 原型 A (GPT-4/Llama-3) | 通信 (车队级) | 使用 3D 并行将数千亿参数（及潜在的更大专有模型）跨数千至数万 GPU 分区，且不让网络成为瓶颈。 |

| 原型 B (大规模 DLRM) | 协调 (路由与放置) | 跨数百节点分片 10 TB+ 嵌入表；在管理稀疏特征路由、分片放置和 𝒪(N²) 全对全竞争的同时，以 <100 ms 尾延迟处理百万级 QPS。 |

| 原型 C (联邦 MobileNet) | 算力 (单设备包络) | 使用联邦更新跨数百万算力受限、不可靠的边缘设备协调学习；原始数据不得离开设备。 |

表 1.4：规模灯塔原型：本书贯穿追踪的三种规范工作负载，及其主导约束和各自引发的车队级挑战。

本教材结构

本教材围绕车队栈组织，从物理底层经分布逻辑推进至社会治理。章节顺序是依赖图谱而非主题清单：硅与散热的物理约束决定我们如何布线网络；网络极限决定我们如何分区训练算法；分区算法决定我们如何处理容错与编排；车队编排决定我们如何在生产中运营、安全防护和治理系统。每一部分解决一个根本规模障碍，阻止单机方案在生产规模下生效。

基础设施篇章始于没有任何算法能忽视的障碍：没有单台服务器拥有足够的内存、功率、散热或 I/O 来训练最大模型。因此第 2 章从高密度硅与设施物理切入，第 3 章将孤立机器织成集群级“梯度总线”，第 4 章通过让加速器吃饱数据同时不让存储成为隐形瓶颈来完成底层建设。

分布式训练篇章始于物理集群建成、协调开销不可避免之时。将数学计算拆分到多台机器上会产生两个新问题：副本必须以足够快的速度交换状态，以表现得像单个优化器；故障变成常态而非例外。第 5 章为拥有数千亿至万亿参数的模型制定分区策略，第 6 章解释将独立节点绑定成一个连贯计算机的通信原语，第 7 章将恢复速度视为比单节点正常运行时间更重要的指标，第 8 章管理多租户集群，负责作业的放置、隔离与重调度。

部署篇章将重心从训练模型转移到经济高效地服务模型。一旦模型投入生产，核心问题不再仅仅是训练耗时；而是延迟、利用率和全生命周期服务成本能否维持在运行包络线内。第 9 章通过算子融合与编译，缩小硬件峰值性能与实际吞吐量之间的差距，第 10 章将这些局部优化转化为面向百万用户的服务系统，第 11 章将智能推向毫瓦级功耗预算的设备端，第 12 章构建控制平面，监控全球部署的健康状况、漂移与性能。

治理篇章将责任视为工程层而非事后诸葛亮。在全球规模下，技术缺陷会演变为社会隐患：对手可投毒数据或窃取权重，开放世界输入可能击溃脆弱模型，能耗成为集群约束，治理失效可将技术能力转化为社会危害。第 13 章、第 14 章、第 15 章和第 16 章将这些义务作为必须设计、度量和运维的系统属性加以阐述。

谬误与陷阱

以下谬误与陷阱捕捉了那些浪费开发资源、错失性能目标，或部署出的系统与其运行约束严重不匹配的架构错误。每一种都代表了我们在从单机机器学习向机器学习集群过渡过程中反复见到的模式。

谬误：专注于算法效率，却忽视硬件-系统协同。

工程师往往优化 FLOPs 和参数量，假设这些指标能预测部署性能。真正的效率取决于数学运算与底层硬件的契合程度。例如，非结构化剪枝虽实现 80% 稀疏度，但在密集硬件（如 NVIDIA Tensor Cores）上却无法提速；而结构化剪枝在 50% 稀疏度下，在支持的硬件和内核上可实现高达 2× 的稀疏数学吞吐，但这并不保证端到端加速。将模型从 10B 参数剪枝至 3B 参数（FLOPs 减少 70%），可能仅带来 20% 的延迟改善，因为内存带宽瓶颈占主导，且剪枝模式缺乏硬件友好的结构。

仅削减 FLOPs 会让延迟仍受限于内存。

陷阱：优化单一指标而不检查系统层面的权衡。

“通用效率谬误” 假设量化或蒸馏等优化是“零成本的收益”。在生产环境中，每项优化都引入特定的权衡。INT8 量化实现 4× 内存压缩，但通常伴随 1–2% 精度损失。知识蒸馏实现 2–4× 压缩，但需要昂贵的教师模型训练。最优架构要求在精度、延迟和功耗间取得平衡，而非仅仅最小化资源消耗。

谬误：边缘部署的效率需求只是云端需求的缩减版。

这种 “云端精简版”谬误 将边缘系统视为资源受限的云系统。边缘设备面临质变的约束。例如，以 120 km/h 行驶的自动驾驶汽车，每 100 ms 的处理延迟就会转化为 3.33 m 的位置不确定性。云部署可扩展至千瓦级，而边缘系统则在 5–15 W 功耗预算下运行。一个云端优化的模型，拥有 95% 精度和 50 ms 延迟，可能在边缘设备上因热节流导致延迟增至 200 ms 且一小时内耗尽电量而变得不可用。

陷阱：假设缩放定律能线性预测所有规模下的效率需求。

“线性缩放谬误” 发生在团队使用幂律关系外推资源需求，却未考虑协调开销时。

ℒ(X) = A_ℒ * X^(−α_scale) + C_ℒ

在验证范围内有效，但在边界处失效。一个团队通过从 10B 参数实验外推来训练 100B 参数模型，可能预测到 3× 的提升，但若协调和通信开销消耗了扩展后步长时间的 40%，实际仅达成 1.8×。假设线性缩放设计的生产系统，当实际性能偏离验证阈值外的幂律预测时，曾经历 2–3× 的成本超支。

概要

本卷以一个根本性挑战开篇：在单机上取得成功的原则，成为阻碍大规模成功的障碍。我们已从实验室走向机器学习集群，在那里通信成本主导计算，故障是统计上的必然，社会影响要求严格治理。

从构建“能工作的系统”向构建“能扩展的系统”转型，代表了工程的下一个阶段。机器学习系统的核心原则（度量一切、优化瓶颈、为故障设计）依然关键，但当系统跨越数千节点时，其应用方式发生根本变化。网络拓扑变得与内存层级同等重要，车队协调取代了本地同步：更新、故障和共享状态必须跨多台机器管理。

这些原则共同重塑了工程师对系统设计的推理方式。当故障成为常态而非例外，当通信成本超越计算，在单机上磨练出的诊断直觉必须重新校准。内化这些约束的工程师，会从局部加速问题转向车队治理问题：协调开销出现在何处，节点消失时什么会失效，哪种一致性保证可以放宽。这种从优化组件到治理车队的转变，正是能够架构大规模系统的从业者与仅能在单机上原型开发者的分水岭。

更多 GPU 改变了问题的本质：在单节点上奏效的技术，在集群规模下不再仅仅是变慢；它们可能变得错误。剖分带宽、供电、可靠性和治理创造了单加速器实验中不存在的约束。
网络吞噬了所有加速：增加加速器分担了本地计算，却增加了同步、梯度流量和尾延迟风险。175B 参数模型每步可移动数百 GB 的梯度，因此有效 FLOPs 取决于通信，而非仅峰值算力。
故障成为稳态：拥有 25,000 张 GPU 的训练运行，单 GPU MTBF（平均故障间隔）以数万小时计，集群级故障仍每隔几小时发生一次。检查点、恢复和可观测性是基线设计要求，而非善后工作。

C³取代单机直觉：单机的数据、算法、机器透视投射为舰队规模下的计算、通信与协调。舰队定律让这一转变变得显性：扩展依赖于同步、重叠与一致性，正如依赖于硬件数量一样。

影响需要控制平面：基础设施规模的系统会将安全、隐私、公平性和策略失效放大到大规模用户群体中。治理不是基础设施的附录；它是决定舰队被允许优化和部署什么的机制。

本引言所论述的一切汇聚于一个反转之上。在规模化场景下，那些让单机变快的技术，反而成为阻碍舰队前进的枷锁，因为约束瓶颈已移至机箱之外。在单个加速器上，计算是成本，存储层级设定极限；跨越万卡，计算反倒是容易的部分，极限在于机器之间的一切——传递每个梯度的通信，以及让成千上万个节点就同一状态达成一致的协调。这就是分布式的物理法则，它遵循着自己的三字母定律：单节点由数据、算法和机器管辖，舰队则由计算、通信和协调管辖。本书其余部分将从芯片层面向上，推演这一转变，直至决定舰队被允许做什么的治理层面。

规模化的需求已确立：我们知晓为何必须分布式，何种物理成本会产生，以及哪些原则管辖机器学习舰队。然而，需求本身无法计算梯度。舰队需要一个能够支撑我们所描述工作负载的物理基础（硅、电力与制冷）。第 2 章开始构建这一基础，考察加速器架构、存储层级和电力输送系统，它们构成了舰队栈的基础设施层。

当工作负载跨入舰队规模的 C³ 领域时，单机 D·A·M 透视应如何改变？

何时增加加速器会减少而非提升有效的训练进度？

工程师应如何将缩放定律作为规划工具使用，而不将其误认为是基础设施保证？

为何治理应被视为舰队的控制平面，而非外部策略层？

舰队原则

机器学习舰队是仓库级计算机，其中网络是总线，功率密度是速度极限，故障是统计上的必然。延续课程对 AI 工程物理学的关注，第一部分构建规模的物理学：使分布式 ML 成为可能的硅、线缆、制冷系统和存储层级。我们从单个加速器转向数据中心级机器，此时工程问题不再是如何在单个设备上计算，而是如何在挑战物理基础设施极限的规模下移动能量和信息。

这一转变要求根本性的视角转换。在规模化场景下，单个 GPU 仅仅是一个更大、紧密耦合系统中的组件。舰队原则不是集群管理的最佳实践；它们是决定能训练什么样的模型以及如何服务的物理不变量。从散热的热力学极限到网络结构的对半带宽，这些约束定义了舰队栈的边界。管辖模式与单节点平行：节点受复杂度守恒在数据、算法和机器上的约束，舰队则受开销在计算、通信和协调（C³ 分类法）上的位移约束。规模的执行税无法消除，只能转移。

这些边界首先显现于设施本身：每一次操作最终都会变成必须被移除的热量。

不变量：不可逆计算和数据移动将电能耗散为热量；在数据中心规模下，实际极限是热量能被移除的速率。 $$\dot{Q}_{\text{limit}} = \frac{\Delta Q}{\Delta t}$$ 其中 Q̇[limit] 为最大散热速率，ΔQ 为热能，Δt 为移除时间窗口。

推论：现代 AI 数据中心的瓶颈不是 FLOP/s，而是每平方英尺瓦特数。当机柜产生 100 kW 热量时，风冷失效。舰队的物理设计由将热量从硅片带走的能力决定。

在机柜层面，同一热量预算变为密度约束。

不变量：集群扩展受热耗散极限（瓦特/机柜）和制冷能力约束，而非仅受硅面积或地板空间约束。

推论：现代 AI 加速器产生的热流密度超过了风冷能力。液冷成为大规模训练集群的设施刚需，而非可选项。

热容量设定外部包络；在内部，存储容量决定前沿模型必须如何分割。

不变量：前沿模型的内存需求增长速度比单加速器 HBM 容量更快、更不规则。

推论：模型不再适配单个设备。架构必须将 3D 并行性（通过张量并行和流水线并行分割模型本身）作为默认状态，打破“单设备”抽象。

一旦模型跨设备分割，网络便成为执行路径的一部分。

不变量：分布式应用的性能受限于网络拓扑的最小对半带宽。

推论：如果加速器由 1 Gbps 以太网树连接，拥有 10,000 块 GPU 的集群无法支持同步分布式训练。非阻塞拓扑（Fat-tree、Dragonfly）是确保网络不成为 AllReduce 等集体操作瓶颈的必要条件。

舰队还确定了效率的来源：在通用灵活性与硬件专用化之间抉择。

不变量：对于计算模式稳定的工作负载，专用化可通过减少通用开销来提升每瓦性能，但也会降低可编程性和工作负载灵活性。 ρ[energy,specific] ≫ ρ[energy,general] 在固定功率预算下

推论：从 CPU 到 GPU 再到张量处理单元 (TPU) 直至固定功能 ASIC 的演进，是取决于工作负载的架构权衡，而非通用物理定律。每一步都可用可编程性换取效率，舰队架构师必须为每个工作负载选择曲线上的最佳点。

计算效率仅在训练管线能持续喂饱加速器时才有帮助。

不变量：当存储吞吐无法以加速器消费数据的速度提供训练数据时，GPU 将空转，无论其算力多强。 $$\text{Utilization} = \min!\left(1,;\frac{\text{BW}{\text{storage}}}{N{\text{GPU}} \times R_{\text{consumption}}}\right)$$ 其中 BW[storage] 为聚合存储带宽，N[GPU] 为加速器数量，R[consumption] 为每个加速器的数据消费速率。

推论：足以支撑 8 块 GPU 的存储系统，在 64 块 GPU 时会成为瓶颈。I/O 墙随加速器数量扩展：加入集群的每一块 GPU 都提高了存储必须维持的吞吐下限，使数据管线而非模型成为限制因素。

满足这一需求需要层级结构，而非单一的无差别存储池。

不变量：随着数据离加速器越远，存储性能下降而容量增加。

含义：系统工程师的任务是确保正确的数据在正确的时间位于正确的层级。数据格式选择、缓存策略、预取缓冲区大小调整和分层策略的存在，都是为了管理向上穿越层级结构的数据移动，以便加速器不会“挨饿”（处于数据饥饿状态）。

即使数据到达了正确的层级，协调开销也限制了增加节点转化为吞吐量提升的效率。

不变量：向分布式训练作业添加节点会产生边际收益递减，因为通信开销随集群规模增长，而单节点计算量保持不变。$$ \eta_{\text{scaling}} = \frac{T_1}{N \times T_N} \leq 1 $$

含义：完美的线性扩展（η[scaling] = 1.0）是理论极限，而非实际目标。调优良好的密集训练作业在现代网络结构上，于中等规模下通常能达到 η[scaling] ≈ 0.85–0.95，并随 N 增长进一步恶化。η[scaling] = 1.0 与实际效率之间的差距即为通信税——即协调的代价。

这些不变量确立了“舰队”作为一个首要工程对象的地位。第一部分将从头构建这台机器：从分布式 ML 系统的全景及单机不再足够的原因入手，覆盖 AI 数据中心的硅基、电力与冷却系统、连接舰队的网络结构，以及为训练管线提供数据的存储层级。这些章节共同构成了基础，支撑我们将在本书中持续追踪的灯塔原型（第 1.6.1 节）。

算力基础设施

目的

为何不仅是算法，基础设施决定了谁能参与大规模机器学习的推进？

机器学习系统拥有超越代码的物理现实。虽然训练大模型的算法可能是公开的，但大规模执行它们的能力却受制于基础设施的物理特性。每一次训练运行都是一场与热力学极限、供电稳定性和数据移动成本的赛跑。当算法是主要瓶颈时，进步可以在任何地方发生。在大规模下，约束转向谁能构建和运行使规模成为可能的物理系统。构建 ML 舰队需要跨越四个物理层面的工程：加速器（硅物理）、节点（互连密度）、机柜（热管理）和 Pod（仓库级网络）。在每一层面，目标都是相同的：最小化数据在传输中花费的时间，最大化数据在计算中花费的时间。经济账同样残酷：大型加速器集群代表着巨额资本支出和兆瓦级的持续功耗。基础设施成为在最大规模下工作的组织的参与门槛。本章绘制该物理栈的全貌，从存储芯片的堆叠到电网级功率爬坡的稳定。用 C³ 术语来说，这个底座是舰队极限的起源：后续章节中关于计算和通信的每一个界限，都可追溯至此。

对比 GPU、TPU 和 ASIC 的数据流，以解释加速器谱系中的专业化分工
应用屋顶线分析，识别训练和推理中的计算受限、内存受限或带宽受限的极限
根据 HBM 容量、带宽、精度和模型状态大小，计算 Token 延迟或内存预算
将张量并行、流水线并行和数据并行映射到 NVLink、机柜和 Pod 带宽层级
使用功率密度、冷却极限、拓扑结构和设施可靠性约束，评估机柜和 Pod 设计
根据持续吞吐量、利用率门槛、能源成本和舰队总拥有成本，选择加速器基础设施

基础设施四堵墙

规模强制分布：计算、通信和协调，取代了数据、算法和单机的直觉。这些舰队级极限现在必须用硬件来买单。随着系统从单个加速器增长到仓库级 Pod，四个物理约束反复出现：内存带宽、供电、通信带宽和可靠性。图 2.1 展示了沿此路径每堵墙在何处成为主导约束。

物理栈始于硅芯片，并向外扩展通过四个层级。在每一层级，都出现相同的工程模式：一个约束变得难以忍受，而解决方案创造了下一层基础设施。节点聚合加速器以克服内存容量限制。机柜集中节点并面对供电和散热挑战。Pod 将机柜连接成仓库级计算机，并全面直面通信墙。从晶体管到数据中心的路径，以 175B 模型为线索，串联起各个层级。

图 2.1：四大基础设施墙：四个主要约束沿扩展之旅排列：功率墙（数据中心供电极限，约 40 MW 设施）、内存墙（HBM 带宽鸿沟，3.35 TB/s HBM3 对比约 2K TFLOP/s）、通信墙（网络二分带宽极限，每端口 400 Gb/s NDR IB）和可靠性墙（2.5 万 GPU 下 MTBF 约 2 小时）。每堵墙在不同规模下成为主导约束，从单 GPU、8 GPU 节点、1K GPU 集群到 2.5 万+ GPU 舰队。

加速器谱系

基石始于硅芯片，专用芯片之所以立足，是因为它能高效地做一件通用处理器无法高效完成的事：以最大吞吐量反复运行相同的稠密算术运算。设想 CPU 执行矩阵乘法时会发生什么。处理器取指、译码、检查数据冒险、通过深流水线路由操作数，并将结果写回寄存器文件。对于每一条乘累加操作，芯片都要在分支预测、投机执行、乱序调度和缓存一致性上消耗能量。

这些机制存在是因为 CPU 必须高效处理任意指令序列，从指针追逐的链表遍历到系统调用。然而对于神经网络负载，操作几乎总是相同的：乘以已知维度的两个矩阵，加上偏置，并应用非线性函数。CPU 精密的控制逻辑代表了对每次操作征收的“税”，它购买的是负载不需要的灵活性。这一概念映射了计算机架构中经典的精简指令集（RISC）与复杂指令集（CISC）之争：正如 RISC 处理器通过简化指令集实现更高吞吐量，ML 加速器通过简化计算模型以匹配主导负载模式，从而实现更高吞吐量。

现代服务器 CPU 将约 30–40% 的晶圆面积用于缓存，20–30% 用于控制逻辑（分支预测器、重排序缓冲区、指令解码器），仅有 5–10% 用于算术单元。这种分配对通用代码合理，因为分支不可预测且数据访问模式不规则。然而对于矩阵乘法，访问模式完美规律，控制流平凡可预测。每一个用于分支预测或投机执行的晶体管，本可以是一个乘法器。这就是通用性税（原理）：处理器在与主导负载无关的能力上浪费的硅面积。

加速器革命的核心，在于消除这一“税收”。从 CPU 到定制 ASIC 的演进每一步，都是通过去除一层通用控制逻辑，将更多芯片面积夺回给算术运算。这一演进是可量化的：CPU 将约 5%–10% 的芯片面积用于算术运算，GPU 约 50%–60%，张量处理单元 (TPU) 约 70%–80%，而专用定制 ASIC 可将 90% 以上的芯片面积用于目标计算。

从通用到专用芯片的过渡遵循着合乎逻辑的演进。光谱的一端，GPU 在保持大量可编程性的同时，提供了比 CPU 高 10–100 倍的矩阵吞吐量。另一端，定制 ASIC 将特定数据流固化在硬件中，以最大效率换取灵活性的牺牲。

理解每种架构落在该光谱的何处，以及为何如此，对于选择与特定工作负载相匹配的硬件至关重要。该光谱并非从“差”（通用 CPU）到“好”（定制 ASIC）的排序，而是一个权衡的连续体，其中每个位置都为不同的工作负载特征和部署约束组合提供最佳匹配。

GPU 代表了在保持可编程性的同时，从通用计算向大规模并行迈出的第一大步。例如，NVIDIA H100 包含 16,896 个 CUDA 核心，组织成 132 个流式多处理器 (SM)。每个 SM 可使用 单指令多线程 (SIMT)¹³ 执行模型同时执行数千个线程。与优化单线程延迟的 CPU 不同，GPU 通过维护数千个在途线程并在某线程因内存访问而停滞时在它们之间切换，来隐藏内存延迟。

程序员编写单个函数（即 内核 kernel），硬件将其映射到海量线程网格上。该模型足够灵活，可运行从卷积到注意力机制再到自定义损失函数的任意数学内核，同时为数据并行计算提供比 CPU 高出数个数量级的吞吐量。

权衡在于，不规则、分支密集的代码运行效率低下，因为 Warp（一组 32 个以锁步方式执行的线程）内发散的线程必须串行执行。当同一 Warp 中的线程走向 if-else 语句的不同分支时，硬件必须依次执行两个分支，在执行每个分支时禁用走另一条路径的线程。对于 ML 工作负载，这种发散惩罚通常很小，因为神经网络操作具有高度一致的控制流：矩阵乘法中的每个元素都遵循相同的计算路径。

TPU 更进一步，通过将数据流本身固化在硬件中，牺牲了部分可编程性，换取在单一操作类型上的最高效率。Google 的张量处理单元采用 脉动阵列¹⁴ 架构：一个固定的乘累加 (MAC) 单元网格，数据以规则的波浪式模式在相邻单元间流动。脉动阵列不再为每次操作获取和解码指令，而是在一边接收矩阵并将其脉冲式地推过网格，每个单元执行一次 MAC 并将结果传递给邻居。这完全消除了指令获取和解码开销，并避免了将中间结果写入内存，因为每个部分和直接流向下一次计算。

这种效率的代价是可编程性降低。模型必须通过加速线性代数 (XLA) 编译，将高级操作映射到固定数据流上。具有不规则控制流或动态形状的工作负载可能难以映射到该架构，且编译过程本身可能耗时（复杂模型需数分钟至数小时），这会拖慢模型开发时的迭代周期。

GPU 和 TPU 编程模型的区别对组织决策有实际影响。频繁修改模型架构的研究团队（添加自定义注意力模式、尝试新激活函数、原型设计新训练算法）通常倾向于 GPU 的 CUDA 生态系统，因为新操作可作为自定义内核实现，无需等待编译器支持。大规模运行成熟架构的团队（标准 Transformer 训练、大规模微调）可能倾向于 TPU，因为 XLA 编译器可优化整个计算图，对于标准操作往往能比手写 CUDA 内核实现更高的硬件利用率。

背景：2013 年，Google 工程师预测，如果用户每天仅通过语音搜索对着 Android 手机说话三分钟，公司就需要将数据中心算力翻倍以应对推理负载 (Jouppi et al. 2017)。成本高得难以承受。

洞察：Google 的 TPU 分析将生产环境神经网络推理定性为规模足够大的稠密线性代数工作负载，仅语音搜索的增长就可能导致服务算力需求翻倍。这一发现直接催生了 TPU v1，一种专用推理加速器，拥有 256×256 脉动阵列，可在 75 W 功耗包络内提供 92 TOPS (INT8) 性能。首批 TPU 于 2015 年部署，服务于 RankBrain 和 Google 神经机器翻译部分等生产推理工作负载 (Jouppi et al. 2017)；AlphaGo 对弈系统单独记录在案 (Silver et al. 2016)。

系统层面的教训：专业化之所以在经济上合理，是因为工作负载稳定、规模巨大，且由单一操作类主导。TPU 的故事是一个“通用性税”案例，而非单纯的“更快芯片”故事。

定制 ASIC 代表了光谱的极端，在此硅片经济性证明完全放弃通用可编程性是合理的。当组织以巨大规模运行单一模型架构时，为该工作负载专门设计芯片在经济上变得合理。通过去除目标计算不需要的每一项功能，定制 ASIC 实现了光谱上所有架构中最低的单位操作能耗和最高的持续利用率。

例如，Tesla 的 Dojo D1 芯片针对基于视频的视觉模型的时空结构进行了优化。其数百个紧密耦合的处理节点围绕 Tesla 视觉管线的数据流需求设计，片上 SRAM 尺寸经过设定，以使空间瓦片紧贴计算单元。这减少了通用 GPU 为同等计算所需的反复往返片外内存的开销。

AWS Trainium 采取了不同方法，面向 Transformer 训练这一广泛类别而非单一模型。Trainium 系统将编译器管理的内存调度与硬件辅助的集合通信相结合，使得张量并行同步和数据并行归约等常见训练模式可在加速器结构中得到优化，而非完全由主机软件处理。

定制芯片的风险同样清晰：如果主流模型架构发生转移（如 2017 年至 2020 年间从卷积神经网络 CNN 到 Transformer 的转变），为旧架构设计的定制 ASIC 就会变成搁浅资产。新 ASIC 从构想到部署的设计周期为 2–3 年，这意味着架构决策必须预测数年后的工作负载趋势。这一预测挑战非同小可：2015 年鲜有人预料到基于注意力的 Transformer 会在五年内取代 CNN 成为主流架构，而在该期间投入 CNN 优化 ASIC 的组织，发现其硬件因架构转变而搁浅。

因此，定制硅片是对工作负载稳定性的押注，而进行这种押注的组织通常是那些规模足够大、足以证明 5000 万至 2 亿美元开发成本合理、且拥有足够工作负载量以将单芯片 NRE（非经常性工程）成本摊销到数百万颗芯片上的组织。Google 之所以能证明 TPU 开发成本的合理性，是因为 Search、YouTube 推荐和 Gmail 垃圾邮件过滤等大流量服务可以摊销共享加速器平台的成本。而运行着几百张 GPU 的研究实验室则无法证明同等投资的合理性。

当工作负载稳定时，这笔押注回报丰厚：专用 ASIC 可为其目标运算提供通用 GPU 5 到 10 倍的能效。然而，押错注的后果很严重，因为芯片固定的数据流无法重新编程以适应根本性的新计算模式。将局部性论点进一步推演，会引出一个关于物理规模的更深层问题：单个芯片是否可以扩展到整个晶圆的尺寸。

晶圆级引擎

晶圆级引擎（WSE）代表了对数据局部性的极致追求。虽然该系列中的其他所有架构都依赖通过相对缓慢的 PCB 级或封装级互连连接的芯粒或离散芯片，但晶圆级引擎（如 Cerebras WSE-3）是一整块连续的硅片，大小相当于一个餐盘。通过避免将晶圆“切割”成单独的芯片，WSE 可以在其整个表面上维持单个大规模片上互连。

WSE-3 包含 90 万个针对 AI 优化的核心和 44 GB 片上 SRAM，全部通过提供 21 PB/s 内存带宽的硅织物连接。为更直观地理解这一点，单个 WSE-3 的算力相当于一个大型多 H100 集群，片上内存带宽相当于数千个 H100 HBM 链路，但由于整个系统位于单块硅片上，任意两个核心之间的通信延迟以纳秒而非微秒计。

正如图 2.2 所示，晶圆级集成的挑战是物理层面的：制造良率、供电和热膨胀。标准芯片上的单个缺陷可能导致其报废，但在晶圆级引擎上，软件必须具备“缺陷感知”能力，在硅织物中绕过局部制造缺陷进行路由。向单块硅片输送 23 kW 功率并对其进行冷却，需要专用的歧管级液冷技术，这更接近于工业管道工程而非传统计算机工程。

晶圆级引擎处于该系列的一个独特位置：它们在物理架构上高度专用，但在计算模型上却很灵活，因为底层核心通常足够通用，可执行多种 ML 内核。它们代表了一种“Scale Up（向上扩展）”理念，试图通过将集群变为芯片来消除通信墙。

图 2.2：晶圆级引擎（WSE）架构：与传统处理器不同，WSE 将整个 300 毫米硅晶圆用作单个连续的计算结构。这消除了“切割”工艺，并用高带宽片上网格取代了 PCB 级互连。软件必须具备缺陷感知，通过统一结构路由数据，将整个晶圆视为一个具有统一内存访问（UMA）特性的单一逻辑处理器，覆盖 90 万个核心。

关键的晶圆级权衡是用制造复杂性和缺陷感知路由，换取彻底消除芯片间通信瓶颈，使所有 90 万个核心在单个硅织物上彼此相距仅几纳秒。图 2.3 将这些架构置于一个连续谱上，揭示了支配每个加速器设计选择的可编程性与效率之间的根本权衡。表 2.1 将同一连续谱转化为工程师必须比较的架构特性。

图 2.3：加速器谱系：机器学习硬件领域涉及可编程性与效率之间的根本权衡。通用 CPU 提供最大灵活性但计算密度低。向定制 ASIC 和脉动阵列发展，通过硬连线常见数据流来提高每瓦吞吐量，代价是支持的模型架构范围变窄。

| 特性 | CPU | GPU (H100) | TPU (v5p) | 晶圆级 | 定制 ASIC |

|---------|-----|------------|-----------|-------------|-------------|

| 执行方式 | 指令 | SIMT | 数据驱动 | 数据流 | 硬连线 |

| 灵活性 | 极高 | 高 | 中等 | 高 | 低 |

| 效率 | 低 | 高 | 很高 | 高 | 极高 |

表 2.1：加速器谱系：从左至右，我们用通用可编程性换取计算密度和能效。晶圆级引擎占据了一个独特的利基市场，在单块硅片上提供集群级性能。

正如表 2.1 所总结的，对于我们的 175B 模型，选择不仅仅关乎峰值 FLOP/s。如果我们是每周都在尝试新架构的研究实验室，GPU 的灵活性足以证明其通用性税的合理性。如果我们要在未来数年大规模部署固定的 Transformer，TPU 的数据流效率或定制 ASIC 的功耗优势可能会主导总成本。归根结底，加速器谱系是一个经济问题：鉴于工作负载的稳定性，可以牺牲多少灵活性。

基于芯粒的加速器

一种主要的加速器设计模式是芯粒架构，典型代表有 NVIDIA 的 Blackwell 和 AMD 的 Instinct MI300 系列。芯粒设计不是制造单个整体芯片，而是将处理器划分为多个较小的芯片，通过公共封装基板上的高带宽芯片间互连将它们连接起来。这种方法解决了制约整体式设计的两个物理限制。

首先，最大芯片尺寸受光刻掩膜限制（第 2.2.3 节中探讨的 858 mm² 单次曝光上限）的制约，这限制了整体式 GPU 可集成的 Tensor Core、SM 和 HBM 堆栈数量。芯粒设计通过在单个封装上放置多个芯片来绕过这一限制，B200 的双芯片设计实际上创造了一个 1600 mm² 当量的处理器。

其次，制造良率随芯片面积呈指数级下降，因为芯片上任何位置的单个缺陷都会导致整个芯片报废。较小的芯粒具有更高的单体良率，而封装级集成允许部分良率（有缺陷的芯粒可替换为良品）。这种良率优势直接转化为单位算力的制造成本降低，这在晶体管密度持续增加、制程节点变得更加昂贵的情况下尤为重要。

权衡之处在于 die-to-die 互连。封装内芯粒之间的通信比封装间通信（NVLink）快，但比单个整体晶圆内部的通信（片上网格网络）慢。那些在处理元件之间产生频繁、细粒度通信的工作负载（例如在非相邻 SM 间共享数据的操作），当这些 SM 位于不同芯粒上时，可能会经历延迟惩罚。GPU 厂商通过使 die-to-die 链路对程序员透明来缓解这一问题，因此软件看到的是单个逻辑 GPU，而不管底层的芯粒拓扑结构如何。

GPU 架构的演进

过去十年 NVIDIA GPU 架构的快速演进展示了加速器设计如何适应不断变化的 ML 工作负载需求。每一代都引入了针对生产 ML 工作负载所暴露的特定瓶颈的架构创新，而不仅仅是增加晶体管数量。

Volta 架构（2017）引入了第一代 Tensor Core，认识到神经网络训练将其大部分时间花费在矩阵乘法上。通过在现有 CUDA 核心旁边添加专用的矩阵乘累加（MMA）硬件，Volta 可以在不牺牲使 GPU 对研究极具吸引力的通用可编程性的情况下，加速主导的工作负载模式。Volta 的旗舰产品 V100 在 300 W 功耗下提供了 125 TFLOP/s 的 FP16 Tensor Core 吞吐量。

Ampere 架构（2020）将 Tensor Core 支持扩展到了更多的数据类型（TF32、BF16、INT8、INT4），反映了混合精度训练和量化推理日益增长的重要性。A100 还引入了多实例 GPU（MIG），它将单个 GPU 分区为多达七个隔离的实例，从而实现昂贵硬件在多个推理工作负载间的高效共享。对基础设施影响最深远的变化是 Ampere 的第三代 NVLink，它将双向带宽从 Volta 的 300 GB/s 提升至每 GPU 600 GB/s，直接解决了张量并行的通信墙问题，后者将每层的矩阵分割到多个 GPU 上。

Hopper 架构（2022）增加了 Transformer Engine，它可以在逐层的基础上动态选择 FP8 和 FP16 精度，在无需手动精度调优的情况下，将 Transformer 模型的有效吞吐量翻倍。Hopper 还引入了 900 GB/s 每 GPU 的 NVLink 4.0 和 NVLink 交换机，使 NVLink 连接突破了 8-GPU 的边界。

H100 在 700 W 功耗下实现了 1979 TFLOP/s 的 FP8 Tensor Core 吞吐量，相较于 V100 效率提升了 6.8 倍，这是通过工艺技术（台积电 4N）、架构创新和精度工程（FP8 支持）相结合实现的。

Blackwell 架构（2024）延续了这一轨迹，B200 通过高带宽芯片间链路将两个 GPU 晶粒封装在单个封装内，有效地创建了一个“双晶粒 GPU”，在 1000 W 功耗下提供约 4,500 TFLOP/s 的密集 FP8 Tensor Core 吞吐量。FP16/BF16 对比应使用厂商针对低精度提供的特定数据，而非 FP8 峰值。

双晶粒方法承认了单晶粒 GPU 尺寸正逼近光刻设备的视场限制，进一步的扩展需要基于芯粒的设计。视场限制是光刻的基本约束：EUV 扫描仪的透镜系统只能在单次曝光中将图案投射到约 26 × 33 mm（858 mm²）的区域上。大于此面积的晶粒需要进行多次曝光和拼接，这在技术上虽可行，但会大幅增加成本并降低良率。

Blackwell 还引入了每 GPU 1800 GB/s 的第五代 NVLink，再次将节点内带宽翻倍。B200 封装内的 die-to-die 链路以 10 TB/s 运行，速度足够快，使得两个晶粒对于许多操作而言，可以在软件层面呈现为单个逻辑 GPU。

这一演进揭示了一个一致的模式：每一代都解决了上一代暴露出的瓶颈。Volta 为计算瓶颈增加了专用矩阵硬件。Ampere 扩展了混合精度支持。Hopper 瞄准了 Transformer 专用的 FP8 精度。Blackwell 通过多晶粒封装突破了晶粒尺寸限制。

在每一步中，加速器的设计都反映了其时代的一个重要工作负载，说明了工作负载的物理特性如何驱动硅的物理特性。这种工作负载与硬件的协同演进并非偶然：加速器架构师分析 ML 工作负载以识别瓶颈，然后设计后续代产品来解决它们。其结果是硬件演进与模型架构演进紧密耦合，这也是为什么自 2017 年以来 Transformer 工作负载深刻地塑造了加速器设计。

这种演进还为基础设施规划者揭示了一个令人清醒的采购模式：高端加速器世代的更迭速度可能快于容纳它们的设施。V100 作为旗舰训练 GPU 维持了约三年（2017-2020）。A100 占据该位置约两年（2020-2022）。Hopper 和 Blackwell 在 2020 年代中期延续了这种短周期模式。

规划启示在于：为加速器建设的数据中心必须在第一个机柜到货前就预判刷新周期。硬件刷新规划因此是初始采购决策的组成部分，而非事后诸葛亮。表 2.2 将这一节奏压缩为主要 NVIDIA GPU 世代以及随之而来的互连和功耗变化。

影响车队一致性的一个细微差别是 silicon lottery（硅彩票）——即制造现实中，4 nm 光刻的微观差异导致每个晶圆上的芯片质量呈分布状。NVIDIA 通过激进的分档来管理这条良率曲线：能在严格控制的电压下、全 TDP 条件下维持高频率的晶粒被指定为高端 H100 SXM 模块，而那些漏电流较高或有微小缺陷的则成为 H100 PCIe 卡或被降频融合为低端产品。即使在顶级 SXM 档位内，可实现的加速频率也因硅特性而异。在同步训练集群中，集体通信原语受最慢的参与者阻塞。单个芯片比车队平均值低 50 MHz 运行，就可能使整个集群的有效吞吐量下降 5-10%，这就是为什么复杂的车队管理系统会跟踪每 GPU 性能指标，并将表现不佳的硅片隔离到推理池中，那里单个芯片差异的影响不那么明显。

| 架构 | 年份 | 关键创新 | 峰值 Tensor | TDP | NVLink 带宽 |

|---|---|---|---|---|---|

| Volta (V100) | 2017 | 首代 Tensor Core | 125 TFLOP/s | 300 W | 300 GB/s |

| Ampere (A100) | 2020 | 多精度、MIG | 312 TFLOP/s | 400 W | 600 GB/s |

| Hopper (H100) | 2022 | Transformer Engine、FP8 | 1979 TFLOP/s | 700 W | 900 GB/s |

| Blackwell (B200) | 2024 | 双晶粒、NVLink 5 | 4,500 TFLOP/s FP8 | 1000 W | 1,800 GB/s |

表 2.2：NVIDIA GPU 架构演进——每一代都引入了针对其时代主导 ML 工作负载模式的架构特性。效率在各代间大幅但不均衡地提升，而 NVLink 带宽从 V100 的 300 GB/s 增加到 B200 的 1,800 GB/s，期间 A100 到 H100 只有较小的 1.5 倍增幅，夹在两次较大的翻倍跳跃之间。

表 2.2 概览

Table 2.2 将四个硬件世代压缩到几列中。Figure 2.4 拆开其中两列，即原始吞吐量和功耗效率，以揭示影响机群级基础设施决策的分歧。

图 2.4 – 加速器效率墙

六代 NVIDIA 数据中心 GPU 的峰值张量核心吞吐量（蓝色，左轴）和功耗效率（绿色，右轴），均采用对数刻度。该序列遵循每代 GPU 所宣传的低精度张量核心模式，因此精度变化属于硬件趋势的一部分，而不是可比较的 FP16 比较。原始吞吐量从 P100 到 B200 增长了 200×，但功耗效率（每瓦特 TFLOP/s）增长远低于此。阴影区域突出显示了电网、冷却系统和数据中心基础设施必须承受的扩大差距。

Figure 2.4 量化了一种关键不对称性：虽然每代 GPU 提供了戏剧性增长的原始吞吐量，但维持该吞吐量所需的功耗几乎以同样速度增长。从 P100 到 B200 的宣传低精度张量核心峰值增长了超过 200×，而每瓦特 TFLOP/s 的增长远低于此。精度模式在各代之间存在差异，但这本身就是硬件趋势的一部分：每一代通过引入低精度格式来部分提升计算密度。这种分歧是下一节中讨论的功耗墙的物理根源，也解释了为什么液冷、兆瓦级功耗供给和热管理在密集型加速器设施设计中占主导地位。

TPU 架构的演进

谷歌的 TPU 演进遵循另一条路径，专注于分布式效率和 XLA 编译器集成。虽然 GPU 强调单芯片峰值吞吐量和软件灵活性（CUDA），但 TPU 从一开始就被设计为一种“Pod 级”资源。每个 TPU 芯片诞生时即是更大集群的一部分，并配备专用的跨芯片互连（ICI）链路，完全绕过了主机 CPU。

该代序列展示了这种以 Pod 为先的设计如何从推理转向训练。TPU v1（2015 年）是一款专用推理芯片，具有 256 × 256 的收敛阵列，为谷歌生产推理工作负载中占主导地位的矩阵运算提供了 92 TOPS（INT8）。随后，TPU v2（2017 年）和 TPU v3（2018 年）通过添加 bfloat16（BF16）将架构转向训练，以避免标准 FP16 的动态范围问题，并将 Pod 概念扩展到 1,024 颗芯片和 100+ PFLOP/s 的总计算能力。TPU v4（2021 年）将相同逻辑延伸到网络层面，新增光电路交换机（OCS），使得物理拓扑可根据不同工作负载重新配置，同时将每颗芯片的 BF16 吞吐量提升至 275 TFLOP/s。

TPU v5p（2023 年）延续了这一以 Pod 为先的设计，用于高端训练。它具有 459 TFLOP/s 的 BF16 计算能力，95 GB 的 HBM2e 内存，内存带宽为 2,760 GB/s，以及每颗芯片 1,200 GB/s 的双向 ICI 带宽，专为十亿参数模型所需的大规模 AllReduce 操作进行了优化。Table 2.3 展示了这种以 Pod 为先的设计在 TPU 各代中的演变。Section D.2.1 阐述了集体通信复杂性模型以及 AllReduce 背后的算法选择，说明了随着模型规模增长，训练吞吐量的上限由跨芯片带宽而非单芯片算力决定。

| 代数 | 年份 | 关键创新 | 峰值 BF16 | HBM | ICI 带宽 |

|----------|----------|--------------|---------------|---------|--------------|

| TPU v1 | 2015 | 收敛阵列（推理） | 92 TOPS | — | — |

| TPU v2 | 2017 | 高带宽内存 | 45 TFLOP/s | 16 GB | 600 GB/s |

| TPU v3 | 2018 | 液冷，Pod 级 | 105 TFLOP/s | 32 GB | 650 GB/s |

| TPU v4 | 2021 | 光电路交换 | 275 TFLOP/s | 32 GB | 1,200 GB/s |

| TPU v5p | 2023 | SparseCore，HBM2e | 459 TFLOP/s | 95 GB | 1,200 GB/s |

表 2.3 – 谷歌 TPU 架构演进

TPU 的发展凸显了一种“Pod 先行”的设计理念，其中跨芯片互连带宽和编译器级优化（XLA）与单芯片峰值算术同样重要。注：TPU v1 仅支持 INT8。

正如 Table 2.3 所示，这一对比揭示了理念上的分歧。GPU 的演进是一场竞赛，旨在将更多算术和更高精度的张量核心集成到单个封装中，通过使用芯片组（Blackwell）来克服物理芯片尺寸限制。而 TPU 的演进则是一场竞赛，目标是构建更高效的仓库规模计算机，其中单个芯片的性能次于 Pod 的集体带宽和可重配置性（Barroso et al. 2019）。

加速器的算术引擎在 H100 上可达到近 2,000 TFLOP/s。然而，如果数据无法快速到达计算单元，原始算术吞吐量将毫无意义。限制每个加速器有效性能的根本瓶颈是存储墙。

存储墙

在选择了加速器的算术引擎后，我们面临一个悖论：我们的逻辑越快，它就越可能因等待数据而闲置。处理器吞吐量与数据访问速度之间这种日益分歧的趋势，正式被称为 存储墙 (Wulf and McKee 1995）。虽然晶体管缩放将逻辑性能提升了若干数量级，但为这些核心供给数据的物理互连却未能跟上步伐。这一点对机器学习而言至关重要：与传统软件不同，传统软件能从缓存和数据复用中获益良多，神经网络在每次推理过程中必须从内存中流式传输数十亿个权重，这通常使带宽——而非计算——成为性能的决定性约束。Section B.2 开发了一种诊断框架，用于将这种受内存限制的状况与其他 fleet 遇到的瓶颈模式进行分类，以便将测得的症状映射到具名约束上，而非纯粹猜测。

这一影响是具体且可感知的，在我们的运行示例中尤为明显。我们的 175B 模型的权重在 FP16 格式下占据 350 GB。在自回归解码过程中，这个完整的 350 GB 张量必须在每生成一个标记时，从片外内存流入处理器的寄存器。单个 H100 无法容纳该张量，因此在分片或量化解决了容量问题之后，这成为一个带宽下限计算问题。在 H100 级别的 HBM 带宽下（约 3.35 TB/s 每个加速器），如果只有一条等效于一个加速器的带宽路径必须流式传输这些权重，那么每个标记的数据移动 alone 将决定超过 100 ms 的延迟下限。存储墙不是一个抽象的架构概念：它是导致聊天机器人在词间出现可感知停顿的物理原因。有三种工程响应可应对这一限制：高带宽内存（HBM）拓宽数据通道，屋顶模型严格诊断工作负载是因数据不足还是算力不足而饥饿，以及张量核心最大化每个取出字节的算术价值。正如 Figure 2.5 所示，内存带宽也是一种布局权衡：将工作集移近计算单元可提升带宽，但通常会减少可驻留在那里的状态量。

图 2.5 – 加速器内存层次

峰值内存带宽和容量将本地 SRAM 设计、HBM 加速器以及边缘/共享 LPDDR 设备区分开来。虚线箭头标记了设计权衡：将数据移近计算单元可提升带宽，但通常会减少可存储在那里的状态量。

图 2.5 并非加速器的排名；它描绘了各种设计选择将字节置于何处。边缘设备保持存储廉价且紧凑，但带宽维持在低位。HBM 将内存移至加速器封装内，提供足够的容量和带宽以容纳活跃的模型状态。本地 SRAM 设计将工作集推得更靠近算术单元，以容量大幅缩减为代价，换取极高的带宽。该层级图解释了为何 HBM 是下一个工程响应：它虽非系统中最快的内存，却是唯一能在计算芯片旁容纳数十至数百 GB 数据的最高带宽层级。

HBM：突破内存墙

H100 可执行近 2,000 TFLOP/s 的低精度矩阵运算，然而在我们 175B 模型的自回归解码过程中，其 Tensor Core 在带宽受限模型中每个周期有超过 99% 的时间处于空闲状态。瓶颈不在于 multiplication 的速度，而在于 delivery（数据传输）的速度：一旦模型经过分片或压缩使权重适配，服务路径仍必须为每个输出 token 将活跃的权重分片流式传输通过算术单元。当现有的 Tensor Core 已因缺乏数据而“饥饿”时，增加再多的 Tensor Core 也无济于事。针对这一根本限制，加速器的回应是高带宽内存¹⁵。

单个加速器内的内存层级在容量和带宽上均跨越数个数量级。顶层是 register file（寄存器文件）¹⁶——分布在所有 SM 上，总计约 20–30 MB——拥有实际上无限的带宽（数百 TB/s），但容量极小。其下是 L1 缓存和 shared memory（共享内存，SRAM）¹⁷，每 SM 约提供 256 KB（总计约 33 MB），聚合带宽约 19 TB/s。再下一层是 50 MB L2 缓存（~12 TB/s），最后是 80 GB HBM3，带宽 3.35 TB/s。

原型 A（GPT-4）主要受吞吐量限制（需求更多 TFLOP/s），而原型 B（大规模 DLRM），即 DLRM 工作负载，主要受容量限制。单个 H100 的 80 GB HBM 无法容纳 10 TB 的嵌入表，单个 8-GPU 节点的聚合 HBM（640 GB）也无法容纳。仅容量一项就要求至少 16 个此类节点，这还未考虑复制、热表预留空间和带宽平衡；生产规模的推荐系统往往增长为更大的多节点分片，将内存访问问题转化为大规模 All-to-All 网络协调问题。

寄存器与 HBM 之间的带宽差距约为 100 倍。若单次操作需从 HBM 取数，算术单元将花费约 99% 的时间在等待。高模型 FLOPs 利用率（MFU），即用于有效模型计算的峰值硬件 FLOP/s 占比，仅能通过激进的 tiling（分块）实现：将巨大的权重矩阵分解为能完全放入共享内存和寄存器的小块，在驱逐该块前在其上执行尽可能多的买累加运算。如图 2.6 所示，此策略将数据加载一次至 SM 的快速 SRAM，并在多个 Tensor Core 操作中复用，从而有效提升每个从 HBM 取取字节的算术价值。

图 2.6：Tensor Core Tiling Strategy（Tensor Core 分块策略）：为克服 HBM 带宽瓶颈，GPU 将大型矩阵运算分解为适合流式多处理器（SM）快速 SRAM 的小块。数据加载一次至 SRAM 并在多个 Tensor Core 操作中复用，从而有效提升每个从 HBM 取取字节的算术价值。

尽管 175B 模型的总内存占用巨大，但在任何给定微秒内，活跃工作集必须严格管理以驻留在顶层 30 MB 寄存器空间中，否则芯片的理论性能将沦为海市蜃楼。HBM 提供海量容量，但分块决定了该容量能否以足够速度馈送算术单元从而产生实际作用。

High Bandwidth Memory (HBM)（高带宽内存）是 ML 加速器采用的 3D 堆叠 DRAM 架构，其中多个内存芯片垂直键合，并通过共享硅中介层上的数千个硅通孔（TSV）与处理器相连，消除了传统 DRAM 厘米级的 PCB 走线，取而代之的是微米级的垂直路径。

Significance（意义）：H100 的 HBM3 提供约 3.35 TB/s 内存带宽——约为 DDR5 ~200 GB/s 的 16 倍——能效为 2 pJ/bit，而 DDR5 约为 20 pJ/bit。此带宽设定了铁律中的带宽上限：H100 的 FP16 峰值点约为 989 TFLOP/s / 3.35 TB/s ≈ 295 FLOP/byte，因此算术强度低于 295 FLOP/byte 的算子（例如注意力机制的 5–20 FLOP/byte）即便有 HBM 仍属于内存受限。
Distinction（区别）：与通过厘米级 PCB 走线连接的 DDR 内存不同（引入电容、衰减和高驱动电流），HBM 使用 1,024 位宽的 TSV 总线，信号路径以微米计，信号距离减少 1,000 倍，从而在功耗不成比例增加的情况下实现更宽总线。
Common pitfall（常见误区）：一个常见误解是 HBM 解决了内存墙。HBM 只是移动了墙而非消除它：跨代际 Tensor Core 吞吐量（R[peak]）的增长快于 HBM 带宽（从 V100 的 900 GB/s 配 125 TFLOP/s FP16 到 H100 的 3.35 TB/s 配 989 TFLOP/s FP16），因此峰值点持续上升，尽管 HBM 改进，更多运算仍受内存限制。

传统 DDR 内存通过印刷电路板（PCB）边缘的引脚与处理器相连。每个 DIMM 通过 64 位总线通信，即使采用多通道（高端服务器 CPU 通常 8 通道），现代服务器的聚合内存带宽也仅约 200 GB/s。

从 DIMM 插槽到处理器芯片的物理距离以厘米计，每厘米铜走线都引入电容、信号衰减和能量损耗。在 DDR5 数据率（每引脚 4,800–6,400 MT/s）下，信号调理电路须补偿严重的通道损伤，导致每比特传输消耗大量功率。在这些长走线上提高数据率需要信号调理消耗逐渐增加的功率，形成边际效益递减曲线，DDR5 已逼近此极限。

HBM 通过彻底改变物理拓扑解决此问题，如图 2.7 所示。HBM 不再将信号水平布线穿过 PCB，而是将多个 DRAM 芯片垂直堆叠，并通过 Through-Silicon Vias (TSVs)（硅通孔）¹⁸ 连接：蚀刻穿过硅基板本身的微观铜柱。

图 2.7：HBM 3D-Stacked Architecture（HBM 3D 堆叠架构）：高带宽内存通过垂直堆叠 DRAM 芯片并经由硅通孔（TSV）连接来实现其性能。整个堆叠体与 GPU 芯片共同位于硅中介层上，实现 1024 位宽总线，将信号传输距离从厘米级缩减至微米级。这种物理邻近性是突破内存墙的关键。

3D 堆叠内存 vs. DDR5

垂直堆叠代表了内存架构的根本性变革：与其通过在长铜迹线中以更快速度推送信号来增加带宽（这是 DDR 的做法，收益递减），HBM 通过极短的垂直连接增加并行信号路径的数量来提升带宽。单个 HBM 堆栈将 8-12 个 DRAM 芯片垂直键合，通过每个芯片穿过数千个 TSV（硅通孔），形成每堆栈 1024 位宽的接口，而 DDR5 通道仅为 64 位。这种 16× 更宽的接口，结合更高的每引脚信令速率，构成了 HBM 带宽优势的来源。由于过孔穿过硅而非穿过 PCB，信号路径从厘米级缩短至几十微米——约 1000× 的减少——整个堆栈与处理器芯片位于同一硅中介层上，因此数据从 DRAM 单元传输到算术单元仅需纳秒级，而片外 DDR 需要数十纳秒。

缩短距离的物理优势

每比特能耗 – 传输成本降低一个数量级，从 DDR5 的 ≈20 pJ/bit 降至 HBM 的 ≈2 pJ/bit，因为更短的迹线具有更低的电容，所需驱动电流更小。
延迟 – 电信号在硅中传播速度约为光速的三分之二，因此更短的路径减少了传播时间。
信令速率 – 更低的电容允许在无需长 PCB 迹线所需的复杂均衡电路的情况下实现更高的信令频率，从而实现与宽总线宽度相辅相成的高每引脚数据速率。

这些效应共同解释了为什么 HBM 通过拓宽接口和缩短路径来提升性能，而非单纯提高片外引脚速度。

评估问题

表 2.4 总结了物理权衡：HBM 通过将内存移至封装内并拓宽接口来赢得带宽优势，而非通过加快每个片外信号的速度。

HBM vs. 标准 DRAM 对比

|---|---|---|---|---|

| 机制 | | 2D PCB 迹线 | 3D 芯片堆叠 | – |

| 带宽 | | ~200 GB/s | ~3.35 TB/s | ~17× 更快 |

| 接口宽度 | | 64‑bit | 每堆栈 1024‑bit | 16× 更宽 |

| 能耗 | | ~20 pJ/bit | 2–5 pJ/bit | 4–10× 效率 |

表 2.4：HBM vs. 标准 DRAM 对比 – HBM 通过三项同时创新实现带宽优势：3D 芯片堆叠（每封装更多位）、TSV 互连（更短信号路径）和片上封装放置（靠近处理器）。

成本考量

正如表所示，带宽优势伴随着代价。HBM 成本约为 $10–15 /GB，而 DDR5 服务器内存约为 $3 /GB。对于配备 80 GB HBM3 的 H100，内存本身约占加速器制造成本的 $800–1,200。对于配备 192 GB HBM3e 的 B200，内存成本上升至每个加速器 $1,920–2,880，使 HBM 成为系统中最昂贵的组件之一。

先进封装工艺——要求跨多个芯片层精确对齐数千个 TSV——良率较低且复杂度较高。每个步骤（芯片减薄、对齐、键合、TSV 蚀刻）均可能引入缺陷。跨 12 个堆叠步骤的累积良率意味着完整 HBM3e 堆栈的总体良率远低于单个 DRAM 芯片的良率。硅中介层本身必须足够大以容纳处理器芯片和多个 HBM 堆栈（通常超过 1,000 mm²），任何一个 TSV 的缺陷都可能导致整个堆栈报废。

供应链动态

HBM 供应链高度集中于少数制造商，其工艺（芯片减薄、TSV 蚀刻、芯片间键合）需要根本区别于标准 DRAM 制造的专用资本设备。扩大 HBM 产能需 12–18 个月的设备采购与认证，因此产能无法随需求激增快速扩展。当需求超越供应——如 2023 年大语言模型兴趣爆发后——交期延长至 12–18 个月，价格可能翻倍。

对基础设施规划者而言，这种集中意味着 HBM 的可用性（而非仅其规格）可能决定训练集群的建设时间表。组织必须提前 12–18 个月锁定 HBM 产能，在系统其余部分设计完成前投入资金。这一采购提前期长于堆栈中任何其他组件，使 HBM 成为车队扩张的节奏决定因素。

对大规模训练的经济影响

以 $10–15/GB 成本模型计算，对于我们的 175B 模型，1,000 张加速器集群中的 HBM 成本约为 $0.8–1.2 百万（每加速器 80 GB）或 $2–3 百万（每加速器 192 GB）。这种成本-容量权衡解释了为何加速器通常提供 80–192 GB HBM，而主机服务器提供 512 GB 至 2 TB DDR：快速内存存放活跃计算数据（每周期访问的权重、激活值、梯度），廉价内存存放其余数据（优化器状态、检查点缓冲区、数据加载队列）。

HBM 与 DDR 的驻留边界是训练框架的关键设计参数。高效管理该边界是关键挑战，由 5.3.3 节中所述的 ZeRO（零冗余优化器）分片与卸载策略解决。分片将优化器、梯度和参数状态跨工作节点划分；当 HBM 容量成为瓶颈时，卸载将冷数据置于主机 DRAM 或 NVMe。任一方向的错误判断代价高昂：过多存入 HBM 浪费昂贵容量，过多存入 DDR 则造成带宽停顿，导致算术单元空闲。

HBM 代际演进与扩展边界

HBM 的演进与模型规模增长紧密对应。每一代增加堆叠芯片数量、每引脚信令速率和每堆栈总容量，由模型参数的持续增长驱动。表 2.5 展示了扩展边界：HBM4 必须拓宽接口，因为仅靠引脚速率提升已无法维持所需带宽增长。

高带宽内存演进

|---|---|---|---|---|---|

| 峰值带宽 | | ~2.0 TB/s | ~3.3 TB/s | ~8.0 TB/s | 12–16 TB/s (预估) |

| 典型容量 | | 40–80 GB | 80–96 GB | 192 GB | 288 GB+ |

| 接口宽度 | | 1024‑bit | 1024‑bit | 1024‑bit | 2048‑bit |

表 2.5：高带宽内存演进 – 每一代增加聚合加速器内存带宽，追踪大模型规模增长。HBM4 自 HBM 推出以来首次将接口宽度翻倍，表明仅靠引脚速率提升已无法维持所需带宽增长。

正如表 2.5 所示，从 HBM3 到 HBM3e 的转变对我们的持续示例尤为重要。配备 80 GB HBM2e 的 A100 只能容纳我们 175B 模型 23% 的权重（FP16 精度）。配备 80 GB HBM3 的 H100 能容纳相同比例的权重，但数据传输速度提升了 65%。配备 192 GB HBM3e 的 B200 能容纳 55% 的权重，并以约 8 TB/s 的速度传输。两者都无法容纳完整模型，这正是我们需要在一个节点中使用多个加速器的原因，我们将在 2.4 节中讨论这个话题。

然而，当应用量化时，容量的情况会发生显著变化。量化为 INT8 的同一个 175B 模型仅需 175 GB，可装入 3 块 H100 GPU 或单块 B200 中。量化为 INT4 时，仅需 87.5 GB，可装入两块 H100 GPU 中。训练过程（通常需要 FP16 或 BF16 精度）因容量限制而驱动的多加速器节点需求，在推理过程（通常可接受 INT8 或 INT4 量化）中得到了实质性缓解。这也是训练和推理基础设施拥有不同最优配置的另一个原因。

带宽提升的意义独立于容量。一旦通过分片或量化解决了容量问题，每一代 HBM 在自回归推理期间都会产生近乎成比例的单 Token 延迟降低。

一个 70.6B 参数的 FP16 模型拥有 141 GB 的权重，因此带宽下限计算得出：在 A100 级别带宽下约为 141 GB/2.04 TB/s = 69.2 ms/token，在 H100 级别带宽下为 141 GB/3.35 TB/s = 42.1 ms/token，在 B200 级别带宽下为 141 GB/8 TB/s = 17.7 ms/token。A100 和 H100 的情况并不意味着完整的 FP16 模型能装入单个设备；它们隔离出了由单个加速器等效 HBM 路径施加的延迟下限。对于交互式应用（聊天机器人、代码助手、实时翻译），用户会感知到高于 50 ms 的延迟为“缓慢”，这些带宽改进直接转化为更好的用户体验，以及在延迟预算内服务更大模型的能力。

预计 HBM4 将接口宽度从 1024 位翻倍至 2048 位，这是自 HBM 推出以来的首次翻倍。这表明仅靠单引脚信令速率的提升无法无限维持带宽增长，总线必须拓宽。接口宽度翻倍需要相应更大的中介层面积来布线，这是随着带宽目标提高，加速器封装尺寸趋于增大的原因之一。

预计总带宽在 12–16 TB/s 范围的 HBM4 级封装，凸显了万亿参数规模模型带来的规划压力。一个 1 万亿参数模型在 FP16 下大约需要 2 TB 的权重存储。在 B200 级 HBM3e 带宽（约 8 TB/s）下，以批大小 1 服务此类模型将以 2000 GB/8 TB/s = 250 ms/token 的速度生成 Token，对于交互式应用而言远太慢。即使在 16 TB/s 下，在批处理、量化或张量并行分片之前，带宽下限仍约为 125 ms/token。这一计算表明，万亿参数模型即使在单请求推理下也需要激进的量化和多加速器张量并行。模型规模与存储技术的协同演进持续驱动着基础设施需求。

一个重要的架构考量是每个加速器的 HBM 堆栈数量及其与处理器的连接方式。H100 拥有 5 个 HBM3 堆栈，每个提供约 670 GB/s，总计约 3.35 TB/s 聚合带宽。B200 级 Blackwell GPU 封装使用 8 个 HBM3e 堆栈，聚合带宽约 8 TB/s。堆栈数量受限于可用于 HBM 放置的中介层面积：每个 HBM 堆栈占用约 100 mm² 的中介层面积，总中介层必须同时容纳处理器芯片和所有 HBM 堆栈。更大的中介层允许更多 HBM 堆栈（从而获得更高带宽和容量），但成本更高且制造更难。

中介层面积约束产生了具体的设计张力。增大处理器芯片（更多 Tensor Core、更多 SM）会留出更少的中介层面积给 HBM 堆栈，可能降低带宽。缩小处理器芯片（更少 Tensor Core）则为更多 HBM 腾出中介层面积，但会降低峰值计算吞吐。最佳平衡取决于目标工作负载在屋顶线图上的位置：计算受限工作负载受益于更大的处理器芯片（更多 Tensor Core），而带宽受限工作负载受益于更多 HBM 堆栈。C.3.1 节推导了区分这两种机制的脊点，通过公式 C.2 和公式 C.4 表达，使得工作负载的算力强度能在投片前预测其落在平衡的哪一侧。

内存带宽与 Token 延迟

内存容量（HBM 可存储多少千兆字节）与内存带宽（每秒可交付多少太字节）之间的区别，是 ML 基础设施中最具实践重要性的概念之一。容量决定模型权重能否装下。带宽决定模型能跑多快。对于自回归文本生成，每个 Token 都需要完整遍历模型权重，带宽几乎总是约束瓶颈。D.1 节为网络间的数据移动形式化了相同的延迟与带宽分解，为读者提供了一个统一的代数模型，既适用于此处的存储系统，也适用于后文的节点间传输。

问题：从 Llama-3 70B（141.2 GB FP16 权重）生成一个 Token 既需要算术运算，也需要从 HBM 完整加载权重。假设容量问题已解决（通过分片、更大容量设备或量化），在 H100 上每 Token 时间的主导因素是计算还是内存传输？

计算时间：每个 Token 需要 2 × 70 × 10⁹ = 1.4 × 10¹¹ 次浮点运算。在 989 TFLOP/s 的 FP16/BF16 Tensor Core 峰值吞吐下，算术运算耗时 T[compute] ≈ 0.14 ms。
内存时间：

以 3.35 TB/s 从 HBM 加载 141.2 GB 权重耗时 T[mem] ≈ 42.1 ms。

系统洞察：处理器 99.7% 的时间都在等待来自内存的数据。算术单元在几乎整个 Token 生成过程中都处于空闲状态。甚至一个拥有无限计算吞吐的假设处理器，生成 Token 的速度也仅会微不足道地快一点，因为内存传输时间完全占据主导。这就是为什么 HBM 带宽改进能为推理工作负载带来近乎线性的加速。

该带宽下限也为我们比较相邻硬件代际提供了清晰的方法：如果计算保持固定，而 HBM 容量和带宽提升，解码延迟应随存储系统变化，而非算术单元。

为了理解为什么“内存墙”是现代大语言模型（LLM）的主要约束，我们对比了 NVIDIA H100 及其继任者 H200。虽然两款芯片共享相同的计算核心（相同的峰值 TFLOP/s），但 H200 提供了 1.4 倍更高的内存带宽和 1.6 倍更多的 HBM 容量。

此乐高对比使用了包含 70.6B 参数、序列长度 2,048、批大小 1 的 Llama 3 模型；报告的加速比是服务求解器的 Token 间延迟估算值，而非单纯的原始带宽比。一个粗略估算能界定该求解器数值：解码阶段将 99.7% 的单 Token 时间花费在权重加载上，因此预期增益即为 HBM 带宽比，4.8 TB/s ÷ 3.35 TB/s ≈ 1.4 倍。

系统洞察

对于 LLM 解码，尽管拥有相同的算力，H200 的速度仍比 H100 快 1.4 倍；求解器的估算结果几乎完全落在带宽比率上，因为解码受限于带宽。这证明了对于大规模自回归模型，“墙”在于内存接口，而非算术逻辑。

草稿计算揭示了现代 ML 基础设施核心处存在的深刻不对称。加速器厂商投入数十亿美元设计更快的算术单元（更多张量核心、更高时钟频率、更宽数据路径），但在单请求推理中，算术运算只需几分之一毫秒即可完成，而内存传输却需要数十毫秒。对于这种负载，算术单元比内存系统快约 300 倍，这意味着推理期间，专用于计算的硅面积中 超过 99% 处于空闲状态。这种算力-内存不对称是关于 ML 推理最重要的单一物理事实，它塑造了服务基础设施的每一个架构和经济决策。

花在等待内存上的 Token 时间占比，在本例中为 99.7%，称为负载的 内存受限度。一个 99% 内存受限的负载，从更快的处理器（更高 TFLOP/s）几乎得不到任何收益，但会从更快的内存（更高 TB/s 带宽）获得近乎线性的加速。

内存受限度是内存墙的定量表达：数十年来处理速度与内存速度的差距不断扩大，在 ML 推理负载中尤为严重。内存墙最早由 Wulf 和 McKee 于 1995 年提出，他们观察到处理器速度每年提升 60%，而 DRAM 速度每年仅提升 7%。这种日益扩大的差距意味着处理器将花费越来越多的时间等待数据，而非对其进行计算。三十年后，他们的预言已被证实，而 ML 推理负载是现代计算中内存墙最极端的体现。

实际意义在于，针对推理负载的加速器选择应优先考虑 每美元带宽，而非 每美元 FLOP/s。一款拥有高内存带宽但算力适中的旧一代 GPU，其每美元推理性能可能优于一款拥有极致算力但带宽提升不足的最新一代 GPU。

图 2.8

图 2.8 直观展示了四代 GPU 中这种分化。当遵循每一代宣传的低精度模式时，峰值张量吞吐量从 V100 到 B200 增长了 36 倍，而内存带宽同期仅增长了 9 倍。算力增长与带宽增长之间不断扩大的差距即是内存墙：每一代加速器在算术上变得更强大，但相对而言也更加“缺数据”。

图 2.8：算力-内存分化 – 当遵循每一代宣传的低精度张量核心模式时，GPU 峰值张量吞吐量从 V100 到 B200 约增长了 36 倍，而 HBM 带宽同期仅增长 9 倍。这两条曲线之间不断扩大的差距即是内存墙：每一代加速器相对而言都变得更加“缺数据”。

对于训练负载，大批量增加了算术强度，权衡的天平倾向于算力：每美元峰值 TFLOP/s 成为相关指标，因为从 HBM 加载的权重数据被分摊到了批次中的许多 Token 上。我们接下来将探讨的屋顶线模型，为精确权衡提供了形式化框架，并能确定哪项指标对特定负载至关重要。

屋顶线模型

上述 Token 延迟计算表明，在 H100 上运行 70B 模型极度受限于内存。问题在于如何系统地判断任意负载在任意硬件上的这一属性。屋顶线模型¹⁹ 由 Williams、Waterman 和 Patterson 提出 (Williams et al., 2009)，它提供了一个视觉化和分析性的框架，用一个数字——负载的算术强度——就能回答这个问题。

对于 H100（989 TFLOP/s FP16，3.35 TB/s HBM），屋脊点约为 295 FLOP/byte；大多数 LLM 推理算子远低于此阈值，这正是屋顶线模型仍作为识别“增加算力还是增加带宽能提升性能”的首选诊断工具的原因。决定负载在该图表上位置的量是其 算术强度 (I)，定义为：

I = FLOP/byte

即计算量与内存流量之比，它决定了负载是受限于带宽还是受限于算力。该量在 9.1.5 节的舰队级性能分析中同样适用。

解码深处于内存受限区域，远低于屋脊点。

屋顶线模型将负载的最大可达性能表示为两个上限中的较小值：

可达 FLOP/s = min( R_peak , BW × I )

公式 2.1 具有直接的物理解释。如果负载的算术强度低（每次操作需要大量字节），则性能受限于内存供数据的速度。可达 FLOP/s 随 I 线性增长，在对数-对数图上呈现为一条斜线。如果算术强度高（每字节驱动大量操作），则性能在硬件的峰值算力处趋于平稳，无论 I 如何进一步增加。这个平台期就是模型中平坦的“屋顶”。

屋脊点 是内存带宽上限与算力上限相交时的 ML 加速器算术强度

(I_{\text{ridge}} = \frac{R_{\text{peak}}}{\text{BW}})

意义 – 它定义了硬件效率阈值。算术强度低于屋脊点的负载受限于带宽 (BW)，高于者受限于峰值算力 (R_peak)。
区别 – 与仅描述水平上限的峰值 FLOP/s 不同，屋脊点描述了架构的平衡性。硬件迭代中屋脊点的上升表明算力增长快于带宽，导致利用率更难提高。
常见误区 – 一个常见误解是所有 GPU 的屋脊点都相同。实际上它随精度变化：因为 INT8 的 R_peak 高于 FP32 而 BW 不变，INT8 的屋脊点高得多，需要更多数据复用才能饱和硬件。

典型负载

LLM 解码 (批量大小 1) – 每个 Token 需加载完整权重张量（约 2 字节/参数），却只对每参数执行 2 FLOP，产生 I ≈ 1 FLOP/byte。这深处内存受限区域，远低于 295 FLOP/byte 的屋脊点。我们的 Token 延迟计算证实了这一点：算术在微秒级完成，而内存传输耗时毫秒级。
LLM 预填充 (长上下文) – 并行处理长输入序列增加了 FLOP（矩阵-矩阵乘法而非矩阵-向量），却未成比例增加内存流量，将 I 推至 100–500 FLOP/byte。此范围跨越 H100 屋脊点：低端仍受限于内存或接近屋脊，高端则进入算力受限区域。
CNN 训练 (大批量) – 具有大空间维度和批量大小的卷积可达 50–200 FLOP/byte 的 I，使其处于大多数加速器屋脊点附近或之上。

注意力机制（长序列）：self-attention 机制在 FLOPs 上随序列长度呈二次方扩展，但在 KV 缓存的内存流量上呈线性扩展，这使得其算术强度依赖于序列长度。短序列受内存带宽限制；长序列受计算能力限制。

关键在于在 Roofline 模型上对每个阶段和批次形状进行分类，而不是为整个模型家族指定一个永久的区域。

阅读 Roofline 图需要理解每个轴的含义。横轴是算术强度（FLOP/byte），采用对数刻度。纵轴是可实现性能（FLOP/s），同样采用对数刻度。两条线定义了“屋顶线”形状：一条斜率为 1 的对角线（在对数-对数图上）代表内存带宽上限，一条水平线代表峰值计算上限。这两条线在屋脊点相交。

任何工作负载都可以通过计算其算术强度并测量其实际性能，作为图表上的单个点绘制出来。如果该点位于对角线上，则工作负载受内存带宽限制，更快的内存将提升性能。如果位于水平线上，则工作负载受计算能力限制，更多的算术单元将提升性能。

如果该点位于任一线条之下，则工作负载未充分利用可用资源。这一差距表明软件层面存在优化机会：内核效率低下、内存访问模式不佳或同步开销过大。缩小这一差距属于内核工程和通信优化的范畴，详见第 9 章。

Roofline 模型的诊断能力不仅限于单个内核，还延伸至整个训练运行过程。对于我们的 175B 模型，计算图包含数千个具有不同算术强度的不同操作。稠密的前馈网络（FFN）层由大规模 GEMM 主导，具有高算术强度，稳居计算受限区域，其中 Tensor Core 利用率是瓶颈。相反，LayerNorm 和逐元素激活函数等操作具有低算术强度，深陷内存受限区域，计算单元在等待数据时处于空闲状态。self-attention 机制则根据序列长度在两种区域间波动：虽然注意力分数的二次复杂度暗示计算受限，但在较短序列下，Key 和 Value 矩阵的加载会产生内存压力。这种诊断区别决定了优化策略：内存受限层受益于内核融合（减少 HBM 往返），而计算受限层受益于降低精度（从 FP16 降至 FP8，从而有效提高硬件的计算上限）。

图 2.9 直观展示了 H100 上的这些关系。注意 LLM 解码在批次大小为 1 时深陷内存受限区域，仅达到峰值计算的 1% 不到，而大批次 LLM 训练则跨越屋脊点进入计算受限区域。在贯穿示例中使用的批次大小 2048 简化假设下，这两种工作负载算术强度约 2,048 倍的差距（解码约 1 FLOP/byte 对比训练约 2,048 FLOP/byte）解释了为何同一硬件在训练时吞吐率优异，而在推理时却显得严重利用不足。

图 2.9：Roofline 图景：NVIDIA H100 (FP16)：H100 Roofline 图展示了内存带宽与峰值计算上限，以及横跨内存受限和计算受限区域的典型 ML 工作负载。

图 2.9 中的 Roofline 由两个上限定义：内存带宽（对角线）和峰值计算（水平线），二者在 FP16 屋脊点（约 295.2 FLOP/byte，对应 989 TFLOP/s 除以 3.35 TB/s）相交。ML 工作负载覆盖全范围：批次大小为 1 的 LLM 解码深度受内存限制，而大批次 LLM 训练受计算限制。每个工作负载的位置决定了是更快的内存还是更快的计算能提升性能。

Roofline 模型还揭示了批次大小与硬件利用率之间微妙但重要的相互作用。对于给定模型，增加批次大小会提高算术强度，因为权重矩阵仅加载一次，却与更大的激活矩阵相乘（传输字节数不变的情况下 FLOPs 更多）。这使工作负载点在图上向右移动，有可能跨越屋脊点，从内存受限区域进入计算受限区域。算术强度随批次大小线性增长（批次大小翻倍使 FLOPs 翻倍，而权重加载保持不变），在批次大小与硬件利用率之间建立了简单且可预测的关系。

对于推理服务，将多个请求批处理在一起能显著提高硬件利用率和吞吐量。一个在批次大小 1 时仅达到峰值 FLOP/s 1% 的模型，在批次大小 64 时可能达到峰值 FLOP/s 的 50%，仅仅因为从 HBM 加载的权重数据在 64 个独立请求中被复用，而非仅服务于 1 个请求。这种硬件利用率 50 倍的提升是有代价的：64 个请求必须等待凑齐一个完整批次才能开始处理，引入了排队延迟。服务系统必须在吞吐量（大批次、高利用率）和延迟（小批次、单请求响应更快）之间仔细权衡。

对于训练，批次大小是一个影响统计收敛和硬件效率的超参数，从业者必须谨慎应对这种权衡。更大的批次大小能提高硬件利用率（将工作负载推向计算受限区域），但可能需要调整学习率和预热策略以维持训练质量。最优批次大小取决于模型架构和硬件的 Roofline 特性，形成了一个跨越 ML 理论与系统工程的跨学科优化问题。

Roofline 模型的实用价值在于它指明了该优化哪种资源。如果工作负载受内存带宽限制，购买更快的加速器（更高 TFLOP/s）毫无益处；只有更高的内存带宽才能有所帮助。反之，如果工作负载受计算限制，升级 HBM 代际就是浪费钱。正是这种诊断能力，使得经验丰富的基础设施工程师在开始硬件选型时，总是先计算目标工作负载的算术强度，并将其绘制在候选硬件的 Roofline 图上：该图能立即揭示哪个硬件特性关键，哪个无关紧要。

对于我们的 175B 模型，大批次训练受计算限制（优化 TFLOP/s），而单请求服务受内存限制（优化带宽）。这种二律背反解释了为何一些组织对训练和推理使用不同代际的硬件。尽管 H100 拥有更高的峰值 FLOP/s，但 A100 凭借更低的成本和足够的内存带宽，在推理场景下可能比 H100 更具成本效益。

Roofline 模型还为评估不同优化手段的投资回报率提供了定量框架。如果工作负载距离计算上限有 10 倍差距，却已触及带宽上限，那么投入工程精力进行内核优化（向计算上限靠拢）将毫无收益。精力应转向通过批处理、内核融合或量化等技术减少内存流量（使工作负载在图上右移）。

天际线诊断能力

天际线的诊断能力使其成为基础设施工程师工具箱中最实用的分析工具之一。在投入任何硬件采购或优化工作之前，在天际线模型上绘制工作负载，能立即揭示该投资是否会带来回报。跳过此分析的团队面临着花费数月时间优化错误资源的风险，而当 GPU 算力每天成本高达数千美元时，这是一个代价高昂的错误。

相同的算术强度计算将运行模型的推理和训练模式区分开来。

`175B` 模型在 `H100` 上

考虑我们在具有 989 TFLOP/s 峰值算力和 3.35 TB/s 内存带宽的 H100 上的 175B 模型。转折点（ridge point）为 295.2 FLOP/byte。

推理（解码，批次大小 1）

每个 token 加载 350 GB 的 FP16 权重并执行 2 × 175 × 10⁹ 次 FLOP。

算术强度：I = \frac{2 \times 175 \times 10⁹}{350 \times 10⁹} = 1 FLOP/byte。

由于 1 FLOP/byte ≪ 295.2 FLOP/byte（转折点），该工作负载严重受内存带宽限制。可实现的吞吐量为 3.35 × 1 = 3.35 TFLOP/s，约为 H100 峰值 989 TFLOP/s 的 0.34 %。无论增加多少算力都无济于事；只有增加内存带宽才能提高吞吐量。

训练前向传播（批次大小 2048）

相同的权重张量与一批 2048 个激活向量同时相乘，将矩阵-向量运算转变为矩阵-矩阵运算。FLOP 增加了 2048×，而权重加载保持不变：I = 2048 × 1 = 2,048 FLOP/byte。由于 2,048 FLOP/byte ≫ 295.2 FLOP/byte，该工作负载受算力限制。现在的可实现吞吐量受峰值算力上限 989 TFLOP/s 限制，内存带宽不再相关。增加更多 TFLOP/s（通过更新一代 GPU）可直接提升性能。

系统洞察

这种对比解释了为什么组织有时对训练和推理使用不同的硬件：训练受益于峰值 FLOP/s，而 推理受益于每美元的内存带宽。

当拟议的升级改变了错误的上限时，同样的诊断最为宝贵。

一个团队在 H100 上以批次大小 1 服务 13B 参数模型，观察到每 token 25 ms。分析显示解码期间张量核心利用率低。

张量核心与矩阵单元

天际线模型告诉我们工作负载能否达到峰值算力。下一个问题是是什么决定了这个峰值。答案在于占据现代加速器芯片面积大部分的专用算术单元：NVIDIA GPU 上的 Tensor Cores（张量核心）和 Google TPU 上的 Matrix Multiply Units (MXUs)（矩阵乘法单元）。

标准 CPU 浮点单元每周期每通道执行一次乘累加运算。即使有宽 SIMD 单元（AVX-512 提供 16 个 FP32 通道），CPU 核心每周期最多执行 16 次 MAC 运算。拥有 32 个核心的高端服务器 CPU 每周期可达约 512 次 MAC 运算，这对于通用计算尚可，但完全无法满足神经网络规模矩阵乘法的需求。

相比之下，Tensor Core 在专用硬件上以单条指令执行小矩阵瓦片的矩阵-乘累加（MMA）运算 Y = A × B + C。在 H100 上，这些瓦片运算分布在每个 SM 中的张量核心阵列中，每条指令产生数百个累加结果，同时将操作数保留在寄存器和共享内存中。这将主要的神经网络运算集中在仅占芯片面积一小部分的硬件中。

H100 全芯片拥有 528 个张量核心（每 SM 4 个，共 132 个 SM），达到天际线分析中使用的 989 TFLOP/s FP16/BF16 峰值。重要的系统层面观点不在于精确的每周期指令核算，而在于架构专业化：芯片将其算术面积的很大一部分用于稠密瓦片矩阵运算，而非通用标量执行。

Google 的 MXU 通过将乘法器组织成收缩阵列，将这一概念推向更远。在收缩式 MXU 中，一个矩阵被加载到阵列的权重寄存器中，而另一个矩阵一次一行地流经阵列。每个单元将传入的激活值与其存储的权重相乘，将结果加到从上方单元流来的部分和上，并将激活值向右、部分和向下传递。这种流水线流动意味着阵列在每个周期都在执行有用计算，一旦流水线填满，就没有空闲单元。TPU v5p 每芯片包含两个 128 × 128 的 MXU，提供 459 TFLOP/s 的 BF16 吞吐量。收缩数据流消除了张量核心仍需的运算间寄存器文件访问，以牺牲运行非矩阵工作负载的灵活性为代价，实现了略高的能效。

对于我们的 175B 模型，张量核心与 MXU 的选择体现在编译器栈中。CUDA 内核可将张量核心运算与任意线程级代码混合，支持融合内核，在一次启动中将矩阵乘法与激活函数、Dropout 和层归一化结合。这种融合对性能至关重要，因为它消除了操作间本会发生的中间内存读写，将数据保留在访问最快的寄存器和共享内存中。

面向 TPU 的 XLA 编译必须将计算分解为映射到收缩数据流的矩阵运算序列，这对标准 Transformer 架构可能更高效，但对自定义运算灵活性较低。XLA 编译器执行全程序优化，分析整个计算图以寻找收缩阵列的最佳分块、内存布局和执行调度。对于标准 Transformer 层，这种全程序优化可比手工调优的 CUDA 内核实现更高的硬件利用率，因为编译器能推理整个计算，而非孤立地优化单个运算。

硬件决定了软件抽象，软件抽象反过来塑造了哪些架构可供实验。这种软硬件耦合是 ML 基础设施的决定性特征，解释了为何硬件选择会对研究速度和模型设计灵活性产生下游影响。

张量核心定义

Tensor Core（张量核心）是一种专用 ML 加速器硬件单元，作为单条硬件指令对小瓦片（如 BF16 下的 16 × 8 × 16）执行融合矩阵-乘累加（MMA）运算 Y = A × B + C，通过牺牲可编程性换取定点矩阵算术，提供比通用 CUDA 核心高得多的吞吐量。

意义：张量核心提供了 H100 989 TFLOP/s FP16/BF16 峰值（FP8 下约 1,979 TFLOP/s）的大部分——约为单独 CUDA（向量）核心提供的 ~67 TFLOP/s 的 14.8×。然而，此峰值仅适用于可分解为瓦片矩阵乘法的运算。层归一化和 Softmax 涉及归约和逐元素运算而非矩阵乘法，在同一硬件上仅能达到峰值吞吐量的约 3–8 %。
区别：与通用 CUDA 核心（在 SIMT 流水线中每时钟每通道执行一条浮点运算）不同，张量核心在矩阵瓦片上每时钟每 warp 执行 512 次乘累加运算——用矩阵算术的特定吞吐量换取了 CUDA 核心的任意逐元素可编程性。

3. 常见陷阱：一个常见的误解是所有 GPU 操作都能从 Tensor Cores 中受益。只有映射到 `Y = A × B + C` 瓦片计算的操作（如密集线性层、注意力分数计算、卷积）才会激活 Tensor Cores；逐元素激活、层归一化和嵌入查找则会回退到 CUDA 核心，每 FLOP 的运行速度可能比 Tensor Core 操作慢 10–30 倍。

随着每一代 Tensor Cores 的精度支持不断扩展，这一进步源于对神经网络训练和推理能够承受比之前假设的更低数值精度的发现。Volta 代代仅支持 FP16 累加。Ampere 添加了 BF16、TF32 和 INT8。Hopper 添加了 FP8（包括 E4M3 和 E5M2 两种格式），并通过 Transformer Engine 实现动态逐张量缩放。

Transformer Engine 会自动监控每个张量的幅度分布，在精度足够时选择 FP8，或在需要更高精度时选择 FP16，从而在 FP8 足够的层中实现有效吞吐量翻倍。这种硬件辅助的精度管理代表了算术设计与模型层面洞察的融合：硬件不再是程序员精度选择的被动执行者，而是精度决策的主动参与者。

理解两种 FP8 格式之间的区别有助于说明这一点对实践者为何重要。E4M3 格式（4 位指数，3 位尾数）可以表示的最大值约为 4.48 × 10²，3 位尾数提供约 1/8 的相对精度。在此范围和精度下，许多神经网络权重和激活值在经过逐张量缩放以将其观测范围纳入 FP8 窗口后是适用的。

E5M2 格式（5 位指数，2 位尾数）提供更宽的动态范围，最大有限值约为 5.73 × 10⁴，但精度降低（仅 2 位尾数，即约 1/4 的相对精度）。这个更宽的范围在反向传播期间的梯度处理中非常重要，因为梯度可能跨越比前向传播激活值更多的数量级，尤其是在深层网络的早期和晚期层中。

Transformer Engine 会在这两种格式之间按层选择，而逐张量缩放因子会被维护在一个小的元数据缓冲区中，这会带来可忽略的内存开销。这些缩放因子会根据观测到的张量值分布每隔几次迭代更新一次，以确保 FP8 的有限精度集中在实际上出现在每个张量中的值范围上。

对舰队设计的实际影响是，峰值 TFLOP/s 规格是精度依赖的。H100 在 FP16 下提供 989 TFLOP/s，而在 FP8 下则达到其一倍（1,979 TFLOP/s）。设计用于 FP8 训练的舰队，相较于运行 FP16 的同等舰队，实际上拥有两倍的计算密度，且无需额外硬件。这使得精度工程成为基础设施规划者的一级优化杠杆，而不仅仅是模型精度的问题。

为了在实践中达到这一峰值吞吐量，整个加速器必须被视为一个刚性流水线：数据从 HBM 流出，经过逐层加深的缓存层次，最终到达 Tensor Cores。根本约束是 流水线平衡：数据进站到寄存器的速度必须匹配或超过算术单元消费数据的速度。当操作的算术强度低于拐点时，流水线会出现停顿，导致 teraflops 级的算力潜力在等待数据时闲置。这使得 内核融合 成为大规模训练中唯一最关键的软件优化。通过将多个操作（矩阵乘法、偏置加法、激活函数）融合为单个内核，系统可以消除如果每个操作顺序执行时会发生的往返 HBM 访问。以注意力机制为例：未融合的实现会将 S × S 注意力矩阵写入 HBM，仅为了在 softmax 操作时再读回，这一往返过程受限于 3.35 TB/s 的内存带宽。而像 FlashAttention 这样的融合实现则会将这些中间矩阵完全保留在片上 SRAM 中，绕过 HBM，使 Tensor Cores 能够接近其理论峰值运行。对于我们的 175B 模型，每个训练步骤涉及跨 96 层 Transformer 的数千次矩阵操作，融合内核与未融合内核之间的差异可能带来 2–3 倍的吞吐量提升——这正是两周训练运行与六周训练运行之间的区别。

峰值 vs. 持续吞吐量

对基础设施规划而言，一个关键的区别是峰值吞吐量（硬件在合成基准测试中能达到的最大值）与持续吞吐量（硬件在实际训练运行中实际交付的值）之间的差异。峰值 TFLOP/s 假设 Tensor Cores 在每个周期都能被数据喂满，这需要完美的调度、零内存停顿和零通信开销。然而，在实际的 Transformer 训练中，针对计算密集型操作的持续吞吐量通常仅为峰值的 30–50%，而对于内存受限操作，则可能低于峰值的 5%。峰值与持续吞吐量之间的差距源于多个来源，每个来源代表不同的物理或软件限制。

当 Tensor Cores 完成当前瓦片乘法，但下一个瓦片尚未从 HBM 加载完毕时，就会发生内存停顿。即使 H100 拥有 3.35 TB/s 的 HBM 带宽，Tensor Cores 仍可能以更快的速度消耗数据，而 HBM 跟不上，导致算术单元在等待数据时出现空闲周期。

流水线气泡产生于某个操作必须完成后，下一个操作才能开始，这会导致一些处理元素闲置。在 Transformer 层中，注意力计算必须在前馈网络开始前完成，而前馈网络必须在下一层的注意力开始前完成。这些顺序依赖会创建一些硬件资源未被使用的短暂时期。其局部机制很简单：一个气泡是依赖阶段之间的空闲槽位，而微批次通过将后续微批次喂入否则会等待的阶段来减少浪费。在基础设施层面，经验是：峰值吞吐量假设流水线被完美填满，而实际训练则包含依赖间隙，这些间隙会降低持续利用率。

来自 AllReduce 操作（用于张量并行）或梯度同步（用于数据并行）的通信开销会在数据在加速器之间交换期间完全暂停计算。即使通信与计算重叠（使用独立的通信和计算流），通常仍存在一些无法重叠的操作，因为它们依赖于通信的结果。

来自内核启动延迟、内存分配和 Python 级控制流的软件开销会额外增加 5–10% 的开销。每次 CUDA 内核启动在主机端大约会产生 5–10 微秒的延迟，而一个 Transformer 层可能涉及 20–30 次内核启动。对于微批次较小的情况，若每个内核在微秒级完成，则启动开销可能成为总执行时间的一个显著部分。

内核融合 通过将多个操作（矩阵乘法、偏置加法、激活函数、dropout）合并为单个 GPU 内核，部分弥合了这一差距，从而消除了否则会在操作之间导致 Tensor Cores 空闲的中间内存读写。实现高持续利用率的关键在于最小化 Tensor Cores 处于空闲状态的时间，这正是为什么像 FlashAttention 和 Transformer Engine 这样的专用内核库得以存在的原因。

对于容量规划，应使用持续吞吐率，而非峰值速率。按峰值 FLOP/s 估算为 1,000 GPU 小时的训练运行，在考虑实际利用率后，实际上需要 2,000–3,000 GPU 小时。经验丰富的基础设施团队将其 Model FLOPs Utilization (MFU) 作为基础设施效率的主要指标进行跟踪，MFU 定义为模型的有效 FLOP 计数与硬件峰值 FLOP/s 与墙钟时间的乘积之比。对于大规模 Transformer 训练，MFU 值在 40%–50% 被认为良好；高于 50% 的值表明软件优化极佳。第 9.9.1 节正式定义了 MFU 并开发了其舰队级应用。

功耗墙与热力学约束

内存墙限制了数据到达计算单元的速度；屋顶线模型诊断计算还是内存是约束瓶颈；而 Tensor Core 最大化了每个获取字节的算术价值。第三个物理约束也限制着加速器的性能：所有这些计算产生的热量。每次 FLOP 都会耗散能量，计算越快，必须移除的热量就越多。这就是功耗墙。图 2.10 追踪了能量从电网到晶体管的旅程。

图 2.10：电力传输路径：能量从高压电网到低压晶体管的旅程涉及多个转换阶段，每个阶段都有其自身的效率损失。累积的传输损耗，加上冷却开销（由 PUE 测量），决定了设施必须从电网汲取多少功率。关键的工程挑战在于机柜 PDU 到 VRM 的过渡，即 10–40 kW 的功率必须在单个机柜内输送。

图 2.10 所示的级联揭示了为何电力传输是一个基础设施问题，而不仅仅是电气问题：这些转换损耗，加上移除热量的开销，决定了设施的总功耗，而集中在机柜 PDU 到 VRM 过渡处的 10–40 kW 功率决定了整个设施的冷却架构。公式 2.2 通过单一的设施比率——电源使用效率（PUE）——捕捉了这种冷却开销：

$$ \\text{PUE} = \\frac{P\_{\\text{facility}}}{P\_{\\text{IT}}} \\qquad(2.2)$$

此处 P[facility] 是数据中心从电网汲取的总功率，P[IT] 是服务器、加速器、存储和网络设备消耗的功率。PUE 为 1.5 意味着设施每向 IT 设备输送 1 瓦功率，就必须从电网汲取 1.5 瓦功率；额外的 0.5 瓦用于冷却、电源转换、照明和其他开销。

每一次浮点运算都会以热量形式耗散能量。大规模矩阵乘法期间密集的 Tensor Core 活动驱动的热量与数十亿个晶体管的开关活动成正比。ML 加速器的 热设计功耗 (TDP)²¹ 是冷却系统必须处理的最大持续散热量，它已成为舰队设计中后果最重大的单一规格。在密集舰队规模下，这构成了功耗墙：即设施的电力输送和散热能力，而非可用的算术单元，决定了可安装和维持的计算量。

这是热力学极限（原则）在起作用：现代 AI 数据中心的瓶颈不是 FLOP/s，而是每平方英尺的瓦数。当单个机柜产生 100 kW 热量时，风冷失效。舰队的物理设计由将热量从硅片移走的能力决定。密切相关的功率密度墙（原则）使后果具体化：对于大规模训练集群，液冷成为设施要求，而非可选项。

热设计功耗 (TDP) 是 ML 加速器冷却系统为使处理器在其额定时钟频率下运行，必须持续移除的最大持续热负载（以瓦特为单位）——它既定义了冷却基础设施要求，也定义了加速器的性能上限。

重要性：H100 SXM5 在 700 W TDP 下运行。当液冷系统只能维持 500 W 的散热（冷却不足）时，GPU 固件会通过热节流降低时钟频率，导致 R[peak] 从 989 TFLOP/s 降至约 712 TFLOP/s FP16，训练吞吐量减少 28%，这直接导致墙钟训练时间变长和每模型成本增加。
区别：与峰值功耗（单指令爆发时的瞬时最大值）不同，TDP 指定的是稳态热预算：决定训练能否在额定性能下连续运行，还是必须降频的长期平均值。
常见误区：一个常见的误解是 TDP 是软件的功率限制。TDP 是一个冷却要求：只有当冷却系统移除热量的速度至少与芯片产生热量的速度一样快时，处理器才能超过其额定速度运行；冷却不足会导致硬件静默降频——不会报错，训练只是变慢，MFU 在没有明显原因的情况下下降。

TDP 的轨迹讲述了一个扩展机制触及极限的故事。三十年来，登纳德缩放²² 允许芯片设计师在保持功率密度近似恒定的情况下缩小晶体管：更小的晶体管需要更低的电压，因此在同一面积内封装更多晶体管不会增加单位面积的热量输出。随着电压缩放和漏电流限制终结了这一机制，架构师不得不将能量、冷却和并行视为一等约束，而非工艺缩放的免费副产品 (Dennard et al. 1974; Hennessy and Patterson 2019)。此后，每一代加速器都必须在性能与功耗、散热之间权衡。“免费”通过工艺缩放获得性能提升的时代已结束；吞吐量的每一点增益现在都必须以瓦特、冷却能力或专用化为代价。

数字令人震惊：V100（2017）在 300 W TDP 下运行，A100（2020）增加到 400 W，H100（2022）达到 700 W，B200（2024）高达 1000 W。在七年里，TDP 已翻了两番多，年均增长约 18%。

如果按规划场景假设此增长率持续，Blackwell 之后的一代将接近每加速器 1,200–1,400 W，再下一代可能达到 1,500–2,000 W。在每加速器 2,000 W 时，单个 8-GPU 节点仅 GPU 功耗就会消耗 16 kW，需要能以接近工业过程冷却设备速率移除热量的液冷²³ 基础设施。

三十年来，德纳德缩放定律让架构师得以在不增加功率密度的前提下增加晶体管数量，因为更小的晶体管需要成比例更低的电压。这顿“免费午餐”在 2006 年左右终结，当时工艺节点跌破 28nm，亚阈值漏电和栅极氧化层隧穿效应等量子效应阻止了电压的进一步降低。结果是，当电压不再成比例缩放时，功率密度随晶体管密度上升：吞吐更高 TFLOP/s 的加速器往往需要更多瓦特。从 V100 (12nm) 到 H100 (4nm) 的演进直观地诠释了这一物理规律：晶体管密度增加了两倍（注：原文为 tripled，即三倍），但无法缩放电压导致 TDP 从 300 W 激增至 700 W。硅基时代“免费”的能效红利已尽；更高的每瓦性能越来越多地来自架构专用化——张量核心、脉动阵列、精度工程——或接受更高的功耗与散热需求。对于 ML 基础设施规划者而言，电力与散热容量必须按算力需求进行规划，机房设计不能假设后续硬件会自动降低功率密度。

TDP 不仅仅是数据手册上的一个规格参数；它是一种贯穿基础设施栈每一层级的物理约束。供电链路、散热系统、机柜设计和机房电气基础设施，所有这些都必须设计为能容纳已部署的加速器，以及未来刷新周期中合理的 TDP 范围。

加速器实施精细的电源管理以在其 TDP 包络内运行。当负载未完全占用所有 SM（例如训练步骤的通信阶段，GPU 正在等待 AllReduce 完成）时，GPU 固件可通过 clock gating（时钟门控）切断空闲电路的时钟信号，消除动态开关功耗，为活跃 SM 释放热余量。另一套独立机制 dynamic voltage and frequency scaling (DVFS)（动态电压频率缩放）会调整芯片的时钟频率与供电电压，以维持在功率与热力极限内；在同时激活所有 SM 的大规模矩阵乘法期间，DVFS 会降低时钟频率以将总功率控制在 TDP 以内。当部分 SM 空闲时，活跃 SM 可提升频率，因为芯片总功率低于 TDP，因此实际时钟频率（进而实际吞吐）会在一个训练步骤内持续变化。

动态电源管理意味着 GPU 的实际功耗在训练过程中持续变化。一个典型的训练步骤，功耗可能在 400 W（通信阶段，大多数 SM 空闲）与 700 W（前向与反向传播，所有张量核心全速运行）之间来回摆动，每次转换仅耗时微秒级。底板上的 VRM（电压调节模块）必须足够快地响应这些转换，以在电流剧烈变化时维持稳定的供电电压。

要理解这一物理挑战，不妨从热通量角度审视 700 W 意味着什么。H100 芯片面积约 814 mm²（粗略 29 × 28 mm）。从该面积散发 700 W 热量，产生的热通量约为 86 W/cm²。作为对比，电炉灶高温档表面热通量约 10 W/cm²。H100 花生米大小的区域产生的热通量是电炉灶的 8.6 倍。

B200 更进一步：双芯片封装功耗 1000 W，平均热通量相当，但单封装须移除的总能量增加了 43%。在不让结温超过 83°C（HBM 可靠性的典型工作上限）的前提下移除这些热量，需要从芯片到冷却液具有极低热阻的热学方案。

该热路径的关键组件是 Thermal Interface Material (TIM)（热界面材料）——硅芯片与冷板（液冷）或散热器（风冷）之间那层微观的相变材料或液态金属。在深度学习负载的极端热循环下，芯片温度在矩阵乘法期间毫秒级从 40°C 飙升至 80°C，通信阶段再骤降，劣质 TIM 会泵出（从接触面迁移开）或开裂。TIM 导热率仅下降 5%，就会迫使 GPU 热节流，降频数百 MHz 以护佑硅片。这种退化属于灰色故障，即降级而非停机：GPU 仍能运行，但性能下降，无声地拖垮整个集群吞吐，这类故障我们将在舰队监控章节再探讨。舰队管理系统若持续追踪单 GPU 结温，可在恒定负载下检测到温度逐渐上升的趋势，从而提前更换，避免性能影响恶化。

放大到机柜层面，四节点 × 八芯片需 33.5 kW 机房相关功率，足以供数户家庭冬季取暖。更直观地说：满载的单 ML 机柜功率相当于约 33 台家用取暖器同时运行，却浓缩在大冰箱般的体积内。

扩展到 Pod 层面，功率需求达兆瓦级，需要专用变电站与工业级冷却厂房。万卡集群功耗 7–10 MW，相当于大型工厂或数千居民小镇的用电量。

万卡 Pod 在如此功率密度下的物理体积却惊人紧凑：计算硬件（不含网络与存储）约占 300 个机柜，机房占地约 1500 平方米（约美式足球场的三分之一）。高密度的意义在于：让加速器物理靠近，缩短线缆长度，降低信号传播延迟，从而实现更高互联带宽。

然而，物理高密度让供电与散热难度呈指数级上升，造就了层级体系中机柜与 Pod 两级的工程挑战。现代 ML 基础设施的悖论在于：计算效率要求物理邻近，而热管理要求物理分离。每个机柜设计都是在这两股对立力量间的妥协。

这种频率变化与软件优化产生微妙的相互作用。高 SM 占用率（每 SM 多活跃 warp）的内核消耗更多功率，可能触发降频，部分抵消占用率收益。反之，中等占用率的内核可能以更高频率运行，在更低功耗下获得相当吞吐。因此，功耗归一化吞吐（TFLOP/s per watt）比原始 TFLOP/s 更稳健，也解释了为何同一 GPU 在不同负载与散热方案下呈现不同的持续频率。

在舰队层面，DVFS 同样影响功率规划。数据中心供电必须按最坏情况功耗（所有 GPU 同时跑满 TDP）设计，但平均功耗通常仅为 TDP 的 70–85%，因为通信阶段 DVFS 降频，且非所有时刻所有 SM 都全满载。部分运营商主动给 GPU 设更低功耗上限（如将 H100 限制在 600 W 而非 700 W），接受 10–15% 峰值性能损失，换取 15% 更低功耗，从而在固定功率预算内部署更多 GPU。功耗上限设定是算力-能效权衡在运维层面的体现。

电源效率曲线为不断攀升的 TDP（热设计功耗）提供了部分制衡。尽管绝对功耗有所增加，但每瓦特所提供的标称低精度 TFLOP/s（万亿次浮点运算/秒）却有了显著提升：从 0.42 TFLOPs/s/W（V100 FP16）提升至 2.83 TFLOPs/s/W（H100 FP8），再到 4.50 TFLOPs/s/W（B200 FP8）。这些并非同类可比的 FP16 数据；精度模式本身就是硬件趋势的一部分。对于能够使用更新精度模式的固定算力预算而言，每一代产品所需的芯片数量更少，因此总功耗也更低。然而，大模型能力目标的增长速度可能快于效率的提升，因此训练下一代更大模型的绝对功率需求仍可能增加。这就是基础设施的“跑步机”效应：效率提升赢得了时间，但规模增长消耗了时间。

TDP 对舰队设计的影响深远，并将贯穿本章始终。在节点层面，TDP 决定了单个机箱可容纳多少加速器（我们将在第 2.4 节中探讨）。在机架层面，TDP 主导了从风冷向液冷的过渡（第 2.5 节）。在 Pod 层面，TDP 推动了将舰队接入电网的兆瓦级供电系统的发展（第 2.6 节）。加速器是引擎，而 TDP 是排气，芯片之上的每一级基础设施部分存在的目的，就是为了管理这些“排气”。

面向 ML 工作负载的加速器选择

加速器的计算吞吐率、内存带宽、内存容量和功耗，仅相对于特定工作负载才有意义。同一块 H100，在大批量训练时可能实现接近峰值的利用率，但在单请求推理时利用率可能不足 5%，因为约束瓶颈从算术运算转移到了内存带宽。因此，选择合适的加速器要求将每种工作负载原型映射到其在 Roofline（屋顶线）模型上的位置，并确定哪种物理资源主导其性能。

以 175B 模型为运行示例。训练期间，大批量将前向和后向传播推至 Roofline 峰点之上，因此直接约束是算术吞吐率。峰值低精度 TFLOP/s 很重要，但前提是内存容量足以容纳分片后的模型状态，且互联互通能保持张量并行和数据并行组的同步。H100、B200 和 TPU v5p Pod 都是解决该训练问题的合理答案；最终选择取决于软件栈，不亚于硅片本身。以 PyTorch 为主的研究团队看重 GPU 生态系统，而以 JAX/XLA 为中心的组织可能愿意为 TPU 的成本效率接受更严格的编译约束。

为同一语言模型提供服务则会改变答案。在自回归解码期间，每个生成的 Token 都会将权重从内存中流式传输，因此关键指标变成了每美元内存带宽，而非峰值 TFLOP/s。在批大小为 1 时，H100 的 3.35 TB/s 带宽决定了吞吐量，而大部分算术硅片处于等待状态。批处理通过跨更多请求复用相同的权重移动来提高算术强度，这正是服务系统竭力在不违反尾延迟 SLO（服务等级目标）的前提下进行批处理的原因。工作负载名称未变，但“铁律”中的约束项变了，加速器的选择也随之改变。

推荐模型再次分化了决策。嵌入表查找由随机访问和内存容量主导，因为每个请求都从 TB 级、局部性差的表中检索小向量。消费这些嵌入的稠密塔则是计算受限的。混合 CPU-GPU 设计由此而来：CPU 和 DRAM 容量处理稀疏查找路径，而 GPU 加速稠密神经网络层。单一的峰值 TFLOP/s 数字无法描述这种工作负载，因为在单个请求内部存在两个不同的瓶颈。

视觉和扩散工作负载则回归到算术吞吐率，因为卷积、注意力模块和去噪网络大量复用数据。扩散推理对此尤为明显：MLSysIM 中的 Stable Diffusion v1.5 配置文件使用 50 步去噪，因此服务需支付一系列完整模型评估的成本，而非每 Token 一步解码。对于这些工作负载，一旦模型状态放入内存，每美元 TFLOP/s 往往主导每美元带宽。

专家混合模型（MoE）增加了路由约束：稀疏门控层仅为每个 Token 激活更大参数集的一部分（Shazeer et al. 2017）。例如 Mixtral-8x7B（A. Q. Jiang et al. 2024）总参数量为 46.7B，但每个 Token 的激活参数仅 12.9B，因为路由器从 8 个专家中选择 2 个。这种计算节省引入了多对多 Token 交换模式，即第 6 章中探讨的 AllToAll 集合通信，并带来了负载均衡风险，因为 Token 必须路由到不同的专家放置位置。高分切带宽结构和负载均衡机制（如惩罚过载专家的辅助损失，或限制每个专家接收 Token 数量的容量因子）决定了理论节省是否体现在训练轨迹中（Fedus et al. 2022; Lepikhin et al. 2021）。

多模态模型增加的是异构性而非单纯的路由。它们结合文本解码、视觉处理、音频特征，有时还包括视频，每种模态具有不同的算术强度和批处理行为。这些工作负载倾向于具有灵活调度和强分切带宽的平台，而非针对单一规则数据流优化的加速器。

Roofline 模型的根本洞见在于：没有单一加速器对所有工作负载都最优。一块在 175B LLM 训练中提供卓越吞吐量的 H100，在批大小为 1 时服务同一模型可能大部分时间处于空闲。一个为 Transformer 训练提供极致成本效率的 TPU Pod，可能不适合具有不规则内存访问模式的推荐模型。

因此，成熟的舰队在设计上必然是异构的，因为每种工作负载都使不同的资源成为决定性因素。训练集群投资于算术吞吐率和快速加速器间链路，因为同步位于关键路径上。服务集群投资于每美元内存带宽和延迟控制，因为解码在尾延迟 SLO 约束下流式传输权重。嵌入系统投资于 DRAM 容量和局部性管理，因为稀疏查找主导请求。微调集群介于两者之间，平衡内存余量与足以保持快速迭代的算力。加速器谱系是一个设计空间，必须针对每种工作负载独立导航。为所有工作负载部署单一硬件配置的组织必然会过度付出：要么硬件为简单工作负载过度配置，要么为繁重工作负载配置不足。

精度与吞吐率的权衡

数值精度与硬件吞吐率之间的关系是基础设施规划中最重要的考量之一，因为它直接影响每个加速器每秒能完成多少有效工作。更低精度的表示每个数字使用的位数更少，这带来了两重复合收益：相同的 HBM 容量能容纳更多数字（降低内存压力），且算术单元每周期能处理更多运算（提高吞吐率）。

ML 领域的精度格局演变迅速。表 2.6 总结了 H100 级加速器上代表性的精度格式及其常见用例。

精度格式与 H100 上的硬件吞吐量

| 格式 | 位数 | 指数 | 尾数 | H100 密集 TFLOP/s | 典型用途 |

|---|---|---|---|---|---|

| FP32 | 32 | 8 | 23 | ~67 | 主权重、损失计算 |

| TF32 | 19 | 8 | 10 | 494 | 训练（NVIDIA 默认） |

| BF16 | 16 | 8 | 7 | 989 | 训练、微调 |

| FP16 | 16 | 5 | 10 | 989 | 通过损失缩放的训练 |

| FP8 (E4M3) | 8 | 4 | 3 | 1,979 | 前向传播、权重 |

| FP8 (E5M2) | 8 | 5 | 2 | 1,979 | 反向传播、梯度 |

| INT8 | 8 | N/A | N/A | 1,979 | 训练后量化 |

| INT4 | 4 | N/A | N/A | 3,958 | 仅权重量化 |

表 2.6：Precision Formats and Hardware Throughput on H100：该表使用在存在 Tensor Core 支持时的密集峰值吞吐量；结构化稀疏性大约可以将这些宣传峰值翻倍。精度的选择会影响训练动态（收敛性、数值稳定性）以及基础设施需求（内存容量、带宽利用率）。TF32 保留了 FP32 的指数宽度，但降低了尾数精度，使 Tensor Core 能够加速常见的 FP32 训练工作负载。

基础设施影响尤为显著。以 BF16 训练为基准的舰队（大型模型常用的基准）在 H100 上的每卡吞吐为 989 TFLOP/s。同样舰队运行 FP8 训练时每卡可达 1,979 TFLOP/s，计算密度几乎翻倍且无需额外硬件。对于一个 10,000 卡的集群，单节点（8 卡）约价 $350,000，BF16 与 FP8 训练的差异相当于再增加 10,000 卡，约 $4.38 亿的节点硬件成本。

然而，并非所有工作负载都能在不牺牲精度的前提下使用 FP8。E4M3 中仅 3 位尾数意味着必须谨慎缩放数值以避免溢出（超出可表示范围的值会饱和或变为非有限，取决于格式和实现）或下溢（小值被四舍五入为零）。Transformer Engine 的动态张量缩放解决了标准 Transformer 架构的此类问题，但具有异常激活分布的自定义模型可能需要手动精度调优。基础设施团队因此必须与模型团队紧密合作，确定在保持可接受精度的前提下的最低精度，因为此决定直接影响有效吞吐量，从而决定所需集群规模。

在推理方面，量化是对服务经济影响最大的优化之一，因为它直接改变了大模型所需的硬件拓扑。我们 175B 模型在 FP16 下需要 350 GB，光是加载参数就至少需要五块 80 GB H100 GPU。使用 INT8 时降至 175 GB，可在三块 GPU 上装载；使用 INT4 时进一步降至 87.5 GB，可在两块 GPU 上装载。对于受内存带宽限制的推理而言，读取 4 位权重而非 16 位权重等价于将权重加载带宽提升四倍，进而比例降低每 token 的延迟。生产团队若在 INT4 而非 FP16 上部署，可显著减少推理舰队的内存占用和带宽需求，前提是所选量化方法和工作负载的质量损失在可接受范围。

在训练中，许多工作负载采用混合精度训练，这种策略将存储精度与算术精度解耦。权重的“主副本”保持在 FP32 以确保数值稳定性，而计算密集的前向与反向过程则转换为 BF16 或 FP16，以充分利用 Tensor Core 的吞吐。梯度在 FP32 中累计，以防止下溢，随后优化器再更新主权重。H100 的 Transformer Engine 通过在每层动态选择 FP8 与 FP16，进一步扩展了这一范式，对能够容忍精度下降的层实现再次翻倍吞吐。若模型在较低精度下仍保持数值稳定，训练速度的累计提升可达到数倍。

数据移动的能耗

Roofline 模型和 token 延迟分析表明，数据移动限制了性能。数据移动同样主导了能耗，对舰队经济有直接影响。一个有用的归一化标准是 FP16 操作数：从 HBM 读取一个 16 位值大约耗费 4 pJ/bit，即约 64 pJ，而一次 FP16 乘加（MAC）耗费约 1 pJ。原始操作数的获取因而约为算术操作的 64 倍，随后通过 tiling 与复用将该移动成本在多个 MAC 上摊销。

数据移动在能耗上远超算术。

这一操作数层面的比例解释了为什么加速器架构师会投入大量硅面积用于数据复用。Tensor Core 的基于块的执行模型将小矩阵加载至本地寄存器，并对每个元素进行数百次复用（每次对应对方矩阵的一个元素），从而在数百次 1 pJ 计算中摊销 HBM 访问成本。若没有这种复用，能耗预算将被内存访问主导，芯片的大部分功耗会消耗在加热线路而非切换晶体管上。

在舰队规模上，数据移动的能耗决定了电费支出。对于一个 10,000 卡的集群，每卡功耗约 700 W，其中约 400–500 W 来自内存子系统（HBM 读写、片上网络传输、寄存器文件访问），仅 150–250 W 用于执行有用算术的 Tensor Core，剩余功耗用于时钟分配、I/O 与泄漏。通过内核融合、FlashAttention、激活检查点等技术提升数据复用，可降低因数据移动而浪费的能量，提高用于有效计算的功率比例。

能耗视角为理解不同并行策略效率差异提供了物理依据。Tensor 并行需要通过 NVLink 进行数据移动（链路层约 5 pJ/bit，加上 NVSwitch 芯片的能耗），数据并行则经由 InfiniBand（约 15–20 pJ/bit，包括 HCA 与交换机的能耗），管道并行移动的数据更少，但调度更复杂。每种并行策略都代表了通信能耗与计算效率之间不同的折中点。

现代计算的铁律是：移动数据的能耗远高于对其进行操作的能耗。我们可以通过分析 4 nm 工艺节点上单次操作的能耗层级来证明这一点。

执行一次 FP16 乘加（MAC）——深度学习的原子单元——约消耗 1 pJ，这是有用工作的基线成本。从 HBM 读取单个 FP16 操作数（16 位）大约需要 4 pJ/bit，总计 64 pJ。若从封装外的 DRAM 读取同一操作数，则约需 20 pJ/bit，合计 320 pJ。两者的差距惊人：从 HBM 读取的能耗是计算的 64 倍，标准 DRAM 则是 320 倍。

这种宏观影响在服务我们的 175B 模型时尤为突出。生成单个 token 需要从 HBM 加载整个 350 GB 权重张量：

Data Movement Energy = 350 GB × 8 bits/byte × 4 pJ/bit ≈ 11.2 Joules

对应约 1.75 × 10⁹ MAC（约 3.5 × 10¹¹ FLOP）的计算能耗则相形见绌：

Computation Energy = 175 × 10⁹ MACs × 1 pJ/MAC ≈ 0.175 Joules

将权重移动到计算单元

将权重移动到计算单元消耗的能量是这种简化解码模型中数学运算本身的 64 倍。这种能量惩罚就是为什么 HBM 被设计为物理上靠近 GPU die —— 更短的走线意味着更小的电容和更低的每比特能量。这也解释了为什么减少数据移动的技术（例如量化（移动更少的位）和内核融合（防止往返内存））是提高系统性能和能效的主要手段。

基准测试加速器性能

采购团队在比较加速器时，需要一个能预测组织实际将达到的性能的已发布数字。峰值 TFLOP/s、内存带宽和 TDP 描述的是潜在性能，而非实现性能，因此决策取决于信任谁的测量结果以及这些结果是在什么规则下产生的。行业标准参考是 MLPerf，由 MLCommons 维护：MLPerf Training 报告将参考模型训练至目标准确率所需的时间，MLPerf Inference 报告在现实的批处理和流式条件下的服务吞吐量和延迟。两者都捕获了完整的系统性能，包括软件栈效率、通信开销和内存管理，而不仅仅是原始硅性能。

真正能预测组织结果的数字是封闭组别的结果，理解原因是读懂 MLPerf 的核心。封闭组别要求每个提交使用相同的模型架构、超参数和训练配方，将硬件和系统软件隔离为唯一变量，使结果可以直接跨供应商比较。开放组别允许任意模型修改、自定义内核和软件优化，这展示了平台的上限，但使跨供应商比较不可靠。基础设施团队应更重视封闭组别结果，因为它们反映了使用标准框架和配置所能达到的性能，而非仅供应商自身优化团队所能达到的性能。

对于我们的 175B 模型，没有单一基准能捕捉全貌。训练阶段在大批量下受计算限制，使峰值 TFLOP/s 和扩展效率成为主导指标。推理阶段在批量大小为 1 时受内存带宽限制，使每美元 GB/s 成为相关指标。微调阶段介于两者之间，适中的批量大小使工作负载接近屋顶模型的屋脊点。全面评估必须在候选硬件上对这三个阶段进行基准测试，使用组织的实际模型和数据管道，而不应仅依赖已发布的 MLPerf 数字。

评估加速器选项时，以下指标比单独的峰值 TFLOP/s 能提供更完整的图景：

模型 FLOPs 利用率（MFU）：实际训练期间达到的 FLOP/s 与峰值硬件 FLOP/s 的比率。MFU 为 50% 意味着硬件有一半时间用于有用计算，另一半时间在等待数据、同步或空闲。
训练时间（TTT）：将参考模型训练至目标指标所需的墙钟时间。这捕获了 MFU 单独无法捕获的所有系统级效应，包括 I/O 停顿、检查点开销和作业重启延迟。
每 Token 成本：对于语言模型训练，总成本（硬件摊销加电力）除以处理的 Token 数量。该指标归一化了不同硬件代际、集群规模和定价模式。
每秒每美元 Token 数：每 Token 成本的倒数，便于比较不同系统的经济效率。

没有单一指标能讲完整个故事。MFU 高但每 GPU 小时成本高的系统，可能不如 MFU 较低但硬件更便宜的系统经济。正确的指标取决于组织是在优化时间（训练必须在截止日期前完成）、成本（最小化总支出）还是吞吐量（最大化单位时间内处理的 Token 数）。

推理专用基础设施考量

虽然本章主要关注训练基础设施（因为训练驱动最苛刻的基础设施需求），但大规模服务已训练模型的基础设施值得单独关注，因为设计约束与训练根本不同。训练基础设施针对吞吐量优化：最大化整个集群每单位时间处理的总 Token 数。工作负载是单个长时间运行的作业，占用整个集群数天或数周。通信模式可预测且重复。单个操作可接受的延迟为毫秒到秒级。

服务基础设施针对延迟和每查询成本优化：最小化每个用户等待响应的时间，同时保持每查询成本足够低以维持商业模式可行性。工作负载由数百万个独立、短生命周期的请求组成，以不规则间隔到达。通信模式极小（每个请求在单个节点或一小组节点上独立处理）。可接受的延迟为交互式应用的几十毫秒。

不同的需求驱动了不同的硬件和架构选择，总结见表 2.7。

| 维度 | 训练基础设施 | 服务基础设施 |

| --- | --- | --- |

| GPU 利用率 | 大批量将工作负载推入计算受限区，集群通常达到 30–50% MFU。 | 低批量服务深度受内存限制，MFU 可能低于 5%，批处理可提高利用率但以延迟为代价。 |

| 模型放置 | 张量并行和流水线并行将单个模型分布在许多 GPU 上。 | 模型副本或大分片处理独立请请求，因此内存需求随并发服务容量扩展。 |

| 网络流量 | 梯度同步需要高带宽、低延迟的 GPU 间通信。 | 独立请求几乎不需要 GPU 间流量，但需要大量面向客户端的带宽以支持每秒数百万 API 请求。 |

| 成本指标 | 训练成本是固定的一次性支出，按每次运行美元计算。 | 服务成本是可变支出，按每生成 1000 个 Token 的美元计算，热门模型可能在几周内超过其训练成本。 |

表 2.7：训练与服务基础设施对比：训练和服务优化不同的硬件行为，因此容量规划必须在车队实际运行的模式下比较利用率、模型放置、网络流量和成本。

该表显示了为什么服务不能规划为使用较小批量的训练：优化目标从同步吞吐量变为延迟受限、持续计费的请求。

这意味着有效的服务基础设施通常使用与训练基础设施不同的硬件、软件和设施设计。一些组织使用上一代 GPU（A100s）进行服务，因为每美元内存带宽可能与新型 GPU 具有竞争力，且较低的 TDP（400 W 对比 700 W）允许更高的机架密度和更低的冷却成本。

推理负载本身可分为两个具有截然相反瓶颈的不同阶段。Prefill（预填充）阶段处理输入提示词，执行大规模矩阵-矩阵乘法，该阶段受限于算力并能实现高 Tensor Core 利用率。Decode（解码）阶段逐个生成 Token，执行矩阵-向量乘法，该阶段深度受限于内存带宽。为最大化硬件利用率，高性能推理系统采用连续批处理，在迭代层面而非请求层面调度请求。这使得引擎能将等待请求的预填充计算注入到正在进行的解码批次的空闲算力槽位中，动态填满 GPU 的算术流水线。以我们的 175B 模型为例，要在 50 ms 首 Token 延迟服务等级协议（SLA）下每秒服务 10,000 个请求，需要将流量分发到数百个 8-GPU 副本（每个副本通过张量并行持有完整模型）上，并由负载均衡器将请求路由至队列深度最低的副本。与训练不同——训练中配合检查点机制，99.9% 的可靠性通常可接受——推理架构必须考量尾延迟，因为单个缓慢的副本就可能导致整个请求批次违反 SLA。

加速器决策矩阵

一个实用的决策框架通过将各原型（第 1.6.1 节）映射到主导其性能和成本的硬件资源，综合了这些特定于负载的特征。表 2.8 明确了选择规则：针对约束瓶颈进行选择，而非最大的宣称峰值数值。

| --- | --- | --- | --- |

表 2.8：加速器决策矩阵：最优加速器取决于哪种物理资源——算力、带宽或容量——是目标负载的约束瓶颈，而非峰值规格。屋顶模型提供了诊断依据：计算算力强度，定位负载相对屋脊点的位置，并选择能最大化每美元约束资源的硬件。

正如表 2.8 针对 175B 运行示例所示，约束瓶颈随生命周期阶段而变化。训练期间，大批次将负载推入算力受限区间，使峰值 TFLOP/s 成为主导指标。凭借高 Tensor Core 吞吐量和用于张量并行的高速 NVLink，H100 或 B200 是自然之选。在小批次推理期间，同一模型变为深度内存受限，相关指标转向每美元带宽。具有足够 HBM 带宽且价格较低的 A100，其每 Token 成本可能优于 H100——后者额外的 TFLOP/s 闲置未用。

组织维度增加了进一步考量。每周修改模型架构的研究实验室需要 GPU CUDA 生态系统的灵活性，可在数小时内编写和测试自定义内核。运行固定 Transformer 架构数月的大规模生产团队可能受益于 TPU，其 XLA 编译器的全程序优化能为标准操作实现比手工调优 CUDA 内核更高的持续利用率。只有当组织具备足够规模来分摊 5,000 万至 2 亿美元的 NRE（非经常性工程）成本，且负载稳定性足以证明 2-3 年的设计周期合理时，定制 ASIC 才在经济上讲得通。加速器谱系最终是在负载物理特性、组织规模和时间跨度的交汇点上得到解答的经济问题。

您的团队需要部署一个 70B 参数模型用于训练和推理。训练将在 256 张 GPU 上使用批次大小 2048 持续 3 个月。推理将在批次大小 1 下每秒服务 10,000 个请求，持续 2 年。

随着加速器物理特性的确定，我们面临一个具体问题。仅模型权重，我们的 175B 模型在 FP16 下就需要 350 GB 内存，而采用 Adam 风格的训练状态一旦包含优化器动量、梯度和激活值，需求就会上升到数 TB。单张 H100 提供 80 GB HBM。没有任何单个加速器能容纳此模型。我们必须扩展到下一个物理层级：节点，图 2.11 对比了在单个机箱内连接多个加速器的两种主流方法。

节点

节点是加速器选择成为互联互通问题的第一个规模层级。多张 GPU 现可共享一个机箱，但它们的有效行为取决于本地结构表现为缓慢的环形、密集的网状，还是交换机支持的交叉开关。

图 2.11：节点内 GPU 拓扑对比：节点内连接 GPU 的三种方法。（左）环形：顺序传递，单链路约 50 GB/s，延迟随距离缩放。（中）全网状：全互联直连，每 GPU 需 N − 1 条链路，超约 8 GPU 即不切实际。（右）NVSwitch 交叉开关：非阻塞结构，单 NVLink 112 GB/s，聚合 900 GB/s，任意 GPU 间单跳直达，支持节点内张量并行 AllReduce。

聚合加速器只有在它们之间的互联足够快、使得整组表现得如同一台机器而非多台传递消息的机器时，才能解决容量问题。175B 模型的权重至少跨越五个加速器，完整训练状态横跨整个 8-H100 节点乃至更多，因此单层的参数现分布在不同芯片上，且必须在每次前向和反向传播中重新组装。这种重组是廉价还是毁灭性的，完全取决于本地结构，这也是节点成为加速器规格不如加速器间连线重要的第一个规模层级。训练系统必须将张量并行与优化器分片及内存卸载相结合，而这些策略中的每一种都对互联提出了不同要求。

节点是 ML 训练集群的物理服务器机箱，通过高速节点内互联（NVLink 或 ICI）聚合多个加速器（通常为 8 个），构建起高带宽本地通信与数量级更慢的节点间网络结构之间的根本边界。

意义

DGX H100 节点内 NVLink 带宽达 900 GB/s 双向，即单向 450 GB/s，而节点间 InfiniBand NDR 提供 50 GB/s，单向存在 9 倍差距，这限制了各并行策略的运行位置。张量并行需对每层输出执行 AllReduce，必须留在节点内；流水线并行仅传输阶段边界激活值，可跨节点经 InfiniBand 进行。节点也是主要故障域：在批量同步并行（BSP）训练作业中——工作进程在步骤屏障处同步推进——单个节点故障会导致整个集群空闲直到恢复。

区别：与单个加速器（提供快速的 HBM 带宽但容量有限）不同，一个节点可以聚合 8 倍于单个芯片的 HBM 容量和 8 倍的计算能力——足以容纳大型 FP16 权重碎片（在 DGX H100 上为 8 × 80 GB = 640 GB），但不足以在 HBM 中保存完整的 Adam 训练状态。
常见陷阱：一个常见的误解是分布式训练作业中的节点独立运行。在 BSP 训练中，所有节点在每个步骤的屏障处同步耦合：一个节点的性能下降（由热限制、故障 NIC 或慢速存储读取引起）会导致整个集群停滞，并在该步骤期间降低整体 MFU。

节点的存在源于内存层次结构中的空白。HBM 提供足够的 bandwidth 来喂养加速器的算术单元，但不足以容纳完整的 175B-parameter 运行示例。主机 DRAM 提供容量（每台服务器 512 GB 至 2 TB），但带宽不足。

节点通过将多个加速器的 HBM 聚合为一个共享池来弥合这一差距，这些加速器通过足够快的互连相连，以允许跨所有加速器的协作计算。关键的工程洞察在于：通过将 8 个加速器置于单一机箱中，并用高速结构将它们连接起来，节点创建了一个虚拟加速器，其内存容量和计算吞吐量分别是单个芯片的 8 倍，而快速互连确保了该虚拟加速器几乎可以像单个整体设备一样高效运行。

多加速器节点的经济论证同样令人信服。考虑替代方案：构建一个能够容纳 175B 模型（FP16 下为 350 GB）的单个加速器。目前的封装每个 HBM 堆栈大约提供 16–24 GB，因此 350 GB 的单加速器设计将需要大约 15–22 个 HBM 堆栈——远超 H100 的 5 栈或 B200 级别的 8 栈封装。这样的封装制造成本将是禁止性的（随着封装和互 poser 面积增大，良率下降），而为一个能够使用全部带宽的 Tensor Cores 数量的单个芯片供电将超过任何实际的冷却方案。通过在 NVLink 上连接的 8 个加速器分布式计算，节点实现了假设超级芯片的总内存容量和计算吞吐量，同时仍保持在可制造和可冷却的范围内。

理解节点如何在其组件之间划分内存对于选择并行策略至关重要。考虑我们训练 175B 模型的内存预算。FP16 精度下的模型权重需要 350 GB。Adam 优化器以 FP32 精度维护每个参数的两个副本（一阶和二阶矩），增加 175 ×10⁹ × 2 × 4 字节 = 1,400 GB。梯度需要另外 350 GB。在考虑激活之前，总计约为 2.1 TB，远远超过单个加速器的 80 GB HBM 和 8-H100 节点的 640 GB 聚合 HBM。

使用 ZeRO 或 FSDP 风格的优化（在数据并行工作器之间分片优化器状态、梯度和可选参数）时，训练系统会避免在每个 GPU 上复制完整的 2.1 TB 状态。张量并行首先减少每个 GPU 的活动权重碎片；数据并行分片然后在许多工作器之间分散优化器状态和梯度；激活检查点降低激活峰值；卸载则通过 PCIe 将冷态优化器状态转移到主机 DRAM。因此，节点是一个高带宽计算和通信单元，而不是整个训练状态的独立容器。

节点的内部内存层次结构，由 HBM（快速、小容量）、主机 DRAM（中等速度、较大容量）和非易失性内存快速存储（NVMe）（慢速、非常大容量）组成，形成了一个分层系统，分布式训练框架会积极利用这一点。Chapter 5 将详细检查这些内存优化策略。

带宽层次结构

多加速器系统的定义特征不是 chip 数量，而是它们能够交换数据的 速度。数据移动速度在跨越物理边界时会降低几个数量级。每个边界代表不同的物理介质、不同的连接器技术和不同的工程约束。从片上 SRAM（快端）到广域网（慢端）的数据传输速率的物理排序即为 bandwidth hierarchy，理解这一点至关重要，因为它决定了每种并行类型可以在哪个层级上高效运行。

该层次结构反映了距离的物理成本：在更密集布线上的更短信号路径在每比特能耗较低时实现更高吞吐量，因此在每个边界处，有效带宽（BW）大约降低一个数量级，而延迟（L[lat]）大约增加一个数量级。这一梯度为分布式训练设定了扩展上限。常见的错误是将所有集群通信视为等同，但并行放置必须具有层次感知：将诸如张量并行这样的高频同步放置在慢速层级上会使计算单元（R[peak]) 空闲，并导致扩展效率（η[scaling]) 崩溃。

带宽层次结构最好理解为围绕每个加速器的一系列同心区域。最内层区域是同一封装上的 HBM，具有每秒太字节级的带宽和亚微秒级延迟。次内层区域包括同一节点内的其他加速器，可通过 NVLink 实现每秒数百 GB 的带宽和微秒级延迟。最外层区域涵盖集群中的所有其他节点，通过 InfiniBand 连接，带宽为每秒数十 GB，延迟以个位数微秒计。在每个区域边界处，带宽大约降低一个数量级，而延迟大约增加一个数量级。Table 2.9 将这些区域映射到它们支持的并行策略。

| 域 | 互连 | 带宽 | 延迟 | 扩展限制 |

| --- | --- | --- | --- | --- |

| 内部封装 | 硅互 poser | ~3.3 TB/s | <100 ns | 单芯片 |

| 内部节点 | NVLink/ICI | ~900 GB/s | ~1 μs | 节点（8–16 片） |

| 跨节点 | InfiniBand NDR | ~50 GB/s | ~5–10 μs | 播（数千） |

表 2.9：带宽层次结构：每个物理边界都会引入一个数量级的带宽断崖。这些断崖不是需要被优化掉的工程失败；它们反映了每种互连介质在物理上的根本差异。这些断崖决定了模型划分：需要在每层后执行 AllReduce 的张量并行严格局限于内部节点域。

Figure 2.12 中的同心视图以空间方式呈现了相同的层次结构，因此每次向外的边界穿越既表现为带宽下降，也表现为延迟增加。

图 2.12：基础设施带宽层次结构：同心区域可视化机器学习工作负载所跨越的带宽层级。HBM（3.35 TB/s）位于最内层区域；每次向外的边界穿越会使带宽下降约 10 倍，延迟增加约 10 倍：NVLink/NVSwitch（900 GB/s）、InfiniBand NDR（50 GB/s）以及存储/网络文件系统（7 GB/s）位于最外层区域。通过分层算法利用这一层次结构是分布式系统工程的主要任务。

正如 Table 2.9 所示，并行策略必须尊重这些边界。一个简单的同步计算使带宽间隔具体化。

问题：一个 10 GB 的缓冲区在整个机群中进行同步。机群的物理“层”如何影响传输时间？

Math: Transfer time is T[transfer] = D[vol]/BW.

HBM (intra-chip): 10 GB / 3,350 GB/s ≈ 3.0 ms.
NVLink (intra-node): 10 GB / 450 GB/s ≈ 22.2 ms.
InfiniBand (inter-node): 10 GB / 50 GB/s ≈ 200 ms.

Systems insight: Moving data across the cluster is 9× slower than moving it within a node. This “Bandwidth Staircase” is the primary driver of all parallelization strategies: we use tensor parallelism where bandwidth is abundant (NVLink) and data parallelism where it is scarce (InfiniBand). A model that “fits” in memory but ignores the staircase will spend 90 percent of its time waiting for the network.

Each cliff in the bandwidth staircase exists for a different physical reason, rooted in the signal-propagation regime at its distance scale. The intra-package interconnect achieves terabytes per second because signals travel through lithographically patterned copper traces on a silicon interposer, with path lengths measured in millimeters. At these distances, signal attenuation is negligible, no amplification is needed, and the signaling rate is limited only by the trace geometry and the transceiver design.

NVLink achieves hundreds of gigabytes per second using high-speed SerDes²⁴ transceivers over short copper cables or traces within a chassis, with path lengths of tens of centimeters. At these distances, signal attenuation is measurable but manageable with simple equalization circuits. The SerDes transceivers use PAM-4 (4-level pulse amplitude modulation) signaling at 112 Gb/s per lane, packing 2 bits per symbol to double the data rate relative to NRZ (nonreturn-to-zero) signaling.

PCIe uses a standardized protocol with flow control overhead, reducing effective bandwidth. While PCIe Gen5 uses the same 32 GT/s signaling rate as NVLink’s individual lanes, the protocol overhead (packet headers, flow control credits, error checking) consumes approximately 20 percent of the raw bandwidth. The standardization that makes PCIe universally compatible also makes it less efficient than proprietary interconnects.

InfiniBand crosses meters of cable between racks, requiring signal amplification, error correction, and switch hops that add both latency and protocol overhead. Active optical cables (AOCs) convert electrical signals to light at the transmitter, propagate through optical fiber, and convert back to electrical signals at the receiver. Each electro-optical conversion adds approximately 2–5 nanoseconds of latency and consumes power for the laser driver and photodetector. Switch hops add another 100–300 nanoseconds each for packet routing and buffering.

As Table 2.9 illustrates, the practical consequence is that parallelism strategies must respect these boundaries. Tensor parallelism (TP), which splits individual matrix multiplications across accelerators and requires an AllReduce operation after every layer, generates communication volume proportional to the model’s hidden dimension hundreds of times per second. At NVLink bandwidth, this synchronization takes roughly 1 ms per layer. At InfiniBand bandwidth, the same synchronization takes 10–20 ms, which would leave the accelerators idle for the majority of each training step.

TP is therefore confined to within a single node, while data parallelism (which synchronizes gradients only once per training step) spans the inter-node network. The bandwidth hierarchy is the physical law that determines the topology of distributed training.

The hierarchy also explains why pipeline parallelism occupies an intermediate position in the bandwidth requirements. In pipeline parallelism, the model is divided into sequential stages, with each stage assigned to a different group of accelerators. The communication between stages consists of activations flowing forward during the forward pass and gradients flowing backward during the backward pass, with a volume proportional to the batch size times the hidden dimension.

For our 175B model with hidden dimension 12,288 and a microbatch of 4 sequences at 2,048, the activation tensor at each stage boundary is approximately 4 × 2, 048 × 12, 288 × 2B bytes (FP16) ≈ 201 MB. This is far smaller than the 350 GB gradient AllReduce required by data parallelism, which is why pipeline parallelism places less demanding requirements on the inter-node network.

Activation transfers occur once per microbatch per stage boundary, far less frequently than tensor parallelism’s per-layer AllReduce. Pipeline parallelism can therefore tolerate the lower bandwidth of inter-node links, making it the preferred strategy for spanning multiple nodes when the model’s depth exceeds a single node’s capacity.

The result is a natural mapping between parallelism types and interconnect domains: tensor parallelism within the node (NVLink), pipeline parallelism across nearby nodes (InfiniBand), and data parallelism across the full cluster (InfiniBand with gradient compression). This mapping is so fundamental that it has become a de facto standard in production-scale Transformer training systems, with the details differing primarily in the number of pipeline stages, the degree of tensor parallelism, and the degree of data parallelism.

The mapping also determines how the job scheduler assigns nodes to training jobs. Nodes within the same tensor-parallel group should be physically adjacent (ideally in the same chassis, connected via NVLink). Nodes within the same pipeline-parallel group should be in the same rack or adjacent racks (minimizing InfiniBand switch hops). Data-parallel groups can span the entire cluster because their communication (gradient AllReduce) is the least bandwidth-intensive and most latency-tolerant of the three parallelism types. One intra-node boundary remains before that mapping reaches the scheduler: the PCIe hierarchy that connects accelerators to host CPUs, NICs, storage, and DRAM.

The PCIe hierarchy within a node

While NVLink provides a high-bandwidth freeway for GPU-to-GPU communication, PCIe Gen5 serves as the universal glue connecting the heterogeneous components of the node. It links GPUs to the host CPU, GPUs to InfiniBand Host Channel Adapters (HCAs), the host CPU to NVMe storage, and the host CPU to system DRAM. Understanding this topology is critical because PCIe bandwidth – though substantial at ~64 GB/s per direction (128 GB/s bidirectional) per x16 link – is often the bottleneck for operations that cross the accelerator boundary, such as data loading, checkpointing, and inter-node gradient synchronization.

A standard DGX H100 node features two host CPUs, each managing a PCIe root complex with 128 lanes. These lanes are distributed to maximize simultaneous throughput: 8 GPUs each receive a dedicated x16 link, and 8 InfiniBand HCAs each receive their own x16 link. This configuration provides an aggregate theoretical bandwidth of nearly 2 TB/s within the chassis. However, this bandwidth is shared among competing traffic streams. During a single training step, the PCIe bus simultaneously carries host-to-GPU data batches, GPU-to-HCA gradient shards for inter-node AllReduce (via GPUDirect RDMA), and periodic CPU-to-NVMe checkpoint writes. Contention between these streams can cause unexpected pipeline stalls, particularly when gradient synchronization saturates the links typically used for data loading.

双 CPU 架构引入了显著的非一致内存访问（NUMA）效应。8 张 GPU 被物理分区，其中 4 张连接到 CPU 0 的根复合体，另外 4 张连接到 CPU 1 的。连接到 CPU 0 的 GPU 可以以满 PCIe 带宽访问 CPU 0 的 DRAM，但要访问 CPU 1 的 DRAM，则必须穿越处理器间互连（UPI 或 Infinity Fabric）。这种穿越会带来额外的延迟，并将有效带宽降低多达 50%。健壮的数据加载流水线必须采用NUMA 感知调度，将数据加载器的工作进程绑定到物理上离目标 GPU 最近的 CPU 核心上。实测基准表明，将数据加载器与正确的 NUMA 域对齐，可使数据摄入吞吐量提升 20–30%，从而在高吞吐量训练运行中防止 CPU 成为瓶颈。

实际后果在于，放置策略也是并行策略的一部分：一个忽略 PCIe 根复合体、NIC 局部性和 NUMA 域的调度器，可能会将一个原本合理的张量并行或流水线并行计划，变成一个受制于主机的瓶颈。第 5 章将形式化地阐述这些节点内和节点间的边界如何与数据、张量和流水线并行相互作用。

稠密节点设计

鉴于带宽层级，节点内的工程挑战很明确：用足够的带宽连接 8 个加速器，使其能作为单一逻辑设备运行张量并行操作。解决方案是一种专用交换结构，它在所有加速器对之间提供全截面带宽。理解这种结构的设计，需要认识到为什么更简单的替代方案会失败。

最简单的方法是将 8 张 GPU 连成一个环，每张 GPU 只与其两个邻居相连。环形拓扑成本低廉（N 张 GPU 仅需 N 条链路），且非常适合环形 AllReduce，数据在环中按循环模式顺序流动。环形 AllReduce 算法能为梯度同步实现最优带宽利用率，因为每张 GPU 同时向右邻居发送数据、从左邻居接收数据，在整个操作过程中让所有链路保持忙碌。

然而，张量并行要求全互连通信：每层之后，每张 GPU 都必须与其他所有 GPU 交换部分结果。这与环形 AllReduce 的顺序流动模式截然不同，环形拓扑对此处理得很差。在一个 8 张 GPU 的环中，对侧通信需要 4 跳，与直接链路相比，有效带宽降低 4 倍。全互连网格（每张 GPU 与其他所有 GPU 都有直接链路）消除了这个问题，但 8 张 GPU 需要 N(N−1)/2=28 条链路，链路数随规模二次方增长，布线挑战很快变得不切实际。NVSwitch 交叉开关两全其美：用可管理数量的交换芯片提供了全截面带宽。

以 NVIDIA DGX H100 架构为例。八张 H100 GPU 位于同一基板上，每张通过 18 条 NVLink 4.0 通道连接到 4 颗 NVSwitch 芯片。NVSwitch 芯片构成一个非阻塞交叉开关²⁵：任意两张 GPU 之间可同时以全双向 900 GB/s 带宽通信，无竞争。这相当于给每对 GPU 都配了一条私有高速公路，而不是强迫它们共用一条单行道。

结果是，DGX H100 内的 8 张 GPU 可被视为单一逻辑设备，拥有 640 GB 聚合 HBM 显存和 8 × 1979 TFLOP/s 的合算算力。这种抽象对软件至关重要：训练框架可像在单个更大的处理器上一样，用张量并行将模型切分到 8 张 GPU 上，而 NVSwitch 结构使这种切分在性能视角下近乎透明。

DGX H100 基板的物理布局反映了这一设计目标。8 张 GPU 排布在基板上，4 颗 NVSwitch 芯片位于中央。每张 GPU 通过 NVLink 通道连接所有 4 颗 NVSwitch 芯片，每颗 NVSwitch 芯片有 64 个 NVLink 端口，交叉互联所有 GPU。

NVSwitch 芯片本身每颗约消耗 200 W（NVSwitch 结构总计 800 W），这是一笔不小的功耗开销，但由其提供的全截面带宽所证明是合理的。为作对比，仅 NVSwitch 结构的功耗就超过一整张上一代 GPU（V100 功耗 300 W）。若无 NVSwitch，要实现全互连需 28 条直连 GPU 链路，既是布线噩梦，也会消耗更多 NVLink 通道总容量。

张量并行前向传播期间，每张 GPU 持有一份权重矩阵的一个分片，并计算其负责的矩阵乘法部分。对于隐藏维度为 12,288 的 Transformer 层（175B 模型典型值），8 张 GPU 每张持有一个 12,288 × 1,536 的权重矩阵切片。每张 GPU 计算出部分结果后，通过 NVLink 在所有 8 张 GPU 间执行 AllReduce 操作求和。

单层输出的 AllReduce 涉及在 NVLink 结构上交换约 4 × 2,048 × 12,288 × 2 字节（FP16）。以典型微批次大小 4 个序列、每序列 2,048 token 为例，单次 AllReduce 约 201 MB，在 900 GB/s 下约 0.2 ms 完成。

即使有 96 层前向传播和 96 层反向传播，累计 AllReduce 时间也仅约 42.9 ms/训练步。这之所以可能，是因为 NVSwitch 交叉开关允许所有 8 张 GPU 同时无竞争通信，而环形拓扑则需数据按顺序多跳传输。

相较于每层约 2–5 ms 的计算时间（取决于序列长度和批次大小），通信开销很小。节点内张量并行扩展效率通常为 85–95%，即 8 张 GPU 实现单张 GPU 吞吐量的 6.8–7.6 倍。

剩余 5–15%的效率损失来自两方面。一是 AllReduce 通信本身，即便在 NVLink 带宽下，也占用了每层执行时间的一小部分。二是 Transformer 中的某些操作（LayerNorm、Dropout、激活函数）未做张量并行，因为其计算量相对矩阵乘法很小。这些顺序操作必须在每张 GPU 上完成，下一层的张量并行计算才能开始，引入了虽小但会累积的空闲时间。

lego-ok-block: PCIe 与 NVLink 张量并行诊断叙事

**场景**：早期多 GPU 节点用户常尝试在 PCIe 上跑张量并行，期望 64 GB/s 带宽足矣。

**诊断**：张量并行要求*每个*Transformer 层后都做 AllReduce，而非每训练步*仅一次*。96 层模型每前向传播产生 96 次 AllReduce，反向传播再来 96 次，每步共 192 次同步事件。在 PCIe 带宽下，针对 12,288 维隐藏状态的单次 AllReduce 约耗时 3.1 ms，每步累计纯通信开销达 604 ms。以 200 ms 计算步为基准，加速器约有 75.1%的时间在等 PCIe 传输。改用 NVLink 后，单次 AllReduce 降至 0.2 ms，总通信开销降为 42.9 ms，加速器利用率恢复至 82.3%以上。

**系统教训**：对张量并行而言，互连是瓶颈，PCIe 与 NVLink 的差距非渐进式；它是功能系统与非功能系统的分水岭。
end lego-ok-block

除了 NVLink，该节点还通过 InfiniBand 主机通道适配器（HCAs）连接到外部网络，并通过 PCIe 连接到主机存储。DGX H100 包含八个 InfiniBand ConnectX-7 HCAs，每个 GPU 对应一个 HCA，从而实现 GPUDirect RDMA：网络适配器可以直接读取和写入 GPU HBM，无需通过主机 DRAM 暂存数据或让主机 CPU 参与数据路径。

GPUDirect RDMA 对于节点间梯度同步至关重要，其中每个 GPU 的梯度碎片必须发送到其他节点上的对端 GPU。如果没有 GPUDirect，每次梯度传输都需要额外的两次拷贝：首先从 GPU HBM 到主机 DRAM（通过 PCIe），然后从主机 DRAM 到网络适配器（通过另一条 PCIe 路径）。这种双拷贝会增加延迟（两次 PCIe 遍历，而不是一次直接的 DMA 操作），并将有效带宽减半（每个字节需要两次遍历 PCIe 总线）。

GPUDirect RDMA 通过允许 InfiniBand HCA 直接从 GPU HBM 读取数据来消除这两次拷贝，完全绕过主机 CPU 和主机 DRAM。数据路径从 GPU HBM 出发，经 NVLink-to-PCIe 桥接后到达 InfiniBand HCA，实现单次传输。这种单跳数据路径是现代训练集群实现接近 InfiniBand 原始线速的节点间通信带宽的原因之一。

主机 CPU 负责作业调度、数据预处理、从存储加载数据以及网络协议处理，但它位于 GPU-到-GPU 计算的临界路径之外。这种分离是故意的：主机处理“慢速”操作（磁盘 I/O、网络管理、作业协调），而 GPU-NVSwitch 结构处理“快速”操作（矩阵运算、梯度同步）。

主机 CPU 的角色类似于传统计算机中操作系统内核的角色：它管理资源、处理异常、协调 I/O，但不执行应用程序的核心计算。在经过良好优化的训练循环中，主机 CPU 几乎从不位于临界路径上，其性能规格（核心数、时钟速度）不如其 I/O 能力重要（PCIe 通道数、内存通道、NVMe 控制器带宽）。

主机 CPU 还运行训练框架的 Python 运行时，该运行时负责编排内核启动、管理计算图以及协调集体通信操作。在经过良好优化的训练循环中，主机 CPU 正在为下一个批次进行数据加载和预处理的流水线操作，而 GPU 正在执行当前批次的前向和后向传播，使所有组件同时保持忙碌状态。

随着主机 CPU 的“数据中心税”增加——多达 30% 的 CPU 周期被网络协议处理、存储虚拟化和安全功能消耗——ML 节点可以采用数据处理单元（DPU）或智能网卡（SmartNICs）。例如，NVIDIA BlueField DPU 将这些基础设施任务卸载到集成在网络适配器自身中的专用 ARM 核心和硬件加速器上。通过将 RDMA 的控制平面、防火墙规则和存储协议转移到 DPU，主机 CPU 可以恢复周期用于机器学习流水线：数据加载、标记化和内核编排。DPU 还充当隔离的安全域，使云服务提供商能够通过 DPU 维持对网络和存储层的控制，同时向客户授予对主机 CPU 和 GPU 的完全访问权限。对于我们的 175B 模型训练，DPU 卸载可以使 RDMA 协议处理位于主机 CPU 临界路径之外，梯度同步从 GPU HBM 流向网络结构，且整个过程中不涉及主机 CPU。

替代节点架构

这些替代方案是加速器系统设计，而非可互换的产品名称。AMD MI300X 是一种 GPU 类加速器，其封装强调非常大的 HBM 容量，而 Intel/Habana Gaudi 设计则强调以太网/RDMA 作为一级通信路径。将它们与 DGX H100 节点进行比较，可以看出每种架构在何处分配其有限的预算。

DGX H100 通过使本地加速器交换变得廉价来解决通用节点设计问题。富交换设计会在通用任何对任何交换上花费功率、板卡面积和成本。当张量并行是临界路径时，这种选择很容易得到证明，因为每个 Transformer 层都会将本地加速器通信变为模型内部循环的一部分。因此，900 GB/s 的 H100 NVLink 结构购买了一种软件抽象：训练框架可以将八个加速器视为一个紧耦合设备，用于必须跨芯片分割的层。

其他系统会移动这一边界。TPU pod 使用片间互连（ICI）和面向网格的拓扑，而不是将中心交换机作为节点的定义组件；MLSysIM 中的 TPU v5p 配置文件将 ICI 建模为 1,200 GB/s。网格可以降低交换机成本并向编译器暴露常规结构，但它也使得放置更加可见：运行时必须尊重邻居关系，而不是假设每对芯片具有相同的通信路径。当工作负载足够规律，以便编译器和集体库能够将通信映射到拓扑时，这是一种合理的权衡。

MI300X 将压力点从本地交换转移到内存容量。其封装暴露出 192 GB 的 HBM，带宽为 5.3 TB/s，而 H100 级加速器仅为 80 GB。因此，一个由八个 MI300X 加速器组成的节点将提供 1,536 GB 的总 HBM 容量，足以容纳我们 175B 运行模型的 350 GB FP16 权重张量。这并未消除在第 2.4 节（第 2.4 节）中引入的优化器、梯度、激活和碎片问题，但它改变了系统将状态溢出到较慢内存层级的频率以及在离载成为强制之前仍可保留的微批次余量。

Gaudi 采取了不同的路径，它在加速器中集成了支持 RDMA 的以太网，并采用更侧重网络的设计来进行通信。Gaudi 2 配置文件通过 24 个连接的 100 GbE 暴露出 300 GB/s 的聚合 RoCE 带宽，而 H100 级 NVLink 节点提供 900 GB/s 的本地 GPU 交换，较新的 Gaudi 3 级加速器仍暴露出 128 GB 的 HBM。问题是：是否通过在节点和 pod 中始终如一地使用以太网来简化结构，值得放弃富交换 NVLink 设计所提供的非常高的本地交换带宽？当数据并行、推理服务或集群成本占主导时，这种权衡可能具有吸引力；但当张量并行集体操作存在于每一层时，吸引力就会降低。

这些替代方案不是供应商排名。它们是稀缺资源的不同分配：节点中的交换带宽、pod 中的常规拓扑、封装中的 HBM 容量或加速器上的网络附接。对于本章中使用的 175B 模型，由于张量并行部分使得本地加速器通信变得尤为重要，因此 DGX 风格的解决方案是自然的。在其他场景下，尤其是内存密集型推荐系统、拓扑规则训练或对成本敏感的服务机群中，不同的边界可能变得最为关键。随后，软件生态系统成熟度、供应可用性和总拥有成本将决定理论上的架构适配是否能成为可部署的系统。

节点健康和可靠性

节点是机群层级结构中的基本故障域。当节点内的单个 GPU 发生故障时，整个节点通常会变得不可用于训练作业，因为张量并行要求所有 8 个 GPU 参与每次 AllReduce 操作。单个缺失的 GPU 会破坏集体通信，导致节点中所有其他 GPU 停止运行。因此，决定节点有效 MTBF 的不是平均可靠性，而是最不可靠的组件。

节点内部故障率最高的组件形成一个诊断清单，大致按频率排序如下：

GPU 显存与组件可靠性

GPU 显存：HBM 可能会遇到 ECC 无法纠正的错误，导致 GPU 脱离服务。
NVLink 连接：信号完整性可能会随时间退化，导致链路重新训练或通信错误。
电源：电容在持续高负载运行下会老化。
散热组件：液冷系统中的水泵和风冷系统中的风扇轴承会引入机械故障模式。

管理良好的机群会追踪每个组件的错误率，并主动将工作负载从显示早期预警迹象的节点上迁移走。最重要的早期预警指标包括：ECC 可纠正错误率上升（通常在不可纠正错误发生前几小时到几天出现）、在恒定负载下结温升高（表明散热性能退化）以及间歇性的 NVLink 重新训练事件（表明线缆或连接器退化）。主动更换显示这些预警迹象的组件，可以防止在多周训练运行中发生代价高昂的非计划作业失败。

因此，节点级健康监控是一项关键的运维实践。现代机群管理系统持续从每个 GPU（温度、功耗、ECC 错误计数、NVLink 错误率）和主机 BMC（基板管理控制器）收集遥测数据。自动化健康检查器会在空闲节点上运行简短的诊断工作负载，以验证所有 GPU、NVLink 和 InfiniBand 连接在作业调度器将训练工作分配给该节点之前都能正常工作。如果没有这种主动监控，一个静默退化的节点可能会破坏训练梯度（如果错误发生在算术路径中）或拖慢整个作业（如果错误导致 NVLink 重新训练，从而暂时降低带宽）。第 7 章详细讨论了机群级容错策略。

故障概率与恢复开销

对于跨越 128 个节点的 175B 模型训练，在为期两周的训练运行期间，至少有一个节点发生硬件问题的概率是相当大的。在综合节点级 MTBF（平均无故障时间）假设为 1,000 小时的情况下，其中包括 GPU、主机组件、电源、散热和网络链路，336 小时运行期间的预期节点故障数约为 43 次。这意味着训练运行平均每天将经历约 3.1 次故障。仅基于 GPU 的下界，根据单 GPU 规范 MTBF 50,000 小时推算，在同一运行周期内预测仅会有 6.9 次 GPU 驱动的节点停机，这还不包括主机、电源、散热和网络故障项。每次故障都需要检测退化节点、驱逐其工作负载、替换备用节点并从最近的检查点恢复——使用自动化工具，该过程需耗时 10 至 30 分钟。有了自动化恢复，直接重启开销约占运行时间的 2.1%–6.4%；若无备用节点和自动化恢复，数小时的人工干预会将开销推高至 20%–30% 范围，消耗数百万美元的 GPU 小时数。

节点内存分区

一个常见的误解是模型的内存占用等于其权重存储。实际上，训练状态远超权重：Adam 优化器动量、梯度和激活值共同消耗的内存是单独参数的 5–7 倍，且这些组件驻留在节点内存层级的不同层级中。

正如表 2.10 所示，对于我们的 175B 模型，训练内存细分如下：

| 组件 | 精度 | 每参数内存 | 175B 模型总计 |

| --- | --- | --- | --- |

| 模型权重 | FP16 | 2 字节 | 350 GB |

| 梯度 | FP16 | 2 字节 | 350 GB |

| 优化器 (Adam m) | FP32 | 4 字节 | 700 GB |

| 优化器 (Adam v) | FP32 | 4 字节 | 700 GB |

| 激活值 | 混合 | 可变 | 100–400 GB |

| 总计 | | | 2.2–2.5 TB |

表 2.10：1750 亿参数前沿模型的训练内存细分：仅优化器状态（FP32 中的一阶和二阶矩）就消耗了模型权重 4 倍的内存，使优化器内存成为训练内存的主要组成部分。这就是为什么内存优化技术高度聚焦于优化器状态分片和卸载。

表 2.10 使这种分区变得具体化。前文确立的 2.2–2.5 TB 相同预算在此重现，但现在按组件和层级分解：FP32 的 Adam 优化器状态，而非 FP16 权重，是主导项，而激活值峰值（随批次大小和序列长度缩放）变化最大。对并行策略选择的启示是：权重只是节点必须持有内容中最小的一块，因此仅分片权重的策略会将最大的消费者——优化器状态和激活值——置之不理。

DGX H100 节点在其 8 块 GPU 上提供 640 GB 总计 HBM，外加 2 TB 主机 DDR5 DRAM。仅 HBM 容量不足以容纳完整的训练状态。要理解为何如此，请考虑不同并行策略的内存算术。纯数据并行下，每个 GPU 必须持有完整模型：350 GB 权重 + 350 GB 梯度 + 1,400 GB 优化器状态 = 2,100 GB —— 在 80 GB 设备上物理上不可能实现。即使是 ZeRO Stage 3，它仅在 8 块 GPU 间分片这三个组件，也会产生 2,100 GB / 8 ≈ 262.5 GB/GPU，仍是可用 HBM 的三倍多。解决方案是将张量并行（跨 GPU 分割模型层，将每 GPU 权重降至 350 GB / 8 = 43.75 GB）与跨多个副本的数据并行分片相结合。在每节点 TP-8 并跨集群 128 路数据并行的配置中，每个 GPU 持有 43.75 GB 权重分片。优化器状态同样被分区，先通过 8 路张量分片，再跨 128 个数据并行副本，因此每个 GPU 持有约 1,400 GB / (1024) ≈ 1.4 GB 优化器状态，或每 8 GPU 张量并行组 10.9 GB，这还不包括梯度、激活值、缓冲区和碎片。约 45.1 GB 的权重加优化器小计只是起点；下文的内存预算练习将展示为何梯度和激活值仍需要检查点和卸载。这种算术正是为何张量并行、优化器分片、激活检查点和内存分层会在大模型训练中结合使用的原因。

ZeRO Stage 3 在参与数据并行的所有 GPU 间完全分片优化器状态、梯度和参数。在节点内 8 块 GPU 间分片时，每个 GPU 仅持有各组件的 1/8，将每 GPU 内存降至约 262.5 GB 等效存储（2,100 GB 总状态 ÷ 8）。这仍超出每 GPU 80 GB，因此分片必须与其他技术结合。激活检查点仅存储一部分中间激活值用于反向传播，并从最近的检查点重新计算其余激活值。它以约 33% 更多 FLOPs 为代价，换取高达 10 倍更低的激活内存。

CPU 卸载将优化器状态存储在主机 DDR5 DRAM 中，仅在参数更新需要时才传输至 GPU HBM。PCIe Gen5 链路的 64 GB/s 带宽会引入传输延迟，但开销可控，因为参数更新仅占总步骤时间的一小部分。NVMe 卸载将同一思路扩展至 SSD 以适应更大模型，顺序读带宽 5–7 GB/s 并伴随更大延迟惩罚，这需要精心的流水线调度以与计算重叠。

内存层次结构和数据加载

节点的内存层次结构因此像一个分层系统一样运作。HBM 存储活跃的计算内容：当前层矩阵乘法所需的权重分片、当前微批次的激活值以及反向传播过程中累积的梯度。DDR5 存储批量优化器状态，仅在每次训练迭代结束时的参数更新步骤中被访问。NVMe 提供溢出容量用于最大模型，存储较少访问的分片，这些分片可以在计算过程中预取。

训练框架的内存管理器负责在这些层级之间编排数据流，其运作方式类似于硬件缓存控制器，但粒度更粗。将其与硬件缓存进行类比是有启发性的：就像 CPU 的缓存控制器通过在处理器需要数据之前预取数据来使用预取技术隐藏内存延迟一样，训练框架的内存管理器使用软件级预取来隐藏 PCIe 传输延迟，通过在 GPU 需要权重之前加载权重来实现。在层 ℓ 的前向传播过程中，管理器同时将层 ℓ + 1 的权重从 DDR5 预取到 HBM（如果它们已被卸载），并将层 ℓ − 2 的权重从 HBM 逐出回 DDR5（如果内存紧张）。

这种流水线确保每一层的计算可以在不等待数据传输的情况下进行，代价是软件复杂度增加以及对预取深度的仔细调校。如果预取太浅，计算会因等待数据而停滞。如果预取太激进，HBM 会被多层之后才会用到的数据填满，从而挤占当前计算所需的激活值和梯度。这些层级之间的容量-带宽权衡决定了训练框架可以保持“热”状态的数据以及必须预取的数据；Table 2.11 量化了内存管理器必须弥补的三个数量级的带宽差距。

| 内存层级 | 容量 | 带宽 | 延迟 | 角色 |

| --- | --- | --- | --- | --- |

表 2.11：节点内存层次结构：每个层级在容量和带宽之间进行权衡。训练框架的内存管理器必须在这些层级之间编排数据流，以适应其总状态超过 HBM 总容量的模型。

这种编排复杂但至关重要：没有它，在 H100 级硬件上训练我们的 175B 模型将是不可能的。第 5 章详细检查了这些内存优化策略及其与并行性的交互作用。

综合应用：内存预算练习

为了巩固内存规划概念，请考虑我们在 DGX H100 节点上针对 175B 模型的具体规模练习。

已知条件：

模型：175B 参数
节点：8× H100 GPU，每个拥有 80 GB HBM（总计 640 GB HBM）
主机：2 TB DDR5
并行性：节点内部 8-way 张量并行

步骤 1：权重分布

采用 8-way TP 时，每个 GPU 存储每个权重张量的 1/8。每个 GPU 的权重内存：43.75 GB（FP16）。

步骤 2：使用 ZeRO Stage 1 的优化器状态

ZeRO Stage 1 将优化器状态分片到数据并行工作器中。在仅使用 TP（无数据并行）的单个节点中，优化器未被分片。每个 GPU 存储其 TP 分片的完整优化器状态：43.75 GB × 4（FP32 m 和 v）= 175 GB。

总量超过了 80 GB HBM 的容量。解决方案是将优化器状态卸载到主机 DDR5。2 TB 的 DDR5 可以容纳完整的 1,400 GB 优化器状态，并且仍有剩余空间。

步骤 3：激活值

通过激活检查点（重新计算每隔一层），对于包含 4 个序列且序列长度为 2,048 个 token 的微批次，激活内存大约为每个 GPU 15–25 GB。如果不使用检查点，则激活内存将达到每个 GPU 100–200 GB，这是不可能的。

步骤 4：梯度累积

梯度与权重大小匹配：每个 GPU 在 FP16 下为 43.75 GB。

每个 GPU 的 HBM 使用总量：

权重：43.75 GB
激活值：~20 GB（带检查点）
梯度：43.75 GB
缓冲区和碎片：~5 GB
总计：~113 GB（超过 80 GB HBM）

解决方案：使用梯度累积（在 AllReduce 前累积 2–4 个微批次，以降低峰值激活内存）和梯度卸载（将非活跃梯度分片存储在 DDR5 中）。采用这些技术后，每个 GPU 的 HBM 使用量降至大约 70–75 GB，能够容纳在 80 GB HBM 限制内，并为 NCCL 通信缓冲区预留少量余量。

系统洞察：模型容量不是唯一的内存限制。只有当权重、梯度、优化器状态、激活值、通信缓冲区和碎片被共同管理时，训练才能得以进行。

该示例说明了为什么对于大型模型的内存规划是一项需要仔细工程的练习，而不仅仅是简单的容量计算。除了内存层级的放置之外，带宽层级结构会对必须跨越节点边界的数据施加严厉的惩罚，这种成本在下一个计算中会被明确说明。

问题：一个训练步骤必须同步一个 1 GB 的梯度缓冲区。相比于在节点内（NVLink）进行传输，跨越节点边界（InfiniBand）进行传输会多花多少时间？

节点内（NVLink）：带宽 = 450 GB/s 单向有效带宽；双向总带宽为 900 GB/s，但此传输时间计算仅考虑单向移动一个缓冲区。T[intra] = 1 GB / 450 GB/s ≈ 2.2 毫秒
节点间（InfiniBand NDR）：带宽 = 50 GB/s。T[inter] = 1 GB / 50 GB/s ≈ 20 毫秒

系统洞察：跨越节点边界会使通信时间增加大约 9 倍。在梯度同步每一步都发生的训练循环中，这种惩罚会导致加速器在每次迭代中的大部分时间处于停滞状态，使利用率远低于 50%。这就是为什么训练框架在节点内部使用张量并行（快速 NVLink），而在节点之间使用数据并行（对较慢的 InfiniBand 具有容忍度）。

数据加载和 I/O 管道

到目前为止的讨论一直集中在节点内部数据如何移动（HBM 到 Tensor Core，GPU 到 GPU 通过 NVLink，GPU 到主机通过 PCIe）。训练还需要从外部存储持续供给节点训练数据流。如果数据加载管道无法跟上 GPU 的消耗速度，系统中最昂贵的组件（GPU）将会空闲等待数据。这就是 I/O 瓶颈，避免它需要对数据加载管道进行精心设计。

对于语言模型训练，训练吞吐量决定了数据消耗速率。如果集群每秒处理 500,000 个 token，且每个 token 需要 2 字节的输入数据（token ID），则原始数据摄入速率仅为 1 MB/s，这对于任何存储系统来说都轻松可以处理。然而，实际的 I/O 需求要大得多，因为训练数据必须经过分词、洗牌、批处理，并传输到 GPU 内存。一个现实的数据管道通过五个有序阶段将原始字节转换为 GPU 就绪的批次：

读取：原始文本从分布式文件系统（NFS、Lustre 或类似 S3 的云对象存储）读取到主机内存。对于大型数据集（TB 级文本），数据通常以二进制格式存储（TFRecord、WebDataset 或内存映射文件），以最小化解析开销。
预处理：在宿主 CPU 上执行分词、序列打包和随机裁剪。这些操作通过数据加载工作进程（通常每个 GPU 使用 4–8 个工作进程）在多个 CPU 核心上并行化。
批处理：单个序列被组装成微批次，填充至统一长度，并组织成张量。
传输：组装好的批次通过 PCIe 从主机 DRAM 传输到 GPU HBM。对于分词语言建模，此传输通常很小，因为 token IDs 和掩码是紧凑的；多模态批次或在宿主机上物化 FP16 嵌入的管道可达到 100–200 MB，并在 PCIe Gen5 带宽下耗时毫秒级。
预取：当 GPU 处理当前批次时，数据加载器并行地预取并预处理接下来的 2–4 个批次，确保当前计算完成时，下一个批次已经位于 GPU HBM 中。

关键的设计目标是让数据流水线对 GPU 不可见：预取必须足够深，以至于无论存储带宽或预处理时间的瞬时变化如何，当 GPU 需要时总是有批次可用。当此流水线调校良好时，GPU 利用率仅受计算和通信限制，而非数据加载限制。当调校不佳时，GPU 可能会花费 10–30% 的时间等待数据，这直接降低了训练吞吐量。

传统数据路径通过宿主 CPU 传输每一个字节：存储控制器到主机 DRAM（一次 PCIe 遍历），然后主机 DRAM 到 GPU HBM（第二次 PCIe 遍历）。这种“缓冲区反弹”架构将 PCIe 根复杂体上的流量翻倍，并使 CPU 成为 I/O 密集型工作负载的瓶颈，由于内核上下文切换和中断处理开销，每个 NVMe 驱动器的有效带宽被限制在 3–4 GB/s。GPUDirect 存储（GDS） 通过在 NVMe 控制器和 GPU 内存之间建立直接 DMA 路径来消除这种低效，完全绕过宿主 CPU。单个 NVMe 驱动器可通过 GDS 直接将 5–7 GB/s 输送到 GPU HBM，饱和驱动器的内部带宽而非宿主机的 I/O 子系统。对于配备四个 NVMe 驱动器的标准节点，GDS 可解锁 20–28 GB/s 的聚合存储到 GPU 带宽，使 CPU 能专注于如分词和序列打包等预处理任务。章节第 4.5 节中的 GPUDirect 存储讨论对此直接路径进行了详细探讨。

所需的预取深度不是任意的，而是基于 I/O 延迟方差的统计得出。如果 GPU 每 T[compute] 秒处理一个批次，而存储系统以 T[I/O] 秒的间隔交付批次，标准差为 σ[I/O]，那么维持 99.7% 零停滞概率所需的最小预取深度 k 为 k ≥ ⌈T[I/O]/T[compute] + 3σ[I/O]/T[compute]⌉。对于我们的 175B 模型训练运行，其中 T[compute] = 2.0 秒，且存储层以 T[I/O] = 1.5 ± 0.5 秒交付批次，所需深度为 ⌈0.75 + 0.75⌉ = 2 个批次。在生产环境中，共享文件系统上的“噪 y 邻居”会导致重尾延迟，工程师通常会将此缓冲过度供应至 4–8 个批次，以使 GPU 免受分布式存储的不稳定物理特性影响。相对于分词语言工作负载中 GPU 停滞的成本，此预取缓冲区的内存成本可忽略不计；尽管多模态管道必须为宿主机端批次缓冲区分配更大的空间。

随着集群规模扩大，一个新的存储瓶颈浮现。当我们在 128 个节点上训练 175B 模型时，系统表现为同步的“雷鸣般的牛群”——所有 128 个节点在每个训练步骤开始时同时请求下一个 token 微批次。即使具有 500 GB/s 聚合吞吐量的共享并行文件系统（如 Lustre），在 128 个客户端同时拉取数据时也会失效，导致读取延迟从毫秒飙升至秒级。解决方案是分层存储，结合激进的本地缓存。通过为每个训练节点配备能够每节点提供 25 GB/s 的本地 NVMe SSD，集群将其即时数据依赖与共享文件系统解耦。后台进程将数据从中央存储异步预取到本地 NVMe 缓存，平滑 I/O 峰值。对于 128 节点集群，本地 NVMe 创建了 3.2 TB/s（128 × 25 GB/s）的聚合读取带宽，远超甚至最昂贵的集中式存储阵列的能力，确保 GPU 永不挨饿。

当数据加载在基准测试中表现快速但在生产条件下退化时，会发生一种微妙的故障模式。单节点基准测试通常从本地 NVMe SSD 读取数据，实现 5–7 GB/s 的读取带宽。而在生产环境中，数据位于被数百个节点同时访问的共享存储系统上，由于网络拥塞和存储控制器争用，每个节点的有效带宽可能降至 100–500 MB/s。基于单节点基准测试设计数据流水线的团队可能会发现，在生产环境中他们的 GPU 正遭受 I/O 饥饿。第 4 章检讨了解决此瓶颈的存储架构策略，包括确保训练数据在不发生停滞的情况下到达 GPU 的分层存储层次结构。

对于我们的 175B 模型，单个 DGX H100 节点提供 640 GB 的聚合 HBM，足以容纳 FP16 模型权重，但不足以在不分片和卸载的情况下容纳完整的 Adam 训练状态。训练还需要处理万亿级别的 token，而单个节点的计算吞吐量将训练时间限制在数月级别。为了在合理时间内完成训练（周而不是月），我们需要数十或上百个节点。将这些节点堆叠到一个物理机箱中，使我们进入基础设施的下一层，此时约束从带宽和容量转向原始功率和散热。

机架

传统数据中心中的标准 42U 机架通过穿孔地板瓷砖吹送的室温空气进行散热，其功耗为 5–10 kW。现在将四个 DGX H100 节点放入同一机架中：32 个 GPU，每个功耗 700 W，加上宿主 CPU、内存、网络、电源转换损耗和散热开销。机架功率达到 33.5 kW，超过了传统数据中心基础设施所设计承担或散热的数量级。在此密度下，工程约束从硅和信号完整性转向功率传输和热力学。机架是功率墙和热传输定律成为主导设计力的地方。

现代 GPU 机架超越了空气冷却包络。

对于我们的 175B 模型，在 1,024 个 GPU 上训练需要 32 个机架（每机架 4 个节点，每节点 8 个 GPU）。每个机架散发 33.5 kW 的热量，相当于小型工业炉的热输出。训练集群的相关设施功耗约为 1.1 MW，足以供几百户住宅使用。可靠地供应此功率、高效地转换它以及在不导致任何组件超过其热极限的情况下移除产生的热量，是一项跨越电气、机械和土木工程的多学科工程挑战。从公用变电站到单个 GPU 电压调节器，电力传输链条上的任意一点故障都可能导致整个训练运行中止，浪费数小时的计算并可能损坏训练状态。

Rack 是物理基础设施单元，一个标准的 42U 机箱，用于容纳多个计算节点、一个机架顶部（ToR）交换机（连接机架内所有节点与更广泛集群织物的首个网络聚合点）、电力分配单元和冷却分配歧管，定义了电力和冷却容量必须预留的粒度。

意义：AI 机架功率密度显著增长：一个包含 4 个 DGX H100 节点的机架拥有 32 个 GPU，每个功率为 700 W，仅 GPU 功率就达 22.4 kW，加上 CPU、NVSwitch、NIC、电能转换损耗和冷却开销 11+ kW，每机架总功率达 33–40 kW。这远超通用数据中心机架典型的 5–10 kW，需要专门的液冷基础设施和必须与建筑同步设计的电气电路。
区别：与节点（计算单元）不同，机架是基础设施单元：它是冷却歧管、电力分配和 ToR 交换机集成的物理层级——使得机架成为设施运维中最小的可替换和可维修单元，而非节点。
常见误区：一个常见的误解是机架摆放是后勤上的事后考虑。同一机架内的节点共享一个 ToR 交换机，具有单跳连接；不同机架之间的节点至少需要经过两次交换机跳转。将训练作业的所有流水线并行阶段放置在同一机架内，可最小化阶段间延迟并降低机架间织物负载。

机架开启者承诺，热传递定律将成为此级别的主导设计力量，原因在于移动流体从表面带走热量的速度存在硬性物理极限。空气是一种较差的冷却介质：它密度低、比热容低，因此一定体积的空气在温度升升到无法再冷却硅的程度之前，只能吸收很少的能量。即使配合热通道/冷通道隔离和高静压风扇的强制风冷，其散热速率也仅取决于设施能够物理推送通过机架的空气量。该速率上限约为每机架 30 kW。在大约 10 kW 以下，通过穿孔地板砖的室温空气已足够，这也是为什么传统 42U 机架从未遇到热问题的原因。经过设计的风冷可将这一极限提升至约 30 kW，但无论增加多少风扇功率，都无法突破此限制：超过此密度时，机架排出的空气已太热，无法吸收更多热量；而额外添加风扇不仅消耗功率、产生噪音，还无法移除额外的瓦特。四个 DGX H100 节点组成的机架功率已达 33–40 kW，已经超出风冷上限；而 Blackwell 级机架正朝向 100 kW 及以上迈进，此时风冷彻底失效。在此密度下，空气不是被“节流”，而是被直接“淘汰”。

这一热阈值迫使机架从风冷转向液冷：超过风冷阈值时，移除热量的唯一方法是使用远比空气更密的冷却介质直接与硅接触，这就是为什么高密度 AI 机架因物理必要性而非选择而必须采用液冷。第 15.4.6 节将探讨满足此要求的冷却架构、风冷与液冷的效率比较，以及该选择在集群运行每小时所带来的设施电力开销。

机架设计考量

机器学习（ML）机架的物理设计与传统服务器机架存在显著差异，这种差异远超功率和冷却范畴。在传统的 42U 机架中，服务器以独立的 1U 或 2U 披萨盒单元形式安装，每个单元均配备自身的风扇、电源和线缆连接。而 ML 机架采用根本不同的形态。一个 DGX H100 占用 8U，内含 8 个 GPU、NVSwitch 结构、多个电源，以及（在液冷配置中）带有快速接头的冷却歧管。四个 DGX 单元放入一个 42U 机架后，仅剩 10U 用于网络交换机、线缆管理和 PDU。

从传统服务器形态向 ML 优化设计的转变，其驱动力与迫使从风冷转向液冷的同一功率密度挑战完全一致。传统 1U 服务器散热功率为 300–500 W，仅需 modest（适度）气流即可冷却。而 DGX H100 节点在其 8 个 GPU、NVSwitch 和支撑组件上的散热约为 8.4 kW，无论是风冷（需巨大气流）还是液冷（需冷却管路）配置，都需相应热管理方案。由于机箱形式必须同时容纳计算硬件与热管理基础设施，因此 ML 节点的高度显著高于传统服务器（8U 对比 1U）。

线缆管理是一项非同小可的工程挑战。每个 DGX H100 节点有 8 条 InfiniBand 线缆（每 GPU 一条）、2 条以太网管理线缆、电源线缆，以及（对于液冷单元）冷却软管。一个完全填充的机架包含超过 40 条高速线缆，每条都必须精心布线。

以下三个物理约束决定了线缆布局：

气流间隙：在风冷设计中，线缆不得阻碍气流，因为即使是部分阻塞也可能产生热点，导致附近组件降额。
弯曲半径：高速线缆具有最小弯曲半径，通常为主动光缆直径的 10–15 倍，低于此值时信号路径会受损，可能导致比特错误或完全链路故障。
电磁干扰：将过多高速铜缆绑在一起会降低相邻链路上的信号质量。

在大型安装中，仅线缆布设就可能耗时数周进行安装和测试，而线缆布线错误是导致安装后调试延迟的最常见原因之一。

随着液冷集群的机架功率密度攀升至 100 kW，传统按服务器进行交流电（AC）转换的低效率已变得无法忍受。传统设计在每个机箱中专门预留空间用于冗余交流电源单元（PSUs），而许多高密度机架设计采用 机架级直流电（DC）分配。在此架构中，一个集中式电源架将市电 AC 转换为贯穿机架高度的 48V DC 母线，取代单个服务器的 PSUs。这种整合消除了一个转换阶段，在训练 175B 参数模型且涉及数千个 GPU 时，可实现系统范围内 2–3% 的效率提升——这是热负荷的有意义降低。电力直接通过 48V 母线送达服务器背板，在那里紧凑的 DC-to-DC 转换器先将其降至 12V，再降至 GPU 的低于 1V 工作电压。该拓扑结构由 Google 和 Meta 通过开放计算项目（OCP）首创，可减少故障点，并为液冷回路和高带宽互连回收宝贵的机箱空间。

机架顶部（ToR）交换机 需要特别关注。在传统数据中心中，ToR 交换机为每台服务器提供 1–10 Gb/s 的以太网连接，并将这些连接汇聚到更高层级交换机的上行链路。而在 ML 机架中，ToR 交换机是 InfiniBand 或高速以太网交换机，每个端口提供 400 Gb/s，且必须处理分布式训练中的突发、同步流量模式。

ToR 交换机的放置和配置直接影响网络拓扑。面向轨道优化的设计（被 Meta 等公司使用）将每个节点内的每个 GPU 分配到一个特定的“轨道”，该轨道连接到专用的 ToR 交换机。在传统设计中，节点内的所有 8 个 GPU 连接到同一个 ToR 交换机，当多个 GPU 同时发送 AllReduce 流量时，可能成为瓶颈。而在轨道优化设计中，每个节点中的 GPU 0 连接到 ToR 交换机 0，GPU 1 连接到 ToR 交换机 1，依此类推。这确保了在一个并行 ism（并行性）组内（其中所有参与者是不同节点上相同 GPU 索引）的 AllReduce 流量被限制在单个交换机内，而无需穿越完整的织物。

铁路优化设计要求每个机架组使用 8 个 ToR 交换机，而不是 1 个，这增加了交换机成本和布线复杂性。然而，它消除了最常见通信模式（节点间数据并行 AllReduce）导致的交叉交换机拥塞，与传统单 ToR 设计相比，提升了扩展效率 5–15%。章节 3 详细探讨了铁路优化拓扑结构，包括其带宽属性的正式分析以及其何时能够优于脂肪树（fat-tree）替代方案的条件。

设施可靠性和环境控制

机架设计还定义了物理故障域。部署机器学习基础设施的数据中心实施多层物理安全和环境监控，不仅为了符合法规要求，还因为单个机架的 DGX H100 节点（仅硬件价值达$1.4 million）集中了足够的价值、热量和液冷风险，以证明采用超出传统服务器设备所需控制的合理性。

因此，环境监控成为计算设计的一部分，而非事后考虑。架空地板瓷砖下方和液冷管道周围的水浸传感器能够在几秒钟内识别泄漏并触发自动冷却隔离阀。吸气式烟雾检测系统持续采样机架内空气，能够探测到低于喷洒系统启动探测器所能感知浓度的燃烧副产物。安装在建筑结构和机架框架上的振动传感器能够捕捉可能损坏磁盘驱动器或松动电缆连接的地震事件或施工引起的振动。湿度控制使相对湿度保持在 40–60%，以防止静电放电和冷凝。

这些环境控制不是事后考虑，而是基础设施设计的组成部分，影响着可靠性和正常运行时间。若水渗漏达到 DGX H100 主板，可能导致数百万美元的损失和数周的停机时间。单个机架的火灾可能导致整个数据中心机房在消防系统充电和受影响区域去污过程中停机数天。2021 年斯特拉斯堡 OVHcloud 火灾表明，若缺乏适当的隔离措施，单建筑事件可能升级为全站范围的故障域。

背景：OVHcloud 在其斯特拉斯堡站点运营着四个数据中心，为那些依赖该站点的物理电力、防火和恢复设计的客户提供服务（OVHcloud 2021）。

故障模式：2021 年 3 月 10 日，SBG2 发生火灾。OVHcloud 报告称 SBG2 被毁，SBG1 严重受损，其他斯特拉斯堡数据中心即使未直接受火也被断电。

后果：该事件导致许多客户曾视为稳定基础设施而非共享物理故障域的站点范围内出现服务中断和数据恢复工作。

系统教训：计算基础设施不仅仅是 GPU 和网络拓扑。防火分隔、电源隔离、备份地理位置和灾难恢复假设决定了机架规模的事件是否会升级为全站范围的中断。

一旦机架级控制到位，可靠性问题将上移至设施冗余。同样的故障域逻辑用于隔离漏液机架，也决定了站点应购买多少冗余电源、冷却和恢复容量。

数据中心的可靠性通常使用 Uptime Institute 分级系统进行分类，Tier III和Tier IV代表任务关键型计算的常见选择（Uptime Institute 2026

图 2.13：Pod 级网络拓扑：两种主导的 Pod 拓扑结构比较。（左）Fat-Tree（3 层）：具有 Leaf、Spine 和 Core 层：全双割带宽，被 InfiniBand 集群如 DGX SuperPOD 所采用。（右）2D Torus 带环绕链路：双割带宽随着$\\mathcal{O}(\\sqrt{N})$的规律缩放，在大规模时成本更低，但更倾向于具有强局部性的工作负载；被 Google TPU Pods 所采用。该选择决定了哪些并行策略能够高效运行。

Pod 的工程挑战在于将这些节点连接成一个足够快的网络，以防止梯度同步成为瓶颈。Pod 将数百个机架聚合为一个协调的计算系统，其中网络结构起到与单机内系统总线相同的作用。

具体来说，这一挑战的规模值得被珍视。一个 1,024 节点的 DGX H100 集群包含 8,192 个 GPU，4,096 个 NVSwitch 芯片，8,192 个 InfiniBand HCAs，几百个 InfiniBand 交换机，数以万计的电缆，以及大约消耗 7–10 MW 的功率。它大约占用 250 个机架，分布在一个或多个数据中心机房内。

这样的集群的物理重量也很可观。每个 DGX H100 节点的重量约为 130 kg（287 磅），因此 1,024 个节点的重量超过 133 公吨。结合机架、交换机、电缆和冷却基础设施，总重量可超过 300 公吨。数据中心地板必须经过结构工程设计以支撑这种集中负载，典型的地板荷载要求为 ML 集群的 1,500–2,500 kg/平方米，而传统服务器安装的地板荷载要求为 500–1,000 kg/平方米。这种结构需求常常在设施规划过程中被忽视，并且可能成为改造现有建筑的阻碍。

数据中心大厅的物理布局反映了这些密度限制。ML 训练机架的极高功率密度要求在风冷部分采用严格的热通道/冷通道封闭，冷空气被强制送入机箱封闭的前部，废热在后部排气口立即被捕获。大厅的“脊柱”——连接所有机架至聚合交换机的中心电缆走廊——必须容纳数千根光纤电缆和电源馈线。为了改善气流和可访问性，首选使用上方电缆托盘而非地下布线，以承载形成集群神经系统的重型铜电源馈线和易碎的光纤互连。布局还必须容纳液冷基础设施：CDU 的放置、冷却剂管道走廊以及允许单个机架在不排空整个冷却回路的情况下进行维修的隔离阀。这些物理布局决策是在设施设计阶段做出的，多年后限制了训练团队可用的网络拓扑选项。

在此集群上训练 175B 模型需要 6 × 175 × 10⁹ × 300 × 10⁹ 次总浮点运算（假设为 3000 亿训练 tokens）。在 45% MFU——一个强但可实现的数值，适用于调校良好的大模型训练——的情况下，集群可维持 8, 192 × 1979 × 10¹² × 0.45 FLOP/s，即约 7.30 EFLOP/s，得出物理极限训练时间约为 12 小时。

实际上，通信开销、流水线气泡、检查点 I/O、硬件故障和维护窗口叠加，使实际挂钟时间超过了物理极限。一个简化的乘数链得出大约 18 小时的系统最小值；一旦排队、数据就绪、调试、重新运行和特定站点的运营裕度进入计划，生产计划可能会延伸至几天或几周。核心主题保持不变：在 pod 规模下，基础设施不完善主导于硅的原始能力。挽回这部分损失的时间是分布式系统工程的核心挑战，其解决方案涵盖硬件（更好的网络）、软件（重叠通信）和运营（主动维护以最小化停机时间）。

我们可以从第一原则推导出我们 175B 模型的训练时间。

总 FLOPs：使用近似公式 6 × P × D，其中 P = 175 × 10⁹，D = 300 × 10⁹ tokens：3.15 × 10²³ FLOPs
集群吞吐量：8,192 块 H100 GPU，峰值性能为 1979 TFLOP/s，在 45% MFU 下运行：8, 192 × 1979 × 10¹² × 0.45 FLOP/s 持续 ≈ 7.30 EFLOP/s
理想化训练时间（“物理极限”）：(3.15 × 10²³ FLOPs)/(8, 192 × 1979 × 10¹² × 0.45 FLOP/s) ÷3600≈ 12.0 小时
实际乘数：
- 通信开销（缩放效率 ≈ 0.85）：÷0.85→ 14.1 小时
- 流水线气泡（ ≈ 5%）：×1.05→ 14.8 小时
- 检查点开销（ ≈ 3%）：×1.03→ 15.3 小时
- 硬件故障和重启（ ≈ 墙上时间的 10%）：×1.10→ 16.8 小时
- 维护窗口（ ≈ 5%）：×1.05→ 17.6 小时

总计：在此简化的系统最小值链中为 17.6 小时，或以周为单位表达时为 0.1 周。真实的生产日历在加入排队、调试、重新运行和特定站点的运营裕度后，仍可能延伸至几天或几周。挽回这部分损失的时间是分布式系统工程的领域——即第 5 章的主题。

在这种规模下，分析单位不再是独立服务器的机架或 pod；设施必须表现为一台协调一致的机器。

Warehouse-Scale Computer (WSC) 是一种建筑规模的计算系统，其中数千台服务器被视为一台协调一致的机器进行操作（网络织构作为系统总线，分布式存储作为磁盘子系统，集群编排器作为操作系统），从而使得在单台机器上物理上不可能完成的训练工作负载成为可能。

重要性：一台配备 10000 块 H100 GPU 的 WSC 可提供约 9.89 EFLOP/s FP16 峰值性能（以及约 19.8 EFLOP/s FP8 性能），使得在单个节点上不可能实现的 175B 级训练工作负载成为可能。然而，该系统的速度仅受其双向带宽限制：每个 GPU 提供 50 GB/s 的非阻塞 InfiniBand，提供 500 TB/s 的聚合注入带宽；如果织构是 4:1 超额订阅，则有效双向带宽降至 125 TB/s，可能成为 AllReduce 的瓶颈，导致训练吞吐量下降 30–60%。
区别：与通用计算集群不同（后者在独立节点上运行许多独立作业，无需紧密耦合），WSC 训练集群作为一个单一的同步仪器运行，其中每个节点必须参与每一次 AllReduce，因此单个节点的故障或减速将成为集群范围内的性能事件。
常见陷阱：一个常见的误解是 WSC 设计主要是软件工程或 IT 运营工作。WSC 设计是建筑级计算机架构：物理布局（机架布置以最小化机架间跳数）、电力供应链（PUE 目标、液冷歧管）和网络拓扑必须作为一个统一系统进行协同设计：任何一层的错误都会通过所有层传播。

该概念由 Luiz Andre Barroso、Urs Holzle 和 Parthasarathy Ranganathan 在 Google 于《数据中心即计算机》中正式提出（Barroso et al. 2019）。关键洞察在于，在 Google 的规模下，数据中心就是计算机，传统计算机架构原则必须应用于建筑层而非芯片层。

WSC 架构原则

![三级时间阶梯：一个 GPU 的平均无故障时间约为 50,000 小时，1,000 个 GPU 约为 50 小时，10,000 个 GPU 约为 5 小时。*（媒体/file43.svg）

随着 GPU 数量的增加， fleet 级 MTBF 成反比下降。

由 Barroso、Holzle 和 Ranganathan 在 Google 提出的 Warehouse-Scale Computer 概念，将数据中心从一个“充满计算机的房间”重新框架为一个“恰好占据一个房间的单一计算机”（Barroso et al. 2019）。这种重新框架对物理设计具有深远影响。

在传统数据中心中，每台服务器都是一个独立单元，具有自己的操作系统、存储和网络标识。设施仅提供电力、冷却和物理安全。服务器可以独立地被添加、移除或替换，且不同服务器上运行的工作负载彼此无关。

在 WSC 中，单个服务器类似于多核处理器中的一个核心：它没有独立的实用价值，仅作为更大系统的一部分而存在。孤立运行的 DGX H100 节点无法训练 175B 模型；只有当它通过精心设计的网络织构连接到数百个其他节点时，才变得有用——此时，分布式存储系统提供训练数据和检查点存储，而 fleet 编排器协调所有节点上的工作。

两个物理后果直接来源于这种重新构架。首先是网络，而非计算，决定了上限：在单个节点上，NVLink 提供足够的带宽用于张量并行，但跨节点时，互连必须传输梯度张量、激活检查点和流水线阶段输出，因此仓库级机器的速度仅取决于将各核心绑定在一起的线路。Chapter 3 对该互连进行完整展开；此处只需指出，WSC 重新构架使得互连成为一等的架构组件，而非外围配件。

第二个后果是故障是物理必然，而非例外事件。单块 GPU 的平均无故障时间（MTBF）约为 50,000 小时（在 Chapter 7 中使用的标准 GPU MTTF 锚点 Systems.Reliability.Gpu.mttf_hours），但可靠性会随组件数量线性下降：一万块此类 GPU 的集群大约每五小时会出现一次故障。Section E.1.2 推导出舰队级故障率实际上就是每个组件寿命除以组件数量。这是物理机器的建筑层属性，正因为如此，WSC 必须从一开始就设计成单个组件故障只会导致性能下降而非工作中断，需要具备双路供电、冗余交换结构以及每一层的持久检查点存储。

第三个后果是构件的组合方式会随所承担的工作负载而不同。一个 pod 并非由单一的标准部件列表组装而成；互连、交换以及内存布局都会根据主导工作负载的通信与容量模式进行选择。Table 2.12 对比了三个生产 pod 以说明这一点：NVIDIA SuperPOD 通过 InfiniBand fat‑tree 将 GPU 串联，提供任意到任意的灵活性；Google TPU pod 将芯片硬连线成环形结构，以实现数据流吞吐；Meta 的 Grand Teton 则围绕嵌入式内存而非纯算力来组织同类加速器。

| 系统 || NVIDIA SuperPOD || Google TPU Pod || Meta Grand Teton |

| --- | --- | --- | --- | --- | --- |

| 互连 || InfiniBand Fat‑Tree || 3D Torus ICI || RoCE（以太网 RDMA） |

| 交换 || 外部交换机 || 直接芯片间连接 || Leaf/Spine 以太网 |

| 拓扑 || 任意到任意 || 最近邻网格 || 分层轨道 |

| 优化目标 || 灵活性 || 数据流吞吐 || 嵌入式内存 |

| 主导工作负载 || 多样化科研 || 大语言模型训练 || 推荐系统 |

Table 2.12: 按工作负载划分的 Pod 架构：每个 pod 的互连、交换和内存侧重点反映了其主导工作负载的通信与容量模式，而非单一的最佳设计。决定组织优化何种工作负载的经济学在 Section 12.3 中讨论。

Grand Teton 最清晰地展示了是内存布局而非计算驱动了整体布局。Meta 的推荐与排序模型使用的嵌入表规模可达数 TB，远超单个加速器的 HBM 容量，而对这些嵌入进行处理的密集神经网络层相对较小。设计将两者在内存层次结构中分离：TB 级别的嵌入表放在主机 CPU DRAM 中（约 $3–5/GB），而密集层在 GPU 上运行，算力密度足以支撑 $10–15/GB 的 HBM 成本。嵌入查询受内存容量限制而非带宽限制：每次请求只访问庞大表格中的一小块，因此廉价的大容量 DRAM 是其理想存放位置，而昂贵的加速器内存则留给需要饱和其带宽的工作。系统层面的经验是，最佳基础设施应针对工作负载而非单纯追求规格最大化：若将计算优化节点用于内存容量受限的工作负载，大部分加速器吞吐量将因硅本身并非瓶颈而被闲置。

舰队在这些物理限制下如何运行、如何检测退化、如何依据故障率设定检查点频率、如何在互连上调度作业，以及如何选址、定价与采购，这些都在舰队运营和付费的章节中展开：Section 12.3 讨论选址、是自建还是采购以及容量规划；Section 12.6 关注舰队遥测与灰故障检测；Chapter 8 讲解群组调度与拓扑感知放置；Section 7.1.2 探讨检查点间隔的取舍。物理构件已就位，运营纪律建立其上。

这些物理约束定义了仓库规模计算机的设计。新技术并不会消除壁垒，只是将壁垒移动。以下技术之所以重要，是因为它们改变了内存、通信或电力约束的所在位置。

将壁垒移动的基础设施技术

新建数据中心在其 15 年的结构寿命内会使用三四代加速器，因此面向未来的技术只有在改变持久规划约束时才有价值。关键不在于技术是否新颖，而在于它移动了哪面墙、移动后出现了什么新墙，以及因此导致的舰队设计决策会怎样变化。Compute Express Link（CXL）移动了内存容量的边界。晶圆级集成移动了芯片间通信的边界。高级封装移动了加速器封装内部的芯片边界。它们都不违背数据移动的物理规律，只是重新定位了基础设施团队需投入功耗、制冷、成本与软件复杂度的地点。

Compute Express Link (CXL)

一个重要的节点架构技术是 Compute Express Link (CXL)²⁶，它是一种基于 PCIe 物理层构建的缓存一致性互连，能够让 CPU、加速器和内存扩展设备共享一致的地址空间。其价值并不在于让远程内存变快，而在于让容量更加灵活。传统上，每个节点的主机 DRAM 被视为固定的本地池，每个加速器的 HBM 则是孤立的高速岛屿；而 CXL 互连可以将内存扩展器或池化内存暴露给在特定训练阶段需要容量的设备。

对于机器学习训练而言，自然的目标是冷或阶段局部状态，而非活跃的矩阵乘法工作集。我们的 175B 模型的 Adam 优化器状态占用约 1,400 GB，且仅在参数更新时被访问，而不是在每一次 Tensor Core 运算中流动。共享的 CXL 池因此可以通过容纳优化器分片、嵌入表溢出或本地数据缓存缓冲区，减轻每个节点的内存压力。训练框架仍需对这些状态进行细致调度，但“是否能装进此节点”或“溢写到存储”的二元问题变得不那么严苛。

新的壁垒是带宽。典型的 PCIe Gen5 x16 CXL 内存路径提供约 64 GB/s，而 H100 HBM 可达 3.35 TB/s。这 52 倍的差距意味着前向与反向传播的权重和激活仍需驻留在 HBM 中。CXL 属于容量层，而非 HBM 的带宽替代品。对舰队设计的具体启示是：规划者应询问服务器平台、机架布局和编排软件是否能够吸收 CXL 内存池化，而不是问 CXL 是否能消除对高带宽加速器内存的需求。

HBM 仍然快 52 倍，因此 CXL 仅用于扩容。

晶圆级集成

与 CXL 处于对立极端的是在第 2.2.1 节中介绍的晶圆级引擎，它将集群浓缩到单个芯片上，使片上带宽几乎“免费”。该架构和良率机制已在彼处论述；对基础设施规划而言，关键在于它移动了哪堵墙。通过将工作集放在晶圆上，芯片间通信墙在很大程度上消失了，但取而代之的是一堵新墙：容量和注入带宽。

我们运行的 1750 亿参数模型仅 FP16 权重就需要 350 GB，远超晶圆上 44 GB 的 SRAM 容量。Cerebras 通过权重流式传输解决此问题：外部 MemoryX 单元以 1.2 TB/s 的速度向晶圆供送权重，同时晶圆执行每一层计算，从而将模型容量与片上内存解耦。这适合推理以及计算阶段清晰的工作负载，但训练重新引入了更棘手的调度问题，因为激活值、梯度和优化器更新必须跨前向和后向传递进行协调。晶圆级设计用流式带宽墙换掉了通信墙。

给基础设施规划者的启示不是晶圆级系统取代 GPU 集群。而是内存邻近性与内存容量相互权衡。WSE 风格的设计通过将工作集置于算力附近，换取了非凡的局部带宽；而 CXL 通过将内存移得更远，换取了灵活的容量。HBM 处于这两个极端之间：片外但封装内，比主机内存小，但足够快以支撑活跃计算。正确的架构是其内存层级与工作负载的复用模式相匹配的架构。

先进封装

支撑这两个方向的是先进封装的演进。封装将边界移入加速器封装内部，而不是一直延伸到机架层面，或是完全收敛到单个晶圆上，这至关重要，因为单次光刻的光掩模极限仅约为 858 mm²。2.5D 中介层（interposers），如 TSMC 的 CoWoS，将计算芯片和 HBM 堆栈安装在共享的硅基板上，使基于芯粒的加速器在大多数软件层面表现得像单个器件。3D 堆叠，采用 SoIC 等技术，将 SRAM 缓存或逻辑直接垂直堆叠，进一步缩短数据路径。从 H100 到 B200 的演进展示了对集群的影响：封装能提供更多的局部算力和芯粒间带宽，但机架必须承受更高的功率密度、更严苛的散热要求，以及对功率瞬变更低的容忍度，硅片优势才能转化为可用的基础设施。

共同主题是迁移而非消除。CXL 将容量外移至网络结构，留下带宽作为限制因素。晶圆级集成将通信内移，留下容量和良率作为限制因素。先进封装压缩了芯粒间距离，留下功率密度作为限制因素。因此，基础设施规划仍始于识别下一个字节移动到哪里、必须多快到达，以及必须构建何种物理系统，使得数据移动不再主导工作负载。

谬误与陷阱

由于瓶颈是移动而非消失，相同的规划错误会反复出现：团队优化可见的规格指标，却错过了约束性的物理瓶颈。算力基础设施的错误通常源于优化可见的规格指标，而忽略了约束性的物理瓶颈。下述谬误将本章的节点、机架、Pod 和设施层面的教训转化为操作性警示。

谬误：GPU 越多，训练越快。

工程师常假设训练时间随 GPU 数量线性缩放：GPU 加倍，训练时间减半。实际上，通信开销随集群规模增长，最终占据主导地位。

阿姆达尔定律确立了理论极限：计算的串行部分（梯度同步、流水线气泡时间、数据加载停顿）无论并行度如何，都限制了最大加速比。对于具有 350 GB 梯度的 1750 亿参数模型，每个训练步骤的 AllReduce 要求每个 GPU 与其他所有 GPU 交换数据。

在 1,024 GPU 的集群上，若网络未精心设计，此同步可能消耗总步骤时间的 30%–50%。从 1,024 扩展到 2,048 GPU，硬件成本翻倍，但训练时间可能仅减少 30%–40%，回报迅速递减。扩展效率曲线是凹的：前 100 个 GPU 提供近乎线性的加速，接下来的 900 个回报递减，超过 2,000–4,000 GPU 后，对大多数模型规模而言，每增加一个 GPU 的边际收益趋近于零。

正确的做法是在采购下一个 Pod 前，先在当前规模下剖析有效计算时间、暴露的通信时间和空闲时间。如果新增 GPU 主要增加暴露的通信时间，采购买到的就是空闲时间而非训练进度。第 5.4.1 节稍后将把这一局部比率转化为扩展效率估算，以在采购决策前做评估。

陷阱：仅凭峰值 FLOP/s 规划训练吞吐量。

采购团队常通过对比峰值 FLOP/s 规格来选择加速器。这种推理忽略了 Roofline 模型的核心洞见：如果工作负载的算力强度低于屋脊点，限制性能的是内存带宽，而非计算。H100 的屋脊点约为 295.2 FLOP/byte。LLM 推理运行在 1–2 FLOP/byte，仅达到峰值 FLOP/s 的 1% 不到。即使是受益于批处理的 LLM 训练，通常也只能达到峰值 FLOP/s 的 30%–50%，原因是受内存带宽限制的注意力核、激活重计算和通信停顿。仅凭峰值 FLOP/s 选型，好比选车只看极速，却忽略了日常通勤的燃油效率。

谬误：功耗和散热约束可在买完加速器后再处理。

团队基于算力需求规划 GPU 采购，却未核实目标设施能否提供所需电力和散热。这些是具有长交付周期的硬性物理限制。

单个装有四套 DGX H100 系统的机架需要 33.5 kW 功率。升级数据中心电气基础设施（新变压器、开关设备和 UPS 容量）需要 12–18 个月的提前期。制冷厂房升级（冷水机组、管道、水泵）需要 6–12 个月。甚至看似简单的变更，如将单机架 PDU 从 20 kW 升级到 60 kW，也可能需要新布线和断路器面板。

组织在未确认设施就绪前订购硬件，就会冒着风险让价值数百万美元的 GPU 留在停车场的集装箱里，等待楼宇改造完成。这并非假设：在 2023–2024 年的 GPU 抢购潮中，多家组织亲历了此境——GPU 交付周期缩短得比数据中心建设时间线还快。

陷阱：购买更新的加速器却不检查工作负载的算力强度。

某团队部署 B200 GPU（FP8 峰值 4,500 TFLOP/s）用于推理工作负载，服务 70 亿参数模型，批次大小为 1。其算力强度约为 1 FLOP/byte，使工作负载深陷内存带宽受限区。

B200 的内存带宽（8 TB/s）仅比 H100（3.35 TB/s）高 2.4 倍，因此这种 batch-1 工作负载受限于带宽，而非峰值算力。如果对比标准是 B200 FP8 对比 H100 FP16/BF16 级别的吞吐量，算力峰值约高 4.6 倍，但解码性能仅提升约 2.4 倍。团队为无法利用的算力买单。对于这种特定工作负载，H100 凭借其更低的单位内存带宽成本，会是更具性价比的选择。

谬误：风冷对 AI 工作负载已足够。

传统机房运营者认为，只要增加足够的风扇和冷水机组容量，风冷就能扩展至高密 AI 机柜。这是不可能的。物理上，风冷在单机柜功率超过约 30 kW 时无法足够快地带走热量；高密 AI 机柜功耗可达 60 至 120 kW，而 Blackwell 级机柜设计甚至突破 130 kW。试图对这种集群进行风冷会导致热节流、持续降频，最终引发组件故障——这不是性能损耗，而是硬件隐患。对于这些集群，液冷不是优化选项；它是热力学刚需，由机柜密度的选择独立决定，与任何 TCO 分析无关。

谬误：所有 GPU 小时在 TCO 分析中等价。

成本对比中常见的错误，是将 H100 上的一个 GPU 小时视作可与 A100 或 V100 上的一个 GPU 小时互换。现实中，不同 GPU 代际每单位有效计算的成本差异巨大：新一代加速器每美元提供的有效吞吐量高得多。一个 H100 GPU 小时提供的 TFLOP/s 是 A100 GPU 小时的 6.3 倍，是 V100 GPU 小时的 15.8 倍。一个耗时 10,000 V100 GPU 小时的训练任务，仅需约 632 个 H100 GPU 小时即可完成同等计算量。相关指标不是每 GPU 小时成本，而是每有效 TFLOP 小时成本，该指标同时考虑了每小时价格和交付的有效吞吐量。仅以 GPU 小时成本为基准评估云选项的组织，会系统性地高估更新、更高效硬件的费用。

陷阱：在确定训练瓶颈前升级网络。

团队有时会大笔投资升级网络结构（例如从 200 Gb/s 升级到 400 Gb/s InfiniBand），期望训练速度成比例提升。提升幅度完全取决于当前网络带宽下训练循环是否受通信限制。若每训练步骤计算耗时 20 秒，通信耗时 2 秒，则工作负载受计算限制：网络速度翻倍仅将总步骤时间从 22 秒降至 21 秒，提升仅 4.5%。同等投资若用于增加 GPU（减少计算时间）或提升 MFU 的软件优化（减少无效计算），回报将大得多。Roofline 模型适用于整个集群，而非仅单个芯片：在投资计算或通信前，先诊断瓶颈是计算还是通信。

谬误：平均功耗足以用于散热设计。

加速器功耗在通信阶段（较低功耗）和计算阶段（较高功耗，达或接近 TDP）间动态变化。训练步骤中的平均功耗通常为 TDP 的 70%-85%。按此平均值而非 TDP 峰值设计散热基础设施的团队会发现，计算阶段芯片温度飙升，触发热节流从而降低持续吞吐量。散热系统必须按最坏热负载（所有 GPU 同时处于 TDP）设计，尽管该峰值每步仅维持一小段时间。散热不足的代价隐蔽且严重：系统表面运行正常（无崩溃、无报错），但 MFU 因 GPU 降频以维持热限制而悄然下降 10%-20%。

陷阱：仅按 HBM 容量选型而不核查带宽。

采购团队有时仅关注模型权重能否“装进”可用 HBM，忽视带宽维度。一个虽能装入 HBM 却因带宽不足无法在可接受延迟下服务的模型，与装不下的模型一样不可用。以服务 700 亿参数模型为例对比两种方案：(a) 192 GB HBM2e、带宽 2.04 TB/s 的加速器；(b) 80 GB HBM3、带宽 3.35 TB/s 的加速器。方案 (a) 容量绰绰有余（FP16 下模型仅需 141 GB），但生成 token 速度为 141 GB/2.04 TB/s = 69.2 ms/token。方案 (b) 需谨慎量化才能装入（FP16 下 141 GB 装不进 80 GB，但 INT8 下 71 GB 可装入），生成 token 速度为 71 GB/3.35 TB/s = 21 ms/token，快 3.3 倍。对延迟敏感的服务场景，尽管容量较小，方案 (b) 更优。正确的加速器是其带宽与容量共同满足工作负载需求的那个。

谬误：数据加载部署后再修复。

团队若将所有部署前优化精力集中在 GPU 内核性能和通信效率上，部署后常会发现 GPU 因缺数据而“饿死”。数据加载流水线（存储 I/O、预处理、主机到 GPU 传输）必须维持吞吐量，达到或超过 GPU 集群的消费速率。语言模型训练中，原始数据摄入率不高（MB/s 级），但预处理流水线（分词、序列打包、洗牌）在每 GPU 消费数据速度超过单 CPU 核准备速度时，会成为 CPU 瓶颈。修复虽直接但必须提前规划：为数据加载工作进程分配足够 CPU 核心（通常每 GPU 4-8 个），将训练数据暂存于高速本地 NVMe 而非依赖共享网络文件系统，并将数据加载与 GPU 计算流水线重叠。

陷阱：购买同构集群而不建模工作负载多样性。

“统一硬件简化调度、减少拖后腿者”这一直觉，常导致组织过早淘汰仍有能力的旧一代硬件。对我们的 175B 模型，最优成本策略常涉及混合代际机群。训练需要 H100 的原始 FLOP/s 和互联带宽以最小化同步开销，而推理服务受限于内存带宽而非计算。

A100 提供 2.04 TB/s 带宽，资本支出显著低于 H100 的 3.35 TB/s。将 H100 节点专用于训练、A100 节点专用于推理，机构可比全 H100 机群降低 15%-25% 的 TCO。谬误在于混淆了 作业级 同构——对防止单次分布式训练中的拖后腿至关重要——与 集群级 同构。成熟调度器能有效管理异构机群，将带宽密集型推理作业路由至旧硬件（其带宽性价比仍具竞争力），将峰值算力节点保留给训练吞吐。

谬误：最后一公里只是次要安装细节。

物理基础设施工程中的关键约束与陷阱

工程团队往往将 90% 的规划精力投入到硬件选型和机房设计上，默认机架安装和堆叠是确定性的商品化任务。现实中，最后一公里——物理安装服务器、布线、注入冷却液、运行烧机测试——经常使生产可用性延迟 2-4 个月。我们的 175B 模型集群涉及数千根线缆；单根松动的 InfiniBand 连接或受损的光纤线缆，就能使有效分割带宽下降 50%，导致分布式训练停滞。GPU 驱动版本与 InfiniBand 交换机固件之间的固件不兼容、BIOS 中的 NUMA 错误配置等隐蔽问题，往往只在持续负载下才会显现。经验丰富的基础设施团队会专门预留总项目时间线的 15-20% 用于调试和烧机，运行合成压力测试（NCCL-tests、HPL benchmarks）数周，以在调度任何生产作业前清除“早期失效”故障。

陷阱：将调试和烧机视为进度缓冲

调试是系统构建的一部分，而非硬件交付滞后时可消耗的缓冲。烧机测试、线缆验证、固件认证、热浸泡和 NCCL 压力运行，是节点、机架、网络和设施层首次作为一台整机协同工作的时刻。压缩该阶段会将安装缺陷转化为生产故障，此时每次调试周期都会使整个机队空转，而非仅限于小规模的验收测试窗口。

总结

机器学习的物理基础设施跨越从晶体管到数据中心，以训练 175B 参数模型为贯穿实例，将每个概念落地为定量现实。本章的核心教训是一个约束级联：加速器功耗决定机架散热，机架密度决定 Pod 布局，Pod 拓扑决定扩展效率，扩展效率决定经济账是否合算。

该级联始于加速器。矩阵乘法负载需求 Tensor Core 和收缩阵列；权重流式传输暴露了内存墙并推动了 HBM；超出单芯片容量的模型状态要求多加速器节点和 NVLink。它延伸至服务器之外：同步训练产生功率瞬变，超过 100 kW 的机架密度强制液冷，Pod 级通信决定更多 GPU 是加速训练还是仅在等待网络。

两大分析主题串联这些细节。通用性税 在每一层反复出现：加速器以控制灵活性换算力吞吐，网络以任意互联灵活性换负载专用效率，散热系统以通用风冷换贴合密集机架的液冷回路。Section 2.3.2 引入的屋顶线模型提供了通用诊断任务：识别各边界上的有用工作是受限于计算还是数据移动。

由此产生的层级结构镜像了仓库规模下的经典内存层级。HBM 速度快容量小，NVLink 节点内快，InfiniBand 跨节点较慢，分布式存储最慢但容量最大。Section 2.4.1 引入的带宽层级因此决定了并行层级：张量并行映射到 NVLink，流水线并行映射到机架本地网络，数据并行跨越整个 Pod。软件参数如精度、检查点间隔、批大小和梯度累积并非独立旋钮；它们是对这些物理极限的响应。

我们的 175B 参数模型作为持久的架构驱动函数，连接了该层级的每一层。在加速器层面，处理单个 Token 需约 3500 亿次浮点运算，但在 Tensor Core 上算力并非限制资源。在内存层面，350 GB FP16 权重张量超出单加速器 HBM 容量，且在为服务分片或压缩后会饱和 HBM 带宽；以 3.35 TB/s 流式传输这些权重，在单加速器等效 HBM 路径上产生超过 100 ms/token 的带宽下限延迟。在节点层面，完整训练状态（含权重、梯度、优化器状态、激活值）膨胀至 2 TB 以上，打破了单芯片 80 GB 的极限，要求张量并行、数据并行分片和内存卸载。在机架层面，32 个此类加速器各消耗 700 W，加上主机 CPU、内存和网络开销，需要 33.5 kW 供电和液冷基础设施。在 Pod 层面，在可行的两周窗口内训练要求跨无阻塞 InfiniBand 网络同步 1000 余张 GPU，硬件故障的统计必然性强制采用以算力换可靠性的检查点策略。在经济层面，突发性云租赁可优于自建，而自建集群仅在持续利用率足以摊销硬件、电力、散热和设施风险时才具吸引力。本章每一个约束——从 HBM 总线宽度到数据中心网络拓扑——均追溯至单一算术事实：该模型无法装入单芯片。

实用方法超越此特定模型。识别各层面的约束瓶颈，量化其影响，并将后果向上传播通过技术栈。若散热基础设施无法带走热量，选用最快加速器适得其反；若电网无法满足需求，构建最密机架徒劳无功；若负载通信模式不使用带宽，部署最宽网络浪费资源。基础设施工程因此是最纯粹的系统工程：一门关于芯片级选择如何改变机架功耗、设施散热、网络拓扑、可靠性策略和总拥有成本的定量学科。

通用性税：加速器通过将硅面积专用于矩阵运算而非分支预测和乱序执行，实现比 CPU 高 10-100 倍的吞吐。代价是灵活性降低。从 GPU 到 TPU 再到定制 ASIC 的每一步，都为运算夺回更多晶圆面积。
内存墙诊断始于屋顶线：对单请求 LLM 推理，内存带宽决定延迟，因为运算在微秒级完成而数据传输耗毫秒级。脊点（I[ridge] = peak FLOP/s / memory BW）将内存受限的 LLM 解码（I ≈ 1）与计算受限的训练（I > 2,000）分开。
带宽层级决定并行主义：NVLink 与 InfiniBand 间每方向 9 倍的带宽悬崖，将张量并行限制在节点内，数据并行限制在节点间。当模型深度超出单节点容量时，流水线并行跨越节点。
峰值与持续：大规模训练的模型 FLOPs 利用率（MFU）达到 40-50% 即视为良好。产能规划必须使用持续吞吐，而非峰值规格。
设施效率是计算机的一部分：液冷可将 90-95% 的设施功率交付给计算，而风冷设施仅 50-65%。Pod 规模下，网络拓扑、散热架构和供电必须为主导负载协同设计。
规模化故障：10,000 GPU 集群约每 5 小时发生一次 GPU 故障。检查点策略是一阶性能关切，必须从一开始就设计进系统。

全生命周期成本胜过采购价：拥有成本包括电力、机房建设、网络和人员，不仅仅是采购价，因此只有当利用率超过某个阈值时，自建基础设施才划算——而这一阈值光看硬件价格永远看不出来。第 12.3 节详细推导了自建与采购的盈亏平衡点，以及车队在运行和付费环节下的全成本。

在计算机发展的大半历史里，计算机等同于芯片。本章标志着这一认知的终结。一旦模型无法装进单张加速器，一个事实就会向上层层传递：芯片决定节点功耗，节点决定机柜散热，机柜决定 Pod 拓扑，拓扑决定经济账能否算得通。没有哪一层能孤立调优，因为每一层都继承了下一层的限制。在这个规模下，计算单位不再是处理器，而是楼宇，这也是为什么本卷剩余部分将数据中心——而非 GPU——视为被设计的那台机器。

我们已将物理基础设施从张量核心晶体管映射到兆瓦级数据中心变电站。然而，一堆互不相连的节点还不是一台计算机；它只是一座堆满昂贵加速器的仓库。网络结构（network fabric）通过在节点间传递梯度、激活值和检查点，将这些节点变成一个统一的训练系统。本书反复揭示同一个约束：通信带宽限制了扩展效率。带宽层级显示 NVLink 与 InfiniBand 之间存在 9× 的断崖，拓扑示例表明结构设计能让 AllReduce 时间变化 2–3×。第 3 章将考察物理层、协议、集合通信和拓扑决策，它们决定了一万卡集群表现为一台协同的机器，还是成千上万台孤立的设备。

此处内容旨在确保在章节开始前正确插入测验。

针对目标负载，团队应如何决定下一美元该买 FLOP/s、HBM 带宽、网络容量还是机房电力？
同一模型为何在训练和推理阶段需要不同的加速器选择？
是什么让数据中心——而非加速器——成为相关的计算单位？
在加速器、ASIC、晶圆级系统、CXL 和先进封装之间，何时专用化值得以灵活性为代价？

网络结构

目的

为什么在大规模下，连接加速器的网络比加速器本身更重要？

单张加速器每秒可执行数万亿次运算，但分布式训练要求这些运算跨数千设备协同。每个同步点——无论是梯度平均、激活交换还是参数更新——都取决于网络带宽和延迟。当网络容量跟不上加速器吞吐时，加速器会因等待数据而空闲，继续增加加速器反而会恶化问题而非改善。在足够大的规模下，网络设计主导系统性能：拓扑决定哪些通信模式高效，带宽决定模型能被切分到多大，延迟决定训练能多紧密地耦合。把网络当事后补救的组织会发现，其昂贵的加速器只能交出理论性能的一小部分，因为网络成了没人规划的瓶颈。用 C³ 术语说，结构（fabric）是通信税征收之地：其拓扑和带宽设定了通信在车队范围内对计算的约束程度。

使用 α-β 框架建模网络通信成本，识别带宽主导与延迟主导两种模式
从延迟、无损保证、运维复杂度等维度对比高性能传输协议
通过计算 BW[bisect] 和 ML 集合通信模式的跳数，分析网络拓扑（胖树、轨道优化、龙蝇）
评估拥塞控制机制及其对分布式训练尾部延迟的影响
利用设备共享和流量隔离，为多租户 GPU 集群设计网络虚拟化策略
运用 RDMA 计数器、链路级遥测和带宽测试工具，诊断网络性能瓶颈

同步骨干

一条慢链路会拖垮所有等待它的对端。

设想一个 1750 亿参数语言模型分布在 1024 张 GPU 上，稠密加速器节点若不能作为一台机器同步，便不再有用。每个训练步都需要对 350 GB 梯度数据做 AllReduce，意味着每张 GPU 必须收发完自己的份额，下一步才能开始。如果结构中哪怕一条链路变慢，其余 1023 张 GPU 都要等待。网络结构不是辅助设施；它是决定该集群高效训练还是白白浪费数百万闲置算力美元的同步骨干。350 GB 数值源自贯穿车队示例的模型规模与梯度体量假设。

在图 1.13 所示的车队栈中，结构将孤立的加速器节点变成连贯的训练系统。加速器、供电、散热、机柜、Pod 定义了各节点孤立时能算多少；结构决定节点能否在通信成本淹没计算前协同行动。图 3.1 将该设计空间组织为五个相互依赖的层级，从物理信令到集群级编排。图中缩写即路线图：每个机制在成为约束瓶颈时被定义。

图 3.1：面向 ML 训练的五层网络模型：五个分层级跨越从物理导线到集群级设计。第 1 层，导线与链路：PAM4/NRZ 信令、SerDes、DAC、AOC、可插拔光模块、以太网与 InfiniBand 链路层。第 2 层，传输：RDMA、GPUDirect、RoCEv2、零拷贝 DMA 及 α-β 通信模型。第 3 层，交换机与拓扑：胖树、轨道优化、龙蝇、自适应路由。第 4 层，结构行为：PFC、DCQCN、HPCC 拥塞控制、自适应路由、Incast 处理。第 5 层，集群设计：NVIDIA SuperPOD、Meta Grand Teton 等生产级结构集成。

在大规模下，通信成本可主导计算成本。公式 1.3 中的车队定律直白地指出：非重叠通信项 Tcomm − T[overlap] 决定了每个训练步有多少暴露给网络结构。结构通过决定通信能否重叠、哪些集合算法可行、网络分区如何与节点故障交互，约束了栈中它之上的每一层。

物理网络结构旨在承载三种基本集合通信模式：

AllReduce：AllReduce²⁷ 在数千张 GPU 间求和梯度，使每张设备持有相同的平均值，构成同步训练的心跳。
AllGather：AllGather²⁸ 收集不同的模型分片，使每张 GPU 能重建完整模型状态。
AllToAll：AllToAll²⁹ 是最苛刻的模式，要求每张 GPU 向其他每张 GPU 发送唯一数据，这对专家并行至关重要。

ML 网络如何颠覆数据中心假设

第 6 章阐述了编排这些模式的算法；而网络结构层提供了承载这些模式的线缆和交换机的物理特性。这种区别至关重要，因为网络结构的物理属性（带宽、延迟和拓扑）决定了哪些模式是高效的，哪些会成为瓶颈。

在单台机器中，内存总线负责在处理器和内存之间移动数据。在分布式训练集群中，网络结构扮演着类似的角色：它是移动工作节点间参数更新的梯度总线。正如第 2.3 节所述的“内存墙”限制了单设备吞吐量，网络结构带宽决定了多设备吞吐量（“通信墙”）。协议、拓扑、拥塞控制和集体路由选择共同决定了这条总线能在多大程度上逼近其物理极限。

将节点内通信与节点间通信分隔开的具体带宽悬崖，使这一梯度总线的类比变得精确。第 2 章确立了单颗 H100 提供 989 TFLOP/s 的 FP16 吞吐量和 3.35 TB/s 的内存带宽。在节点内，八颗此类加速器通过 NVLink 通信，聚合双向带宽达 900 GB/s。然而，一旦计算跨越节点边界，可用的单向带宽就会下降 9 倍，从 NVLink 的 450 GB/s（双向链路的一个方向）降至 50 GB/s（每端口 NDR InfiniBand）。这一悬崖，即从节点内通信到节点间通信的转变，是网络结构设计的核心挑战。附录 C.2 节汇总了规范的 NVLink 和 InfiniBand 带宽规格，以及锚定这些数据的 1K-GPU 集群参考配置。对于我们的 175B 模型，通过 50 GB/s 的链路移动 350 GB 的梯度意味着单次 AllReduce 就可能耗时数秒，除非网络结构和集体算法能将该传输与计算重叠，否则集群中的每个 GPU 在此期间都将处于空闲状态。图 3.2 通过在对数坐标上绘制四代 GPU 通信层级各级的带宽，使这一层级关系具体化。

![](https://github.com/OpenDocCN/dsai-notes-pt3-zh/tree/master/docs/hav-cs249r-mlsys-vol2/img/file48.svg)

图 3.2：带宽层级：四代 GPU 通信层级中四个层面的带宽，采用对数刻度。虽然从 V100 到 B200，HBM 和 NVLink 带宽分别增长了约 9 倍和 6 倍，但 InfiniBand 仅增长了 4 倍。标注显示了 NVLink 双向总带宽与单个 InfiniBand 端口的比率，量化了分布式训练在每个同步点必须跨越的悬崖；在同向同类比较基础上，H100 到 NDR 的悬崖约为其一半，大致 9 倍（见正文）。

图 3.2 揭示了这一悬崖并非某一代加速器的产物。其标注将 NVLink 的双向总带宽与单个 InfiniBand 端口进行比较，因此读数较大（H100 代约为 19 倍），超过了同向同类比较的悬崖倍数。按单向计算，从本地 NVLink 域跨越到单个 InfiniBand 端口会使带宽减少约 9 倍，尽管每一层级的绝对带宽都在提升。这一持久的悬崖反映了基本物理限制：片上互联（NVLink）在毫米级铜线上运行，而节点间链路（InfiniBand）跨越数米线缆且必须穿越交换机。这一比率决定了哪些并行策略是高效的。张量并行需要持续高带宽交换激活值，在节点内可行但跨节点不切实际。流水线并行和数据并行能容忍较低的节点间带宽，必须承担跨节点通信的重任。本章中的每一个拓扑和协议决策，都试图将这一层级对集体通信性能的影响降至最低。

这一比率在单个训练步骤中便清晰可见。图 3.3 使用了归一化时间线：计算阶段固定在 100 ms，AllReduce 模块代表一小块梯度分片，旨在使节点内与节点间的对比清晰可见。这并非完整的 175B 参数梯度交换；它隔离了跨越节点边界如何改变利用率。

![](https://github.com/OpenDocCN/dsai-notes-pt3-zh/tree/master/docs/hav-cs249r-mlsys-vol2/img/file49.svg)

图 3.3：训练步骤中的带宽悬崖：相同计算阶段的示意性归一化时间线：使用 NVLink（900 GB/s）的 8-GPU 节点内作业（上），和使用 InfiniBand（50 GB/s）的 64-GPU 节点间作业（下）。AllReduce 阶段（红色）从薄薄的一条变成了步骤中的主导部分。若无通信-计算重叠，GPU 在整个 AllReduce 期间将处于空闲，两种场景的利用率差距为 12.5 个百分点（99.5% 对 87%）。

这一 12.5 个百分点的利用率差距，在长达数月的训练运行中意味着数百万美元的算力浪费。因此，网络结构设计是分布式训练的核心工程挑战，而非事后补充。

ML 网络如何颠覆数据中心假设

来自大规模 Web 服务领域的网络架构师，会觉得分布式训练集群的流量模式违反直觉。传统数据中心流量的特点是海量、微小、独立且异步的流。数百万用户访问 Web 服务产生随机流量模式，这非常适合标准传输控制协议/网际协议（TCP/IP）和统计复用、超额订阅的网络。

ML 训练工作负载则截然相反：同步、周期性，且由少量大规模集体通信操作主导。这种 ML 网络反转颠覆了传统网络设计的核心假设。表 3.1 展示了实际后果：网络结构针对全局同步时间进行优化，而非平均单流吞吐量。

| 工作负载模式 | 传统数据中心假设 | ML 现实 |

| --- | --- | --- |

| 流量模式 | 异步、随机、多对多 | 同步、周期性集体操作 |

| 流类型 | 数百万个微小、短生命周期流 | 少量巨大、长生命周期“大象”流 |

| 性能指标 | 平均吞吐量、单流公平性 | 尾延迟、全局同步时间 |

| 丢包容忍度 | 可容忍（TCP 重传） | 不可容忍（单个丢包导致全局停滞） |

| 拥塞 | 局部、独立事件 | 全局、相关（汇聚拥塞/Incast） |

表 3.1：ML 网络颠覆传统数据中心假设：Web 服务要求为数百万独立流提供公平性，而 ML 训练需要一个全局同步、无损的网络结构，针对少量大规模集体操作进行优化。

正如表 3.1 所总结，同步性反转是最根本的。Web 流量是异步的；某用户的慢速连接不影响其他用户。批量同步并行（BSP）³⁰ 模型管辖分布式训练：训练作业中所有 1,024 个 GPU 必须完成梯度交换，任一 GPU 才能进入下一步。因此，最慢的链路决定了整个集群的性能。单个拥塞的交换机端口若延迟某 GPU 的数据包 100 ms，实际上就浪费了所有 1,024 个 GPU 100 ms 的计算时间。尾延迟不是异常值；它就是瓶颈。

流反转使这一问题复杂化。传统网络旨在为数百万个“鼠流”提供公平性，而机器学习训练则由少数对应梯度 AllReduce 的“象流”主导。在 1750 亿参数模型上，单次 AllReduce 可能涉及交换 350 GB 的数据。标准的流控制和路由机制（如等价多路径 ECMP）会将每个流哈希到若干等价路径中的一条，这种机制不适合此类流量模式。静态哈希无法将单个象流细分到所有可用链路上，并可能意外地将多个象流映射到同一链路，造成严重拥塞，而其他链路却闲置。

丢包反转完善了这一图景。TCP/IP 专为不可靠网络设计，通过重传优雅地处理丢包。机器学习集群中使用的基于 RDMA 的协议（InfiniBand、RoCE）假设网络结构无丢包。单个丢包可能触发 Go-Back-N 恢复，这会从丢失的包重新开始传输，而非仅修复丢失的帧，并可能使发送端停滞数毫秒，造成灾难性的 straggler（拖后腿者），延迟整个同步训练步骤。因此，机器学习网络结构必须针对零丢包进行设计。InfiniBand 使用基于信用的流控制；基于以太网的 RoCE 部署使用经过精心调优的优先级流控制 PFC，这是一种链路层背压机制，在缓冲区溢出前暂停发送端，因此依赖于足够的交换机缓冲。

这些反转解释了为何在标准企业以太网网络上运行大规模分布式训练效率低下或不可能。机器学习的网络结构是一个分布式、高性能的“总线”，用于集合通信，从头设计用于同步、大规模并行的独特物理特性。

五层模型

每一种反转都可追溯到特定的物理或协议约束。针对高性能互联的五层模型使这些约束具体化：

第 1 层：线缆与链路（第 3.3 节）。信号完整性（PAM4、SerDes）和光纤中的光速对延迟和集群几何施加硬约束。
第 2 层：传输层（第 3.4 节）。InfiniBand 和 RoCE 提供 RDMA 原语；$\alpha$-$\beta$ 模型量化了不同消息大小的延迟与带宽权衡。
第 3 层：交换机与拓扑（第 3.5 节）。Fat-tree、轨优化设计和蜻蜓拓扑通过不同的结构权衡实现全局集合通信所需的 BW[bisect]。
第 4 层：网络结构行为（第 3.6 节）。拥塞控制机制（如 DCTCP 风格的显式拥塞通知 ECN 响应、DCQCN 和 HPCC）决定理论带宽是否转化为实际吞吐量；自适应路由和 incast 行为决定该吞吐量能否在真实集合流量下生存（Alizadeh 等 2010；Zhu 等 2015；Li 等 2019；Gangidi 等 2024）。
第 5 层：集群设计（第 3.7 节）。NVIDIA SuperPOD 和 Meta Grand Teton 等生产超级计算机将这些层整合为统一的梯度总线（NVIDIA 2023；Meta Engineering 2024）。

这些层级不仅是网络主题的清单；它们是将同步机器学习流量转化为基础设施需求的因果链。大梯度消息首先考验线缆和传输层，接着迫使拓扑选择以保护剖分带宽，继而暴露出普通企业网络可隐藏的拥塞行为，最终决定整个集群是否表现得像一台训练机器。

本章其余部分将沿此栈向上攀登，从底层的铜缆与光纤起始。登顶后，章节将转向生产环境中围绕网络结构的运营层：跨租户共享、负载下观测、以及随底层技术提升上限而演进。

第 1 层：线缆与链路

在分析协议和拓扑之前，我们必须了解物理介质。每一个网络设计决策最终都受限于线缆能承载什么。在 400 Gb/s 及以上速率下，信号传输的物理特性对缆长、功耗和误码率施加硬性限制。这些不是工程不便；它们是塑造集群几何的基本约束。

信号完整性与 PAM4

PAM4 信令是高速机器学习集群网络结构中使用的一种电调制方案，每个符号周期用四个不同电压电平编码两比特，在不提高符号率的前提下，将给定物理介质上的数据率提高一倍。

重要性：PAM4 实现了维持大规模梯度同步所需带宽的 400 Gb/s 和 800 Gb/s 链路速率。然而，电压电平间间隙缩小增加了对噪声的敏感度，需要前向纠错 FEC，通常为 Reed-Solomon RS(544,514)，这在常见高速以太网讨论中每链路增加约 100 ns 的主机侧 FEC 处理延迟（Anslow 2016；Yin 等 2022）。在三层 fat-tree 中（每向三跳），仅 FEC 就可能为每个包贡献数百纳秒的固定延迟，为网络结构每条消息的固定启动延迟设定硬性下限，即第 3.4.4 节形式化的通信成本模型中的 $\alpha$ 项。
区别：与仅用两个电压电平、提供更好噪声裕度但每通道数据率受限于一半的 NRZ（不归零）二进制信令不同，PAM4 以需在每端口进行 FEC 为代价，用信噪比换取带宽密度——同一铜迹承载双倍数据。
常见误区：常见误解认为每符号翻倍比特是免费的吞吐增益。PAM4 链路要求两端均进行 FEC，使其根本上比等效 NRZ 链路延迟更高；像 AllReduce 这种延迟敏感型集合通信在每个包上都要支付这笔 FEC 税，无论消息大小。

为达到 400 Gb/s，我们不能仅通过更快翻转电压来实现。铜缆中的信号衰减和光纤中的色散对符号率（每秒信号跳变数）施加硬上限。高速链路通过 PAM4 在每次跳变中封装更更多信息来克服这一点。

然而，与 NRZ 相比，PAM4 相邻电压电平之间的间隙缩小了三倍，这使得链路极易受噪声影响。因此，高速链路工作在可靠检测的物理极限附近，要求在物理层实施前向纠错（FEC），高速以太网设计中常用 RS(544,514) 系列里德-所罗门码（Anslow 2016；Ethernet Alliance 2025）。FEC 处理是一个与实现相关的延迟项；IEEE 802.3df 运营商资料将约 100 ns 的主机 KP4 FEC 和数百纳秒的端到端模块延迟视为 AI/HPC 网络时间尺度下有意义的指标（Yin et al. 2022）。对于我们的 175B 模型训练，其每步在 1,024 块 GPU 上产生 350 GB 的梯度流量，这种延迟下限是不可妥协的。数据包在胖树拓扑中跨越三级交换机跳数，会产生单向 FEC 解码和编码延迟 300 ns–600 ns 的场景预算，或双向三跳路径 600 ns–1200 ns 的延迟。这种“物理税”设定了网络固定启动延迟的硬性下限，在第 3.4.4 节中被形式化为 α 项，无论软件如何优化，都限制了 AllReduce 等对延迟敏感的集合通信操作的速度。图 3.4 直观展示了这种信令权衡：PAM4 相较于 NRZ 将每符号位数翻倍，但更小的电压间隙降低了噪声裕量，使 FEC 成为链路延迟下限的一部分。

![](https://github.com/OpenDocCN/dsai-notes-pt3-zh/tree/master/docs/hav-cs249r-mlsys-vol2/img/file50.svg)

图 3.4：信令演进：NRZ 对比 PAM4：为在不加倍时钟频率的情况下提升带宽，高速互连从 NRZ（2 个电压电平，每符号 1 比特）演进至 PAM4（4 个电压电平，每符号 2 比特）。权衡在于噪声裕量降低：信号“眼图”变小，这使得前向纠错（FEC）成为必需，并增加了网络不可消除的 α 延迟。

传输距离与介质：铜缆对比光缆

物理介质的选择决定了链路在延迟、功耗和成本重塑集群几何结构之前能传输多远。表 3.2 从决定各介质适用位置的属性出发，对比了常见的线缆和光模块选项。

| --- | --- | --- | --- | --- |

表 3.2：线缆与光模块部署权衡：常见互连介质占据不同的传输距离、延迟和成本坐标，因此集群设计者在机架内使用铜缆，而在距离开始主导布局决策时改用光缆。

对于光链路，前向纠错（FEC）³² 是延迟预算的一部分，这使得传输距离成为一个拓扑决策，而非简单的线缆选择。表 3.2 中的对比是集群几何权衡的缩影：铜缆廉价且低延迟，但迫使加速器紧凑部署；光互连以更高功耗和延迟为代价延展行或 Pod；只有当拓扑需要距离胜过单跳最小成本时，才会采用可插拔光模块触达核心层。

在 ML 集群中，距离就是金钱。一个 10,000 GPU 的集群仅在脊椎层就需要约 20,000 条光链路。按每个 $500、每个可插拔链路 20 W 计算，这意味着仅收发器就需要 1,000 万美元的布线成本和 400 kW 的持续功耗。成本决定了集群几何结构：架构师将加速器尽可能密集地堆叠（单机架 70–100 kW），以最大化廉价铜缆的使用并最小化昂贵的光模块。

SerDes、链路预算与功耗

每个端口都依赖一个串行器/解串行器（SerDes）电路，将来自交换机 ASIC 的并行数据转换为串行流。随着带宽扩展，这些电路已成为网络结构中主要的功耗来源。以我们的 1,024 GPU 集群为例：为 350 GB 梯度流量维持满 BW[bisect] 需要约 3,000 条高速链路。若每个 400 Gb/s 端口消耗 25 W（SerDes 与光收发器功耗之和），仅互连一项就持续抽取 75 kW——集群功耗预算的 10.5% 仅用于搬移比特，而非计算。

链路预算是信号衰减的严格分贝（dB）额度，它决定了这些链路的传输距离。信号穿过铜缆时，因趋肤效应和介质吸收而损耗能量。链路预算等于发射端输出功率与接收端灵敏度极限之差。对于标准 50G PAM4 通道，预算可能为 30 dB。若 3 米 DAC 线缆引入 18 dB 损耗，连接器再增 2 dB，尚余 10 dB 余量。然而，当频率加倍以支持 100G 通道（用于 800 Gb/s 端口）时，单位长度损耗急剧上升。物理规律迫使残酷权衡：为在不超功耗预算前提下维持信号完整性，线缆传输距离必须缩短。800 Gb/s 运行的铜缆链路限制在约 1–2 米，这物理上约束了计算机架的直径，并强制任何出机柜连接采用昂贵、大功耗的光模块。在 1.6 Tb/s 级规划场景中，SerDes 和光功耗可占集群能耗的很大比例，使每比特功耗成为主要扩展约束。布线设定了传输距离和速率的硬性上限；传输层必须在这些物理链路之上构建可靠的通信原语。

第 2 层：传输层与性能模型

大规模训练需要持续、同步的批量传输。一次跨越 1,024 块加速器的 AllReduce 操作可能搬运 TB 级梯度数据。这种模式要求网络针对远程直接内存访问（RDMA）进行优化以消除 CPU 开销，并要求无损传输以确保性能可预测。

RDMA 与 GPUDirect

远程直接内存访问（RDMA） 是 ML 训练网络中采用的一项网络技术，它允许一台机器直接读写另一台机器的内存，通过将传输处理卸载到网卡，绕过双方的操作系统内核和 CPU。

意义：RDMA 将端到端消息延迟从内核 TCP 典型的 50–100 μs 降至约 1–2 μs，按 25–50× 幅度削减铁律中的 L[lat] 项。对于在 1,024 块 GPU 间交换 350 GB 梯度数据的 175B 参数模型，RDMA 通过 GPUDirect RDMA 允许网卡直接读取 GPU 内存而无需经由主机内存暂存，每步还能消除 700 GB 的冗余内存拷贝。
区别：与传统 TCP/IP 不同，后者要求 CPU 通过内核网络协议栈处理每个数据包（饱和一个 400 Gb/s 链路需消耗数十个 CPU 核心），RDMA 将整个传输层卸载到专用网卡硬件，释放 CPU 去编排计算而非搬运数据。

常见误区

一个常见的误解是 RDMA 可以在任何以太网网络上可靠工作。RDMA 缺乏 TCP 的重传逻辑；单个丢包就可能导致整个 1,024-GPU 的 AllReduce 操作停滞 100–500 ms，因为 Go-Back-N 恢复机制会从丢包点开始重传。RDMA 需要无损网络结构——InfiniBand 或启用了优先级流控的以太网——才能在大规模下正确运行。

标准 TCP/IP 在架构上不适用于 400 Gb/s 时代。该协议栈设计于网络速度比 CPU 内存带宽慢几个数量级的年代，但在当前的线速下，这种关系已经逆转。通过 Linux 内核处理 400 Gb/s 数据流会带来巨大的中断开销：在用户空间和内核缓冲区之间复制负载数据可能会消耗双路服务器的全部内存带宽，仅为了填满管道就需要数十个 CPU 核心。结果是撞上了“CPU 墙”，宿主处理器成为网络流量的瓶颈，挨饿了本应服务的应用逻辑。

RDMA 完全绕过了这一层。通过将传输逻辑卸载到网卡硬件，它允许应用程序直接读写远程内存。对于机器学习，GPUDirect RDMA 将这一零拷贝原则延伸至加速器本身 (NVIDIA 2026a)。没有 GPUDirect 时，梯度更新需走一条曲折的路径：GPU 内存 → CPU 系统内存 → 内核缓冲区 → 网卡。GPUDirect 将其短路为单次 PCIe 事务：GPU → 网卡，如图 3.5 对比所示。针对我们 175B 模型的 350 GB 梯度交换，该优化每步消除了集群中 700 GB 的冗余内存拷贝，降低了延迟，并释放 CPU 去编排复杂的流水线逻辑，而非充当数据搬运工。

图 3.5：GPUDirect RDMA 数据路径：传统路径与 GPUDirect 路径的对比。传统 RDMA（上）要求在传输至网卡前将数据拷贝至主机内存。GPUDirect RDMA（下）使网卡能通过 PCIe 总线直接访问 GPU 内存，消除冗余拷贝并降低批量梯度传输的延迟。

InfiniBand 和 RoCE

GPU 集群通常在两种 RDMA 传输栈之间选择，该决策是可靠性与运维的权衡。表 3.3 对比了每种栈将无损和拥塞控制的负担放在何处。

| --- | --- | --- | --- |

| RoCE (RDMA over Converged Ethernet) | RoCEv2 通过在 UDP/IP 数据包中封装 InfiniBand 传输头部来承载 RDMA 语义 | 必须通过优先级流控 (PFC)、ECN、感知工作负载的路由或准入控制来逼近 InfiniBand 的原生无损特性 (Guo et al. 2016; Gangidi et al. 2024) | 可承担更多拥塞控制调优工作的多厂商以太网集群 |

表 3.3：RDMA 传输栈权衡：InfiniBand 和 RoCE 通过不同的运维契约暴露 RDMA 语义，一个围绕原生无损构建，另一个围绕以太网兼容性构建。

InfiniBand 行反映了一种协议传承，它倾向于硬件管理的无损特性而非以太网兼容性。

这种栈的选择在协议边界处可见。图 3.6 对比了这两种栈，展示了基于 RDMA 的协议如何暴露用户空间 Verbs API 以绕过内核的传统 TCP/IP 栈。

图 3.6：传统 TCP/IP 与 RDMA/RoCE v2 栈对比：并排比较。传统 TCP/IP（左）遍历应用、操作系统内核（上下文切换）、Socket API、TCP/UDP、IP/以太网和网卡，延迟为 10–20 μs，需 2–3 次 CPU 拷贝。RDMA/RoCE v2（右）暴露用户空间 Verbs API 绕过内核，将传输卸载至 RDMA 网卡（GPUDirect 直接读取 GPU HBM），延迟为 1–3 μs，零拷贝 CPU 开销。

无损与 Go-Back-N 问题

图 3.6 的关键启示是 Verbs API 提供了统一的编程模型，但其下的可靠性保证有本质区别：InfiniBand 在硬件层面强制无损，而 RoCE 必须利用 PFC 和 ECN 从以太网的尽力而为基础上构建无损。ML 集合操作假设有序、无损的交付，但这种可靠性的硬件实现引入了关键的脆弱性。TCP 通过选择性确认优雅地处理丢包，仅重传特定的缺失段。相比之下，RDMA 协议（如 RoCEv2）在极少数丢包发生时通常依赖更简单的恢复路径，如 Go-Back-N 重传 (Gangidi et al. 2024)。网卡的物理约束驱动了这一选择：为无序包实现复杂的重组逻辑需要大量片上 SRAM，这会消耗宝贵的芯片面积，而该面积原本用于 SerDes 模块和数据包处理引擎。网卡硬件针对吞吐量优化，而非状态管理。

这种权衡在失败时带来严重惩罚。如果网络交换机在 1 GB 梯度传输的 900 MB 处丢掉单个数据包，接收方将丢弃所有后续包，迫使发送方重传整个消息尾部，可能因单个丢帧而重传 100 MB 数据。在 400 Gb/s 下，这种重传触发的延迟峰值比线路延迟大几个数量级。在同步训练循环中，数千个 GPU 等待最慢成员，单个丢包就会导致整个集群空闲。网络结构因此必须表现为无损介质，通过优先级流控 (PFC) 将流控复杂性推给交换机，确保缓冲区永不溢出。

考虑一个 2,048-GPU 的训练集群，它将同时运行大语言模型训练（数 GB 级梯度消息）和强化学习（频繁的小控制消息）。

α‑β 性能模型

协议选择决定了网络结构能否表现为无损介质；性能建模进而询问该介质能以多快速度传输给定消息。α‑β 模型将消息传输时间分解为 T(n) = α + n/β，其中 α 为固定启动延迟，β 为持续带宽 (Hockney 1994)。D.1 节给出完整推导，并通过具体消息规模演示模型，区分延迟主导与带宽主导的传输；6.2.1 节稍后将同一分解应用于集合通信算法。拓扑选择直接影响这两个参数：Fat-tree 通过提供长度相等的最短路径来最小化 α，而环形拓扑随着参与者数量 N 增加会放大 α，因为消息遍历的跳数随之增长。

该模型揭示了两种需要不同工程响应的区域。对于满足 n < α·β 的消息，启动成本 α 主导传输时间；小控制消息和流水线气泡落入此延迟主导区域。对于满足 n > α·β 的消息，n/β 项主导；梯度 AllReduce 落入此带宽主导区域。

对于 α ≈ 1.5 μs 且 β ≈ 50 GB/s 的 NDR InfiniBand，交叉点 n^* = α · β ≈ 75 KB。小于此值的消息从更多带宽中获益甚微；大于此值的消息从更低延迟中获益甚微。该交叉点将两种根本不同的优化策略分开：减少跳数以降低 α，或增加链路带宽以提高 β。将该模型应用于我们的 175B 训练作业每次迭代产生的具体消息大小，使这种区分具有可操作性。

问题：网络架构师正在对比 InfiniBand NDR (1.5 μs, 50 GB/s) 与较慢的以太网基线 (5 μs, 12.5 GB/s)。对于 4 KB 控制消息和 350 MB 梯度分片，T(n) = α + n/β 的哪一部分占主导？为什么更快的网络在两个区域中以不同原因提供帮助？

数学计算：对 4 KB 控制消息和 350 MB 梯度分片应用 T(n) = α + n/β。

小消息 (4 KB)：
- InfiniBand: 1.5 μs + 4 KB / 50 GB/s = 1.5 + 0.08 = 1.58 μs
- 以太网: 5.0 μs + 4 KB / 12.5 GB/s = 5.0 + 0.32 = 5.32 μs
- 结果：InfiniBand 快 3.4 倍，纯粹归因于更低的 α。
大消息 (350 MB)：
- InfiniBand: T = α + n/β = 7.0 ms
- 以太网: T = α + n/β = 28.01 ms
- 结果：InfiniBand 快 4 倍，纯粹归因于更高的 β。

系统洞察：对于大规模训练，交叉点 (n^* = α·β) 通常在 75 KB 左右。由于梯度大小为兆字节到千兆字节，我们几乎总是处于带宽主导区域。然而，流水线并行和分布式协调依赖延迟主导区域的小消息，在该区域线速升级零收益，仅拓扑和跳数减少有效。

要了解这种区分在实践中 为什么 重要，考虑我们的 175B 模型训练作业每次迭代发送的两条消息。第一条是 4 KB 流水线调度控制消息，协调流水线阶段间的微批次传递。应用模型：T(n) ≈ 1.58 μs（控制消息）。带宽项仅贡献总时间的 5.1%。将链路速度翻倍仅能节省可忽略的微秒分数。对于此消息，最直接减少传输时间的方法是减少跳数（降低 α），而非购买更快链路。

第二条消息是某层 AllReduce 的 350 MB 梯度分片。此时：T(n) ≈ 7.0 ms。延迟项不可见。将带宽翻倍至 100 GB/s 将传输时间减半，获得直接且成比例的收益。这两个案例说明了 为什么 网络设计必须同时解决 α 和 β：拓扑和跳数控制延迟主导区域，而链路速度和路径多样性控制带宽主导区域。

图 3.7 使这两个区域在完整消息大小范围内可见。对于 InfiniBand，交叉点发生在约 75 KB：小于此值的消息为延迟主导（左侧平坦区域），大于此值的消息为带宽主导（右侧线性区域）。Ethernet RoCE 交叉点略早，约 62.5 KB，因其较低的单链路带宽使传输项在更小消息大小时超越更高的固定延迟。InfiniBand 与 Ethernet RoCE 间 5 倍的延迟差距主导小消息，但对主导训练通信的兆字节级梯度传输变得无关紧要。

![](https://github.com/OpenDocCN/dsai-notes-pt3-zh/tree/master/docs/hav-cs249r-mlsys-vol2/img/file53.png)

图 3.7：α-β 交叉点：InfiniBand NDR 和 Ethernet RoCE 的传输时间随消息大小变化函数。小消息为延迟主导（平坦区域），大消息为带宽主导（线性区域）。交叉点标志着投资带宽比降低延迟开始产生更高回报的位置。

除了对单个传输分类，同一模型还能识别通信何时超过计算。上述 α-β 分析聚焦单链路单个消息的传输时间，将网络视为点对点信道。但在数据并行训练循环中，相关问题是全集群的集体 AllReduce 是否在下一计算步骤准备好前完成。当梯度向量足够大时，环形 AllReduce 的聚合传输时间超过单步计算时间，网络成为整个训练作业的节奏约束。

问题：对于训练 GPT-2 规模及以上模型的 1024-GPU H100 集群，环形 AllReduce 何时成为瓶颈？

设置：基线集群训练 15 亿参数的 GPT-2 规模模型（6 GB FP32 梯度）。每 GPU 以 989 TFLOP/s FP16/BF16 峰值计算。网络使用 NDR InfiniBand（α = 1.5 μs 和 β = 50 GB/s 每链路）。

步骤 1：每次迭代计算时间。假设每 GPU 处理合成微批次需 5.00 × 10¹³ FLOPs，选取该值使该瓶颈示例的计算阶段约 101 ms。在 989 TFLOP/s 和 50% 利用率下：

T[compute] = 101.1 ms

步骤 2：环形 AllReduce 通信时间。以 N = 1024 和约 6 GB 的梯度负载 M：

环形成本模型：$T_{\text{ring}} \approx \frac{2(N-1)}{N}\frac{M}{\beta} + 2(N-1)\alpha$；第 6 章推导了该表达式背后的算法步骤。
总通信时间：T[ring] ≈ 242.8 ms

步骤 3：通信占比。通信占比 = 70.6%

通过计算与通信重叠（因反向传播逐层产生梯度而成为可能），有效开销可降低，但网络已成为此配置下迭代时间的主要贡献者。

在 700 亿参数（280 GB 梯度）下，若单 GPU 计算通过批次大小缩放保持相似，带宽项成为瓶颈：

T[ring] ≈ 11192.1 ms

现在纯数据并行下通信主导计算。我们的 175B 模型远超此规模，瓶颈将更严重。超越数十亿参数的模型因此需要张量并行和流水线并行来分区模型，而非仅依赖数据并行（必须 AllReduce 完整梯度向量）。

α-β 模型量化了单链路速度，但我们的 175B 参数模型需要 1,024 GPU 协同工作。将这些传输原语从一对节点扩展到仓库级超级计算机，需要 网络拓扑：一种特定连接模式，在最小化全局集体操作的跳数和布线成本的同时最大化 BW[bisect]。

Level 3: 交换机与拓扑

交换机的物理排列决定了分叉带宽 BW[bisect] 以及网络是否为非阻塞。这两个属性决定了网络对主导分布式训练的全局通信模式的支持程度，这一约束由分叉带宽定理（原理）捕获。

第一个属性，分叉带宽，量化了拓扑在交换层级最窄点的横截面容量对全局集体操作施加的最坏情况吞吐上限。集群边缘可拥有数千条快速链路，但如果交换层级最窄处的横截面容量不足，仍会使 AllReduce 操作饥饿。

分区带宽

分区带宽 是一种网络拓扑指标，定义为横跨任何将集群划分为两个相等部分的分区的最小聚合链路容量，代表了诸如 AllReduce 这类全对全通信模式的最坏情况吞吐量上限。

重要性：分区带宽 BW[bisect] 直接决定了全局同步的集群级带宽上限。一个拥有 1,024 个 GPU、400 Gb/s 链路且 1:1 无超配比的 Fat-tree 提供 BW[bisect] = 512 × 50 GB/s = 25.6 TB/s（单向）；若采用 4:1 超配的脊叶交换机，该值将降至 6.4 TB/s，导致每个 AllReduce 步骤变慢 4 倍，使网络成为主导性的“铁律瓶颈”，而非加速器。
区别：与聚合带宽（所有边缘链路速度之和，即使在连接不良的拓扑中也可能很高）不同，BW[bisect] 衡量的是全局连通性——一个拥有 1,000 条边缘链路全部汇聚到一个中心交换机的星型拓扑，虽然聚合带宽很高，但其 BW[bisect] 却受限于该交换机的背板容量。
常见误区：一个常见的误解是增加叶子交换机总能提高 BW[bisect]。在三层 Fat-tree 中，如果脊叶层超配（每个 Pod 交换机的上行链路少于下行链路），无论存在多少叶子交换机，BW[bisect] 都会低于边缘链路总和。

对于 ML 训练这种以全对全通信为标准的场景，充足的 BW[bisect] 是基础要求。如果网络结构不足，每个同步步骤都会在最窄的横截面处形成瓶颈，整个集群将在梯度缓慢传输期间处于空闲状态。

分区带宽是一项指标；而在任意流量模式下提供满额 BW[bisect] 的拓扑属性，则是非阻塞网络。非阻塞设计保证每个交换机层级的上行容量匹配或超过下行容量，从而确保没有内部争用会将横截面吞吐量降低至理论最大值以下。当网络超配时，有效 BW[bisect] 会按超配比下降，每个全局集体通信操作也会随之按比例变慢。附录 B.4.1 节展示了如何诊断通信而非计算成为约束瓶颈的区间，从而及早识别出超配的脊叶是网络结构问题，而非加速器性能问题。

非阻塞网络

非阻塞网络 是一种 ML 集群网络拓扑，其中任意输入-输出端口对的排列均可在全线速下同时通信而无内部争用，这是通过确保每个交换机层级的上行容量等于或超过下行容量来实现的。

重要性：在 ML 集群中，非阻塞网络确保来自任意加速器子集的 AllReduce 流量不会争用共享链路，从而为全局集体通信保留完整的 BW[bisect] 项。一个 2:1 超配的脊叶会将有效 BW[bisect] 减半，使全局梯度的 AllReduce 时间翻倍，并相应降低缩放效率 η[scaling]——在通信占比 30% 的工作负载中，这会损失约 23.1% 的集群总吞吐量。
区别：与 Web 数据中心常见的超配网络（上层链路被许多下层节点共享）不同，非阻塞网络为所有可能的发送方和接收方配对同时提供专用路径容量。
常见误区：一个常见的误解是非阻塞意味着零拥塞。如果多个发送方同时以同一接收端口为目标，无论内部网络容量多大，端点拥塞（Incast）仍可能发生。

Fat-tree 基于 Clos 式非阻塞网络思想构建，以提供全额 BW[bisect] (Clos 1953)，轨道优化网络以降低成本为代价牺牲了部分全局灵活性，而 Dragonfly 拓扑则在接受工作负载放置约束的前提下减少布线 (Kim et al. 2008)。这种在保证带宽与经济可扩展性之间的权衡，驱动着大规模 ML 集群的每一个拓扑决策；本节后续的拓扑对比将使这种带宽-成本权衡具体化。

机顶交换机与故障域

机顶交换机 是基础的物理聚合点，同时定义了带宽限制和集群的最小故障域。在使用标准 DGX 节点的高密度 AI 配置中，单个机架通常包含 4 个节点，每个节点含 8 个 GPU，共计 32 个加速器。ToR 交换机将这些设备连接在一起，但也造成了关键脆弱性：如果 ToR 故障，会瞬间将 32 个 GPU 从训练作业中分离，迫使全局调度器停止并从上一个检查点恢复。

为缓解边缘拥塞，网络架构师会最大化交换机的端口数，即可用端口数量。一个拥有 64 个端口的大端口数交换机，将 32 个端口作为下行连接服务器（确保 32 个 GPU 的满带宽），32 个端口作为上行连接脊叶。这种 1:1 的订阅比保证了机架级别的非阻塞性能。对于我们的 1,024 GPU 集群，物理拓扑包含约 32 个这样的机架。

同一个机架边界也决定了恢复策略。作业调度器必须具备拓扑感知以保证性能，而可靠的副本放置必须将冗余状态和替换容量置于同一机架故障域之外，以便单个机架的损坏不会导致整个训练运行中断（参见 7.9.2.3 节）。

Fat-tree (Clos) 网络

ToR 在单个机架内提供非阻塞带宽，但要将 32 个机架连接成一个集群，并在每一对可能的通信节点间保持全额 BW[bisect]，需要一种能随集群规模扩展横截面容量的拓扑。Fat-tree（也称 Clos 网络）通过在每个层级增加并行脊叶交换机来实现这一点，使聚合上行容量始终匹配流入的总边缘带宽。在此术语体系中，叶子交换机连接服务器或机架，脊叶交换机连接 Pod 内的叶子交换机，而核心交换机在需要第三层时连接多个 Pod。

Fat-Tree

Fat-Tree 是一种分层 ML 集群网络拓扑，其中并行路径的数量（因此聚合横截面容量）随交换机层级向脊叶方向增加，提供全额 BW[bisect] 以及任意两个节点间的多条等价路由 (Al-Fares et al. 2008)。

重要性：基于基数为 k 的交换机构建的 k 元 Fat-tree，在两层（Pod）配置下支持 k²/2 个主机，在三层配置下支持 k³/4 个主机，均具备全额 BW[bisect]。当 k = 64 时，两层 Pod 支持 2,048 个 GPU，三层网络支持 65,536 个主机。因为每个 AllReduce 都可以使用任意可用的脊叶路径，该网络结构能维持来自所有加速器的同时全速通信，满足全局梯度同步对 BW[bisect] 的要求。
区别：与标准树形拓扑（根节点带宽是所有叶子共享的单一瓶颈）不同，Fat-tree 用多个脊叶交换机取代每个根节点，其组合上行容量匹配总边缘带宽，从而消除了瓶颈。
常见误区：一个常见的误解是 Fat-tree 保证零网络成本。它们需要 𝒪(N log N) 个交换机和密集布线：4,000 GPU 规模的非阻塞三层 Fat-tree 需要数百个交换机和数万根光缆，仅交换硬件成本就达 2,000 万至 1 亿美元。

Leaf、Spine 和 Core 三层提供了多条等价路径，而不是单一的超额订阅根节点，这就是 Fat-Tree 创造容量保证的方式（Figure 3.8）。

Figure 3.8: Non-Blocking Fat-Tree Topology：由基数为 k 的交换机构建的三层 Clos 网络。通过确保每一层的上行链路数量与下行链路数量匹配，该拓扑在任意两个 Pod 之间提供全 BW[bisect]。Leaf 和 Spine 之间的多条并行路径使基于硬件的自适应路由能够喷射数据包并避免拥塞。

Fat-Tree³⁵ 是 ML 集群的常见默认选择，因为非阻塞设计可以提供全 BW[bisect]，这是 AllReduce 集体通信的非妥协性要求，后者需要同时进行全对全通信。网络按层级构建：Leaf 交换机（ToR）直接连接服务器，Spine 交换机互联某个局部域（称为 Pod）内的所有 Leaf，Core 交换机将多个 Pod 绑定在一起。

由基数³⁶为 k 的交换机构建的 Fat-Tree 在三层下支持 N[hosts] = k³/4 台主机，并有两种不同的两层框架，它们的区别仅在于上层被视为集群的边缘，还是视为未来 Core 层下方的汇聚层。第一种框架将两层中的每个交换机都计算为主机的线速容量。采用基数-64 交换机时，Fabric 将每个 Leaf 的一半端口用于主机，另一半用于 Spine 上行链路，从而在 Pod 内提供 k²/2 = 2,048 个主机端口。第二种框架将上层保留为汇聚层，稍后将上行链路连接到 Core 层，而不是终止主机：每个 Leaf 仍提供 k/2 个主机端口，但 Pod 现在仅包含 k/2 个 Leaf，因此每个 Pod 可达 (k/2)² = 1,024 台主机。这两个数字是相同的交换机但核算方式不同：上层是作为集群 Spine 终止，还是作为 Pod 汇聚阶段。任一框架都能轻松容纳我们的 1,024 参考集群，仅需 Leaf 和 Spine 两层。

一个具体的二分估算展示了超额订阅如何迅速转化为同步延迟。

Problem：集群设计师正在为 1,024 GPU 集群在“Non-blocking”（1:1）Fat-Tree 和“Cost-optimized”（4:1）Spine 之间做选择。在更便宜的网络上，每 GPU 100 GB 的 AllReduce 会慢多少？

Math：二分带宽（BW[bisect]）是集群两半之间的最小管道直径。

Non-blocking (1:1)：BW[bisect] = 512 × 50 GB/s = 25,600 GB/s（每个方向）。
- Time：51,200 GB / 25,600 GB/s ≈ 2,000 ms。
Oversubscribed (4:1)：BW[bisect] = 25,600 GB/s 除以 4 = 6,400 GB/s（每个方向）。
- Time：51,200 GB / 6,400 GB/s ≈ 8,000 ms。

Systems insight：在 Core 交换机上省钱会给全局同步造成 4× 瓶颈。在一台 3 亿美元的超级计算机上，如果训练有 30% 的时间用于通信，该瓶颈浪费的空闲计算时间约为 1.421 亿美元，这与 Section 3.5.2 中的二分瓶颈模型相符。对于训练而言，网络超额订阅是得不偿失的。

这种超额订阅计算将拓扑定义转化为设计规则：每一层的订阅率决定了 Fat-Tree 是否能支撑全局集体通信。

以下问题用于检验层级交换 Fabric 权衡是否清晰：

超越此规模需要采用带有 Core 交换机的三层架构，使 Fabric 能够达到 65,536 台主机，但额外的规模带来了成本和延迟。非阻塞的 k = 64 三层树在 Core、聚合和边缘层总共需要约 5k²/4 ≈ 5,120 个交换机；按每个交换机 1 万到 5 万美元计算，仅交换层就代表 5,000 万到 2.5 亿美元。Hop count 也从 Pod 内流量的 2（Leaf-Spine-Leaf）上升到 Pod 间流量的 4（Leaf-Spine-Core-Spine-Leaf），在数千个同步步骤中，这给 α 延迟项增加了序列化延迟和交换机处理时间。Rail-optimized 拓扑通过将物理布线模式与集体通信模式相匹配，同时应对这两种压力。

Rail-optimized topology

Rail-optimized 拓扑从通信模式出发，而非通用的交换机层级。在密集加速器节点中，GPU 可以按本地槽位分组为 Rail；Figure 3.9 使这种物理布线模式具体化。

Figure 3.9: Rail-Optimized Physical Wiring：在密集加速器节点（例如 DGX H100）中，GPU 被划分为对应其 PCIe 槽位的“Rail”。每个节点的 GPU 0 连接到 Switch Rail 0，GPU 1 连接到 Switch Rail 1，依此类推。这种架构确保了数据并行 AllReduce 流量（在对应 GPU 间同步）永远不会与其他并行组争夺 BW[bisect]，从而为最敏感的流量最小化 Hop count 和拥塞。

该布线模式通过专用 Rail 交换机而非共享 ToR 交换机，将节点间的对应 GPU 连接起来（GPU 0 到 GPU 0，GPU 1 到 GPU 1）。这很重要，因为数据并行创造了确定性且高度分层的通信模式，标准拓扑无法利用。当张量并行组保持在节点内时，每个副本将对应的模型分片分配给相同的本地 GPU Rank。Rank 是分布式运行时分配的工作进程或 GPU 索引，因此某节点的 GPU 0 将该分片的梯度与其他节点的 GPU 0 同步，但很少与 GPU 1 同步。Rail-optimized topology 通过将这些同 Rank 通信路径隔离到专用网络中，从物理上硬连线了这一逻辑。网络不是将节点内所有 8 个 GPU 连接到单个 ToR 交换机，而是将整个集群中所有 GPU 0 连接到专用的“Rail 0”交换 Fabric，所有 GPU 1 连接到“Rail 1”，以此类推。一个简单的 Hop count 估算显示了其收益。

Problem：一个团队正在跨 128 个节点同步按 Rank 的数据并行梯度。在标准 Fat-Tree 中，同 Rank GPU 间的每条消息遍历其源 Leaf 交换机、一个 Spine 交换机和目标 Leaf 交换机（3 次交换机遍历）。在 Rail-optimized 网络中，所有对应 GPU 位于同一个 Rail 交换机上（1 次遍历）。Rail 设计赚取了多少“Latency Dividend”？

Math：通信延迟（α）与交换机遍历次数成正比。

Standard latency：3 次遍历 × 0.6 μs = 1.8 μs。
Rail-optimized：1 次遍历 × 0.6 μs = 0.6 μs。
Result：延迟降低 3×。

Systems insight：对于同步数据并行 AllReduce（训练步每次迭代都在等待它），3× 的延迟降低是 80% 和 95% 扩展效率的区别。扩展效率界限（原理）解释了这为何重要：将网络与模型的同 Rank 流量模式物理对齐，消除了对最贪婪带宽通信的“Spine Tax”。Archetype A 集群之所以实现其性能，是因为它们是结构化的，而不仅仅是大。

这种同 Rank 延迟红利正是 Rail 模式出现在大规模 LLM 训练集群中、而不只是作为布线优化而存在的原因。Archetype A 工作负载直接利用这一结构，因为 3D 并行产生的流量模式与 Rail 布线相匹配。

Archetype A 的 3D 并行与铁路优化拓扑

Archetype A 对 3D 并行的使用产生了两种截然不同的流量模式，它们朝相反方向拉扯：(1) 用于数据并行的海量、带宽饥渴型梯度平均，以及 (2) 用于张量并行的高频、延迟敏感型激活交换。铁路优化设计确保数据并行流量在节点间仅遍历单个交换机跳数，从而将本会阻塞同步训练循环的延迟降至最低。

这种对齐带来的工程效果在集群规模上是可测量的。因为节点内的 8 个 GPU 秩在数据并行 AllReduce 期间仅与其他节点上的同秩通信，铁路拓扑将集群划分为 8 个独立的交换机网络，它们可并发运行而无竞争。

对于跨越 128 个节点的 1,024 GPU 集群，这创建了 8 个各含 128 GPU 的并行网络，使按秩的数据并行 AllReduce 流量只需穿越单个交换机跳数，而非标准胖树所需的多跳 leaf-spine-leaf 路径。对于同步数据并行所要求的频繁、带宽饥渴型梯度交换，这种延迟收益显著。然而，这种架构引入了尖锐的权衡：必须到达不同秩 GPU 的流量（如 MoE 中的专家路由、或与铁路布线不对齐的流水线阶段切换）需要跨铁路桥接。因此大型集群常采用混合方法，使用铁路优化的叶子交换机处理同秩数据并行流量，同时用全胖树脊柱桥接铁路以支持跨秩通信模式。

这些问题旨在检验工作负载特定的网络设计权衡是否清晰：

Dragonfly 与 Torus 替代方案

Dragonfly³⁷ 拓扑将交换机组织成高基数组，每个组作为一个全连通的岛屿运作。这些组通过全局光链路相互连接。这种分层结构将扩容所需昂贵的长距离线缆数量最小化，与胖树相比将布线成本降低约 50%。然而，组内带宽是无阻塞的（100%），而组间带宽通常仅为聚合注入速率的 25–50%。对于 ML 工作负载，这种过订阅基于作业放置产生了二元性能悬崖。完全适配单个 Dragonfly 组的训练作业享有全线速性能；跨越多个组的作业则受限于有限的全局带宽，可能遭受 2–4 倍的减速。因此 Dragonfly 结构需要拓扑感知调度器，将作业严格打包进组内，以避免跨越过订阅的全局链路。

Torus（环面）拓扑将每个节点直接连接到其在多维网格中的邻居，最常见的是 3D 环面，其中每个节点链接到其 6 个相邻节点（上/下、左/右、前/后）。该设计以最少的交换硬件提供全本地带宽，因为连接仅需 1–2 跳即可到达邻居。然而，全局通信需要穿越网格的直径（𝒪(N^(1/3)) 跳），导致延迟随集群规模扩展不佳。Google 为其 Tensor Processing Unit (TPU) pods 采用了此架构，因为 Transformer 训练主要由数据并行和流水线并行主导，两者均使用最近邻通信模式，自然映射到物理网格上。该局限在 Mixture-of-Experts (MoE) 中显现，后者依赖 AllToAll 通信模式。在环面上，这些随机排列拥塞网格有限的 BW[bisect]，导致性能较基于交换机的胖树下降 2–4 倍。

当为大规模部署量化这些拓扑间的权衡时，差异变得鲜明。考虑一个 4,096 GPU 集群。按本章假设的 k = 64 交换机构建的该规模无阻塞胖树，需要数百个交换机（两个 2,048-GPU pod 加一个桥接核心层）和数万根光缆，以提供 100% BW[bisect]，使任意 GPU 能以全速与任意其他 GPU 通信。连接相同节点的 3D 环面可能使用零外部交换机（依赖直连主机链路）和仅短铜缆，但仅提供 BW[bisect] 的一小部分（随 N^(2/3) 缩放）。架构选择取决于工作负载规律性。Google 的 TPU Pods 使用环面拓扑，因为其工作负载（主要是 Transformer 训练）可预测，且结构化网格高效支持映射到 3D 网格上的集体通信算法（环 AllReduce、AllGather、ReduceScatter）。通用 GPU 集群常青睐胖树，因为其工作负载更多样（从推荐系统到图神经网络），且严重依赖仅胖树能提供全 BW[bisect] 的全局 AllReduce 模式。环面节省数百万交换机成本但刚性约束软件；胖树成本更高但提供通用 AI 研究所需的通用性。

图 3.10 量化了这些常见拓扑族间的带宽与成本差异。Butterfly 柱代表多级低直径交换网络：它比全胖树使用更少级数，但其结构化路径为任意 ML 集体操作提供更少的分割带宽。

![](https://github.com/OpenDocCN/dsai-notes-pt3-zh/tree/master/docs/hav-cs249r-mlsys-vol2/img/file56.svg)

图 3.10：ML 网络拓扑：带宽与成本：柱状图对比五种拓扑在 1,024-GPU 集群上的 BW[bisect] (TB/s，左轴) 与每 Gb/s 成本 (右轴)：胖树 (25.6 TB/s, $3.0/Gb/s)、Dragonfly (20.0, $4.0)、3D 环面 (8.0, $1.5)、铁路优化 (12.8, $2.0)、Butterfly (6.4, $5.0)。胖树提供全 BW[bisect] 但每 Gb/s 成本是 3D 环面的 2 倍。

仅分割带宽分析假设单一工作负载类型。实践中，集群服务多种具有不同通信模式的工作负载，拓扑选择必须平衡其竞争需求。

网络拓扑选择决定了训练效率的上界。首先通过将各单一工作负载模式匹配到其理想拓扑来热身，再设计一个必须同时服务多种工作负载的结构。

单一工作负载选择

为混合集群设计

你正在为一个新 ML 集群设计网络，该集群将运行两种主要工作负载：(1) 使用 3D 并行（张量、流水线和数据并行）训练 175B 参数语言模型，(2) 服务严重依赖 AllToAll 通信将 token 路由至正确专家的 Mixture-of-Experts 模型。

拓扑为我们的 1,024 GPU 集群提供了通信的结构性容量，但结构本身不保证性能。当所有 1,024 GPU 同时向结构注入 350 GB 梯度流量时，理论容量与 结构行为 的现实碰撞：拥塞控制与路由动态决定该流量是顺畅流动，还是在 BSP 模型严格同步下陷入死锁。

Level 4：结构行为（拥塞、路由）

真实结构因拥塞而偏离理论全 BW[bisect]，且这种拥塞的影响在 ML 集群中与通用网络有本质不同。前文引入的 BSP 屏障正是产生差异的原因：Web 流量是随机且异步的，一个用户的 50 ms 延迟不惩罚其他数千用户，但在 BSP 下，结构中最慢的流决定整个集群的迭代时间。若 10,000 条链路中仅有一条拥塞且延迟加倍，整个超级计算机该步骤的有效吞吐率下降。在此同步机制下，尾延迟是主要性能约束，而非异常指标。

同步并行批处理（BSP）

同步并行批处理（BSP） 是一种并行执行模型，其中每个工作节点完成局部计算阶段，与所有其他工作节点交换数据，然后在全局屏障处等待，直至所有工作节点才能开始下一阶段——这使得最慢的参与者成为整个集群的性能瓶颈。

1. 重要性

BSP 使得系统效率 η[scaling] 与最慢的工作节点成正比：如果在一个拥有 1,024 个 GPU 的集群中，由于热节流或网络抖动导致某个 GPU 运行速度慢了 10%，那么该屏障将导致剩余的 1,023 个 GPU 在该步骤中被迫停滞，相当于每次迭代浪费了有效的 102 GPU-steps 的计算。按每 GPU 每小时 $3 计算，在一个 5,000 万美元的训练过程中，5% 的滞后者差距将导致大约 250 万美元的加速器空闲时间浪费。

2. 区别

与异步并行不同，异步并行允许工作节点使用来自之前步骤的过时权重继续前进，BSP 在每个屏障处强制执行全局状态更新，提供了与单设备训练在数学上等价的行为，并且具有可预测的收敛性。

3. 常见误解

一个常见的误解是，BSP 仅仅比异步模型效率低。实际上，异步训练通常需要更多的总步骤才能收敛，因为过时的梯度更新会引入噪声——在实践中，通过仔细的滞后者缓解，BSP 通常比异步替代方案在更少的墙钟小时内达到相同的损失。

这就是为什么 尾延迟（P99），而不是平均吞吐量，才是决定训练架构的指标：一个拥堵的交换机端口会导致屏障停滞，进而使整个集群停滞。因此，保持尾延迟受控的机制成为结构行为的核心关注点。

优先流量控制（PFC）

BSP 的最弱环节特性意味着即使是一个单独的丢包也可能触发重传超时，使得全局屏障在毫秒级别被阻塞——这在每个计算步骤仅需几十毫秒完成的训练循环中是一个永恒。RoCEv2 结构通过 优先流量控制（PFC） 来缓解这一问题，PFC 以无损模式运行：不是让交换机缓冲区溢出并丢弃数据包，而是在任何缓冲区饱和之前使用链路层背压机制暂停上游发送器（Guo et al. 2016; Gangidi et al. 2024）。

优先流量控制（PFC） 是 RoCEv2 机器学习集群结构使用的一种链路层机制，当端口的队列深度超过配置阈值时，通过向上游发送器发送 PAUSE 帧来防止交换机缓冲区溢出，按优先级对注入流量进行限速，而不会丢弃数据包。

1. 重要性

PFC 是 RoCEv2 RDMA 所需的无损以太网的基础。PFC PAUSE 帧必须在缓冲区溢出之前到达上游发送器，时间窗口大约为一个往返时间（在交换机之间的距离下约为 1–5 μs）。在一个 1,000 节点的集群中，一个慢速接收器可以触发 PAUSE 帧，这些帧在 10–50 毫秒内向上游传播 3–5 跳，导致数千个无关的 GPU 对之间的梯度流量被中断，使得集群吞吐量几乎降至零。

2. 区别

与标准的 IEEE 802.3 流量控制不同，后者会暂停链路上的所有流量类别，PFC 按优先级类别运行，允许对延迟敏感的控制消息继续流动，而仅暂停拥塞的梯度数据队列。

3. 常见误解

一个常见的误解是 PFC 能够解决拥塞问题。实际上，PFC 将数据包丢失转换为拥塞扩散：背压级联可能在单个故障收发器出现后的 200 毫秒内冻结整个结构，因为没有机制限制 PAUSE 帧在网络中的传播范围。

PFC 的危险在于其级联特性。当交换机端口的缓冲区填满时，它会向上游发送一个 PAUSE 帧，这会导致该交换机的缓冲区也填满，进而触发另一个 PAUSE 帧向更上游传播。理论上，这种背压应当限流来源。但实际上，单个慢速接收器可能在毫秒级内将暂停传播到整个结构中，冻结那些与原始拥塞点毫无关联的链路。这种级联行为，被称为 拥塞扩散 或 受害者流，是基于 PFC 的无损以太网的主要运行风险。根本原因是 incast，这是一种内在于分布式同步的多对一流量模式，如图 3.11 所示；这种确定性过载正是后文所述 PFC 背压级联的触发因素。

一个暂停的接收器可以冻结无关的流。

图 3.11：分布式训练中的 Incast 问题：在 AllReduce 同步过程中，每个 GPU 节点以线速向一个公共汇聚交换机端口发送流量，产生许多对一的流量突增。图中展示了 256 个 GPU 节点，每个以 50 GB/s 的速率汇聚到一个具有 400 Gb/s（50 GB/s）容量和 32 MB 缓冲区的交换机端口：提供的负载达到 12.8 TB/s，而端口容量仅为 50 GB/s，导致出口端口被过度使用 256 倍。这种确定性过载正是本节后文所述 PFC 背压级联的根本原因。

生产事件：超大规模 RoCE 结构中的 PFC 死锁

背景：由微软研究院的 Chuanxiong Guo 领导的团队在微软的数据中心部署了 RoCEv2——一个规模达数万台服务器的 fleet——以支持对延迟敏感的服务。RoCEv2 需要无损结构，因此网络使用了 优先流量控制（PFC），并且团队开发了一种基于 DSCP 的 PFC 机制，以将部署扩展到 VLAN 边界之外 (Guo et al. 2016)。DSCP 标记数据包优先级，VLAN 定义第二层流量边界，ARP 将 IP 地址解析为 MAC 地址，而交换机学习 MAC-到-端口的转发表。

故障模式：PFC 与以太网泛洪相互作用，形成了循环缓冲区依赖。在微软报告的案例中，一台 ARP/MAC 映射不完整的死机导致上游交换机向每个端口泛洪无损数据包；PFC PAUSE 帧则作为对泛洪流量的响应向上游传播，最终在交换机之间形成一个暂停缓冲区的闭环。

后果：一旦形成 PFC 死锁，重启服务器无法清除它。微软的解决方案是架构层面的：阻止广播和多播流量进入无损流量类别，并在对应的 ARP 条目不完整时直接丢弃无损数据包，而非回退到泛洪。

系统教训：PFC 拥塞扩散是无损以太网在超大规模下的结构性漏洞。RoCE 结构需要数据包类纪律、PFC 暂停遥测以及硬件级防护，因为一个最初设计用于避免数据包丢失的机制，本身可能成为故障模式。基于 RoCE 构建的机器学习训练结构直接继承了这一风险：一个过时的 ARP 条目可能级联为 PFC 风暴，使得数千 GPU 的训练运行被阻塞，而集群看似健康，但实际上工作节点之间没有梯度流动。

概率分析：规模下的 PFC 风暴风险

一个简单的概率计算表明，此类事件并非罕见的边界情况，而是规模化下的反复运营风险。

问题：一个包含 4096 个 GPU 的 RoCE 集群正在运行。如果单个收发器降级并触发 PFC 暂停的概率仅为每天 0.001%，那么在给定的一天内发生集群范围的 “PFC 风暴”的概率是多少？

数学：在无损以太网结构中，一个故障链路可以暂停其邻居，进而逐级传播，最终冻结整个树状拓扑。

总暴露量

4096 × 3 链路层级 = 12,288 条链路，即 24,576 个收发器。

零收发器故障的概率

Pr(安全) = (1 − 0.00001)^(24,576) ≈ 0.782.

至少发生一场风暴的概率

Pr(storm) = 1 − 0.782 = 0.218（约 21.8%）。

系统洞察：即使组件拥有“五个九”的可靠性，大规模 RoCE 集群仍面临 21.8% 的日度风险，即发生全结构冻结。这不一定每天都会发生，但频率足以成为每周级别的运维关注点。因此，RoCE 部署需要激进的 PFC 看门狗和硬件级遥测，因为在大规模下，“罕见”的链路退化会成为必须自动处理的经常性运维现实。

主动拥塞控制：DCQCN 与 HPCC

为了避免 PFC 暂停这一生硬手段，高性能结构依赖主动拥塞控制在缓冲区溢出前调节注入速率。在 BSP 工作负载中，主动控制是延迟需求，而非可选的吞吐优化：如果单个数据包因拥塞交换机队列而延迟，整个集群必须等待该落后者完成同步步骤。网络的尾延迟实际上变成了训练作业的平均步耗时。

首个广泛部署的解决方案 DCQCN³⁸，作为一个使用显式拥塞通知（ECN）的反馈回路运行（Zhu et al. 2015）。当交换机的队列深度超过配置阈值时，它会在数据包头部标记 ECN 位。接收方通过拥塞通知包（CNP）将此标记回传给发送方，提示发送方使用乘性减少算法降低注入速率。DCQCN 支持广泛，但生产环境中的 AI 集合操作暴露了一个调优问题：ECN 阈值和网卡固件行为会在 PFC 避免、吞吐、可观测性和尾延迟之间进行权衡，而非提供一个稳定的最优解（Gangidi et al. 2024）。

一个更精确的替代方案 HPCC³⁹，通过使用网络内遥测（INT）解决了这种不透明性（Li et al. 2019）。交换机不再只是简单地标记一位，而是向每个数据包头部追加精确元数据：当前队列深度、链路利用率和时间戳。发送方接收到网络状态的完整仪表盘，从而能在单个往返时间内计算出确切的允许传输速率。通过对精确遥测而非二进制信号做出反应，HPCC 在评估的 Incast 重负载工作负载中减少了队列堆积和尾延迟方差。主要权衡在于硬件支持：DCQCN 可在标准支持 ECN 的以太网交换机上运行，而 HPCC 需要能够以线速推送 INT 元数据的可编程交换机。

自适应路由

静态路由协议如 ECMP⁴⁰（等价多路径）通过哈希流头部将流量分发到固定路径。虽然这种方法对数百万个微小 Web 请求在统计上是合理的，但它对 ML 训练典型的“大象流”失效。设想一个有 4 条等价路径和 8 个大梯度流的场景。完美的分发会将 2 个流放在每条链路上。然而，静态哈希经常导致冲突，使一条链路承载 4 个流而另一条闲置。在同步训练步骤中，完成时间由过载链路决定，实际上使网络的有效带宽减半。

自适应路由通过允许交换机基于实时队列深度而非静态哈希动态选择输出端口来缓解此问题。实现方式取决于协议：InfiniBand 结构执行数据包级自适应路由，将单个数据包喷洒⁴¹到所有可用通道，因为硬件传输保证在目的地按序交付。

以太网结构通常采用流片交换，仅在检测到足够的时间间隙时重新路由数据包突发，以避免数据包乱序带来的性能惩罚。对于混合专家模型，此机制变得至关重要。与可预测的 Ring AllReduce 模式不同，MoE 模型使用 AllToAll 通信，每个 GPU 向包含活跃专家的其他每个 GPU 发送数据。对于使用专家并行且有 64 个专家的 175B 参数模型，这会生成一个密集的 64 × 64 流量矩阵——4,096 个同时进行的流。在静态 ECMP 下，哈希冲突在统计上必然会产生落后者；自适应路由对于将此流量均匀分发到结构的 BW[bisect] 至关重要。

posted @ 2026-09-06 04:02 绝不原创的飞龙阅读(3) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

哈佛-CS249r-机器学习系统第二卷-一-

哈佛 CS249r：机器学习系统第二卷（一）

哈佛 CS249r：机器学习系统第二卷

献词

作者的话

本书适读对象

为何需要舰队级教材

本书内容概览

建议阅读路径

约定

粗体标记首次定义

斜体承担特定修辞任务

正文内容

标注框拥有与其职责相匹配的视觉标识

一个学习平台

一本开源教材

先修要求

超越本书

在课程中使用本书

版权与许可

起源

致谢

合作者与同事

支持

关于 AI 协助的说明

符号约定

机器学习系统的铁律

这些选择为何重要

带下标的变体

退化方程

能量推论

深度学习符号

分布式系统符号约定

性能、服务与内存符号约定

概率与分布符号约定

局部矩阵代数约定

单位与精度

快速参考：冲突消解

时序组件

通信模型

LogGP 扩展

扩展效率

故障容忍与可靠性

并行维度

集群容量因子

压缩经济学

简介

目的

规模时刻

符号与记法

传输与压缩时序

大规模服务内存

附加冲突点

附加单位

舰队堆栈：一种层次化架构

规模不连续性

舰队堆栈：一种层次化架构

上层两层经历了同样深刻的变革

传统舰队与 ML 舰队的动态对比

向仓库级计算机的转变

通信成为主导因素

故障成为常态

AI 扩展定律

扩展定律的经验证据

计算最优资源分配

数学基础与运行机制

资源受限缩放机制

系统设计中的实际应用

可持续性与成本影响

扩展定律失效条件

将效率与扩展相结合

规模的约束

可靠性鸿沟

通信强度（CI 比率）

通信与扩展优化

为何分布式很难

CAP 定理的现实

边缘分布式的复杂性

`175B` 模型在 `H100` 上

推理（解码，批次大小 1）

训练前向传播（批次大小 2048）