算子与编译器：性能反模式与失败案例

很多算子优化失败，并不是因为工程师不够努力，而是因为掉进了一些反复出现的性能反模式。它们的共同特点是：单看局部实现似乎合理，放到真实系统里却会不断放大损失，并且往往伴随“理论上应该更快，实际上却不快”的现象。

把这些反模式单独列出来很有价值，因为它能帮助你少走很多弯路。

初学者先抓住

性能反模式通常不是“看起来明显错误”的写法，而是局部合理、全局变慢的选择。看到理论 FLOPs 下降、融合更多、低精度更低时，都要回到真实数据流和端到端指标验证。

难点解释：为什么局部最优会伤害系统

一个 kernel 为某个 shape 极致优化，可能增加 dispatch 复杂度、fallback 比例或维护成本；一次融合减少了 launch，却可能让寄存器溢出。系统性能看的是完整路径，不是单个指标漂亮。

1. 反模式一：只看 FLOPs，不看数据流

最常见的误判是：算法 FLOPs 更少，所以实现也应该更快。现实里，如果这个算法引入了更多中间张量、更多 layout 变换、更多不连续访存或更多 launch，那么它完全可能比“FLOPs 更多”的老方法更慢。

2. 反模式二：为了融合而过度融合

Fusion 通常是好事，但并不是越多越好。过度融合常导致 register pressure 爆炸、occupancy 下降、autotune 空间失控、边界 case 极难维护，某些 shape 上甚至反而更慢。

因此融合的判断标准应该是“是否减少了真正昂贵的数据移动”，而不是“是否把更多逻辑塞进一个 kernel”。

3. 反模式三：把训练优化直接照搬到服务

训练里有效的优化，放到服务里未必有效。例如把大 batch GEMM 思路直接搬到 decode，把训练 attention 路径直接搬到 paged KV，或者只看平均吞吐、不看 TTFT 和 tail latency，都会把训练负载和在线服务负载混为一谈。

这种反模式在推理服务系统里非常常见，因为训练和推理的负载画像本来就不同。

4. 反模式四：只测最漂亮的 shape

如果一个 kernel 只在完美对齐 shape、固定 batch、单一 dtype 和最适合的设备上测试，那么它的结果很难说明真实系统收益。
真实 workload 往往是 shape 分布，而不是单点 shape。

5. 反模式五：没有 fallback 却做大量特化

shape specialization 是有价值的，但如果没有 fallback，就会出现低频边界 shape 无法处理、新模型结构一改就断、线上因为某个罕见请求直接回退失败等问题。

成熟系统通常是“热点 shape 特化 + 低频 shape 保守 fallback”，而不是彻底抛弃通用路径。

6. 反模式六：把 profile 结果看成单层真相

只看一个 profile 维度很容易误判：系统级 trace 只能看到慢，不一定知道为什么慢；单 kernel profile 只能看到局部，不一定看到全局瓶颈；微架构级指标很细，但不一定说明端到端最值得优化的地方。真正稳妥的做法，是把系统级、kernel 级和微架构级三层信息串起来看。

实践中可以把一次性能分析拆成三问：端到端 trace 里用户等待在哪里，热点 kernel 里时间花在算力、带宽、同步还是 launch，微架构指标是否支持这个判断。三层证据一致时再动手改 kernel；如果三层证据相互矛盾，优先补测 workload 和 shape 分布，而不是立刻写新实现。

7. 反模式七：忽略维护成本

一个 kernel 即使很快，如果只支持一代 GPU、一升级框架就坏、很难调试、没有回归基线，那么它也很难成为真正的系统资产。
这类问题短期内不显眼，长期却最致命。

7.1 把反模式写进评审

性能评审最好不要只问“快了多少”，还要问“慢在哪里被转移了”。一次优化如果增加了 layout 变换、编译版本、dispatch 分支或 fallback 风险，就应该把这些代价写进评审记录。这样后续出现 tail latency、冷启动或兼容性问题时，团队能回到当初的取舍，而不是重新猜一遍。

一个简单但有效的做法是为每次性能优化附带反例：哪些 shape 不受益，哪些硬件不支持，哪些路径要禁用，什么指标触发回滚。反模式一旦被制度化记录，就不再只是经验教训，而会变成后续设计的护栏。

这也解释了为什么性能优化要有“退出条件”。如果一个方案只能在单点 benchmark 上赢，但在真实流量下需要大量特判、复杂 fallback 和额外监控，它可能仍然值得放进实验分支，却不一定适合进主服务路径。好的性能工程会把收益、适用范围和代价一起交付。

8. 一个形象比喻

这些反模式就像赛车改装中的典型误区：只换更大马力的引擎却不管传动和轮胎，只在理想赛道测试却忽略真实天气，只追求极端轻量化却不考虑长期可靠性。算子优化也是一样，真正的工程能力不是“做出最极端的一次加速”，而是避开这些高频反模式，稳定地把收益带到真实系统里。

9. 小结

性能反模式之所以值得专门总结，是因为它们往往比“正向技巧”更能帮助团队建立判断力。知道哪些思路看起来对、实际常错，往往比多背几个优化技巧更重要。高性能系统最终拼的，不只是会做什么优化，更是知道什么优化不该做、什么时候该停下来回到 profile 和 workload 本身。

工程收束

性能反模式要围绕无效搬运、错误融合、坏布局、过度特化和同步放大来排查。不要只优化单个指标，也不要把问题藏进复杂 kernel；更稳的做法是为反模式建立案例库，每次优化写反例，将失败模式纳入 code review，并做端到端回归。

这类页面的价值在于帮团队建立“停下来”的判断：当一次优化开始牺牲可解释性、可维护性或尾部稳定性时，应该先回到 profile 和 workload，而不是继续往 kernel 里堆复杂度。

长期看，反模式库本身就是性能团队的知识资产，能让新人少重复踩坑。

它也能让 code review 从“感觉会不会快”变成“哪些代价已经被显式记录”。

真实排查案例：低比特路径省显存，却拖慢首 token

输入症状：把一个 13B 服务从 FP16 切到 W4A16 后，显存占用下降明显，但 TTFT 从 820ms 增到 1.25s，短问答用户感知变差。

关键指标：权重显存下降约一半，batch 上限提高；但短请求 prefill latency 上升，dequant kernel 占比升高，小 batch 下 Tensor Core 利用率下降；长输出请求的 TPOT 反而略有改善。

Nsight / trace 观察：trace 显示每层 linear 前后多出 dequant / layout 转换片段；长 decode 中权重带宽收益能摊薄这些开销，短 prefill 中额外 kernel launch 和转换成本更显眼。

判断：这是“只看显存，不看请求桶”的反模式。W4A16 并非全局更优，它把瓶颈从显存容量转移到低 batch 的解量化和 kernel 支持上。

修复：按请求桶启用量化：长上下文和高并发租户走 W4A16，短问答保留 FP8/FP16 或使用更成熟的 W8A8 路径；把 TTFT、TPOT、显存水位、质量掉点放进同一张验收表。

反例：如果服务主要是长输出、高并发、decode 带宽受限，且 runtime 有成熟 fused dequant GEMM，低比特路径可能同时省显存和提吞吐。反模式不是量化本身，而是把一个桶的收益套到所有桶。