MFU 优化：Profiling → 诊断 → 提升实战

更新日期：2026-04-16

---

一、MFU 定义

\(\text{MFU} = \frac{\text{实际模型 FLOPS}}{\text{GPU 理论峰值 FLOPS}}\)

其中实际模型 FLOPS \(= 6 \times N \times \text{tokens/sec}\)（\(N\) = 模型参数量，6 = 前向 2 + 反向 4）。

为什么关心 MFU？MFU 50% 意味着你花的钱只有一半变成了有效计算。从 35% 提到 55% = 同样的钱多训 57% 的 token。

---

二、业界 MFU 水平

34% → 54% 的提升完全来自软件（CUDA/NCCL/框架优化），硬件没变。说明大多数集群还有巨大优化空间。

---

三、Profiling 工具——每个工具的原理

3.1 Nsight Systems：全系统 Timeline

是什么：NVIDIA 的系统级 profiler，生成 CPU+GPU 的统一时间线。

底层原理：

Nsight Systems 通过两套机制采集数据（参考 GPU Profiling Under the Hood (2025)）：

• CPU 端：通过 Linux perf_event_open 系统调用做轻量级采样。每隔固定间隔（如 1ms）中断 CPU 线程，记录当前指令地址和调用栈 → 得到 CPU 时间线

• GPU 端：通过 CUPTI（CUDA Profiling Tools Interface） 注册回调。每当 CUDA 运行时发生事件（kernel launch、memory copy、同步等），CUPTI 触发回调记录时间戳 → 得到 GPU 时间线

• 时间对齐：CPU 和 GPU 使用同一时钟基准对齐，使得你能看到"CPU 在 t=100ms 启动了 kernel A，GPU 在 t=100.05ms 开始执行 A，t=102ms 完成"

看什么：

• GPU 空闲（气泡）：timeline 上 GPU 行没有 kernel → PP 气泡或通信等待

• Kernel launch 延迟：CPU 发射到 GPU 开始之间的间隔 → 用 CUDA Graph 优化

• 通信阻塞：AllReduce/All-to-All 占据大块时间 → 通信计算重叠

• Python GC：周期性的 CPU 暂停导致 GPU 短暂空闲 → 关闭 GC

开销：极低（~1-2%），因为只记录事件时间戳，不读硬件计数器。可以长时间 profile。

3.2 Nsight Compute：单 Kernel 深度分析

是什么：NVIDIA 的 kernel 级 profiler，对单个 CUDA kernel 做深度分析。

底层原理：

Nsight Compute 工作方式完全不同于 Nsight Systems（参考 Nsight Compute Profiling Guide）：

• 硬件计数器（Hardware Performance Counters）：GPU 内部有数百个硬件计数器，记录 SM 利用率、L1/L2 cache 命中率、HBM 带宽、warp 调度效率等。Nsight Compute 编程这些计数器来采集精确的硬件级指标

• 重放机制（Kernel Replay）：因为硬件计数器数量有限（不能同时采集所有指标），Nsight Compute 会多次重放同一个 kernel，每次采集不同的计数器组。这就是为什么它很慢——一个 kernel 可能被执行 5-20 次

• Section Sets：指标按逻辑分组为 Sections（如 Memory、Compute、Scheduler），用户选择采集哪些 Sections

核心分析能力： 开销：很高（10-100x 减速），因为 kernel 被多次重放。只用于分析热点 kernel，不适合全程 profile。

3.3 PyTorch Profiler (Kineto)

是什么：PyTorch 内置的 profiler，集成了 CPU 算子追踪 + GPU kernel 追踪。

底层原理：

PyTorch Profiler 由三层组成（参考 Kineto GitHub）：

• Python 层：torch.profiler.profile() context manager，记录 Python 调用栈

• C++ 层（Autograd Profiler）：在 PyTorch 的 C++ 算子调度器中插入 hook，记录每个算子（如 aten::matmul、aten::layer_norm）的开始/结束时间

• GPU 层（Kineto/CUPTI）：Kineto 库桥接到 CUPTI，采集 GPU kernel 时间线。将 CPU 算子和 GPU kernel 关联起来——告诉你"Python 的 model.forward() 最终触发了哪些 GPU kernel"

独特价值：

与 Nsight Systems 的关键区别：PyTorch Profiler 知道算子语义（这是 matmul 还是 layernorm），而 Nsight Systems 只看到匿名的 CUDA kernel 名。

with torch.profiler.profile(
    activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
    schedule=torch.profiler.schedule(wait=5, warmup=2, active=3),
    on_trace_ready=torch.profiler.tensorboard_trace_handler('./log'),
    record_shapes=True,   # 记录 tensor 形状
    with_stack=True,       # 记录 Python 调用栈
) as prof:
    for step, batch in enumerate(dataloader):
        train_step(batch)
        prof.step()

# TensorBoard 中查看: tensorboard --logdir=./log

输出：

• Chrome Trace (JSON)：在 chrome://tracing 或 TensorBoard 中打开

• Table Summary：按算子统计耗时排名

• Memory Profile：追踪内存分配/释放

• 自动建议：检测常见问题（如缺少 FlashAttention、DataLoader 慢）

3.4 torch.cuda.Event：手动计时

是什么：最底层的 GPU 计时方式。

原理：

start = torch.cuda.Event(enable_timing=True)
end = torch.cuda.Event(enable_timing=True)

start.record()           # 在 GPU stream 中插入时间戳标记
some_gpu_operation()
end.record()             # 插入结束标记
torch.cuda.synchronize() # 等 GPU 完成
print(start.elapsed_time(end))  # 毫秒

为什么不能用 time.time()？因为 GPU 操作是异步的。time.time() 测的是 CPU 提交命令的时间，不是 GPU 实际执行的时间。cuda.Event 直接在 GPU stream 中记录时间戳，是准确的。

3.5 Megatron 内置 Timer

是什么：Megatron-LM 框架自带的高层计时。

原理：在训练循环的关键位置（forward、backward、allreduce、optimizer step、data loading）前后插入 cuda.Event 计时，每 N 步输出一次统计。

[Rank 0] iteration 100 | elapsed_time=2.45 | 
  forward: 0.42s | backward: 0.85s | allreduce: 0.15s | 
  optimizer: 0.05s | data_loading: 0.02s | throughput: 12500 tok/s

优势：开销几乎为零（只是几个 cuda.Event），可以始终开启。是发现"哪个阶段最慢"的第一工具。

3.6 NCCL Debug

是什么：NCCL（NVIDIA 集合通信库）的内置诊断。

原理：通过环境变量 NCCL_DEBUG=INFO 开启。NCCL 在每次集合通信（AllReduce、All-to-All 等）时打印：

• 选择的算法（Ring/Tree/Direct）

• 使用的网络接口（NVLink/IB）

• 检测到的拓扑（哪些 GPU 通过什么连接）

• 实际带宽

export NCCL_DEBUG=INFO
export NCCL_TOPO_DUMP_FILE=/tmp/topo.xml  # 保存拓扑到文件

# 输出示例:
# NCCL INFO Ring 0: 0->1->2->3->4->5->6->7->0
# NCCL INFO Using network IB
# NCCL INFO comm 0x7f8a... rank 0 nranks 8 ... AllReduce 16MB ... 
#   algo Ring proto Simple ... time 1.2ms ... bandwidth 106.7 GB/s

什么时候用：通信速度不符合预期时。对比 NCCL_DEBUG 报告的带宽和硬件理论带宽——如果差距大，说明拓扑检测错误、网络拥塞或配置问题。

3.7 工具选择决策

flowchart TB
    start["MFU 不达标"]
    q1{"瓶颈类型"}

    start --> q1

    q1 -->|"GPU 利用率低<br/>(<60%)"| nvprof["nvprof / Nsight Compute<br/>(kernel 级)"]
    q1 -->|"通信慢"| nccl["NCCL_DEBUG=INFO<br/>+ Nsight Systems"]
    q1 -->|"DataLoader 慢"| torch_prof["torch.profiler<br/>(timeline)"]
    q1 -->|"OOM / 内存"| memory["torch.cuda.memory_summary()"]
    q1 -->|"分布式不平衡"| dist["per-rank profile<br/>+ NCCL_TOPO"]

    classDef stage fill:#fff,stroke:#cc785c,color:#1a1a1a;
    classDef decision fill:#f5f3eb,stroke:#bdb9ab,color:#1a1a1a;
    class start,nvprof,nccl,torch_prof,memory,dist stage
    class q1 decision

实操顺序：torch.profiler 先扫一遍（覆盖 forward/backward/comm/dataload 全栈），有具体瓶颈再用 Nsight Systems / Nsight Compute / NCCL debug 深入。

---

四、诊断流程

4.1 常见瓶颈与修复

这个表的每一行我都详细解释：

1. 未用 Flash Attention → MFU +10-20%

标准 Attention 的问题不是计算量（都是 \(O(n^2d)\)），而是内存访问模式。标准实现需要在 HBM 中实例化完整的 \(n \times n\) 注意力矩阵（128K 上下文 = 128K² = 16G 个元素）。FlashAttention 通过分块计算 + 在线 softmax 完全避免这个矩阵的实例化——所有中间计算在 SRAM（片上高速内存）完成。效果：不是更快的计算，而是更少的内存读写 → HBM 带宽不再是瓶颈。 2. 未用 Fused Kernels → MFU +3-5%

问题：PyTorch 默认把 LayerNorm 拆成多个小 kernel（mean、var、normalize、scale、bias）。每个 kernel 都要从 HBM 读数据、写回 HBM。kernel launch overhead + 多次 HBM 读写 是浪费。Fused kernel 把整个 LayerNorm 合并成一个 kernel，数据只读一次写一次。对 Softmax、GeLU 同理。Megatron 的 --use-fused-* 系列 flag 开启这些。 3. 通信未重叠 → MFU +5-15%

默认行为：Forward → Backward → 等 AllReduce 完成 → Optimizer Step。GPU 在 AllReduce 期间完全空闲。重叠方法：Backward 的第 N 层梯度算完后，立刻启动第 N 层的 AllReduce，同时继续计算第 N-1 层的反向。因为 GPU 有独立的通信引擎（NVLink/IB 的 DMA），通信和计算可以真正并行。Megatron 的 --overlap-grad-reduce 开启。 4. Micro-batch Size 太小 → MFU +5-10%

为什么 micro-BS=1 慢？因为 GPU 的矩阵乘法在小矩阵上利用率极低。H100 的 Tensor Core 一次处理 16×16 的 tile——如果你的 batch 维度只有 1，大部分 Tensor Core 在空转。增大 micro-BS 让矩阵更大 → Tensor Core 利用率提升。但 micro-BS 受限于 GPU 内存——用 activation checkpointing 换内存。 5. PP 气泡 → MFU +5-10%

流水线并行的 warmup/cooldown 阶段部分 GPU 空闲。标准 1F1B 的气泡率 = \((PP-1)/\text{micro-batches}\)。Interleaved 1F1B 通过让每个 GPU 处理多个非连续层段减少气泡。DualPipe（DeepSeek）通过双向流水线消除 75% 气泡。Zero Bubble PP 通过拆分反向传播为权重梯度和输入梯度两部分，重新排列调度，把气泡率降到接近 0。 6. Python GC → MFU +2-5%

Python 的垃圾回收器在大规模训练中是隐蔽杀手。GC 触发时当前线程暂停（stop-the-world），但不同 rank 的 GC 触发时间不同 → 某些 rank 暂停时其他 rank 在等它（集合通信需要同步）→ 所有 rank 都被拖慢。MFU 图上表现为周期性的小尖刺。解决：gc.disable() 或调大 GC 阈值 gc.set_threshold(50000, 50, 50)。参考 stas00/ml-engineering。 7. DataLoader 慢 → MFU +5-10%

如果 GPU 等数据（data_loading 时间长），说明 CPU 预处理或磁盘 IO 是瓶颈。原因通常是 num_workers 设太低（默认 0 = 主线程加载）。增加到 4-8 让多个 CPU 核并行预处理。极端情况用 3FS（DeepSeek 的分布式文件系统）或预取到 NVMe SSD。 8. NCCL 算法选错 → MFU 视情况

NCCL 自动选择 AllReduce 算法（Ring/Tree/Direct），但自动选择有时不是最优的。Ring AllReduce 适合大消息（>1MB），Tree AllReduce 适合小消息（<1MB）。用 NCCL_ALGO=Ring 或 NCCL_ALGO=Tree 强制指定，对比哪个更快。另外 NCCL_TOPO_DUMP_FILE 检查 NCCL 是否正确检测到了你的网络拓扑——错误的拓扑检测是常见问题。

---

五、Activation Checkpointing

为什么需要它？训练时反向传播需要前向的中间激活。存所有激活 → 内存爆炸。Checkpointing 只存部分激活，其余在反向时重新计算。 选择性 checkpoint 是最佳实践：内存减少约 60%，计算只增加约 15%。

---

六、通信优化深入

6.1 AllReduce 算法

Ring 的 2(N-1) 步为什么带宽利用率高？因为每一步每个 GPU 都在同时发和收——全双工利用了所有链路。总传输量 = 2 × (N-1)/N × 数据量 ≈ 2 × 数据量（N 大时），接近理论下限。

6.2 通信计算重叠原理

flowchart LR
    subgraph nooverlap["未重叠"]
        f1["Forward"] --> b1["Backward"] --> a1["AllReduce<br/>(GPU 空闲)"] --> opt1["Optimizer"]
    end
    subgraph overlap["重叠"]
        f2["Forward"] --> b2["Backward L_n<br/>+ AllReduce L_{n+1}"] --> opt2["Optimizer"]
    end

    classDef stage fill:#fff,stroke:#cc785c,color:#1a1a1a;
    class f1,b1,a1,opt1,f2,b2,opt2 stage

为什么能并行？GPU 有独立的 DMA 引擎执行 NVLink/IB 通信，不占 SM。SM 算反向传播的同时，DMA 引擎做 AllReduce。但前提是通信量 < 反向计算时间，否则通信仍然会暴露。

---

七、实战案例：128×H100 训 70B 从 32% 到 55%

总计：32% → 55%，1.72x 提升，硬件没变。最大的单项收益来自 Flash Attention。

---

八、追问

问题	方向
Nsight Systems 的 overhead 到底多低？	~1-2% CPU overhead，GPU overhead 近零（只记时间戳）
Nsight Compute 为什么要重放 kernel？	硬件计数器数量有限（一次只能采集 ~10 个），但指标需要 ~100 个计数器
PyTorch Profiler 和 Nsight 能一起用吗？	可以但不建议——两者都用 CUPTI，可能冲突
怎么 profile 多节点？	每个节点独立跑 Nsight Systems，然后用 multi-report 对齐分析
CUDA Graph 怎么减少 launch overhead？	把一系列 kernel 的 launch 序列录制成一个 graph，之后一次 launch 整个 graph

---

参考文献

• [1] GPU Profiling Under the Hood (Survey). 2025. 博客

• [2] Nsight Compute Profiling Guide. 文档

• [3] Kineto (PyTorch GPU Profiler). GitHub

• [4] ML Engineering: Training Performance. 指南

• [5] CoreWeave H100 Benchmarks. 报告

• [6] H100 vs GB200 Benchmarks. SemiAnalysis

• [7] Narayanan et al. Efficient Training on GPU Clusters. 2021. 论文

---

↑ 上级 · C. 分布式训练基础设施