企业官网建设流程全解析

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 左右的梯度 tensor，k 取 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、Activation（GELU）、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 做算子自动调优：不要迷信默认配置

说到算子融合，不得不提昇腾的 AOE（Ascend 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 切开。但把这些并行策略组合到同一个训练任务里的时候，它们之间会产生复杂的交互。

举一个很典型的冲突场景：假设你同时用了张量并行（TP=8）和数据并行（DP=16），那一共有 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 的 activation（Q、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 卡时，TP=8、PP=1 通常最优，因为机内带宽最好。
• --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 环境上的实测数据对比。大家感受一下融合优化的组合效果：

可以看到，每加一层优化，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 卡、TP=8 的典型配置下，通信占比如果能压到 10% 以下，说明通信计算重叠做得不错；如果通信占比超过 25%，说明调度或者 chunk 划分还有优化空间。

MFU（Model FLOPs Utilization）也是一个直观的指标。MFU 计算方法是：

MFU = 实际计算量(FLOPs) / (GPU数量 × GPU峰值算力 × step耗时)

对于 GPT 类稠密模型，单个 token 的前向计算量约等于 6N，其中 N 是模型参数量。反向传播是前向的 2 倍，所以一个训练 step 的总计算量约等于 6N × 3 × tokens_per_step。把这个数除以硬件峰值总算力乘以 step 耗时，就得到 MFU。

举一个实际的例子：13B 模型参数量 N=130亿，global batch size 32、序列长度 4096，那么每个 step 处理的 token 数是 32 × 4096 = 131072，总计算量约等于 6 × 13e9 × 3 × 131072 ≈ 3.06e16 FLOPs。如果 step 耗时 2.4 秒，单卡峰值算力约 3.2e14 FLOPs/s（BF16），总算力就是 8 × 3.2e14 = 2.56e15 FLOPs/s。MFU = 3.06e16 / (2.56e15 × 2.4) ≈ 0.497，也就是约 50%。

如果 MFU 卡在 30% 左右上不去，我会按这个顺序排查：先看是不是数据加载是瓶颈（CPU 喂不上数据），再看通信占比，再看算子效率，最后看有没有因显存不足导致的频繁换入换出。绝大多数情况下，通信重叠和算子融合没有生效是 MFU 提不上去的主要原因。

我在实际使用中还有一个心得：融合优化是一个"调优收敛"的过程，不需要追求把每个开关都打开。比如你的显存还很宽裕，选择性重计算就没必要开太多；如果你的模型层数不多，流水线并行的 interleaved 也别碰。一切都以实测数字为准，而不是以"开了多少优化"为荣。MindSpeed 真正厉害的地方不在于某个单一优化技术有多激进，而在于它把这些技术融合成了一个整体，让你可以在合理的配置下稳定地拿到收益——这一点，是很多 DIY 组合方案很难做到的。