经验法则

The C$^3$ 分类法

在分布式训练集群中，“它很慢”甚至比单机场景下更缺乏信息量。作业可能因加速器利用率不足（Compute）而停滞，或因梯度同步使互连结构饱和（Communication）而停滞，也可能因检查点与恢复延迟而进展缓慢（Coordination）。本附录将单机诊断扩展到集群级基础设施，提供贯穿全书的 C$^3$ 记分卡，用于隔离分布式系统中的绑定瓶颈。

如何使用本附录

本附录设计为参考手册。先阅读诊断汇总表，形成关于哪个 C$^3$ 轴占主导地位的假设，然后选用能够确认（或证伪）该假设的工具。

当训练吞吐量偏低时，检查模型 FLOPs 利用率（MFU）、通信占比与有效吞吐率，然后将各项分别映射到计算、通信或协同轴。当扩展效率低于预期时，使用集群规模定律分解来识别增长的是哪一项。当成本急剧上升时，使用 C$^3$ 记分卡，以确保投入针对主导项，而非非瓶颈项。

C$^3$ 分类法 是集群级机器学习系统工程诊断框架。在单机基础（如 **D·A·M 基础** 中所述）诊断的是单节点内部的瓶颈——数据饥饿、算法开销或硬件饱和——而 C$^3$ 分类法则诊断整个分布式集群跨节点的瓶颈。大多数集群级性能问题可以通过识别主导轴来诊断：Compute（加速器是否在执行有用的计算？）、Communication（网络是否足够快地传输数据？）或 Coordination（系统是否将过多时间耗费在同步、故障恢复与调度上？）。许多生产环境中的瓶颈位于这些轴之间的交点。

从 D·A·M 到 C$^3$

C$^3$ 分类法并未取代 D·A·M——它是在其基础上加以扩展。当工作负载从单台机器迁移到整个集群时，每个 D·A·M 轴都会产生单机框架无法捕捉的新故障模式。表 1 展示了这一迁移过程。

表 1: 将 D·A·M 映射到 C$^3$：单机器诊断关注点如何推广为集群级挑战。

D·A·M 轴	单机关注点	C$^3$ 扩展	集群规模下发生了什么变化
数据	主机磁盘 $\to$ GPU 内存流水线	通信	数据传输跨越网络互连结构；AllReduce、AllGather 与流水线传输占主导
算法	算子选择、自动微分图	计算/协同	工作负载必须被切分（$N$ 路切分）；通信与计算的比值决定扩展
机器	SM 占用率、HBM 带宽	协同	单设备故障演变为集群级慢节点；故障恢复、调度与功率密度共同约束 $N$

表 1 中最重要的行是最后一行。在单机器上，铁律中的开销项（$L_{\text{lat}}$）通常很小——内核启动延迟、Python 分派、同步屏障。在集群规模下，协同成为其自身的轴：检查点写入、故障检测与恢复、流水线气泡开销、调度器抢占以及维护窗口共同消耗了可观比例的墙钟时间。协同正是本书致力于解决的轴。

诊断摘要

映射建立后，诊断就变成将症状与约束集群的轴相匹配的问题。表 2 提供了集群级诊断的主要参考表。每个 C$^3$ 轴都对应一个物理约束、可观测症状、可测量指标与工程杠杆。

表 2: C$^3$ 诊断摘要：每个轴对应一个独特的物理约束和一项高杠杆优化策略。诊断从这里开始：先确定哪个约束起主导作用，再沿优化指针前往相关章节。

C$^3$ 轴	物理约束	症状	关键指标	高杠杆优化
计算（$C_1$）	算术吞吐率（$R_{\text{peak}} \times \eta_{\text{hw}}$）	MFU 偏低、GPU 利用率低于 80%、单 GPU 性能不佳	MFU（模型 FLOPs 利用率）	内核优化、混合精度、算子融合（性能工程）
通信（$C_2$）	网络带宽（$\text{BW}_{\text{net}}$）	AllReduce 时间偏高、扩展效率偏低、通信占步长超过 30%	扩展效率（$\eta_{\text{scaling}}$）、通信占比（$T_{\text{comm}}(N)/T_{\text{step}}(N)$）	梯度压缩、计算/通信重叠、拓扑优化（集合通信）
协同（$C_3$）	同步开销与故障恢复	有效吞吐率偏低、频繁重启、流水线气泡较大、调度器频繁切换	有效吞吐率（$T_{\text{useful}}/T_{\text{wall}}$）	异步检查点、弹性训练、更快的故障检测（容错）

集群规模定律

同一分类法可以写成每个分布式步骤的时间预算。在 **C^3 分类法：规模的基础** 中提出的集群规模定律，将每个分布式训练步骤分解为分布式步骤时间预算：

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

该方程是铁律在集群规模下的对应形式。铁律将单机执行分解为数据传输、计算与开销，而集群规模定律将分布式执行分解为本地算术、网络数据传输与同步逻辑。诊断策略完全相同：测量各项，识别其中占主导的一项，并将工程投入导向主导项。

分量分解

集群规模定律的每一项都对应特定的可测量活动：

$T_{\text{compute}}/N$：前向传播、反向传播、优化器步长——即分布在 $N$ 台设备上的全部本地算术。受 MFU 与单 GPU 内核效率支配。改进来自更好的内核、混合精度与算子融合。
$T_{\text{comm}}(N)$：梯度的 AllReduce、参数（在 FSDP/ZeRO 中）的 AllGather，以及张量并行/流水线并行中的激活传输。受网络带宽与集合通信算法选择支配。改进来自梯度压缩、分层集合通信与计算—通信重叠。
$T_{\text{sync}}(N)$：同步屏障、检查点写入、故障检测与恢复、流水线气泡空闲时间、调度器抢占与维护窗口。受集群可靠性与编排软件支配。改进来自异步检查点、弹性训练与更快的故障检测。
$T_{\text{overlap}}$：隐藏在有用算术背后的通信或协同时间。受调度与实现重叠支配。

集群的效率由此直接得出：

\[ f_{\text{compute}} = \frac{T_{\text{compute}}/N}{T_{\text{step}}(N)} \]

当 $f_{\text{compute}}$ 低于 0.5 时，集群在通信与协同上花费的时间超过有用算术。该计算时间占比并非集群总效率；有用的集群效率还取决于 MFU、扩展效率与有效吞吐率。C$^3$ 分类法用于确定是哪个非计算项负责。

交点图谱

开篇章节使用 C$^3$ 交集版图 建立跨节点底层、网络骨干与编排层的协同设计图谱。在生产环境中，瓶颈很少以单一孤立轴的形式呈现；它们往往出现在两个或多个维度叠加的边界处。诊断这些复合瓶颈需要先将这些症状映射到其主导交点，再选择干预措施。

表 3 将三个纯维度、三个两两交点以及中心汇聚展开为具体的工程技术与各自对应的本书主要章节。

表 3: C$^3$ 交点参考：每个区域将具体技术映射到其跨越的轴以及覆盖它们的章节。两两交点需要同时推理两个领域；中心交点则需要同时考虑全部三个维度。

区域	名称	关键技术	本书覆盖
计算（$C_1$）	节点底层	算子融合、混合精度（FP8/BF16）、MFU 优化、本地 NVMe 暂存	计算基础设施, 数据存储, 性能工程
通信（$C_2$）	网络骨干	面向链路的 Clos 拓扑优化、RoCEv2/InfiniBand 互连、集合通信算法	网络互连结构, 集合通信
协同（$C_3$）	编排层	批量调度（Slurm、Kubernetes、Ray）、状态一致性、心跳故障检测	容错, 集群编排, 规模化机器学习运维
计算 $\cap$ 通信（$C_1 \cap C_2$）	隐藏网络延迟	1F1B 流水线、CUDA stream 计算—通信重叠、通信—计算比值（$\rho$）调优、链路压缩	分布式训练, 集合通信
计算 $\cap$ 协同（$C_1 \cap C_3$）	最大化集群有效吞吐	非阻塞异步检查点、流水线气泡缩减、内存重算与回滚对比、快速节点释放	容错, 集群编排
通信 $\cap$ 协同（$C_2 \cap C_3$）	集合同步	慢节点缓解、分层集合通信（NVLink 与 IB 对比）、有界陈旧度、感知拓扑的秩映射	集合通信, 容错
计算 $\cap$ 通信 $\cap$ 协同（$C_1 \cap C_2 \cap C_3$）	集群机器学习系统工程	集群规模定律分解、4D 并行（DP+TP+PP+EP）、内存切分（FSDP2、ZeRO-3）、有效吞吐指标	分布式训练, 在大规模下运行推理, 边缘智能

计算 $\cap$ 通信

该交点决定系统是否能够利用计算来隐藏通信。通信—计算比值（$\rho = T_{\text{comm}}(N)/(T_{\text{compute}}/N)$）是关键诊断指标（通信—计算比）。当 $\rho < 1$ 时，计算耗时超过通信耗时，网络传输在理论上可以重叠——系统处于计算受限且健康状态。当 $\rho > 1$ 时，GPU 在收到下一轮操作数之前已完成本地工作，系统转为通信受限。

在 GPU 执行追踪中，这一瓶颈表现为未被计算掩盖的通信区间，此时张量核心处于空闲状态，等待集合通信完成（例如 ncclKernel_AllReduce 或 ncclKernel_AllGather）。这一交叉点的工程重点在于重叠与压缩：在所有梯度最终确定之前，于反向传播过程中启动 AllReduce；在 1F1B 调度中以流水线方式传输激活；增大微批次大小或梯度累积步数，以降低通信频率；并采用 FP8 或 INT4 传输量化，将所需的网络传输量减半（分布式训练、集合通信）。

计算 $\cap$ 协同

这一交叉点涵盖了编排与韧性机制导致的计算资源闲置。理想情况下，计算引擎应持续进行算术运算并保持饱和，但协同开销会反复迫使硬件进入空闲状态。

三种不同的机制支配着这一交叉点：

流水线气泡：在流水线并行（PP）中，各阶段在流水线填充（预热）和排空（冷却）期间处于空闲状态。对于流水线深度 $p$ 和微批次数量 $m$，气泡占比 $F_{\text{bubble}} = (p - 1) / (m + p - 1)$ 会直接浪费加速器周期，除非通过交错式 1F1B 调度将其隐藏。
检查点停顿：同步检查点写入会阻塞训练循环，以序列化数 TB 的权重和优化器状态，从而将昂贵的计算时间转化为存储等待时间。异步检查点通过在毫秒级时间内对主机页锁定内存或本地非易失性内存高速接口（NVMe）存储中的状态生成快照来缓解这一问题，并将远程持久化交由后台 I/O 线程完成。
恢复回滚：当一个包含 $N$ 个节点的集群中有节点发生故障时，训练会停止并回滚到最近的有效检查点，从而浪费自该快照以来执行的算术运算。通过快速健康心跳和动态节点替换来最小化故障影响范围，可以限制这种计算损失（容错、集群编排）。

通信 $\cap$ 协同

这一交叉点涵盖了网络通信中内含的同步成本。每一次集合操作（AllReduce、AllGather、ReduceScatter）既是通过物理线路进行的数据传输（$C_2$），也是一道集群级屏障（$C_3$）。所有参与者都必须到达屏障，集合操作才能完成。

主导性的失效模式是慢节点效应放大。如果单个 GPU 或链路出现丢包、热降频或 ECC 重试延迟，参与集合操作的其他所有 GPU 都会等待，从而将局部性能退化转变为整个集群的停顿。在大规模集群中（$N \ge 10{,}000$），尾延迟主导屏障等待时间：至少一个节点变慢的概率趋近于 1（$1 - (1 - p_{\text{straggle}})^N \to 1$）。

这一交叉点的工程重点在于将同步与底层通信解耦：采用分层集合通信，将高带宽的节点内 NVLink 域与节点间 InfiniBand 网络互连结构隔离；采用陈旧度有界的异步训练，以吸收瞬态尾延迟；并强制采用拓扑感知的成组调度，使集合通信环与物理脊叶交换网络的通道对齐（集合通信、容错）。

集群级机器学习系统工程

在中心位置（$C_1 \cap C_2 \cap C_3$），三项约束同时汇聚。这就是集群级机器学习系统工程这一学科。处于这一中心位置的系统工程师并非只优化单个加速器或单台网络交换机，而是将分布式机器视为一个完整系统，管理其中的权衡取舍。

核心工程挑战包括：

4D 并行协同设计：平衡数据并行（DP）、张量并行（TP）、流水线并行（PP）和专家并行（EP），使内存占用不超过加速器高带宽内存（HBM）的容量（$C_1$），将高频通信映射到节点内 NVLink，将低频通信映射到节点间网络互连结构（$C_2$），并最小化流水线气泡和屏障依赖（$C_3$）。
内存分片与通信量的权衡：PyTorch FSDP2 和 DeepSpeed ZeRO-3 等框架通过将模型状态划分到各个工作节点来消除内存冗余（$C_1$），但必须承担重复 AllGather 通信（$C_2$）和状态协同元数据（$C_3$）带来的开销。
整体有效吞吐量优化：Google 的机器学习生产力有效吞吐量指标通过将集群生产力分解为程序有效吞吐量（$\eta_{\text{program}}$、$C_1$）、运行时有效吞吐量（$\eta_{\text{runtime}}$、$C_2$）和调度有效吞吐量（$\eta_{\text{scheduling}}$、$C_3$），将这一三重交叉点转化为可操作的度量。

C$^3$ 协同与重叠

正如单节点执行将加法形式的铁律转化为受依赖关系约束的最大值（D·A·M 协同：从求和到取最大值），集群级重叠也会改变集群定律（equation），其方式是最大化 $T_{\text{overlap}}$。C^3 重叠技术 汇总了 C$^3$ 各维度上的主要重叠技术。

**C$^3$ 重叠技术**：通过有效计算隐藏通信或协同开销的系统技术，用于最大化集群定律中的 $T_{\text{overlap}}$。
技术	C$^3$ 重叠	机制	实现
1F1B 流水线调度	$C_1$ 与 $C_2$ 重叠	交错安排前向和反向微批次，使跨阶段激活传输与算术运算重叠	微批次队列调度（分布式训练）
CUDA 流解耦	$C_1$ 与 $C_2$ 重叠	在独立的通信流上启动非阻塞 AllGather 或 AllReduce，使其与 GEMM 并发执行	专用 NCCL 流（集合通信）
异步检查点	$C_1$ 与 $C_3$ 重叠	快速生成内存或本地 NVMe 快照，同时 GPU 立即恢复算术运算	后台主机线程将数据刷写到存储（数据存储、容错）
分层集合通信	$C_2$ 与 $C_3$ 重叠	将集合操作划分为本地 NVLink 归约和节点间网络互连传输，隔离尾延迟抖动	分层 NCCL 通信器（集合通信）
双缓冲数据流式传输	$C_1$ 与 $C_2$ 重叠	在主机页锁定内存中预取并解压下一批次的数据分片，同时 GPU 计算当前批次	主机页锁定内存 + 异步 D2D 传输（数据存储）

存储作为持久化基础

一个常见的诊断问题是：为什么存储没有作为第四个显式坐标出现在 C$^3$ 分类体系中，也没有作为独立的 $T_{\text{storage}}$ 项出现在集群定律中。

物理数据中心的采购围绕计算、网络和存储展开（数据存储）。然而，在运行时，存储设备不执行任何模型算术运算。因此，存储开销会通过三个 C$^3$ 维度动态体现：

在计算维度（$C_1$）：高吞吐量的本地 NVMe 驱动器充当加速器内存层次结构的第三级扩展（位于 SRAM 和 HBM 之下），用于参数卸载（ZeRO-Offload）和激活溢出存储。
在通信维度（$C_2$）：从并行文件系统（Lustre、GPFS）或对象存储（S3、Ceph）流式传输远程数据集时，会与集合通信流量共享集群网络带宽和网络接口卡（NIC）容量。
在协同维度（$C_3$）：持久化分布式存储提供检查点序列化、节点故障切换和作业重新调度所需的持久状态锚点。

当存储延迟导致训练停顿时，性能分析器识别到的症状并不是原始磁盘延迟，而是网络通信瓶颈（$C_2$，数据集供给不足）或阻塞性的协同屏障（$C_3$，同步检查点刷写）。存储是支撑全部三个维度的持久化基础，而不是单步执行预算中的独立项。

在生产事故处理过程中，快速启发式规则能在需要剖析器之前先缩小搜索空间。这些阈值构成了第一道防线。

C$^3$ 红绿灯

表 4 为每个 C$^3$ 轴提供基于阈值的分诊。

表 4: C$^3$ 红绿灯：面向集群规模诊断的快速分诊阈值。绿色表示该轴健康；黄色表示值得排查；红色表示它很可能是瓶颈。这些阈值假定是在当前一代硬件上进行优化良好的大模型训练。

C$^3$ 轴	绿色（健康）	黄色（需排查）	红色（瓶颈）
计算	MFU $>$ 50%	MFU 30%–50%	MFU $<$ 30%
通信	通信占比 $<$ 20%	通信占比 20–40%	通信占比 $>$ 40%
协同	有效吞吐比 $>$ 90%	有效吞吐比 75–90%	有效吞吐比 $<$ 75%

瓶颈诊断表

一旦确定瓶颈轴，表 5 便展示哪些优化有效、哪些优化是浪费。

表 5: 集群规模下“有效”与“浪费”：优化非主导的 C$^3$ 轴只能带来有限的改善，往往还会恶化成本效率。对于通信受限的集群，在解决 AllReduce 及其他通信瓶颈之前，更快的 GPU 几乎收效甚微。

若集群处于…	主导项	有效的优化	被浪费的优化
计算受限	$T_{\text{compute}}/N$	更好的内核、混合精度、算子融合、新一代加速器	更多网络带宽（GPU 并未等待网络）
通信受限	$T_{\text{comm}}(N)$	梯度压缩、计算—通信重叠、分层集合、InfiniBand 升级	更快的 GPU（它们只会更快地空闲等待网络）
协同受限	$T_{\text{sync}}(N)$	异步检查点、弹性训练、更快的故障检测、更少的流水线阶段	既非更快的 GPU 也非更快的网络（时间损失于开销，而非数据移动或算术运算）

C$^3$ 案例研究

理论约束在生产环境中会表现为令人困惑的症状。本节通过案例说明如何将该 C$^3$ 分类法应用于集群规模的性能问题。每个案例先隔离一个主导维度，再展示由此诊断得出的优化手段。

案例 1：利用率不足的集群（Compute）

症状

一个工程团队为大型语言模型训练任务配置了 4,096 个 H100 GPU。训练循环运行无错误，但 PyTorch Profiler 显示 MFU 仅为 15 percent。网络剖析器显示通信占单步时间的不到 10%。集群处于运行状态，但几乎未真正工作。

诊断

Compute 维度是瓶颈。在 15 percent 的 MFU 下，集群峰值容量的 85 percent 未被计入有用的模型 FLOPs。这既不是通信问题，也不是协同问题——网络速度足够快，系统保持稳定。系统并未高效地向 GPU 提供计算工作。

修复方案

这是一个单 GPU 效率问题，只是被 4,096 个加速器放大。针对 compute 维度：

混合精度：确保 BF16/FP8 Tensor Cores 被启用。常见诱因是归一化层或损失计算中的 FP32 回退。
算子融合：使用 torch.compile 或类似的即时（JIT）编译来融合逐元素操作，降低内核启动开销。
批大小调优：若单 GPU 批大小过小，矩阵乘法缺乏足够的算术强度以饱和 Tensor Cores。

在同一硬件上将 MFU 从 15 percent 提升至 50 percent，可带来 50 percent/15 percent = 3.3× 的更多有用工作——相当于在不新增任何 GPU 的情况下将集群规模提升三倍。

案例 2：通信墙（Communication）

症状

一次 512-GPU 数据并行训练运行在每个 GPU 的计算阶段达到 45 percent 的示意性计算效率——单设备内核效率良好。但涵盖完整单步（含 AllReduce）的墙钟 MFU 仅为 20.2 percent，因为 AllReduce 消耗了每个训练步骤的 55 percent。从 64 个 GPU 扩展到 512 个 GPU 仅带来 4× 的加速比，而非预期的 8×，即 50 percent 的扩展效率。

诊断

Communication 维度占主导。每个 GPU 的计算阶段效率良好，但超过一半的单步时间用于通过网络同步梯度。系统处于 Communication-Bound 状态：增加 GPU 只会使其更糟而非更好，因为 AllReduce 时间随参与节点数增长，而单 GPU 的计算量保持不变。

修复方案

针对通信维度，同时不改动单 GPU 的计算：

计算—通信重叠：在反向传播期间启动 AllReduce，而不是等待其完成。现代框架（FSDP、DeepSpeed）原生支持该机制。
梯度压缩：应用 TopK 稀疏化或量化，将穿越网络的字节数减少 10–100$\times$。
分层集合通信：第一级归约使用节点内 NVLink，跨节点聚合仅使用节点间 InfiniBand，从而将跨节点流量降低 8$\times$。

若完全消除通信，吞吐量将提升 2.2×（Amdahl 定律应用于 45 percent 的计算占比）。现实情况下，将通信从 55 percent 降至单步时间的 20%，可恢复大部分已损失的扩展收益。

案例 3：协同开销（Coordination）

症状

一次 10,000-GPU 训练运行显示每设备 40 percent 的 MFU，通信仅占单步时间的 15 percent——两者均健康。然而，该任务的 Goodput Ratio（每秒有用训练步骤数除以理想或已分配的单步速率）仅为 60 percent。剩余 40 percent 的墙钟时间被检查点写入、故障恢复重启、流水线气泡空闲时间、调度器抢占（17 percent 的墙钟时间）以及维护窗口消耗。

诊断

Coordination 维度占主导。单 GPU 计算与节点间通信均高效，但 40 percent 的墙钟时间被非生产性开销消耗：10 percent 的故障恢复（在 10,000 个 GPU 下，GPU 故障大约每 5 hours 发生一次）、5 percent 流水线气泡、3 percent 检查点写入，以及 5 percent 的维护窗口。更快的 GPU 或更快的网络都无帮助——消耗时间的是协同，而非计算或通信。

修复方案

针对协同维度：

异步检查点：将检查点写入与下一个训练步骤重叠，将可见的检查点开销从 3 percent 降至接近零。
弹性训练：当节点故障时，缩小任务并继续运行，而不是让全部 10,000 个 GPU 暂停恢复。这将 10 percent 的故障恢复成本转化为较小的吞吐量下降。
流水线调度优化：从 GPipe 切换到交错的 1F1B 调度以降低气泡占比，或增加每条流水线冲刷的微批次数。
更快的故障检测：将心跳超时从 30 秒缩短至 5 秒，配合硬件级健康监控，减少从故障发生到恢复启动之间的空闲时间。

生产故障排查

表 6 提供了常见集群规模故障模式的诊断矩阵。

表 6: C$^3$ 故障排查矩阵：常见集群规模瓶颈的根因识别与修复。每一行将用户可见的症状连接到最可能导致该问题的 C$^3$ 维度，从而在启用剖析器之前缩小排查空间。

Symptom	C$^3$ Axis	Diagnostic Question	Measurement	Action
Low MFU despite fast network	Compute	Are Tensor Cores engaged? Is batch size sufficient for arithmetic intensity?	Per-GPU kernel trace (Nsight/PyTorch Profiler)	Enable mixed precision, increase per-GPU batch size
Throughput plateaus when adding GPUs	Communication	Does AllReduce time grow faster than computation shrinks?	NCCL trace, $\rho$ ratio	Gradient compression, hierarchical collectives, overlap
Frequent job restarts	Coordination	What is the cluster MTBF? Is detection fast enough?	Failure logs, MTBF calculation	Elastic training, faster detection, smaller blast radius
High GPU-hours but slow progress	Coordination	What fraction of GPU-hours produce useful training steps?	Goodput ratio ($T_{\text{useful}}/T_{\text{wall}}$)	Async checkpointing, reduce pipeline stages, eliminate scheduler churn
Scaling efficiency drops with cluster size	Comm/Coord	Is the bottleneck network bandwidth or synchronization barriers?	Separate $T_{\text{comm}}(N)$ from $T_{\text{sync}}(N)$	If comm: compress or overlap. If coord: async methods
Stragglers slow entire job	Comm $\cap$ Coord	Is one node consistently last to reach the AllReduce barrier?	Per-node step time histogram	Straggler detection + replacement, bounded staleness, backup workers

工具映射

工程师必须借助具体的剖析工具来测量抽象的 C$^3$ 维度。表 7 将每个维度映射到用于确认或证伪假设的工具。

表 7: C$^3$ 工具映射：用于诊断集群规模瓶颈的剖析工具。先从主工具开始进行快速分诊，再使用次级工具进行深入分析。Compute 工具按 GPU 操作；Communication 工具在网络层操作；Coordination 工具在集群/任务层操作。

C$^3$ Axis	Key Metric	Primary Tool	Secondary Tool
Compute	MFU, kernel utilization	PyTorch Profiler (TensorBoard plugin)	Nsight Compute (per-kernel roofline analysis)
Communication	AllReduce time, $\rho$ ratio	NCCL debug logs (`NCCL_DEBUG=INFO`)	Nsight Systems (timeline), `ibstat`/`perfquery` (IB)
Coordination	Goodput ratio, restart count	Cluster scheduler logs (Slurm, K8s event logs)	Custom goodput dashboards (for example, Google ML Goodput)

C$^3$ 记分卡

C$^3$ 记分卡依据已知阈值对集群效率进行评级，将单机记分卡（**D·A·M 基础**）扩展至分布式环境。表 8 定义了刻画集群健康度的三个指标。

表 8: C$^3$ 效率标尺：使用这三个数值来刻画集群健康度。MFU 的分母采用集群聚合峰值，当 $N R_{\text{peak,device}}$ 表示单设备数值时写作 $R_{\text{peak}}$。通过全部三项阈值的集群，其容易实现的优化手段已用尽；进一步的性能提升需要依靠架构调整、硬件升级或更大的问题规模，以改善扩展形态。

C$^3$ Axis	Metric	Definition	Failing Grade	Passing Grade
Compute	MFU	$\frac{O_{\text{step}}}{N R_{\text{peak,device}} \times T_{\text{step}}}$	$<$ 30%	$>$ 50%
Communication	Scaling Efficiency ($\eta_{\text{scaling}}$)	$\frac{T_1}{N \times T_N}$	$<$ 35%	$>$ 70%
Coordination	Goodput Ratio	$\frac{T_{\text{useful}}}{T_{\text{wall}}}$ or $\frac{\text{useful steps/sec}}{\text{ideal or allocated steps/sec}}$	$<$ 75%	$>$ 90%

C³ 基础设施诊断决策树与集群 D·A·M 记分卡

为在硬件级遥测与架构优化之间建立衔接，集群运维团队需要一套系统性流程，将底层硬件信号映射到对应的 C$^3$ 瓶颈墙。

遥测信号到 C$^3$ 墙的映射

现代 GPU 集群会在硅片、PCIe 总线、温度传感器和网络交换机层面产生密集的遥测数据：

MFU 下降：模型 FLOPs 利用率相对预期基线出现突降或持续下降。
PCIe AER（Advanced Error Reporting）重试：非致命总线错误导致数据包重试、链路降级（例如 PCIe Gen 5 $\to$ Gen 3），或主机到设备直接内存访问（DMA）节流。
热节流：GPU SM 时钟降频（例如 1.9 GHz $\to$ 1.1 GHz），由结温限制或散热风扇性能退化触发。
InfiniBand 信用暂停与 PFC 暂停帧：优先级流量控制（PFC）暂停帧、拥塞通知包（CNP），或交换机缓冲区信用耗尽。

诊断决策树

下方的硬件优先诊断树指导从初始遥测信号排查至底层 C$^3$ 瓶颈墙及相应修复动作。

                    [Telemetry Signal/Performance]
                         [Anomaly Detected]
                                  |

                 /----------------+----------------\
                 v                                 v
       [System Telemetry]                  [Network Telemetry]
  [MFU drops, Thermal, AER]          [PFC Pauses, Credit Stalls]
                 |                                 |

          /------+------\                   /------+------\
          v             v                   v             v
     [Thermal]       [PCIe]            [IB Credit]      [High]
       [Temp]         [AER]              [Stalls]       [Tail]
      [> 85°C]      [Retries]             [> 5%]      [Latency]
          |             |                   |             |

          v             v                   v             v
     [COMPUTE]      [COMPUTE]            [COMM.]       [COORD.]
       [WALL]         [WALL]              [WALL]         [WALL]

      (Thermal       (PCIe Bus           (Network      (Straggler
     Throttling)    Degradation)         Congestion)     Barrier)

结构化诊断遥测表

表 9 将硬件级遥测计数器映射到根因、C$^3$ 瓶颈墙以及具体的运维修复措施。

表 9: C$^3$ 遥测诊断映射：从芯片级遥测信号到分布式瓶颈墙及修复流程的直接映射。

遥测信号	硬件/OS 计数器	根因	C$^3$ 瓶颈墙	修复措施
MFU 下降且 GPU 温度过高	`gpu_temperature > 85°C`、`clocks_throttle_reasons.sw_thermal`	热节流降低 GPU SM 时钟频率	计算墙	检查冷却液流量，更换导热界面材料（TIM），调整风扇曲线
MFU 下降且主机—GPU 带宽过低	`pcie_aer_correctable_errors`、`pcie_link_width < x16`	信号噪声导致 PCIe 链路劣化/重试	计算墙	重新插拔 GPU/PCIe 转接卡，清洁 PCIe 边缘连接器，更换线缆
全归约停滞且出现暂停帧	`PFC_PAUSE_XOFF_FRAMES`、`infiniband_credit_stalls`	网络互连结构拥塞、IB 缓冲区耗尽	通信墙	启用自适应路由（AR），重新平衡 ECMP 哈希，调整 NCCL 缓冲区大小
NCCL 屏障超时/挂起	`NCCL_WARN=INFO` 日志 `Unhandled CUDA error`、`heartbeat_miss`	单个节点拖慢整体进度，或内核静默挂起	协同墙	停止向性能退化的节点分派任务，通过节点健康检查脚本将其隔离，触发快速重启
训练步开销高且 GPU 空闲	`nvlink_throughput == 0`、`fs_write_latency > 1s`	向存储执行阻塞式同步检查点写入	协同墙	切换为异步双缓冲检查点，或采用主机 RAM 暂存

集群 D·A·M 记分卡

表 10 中的集群 D·A·M 记分卡将单节点的数据、算法和机器（D·A·M）诊断推广至集群规模的 C$^3$ 瓶颈。

表 10: 集群 D·A·M 记分卡：量化单节点硬件遥测如何映射为集群级 C$^3$ 执行约束。

D·A·M 维度	集群遥测信号	C$^3$ 瓶颈墙	目标效率基准
数据 ($D$)	网络互连结构 RX/TX 饱和、存储写入 I/O 等待时间	通信/协同	I/O 等待时间 $< 2\%$ 训练步耗时；NCCL 环带宽 $> 85\%$ 网络互连结构峰值带宽
算法 ($A$)	模型 FLOPs 利用率（MFU）、流水线气泡空闲比例	计算/协同	MFU $> 60\%$；流水线气泡比例 $< \frac{p-1}{2K}$
机器 ($M$)	PCIe AER 错误、热节流计数器、GPU 功率限制节流	计算	热节流事件 $= 0$；PCIe 链路宽度保持最大值（Gen 5 x16）

从 C$^3$ 视角审视规模定律

规模定律通常以算法 FLOPs 表述，但训练集群只能提供扣除利用率、通信和协同损失后剩余的有用 FLOPs。规模定律的目标可直接转化为 C$^3$ 框架下的表述：隐含的理想系统假设忽略了这些损失，而有效 FLOP/s 则定义了将模型质量预测与实际集群容量联系起来的可用吞吐量。

为什么规模定律假设 C$^3$ 处于理想状态

规模定律——Kaplan、Chinchilla 及其后续定律——将模型质量预测为算法训练计算量的函数。它们通常忽略系统效率：实际运行时间、加速器峰值 FLOP/s、计算阶段效率、通信开销和调度器损失，只有在团队配置硬件以实现目标计算预算时才会纳入考虑。用 C$^3$ 的术语来说，规模定律中的 FLOPs 必须在计入计算阶段、分布式训练步和运维有效吞吐损失后，换算为所需的集群原始容量。

规模定律预测与观测到的训练结果之间的差距，在很大程度上是 C$^3$ 方面的差距。为训练分配 $10^{24}$ FLOPs 预算的团队，实际提供给模型的有效 FLOPs 会少得多，因为每个 FLOP 都必须经过三项乘性损失：每个 GPU 的计算阶段效率、节点间扩展效率 ($\eta_{\text{scaling}}$)，以及运维有效吞吐。

有效 FLOP/s 的概念

集群的有效 FLOP/s 是在叠加三项互不相交的 C$^3$ 效率因子后得到的可用吞吐量：

\[\text{Effective} = \text{Peak} \times \underbrace{\eta_{\text{compute-phase}}}_{\text{Compute}} \times \underbrace{\eta_{\text{scaling}}}_{\text{Distributed step}} \times \underbrace{\eta_{\text{operational}}}_{\text{Operational goodput}}\]

计算阶段因子衡量的是仅在本地计算活跃期间，有用模型算术相对于峰值吞吐量的比值。扩展效率因子涵盖通信及其他分布式步长损失，包括流水线气泡。运维有效吞吐因子涵盖这些测量步骤之外的时间，包括检查点、故障恢复、调度器抢占和维护。这些互不相交的测量窗口避免了将同一损失重复计入。

一个具体估算使集群规模下的相乘损失清晰可见。

Systems Perspective 1.1: 100,000 GPU 集群上的 C³ 协同开销

考虑一个 100,000 GPU 的 H100 集群，峰值聚合吞吐量为 98,900 PFLOP/s。经过三项互不相交的 C$^3$ 效率因子后：

\[\text{Effective} = 98,900 PFLOP/s \times 0.50 \times 0.35 \times 0.65 \approx 11249.9 PFLOP/s\]

集群交付了其峰值容量的 11.4 percent 作为有用训练工作。C$^3$ 协同开销——峰值与有效吞吐之比——为 8.8×：要达到给定的有效计算预算，需要 8.8× 的原始硬件。计算阶段保留 50 percent 的效率因子。分布式步长保留 35 percent 的扩展因子，以 8,192 GPU 参考配置作为包含流水线损失的示意性代理。运维在检查点、故障、调度器抢占和维护之后保留 65 percent 的有效吞吐因子。

这些损失反映的是集群规模计算的物理规律，而非工程上的失败。C$^3$ 分类体系量化了损失发生的位置，从而使优化工作能够针对主导项。

摘要

C$^3$ 分类体系为诊断集群级瓶颈提供了系统框架。每个轴对应一种独立的物理约束：算术吞吐量和 MFU 决定计算；网络带宽与集合算法效率决定通信；同步开销、故障恢复和运维损失决定协同。集群定律量化了这些约束，从而支持系统性诊断。使用 C$^3$ 交通灯进行快速分诊，使用瓶颈诊断表选择正确的杠杆，使用 C$^3$ 记分卡评定集群健康度。

Key Takeaways: 集群规模下优先排查什么

每个集群级瓶颈都有一个主导的 C$^3$ 轴：计算、通信或协同，许多真实瓶颈跨越多个轴的交叠区域。先识别主导轴，再进行优化。
测量 C$^3$ 记分卡：在投入优化之前，先确认 MFU $>$ 50 percent、扩展效率 $>$ 70 percent 和有效吞吐比 $>$ 是否达到 90%。
C$^3$ 协同开销是相乘的：峰值 FLOP/s $\times$ 计算阶段效率 $\times$ 扩展效率 $\times$ 运维有效吞吐 = 有效 FLOP/s。当 100,000 GPUs 时，实际仅约为峰值的 ~11.4 percent。
协同是新的轴：在单台机器上，开销可以忽略。在集群规模上，检查点、故障、流水线气泡和调度会消耗 40 percent 或更多的挂钟时间。
优化错误的 C$^3$ 轴带来的改善有限：更快的 GPU 无法单独修复通信受限的集群；更快的网络也无法修复协同开销。

回到顶部

C\(^3\) Axis	Metric	Definition	Failing Grade	Passing Grade
Compute	MFU	\(\frac{O_{\text{step}}}{N R_{\text{peak,device}} \times T_{\text{step}}}\)	\(<\) 30%	\(>\) 50%
Communication	Scaling Efficiency (\(\eta_{\text{scaling}}\))	\(\frac{T_1}{N \times T_N}\)	\(<\) 35%	\(>\) 70%
Coordination	Goodput Ratio	\(\frac{T_{\text{useful}}}{T_{\text{wall}}}\) or \(\frac{\text{useful steps/sec}}{\text{ideal or allocated steps/sec}}\)	\(<\) 75%	\(>\) 90%

The C\(^3\) 分类法

如何使用本附录

从 D·A·M 到 C\(^3\)

诊断摘要

集群规模定律

分量分解

交点图谱

计算 \(\cap\) 通信

计算 \(\cap\) 协同

通信 \(\cap\) 协同

集群级机器学习系统工程

C\(^3\) 协同与重叠

存储作为持久化基础

C\(^3\) 红绿灯

瓶颈诊断表

C\(^3\) 案例研究

案例 1：利用率不足的集群（Compute）

症状

诊断

修复方案

案例 2：通信墙（Communication）

症状

诊断

修复方案

案例 3：协同开销（Coordination）

症状

诊断

修复方案

生产故障排查

工具映射

C\(^3\) 记分卡

C³ 基础设施诊断决策树与集群 D·A·M 记分卡

遥测信号到 C\(^3\) 墙的映射

诊断决策树

结构化诊断遥测表

集群 D·A·M 记分卡

从 C\(^3\) 视角审视规模定律

为什么规模定律假设 C\(^3\) 处于理想状态

有效 FLOP/s 的概念

摘要