有个反直觉的事实值得先说清楚：`nvidia-smi` 里的 GPU 利用率，说的是"GPU 有没有在干活"，不是"GPU 干的是不是正事"。一个内核要是写得烂，它能让 GPU 100% 忙着一整秒，产出却只有理论值的十分之一。所以盯利用率会骗人，得换把尺子——这篇讲的就是怎么量、量什么

## 一、先跑一遍：一个能看见"搬运开销"的 MoE

与其听我讲结论，不如自己跑一次。下面这段搭了个简化的 top-2 MoE 层，路由、分发、专家计算、回收全用 PyTorch 原生算子写出来，六十行左右：

```python
import torch, torch.nn.functional as F

def moe_layer(x, gate_w, w1, w2, topk=2):
    """简化 top-2 MoE：路由 → dispatch → 专家 FFN → combine"""
    T, d = x.shape
    E = gate_w.shape[1]
    dev = x.device

    # ---- 路由：每个 token 挑 topk 个专家 ----
    probs, idx = torch.topk(F.softmax(x @ gate_w, -1), topk, -1)   # [T, k]
    flat_e = idx.reshape(-1)                       # [T*k] 每个副本去哪个专家
    flat_w = probs.reshape(-1)
    flat_x = x.repeat_interleave(topk, dim=0)      # [T*k, d]   ← 搬运 ①：复制
    src_tok = torch.arange(T, device=dev).repeat_interleave(topk)

    # ---- dispatch：按专家排序，把 token 收拢成连续分组 ----
    order = torch.argsort(flat_e)                  #                 ← 搬运 ②：排序
    sx = torch.index_select(flat_x, 0, order)      # [T*k, d]        ← 搬运 ③：收拢
    sw, se = flat_w[order], flat_e[order]
    counts = torch.bincount(se, minlength=E)
    C = int(counts.max())                          # 按最大分组 padding
    offsets = torch.cumsum(counts, 0) - counts
    pos = torch.arange(T * topk, device=dev) - offsets[se]

    buf = torch.zeros(E, C, d, device=dev, dtype=x.dtype)
    buf[se, pos] = sx                              # [E, C, d]       ← 搬运 ④：scatter

    # ---- 专家 FFN：真正"算"的部分，只有这两行 ----
    hh = F.relu(torch.bmm(buf, w1))                # [E, C, h]  w1: [E, d, h]
    out = torch.bmm(hh, w2)                        # [E, C, d]  w2: [E, h, d]

    # ---- combine：按原路 gather 回来，加权求和 ----
    gathered = out[se, pos] * sw[:, None]          #                 ← 搬运 ⑤：gather
    back = torch.zeros(T * topk, d, device=dev, dtype=x.dtype)
    back[order] = gathered                         #                 ← 搬运 ⑥：逆排序
    y = torch.zeros(T, d, device=dev, dtype=x.dtype)
    y.index_add_(0, src_tok, back)                 #                 ← 搬运 ⑦：归拢
    return y
```

注意到没有：**七步里只有两步在"算"（那两个 bmm），其余五步全在"搬"**。真实 MoE 里 dispatch/combine 走的是 all-to-all 通信，比这里的显存内搬移更贵，但结构是一样的。

现在把它跑起来看账本：

```python
from torch.profiler import profile, ProfilerActivity

dev = "cuda"
torch.manual_seed(0)
T, d, E, h, topk = 8192, 2048, 8, 1024, 2
x      = torch.randn(T, d, device=dev, requires_grad=True)
gate_w = torch.randn(d, E, device=dev) * 0.02
w1     = torch.randn(E, d, h, device=dev) * 0.02
w2     = torch.randn(E, h, d, device=dev) * 0.02

with profile(activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
             record_shapes=True) as prof:
    for _ in range(5):
        y = moe_layer(x, gate_w, w1, w2, topk)
        y.sum().backward()

print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=15))
```

看输出的 `Self CUDA Time` 那一列。做过这个实验的人通常会愣一下：排在前面的不只有 `bmm`，还有一串名字里带 `index_select` / `index_put_` / `index_add_` / `argsort` / `repeat_interleave` 的算子——它们就是上面标的"搬运"。

**把它们的时间加总，除以总 CUDA 时间**，这个比值就是"搬运"占掉的份额。改改 `topk` 和 `E` 再跑一次，看它怎么变。这个数字在不同硬件、不同 token 数上差别很大，所以我就不给你一个具体值了——**自己跑出来的才有意义，而且你会记住它**。

我第一次跑完的感受是：一直以为是专家 FFN 太慢，结果大头在没人看的那几行索引操作上。如果当时直接去优化 `bmm`，大概率会白忙一场。

## 二、三层体检设备：从"在哪个环节慢"到"为什么慢"

工具很多，按"回答什么问题"分就三层：

| 层   | 工具                          | 回答的问题                     | 开销经验值      |
| --- | --------------------------- | ------------------------- | ---------- |
| 操作级 | PyTorch Profiler（基于 Kineto） | 哪个算子最贵？前向/反向是否失衡？         | 10%-20%    |
| 系统级 | Nsight Systems（nsys）        | 时间线全貌：GPU 空等了吗？CPU 喂得过来吗？ | ~5%        |
| 内核级 | Nsight Compute（ncu）         | 单个热点内核为什么慢？计算受限还是内存受限？    | 很慢（逐个内核重放） |

用它们的顺序有讲究：**先用系统级看全貌，再用操作级看分解，最后用内核级钉死原因**。ncu 会重放内核去采集硬件计数器，慢到只适合精查少数几个已知的热点——拿它做全量扫描，一天都跑不完（工具开销经验值来自 2025-2026 年社区 profiling 实践资料）。

三层工具之间有个共同语言：**NVTX 标记**。可以理解成给代码打"时间轴书签"——把 forward、backward、optimizer_step 各标一段，同一个 `forward` 区间就会同时出现在 PyTorch Profiler 的追踪和 nsys 的时间线里，跨工具对照有了锚点。PyTorch 关键区域已经自动打好了标记，自己的代码可以加：

```python
with torch.profiler.record_function("my_moe_layer"):
    y = moe_layer(x, gate_w, w1, w2)
# nsys 侧对应：torch.cuda.nvtx.range_push("my_moe_layer") / range_pop()
```


![fig12-profiling-stack.png](https://developer.qcloudimg.com/http-save/yehe-11479707/f099771d4c2a09ba073426e670e67b52.png)


## 三、四步体检法

**第一步：换把尺子，看 MFU 而不是利用率。**

利用率高不代表算得有效率。真正该盯的是 **MFU（Model FLOPs Utilization，模型算力利用率）**：实际算出的有效浮点运算 ÷ 硬件理论峰值。

一个具象锚点：一张 H100 跑 70B 稠密模型，MFU 40% 大概相当于每卡输出 400 TFLOPS 左右。健康线按场景分：稠密预训练公认 **35%-50% 算健康**；但 MoE 模型走 FP8 训练时 **20%-32% 才是当前的优秀线**（DeepSeek-V3 公开材料约 21%、字节 MegaScale 报告 28%-32%）——MoE 被压低的一大原因是 all-to-all 通信吃掉理论峰值（来源：AI Infrastructure Knowledge Base 分布式训练专题，2026；DeepSeek-V3 技术报告；MegaScale 工程分享）。

MFU 是相对数，不同模型、不同并行配置没法横向比；但在同一份训练作业里，它是"优化有没有见效"最诚实的尺子。

**第二步：nsys 拉时间线，找"气泡"。**

健康的时间线是 GPU 内核一个接一个，间隙极小，CPU 侧数据加载在后台和计算重叠。不健康的有三种典型形态，一眼能认出来：

- **GPU 饿肚子**：内核之间长长的空洞，多半是 CPU 喂不动（数据加载慢、Python 开销大）；
- **小内核风暴**：密密麻麻全是几微秒的小内核，启动开销拖垮吞吐——这是编译器和 CUDA Graph 的活儿（下一篇讲）；
- **同步等待**：多卡作业里某个 rank 在等别的 rank，通信没和计算重叠，或者出了掉队者。


![fig12-timeline-gaps.png](https://developer.qcloudimg.com/http-save/yehe-11479707/7e250e0574aaef9b5e25b102fb175dfb.png)

**第三步：锁定 Top 内核，用 ncu 问"为什么"。**

从时间线里挑 GPU 时间占比最高的 3-5 个内核交给 ncu。不用记一堆指标，抓住三个就够判断方向：

```bash
ncu --metrics \
  sm__throughput.avg.pct_of_peak_sustained_elapsed,\
  dram__throughput.avg.pct_of_peak_sustained_elapsed,\
  sm__warps_active.avg.pct_of_peak_sustained_active \
  -k <你的内核名> python train.py
```

怎么读：

- **算力百分比高、带宽百分比低** → 计算受限。流水线卡在"机器不够"，得降精度、减少冗余计算。
- **带宽百分比高、算力百分比低** → 内存受限。卡在"走廊太窄"，得提高算术强度、少搬数据（下一篇的主题）。
- **两个都低** → 延迟受限。占用率不足，没有足够的并行任务掩盖访存延迟，去查 block 尺寸和寄存器用量。

**第四步：改一处，测一处。**

每改一个地方就重跑一次 ncu，看上面三个百分比怎么动。优化成功的标志很明确：内核从"内存受限"往"计算受限"挪——算力百分比往上走、带宽百分比往下走，说明它更接近硬件极限了。一次改一堆的后果是，最后不知道是哪味药起效的。



![fig12-diag-flow.png](https://developer.qcloudimg.com/http-save/yehe-11479707/1297fcad9e4eea424584434e6e82ff8c.png)



## 四、GPU 只是嫌疑人之一：CPU 和 I/O 会"装病"

体检最容易犯的错是只盯着 GPU。训练是条流水线，任何环节掉链子，症状都表现为"GPU 利用率低"——但病根常常不在 GPU。

- **CPU 侧**：Python 解释器开销、GIL 争用、数据预处理循环，都能让 GPU 空等。用 Linux `perf` 采样看火焰图：
  ```bash
  perf record -F 99 -g --call-graph dwarf -p <pid> -- sleep 30
  perf report            # 看火焰图里时间烧在哪
  ```
  值得留意的是主机侧的系统调用和 Python 解释器帧占比——数据读取拖后腿这件事，PyTorch Profiler 的 CUDA 视图里是看不到的。
- **I/O 侧**：DataLoader worker 不够、预处理太慢，GPU 就断粮。这是第三章（数据管道）和第五章（内存三件套）讲过的坑，但**怎么发现**是这一篇的事：nsys 时间线里 GPU 出现空洞 + CPU 侧数据线程持续忙碌，就是数据管线的典型指纹。
- **通信侧**：回到第一节那个 MoE，dispatch/combine 本质不是"算"是"搬"，跨设备版本就是 all-to-all。这类开销在操作级 Profiler 里看得清清楚楚，问题在于很多人只看第一名。

所以 GPU 利用率低只是症状。时间线拉出来，CPU、I/O、通信轮流审一遍，哪个露马脚抓哪个。

## 五、多卡：一个掉队的 rank 拖垮整个集群

单机体检完，多卡还有一道坎。分布式训练里所有 rank 是集体行动，一个 rank 慢，其余全在等它——这就是 **straggler（掉队者）问题**。整机利用率再高，也被最慢那块短板钉死。

多卡场景的体检工具是 Meta 开源的 **HTA（Holistic Trace Analysis，整体追踪分析）**，把多 rank 的 PyTorch Profiler 追踪聚合到一条时间线上，专门找"某个 GPU 在等别的 GPU"的空闲段，还能验证通信和计算到底有没有重叠（来源：Meta HTA 开源项目）。再往上是第五章下篇讲的集群级监控（DCGM 这类），那是"长期运营的血压计"，和本篇"单次作业的病理解剖"是两回事。

查看工具方面顺带一提：PyTorch 与 TensorBoard 集成的 trace 插件已经弃用，现在看时间线用 **Perfetto**（网页版，支持 SQL 过滤），看多卡用 HTA（来源：PyTorch 官方 2026 教程）。

```bash
# 导出追踪后在 https://ui.perfetto.dev 打开
# 或者用 HTA 做多 rank 聚合分析
pip install hta
python -m hta.trace_analysis --trace-dir ./profiler_traces
```

---

第一节那段脚本跑完，你看到的"搬运占比"是多少？把 `topk`、`E`、token 数和那个比值一起贴出来会挺有意思——不同配置下的差异比想象中大。要是碰到"Profiler 一开、结果的排序就变了"这种情况（确实会发生，Profiler 本身有 10%-20% 开销），也值得说说，那正是理解工具边界的好素材。


有个反直觉的事实值得先说清楚：nvidia-smi 里的 GPU 利用率，说的是"GPU 有没有在干活"，不是"GPU 干的是不是正事"。一个内核要是写得烂，它能让 GPU 100% 忙着一整秒，产出却只有理论值的十分之一。所以盯利用率会骗人，得换把尺子——这篇讲的就是怎么量、量什么

AI Infra 系列 · 第六章 · GPU 性能工程（一）：训练慢，先别改代码，先做一次性能体检

这篇给一套能立刻上手的四步体检法：PyTorch Profiler、Nsight Systems、Nsight Compute 三层工具各回答一个问题，配合一段可以直接跑的 MoE 脚本，让你亲眼看到"搬运"吃掉的那部分时间。先量出来，再动手。

运维开发工程师

人工智能

编程语言

架构设计

用MFU判断算力效率而非GPU利用率；先用nsys找时间线气泡，再用操作级Profiler锁定dispatch/combine等通信瓶颈，最后用ncu钉死内核受限类型。CPU、I/O、通信都会伪装成GPU瓶颈，多卡场景用HTA揪出掉队rank。优化后重测对比，确保改动真实生效。

数据预处理

数据管道

代码解释

编译器

解释器

DeepSeek

路由

Python

Linux

2026上云采购 | AI焕新·智启新局

tione

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI Infra 系列 · 第六章 · GPU 性能工程（一）：训练慢，先别改代码，先做一次性能体检-腾讯云开发者社区-腾讯云

AI Infra 系列 · 第六章 · GPU 性能工程（一）：训练慢，先别改代码，先做一次性能体检

AI Infra 系列 · 第六章 · GPU 性能工程（一）：训练慢，先别改代码，先做一次性能体检

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐