模型迁到国产芯片上，能运行只是第一关。RMSNorm、门控激活、路由等算子如果仍按原计算图逐个执行，数据就会在 DDR 和片上缓存之间反复搬运。结果很常见：功能对了，延迟却下不来。
《2026年中国AI发展趋势前瞻》给出的 2025 年数据是，中国 AI 企业数量超过 6000 家，AI 核心产业规模预计突破 1.2 万亿元，同比增长近 30%。到了 2026 年，算力需求已经不只是“有没有”。同花顺刊载的《算力优化分水岭》把变化概括为“好不好用”和“划不划算”。
凤凰网财经转述的机构观点则把 2026 年称为“国产 AI 算力全线兑现元年”，并提到一季度算力租赁出现加单和涨价。这个标签是否准确可以讨论，但工程问题很具体：卡买到了，模型里的自定义算子仍要重新适配。
能跑起来，只是适配的开始
昇腾的 DaVinci 架构、寒武纪的 MLU-Core 和英伟达 Tensor Core，在缓存层级、指令调度以及矩阵与向量单元的使用方式上并不相同。在英伟达平台上可以用 Triton 处理的算子，迁到国产芯片后，往往要面对 TBE 或 BANG C。
这不是换一种语法重写代码那么简单。
以 RMSNorm 为例，Stride 没有对齐，或者 Block 大小不适合目标芯片，都可能增加片外内存访问。规约、激活和逐元素乘法如果没有融合，性能也会被多次读写拖住。更麻烦的是，有些问题不会直接报错，而是表现为难以定位的精度偏差。
2026 年 6 月 17 日，科技日报报道了大连理工大学团队研发的 OSCAR 智能编译优化系统。OSCAR 与 Auto-Kernel 不是同一套系统，但它说明了一件事：编译优化并非芯片适配的边角工作，它直接影响底层算力能否用起来。
Auto-Kernel 接管的是哪段工作
2026 版 Auto-Kernel 处理的是计算图到芯片代码之间的流程。它接收 PyTorch 导出的 TorchScript 或 ONNX 算子图，转换为中间表示，再完成算子融合、分块和目标代码生成。
针对昇腾 910D，后端生成 TBE 算子代码；针对寒武纪 MLU，则使用相应的硬件描述模板。自动搜索部分支持 Bayesian 策略，用来选择 Tiling Size 和 Pipeline Stages 等参数。
它不会替代模型迁移，也解决不了多机通信。但对于需要反复手调的自定义算子，这段流程可以从人工试错变成可重复的编译任务。
用 RMSNorm + Gated-SiLU 走一遍
下面的融合算子可用于 LLaMA 变体或 MoE 模型。它先完成 RMSNorm，再计算 Gated-SiLU：
import torch
import torch.nn as nn
class CustomRMSNormSilu(nn.Module):
def __init__(self, dim, eps=1e-6):
super().__init__()
self.eps = eps
self.weight = nn.Parameter(torch.ones(dim))
def forward(self, x, gate):
variance = x.pow(2).mean(-1, keepdim=True)
x_normed = x * torch.rsqrt(variance + self.eps) * self.weight
silu_gate = gate * torch.sigmoid(gate)
return x_normed * silu_gate
不急着生成代码，先读懂算子
导出为 TorchScript 或 ONNX 后，Auto-Kernel 会识别 pow -> mean -> rsqrt -> mul 这组逐元素计算和规约操作，并将其转成硬件无关的中间表示。
这一步解决的是算子语义。如果语义没有固定下来，后面的分块和代码生成再快，也可能得到一个性能不错但结果不对的内核。
尽量把数据留在片上
未经优化时，计算图里的多个操作可能分别读写 DDR。Auto-Kernel 会尝试将 RMSNorm、SiLU 和最后的乘法合并为一个算子，让中间结果尽量留在 SRAM 或 L1 缓存中。
这里省下的不是几行 Python，而是多次片外内存往返。对于访存受限的算子，这往往比单纯增加计算并行度更直接。
分块参数交给目标芯片搜索
编译到昇腾 910D 时，可以执行：
auto-kernel compile --model custom_rmsnorm.onnx --target ascend-910d --tune-strategy bayesian --output ./output_kernels
后端生成 TBE 代码后，会通过硬件模拟器或真机测试环搜索分块大小、流水线深度和数据对齐方案。这里使用的目标是 ascend-910d；切换到寒武纪平台时，则需要调用相应的 MLU 模板。
240 微秒降到 28 微秒，先看测试边界
现有测试采用 4096 维输入，Batch Size 为 32，结果如下：
| 运行方式 | 单次前向耗时 |
|---|---|
| PyTorch JIT 原生迁移 | 约 240 微秒 |
| Auto-Kernel 自动调优 | 约 28 微秒 |
按同一口径计算，算子性能提升约 8.5 倍。与 FP32 基准相比，数值误差保持在 10^-5 以内。
这组数字需要限定使用范围。它对应的是一个固定算子、固定输入形状和昇腾 910D 上的算子级测试。现有数据没有列出软件栈版本、预热次数和统计方法，因此不能直接换算成整模型提速，也不适合外推到其他芯片或输入形状。
上线前别只盯着内核跑分
Auto-Kernel 把大量试错交给编译器，但产线验证仍不能省。至少要检查三件事：
- 用真实输入形状复测。 4096 维、Batch Size 32 得到的分块方案，不代表其他形状仍是最优选择。
- 确认融合没有中途回退。 如果部分操作重新落回框架执行，DDR 读写和调度开销可能再次出现。
- 区分算子提速与模型提速。 Auto-Kernel 解决的是单卡算子层问题。模型扩展到多卡、多机后，HCCL 通信和网络带宽仍需单独调优。
手写 TBE 或 BANG C 不会立刻消失。遇到尚未支持的算子，或者需要压榨特定场景下的极限性能，底层代码仍有用武之地。但它不必再成为默认起点。
Auto-Kernel 的实际价值，是把算子语义、搜索空间和测试过程固定下来。工程师少做一些重复的缓存偏移计算和分块试验，把时间留给精度验证与整模型性能分析。这比一句“自动适配”更接近它在国产芯片迁移中的真实作用。
