激活函数在模型里是"便宜"的操作——逐元素计算，FLOPs 占比不到 2%。但在昇腾NPU上，激活函数的性能不取决于计算多快，取决于它跟前后算子能不能融合。ops-nn 仓库里的激活函数算子族，核心价值不在单个算子多快，在于它们都预留了融合接口。

常见激活函数在昇腾NPU上的实现

Vector 单元指令数越少，跟 Cube 单元的 MatMul 融合时 register pressure 越低。ReLU 最简单，一条比较指令搞定；Tanh 需要指数运算，register 占用大，融合收益反而小。

这里有个反直觉的结论：激活函数越简单，融合收益越大。 因为融合省的是 HBM 读写和 kernel launch 开销，不是计算时间。SiLU 比 GELU 融合友好，所以 Llama 选 SiLU 不只是因为数学性质好，也因为工程上更容易优化。

SiLU 为什么是大模型的标配

SiLU（也叫 Swish）在 Llama、Qwen、DeepSeek 里都是默认激活函数。从昇腾NPU的硬件角度看，SiLU 有两个优势：

1. 计算简单。 一次 sigmoid 加一次乘法，Vector 单元 3 条指令。GELU 需要近似计算（tanh 近似），4 条指令。
2. 融合路径多。 SiLU 可以跟前面的 MatMul 融合（ops-nn 的 linear_activation），也可以跟后面的 elementwise multiply 融合（FFN 里 gate*up 的操作）。GELU 的 tanh 近似在融合时 register conflict 更严重。

FFN 层的 SiLU 场景：
Gate: x @ W_gate → SiLU(gate) * up
      ↑ 这里的 SiLU 可以跟 MatMul 融合
      ↑ SiLU 的输出可以跟 elementwise multiply 融合
      两次融合机会

GELU 场景：
FFN: x @ W → GELU(x) → @ W_out
     ↑ GELU 只能跟前面的 MatMul 融合
     ↑ GELU 输出后是直接进下一个 MatMul，中间没有 elementwise 操作
     一次融合机会

性能数据

单独测激活函数没意义——差异在纳秒级。融合场景下的差异：

SiLU 比 GELU 快 12%，比 Tanh 快 24%。原因不是 SiLU 算得快，是融合后 register 压力小，Cube→Vector 的流水线更顺畅。

什么时候该用 ReLU

ReLU 是最老的激活函数，在大模型里几乎不用了。但在 CV 模型和轻量级网络里，ReLU 仍然是首选——不是因为性能好，是因为稀疏性。

ReLU 会把负值直接置零，输出有 40-50% 是零。在昇腾NPU上，零值可以用稀疏编码压缩，减少后续计算的 HBM 读取。SiLU 和 GELU 没有这个特性，输出全是非零值。

如果你的模型在推理时显存带宽是瓶颈（而不是计算能力），ReLU 的稀疏性可能比 SiLU 的融合友好度更有价值。但这个场景在大模型推理中不常见——大模型的瓶颈在 Attention，不在 FFN 的激活函数。

ops-nn 的融合接口

import torch_npu

# Linear + Activation 融合
out = torch_npu.npu.linear_activation(x, w, b, activation="silu")

# 支持的 activation 值：relu, gelu, silu, sigmoid
# 如果传 None，等价于普通 Linear（MatMul + Bias）

这个接口在 CANN 的 torch_npu 适配层自动生效。PyTorch 原生的 F.linear + F.silu 在昇腾NPU上会被自动替换成融合版本，不需要手动调用 npu.linear_activation。

踩坑

GELU 有两个版本。 PyTorch 的 F.gelu 默认用精确版（erf 实现），ops-nn 的融合版本用 tanh 近似版。两者精度差异在 float16 下约 1e-3，训练场景可能累积误差，推理场景无影响。如果你需要精确 GELU，设 approximate='none'，但这个不走融合路径。

激活函数选型看起来是个小事，但在昇腾NPU的融合体系里，它决定了 FFN 层能做几重融合。SiLU 是当前最优解——计算简单、融合路径多、精度够用。除非你有特殊的数学需求，否则没必要换。仓库在这里：

https://atomgit.com/cann/ops-nn