## 一、先看一个案例：138ms 的训练步，一半花在"搬运"上

假设你手里有个 MoE 模型在训，一个训练步（forward + backward + 优化器）跑得很慢。直觉告诉你：肯定是专家层的矩阵乘法（matmul）太慢了，模型大、算得多嘛。

把 PyTorch Profiler 打开，按 CUDA 时间排序看前 10 个算子，结果出乎意料：专家 matmul 确实是第一瓶颈，但排第二、第三的是一对叫 **dispatch（分发）和 combine（聚合）** 的操作——token 被路由到不同 GPU 上的专家、算完再收回来，这对"搬运工"前向加反向一共吃掉了 **30.8ms**（dispatch 18.7ms + combine 12.1ms）的 GPU 时间（来源：*AI Systems Performance Engineering* 第 13 章 Profiling 实战案例）。整个训练步的 GPU 总时间是 138ms，也就是说，**超过两成的时间花在搬运上，而不是计算上**。

如果不体检，你会怎么优化？大概率是去调 matmul，或者上更激进的并行策略。但真正的病根之一，是 MoE 路由带来的通信开销——那是另一味药。

这个案例想说明一件事：**性能优化的第一步不是动手，是知道瓶颈到底在哪。**

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

GPU 性能分析工具很多，容易挑花眼。其实按"问的问题"分，就三层：

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

顺序很重要：**先用系统级看全貌，再用操作级看分解，最后用内核级钉死原因**。别一上来就钻内核，那是给"已经知道哪个内核是热点"的人用的——ncu 会重放内核采集硬件计数器，慢到只适合精查少数几个内核（来源：*AI Systems Performance Engineering* 第 13 章；工具开销经验值来自 2025-2026 年社区 profiling 实践资料）。

这一层工具背后有个共同的语言：**NVTX 标记**。你可以把它理解成给代码打的"时间轴书签"——比如把 forward、backward、optimizer_step 各标一段。书签打上之后，同一个"forward"区间会同时出现在 PyTorch Profiler 的追踪和 nsys 的时间线里，跨工具对照就有了锚点。PyTorch 大多数关键区域已经自动打好了标记，你也可以自己用 `torch.profiler.record_function()` 加（来源：同上，第 13 章 NVTX 小节）。

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


## 三、体检四步法：不靠猜，靠流程

工具齐了，怎么用？给你一套可以直接照抄的四步流程：

**第一步：先看一个数——MFU，而不是"利用率"。**  
`nvidia-smi` 显示 GPU 利用率 90%，你是不是觉得挺满意？先别高兴。利用率只说 GPU 没闲着，不等于在干正事——它可能 90% 的时间在跑低效内核。真正该盯的指标叫 **MFU（Model FLOPs Utilization，模型算力利用率）**：实际算出的有效浮点运算 ÷ 硬件理论峰值。一个粗糙的具象锚点：一张 H100 跑一个 70B 稠密模型，MFU 40% 大概相当于每卡输出 400 TFLOPS 左右——不算爆表，也不算丢人。健康线按场景不同：稠密预训练公认 **35%-50% 算健康，低于 35% 提示有瓶颈**；但 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 开销大）；
- **小内核风暴**：密密麻麻全是几微秒的小内核——启动开销把 GPU 拖垮，这是编译器和 CUDA Graph 的活儿（下一篇会讲）；
- **同步等待**：多卡作业里，某个 rank 在等别的 rank——通信没和计算重叠，或者出了个掉队者。

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

**第三步：锁定 Top 内核，用 ncu 问"为什么"。**  
从时间线里找出 GPU 时间占比最高的 3-5 个内核，交给 ncu。它会告诉你这个内核卡在哪：**计算受限**（SM 算力打满，需要降精度或减少冗余计算）、**内存受限**（内存带宽打满，需要提高算术强度，少搬数据）、还是**延迟受限**（占用率太低，没足够的并行任务掩盖延迟）。一个粗略的比喻：把一条流水线比作一条工厂的走廊，算力像产线上的机器，内存带宽像走廊宽度，延迟像工序之间的等待时间——ncu 的 roofline 图就是告诉你，工厂卡在机器不够、走廊太窄、还是工序空转。

**第四步：改一处，测一处。**  
书上那个 MoE 案例就是这么收尾的：针对专家 matmul 做算术强度优化（融合内核、减少内存移动）之后重跑 ncu，内核的 **SM 计算峰值利用率从优化前涨到 85%，内存带宽占用降到 40%，占用率升到 80%**——内核从"内存受限"变成了"计算受限"，更接近硬件极限了（来源：*AI Systems Performance Engineering* 第 13 章 Roofline 案例）。每一步改动都重新测，才知道哪味药真的起效。这也是第五章说的"先算账再动手"在单卡尺度上的版本。


![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` 采样 CPU，看火焰图里时间烧在哪。书上那个案例里，`perf` 就抓到了 read 系统调用在 CPU 采样中占了 5.3%——数据读取在拖后腿，这是 PyTorch Profiler 里看不到的主机侧证据（来源：同上，第 13 章 Linux perf 小节）。
- **I/O 侧**：DataLoader 的 worker 不够、预处理太慢，GPU 就断粮。这是第三章（数据管道）和第五章（单机调优里的内存三件套）讲过的坑，但注意：**怎么发现**是这一篇的事——nsys 时间线里 GPU 空洞 + CPU 侧数据线程忙碌，就是数据管线的典型指纹。
- **通信侧**：回到开头的 MoE 案例，dispatch/combine 本质上不是"算"，是"搬"——跨设备的 all-to-all。这类开销在操作级 Profiler 里看得清清楚楚，但很多人从不看第二、第三名的算子。

一句话：**GPU 利用率低只是症状，别急着给 GPU 定罪。** 时间线先拉出来，CPU、I/O、通信轮流审一遍，哪个露马脚抓哪个。

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

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

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

另外提醒一句：PyTorch 与 TensorBoard 集成的 trace 插件已弃用，现在看时间线用 **Perfetto**（网页版，支持 SQL 过滤），看多卡用 HTA（来源：同上，第 13 章；PyTorch 官方 2026 教程）。


假设你手里有个 MoE 模型在训，一个训练步（forward + backward + 优化器）跑得很慢。直觉告诉你：肯定是专家层的矩阵乘法（matmul）太慢了，模型大、算得多嘛。

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

大多数人的第一反应是改代码、换并行、加机器。这一篇想劝你一句：先别动手。慢在哪、为什么慢，是能测出来的——PyTorch Profiler、Nsight Systems、Nsight Compute 三层工具就是你的体检设备。一次 138ms 的训练步里，有 30.8ms 花在没人注意的 token 搬运上；GPU 利用率低，瓶颈可能在 CPU、在 I/O、在通信，唯独不一定在你盯着的那个算子。

运维开发工程师

人工智能

编程语言

架构设计

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

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 性能工程（一）：训练慢，先别改代码，先做一次性能体检

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐