1. 先别急着怪显卡：99% 利用率背后的“伪忙碌”
先说个特别典型的现场。你盯着nvidia-smi，GPU-Util 那一栏稳稳的 99%，温度、功耗、显存占用全都正常，可训练一个 step 的时间就是比预期慢两到三倍。这时候很多人第一反应是换更好的卡，或者怀疑是不是并行策略不对。我见过不少团队卡在这个误区里好几天，最后发现根本不是算力不够，而是 GPU 在“装忙”。
那 99% 到底意味着什么？严格说，nvidia-smi里的 GPU-Util 表示的是采样周期内，Streaming Multiprocessor（SM）上有至少一个 warp 在活动的时间占比。注意，是“有活干”，不是“干满活”。一个 warp 在等数据、等锁、等依赖的时候，只要它还在 SM 上占着位置，硬件计数器就可能把这部分时间也算成 busy。换句话说，99% 只能说明 GPU 没闲着，但算没算在刀刃上，它一点都看不出来。
真正能看出问题的是 Trace。把 PyTorch Profiler 跑起来，导出一份时间线，你会发现 GPU 确实在忙，但那可能忙在一堆只有几微秒的“碎 kernel”上来回切换上。或者，你会在 kernel 之间看到大量几百微秒的空档——GPU 像一台被喂饭的机器，嚼一口，停一会，再嚼一口。这种情况，利用率看着高，吞吐就是上不去。
所以这一讲我就围绕一件事：怎么用 PyTorch Profiler 配合底层的 Kineto 探针，把训练缓慢的真实病灶找出来。我会先解释 Trace 时间线里最常见的四类问题，再带你走一遍完整的性能体检流程。不管你是刚入门 PyTorch 的新手，还是已经被性能问题折磨过几轮的算法工程师，这篇内容都能给你一个可复制的排查思路。
2. 从探针说起：Kineto 到底帮我们看了什么
2.1 没有探针，就没有时间线
聊 Trace 之前，得先清楚这些时间线数据是从哪来的。PyTorch Profiler 在 1.8 之后默认走的是 Kineto 这条链路。Kineto（Kineto 是 PyTorch 里的 GPU 性能分析库，底层叫 Libkineto）干的事情，就是统一接管 CPU 侧和 GPU 侧的事件采集。
CPU 侧的事件好理解，比如你调用了某个 PyTorch operator，它什么时候开始、什么时候结束，这个是在进程内直接打时间戳的。但 GPU 侧的 kernel 执行时间不能这么干。GPU 是异步的，你把一个 kernel 扔进 stream，CPU 这边立刻返回，真正执行发生在几百微秒甚至几毫秒之后。这时候如果只靠 CPU 时间戳，你看到的全是“假开始、假结束”。
Kineto 的解决方案分两类机制。一类是跟 CUPTI（CUDA Performance Tools Interface）配合，通过 CUPTI 的回调函数和硬件计数器拿到 GPU kernel 的真实启停时间。另一类是在较新的版本里，直接用 CUDA 的 trace 机制，以更小的开销采集事件。说到底，Kineto 就是一套贴着硬件走的监听系统，它不干扰你的训练逻辑，只是在旁边记录每一件跟执行相关的事情。
2.2 时间线数据是怎么“攒”下来的
这里有个很多初学者忽略的点：默认情况下，PyTorch Profiler 不是把所有事件都逐条记到磁盘，那样开销太大，训练早就被拖垮了。它是在内存里维护一个环形缓冲区，Kineto 把事件不断写进去，到一定批量之后再做序列化和导出。
所以你会看到，PyTorch Profiler 有一个schedule参数，用来控制“在哪些 step 采集”。比较常见的做法是 warmup 几个 step，让 CUDA context、显存分配都稳定下来，再开始正式采集。比如：
from torch.profiler import profile, ProfilerActivity, schedule my_schedule = schedule( wait=2, warmup=2, active=5, repeat=1 )这个配置的含义是：前 2 个 step 什么都不做，接下来 2 个 step 预热，然后连续采集 5 个 step，最后整个 schedule 重复 1 次。我一般会再加一个profile_memory=True和with_stack=True，前者能看到显存分配的调用链，后者能在排查显存泄漏或异常分配时直接定位到 Python 代码行。代价是采集速度明显变慢，所以这两个开关只在定位问题时开，平时跑基线性能不用带。
Kineto 里还有一个值得提的机制叫 “activity profiling”。它把事件分成 CPU 活动和 GPU 活动两类，你在导出 Trace 后看到的两条 swimlane（泳道），分别对应的就是这两类事件的时间线。GPU 那条泳道的准确性，直接依赖 Kineto 和 CUPTI 的配合程度。如果你发现 GPU kernel 的时长跟实际墙钟时间对不上，先检查一下驱动和 CUDA 版本是否匹配，再检查 PyTorch 是不是官方预编译包——自编译的 PyTorch 如果没带 Kineto 的完整依赖，统计出来会有奇怪偏差。
3. Trace 时间线里的四类典型病灶
3.1 病灶一：kernel 启动间隙过长
这张图在 Trace 里最常见的形状：GPU 泳道上一个 kernel 跑完，然后空一大段，再跑下一个 kernel。空档可能有三四百微秒，kernel 本身才几十微秒。这类问题有个专门的叫法——launch bound，意思是训练过程被 kernel 的启动和调度延迟卡住了。
为什么会有这么长的间隙？最直接的原因是 CPU 侧来不及把 kernel 发出去。PyTorch 的 eager 模式（就是你写一行x = x + 1就立刻执行那种模式）会在每个 operator 上都做 dispatch、参数校验、kernel selection 这些动作。这里面有 Python 解释器的开销，有 PyTorch C++ 层的 overhead，还有跟 CUDA runtime 通信的延迟。当 operator 很碎很小时，GPU 很快就跑完了，但 CPU 还没准备好下一个 kernel，于是 GPU 只能干等。
判断这个病的方法很简单：打开 Trace，看相邻 kernel 之间的 gap 是否显著大于 kernel 自身时长的两三倍。如果一段训练里大部分时间都是这种空档，那基本可以确定是 launch bound。后续的解决办法无非是几个方向：把多个 operator 合并成一个大的 kernel（也就是做算子融合）、用torch.compile走图模式减少 Python 和 C++ 层的反复、或者在某些场景下用 CUDA Graph 把一遍 kernel 启动序列固化下来，省掉重复 launch 的开销。
3.2 病灶二：大量“碎片 kernel”占满时间线
第二种情况是 GPU 泳道上几乎没有空隙，全是密密麻麻的短 kernel。短到什么程度？很多只有 2~5 微秒。这种形态下，GPU 利用率肯定是高的，因为 SM 基本没停过。但你要注意，频繁的 kernel 切换是有代价的。每个 kernel 在 GPU 上启动都要经过调度器，都有固定的开销，这个开销乘以几千上万个 kernel，就是你训练变慢的隐形杀手。
我在真实项目里看到过一个典型例子。某个模型中有大量 elementwise 操作，比如激活函数、加法、乘法、归一化里的某些中间步骤。这些操作单独看都很轻，但 PyTorch eager 模式会把它们拆成好多个独立 kernel 逐个执行。Trace 里一眼望去，GPU 泳道就像一条碎头发丝拼成的线，没有一个大块头 kernel 能撑起几十微秒的计算量。
这种“碎片化 kernel”问题，本质是“启动开销摊薄了计算收益”。你虽然让 GPU 一直忙，但它忙在了无谓的上下文切换上。解决思路跟第一种情况有交叉：优先用算子融合。比如把x + 1和torch.relu(x)合成一个 kernel，或者直接用编译器里的 fusion pass。改完代码后，再去 Trace 里对比：kernel 总数是不是下降了，长 kernel 的占比是不是提高了。这里有个经验：kernel 平均时长如果能从 5 微秒提升到 20 微秒以上，训练吞吐通常能有实打实的提升。
3.3 病灶三：Host 侧数据搬运和同步等待
第三种情况，Trace 里会出现明显的 memcpy 事件，或者能观察到 GPU 在等待cudaMemcpyAsync完成。如果显存拷贝是同步执行的，那你很可能在 CPU 时间线上看到cudaStreamSynchronize或者.cpu()、.item()这类触发同步的调用。一旦有同步点，整个训练管线就会被迫“排队”，GPU 和 CPU 没法重叠干活，性能自然被拽下去。
我之前排查过一个训练脚本，每个 step 都会从 GPU 显存把 loss 拷回 CPU，然后执行print(loss.item())。就这一行看似无害的代码，因为触发了 GPU 和 CPU 之间的同步，导致 GPU 每跑完一个 step 都得停下来等 CPU。把打印改成每 N 个 step 打一次，或者用异步方式把 loss 复制到 CPU，训练直接快了 15%。
还有一种常见的数据搬运病灶，是 host 侧把数据从 CPU 内存搬到 GPU 显存。如果DataLoader里面没有合理设置num_workers和pin_memory，你会看到 GPU 经常在等数据。这个在第四类里详细说，但你要知道，任何出现在 Trace 里的大段 H2D（Host to Device）拷贝，都值得警惕。
用 PyTorch Profiler 看这个问题的标准姿势是：在 Profiler 的 table 输出里，找cudaMemcpy相关的条目，看它是 H2D、D2H 还是 D2D，以及它占了多少时间。H2D 过多意味着数据从 CPU 传过来的路径有问题，D2H 过多则大概率有同步或在频繁地取数据回 CPU。
3.4 病灶四：数据管线吃紧导致 GPU 挨饿
最后这一类，症状是 GPU 利用率不是一直 99%，而是周期性掉到 0% 或 30%。这种情况下，Trace 里往往能看到 GPU kernel 之间有规律的“断档”，而这个断档时间刚好对应 CPU 侧在做数据加载和预处理。
数据管线问题最经典的现象：GPU 跑得很快，但 DataLoader 的 worker 来不及读取、解码、增强图片，导致collate之后形成 batch 的速度赶不上 GPU 的消耗速度。GPU 干完手头的活，下一批数据还没到，只能空转。你要是只看nvidia-smi的平均利用率，可能还是 70%~90%，但实际有效算力已经被拖累了一大截。
要确诊这个病灶，在 PyTorch Profiler 里有个笨办法但很有效：看 CPU 泳道里有没有持续很长时间的DataLoader操作，或者看 CPU 时间线里是否存在明显的数据加载瓶颈。另一个从侧面验证的方法是做实验：手动把DataLoader的数据换成纯随机生成的 numpy 数组，或者直接取消图像解码，看看训练速度是否大幅提升。如果速度上去了，说明瓶颈确实在数据读取环节。
我的习惯是，不论数据量大小，上来先把这几个参数加上：num_workers设为 CPU 核心数的四分之一到三分之一，pin_memory=True，prefetch_factor根据内存余量适当调大。要强调的是，这些参数不是越极端越好，worker 太多会导致进程间通信和内存复制开销反超收益，prefetch 太大也会让显存压力变大。
4. 实操：用 PyTorch Profiler 跑一次性能体检
4.1 环境准备与脚本骨架
我们先看一个最基础但实用的 profiler 脚本骨架。这里以 ResNet 分类训练的一小段为例，目标不是跑 benchmark，而是演示怎么把 profiler 嵌入训练循环：
import torch import torch.nn as nn import torch.optim as optim from torch.utils.data import DataLoader, TensorDataset from torch.profiler import profile, ProfilerActivity, schedule, record_function model = nn.Sequential( nn.Conv2d(3, 32, kernel_size=3, padding=1), nn.ReLU(), nn.Conv2d(32, 64, kernel_size=3, padding=1), nn.ReLU(), nn.AdaptiveAvgPool2d(1), nn.Flatten(), nn.Linear(64, 10) ).cuda() optimizer = optim.SGD(model.parameters(), lr=0.01) loss_fn = nn.CrossEntropyLoss() dummy_input = torch.randn(128, 3, 32, 32) dummy_target = torch.randint(0, 10, (128,)) dataset = TensorDataset(dummy_input, dummy_target) loader = DataLoader(dataset, batch_size=128, num_workers=2, pin_memory=True) my_schedule = schedule( wait=2, warmup=2, active=5, repeat=1 ) model.train() with profile( activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA], schedule=my_schedule, profile_memory=True, with_stack=True ) as prof: for step, (inputs, labels) in enumerate(loader): inputs = inputs.cuda(non_blocking=True) labels = labels.cuda(non_blocking=True) optimizer.zero_grad() with record_function("forward"): outputs = model(inputs) loss = loss_fn(outputs, labels) loss.backward() optimizer.step() prof.step() if step >= 9: break print(prof.key_averages().table( sort_by="cuda_time_total", row_limit=30 ))这段代码有几个地方值得解释。首先，activities里同时开了 CPU 和 CUDA，这样导出的结果里才有两条泳道，才能判断 launch bound 和 CPU 瓶颈。record_function("forward")是我手动加的标注，它能把 forward 这段区域在 Trace 里圈出来，方便快速定位每个 step 的大致分段。non_blocking=True配合pin_memory，可以让数据从 CPU 搬到 GPU 的过程尽量异步，减少同步等待。
4.2 导出和打开 Trace 文件
很多人跑到key_averages().table()就停了，导出文件反而不会操作。其实导出也简单：
prof.export_chrome_trace("resnet_trace.json")这个 JSON 文件就是 Chrome Tracing 格式。你可以在 Chrome 或 Edge 浏览器地址栏输入chrome://tracing，打开后把 JSON 拖进去。也可以直接用https://ui.perfetto.dev/这个在线工具打开，效果更清晰。Perfetto 的好处是支持快捷键缩放、搜索 kernel event，看长时间线比 tracing 顺手很多。
打开之后，你会看到若干条泳道。CPU 泳道上密密麻麻是 PyTorch operator 的起止时间，GPU 泳道上是实际的 CUDA kernel 和 memcpy。如果用了schedule，你会在文件里看到好几个 step 的完整时间线。我的建议是，先整体看一个 step 的时间跨度，再放大某一个 GPU kernel 密集的区域，逐项检查有没有我们前面提到的四类病灶。
4.3 三张关键报表，快速定位问题
除了 Trace 时间线，PyTorch Profiler 的表格输出也很重要。我要重点看三张表。第一张是sort_by="cuda_time_total"，按 GPU 总耗时排序，能帮我找到“哪类 kernel 吃掉了最多的 GPU 时间”。第二张是sort_by="cpu_time_total"，按 CPU 总耗时排序，用来判断 CPU 侧的瓶颈到底在哪个 operator。第三张是带group_by_input_shape=True的版本，防止同一 operator 因为不同形状而被摊平成一条记录，影响判断。
举个例子，如果第一张表里最大的 GPU 耗时来自某个 elementwise kernel，而且它又被调用了成千上万次，这就跟我前面说的“碎片 kernel”问题对上了。如果第一张表最大的是 conv，那可能要往计算效率、矩阵规模合理性方向考虑。如果第二张表里某个 Python 层 operator 的 CPU 耗时异常高，那就要怀疑是不是触发了同步，或者这个算子本身有低效的调度逻辑。
4.4 结合硬件性能计数器做交叉验证
再进阶一步，PyTorch Profiler 还允许你配置一些硬件指标，看内核内部的微观表现。比如你可以通过torch.profiler.ProfilerActivity.CUDA配合 cupti 相关的配置去拿 SM 利用率、显存带宽利用率等数据。这个功能在不同版本、不同硬件上支持度不完全一样，但在 NVIDIA 主流卡上基本可用。
拿到这些计数器后，你会发现有的 kernel 虽然很耗时，但 SM 利用率并不高，说明它可能在等显存数据，是 memory bound。有的是计算高但显存访问少，说明真正的计算密集型算子，合并它带来的收益可能有限。这些交叉验证能帮你判断“该不该优化这个算子”。如果 SM 利用率和显存利用率都拉满了，那线性层或者卷积层的优化空间就很小了，hardware 极限摆在那里，你再改 Python 代码也是白搭。
5. 案例复盘：一个真实的排查过程
5.1 现象与初始假设
之前帮人排查过一个训练实例分割模型的场景。显卡是当时主流的 24GB 级别卡，batch size 设得不大，nvidia-smi显示利用率 99%，显存占用也正常。问题是训练一个 step 要 3 秒多，而换到另一台同样型号显卡的机器，同样的代码只要 1.2 秒。用户最初怀疑是显卡被“挖矿”或别的任务抢占了，但检查之后发现没有其他人占用 GPU。
我告诉他别换机器，先跑一份 profile 看数据。初始一看 GPU 利用率 99%，确实没被骗住。最可疑的是：既然利用率这么高，为什么耗时差这么多？单纯的“快慢差别”很可能来自 kernel 的启动模式，而不是 kernel 本身。
5.2 在 Trace 里发现了什么
导出 Trace 后，一眼就看到一个典型问题：GPU 泳道上大量 3~10 微秒的小 kernel，每隔一段时间还会有一次 400~500 微秒的断层。再点开断层区域看 CPU 泳道，发现 CPU 正卡在某个自定义数据增强函数的执行上。这个函数里有大量小 tensor 的创建、unsqueeze、permute 操作，每个操作都触发了一次 Python 到 C++ 的 dispatch，整体开销被放大了很多倍。
这就是典型的“CPU 瓶颈 + 碎片 kernel”混合病情。GPU 占满是因为碎 kernel 太多，但真正拖慢 step 时间的是 CPU 无法快速提供下一个 kernel，导致 GPU 周期性地挨饿。
5.3 改动与收益
优化分两步做。第一步，把数据增强改成基于torchvision.transforms的向量化写法，避免逐个小操作触发 dispatch；同时把num_workers从 2 提到 8，让 GPU 在 CPU 做预处理时不用干等。第二步，把模型前向里的若干 elementwise 操作写成一个自定义的融合算子，减少 kernel 数量。
改完之后，同样一份代码在原来的机器上跑到了 1.3 秒一个 step。Trace 里干净了很多，长 kernel 的比例明显提高，断层区域基本消失。最重要的是，训练总时间从原本预计的 60 多个小时压缩到了不到 30 小时——这个痛感，只有经历过超长训练的人才懂。
6. 常见问题与排查技巧速查
6.1 为什么 Trace 里看不到 CUDA kernel？
如果你导出的 JSON 里只有 CPU 事件，GPU 泳道一片空白，先检查两件事。第一，PyTorch 和 CUDA 版本是否匹配，很多不匹配的情况会导致 CUPTI 采集失效。第二，activities里是否加上了ProfilerActivity.CUDA。第三，老版本 PyTorch（1.8 之前）的 profiler 不带 Kineto，务必升级到较新版本。还有一个冷门但实际遇到过的问题：驱动权限不足。某些容器环境里/dev/nvidia*设备权限异常，也会导致 CUDA 事件采集不到。
6.2 采样工具对比：为什么 nvidia-smi 和 Trace 数据对不上
nvidia-smi的 util 是抽样统计的，通常几秒钟刷新一次，它观察的是一个粗糙的核态利用——只要 SM 上有活动 warp 就算忙。而 Kineto 记录的是每个 kernel 从开始到结束的精确 wall-clock 时间，它能看到 kernel 内部有多少停顿、kernel 之间有多少空隙。同一个训练过程，前者显示 99%，后者可能显示有效计算只占 60% 甚至更低。这俩不是谁对谁错，而是观察维度不同。
想看更细的 GPU 内部指标，可以用ncu（NVIDIA Nsight Compute）做单 kernel 级别的分析，能看到访存率、SM 活跃率、warp 停顿原因。PyTorch Profiler 适合做整体管线扫描，ncu适合做单点深挖，二者配合最省力。
6.3 一份简明的排查定位表
| 现象 | 可能病灶 | 首选验证手段 | 常用解法 |
|---|---|---|---|
| GPU 利用率高但训练慢，Trace 有大量 kernel 间隙 | launch bound | 看相邻 kernel 的 gap 是否过大 | torch.compile、算子融合、CUDA Graph |
| GPU 泳道全是几微秒碎 kernel | 碎片 kernel 过多 | 按 cuda_time_total 排序看 kernel 数量 | elementwise 融合、减少小操作 |
| GPU 周期性掉 0%，CPU 泳道有长耗时 | 数据管线瓶颈 | 尝试纯随机数据，看速度是否大幅提升 | 调大 num_workers、pin_memory、prefetch_factor |
| Trace 里有大量 .item() / .cpu() | 同步等待 | 搜索 CPU 时间线里同步点 | 改成异步打印、聚合打印 |
| 某个 kernel 特别耗时 | 算子本身低效 | 用 ncu 看 SM 和显存利用率 | 换更高效的算子实现或改算法结构 |
6.4 最容易忽略的几个点
在性能排查案例里，我反复看到这几个被忽略的细节。第一个是cudnn.benchmark没开。如果你的输入尺寸固定，加上torch.backends.cudnn.benchmark = True会让 cuDNN 自动搜索最快的算法，经常能吃到 10%~20% 的免费性能提升。第二个是输入的 shape 不固定。哪怕只是在 batch size 的边界上出现一点波动，很多算子都得回退到更保守的算法。第三个是梯度累积场景下的optimizer.zero_grad()时机。如果每个微批次都调zero_grad()，会导致很多无意义的 kernel 启动，可以考虑把梯度置零挪到需要真正更新参数之前的位置。
还有一个值得提的点：如果训练程序里用了多个 CUDA stream 做并行处理，Trace 会显得更复杂，时间线里会有多个 GPU 泳道或交织的 event。这种场景下，不能简单用“GPU 有没有空档”来判断瓶颈，得结合 stream 之间的依赖关系去分析。一般工程里能不用多 stream 就不用，除非你对它的语义非常熟悉，否则它带来的复杂度可能会掩盖真正的性能问题。
7. 写在最后：性能体检应该成为一种习惯
我现在的习惯是，任何一个新模型或新数据集，第一次跑训练前，都会先花十分钟跑一个短期 profiler，把 baseline 留档。不是说每次都非要优化到极致，而是先知道“正常情况下它应该长什么样”。这样一旦之后训练变慢，拿新 Trace 和 baseline 一对比，问题很快就暴露了。很多线上训练事故，最后查出来的原因都是“某个依赖库升级之后 kernel 选择逻辑变了”这种隐蔽问题，没有 baseline 很难快速发现。
另外分享一个小技巧：profiler 采集本身是有开销的，所以我在判断“要不要开着 profiler 训练”时会分两种模式。平时跑业务，不开，只通过日志里的吞吐量曲线监控趋势。出了问题，再开一次短期 profiler（比如 3~5 个 step），拿数据对比，定位完就关掉。把 profiler 当作“听诊器”而非“生命维持仪”，它是诊断工具，不需要天天挂着。
如果你正在为训练速度慢头疼，别急着怪硬件。先跑一份 Trace，看看 GPU 到底是在真算，还是在装忙。我赌大部分时候，问题不是显卡不行，而是它没被喂饱，或者一直在嚼那些不该嚼的碎渣子。
