企业官网建设流程全解析

这系列聊到第三篇，也该动点真格的了。前两篇把MFU的口径怎么定义、怎么采样、怎么找到瓶颈讲清楚了，这篇就直接回答最核心的问题：在智算数据中心的千卡集群上，MFU到底怎么往上提？

先说明白一件事：MFU全称是Model FLOPs Utilization，模型算力利用率。它衡量的是GPU在训练过程中真正用于“算模型”的时间占比，而不是跑分软件里的峰值数字。人工智能模型的训练成本大头就是GPU时间，GPU时间就是钱，MFU直接决定了你付出去的每一块GPU能把多少算力变成有效产出。智算数据中心这些年越建越多，但如果你去翻真实运营数据，大量训练任务MFU长期卡在35%到50%之间，算力资源被通信等待、数据加载、算子低效白白吃掉了一大半。这篇文章适合算法工程师、AI Infra工程师、智算中心平台上的人来对照着抄作业，也适合刚接触分布式训练的人建立“性能优化该从哪下手”的完整框架。

1. 先认清MFU的口径和优化边界

1.1 两个公式、两种口径

MFU的标准公式其实非常简单：

MFU = (单次迭代模型计算量FLOPs × 总迭代次数) ÷ (GPU卡数 × 单卡峰值FLOPS × 总耗时秒数)

关键是分母里“总耗时”怎么取。这里存在两种完全不同的口径，我在实际工作里被这个坑过不止一次。

第一种是“全局MFU”，分母里的耗时就取整个训练任务的墙钟时间，从任务启动到结束的所有时间都算进去。这种口径最诚实，它把数据加载、通信等待、checkpoint停顿、偶发降频全部算进成本，反映的是你在智算中心真实花的钱产生了多少有效算力。

第二种是“局部MFU”，分母只取GPU在计算流里“忙碌”的时间，通信等待、数据等待全被过滤掉。这种口径适合做单点算子优化对比，但跨集群跨任务对比时没有意义，因为不同的人会过滤掉不同的部分。

我用实际数字解释一下差距。假设用64张A100 80G训练一个70亿参数的稠密模型，序列长度4096，global batch size是512条序列。前向加反向每个token的FLOPs大约是参数量的6倍，那么单次迭代的计算量是：

512 × 4096 × 6 × 7×10⁹ ≈ 8.8×10¹⁶ FLOPs

A100 80G的BF16稠密峰值算力312 TFLOPS，也就是每秒3.12×10¹⁴ FLOPs。64张卡的理论峰值是每秒1.9968×10¹⁶ FLOPs。如果MFU是100%，每一步理论耗时5秒左右。但实际训练中你去看，10秒一步是常见水平，甚至更慢。用全局口径一算MFU只有44%，这时候再去看局部MFU，可能显示GPU计算流水线本身占用率80%，给你一种“已经优化到位”的错觉。这两个数字的天壤之别，恰恰就是通信、IO和调度浪费所在的地方。

所以我的建议很直接：对外汇报、算成本、做集群排期，一律用全局MFU；做代码层面的算子级调优，可以看局部MFU辅助定位，但不要拿它当绩效指标。

1.2 瓶颈拆解的基本框架

把MFU低下这个结果拆开，本质上是GPU的有效计算时间被四类问题侵蚀了。我习惯把GPU的时间占比画成一个饼图，逐项量化：真正在跑Tensor Core做矩阵乘法的有效计算时间、参与集合通信的等待时间、等待数据从CPU传到GPU的时间、各种调度与冗余操作的时间。

第一类“算子效率低”属于计算侧问题。典型的例子是没有启用FlashAttention时，注意力计算把中间矩阵S写回显存再读出来，一次注意力操作要多出好几轮HBM读写，SM（流处理器）大部分时间在等显存而不是在算。还有矩阵乘法没用上Tensor Core，或者是padding太碎导致计算形状不整齐，Tensor Core利用率上不去。

第二类“通信等待”是分布式训练最典型的问题。梯度allreduce是同步操作，每一轮迭代跑完反向传播后，所有GPU必须等彼此的数据合并完成才能开始下一轮。如果你的通信时间占迭代总时长的30%，即使计算流水线内部已经很高效，全局MFU也必然低。

第三类“数据等待”是数据集、数据加载配置不合理导致的。最常见的是海量小文件读取得极慢，dataloader的worker数量不够，或者shuffle在CPU侧做得太重，导致GPU把算力空转着等下一批数据。

第四类是“调度浪费”，比如checkpoint同步写盘造成周期性的停顿，比如少量GPU因为电源策略降频拖慢了整个集群，再比如容器绑核没有绑好导致CPU侧的梯度归并环节跟GPU抢资源。

每次优化之前先做量化分类，不要凭感觉动手。哪怕只是用nvidia-smi dmon定时记录GPU利用率和显存利用率，再在训练脚本里打印每一步的耗时曲线，你都能快速识别出主要矛盾在哪一类。多数情况下，你只会遇到一到两个主要瓶颈，把这两个按下去MFU就能有肉眼可见的提升。

2. 计算侧优化：让GPU把算力花在“有用的地方”

2.1 算子融合与FlashAttention原理

计算侧优化的核心一句话：让GPU多算、少等。GPU里的SM计算单元和HBM显存之间存在巨大的速度差，很多算子看起来在“算”，实际上绝大部分时间在等显存搬运数据。算子融合的思路就是减少中间结果的显存读写，把多个小算子合成一个kernel，数据尽量留在片上寄存器或共享内存里处理完。

FlashAttention就是这类优化的代表。标准注意力计算需要三步：先算Q乘K得到形状为[seq_len, seq_len]的S矩阵，再把S写入HBM；接着对S做softmax，又把结果写回HBM；最后再乘以V。每一步都在HBM和SM之间来回搬运，长序列场景下这个开销巨大。FlashAttention把整个注意力计算分块地在片上完成，softmax通过在线统计最大值来修正，避免了大矩阵的频繁写出。效果就是同样的注意力计算，HBM读写量降低数倍，SM真正在算的时间占比明显提升。

在PyTorch里不需要自己实现FlashAttention，直接用内置接口就可以：

import torch.nn.functional as F attn_output = F.scaled_dot_product_attention( query, key, value, is_causal=True )

PyTorch 2.0以上版本会根据输入形状和硬件自动选择flash attention还是memory-efficient attention的kernel。设置torch.backends.cuda.enable_flash_sdp(True)可以强制启用，但要注意部分GPU架构和半精度组合不兼容，测试时留意是否回退到普通kernel。

还有一个容易被忽略的计算侧配置是TF32。A100及以上型号支持TF32格式，它比FP32精度低一些，但矩阵乘法的吞吐可以翻倍。如果你训练的是常规大模型，数据和梯度都不需要FP32级别的矩阵精度，直接开启：

torch.backends.cuda.matmul.allow_tf32 = True torch.backends.cudnn.allow_tf32 = True

这两行代码在兼容性测试通过的情况下基本等于白捡的算力，但注意对比开启前后的loss曲线，确认收敛轨迹没有明显恶化。

2.2 用PyTorch 2.0把计算图“压”平

PyTorch 2.0以后的torch.compile是一个真正值得重点投入的方向。它通过Triton把Python层面的算子调度编译成更高效的GPU kernel，自动做算子融合、内存规划，甚至可以自动插入部分激活重计算。

我实测过一个80亿参数的模型，启用torch.compile后单步耗时下降了8%到12%，收益主要来自两个地方：一是inductor后端的fuser把小算子融合成了大型kernel，二是编译时把固定的张量形状和布局做了专门优化，省掉了运行时反复的shape推导和内存分配。

model = torch.compile(model, mode="reduce-overhead")

reduce-overhead模式会对每次CUDA graph捕获做额外优化，减少kernel启动开销，特别适合训练步数多、单步计算量不是特别大的模型。不过torch.compile不是开箱即用的，编译过程中如果遇到动态shape、自定义算子、或者某些控制流，可能产生graph break，导致编译后的图分成多段，性能反而下降。排查方法是在编译时设置环境变量TORCH_LOGS="graph_breaks"，看日志里报了多少处graph break。我的经验是：如果graph break超过十几处，先静态化你的输入形状和attention mask，去掉不必要的Python控制流，再重新编译。

对于数据并行训练，static_graph=True也可以减少DDP第一次前向反向时对autograd图的重复分析开销：

ddp_model = torch.nn.parallel.DistributedDataParallel( model, device_ids=[local_rank], gradient_as_bucket_view=True, static_graph=True, )

gradient_as_bucket_view=True让参数梯度直接写到DDP的bucket对应视图里，省一次拷贝。这些参数对大规模训练的性能影响不算巨大，但组合起来可以省掉好几个百分点的开销。

2.3 激活重计算：一张“此消彼长”的牌

激活重计算（Activation Recompute，也叫activation checkpointing）的策略是在前向传播时丢掉部分中间激活值，反向传播用到这些激活时再重新前向计算一次。它的直接作用是大幅降低显存占用，让你能把global batch size调大、序列长度调长，或者用更激进的并行策略。

但这里有一个必须讲清楚的误区：如果你拿MFU当作唯一指标，激活重计算会让MFU数值变差。因为在全局MFU的公式里，分母的总时间变长了（反向时多算了重计算的前向FLOPs），而分子的模型有效计算量没有变。我见过有人把recompute全部打开后，发现MFU从50%掉到40%，急急忙忙回滚配置，这就是典型的不理解指标含义造成的误判。

正确的思路是：激活重计算的本质是用算力换显存，算力多了但显存成为瓶颈时它才有意义。建议优先使用selective recompute，也就是只对选定的几个模块（比如注意力模块和FFN模块的第一层）做重计算，而不是全模型一层不落的recompute。PyTorch纯手工实现比较麻烦，但可以用torch.utils.checkpoint.checkpoint包装具体子模块来做到精确控制。我的实测经验是，在64卡A100集群上训练7B模型，用selective recompute把显存压下来之后，batch size可以放大一倍，此时虽然MFU数值略有下降，但每秒处理的token数吞吐是实打实提升的。在你做决定之前，先想清楚自己的目标到底是MFU这个比值还是单位时间的有效吞吐。

3. 通信优化：把等待时间从主链路里赶出去

3.1 梯度同步为什么吃掉大量MFU

分布式训练里最影响MFU的往往是通信，而不是计算。以数据并行为例，每个GPU独立算前向和反向得到本卡的梯度，然后在迭代末尾做一次全局allreduce把梯度求和，每个GPU拿到完整梯度后才会开始下一轮迭代。在allreduce完成之前，所有GPU都在等最后一块拼图。

深度学习的梯度是逐层产生的，反向传播按时间顺序从前向后算，但DDP做allreduce却要等所有梯度算完才开始，在通信期间GPU计算单元是完全空闲的，这段时间直接算进全局MFU分母，就是实打实的浪费。PyTorch DDP为了解决这个问题，把梯度按参数顺序切成多个bucket，每个bucket填满就立刻对该bucket的梯度发起allreduce，而不是等全量梯度算完。这样一来，反向传播后半个阶段，通信和计算是重叠进行的。

ddp_model = torch.nn.parallel.DistributedDataParallel( model, device_ids=[local_rank], bucket_cap_mb=25, gradient_as_bucket_view=True, static_graph=True, )

bucket_cap_mb这个参数很多人在默认值上用到底，其实它直接影响通信和计算的重叠效率。bucket太小，通信次数会变多，每次通信的固定开销占比上升；bucket太大，通信不能及时开始，仍然要等。我在7B模型上实测，默认25MB时通信等待尾巴明显，改成50MB到100MB后部分层的通信能更平滑地跟反向计算重叠。这个参数没有绝对最优，跟模型大小、层数、网络延迟都有关系，建议跑一组阶梯值对比每一步耗时。

3.2 NCCL和网卡的“玄学”参数

NCCL是NVIDIA官方的高性能集合通信库，分布式训练通信路径上九成的问题都出在NCCL配置不合理。下面这组环境变量是我在智算中心常见的IB网络环境下实测有效的组合：

export NCCL_BUFFSIZE=16777216 export NCCL_IB_TIMEOUT=22 export NCCL_IB_QPS_PER_CONNECTION=4 export NCCL_IB_GID_INDEX=3 export NCCL_SOCKET_IFNAME=ib0 export NCCL_NET_GDR_LEVEL=3 export NCCL_NET_GDR_READ=1 export TORCH_DISTRIBUTED_DETAIL=1 export CUDA_DEVICE_MAX_CONNECTIONS=4

逐条解释一下我的理解。NCCL_BUFFSIZE是NCCL通信缓冲的大小，调大后大消息传输更稳定，但会多占显存；NCCL_IB_TIMEOUT设成22是为了避免IB网络偶发抖动导致通信超时；NCCL_IB_QPS_PER_CONNECTION控制每个连接的队列对数量，有一定带宽调优空间；NCCL_NET_GDR_LEVEL和NCCL_NET_GDR_READ控制GPUDirect RDMA路径，让数据直接从显存经过网卡传输，绕过CPU的中转拷贝，这个对多机训练的收益非常明显，但前提是网卡必须和GPU在同一NUMA节点上且支持GDR，否则可能适得其反。

这里必须说我踩过的坑：网上很多NCCL环境变量是从别人机器上抄来的，直接搬到自己环境里可能毫无收益甚至变慢。关键在于先确认你的网络拓扑。用nvidia-smi topo -m看GPU和网卡的PCIe拓扑关系，用ibstat确认IB网卡状态，再用nccl-tests做基准测试验证改动是否有效。盲目堆参数不是调优，是玄学。

3.3 通信基准测试：用数据说话

所有通信优化的第一步都应该是跑NCCL官方自带的基准测试。从nccl-tests编译出的build/all_reduce_perf可以直接测量allreduce的带宽和延迟：

./build/all_reduce_perf -b 128M -e 8G -f 2 -g 8 -t 2

参数含义是：从128MB到8GB规模，倍率2，用8个GPU跑2轮。输出中的busbw是算法带宽，它除以单卡理论带宽（比如100G HDR IB的12.5GB/s，NVLink3.0单向25GB/s）再乘以2，就得到实际能达到的效率比例。如果在单机8卡内跑出来的busbw只有理论NVLink的60%，那说明单机内通信有瓶颈；如果16卡两机跑出的busbw连单机的一半都不到，多半是IB网卡或GDR路径没有生效。

我在线上环境做过一次比较：NCCL环境变量全默认时，两机间的allreduce busbw只有11GB/s；把GDR和IB参数调整后，提升到21GB/s，接近25GB/s的物理上限。而这一个改动直接让训练脚本的单步耗时下降4%，全局MFU从48%升到52%。这个数据背后就是通信等待时间实实在在地缩短了。

3.4 MoE模型的额外通信负担

如果你的智算中心主要跑的是MoE（混合专家）模型，通信问题会更突出。MoE模型里每个token会被路由到不同的专家模块处理，专家分布在多张GPU上，导致每轮迭代都伴随着大量的all-to-all通信，这比多机间的allreduce还要昂贵。同时，路由算法不均匀会导致某些GPU上的专家负载过大，其他GPU先算完等待，形成负载失衡型的等待。

这类场景下的优化方向一般是两个：一是使用aux loss对路由做负载均衡约束，让token在专家上的分布尽量均匀；二是牺牲少量计算精度做专家并行的通信压缩，比如对all-to-all传输的中间激活做低比特量化，减少通信字节量。但这两个方向都涉及占用比例和收敛质量的权衡，不建议在没做定量分析前就盲目上。

4. 数据加载与集群调度：另一种“看不见”的算力浪费

4.1 DataLoader流水线配置要点

在很多人只盯着NCCL通信调参的时候，我想说一下数据加载问题。它不像通信和算子优化那么“性感”，但在实际智算中心里，数据侧造成的MFU损失经常比重前问题还要高。尤其是CV和多模态任务用的海量小文件数据，一个epoch有几万甚至几十万个独立小文件，读取耗时极慢，GPU只能干等。

做好数据加载的要点可以分三层。

第一层是把数据物理格式改成大文件。把海量小文件打包成webdataset格式的tar包，或者用TFRecord格式，让每个文件尽量大，减少文件系统的inode寻址次数。同样一批训练数据，从这个改动上可以获得5%甚至更高的吞吐提升，比调任何深度学习超参数都直观。

第二层是配置合理的DataLoader参数。num_workers要根据CPU核心数和IO等待类型来设，普通SSD环境下8到16个worker就够了，更多不一定更好；prefetch_factor加大可以让CPU提前准备多个batch的数据，隐藏IO延迟；persistent_workers=True可以避免每个epoch结束重建worker；pin_memory=True让CPU侧数据锁页，加快H2D拷贝。

dataloader = DataLoader( dataset, batch_size=8, num_workers=12, prefetch_factor=4, persistent_workers=True, pin_memory=True, )

第三层是看训练日志里数据加载是均匀地慢还是周期性地卡顿。如果是均匀地慢，优先改格式和prefetch；如果是周期性卡顿，重点排查是否每次shuffle都在重新建索引，或者eval阶段混杂着大量数据预处理。

4.2 Checkpoint、慢卡与锁频

数据加载之外，checkpoint写盘是另一个常见的“周期黑洞”。有些训练框架每个epoch或每固定步数同步写checkpoint，写盘期间所有GPU都停下等IO完成。如果这个时间占总耗时的比例不小，一定要改成异步checkpoint。实践做法是：先异步把模型权重写到本地NVMe盘上，再在后台异步上传到对象存储或并行文件系统，训练主进程完全不等待。改动量不大，但能把周期性的尖峰延迟抹平。

另一个容易被忽视的是“慢卡效应”。分布式训练是木桶效应，全集群最快的那张卡也要等最慢的那张卡。我遇到过一台GPU因为散热问题触发降频，SM时钟从官方标称的1410MHz掉到1200MHz，单步时间比别卡慢8%，整个集群都被它拖慢了。排查方法是周期性地用nvidia-smi --query-gpu=name,temperature.gpu,clocks.sm,clocks.mem,power.draw --format=csv记录所有GPU的状态，凡是时钟或温度明显偏离平均水平的机器，直接定位出来。为减少这种波动，在GPU温度和功耗余量允许的情况下，可以用nvidia-smi -lgc 1410锁住SM时钟频率，让训练速度稳定可预期。锁频需要管理员权限，普通用户机权限不够时只能靠平台侧设置。

4.3 拓扑亲和：CPU、内存和网卡都要贴对地方

集群调度层面的优化比代码层面更容易被忽略的是NUMA亲核性。GPU和CPU、网卡之间通过PCIe相连，如果GPU所在NUMA节点和容器绑定的CPU核心、内存节点不一致，每一次数据搬运都要跨越NUMA域，性能损失可以达到20%到30%。

用nvidia-smi topo -m先确认GPU和网卡属于哪个PCIe switch域，然后部署容器时用--cpuset-cpus和--cpuset-mems把容器限制在对应NUMA节点上。容器平台创建任务时也要注意，让同一个训练任务的所有进程尽量落在同一台物理机的同一NUMA拓扑内。这个优化在单机多卡场景尤其重要，多机场景则要先确认IB网卡和GPU之间的GDR路径是否畅通。

docker run --gpus '"device=0,1,2,3"' \ --cpuset-cpus=0-31 --cpuset-mems=0 \ --shm-size=32g \ training:latest

--shm-size也要给足，因为DataLoader的lock页内存和共享内存会占用/dev/shm，默认2MB经常不够用，导致多worker的IPC失败或性能骤降。

5. 一个实操案例：把64卡训练MFU从38%提到52%

5.1 基线环境与取样方式

拿一个真实跑过的案例说明完整流程。环境是64张A100 80G，8台机器每台8卡，IB 200Gbps网络，训练一个70亿参数的稠密语言模型，序列长度4096，使用ZeRO-2加张量并行4。基线配置下每一步耗时10.2秒，用全局MFU公式计算：

单步FLOPs = 512 × 4096 × 6 × 7×10⁹ ≈ 8.8×10¹⁶ 理论峰值 = 64 × 3.12×10¹⁴ = 1.9968×10¹⁶ FLOPs/s MFU = 8.8×10¹⁶ / (1.9968×10¹⁶ × 10.2) ≈ 43%

注意这里的10.2秒已经包括了同步的时间，我用的是全局墙钟口径，不是只算GPU计算流的时间。

分析工具用PyTorch Profiler加Nsight Systems。在训练脚本里对单个step做profile时，重点关注GPU Kernel时间和空闲时间段的分布。从trace里能明显看到三个问题：注意力计算用的是标准实现，kernels之间的缝隙很大；每次迭代结束DDP的allreduce尾巴拖得比较长；数据加载在每步开始后1.5秒才把数据送到GPU。

5.2 逐步优化过程与收益对照

优化不是一次性做完的，我按下面这个顺序逐步推进，每做一步就重跑一次trace确认收益方向。

第一步换scaled_dot_product_attention，让PyTorch自动选用flash attention kernel，并顺手开启TF32矩阵计算。单步耗时从10.2秒降到9.4秒。这一步收益最大，因为注意力计算在整个Transformer里的占比很高，而且flash attention减少了大量HBM读写。

第二步调DDP bucket配置，bucket_cap_mb从25改到50，加上gradient_as_bucket_view=True和static_graph=True。单步耗时降到9.0秒。这一步让梯度通信更早开始，反向计算和通信重叠得更充分。

第三步调整NCCL环境变量，主要是打开GPUDirect RDMA相关的路径并调大buffer。单步耗时降到8.7秒。同时用nccl-tests确认两机间的allreduce带宽在参数前后有明显变化，确保这一步的收益不是玄学。

第四步优化DataLoader，把数据从海量json小文件改成webdataset的tar包格式，调大num_workers到12并开启persistent_workers和pin_memory。单步耗时进一步降到8.4秒，每步开始前的数据等待基本消失。

第五步锁SM时钟并确认所有机器无降频，单步耗时稳定在8.5秒附近。最终MFU算下来：

MFU = 8.8×10¹⁶ / (1.9968×10¹⁶ × 8.5) ≈ 52%

从43%到52%，九个百分点的提升，主要来源是通信重叠和数据IO。整个过程中没有改模型结构、没有动超参数，纯粹是靠系统的优化。

5.3 优化后的“此起彼伏”

做完这一步后我并没有停下来。训练跑到第十天时发现单步耗时出现周期性尖峰，每个大循环中间总有几步明显变慢。排查后发现是checkpoint写盘堵住了后台的IO路径，占用了DataLoader的磁盘带宽。改成异步checkpoint后尖峰从3秒降到0.3秒，训练稳定性大幅改善。

还有一个心得：调优过程中的每一项改动都要能跟某个具体的耗时数字挂钩。改DDP参数时，要能从trace里看到“allreduce等待尾巴缩短了”；改DataLoader时，要能看到“数据到达GPU时间提前了”。如果改动只是让整体数字模糊地变好了一点点，不要急着保留，先回到有用的环节确认它为什么变好。因为没有解释的性能提升，到了下一轮环境变化时会莫名其妙地消失。

6. 常见问题与排查技巧实录

6.1 三个高频症状与排查路径

症状一：迭代时间周期性上升。每隔k步出现一次尖峰延迟，其余步正常。优先怀疑三类原因：checkpoint同步写盘、周期性日志或评估任务抢占IO、数据加载时候的shuffle重建。从训练日志里对齐时间戳，把每次尖峰与checkpoint或日志任务关联起来，就能快速定位。

症状二：多卡利用率不均衡，有的卡被跑满，有的卡GPU利用率只有百分之几十。在单机多卡场景下优先看是不是CPU线程绑核不均匀，某个进程的CPU线程全挤在一个NUMA节点上；在MoE模型场景下优先看专家路由是否均衡。

症状三：单机性能很好，扩展到几十卡后性能不线性增长。优先跑nccl-tests，确认多机allreduce带宽是否达到物理上限；再检查IB网卡的GDR是否生效，nvidia-smi topo -m确认网卡和GPU拓扑是否合理。如果网络本身没有瓶颈，再去看是否所有机器间的拓扑一致，有些机器可能因为PCIe插槽位置不同，导致部分GPU的带宽天生小于其他GPU。

6.2 排查命令与工具清单

我把平时最常用的一组命令整理成了表格，遇到问题时直接按表执行，避免临场手忙脚乱。

6.3 哪些“优化”不值得做

最后说几个我在业务里见过很多人做但实际效果不大甚至有反效果的操作，帮大家少走弯路。

第一类是无脑开启全模型激活重计算。前面提过，recompute提升显存容量却拉低MFU数值，在显存不紧张的情况下只增加计算开销。正确做法是selective recompute只包选定的模块，或者干脆不开。

第二类是梯度压缩。把梯度从FP32压成BF16再做allreduce，可以减半通信量，但很多模型会出现收敛精度下降。虽然论文里说有一些补偿方案，但实际工程里的收益很容易被重调参成本吃回去。对大部分稠密模型，优先优化通信重叠机制，不要轻易上梯度压缩。

第三类是盲目追求Zero-3替代Zero-2。ZeRO-3把参数和优化器状态也分片了，显存占用更低，但每一步都需要额外的all-gather通信来恢复参数。如果显存够用，ZeRO-2配合合适的张量并行组合往往比ZeRO-3吞吐更高。把并行策略当成一个搜索空间来测，不要默认最激进的方案就是最好的。

第四类是反复修改NCCL环境变量但不跑基准测试。调了NCCL_BUFFSIZE就以为通信变好，但实际所有环境变量都应该以nccl-tests的busbw结果为准，没有数据支持的调参只能算自我安慰。

我自己做AI基础设施优化这几年最深的体会是：MFU是结果指标，不是优化目标本身。每做一项改动，都要能定位到“它到底减少了哪一段浪费的时间”，只有找到了浪费，优化才真正有价值。智算中心的每一块GPU都在烧钱，MFU每提升一个百分点，都是实打实的成本节省。这篇文章里的每一步方法都可以在真实环境里复现，但别把所有参数原封不动搬走，先用工具量出你自己集群的瓶颈在哪里，再对症下药，效果会比盲目抄配置好得多。