4、手工融合的优缺点：性能提升明显、调试困难、维护成本高、缺乏通用性
手工算子融合，说白了就是靠人肉去抠性能。我做了这么多年编译器，坦白讲，手工融合确实能带来肉眼可见的加速，但代价也不小。今天咱们就掰开揉碎聊聊它的优缺点。
4.1 性能提升明显——为什么手工能赢过自动？
手工融合最大的底气，就是性能。你想想看，自动融合工具再聪明，它也得遵守通用规则。而人不一样，人可以针对特定模型、特定硬件，搞出一些「不讲武德」的优化。
我记得有一次优化一个BERT模型，自动融合工具死活不肯把LayerNorm和后面的Add合并。为什么？因为工具认为这两个算子的数据流图有分支，合并后可能影响精度。但我仔细看了下，这个分支其实是个恒等路径，根本不影响结果。于是我手动写了个融合kernel，直接把LayerNorm+Add+Residual三个操作塞进一个CUDA核里。结果呢？延迟从2.1ms降到了1.4ms，提升了33%。
手工融合的典型收益场景：
- 小算子密集场景：比如多个element-wise操作（ReLU、Add、Mul）串在一起，手工合并能省掉大量中间读写
- 特殊硬件特性利用：比如NVIDIA的Tensor Core对某些数据排布有特殊要求，手工融合可以提前做好布局
- 跨边界融合：自动工具通常不敢跨子图边界融合，但人可以大胆地做
但这里我要泼一盆冷水。性能提升明显，不代表每次都能提升。我在项目中遇到过一种情况：手工融合后，寄存器压力暴增，导致编译器不得不做大量spill（溢出到内存），结果性能反而下降了。嗯，这就是典型的「过度融合」陷阱。
4.2 调试困难——改一行代码，查三天问题
手工融合最大的痛点，就是调试。为什么？因为融合后的kernel不再是简单的「先算A再算B」，而是把多个算子的逻辑揉在一起。一旦出问题，你根本不知道是A算错了，还是B算错了，还是融合逻辑本身有bug。
我曾经写过一段融合kernel，把Conv、BN、ReLU三个算子合并。跑起来结果不对，精度掉了0.5%。我花了整整两天时间，一行一行地对比中间结果。最后发现，问题出在BN的running_mean更新逻辑上——手工融合时我忘了把BN的推理模式和训练模式分开处理。
避坑指南：
我曾经因为手工融合后数值精度对不上，排查了整整一周。后来学乖了，每次写融合kernel之前，先写一个「分步验证脚本」：把融合前后的中间结果全部dump出来，逐层对比。虽然麻烦，但能救命。
调试困难的另一个原因，是工具链支持差。你想想看，自动融合工具好歹有可视化图、有profiling报告。手工融合呢？你只能靠printf大法，或者用NVIDIA的cuobjdump反汇编看生成的PTX代码。说白了，就是「裸奔」。
4.3 维护成本高——写一次爽，改一次哭
手工融合的代码，通常都是高度特化的。什么意思？就是针对某个模型、某个硬件、某个batch size写的。一旦模型升级了、硬件换代了、或者batch size变了，你的融合kernel可能就废了。
我举个例子。之前为ResNet-50手工写了一个Conv+BN+ReLU的融合kernel，跑在V100上效果很好。后来换了A100，我心想「架构差不多，应该能直接跑吧？」结果一测，性能反而比不融合还差。为什么？因为A100的Tensor Core对数据排布要求更严格，我原来的融合逻辑没考虑到这一点。
维护成本高还体现在团队协作上。你想想看，一个团队里如果有三个人各自写了不同的手工融合kernel，那代码库就变成了「三套方言」。新人接手时，光看懂这些融合逻辑就得花两周。
我的建议：
如果一定要用手工融合，至少做到两点：第一，把融合逻辑写成独立的函数，加上详细的注释；第二，写一个自动化测试脚本，每次改完代码后自动验证精度和性能。别问我为什么知道——我曾经因为没写测试，改了一个融合kernel后把整个模型的精度搞崩了，还浑然不知。
4.4 缺乏通用性——一个模型一套方案
手工融合最大的硬伤，就是通用性差。你为一个模型写的融合方案，基本没法直接迁移到另一个模型上。为什么？因为不同模型的算子组合、数据流图、计算密度都不一样。
我做过一个对比实验：针对三个不同的模型（ResNet、Transformer、LSTM），分别手工做了算子融合。结果呢？ResNet的融合方案在Transformer上完全没用，因为Transformer的核心是Attention，跟CNN的Conv+BN模式完全不同。而LSTM的融合方案更是「独一份」——它的循环结构导致融合逻辑必须考虑时间步的依赖关系。
| 模型类型 | 手工融合方案 | 可迁移性 |
|---|---|---|
| ResNet（CNN） | Conv+BN+ReLU融合 | 仅适用于CNN类模型 |
| Transformer | QKV投影+Attention融合 | 仅适用于Attention结构 |
| LSTM | 门控计算+状态更新融合 | 仅适用于循环结构 |
说白了，手工融合就是「定制化」的极致。你投入了大量精力，换来的是针对特定场景的极致性能。但一旦场景变了，这些投入就打了水漂。
4.5 手工融合 vs 自动融合：一张图看懂
下面这张图，是我自己总结的手工融合和自动融合的对比。你可以直观地看到，手工融合在性能上占优，但在调试、维护、通用性上全面落后。
从这张图可以看得很清楚：手工融合在性能维度上「一骑绝尘」，但在调试、维护、通用性三个维度上全面落后。自动融合虽然性能不是最顶尖的，但胜在均衡——每个维度都能做到中等水平。
4.6 什么时候该用手工融合？
说了这么多缺点，是不是手工融合就一无是处了？当然不是。我个人的经验是，以下场景可以考虑手工融合：
- 极致性能需求：比如推理延迟要求1ms以内，自动融合达不到
- 固定模型+固定硬件：比如某个模型要在某个芯片上跑一年，值得投入
- 自动工具无能为力：比如某些自定义算子，自动融合工具根本不认识
但如果你问我个人建议，我会说：能用自动融合，就别用手工。手工融合就像手写汇编——你知道它能跑得更快，但代价是你要付出十倍的时间和精力。而自动融合，虽然性能不是最顶尖的，但它稳定、可维护、可迁移。说白了，在大多数场景下，「够用」比「极致」更重要。
总结一下：
手工融合是一把双刃剑。用好了，性能起飞；用不好，调试到崩溃。我的建议是：先让自动融合工具跑一遍，看看性能瓶颈在哪。如果自动融合已经够用了，就别折腾了。如果确实有瓶颈，再针对性地做手工融合。记住，不要为了融合而融合。
想要更多资料，联系可可