1、算子库的起源：从手写汇编到标准库的演变，为什么我们需要算子库？

大家好，我是你们的老朋友。今天咱们聊聊算子库的起源。

说实话，我入行那会儿，深度学习还没现在这么火。那时候做AI芯片，最头疼的就是——算子怎么写？

你可能觉得，写个卷积、写个矩阵乘，有什么难的？

嗯，如果你这么想，那说明你还没经历过「手写汇编」的年代。

1.1 从手写汇编说起

最早期的AI芯片，比如我参与过的第一代NPU，根本没有所谓的算子库。

那时候，每个算子都是工程师手写汇编代码。

举个例子，一个简单的ReLU激活函数：

// 伪汇编代码：ReLU实现
LOAD R1, [input_addr]   // 加载输入数据
CMP R1, #0              // 比较是否大于0
BLT ZERO                 // 如果小于0，跳转到ZERO
STORE R1, [output_addr] // 存储原值
JMP DONE
ZERO:
STORE #0, [output_addr] // 存储0
DONE:

你看，就这么几行代码，我得反复调试。为什么？因为芯片的指令集、内存布局、流水线，每个细节都得自己把控。

我记得有一次，一个卷积算子的汇编代码写了整整两周。结果一跑，性能还不如预期的一半。排查下来，是数据对齐出了问题。嗯，这种坑，踩过一次就记住了。

1.2 为什么不能一直手写？

你想想看，一个AI模型里有多少算子？

卷积、池化、全连接、激活函数、归一化、损失函数……少说几十种。

每种算子，又分不同数据类型（float32、float16、int8）、不同尺寸（3x3、5x5、7x7）、不同布局（NCHW、NHWC）。

如果每个组合都手写汇编，那工作量是天文数字。

更关键的是——可移植性。

我换了一款芯片，指令集变了，所有汇编代码都得重写。这谁受得了？

1.3 标准库的诞生

所以，行业里开始思考：能不能把常用的算子封装起来，形成一套标准接口？

这就是算子库的雏形。

最早的标准库，比如Intel的MKL（Math Kernel Library），专门针对CPU优化了矩阵运算、FFT等基础操作。

后来，NVIDIA推出了cuBLAS、cuDNN，专门为GPU优化深度学习算子。

这些库的出现，让开发者不用再关心底层汇编。你只需要调用一个函数：

// 使用cuBLAS做矩阵乘法
cublasSgemm(handle, CUBLAS_OP_N, CUBLAS_OP_N,
            m, n, k, &alpha, dA, lda, dB, ldb, &beta, dC, ldc);

一行代码，搞定矩阵乘。底层怎么优化？那是库的事。

我个人习惯，把这种演变总结为三个阶段：

阶段	特点	代表
手写汇编	完全定制，性能极致，但开发成本极高	早期NPU、DSP
硬件专用库	针对特定硬件优化，接口标准化	cuDNN、MKL
跨平台算子库	一次编写，多平台运行	ONNX Runtime、TVM

1.4 为什么我们需要算子库？

说白了，算子库解决了三个核心问题：

• 开发效率：不用重复造轮子。你写一个卷积，别人也写一个卷积，何必呢？
• 性能保障：算子库通常由资深工程师优化，比你手写的快得多。
• 生态兼容：不同框架（PyTorch、TensorFlow）都能调用同一套算子库，互操作性大大提升。

我曾经在一个项目里，团队坚持手写所有算子。结果呢？项目延期了三个月，性能还不如用现成的cuDNN。从那以后，我再也不建议「从零造轮子」了。

1.5 算子库的核心逻辑

为了让你更直观地理解算子库的架构，我画了一张图：

从这张图你能看到，算子库处于应用层和硬件层之间。它把底层的硬件细节封装起来，向上提供统一的接口。

说白了，算子库就是一座桥。桥的一头是算法工程师，他们只关心模型结构；桥的另一头是芯片，它只关心指令执行。算子库让两者各司其职，互不干扰。

1.6 小结

回顾一下，算子库的起源其实很简单：

• 手写汇编太痛苦，效率低、移植难
• 标准库的出现，让开发者从底层解放出来
• 算子库的核心价值：提效、保性能、建生态

嗯，这一章就到这里。下一章，我会聊聊算子库的「壁垒」到底是怎么形成的。为什么有些算子库，别人就是抄不走？

---