<p>PyTorch Profiler需精准配置才能定位瓶颈：必须启用ProfilerActivity.CPU、用record_function包裹数据加载逻辑、配合schedule跳过warmup，并优先分析Self CPU/cuda time及# Calls等关键列。</p>
PyTorch Profiler 不是“开了就能看出瓶颈”的开关，而是需要精准配置+合理埋点+针对性解读的诊断工具。默认参数下跑出来的 trace，大概率看不出真实问题。
为什么 profile 跑完没看到 data_loader 瓶颈？
常见现象：GPU 利用率低、训练慢，但 profiler 输出里 aten::copy_ 或 aten::add 排第一，DataLoader.__next__ 却几乎不显形。
- 根本原因：没开
ProfilerActivity.CPU，或没把record_function包住实际数据加载逻辑 —— profiler 只记录了 tensor 运算，没捕获 Python 层的阻塞等待 -
record_function("data_load")必须包裹在for inputs, targets in train_loader:循环体内，而不是只包model(inputs) - 如果用了
num_workers > 0，还要确认pin_memory=True，否则 profiler 会把内存拷贝（cudaMemcpyAsync）归到 CPU 时间里，掩盖真实 I/O 延迟 -
record_shapes=True能帮你发现 loader 输出张量尺寸不一致（比如 batch 最后一个不满），导致后续算子反复重编译 —— 这种问题在 table 里表现为同一算子# Calls异常高
ROCm / AMD GPU 上 profiler 为啥只显示 CPU 时间？
在 Instinct MI300X 或其它 ROCm 设备上，ProfilerActivity.CUDA 依然可用，但必须确保底层 HIP 驱动与 PyTorch 版本匹配；否则 profiler 会静默降级为仅 CPU 模式。
- 先验证设备识别：
torch.cuda.is_available()和torch.cuda.get_device_name(0)必须成功返回，否则 profiler 不会启动 CUDA activity - ROCm 7.x+ 的 PyTorch 构建中，
ProfilerActivity.CUDA实际调用的是 HIP profiling 接口，不是 NVIDIA CUPTI —— 所以不要试图传ProfilerActivity.HIP，它不存在 - 若输出中
cuda_time_total列全为 0 或空，检查 PyTorch 是否为 ROCm 编译版本：torch.__config__.show()里应含rocm字样，而非cuda - ROCm 下
profile_memory=True仍有效，但显存分配事件（MEM_ALLOC）可能比 NVIDIA 平台略滞后，建议配合torch.cuda.memory_summary()交叉验证
怎么避免 profiler 拖慢训练、干扰真实性能？
profiler 开销本身会改变调度节奏，尤其在 warmup 阶段未完成时就采样，容易把 kernel 编译时间误判为计算瓶颈。
Python Matplotlib Chinese Font
下载
使用 font_manager.addfont() 添加中文字体文件，设置 rcParams['font.family']，并禁用 unicode_minus，使 matplotlib 显示中文。
立即学习“Python免费学习笔记（深入）”；
- 必须用
schedule=torch.profiler.schedule(wait=1, warmup=1, active=3)：跳过 step 0（初始化抖动），step 1 预热（触发 kernel 编译），只分析 step 2–4 的稳定态 -
with_stack=True会显著拖慢 profiler（尤其 deep model），只在查自定义nn.Module或封装层时启用；定位算子级瓶颈时可关掉 - 别在每个 batch 都调
prof.step()后立刻on_trace_ready写磁盘 —— 改成每active周期写一次，或用tensorboard_trace_handler('./log')异步落盘 - 训练循环里插
record_function时，避免嵌套过深（如在 for 循环内反复新建 record_function 块），否则 profiler 元数据开销会累积
看哪几列才能快速定位真瓶颈？
别被 cpu_time_total 排序带偏 —— 它包含所有子调用耗时，容易把顶层 wrapper 函数（如 nn.Sequential.forward）排第一，而真正耗时的 conv2d 反而藏在下面。
- 优先看
Self CPU time total：排除子调用干扰，直接反映该算子自身执行时间 - 结合
cuda_time_total和Self cuda time total对比：若前者远大于后者，说明大量时间花在同步等待（如torch.cuda.synchronize()或隐式同步） - 关注
# Calls异常值：>1000 次的index_select或gather，基本等于你在 GPU 上写了 Python for 循环 - 打开
profile_memory=True后，检查allocated memory峰值是否集中在某一层输出 —— 如果某 layer 输出 tensor 显存暴涨且没被及时释放，可能是中间变量未 detach 或 gradient 计算路径异常
最易被忽略的点：profiler 不会自动告诉你「为什么」某个算子慢，它只告诉你「哪里」慢。比如看到 aten::native_layer_norm 耗时高，得进一步查输入 shape 是否触发了非最优实现路径（如 batch size=1 时 fallback 到 CPU path），而不是直接换算子。
