企业官网建设流程全解析

1. “望”：不急着跑Profile，先看清算子的性格与处境

提到算子性能分析，很多人的第一反应是开Profiler、挂Nsight，然后一头扎进时间线里翻热点。但我的习惯恰恰相反：正式动手之前，一定会先花二十分钟做静态观察。这个阶段不需要任何性能工具，只需要把模型结构、算子清单、张量形状、数据流调度方式摆到桌面上，先弄明白每个算子在这个模型里“过的是什么日子”。

性能问题本质上是一个系统问题，而算子只是这个系统里的一个环节。你看到某个算子占用了整体时间的一半，就直接钻进它的kernel内部去优化，往往会扑空。因为相当一部分“算子慢”，其实并不是kernel内部执行慢，而是任务调度、图融合、数据搬运、动态shape重编译这些外部因素造成的。先看全局，再谈局部，能帮你省下大量的无效排查时间。

1.1 从计算图和调度结构入手

第一步是看计算图。把模型导出成静态结构，按算子类型、输入输出张量形状、依赖关系列一个清单。重点看三类信息：

• 每个算子的输入/输出shape，尤其是batch维度和通道维度的变化；
• 相邻算子之间是否存在可以融合但实际没有融合的Elementwise类算子；
• 张量在设备之间的搬运点，以及Host侧与Device侧是否存在频繁同步。

举个例子，有一次我帮某团队排查一个多段融合模型的性能问题。模型本身不算复杂，大约十几个算子，在没有优化的版本里推理一次要23毫秒。团队成员已经做了很多轮kernel层面的调参，比如调整block大小、改用向量化访存，但收益都微乎其微。我接手后先把计算图展开，发现一个问题：模型前端的张量形状是动态的，batch在2到16之间波动，而框架的算子融合策略在shape变化时经常失效。每来一个新的batch值，框架就要重新触发一次融合编译，有时候一个融合组要花掉十几毫秒的重编译时间，这在总耗时里已经占了大头。

后来把输入分批静态化，设置一个维度截断策略，让不同batch都归一到适配的bucket里，重编译开销直接被削掉了一大半。整个过程没有改任何算子内部的指令，纯粹是在图结构层面做调整。这就是“望”的价值：先看布局，再下结论。

1.2 动态Shape与重编译的隐患

动态shape是一个特别容易被低估的隐形杀手。很多团队在模型交付时只测试固定shape，到了生产环境中shape一变，才发现性能掉得厉害。你要检查的不只是算子本身是否支持动态shape，更重要的是框架在动态shape下如何选择kernel实现。

现代深度学习框架通常会对相同shape的kernel做cache。shape一变，如果超过cache限制，就会重新做kernel选择和启动准备。这种“自动调优”在开发阶段很有用，但在性能敏感场景下可能变成随机延迟源。因为重编译和重新tuning的开销并不小，有时能达到毫秒级别，比许多kernel的实际执行时间还长一个数量级。

我通常会写一个小脚本，在模型推理前后打上时间戳，专门记录每个算子的首次调用时间与后续调用时间的差值。如果首次调用远慢于后续调用，说明shape切换触发了重编译。对这种场景，最常见的优化手段有三种：将动态shape映射到有限个固定bucket；关闭框架的自动调优开关并手动固化最优实现；或者干脆在模型入口处统一pad到固定shape。方案各有取舍，但核心思路是一样的：让算子的执行环境尽量确定，排除外部不确定性。

1.3 融合策略的“隐性性能”

融合是另一个需要静态观察的点。很多人认为框架里开了算子融合就万事大吉，但实际上融合的触发条件非常微妙，比如会考虑张量的连续性、内存布局、是否在计算图中被多处引用等等。一个没被融合的Elementwise算子单独看可能只占0.2毫秒，但如果连续几十个这样的算子堆在关键路径上，累积起来就是不可忽视的开销，而且多余的内存读写会压低带宽利用率。

检查融合度有个非常朴素的方法：把相邻Elementwise算子之间的中间张量在内存中产生的次数数一遍。每多一次中间张量的落地，就意味着一次读和一次写。在带宽受限的模型里，这些读写往往是比计算本身更昂贵的资源消耗。判断一个算子是否“值得融合”，可以直接对比它的算术强度——也就是计算量与访存量之比。算术强度偏低的算子，融合收益通常最大。

2. “闻”：用粗粒度采样捕捉运行轨迹，圈定嫌疑环节

静态观察把结构问题清理掉之后，才轮得到真正跑profile。但第一轮的profile不需要做得很细，我一般只用粗粒度工具把整体运行轨迹录一遍，把问题从“哪个算子慢”进一步收敛到“哪一类慢”。这一阶段的目标不是找到具体某一行指令，而是形成一张完整的嫌疑分布图。

在实际操作里，我比较常用的是两步法：先用时间线类的工具录制整个推理或训练过程，观察Host端和Device端的活动中各自的占空比；然后再用尾部采样或者轻量级计数，确认哪些算子的累计耗时排名靠前。这样可以避开“单次运行偶发变慢”带来的干扰，得到相对稳定的结论。

2.1 第一轮Profile：时间线而非热点

很多人拿到Nsight Systems或类似的工具，第一件事就是看kernel时间排序表。但我觉得第一轮更应该先看完整时间线，而不是只看热点表。时间线能直接暴露很多热点表看不到的问题，比如两个kernel之间存在明显的间隙、数据搬运和kernel执行在时间上没有重叠、Host端发出计算指令的速度跟不上Device侧执行的速度。

具体来说，我会观察这样几个时间片段：

• kernel之间的平均间隔是多少。如果这个间隔普遍大于5微秒，就要怀疑Host侧启动开销或者同步等待；
• 某个算子的输入是否被提前准备好，还是执行前才开始排队做张量拷贝；
• 数据在主机内存和显存之间的拷贝频次与总量。

用torch自带的profiler做个粗略时间线非常简单：

torch.profiler.profile( activities=[ torch.profiler.ProfilerActivity.CPU, torch.profiler.ProfilerActivity.CUDA, ], schedule=torch.profiler.schedule(wait=1, warmup=1, active=3), on_trace_ready=torch.profiler.tensorboard_trace_handler('./logs') )

跑完一轮之后，打开时间线视图，先别急着看哪个kernel颜色最深。把每个kernel之间的空白区间当成同样重要的信息：如果空白区间比kernel执行时间还长，那算子内部再优化也没用，瓶颈根本不在执行阶段。

2.2 GPU利用率不是唯一指标

“GPU利用率已经99%了，GPU很忙，那肯定没得优化了吧？”这种判断我见过太多次，实际上是一个很容易误导人的误解。GPU利用率高只代表GPU的SM上一直有任务在排队运行，完全不等于计算资源被充分利用。一个访存密集的kernel，可能SM大部分时间都在等待显存数据返回，但SM本身依然处于“忙碌”状态，所以利用率照样是高数值。

判断SM到底有没有在做有效计算，要看实际的有效运算吞吐量，而不是利用率。比如你可以对比同类型算子的理论峰值和实测吞吐，如果实测只有峰值的20%，那说明有大量周期花在了等待数据、指令发射停顿、或者分支分歧上。利用率数据适合用来判断系统是否空闲，但不适合判断代码是否高效。

更靠谱的指标就得上Nsight Compute这类工具去看：

• achieved occupancy是否达到设想的水平；
• memory throughput实际值是多少，而不是显存的理论带宽；
• 是否有大量的warp在stall状态，以及stall的reason分布。

2.3 CPU侧与数据传输的干扰

一个极度容易被忽略的性能问题是：GPU性能分析工具会把注意力全部吸引到kernel内部，而真实的延迟可能来自CPU侧的预处理和数据搬运。尤其在推理场景里，输入图片或文本的预处理、tokenization、动态padding这些操作都是跑在CPU上的。一旦CPU没有提前把下一批数据准备好，GPU就只能停下来等待，时间线上就会出现一大片“compute wait for input”的空白。

我记得有一次帮一个图像处理业务定位推理慢的问题，本质是一个看起来极简的卷积+归一化算子组合。GPU kernel单次执行只有不到1毫秒，但每次推理要执行30多次这样的组合，期间穿插着大量的图像缩放、色彩空间转换和host-to-device拷贝。真正的时间开销有将近60%花在了CPU预处理与数据拷贝上。优化手段也很直接：把预处理流水线并行起来，用另一条线程预处理下一批数据，同时合并多次小拷贝为一次连续拷贝。GPU端算子本身几乎没有改动，整体延迟却降了一半。

所以“闻”这一阶段的核心任务，是把问题精确定位到“CPU调度”“数据搬运”“kernel执行”三类环节中的哪一类。如果定位结果显示问题出在CPU侧，那么再去抠GPU kernel指令就是在错误的地方努力了。

3. “问”：用控制变量与极限实验，逼出真实瓶颈

到了这个阶段，你大概已经清楚瓶颈出现在某个kenerl或者某个子图上。接下来的问题分两步走：第一步是判定这个算子的优化空间到底有多大；第二步是确定限制性能的到底是计算能力、内存带宽、启动开销，还是并行度不足。“问”的阶段就是与系统对话，不断提出假设，再用控制变量的实验去验证。

这个阶段不需要直接改代码。我更倾向于先做实验性修改，比如调整block数量、调整线程数、改变访存模式、替换成不同的实现变体，跑一轮就记录一轮数据。本质上是用“可控变量法”给算子的性能画像。

3.1 把“慢”拆成三个维度：延迟、吞吐、占用

我拿到一个待优化的算子，首先会把它拆进三个框里：延迟、吞吐、占用。

延迟卡点：算子本身执行并不慢，但前后被同步点卡住，导致整条流水线空等。典型场景是kernel launch过密、依赖过长，或者Host侧没有做异步托管。

吞吐卡点：算子的访存带宽或计算吞吐接近硬件上限，继续调参往往收益很小，需要换算法或者减少访存量。

占用卡点：并行规模没拉开，SM上有效warp太少，无法掩盖访存延迟。典型表现是理论算力很高但实测吞吐远低于峰值，同时achieved occupancy远低于预期。

判断这三个维度最直接的实验方式，就是把线程块尺寸和网格尺寸调大调小看反应。如果改变occupancy对性能影响非常大，基本可以判定为占用卡点。如果改变网格大小没明显变化，而访存量一降就提速，那大概率是吞吐卡点。

3.2 网格与Wave：一个容易被忽略的尾部效应

很多读者可能听过“wave quantization”这个词，但在实际排查里往往被忽略。GPU在执行核函数时，SM数量是固定的。如果总block数不是SM数量的整数倍，最后一轮“wave”就会不满载，整个设备只能部分SM工作，导致本轮耗时增加。

举个例子，假设目标设备有108个SM，你的kernel被切成了120个block。前108个block完整占满一批wave，最后12个block单独占用一批wave，但只用了大约11%的SM。如果每个block的执行时间势均力敌，那么最后一轮浪费的时间就是整批wave的完整耗时。所以总执行时间不是理想中的ceil(120/108)乘以单wave时间，而是直接多算了一批。

我见过一个矩阵运算算子，naive实现只有16个block。由于block数量远小于SM那么多数，设备的计算资源大量闲置。改造思路是想办法把任务切得更碎，比如按tile切分，让网格大小达到SM数量的好几倍，这样既可以提高负载均衡度，也给调度器留出填充wave的余地。改造后最终性能提升近70%。

需要提醒的是，并不是block越多越好。block数量过多时，调度开销和block间通信成本会上升；block数量过少时，又会出现尾部wave。所谓的“合适”，通常是在两者之间取一个平衡点，具体要实测几组数据。

3.3 访存密集还是计算密集：用Roofline模型来判断

判断算子是访存密集还是计算密集，最直观的工具是Roofline模型。它的核心思想很简单：每个算子都有一个算术强度（Arithmetic Intensity），单位是FLOP/Byte，也就是平均每访问1字节数据能执行多少次浮点运算。把这个值与硬件的计算带宽和访存带宽之比——也就是机器的拐点——做比较：

• 算术强度远低于拐点：说明算子的访存量远大于计算量，性能上限由内存带宽决定；
• 算术强度远高于拐点：说明计算量占主导，性能上限由FLOPS决定；
• 如果恰好均衡附近，则优化思路要两面兼顾。

实际判断时很粗暴：把算子里的乘法/加法次数估算出来，再把算子要访问的所有输入输出大小加起来，做个比值。如果是逐元素操作类算子，算术强度通常在1以内，访问一个数只做一次运算，这种算子的优化目标一定是减少访存量，而不要去纠结浮点运算效率。因为你在访存带宽上的问题根本不需要计算指令来背锅。

4. “切”：当热点锁定之后，怎么把方案落到指令级

完成了前三步，终于到了可以打开Nsight Compute深入到kernel内部的阶段。但要注意，“切”并不仅仅指打开一个profile工具看热点行，真正的“切”是把问题的根因从“这个kernel慢”精确切割到“这个kernel里具体哪一段指令、哪一个访存模式造成了性能损失”。只有切到这个粒度，优化方案才谈得上真正落地。

到这一步我一般会做三件事：阅读kernel源码并按执行逻辑分段；用profiler查看访存与计算指标；对照Roofline做一次充分复盘。下面结合具体场景展开。

4.1 读关键源码，找访存模式

很多人跑Nsight Compute时只会看Summary页的occupancy、memory throughput这些指标，但要想真正分析，必须回到源码。至少要把kernel本身读一遍，按访存模式做分段标注。比如一个kernel里同时有全局内存顺序访问、随机索引访问、共享内存访问、以及不同分支，它们各自对性能的影响是完全不同的，必须分开来看。

我有一个常用的分段方法：把kernel切分成“取数-计算-写回”三部分，分别估算数据吞吐。取数部分需要检查访问是否对齐、合并、连续；计算部分需要看是否存在不必要的分支、低效的三角函数、类型转换；写回部分需要看是否引入了额外的原子操作或者无合并写。

我印象比较深的一个案例，是一个自定义的Gather算子。逻辑很简单：按索引从一个大表中收集若干行向量再做归一化。第一轮profile看下来，kernel的时间几乎可以忽略不计，但在一整条流水线里占的比重却非常高。后来把取数段的访存模式切出来看，发现索引数组是非连续且随机的，每次取数都触发无合并访问，L2 cache命中率不到15%。这就直接解释了一条流水线为什么会在这段浪费大量周期：因为数据总是在不同cache行之间跳来跳去，没有局部性可言。

方案是把索引先做一次排序，形成多个连续区间，再分批处理同一区间的数据。这个改动没有改变算子本身的算法逻辑，但把cache命中率从15%提到了70%左右，整体性能提升了接近3倍。

4.2 向量化与Shared Memory冲突

访存模式之外，每一类访存冲突也值得仔细检查。在GPU编程里，全局内存访问要尽量向量化，比如用float4一次读四个float，而不是连续用四条指令读四个单独的float。原因在于，向量化访存能让每个线程在单条指令里完成更大的数据搬运，有效提升内存吞吐率，同时减少指令发射数量，降低指令带宽的占用压力。

我看到很多初版kernel的问题恰恰就在没有向量化。一个elementwise的scale算子在内存布局连续的前提下，原本完全可以用float4做读取和写回，实际代码却拆成了四个标量操作。这样一通放大，访存指令数翻了四倍，指令发射也就变成了性能瓶颈。改进之后虽然没有改变总数据量，却因为指令效率的提升，得到了接近两倍的收益。

共享内存是另一个高频冲突来源。当多个线程在同一bank上访问不同地址时会产生bank conflict，导致访存被串行化。判断方法很简单：把线程访问shared memory的下标算一遍，看看同一条指令内，32个线程访问的地址是否落在32个bank里且各不相同。如果地址始终落在某几个固定bank上，则存在冲突。

比较典型的模式是访问二维共享数组，如果数组的第二维大小是32的倍数且所有线程按行访问，那么同一列的线程就会访问同一个bank的地址，产生一个N路的冲突。解决思路通常是padding：把第二维从32扩到33，让不同行错开到不同bank。这类优化虽然看起来只有一点点改动，但在高冲突场景下往往能直接换来接近两倍的总延迟降低。

4.3 优化后验证：不要只看Kernel加速比

最后一个环节，我觉得是很多人容易做错的一步：优化做完了，兴冲冲跑一轮profile，看到某个kernel从2毫秒降到0.8毫秒，就开始写总结。但这样做其实不够。因为kernel的局部时间变化并不一定意味着整个业务的效果提升了。你需要看的是端到端延迟，以及更关键的——这个优化有没有引入新瓶颈。

一个常见现象是：你把一个kernel的访存效率提高了，但它同时产生更多的中间数据，导致下一级操作的数据量变大，整体反而变慢了。另一个常见现象是：你把某个kernel的block数调大到SM数好几倍，它的调度开销上来了，在短kernel场景里反而让整体变差。所以最终验证必须回到业务的端到端指标上来。

我的习惯是优化后跑三个维度：第一个维度是目标kernel本身的时间变化，用来确认优化是否生效；第二个维度是整条流水线的端到端延迟变化，用来确认优化是否有真实业务收益；第三个维度是显存峰值和功耗的变化，用来评估优化是否付出了过高的额外代价。

只有三个维度都符合预期，我才会把这个优化方案固化进代码里。如果端到端延迟没有变化，那这个kernel优化大概率属于“局部好看但全局无效”的无效优化，不如直接舍弃。

最后再把“望闻问切”这套流程放回实际工作场景里总结一下：我见过太多性能优化卡在“不知道该先看哪里”的阶段，也见过太多人花了一整天把时间线数据翻了个遍，却忘记了真正的业务目标是什么。性能分析的产出不是一张堆满指标的报表，而是能说清楚“这个算子的性能边界在哪、是什么限制了它、应该从哪个层面动刀”的决策依据。先去静态架构里找问题，再用粗采样缩小范围，接着用实验验证假设，最后才落到指令级优化——这套顺序坚持下来，大部分算子性能问题都能在可控时间内定位清楚。如果你的项目也正在被某个说不清道不明的“慢”困住，不妨也先退一步，像中医一样真正去望、闻、问、切一遍。