大模型训练提速：MindSpeed 融合优化原理与实战

1. 大模型预训练的真正瓶颈算力都耗在了哪里先明确一件事MindSpeed 并不是某个新出的模型而是昇腾生态下专门为大模型训练打造的加速库。我最早接触到它是在训练一个百亿参数规模的稠密语言模型时。当时我们团队已经搭好了完整的训练流程——数据 pipeline 没问题模型结构没问题Loss 也能正常下降但 GPU当时还是用的其他加速卡利用率始终上不去MFU 长期徘徊在 30% 上下。后来团队把训练迁移到昇腾环境配合 MindSpeed 做改造才真正把 MFU 拉到了 45% 以上。这个提升不是某一个优化点带来的而是一整套融合优化的组合拳。想理解 MindSpeed 的融合优化先要理解一个大模型预训练过程中算力到底浪费在了什么地方。表面上看起来训练就是前向传播、反向传播、参数更新这三个大步骤。但放到分布式环境下每一步都会产生大量的额外开销——张量并行时每个 Transformer 层的输出都要做 AllReduce把切分在不同卡上的数据拼回来流水线并行时相邻 stage 之间要搬运 activation 和梯度序列并行时LayerNorm 和 Dropout 这类算子要处理跨卡的数据依赖。通信量一旦上来卡就算在疯狂计算也有一大半时间在等着别人把数据传过来。除了通信开销还有显存瓶颈。大模型预训练时 activation 占用的显存是极其夸张的。以 GPT-3 175B 为例光 activation 就可能占掉几百 GB 显存不做任何优化根本塞不进单卡 80GB 的显存里。传统方案是重计算Recompute把前向的 activation 丢掉、反向时重算一遍用算力换显存。但重计算的比例如果太高等于白白浪费了一倍的计算量MFU 照样上不去。MindSpeed 的融合优化就是在这些维度上做文章把通信和计算重叠起来把多个小算子打包成一个大算子减少访存和 kernel 启动开销把不同并行策略编排得更合理让每一张卡都在有效工作而不是空等。这套东西不是昇腾独有的思路PyTorch 的 DDP 也有梯度桶 AllReduce、NVIDIA 的 Megatron 也做算子融合但 MindSpeed 针对昇腾硬件的特性做了大量底层适配很多优化是直接跟昇腾的 HCCL集合通信库和 AOE算子自动调优工具打通的。这篇文章我想把我在实际项目中验证过的融合优化路径完整梳理一遍从原理到配置到踩坑尽量讲清楚为什么这么干以及实际效果如何。2. 通信与计算的重叠而不是交替2.1 为什么 AllReduce 是大模型训练的隐形时间黑洞先看一个最基本的场景张量并行Tensor Parallelism下每个 Transformer 层的 MLP 结构通常是这样拆分的——输入 x 通过 Column Parallel 的 Linear 层切到多张卡上各自算出一部分结果然后经过 Data Parallel 的 AllReduce 把各卡结果加起来再进入 Row Parallel 的 Linear 层。也就是说每一层 Transformer 里至少有一到两次 AllReduce 通信。这张图我想你在脑子里建立一个印象就行通信不是在计算完成之后顺便做一下它是整个训练 step 的关键路径的一部分。如果通信耗时 10ms计算耗时 20ms那一层 Transformer 的总耗时就是 30ms。哪怕你把计算优化得再快通信这一块不压掉层耗时永远卡在计算通信串行累加的结果上。MindSpeed 解决这个问题的核心手段叫通信与计算重叠本质上就是把通信回调函数提前注册到计算流上让 AllReduce 的数据准备好一部分就先把这一部分发出去同时另一部分数据还在计算。用并发编程的话说就是把原来先算完、再通信的串行依赖拆成边算边通信的流水线。具体到工程实现上MindSpeed 会把通信拆成多个 chunk。以 AllReduce 为例一整块大 tensor 不会被一次性发完而是切成若干个小块每个小块数据就绪后立刻发起通信不需要等整块 tensor 都算出来。这样通信的耗时就能藏在后面那些 chunks 的计算时间后面。我在实际测试里遇到过一种很典型的情况在 32 卡环境训练一个 13B 模型不开启通信计算重叠时一个 step 的平均耗时是 3.2 秒开启重叠优化之后一下子掉到了 2.1 秒。这个提升不是说通信不花时间了而是通信时间被并进了计算时间里面从关键路径上消失了。2.2 MindSpeed 的通信流与计算流分离机制要真正把通信藏到计算后面单单靠cut tensor into chunks还不够还需要在软件层面支持多流并行。MindSpeed 的做法是在昇腾的 CANN 层之上把通信流Communication Stream和计算流Compute Stream分开管理。这里有一个很多人容易忽略的细节多流并用不是随便 create 几个 stream 就行关键是要正确同步。计算流在往某个 chunk 里写数据的时候通信流不能去读这个 chunk否则就会读到还没算完的垃圾数据。MindSpeed 的做法是给每个 chunk 设置事件Event计算流算完一个 chunk 就记录一个 event通信流要等到对应 event 到达之后才开始搬运这个 chunk。下面是一个简化的伪代码逻辑# 伪代码MindSpeed 通信计算重叠的基本逻辑 for each micro_batch: for each layer: x column_parallel_linear(x) # 前向计算按chunk计算 for chunk in output.chunks(k): event[chunk].record(compute_stream) # 该chunk数据已就绪 for chunk in output.chunks(k): comm_stream.wait_event(event[chunk]) comm_stream.all_reduce(chunk) # chunk级通信 event_allreduce.record(comm_stream) compute_stream.wait_event(event_allreduce) x row_parallel_linear(x)实际实现比我这个伪代码复杂得多但核心思路就是这样。值得说明的是chunk 数量 k 的选择是一个关键的超参。k 太小重叠效果不明显k 太大通信次数变多HCCL 每次通信都有固定的建立开销反而会拖慢速度。以我在昇腾 910B 环境上的测试经验对于 200MB 左右的梯度 tensork 取 4~8 是比较合理的范围。你可以用 MindSpeed 的 profiling 工具看通信流的空闲率如果通信流大部分时间在等事件说明 k 偏小如果计算流经常因为通信未完成而阻塞说明 k 偏大。2.3 梯度 AllReduce 的融合把上千次小通信合并成几十次除了前向过程中的 AllReduce反向传播时的梯度同步也是一个大头。用 PyTorch 原生 DDP 训练大模型你会发现每个参数 tensor 在反向算完梯度后都会触发一次 AllReduce。一个 13B 模型可能有几百甚至上千个参数 tensor如果每个 tensor 都独立做一次 AllReduce那光通信建立开销就是一个灾难。MindSpeed 借鉴了 DDP 的梯度桶Gradient Bucket思路但做了进一步融合——它会把同一层或者相邻层的梯度 tensor 动态拼接成一个大的梯度桶然后对桶整体做一次 AllReduce。这就好比你搬家与其跑一百趟搬一百个小箱子不如把箱子先捆成几个大堆用大卡车一次性拉走。这里有一个在 PyTorch DDP 和 MindSpeed 里都存在的经典问题梯度桶的切分边界怎么确定如果桶太大必须等所有梯度都就绪才能开始通信重叠效果变差如果桶太小通信次数太多。MindSpeed 的默认策略是按照参数的存储顺序把梯度累积到一定大小比如 25MB就封一个桶同时保证不同 bucket 之间的前向依赖关系尽量一致这样可以在反向传播的过程中边算边通信。我自己的调参经验是在千卡规模训练时梯度桶大小对 MFU 的影响可以达到 5~8 个百分点。昇腾环境里梯度桶建议设置在 20MB 到 40MB 之间太小了通信次数多太大了通信等待时间长。MindSpeed 里对应的配置项是--gradient-bucket-size单位是 MB。你可以通过 mindstudio profiler 观察通信占比来反复调整。3. 算子融合从频繁搬运到一次打包3.1 融合的两个目标减少访存、减少 kernel 启动通信问题解决之后再来看单卡上的计算效率。大模型 Transformer 的每一个层里除了矩阵乘法这类计算密集型算子还有很多小算子——LayerNorm、Dropout、Residual Add、ActivationGELU、Softmax 等等。这些小算子本身计算量不大但每一个都要经历把数据从全局内存搬到寄存器或共享内存、计算、写回全局内存的过程。如果这些算子各自独立执行就会出现一个很尴尬的局面计算时间没多少访存时间占了大头。举个例子LayerNorm 需要对一行数据做两次遍历——第一次算均值和方差第二次做归一化。如果只算 LayerNorm数据已经来回搬运了两趟如果你还要做 Residual Add数据又被拖出来加一遍再放回去。一顿操作下来真正有用的算力没多少大部分时间都在等待内存读写。MindSpeed 的融合优化就是把这些小算子在计算图层面合并成一个大的 fused kernel。LayerNorm Residual Add Dropout 这三个操作可以融合成一个算子数据从全局内存读一次依次完成归一化、加残差、随机失活最后写回一次。原来三次访存变成一次访存kernel 启动次数也从三次变成一次。我做过一个粗略的实验对比把 Transformer 层的 LayerNorm、Residual Add、Dropout 替换成 MindSpeed 的融合版之后单层前向耗时降低了大约 30%。这个 30% 不是凭空变出来的算力恰恰是把之前浪费在访存和 kernel 启动上的时间省下来了。3.2 Flash Attention 类融合计算强度与显存占用的双优化注意力机制的融合是另一块大头也是近两年大模型训练提速的关键突破。FlashAttention 的核心思想其实不复杂传统 attention 实现需要先算 S Q K^T然后把完整的 S形状是 [batch, heads, seq_len, seq_len]存到显存里再对它做 Softmax再与 V 相乘。这个 S 矩阵的显存占用是序列长度的平方序列一长显存直接爆掉。FlashAttention 的做法是在 SRAM 和 HBM 之间做分块处理——不生成完整的 S 矩阵而是分成小块在 SRAM 里完成 Softmax 计算后马上乘 V把结果累加写回。这样显存占用从 O(n^2) 降到了 O(n)同时因为减少了 HBM 访存计算效率也大幅提升。MindSpeed 里对齐实现的融合注意力算子除了包含 FlashAttention 的分块计算逻辑还把 Dropout、Mask 之类的操作一并融进去了。实际使用中我在一个 7B 模型上对比过开启融合注意力和不开启的显存占用序列长度 4096、batch size 16 的情况下activation 显存节省了大约 40%step 时间也缩短了约 18%。3.3 用 AOE 做算子自动调优不要迷信默认配置说到算子融合不得不提昇腾的 AOEAscend Optimization Engine。MindSpeed 在首次编译模型时可以调用 AOE 对融合算子做自动调优——它会根据你的模型结构、输入 shape、硬件型号自动尝试不同的算子切分方式、buffer 大小、融合策略选一组最优参数。我的建议是在大规模训练之前一定要单独跑一次 AOE 调优把生成的aoe_data和最佳配置保存下来。这一步看起来耗时一个 7B 模型可能要跑两个小时但对后续整个训练周期的收益非常显著。我踩过一次坑有次直接在训练命令里加了--auto-tune参数让 AOE 在训练过程中并行调优。结果模型刚开始训练那几百个 step 各种不稳定Loss 偶尔抖动后来排查发现是因为 AOE 在运行时动态改算子实现方式导致前向计算图的数值路径发生了变化和梯度累积产生了冲突。后面改成离线调优、再把配置固化下来问题就消失了。注意AOE 调优的结果跟输入 shape 强相关。如果你的模型支持动态 shape比如序列长度会变化建议把常见的几种 shape 都作为 tuning 的 shape 范围传进去否则 AOE 选出来的最优算子只在固定 shape 下最优。4. 并行策略的融合编排一加一要大于二4.1 三种并行各自为战反而会互相拖累张量并行、流水线并行、数据并行每一种单独拎出来都容易理解张量并行把模型参数切开、流水线并行把模型层数切开、数据并行把 batch 切开。但把这些并行策略组合到同一个训练任务里的时候它们之间会产生复杂的交互。举一个很典型的冲突场景假设你同时用了张量并行TP8和数据并行DP16那一共有 128 张卡。每次反向传播完张量并行的梯度 AllReduce 需要在一个 TP 组内通信数据并行的梯度 AllReduce 需要在 DP 组内通信。如果这两组通信顺序没编排好就会出现通信热点重叠——所有卡同时发起通信HCCL 的网络带宽瞬间被打满大量消息在交换机里排队。MindSpeed 的并行编排策略核心就是解决多个并行维度如何有序地进行通信这个问题。它会根据并行策略生成一个层级化的通信拓扑TP 维度通信量最大、延迟最敏感优先在物理邻近的卡上建立通信域DP 维度通信量相对小可以走得远一点PP流水线并行维度的通信是点对点的量级不大但对顺序敏感。4.2 序列并行与 Zero 优化的融合MindSpeed 的融合优化还有一个很关键的维度就是并行策略和显存优化策略的融合。先看序列并行Sequence Parallelism。Transformer 里的 LayerNorm、Dropout 是沿着序列维做独立计算的理论上跟序列并行天然契合。传统张量并行只拆分 Linear 层的参数但 LayerNorm 和 Dropout 需要所有卡都保留完整副本这样会产生重复计算。序列并行把这两个算子也按序列维度切成多份每张卡只算一段序列最后通过一次 AllReduce 把结果合并。这样省下的不只是重复计算还有每张卡上 activation 的显存占用量。Megatron-LM 提出了名为 Sequence Parallel 的经典做法MindSpeed 在实现时与之兼容同时又跟昇腾的 Flash Attention 算子做了联动。再来看 ZeRO 优化。ZeRO 的思路是把优化器状态、梯度、参数做分布式切分避免每张卡都存一份完整的训练状态。MindSpeed 在 Zero-2只切优化器状态和梯度场景下做得很成熟Zero-3连参数也切分也支持但要注意Zero-3 下参数是每层用时才做 AllGather 取回来的所以对通信的要求更高一般需要配合通信计算重叠一起开才有正收益。我自己的经验是在百亿参数模型、千卡规模以下这个范围Zero-2 往往比 Zero-3 更划算——Zero-3 省下来的显存确实很可观但参数 AllGather 带来的通信开销也很客观。如果你的目标是在有限的卡上跑更大的模型Zero-3 是必须的如果目标是把现有模型训练速度推到极致Zero-2 加流水线并行往往表现更好。4.3 流水线并行下的微批次调度流水线并行最容易被人低估的一点是它的气泡问题。一个流水线有多个 stage前向传播像流水线一样依次流过各个 stage如果调度策略不好stage 之间会大量出现前面的 stage 在算、后面的 stage 在等的空档期这就是气泡。经典方案是 GPU 集群完整地把 batch 切成多个 micro batch 送入流水线让不同的 stage 同时处理不同的 micro batch。微软的 PipeDream 和英伟达的 Megatron 分别提出了不同策略MindSpeed 用的是和 Megatron 类似的调度方案同时增加了一个interleaved模式把模型层切分成更细的多个 stage 副本让每个设备交替处理层区间这样可以显著缩小气泡比例。不过在 40 层左右的常规规模模型上我建议不要开 interleaved——它虽然减少了气泡但会增加 activation 的保存数量和通信次数。层数在 80 层以上时interleaved 的收益才会明显覆盖开销。MindSpeed 里可以用--num-layers-per-virtual-pipeline-stage参数调整 interleaved 的粒度建议从 2 开始试。5. 显存优化的融合视角重计算、Offload 与内存池5.1 选择性重计算不是所有 activation 都值得重算前面提过重计算是用算力换显存。但全部重算显然不是最优解——某些 activation 很小、保留它的显存成本很低某些 activation 很大、但重算它的计算量也很大。这里存在一个平衡点。MindSpeed 的选择性重计算机制允许你指定哪些模块不保存 activation。比如在 100B 量级的模型上Self-Attention 的 activationQ、K、V 矩阵以及注意力分数相关的中间结果占显存很大但重算代价不低而 MLP 中间层的 activation 计算量相对小重算代价低。把 MLP 部分设置为不保存、需要时重算Self-Attention 部分保留这样的组合往往能获得比较好的性价比。相关配置在 MindSpeed 里是通过模型代码中的标志位控制的具体可以查一下你用的模型脚本里Mlp层是否支持recompute_granularity参数。我推荐从full recompute selective recompute 逐步降低重算比例这个路径去调先看显存余量再慢慢把大的 activation 从重算列表里挪出来直到显存刚好够用。5.2 优化器状态 Offload把 CPU 内存也利用起来到了一定规模哪怕 Zero-2 已经把优化器状态切分到各卡上单卡的显存还是压力山大。MindSpeed 提供了把优化器状态卸载到 CPU 内存的选项Optimizer Offload也就是把 Adam 的一阶矩和二阶矩挪到 HBM 之外每步更新参数时再把对应的状态搬回来算。这个选项对显存的释放非常直接但会显著增加通信压力。我个人的经验是它更适合那些显存差一点点、但不希望缩小 batch size的场景。正常训练里有更优的解法就先别碰 offload因为 CPU 与加速卡之间的搬运带宽和延迟跟卡间通信完全不在一个量级开过头了会把训练变成 IO 密集型任务。5.3 显存池与垃圾回收机制的调优在大模型训练中显存碎片化和频繁 malloc/free 也是一个容易被忽视的问题。PyTorch 的缓存分配器Caching Allocator会尽量复用已释放的显存块但遇到训练动态 shape、不同层显存需求差异很大时还是容易产生碎片。MindSpeed 在昇腾环境下做了一层显存池管理把常用的几个显存块如 activation buffer、gradient bucket做预分配和复用。在开启这个机制后我观察到的显存碎片率明显降低训练也更稳定了。这里提一个小经验如果你在 MindSpeed 里遇到了显存足够但申请失败的问题十有八九是显存碎片导致的。可以先尝试把 batch size 稍微调小一点或者调整PYTORCH_NO_CUDA_MEMORY_CACHING昇腾环境可能是ASCEND_NO_MEMORY_CACHING相关设置看看问题是否缓解。不要一上来就怪显存容量不够。6. 融合优化实践的完整配置流程与实测效果6.1 从零到一的训练配置清单我把在昇腾环境上使用 MindSpeed 跑大模型预训练的完整配置过程整理一下照着走一遍基本能跑通一个中等规模的模型。首先是环境准备。MindSpeed 需要配套的 CANN Toolkit、昇腾驱动以及对应版本的 PyTorch。安装 MindSpeed 时一定要严格匹配版本MindSpeed 和 CANN 的版本有一个兼容矩阵如果版本不匹配最常见的现象就是训练跑起来之后报一些莫名其妙的算子执行错误查起来非常费劲。其次模型脚本建议直接用 MindSpeed 官方仓库里配套的模型如 GPT、LLaMA 的实现不要自己写一套因为 MindSpeed 的融合优化点很多是埋在模型实现里的自己写很容易漏掉。关键的训练启动配置参考如下# 13B 模型昇腾 910B 单机 8 卡示例 python train_gpt.py \ --model-type GPT \ --tensor-model-parallel-size 8 \ --pipeline-model-parallel-size 1 \ --num-layers 40 \ --hidden-size 5120 \ --num-attention-heads 40 \ --seq-length 4096 \ --micro-batch-size 1 \ --global-batch-size 32 \ --optimizer adam \ --zero-stage 2 \ --recompute-method uniform \ --recompute-num-layers 12 \ --gradient-bucket-size 25 \ --overlap-grad-allreduce \ --profile几个关键配置项解释一下--tensor-model-parallel-size和--pipeline-model-parallel-size设定张量并行度和流水线并行度。单机 8 卡时TP8、PP1 通常最优因为机内带宽最好。--zero-stage 2开启 Zero-2 优化梯度归约前先做一次 Slice减少通信量。--recompute-method uniform和--recompute-num-layers控制重计算的层数。这个必须根据显存实测结果来调先从多往少试。--overlap-grad-allreduce开启梯度 AllReduce 与反向计算的通信重叠。--profile开启 profiling方便后续分析 MFU。6.2 实测数据融合优化开与不开的差距下面这张表是我在一个 13B 稠密模型、序列长度 4096、单机 8 卡昇腾 910B 环境上的实测数据对比。大家感受一下融合优化的组合效果配置项未开启优化开启核心优化开启全部优化梯度 AllReduce 重叠关开开算子融合关开开Flash Attention关开开AOE 算子调优无无有单 step 耗时4.1s3.0s2.4sActivation 显存占用约 68GB约 42GB约 40GBMFU 估算值约 25%约 37%约 46%可以看到每加一层优化step 时间都在缩短。最让人惊喜的是 Flash Attention 加上去之后显存和速度同步改善——这正是融合注意力把大矩阵拆分成小块带来的效果。另外要提醒的是MFU 这个指标在不同硬件、不同显存带宽模型下的天花板不一样昇腾 910B 的 MFU 和 H 系列卡会略有差距关键是看同一个硬件上优化前后的相对提升。6.3 踩坑记录融合优化不是越大越多就越好我会把融合优化中遇到的几个典型坑放在一起说希望能帮你少走弯路。第一个坑是 AllReduce 的 chunk 数开得过大。一开始我以为 chunks 越多重叠越充分结果从 4 个 chunk 改成 16 个 chunk 之后通信时间反而变长了。原因很简单HCCL 的每次通信都有固定的建立和收尾开销chunk 数从 4 翻到 16通信次数翻了 4 倍哪怕每次通信的数据量变小了总开销依然上升。这个参数一定要用 profiler 实测不要盲目调大。第二个坑是 Flash Attention 和具体 mask 结构的兼容性。如果你的 attention 有非常规的 mask比如前缀 mask、因果 mask 的特殊变形MindSpeed 的融合注意力算子不一定能完美兼容。有次我换了融合注意力之后模型 Loss 不降反升排查了整整一天最后发现是 mask 加法顺序和算子内部的实现细节不一致导致的。遇到这种问题先关掉融合注意力跑一遍如果 Loss 恢复再去对比算子的数值差异。第三个坑是 AOE 调优和超长序列的冲突。AOE 会针对你输入的 shape 范围做优化但如果你训练过程中经常出现序列长度分布极不均匀的情况比如 pack 了很多长样本AOE 选出来的最优算子可能对绝大多数 batch 不是最优的。解决办法是在 AOE 调优时传入你训练数据里最典型的几个 shape而不是所有 shape。7. 给迁移场景的几个定向建议如果你现在有一个正在 PyTorch 或 Megatron 上跑的训练任务想迁移到 MindSpeed 上我的建议是不要一把梭全部改完。先把模型结构对齐到 MindSpeed 的官方实现用单机单卡跑通小 batch确认 Loss 曲线和原来一致然后开启张量并行验证单机多卡的数值一致性再逐步开启算子融合、Flash Attention、通信重叠这些优化项每开一个都记录一下 step 时间和显存变化。最容易出问题的环节是梯度合并与 AllReduce 语义的对应。Megatron 的梯度同步是在桶级别做的MindSpeed 也是但它们的桶划分边界可能不一样这在多机多卡训练时会引入额外的通信差异。如果你发现迁移到多机后扩展性变差优先检查梯度桶的划分方案和通信拓扑设置。另外MindSpeed 的混合精度策略AMP默认是 BF16 FP32 参数副本。如果你的原始训练用的是 FP16迁移时要格外小心——FP16 在梯度回传时容易出现下溢出而 BF16 的精度特性跟 FP16 差别很大。改到 MindSpeed 之后最好重新评估一下学习率和 warmup 策略不要直接用原来的超参。8. 融合度量的两个关键指标MFU 与通信占比最后说一个比较实操的话题——怎么判断你的融合优化有没有做到位。判断标准只有一个关键路径上还有多少时间花在等通信上。如果有 profiler直接看通信算子AllReduce、AllGather、ReduceScatter占据整个 step 时间的比例。在单机 8 卡、TP8 的典型配置下通信占比如果能压到 10% 以下说明通信计算重叠做得不错如果通信占比超过 25%说明调度或者 chunk 划分还有优化空间。MFUModel FLOPs Utilization也是一个直观的指标。MFU 计算方法是MFU 实际计算量(FLOPs) / (GPU数量 × GPU峰值算力 × step耗时)对于 GPT 类稠密模型单个 token 的前向计算量约等于 6N其中 N 是模型参数量。反向传播是前向的 2 倍所以一个训练 step 的总计算量约等于 6N × 3 × tokens_per_step。把这个数除以硬件峰值总算力乘以 step 耗时就得到 MFU。举一个实际的例子13B 模型参数量 N130亿global batch size 32、序列长度 4096那么每个 step 处理的 token 数是 32 × 4096 131072总计算量约等于 6 × 13e9 × 3 × 131072 ≈ 3.06e16 FLOPs。如果 step 耗时 2.4 秒单卡峰值算力约 3.2e14 FLOPs/sBF16总算力就是 8 × 3.2e14 2.56e15 FLOPs/s。MFU 3.06e16 / (2.56e15 × 2.4) ≈ 0.497也就是约 50%。如果 MFU 卡在 30% 左右上不去我会按这个顺序排查先看是不是数据加载是瓶颈CPU 喂不上数据再看通信占比再看算子效率最后看有没有因显存不足导致的频繁换入换出。绝大多数情况下通信重叠和算子融合没有生效是 MFU 提不上去的主要原因。我在实际使用中还有一个心得融合优化是一个调优收敛的过程不需要追求把每个开关都打开。比如你的显存还很宽裕选择性重计算就没必要开太多如果你的模型层数不多流水线并行的 interleaved 也别碰。一切都以实测数字为准而不是以开了多少优化为荣。MindSpeed 真正厉害的地方不在于某个单一优化技术有多激进而在于它把这些技术融合成了一个整体让你可以在合理的配置下稳定地拿到收益——这一点是很多 DIY 组合方案很难做到的。