少一次写回、少一次读取，按理说算子融合应该让内核跑得更快，但实际开发中经常碰到反直觉的现象——融合之后性能不升反降。问题往往不出在数学运算本身，而在于数据活跃期被拉得过长。编译优化时最容易误判的不是融合能省多少访存，而是寄存器和片上缓存到底能不能扛住融合后同时存活的中间值。
融合带来的好处很直接：中间结果不必写回片外显存，访存事务减少，调度开销也随之下降。但每往内核里多塞一个算子，所有相关数据的生命周期都在延长——输入、输出、临时缓冲、索引变量、部分累加和，原本单个核内一闪而过的值，在融合后的长流水线里可能要跨越多个阶段同时存活。寄存器分配器的压力随之骤增，最终只能把一部分变量溢出到本地存储甚至更慢的层级。
溢出一旦发生，融合省下来的带宽马上被新增加的回写和重读抵消掉。更麻烦的是，溢出往往牵出一连串连锁反应：更多的地址生成指令、额外的同步屏障、更复杂的依赖图，表面上只多了几次存储和加载，实际上却把整条流水线的有效占用率拉低了一大截。某些内核最终不是算得慢，而是大部分周期都在应付融合后过于臃肿的活跃变量集合。
寄存器压力还会以更隐蔽的方式侵蚀吞吐能力。许多AI加速器的并行度与寄存器配额直接挂钩——一个线程块、warp或tile占用的寄存器越多，芯片上能同时驻留的计算单元就越少。即便单个实例的片外访存确实减少了，整体芯片却丧失了靠大量并发掩盖访存延迟的能力，最终端到端的耗时反而更长了。

对编译器而言，最难拿捏的是融合深度该划在哪里。激活函数、偏置加法和简单的归一化操作通常适合贴近主算子融合，但涉及大跨度归约、复杂索引变换或需要额外workspace的步骤，硬塞进同一个内核往往得不偿失。真正高效的策略不是一味堆深度，而是在寄存器压力和指令开销开始反噬收益之前主动收手。
局部回退比全盘否定融合更现实。比如只把寄存器压力最大的那小段逻辑拆出去单独执行，或者调整计算顺序压缩某些中间值的存活窗口，同时保留前后端那些容易复用的数据通路。这样既能守住主要的访存收益，又不会让内核因为活跃集爆炸而整体失控。
排查融合导致的性能回退时，不能只看总访存量降了多少，还要盯住寄存器占用率、溢出字节数、并发驻留单元数和指令缓存命中率这几个指标。这几项数据放在一起看，很快就能判断出带宽是真实省下来了，还是寄存器先被压垮了。
代码体积也是一个经常被忽略的变量。融合越深，生成的内核里分支判断、地址计算和谓词控制就越复杂，前端取指和解码的压力随之上升。再加上谓词执行和向量重排带来的额外开销，部分后端即使算子数量减少了，也会因为指令发射效率下滑而丢失本该到手的并行收益，长链融合中这种现象尤其明显。有些场景即便没有发生显式溢出，指令流过重也足以把理论上的融合收益磨掉一大截。调试时如果只看算子级统计，很容易把前端发射受限误判成带宽瓶颈。
说到底，融合反而变慢，通常不是优化方向本身有误，而是活跃值的生命周期没有被有效管控。把融合边界围着寄存器压力来画，编译器算出来的收益才不会在执行阶段又被硬件吐回去。