Profiling 驱动优化的标准动作

一句话定位：不凭感觉优化。这套六步动作在 Spark 与 GPU 上完全同构，是我最强的可迁移叙事——工具会换，动作不换。

1. 六步标准动作

1 采集基线

先建立可复现的量化基线（固定输入与环境、区分预热、报 P50/P99，见 5.4）。没有基线就无法证明收益。

2 定位 Top 耗时算子 / Stage

用工具按耗时排序找热点：GPU 侧用 PyTorch Profiler 算子排序 + Nsight 时间线（5.1/5.2），大数据侧用 Spark UI 的 Stage/Task 分布。必须先判定瓶颈类别（数据供给 / 调度同步 / 通信 / 计算，见 3.3），否则方向就错了。

3 提出假设与预期收益

明确写下：”我认为瓶颈是 X，做 Y 之后，指标 Z 应改善约 N%。”

• 预估收益要基于占比（Amdahl 定律）：占比 10% 的算子优化到 0，整体最多快 10%；
• 这一步能过滤掉大量”看起来很酷但收益极小”的优化。

4 单变量验证

一次只改一个变量，改完立刻复测。多变量同时改会导致无法归因（哪项起了作用、哪项起了反作用都不知道）。

5 前后对比数据留档

记录改动内容、配置差异、前后指标（含 P99 与稳定性）、结论。留档的意义：

• 避免重复踩坑与反复回退；
• 形成可对外复述的证据链（面试与汇报都靠这个）。

6 沉淀为工具 / 模板

把一次性的排查过程固化成脚本、看板、检查清单或对比表模板（如 4.7 的四维选型表）。一次优化 → 一份可复用资产，这是平台化思维的体现。

2. 为什么这是最强的可迁移叙事

同一套动作在两个领域的实例化：

步骤	Spark 场景	GPU 场景
采集基线	固定数据量与集群配置跑基准作业	固定输入分布与环境测吞吐/延迟
定位热点	Spark UI 看 Stage/Task 耗时与 Shuffle 量	Nsight 看 Kernel 时间线与空隙
提假设	“倾斜 key 导致长尾，加盐后 Stage 时间降 X%”	“数据供给不足导致锯齿，调 workers 后利用率升 X%”
单变量验证	只改分区数/只开 AQE	只改 num_workers / 只开 FlashAttention
留档	前后 Stage 耗时对比	前后 P50/P99 与利用率对比
沉淀	倾斜探测脚本、调优清单	Profiling 模板、选型对比表

结论话术：我迁移的不是框架 API，而是”先量化、再定位、再单变量验证”的工程方法论——这正是性能优化岗位真正需要的能力。

参考：NVIDIA《GPU Performance Analysis and Optimization》博客系列