1. 为什么我要在 ARM 上从零手搓一个推理引擎先说结论这个课程的核心目标是带你用 30 天时间从零开始写一个不依赖任何第三方推理框架、不依赖 BLAS、不依赖 OpenMP、甚至不依赖 libm 的纯 C 推理引擎并且让它真正跑在 ARM 架构的开发板上。关键词就三个ARM、纯 C、零依赖。适合谁适合那些已经会写 C 语言、能看懂指针和结构体但一提到“推理引擎”就觉得那是大厂框架工程师才碰的东西的人也适合手里已经有一块 RK3588 开发板、想搞清楚 NPU 之外 CPU 上到底怎么把模型跑起来的人。我为什么想做这件事因为现在市面上讲推理引擎的资料要么是讲怎么调用现成框架的 API要么是讲框架源码里某个算子的实现中间那一层——“一个最小的推理引擎到底由哪些部件组成、每个部件为什么这么设计”——几乎是空白的。你去看 ONNX Runtime 的代码几百万行光构建系统就够你喝一壶你去看 TFLiteMicro 版本倒是精简但它的算子实现和内存规划耦合得很紧不适合拿来当教学样本。而 ARM 平台上的资料更少大部分部署教程到“交叉编译一个库然后调用”就结束了真正涉及 NEON 手写 kernel、涉及内存对齐、涉及 ARM 缓存行大小的内容散落在各种角落。这个课程要填的就是这个空。30 天每天一个主题从最基础的数据结构开始到张量定义、算子实现、内存池、图执行器最后到 NEON 加速和 RK3588 上的实测。全程纯 CC99 标准不引入任何外部依赖。你写出来的东西可能性能比不上 MNN 或者 NCNN但你会彻底明白一个推理引擎的每一行代码在干什么。这种理解是调框架调一辈子都换不来的。我自己的背景是做了七八年嵌入式端侧部署从最早的 Cortex-A7 到现在的 RK3588各种坑都踩过。我见过太多人拿着 RK3588 的数据手册知道它有 6 TOPS 的 NPU但一问 CPU 上怎么跑一个小模型就卡住了。也见过太多人写 C 代码时对 NEON 一无所知明明一个循环向量化就能快三倍结果硬生生跑出个位数帧率。这个课程就是把这些经验系统化让你少走弯路。注意这个课程不教你训练模型也不教你模型量化。我们假设你已经有一个训练好的、权重是 float32 的模型比如一个简单的 MLP 或者一个小型 CNN。课程的重点是推理侧的工程实现。2. 课程整体设计与 30 天路线拆解2.1 为什么选择“零依赖纯 C”这条路线先解释一下“零依赖”到底意味着什么。不是说你不能用标准库而是说你不依赖任何推理框架、不依赖任何数学加速库、不依赖任何线程库。你可以用stdio.h打印日志可以用stdlib.h做内存分配但矩阵乘法你得自己写卷积你得自己写内存池你得自己管。为什么这么苛刻因为只有把依赖砍到零你才能真正看清每个环节的成本。举个例子如果你用 OpenBLAS 做矩阵乘法你确实快但你不知道它内部怎么分块、怎么用 NEON、怎么处理边界。当你的模型里有一个奇怪的 shapeOpenBLAS 性能突然掉下去你根本无从下手。而自己写一遍之后你知道 4x4 分块是因为 NEON 有 32 个 128 位寄存器你知道为什么要在内层循环做 FMA你知道边界处理为什么要单独拎出来。这些知识在你以后调任何框架的时候都用得上。另一个原因是 ARM 平台的碎片化。x86 上你还能假设 SSE/AVX 存在ARM 上从 Cortex-A53 到 A76 到 X4NEON 的实现差异很大缓存层级也不一样。RK3588 是 4 个 A76 加 4 个 A55 的大小核架构L1 缓存 64KBL2 每核 512KBL3 共享 3MB。这些参数直接决定了你的分块策略。如果你用现成库这些参数对你来说是透明的但如果你想榨出最后一点性能你必须自己控制。2.2 30 天大纲的编排逻辑整个课程按“数据结构 → 算子 → 内存 → 执行 → 优化”五层递进每天一个独立主题但前后有依赖关系。前 5 天打基础中间 15 天写核心算子后 10 天做优化和实测。具体安排如下阶段天数主题核心产出基础Day 1-3张量定义、内存布局、数据类型tensor.h/tensor.c基础Day 4-5模型格式解析、图结构表示graph.h/graph.c算子Day 6-10矩阵乘法、激活函数、逐元素运算gemm.c, activations.c算子Day 11-15卷积、池化、归一化conv.c, pool.c, norm.c内存Day 16-18内存池、张量生命周期、原地操作mempool.c执行Day 19-22图执行器、算子调度、拓扑排序executor.c优化Day 23-26NEON 内联汇编、循环展开、分块neon_kernels.c实测Day 27-30RK3588 交叉编译、性能剖析、调优benchmark 报告这个编排不是拍脑袋定的。前 5 天你必须把张量和图结构定清楚不然后面算子写起来会反复改接口。中间 15 天是工作量最大的部分卷积尤其耗时因为要处理 padding、stride、dilation 各种组合。后 10 天是拉开差距的地方同样的算子NEON 优化前后性能可能差 5 到 10 倍。2.3 目标平台 RK3588 的关键参数既然课程以 RK3588 为主要实测平台有必要先把它的关键参数列清楚。这些参数直接影响你的优化策略CPU4x Cortex-A76 2.4GHz 4x Cortex-A55 1.8GHz大小核架构NEONA76 支持 ARMv8.2-A有完整的 NEON 和 FP16 支持缓存L1D 64KB per coreL2 512KB per coreL3 3MB shared内存通常板载 4GB 或 8GB LPDDR4/LPDDR4XNPU6 TOPS但本课程不涉及我们只用 CPU为什么要强调大小核因为你的推理引擎如果只用单线程跑在大核还是小核上性能差 40% 以上。课程里会讲怎么通过sched_setaffinity把线程绑到大核以及为什么在 RK3588 上绑核比不绑核稳定得多。L3 只有 3MB 这个事实也很关键意味着你的模型权重如果超过 3MB就会频繁访问主存这时候分块策略就要调整。提示RK3588 的数据手册里关于缓存的部分写得比较简略建议结合 ARM 官方的 Cortex-A76 技术参考手册一起看里面关于 prefetcher 和 cache replacement policy 的描述对优化很有帮助。3. 核心细节解析与实操要点3.1 张量定义为什么内存布局决定了一切张量是推理引擎的基石但很多人对张量的理解停留在“多维数组”。在引擎实现里张量最重要的属性不是 shape而是内存布局。同样的 shapeNCHW 和 NHWC 的性能可能差好几倍。为什么因为卷积算子的内层循环访问模式不同。我们课程里采用 NCHW 作为默认布局原因是 ARM 的 NEON 在处理通道维度时NCHW 更容易做向量化。具体来说当你计算输出通道时NCHW 下输入通道是连续的可以一次加载 4 个 float 做 FMA。而 NHWC 下通道是最后一维虽然也连续但空间维度的步长变了边界处理更麻烦。张量的结构体定义大概长这样typedef struct { int ndim; int shape[4]; int strides[4]; float* data; int is_view; } tensor_t;注意strides字段。很多教学代码只存 shape计算时现算 stride这在热路径上是灾难。每次访问元素都做一次乘法累积起来开销很大。预计算 strides 是标准做法。is_view用于标记这个张量是否共享其他张量的内存这在实现 slice 和 reshape 时很有用但要注意生命周期管理否则容易出现悬空指针。另一个细节是内存对齐。NEON 的加载指令vld1q_f32虽然不要求 16 字节对齐但对齐后性能更好。我们在分配张量内存时统一用posix_memalign对齐到 64 字节这个数字来自 ARM 的缓存行大小。RK3588 的缓存行是 64 字节对齐后可以避免跨缓存行访问带来的额外开销。3.2 矩阵乘法从朴素实现到 NEON 优化矩阵乘法是推理引擎里最核心的算子全连接层、注意力机制都靠它。课程里会从最朴素的三重循环开始一步步优化到 NEON 版本。这个过程能让你直观感受到每一步优化带来的收益。朴素版本大概是这样void gemm_naive(const float* A, const float* B, float* C, int M, int N, int K) { for (int i 0; i M; i) { for (int j 0; j N; j) { float sum 0.0f; for (int k 0; k K; k) { sum A[i * K k] * B[k * N j]; } C[i * N j] sum; } } }这个版本在 RK3588 上跑 512x512x512 的矩阵乘法大概需要 200 毫秒左右。问题很明显内层循环对 B 的访问是列优先的而 B 是行优先存储每次访问都跨 N 个 float缓存命中率极低。第一步优化是循环重排把 k 循环放到最内层同时交换 j 和 k 的顺序for (int i 0; i M; i) { for (int k 0; k K; k) { float a A[i * K k]; for (int j 0; j N; j) { C[i * N j] a * B[k * N j]; } } }这样对 B 的访问变成连续的对 C 的访问也是连续的。实测性能提升大约 3 倍。但还不够因为 C 被反复读写内存带宽是瓶颈。第二步是分块。把 C 分成 4x4 的小块每个小块常驻寄存器。为什么是 4x4因为 NEON 有 32 个 128 位寄存器每个寄存器存 4 个 float。用 16 个寄存器存 C 的累加值剩下 16 个用于加载 A 和 B。这个比例是经过实测的再大就会寄存器溢出。第三步是NEON 内联汇编。用vld1q_f32加载用vfmaq_f32做乘加。核心循环大概是这样asm volatile( ld1 {v0.4s}, [%[a]], #16\n ld1 {v1.4s}, [%[b]], #16\n fmla v2.4s, v0.4s, v1.s[0]\n ... );这里有个坑fmla的第二个操作数可以是标量但标量必须来自向量寄存器。如果你直接从内存加载标量编译器会插入额外的指令。所以正确做法是先把 B 的一列加载到向量寄存器然后用v1.s[0]、v1.s[1]这种方式访问。经过这三步优化512x512x512 的矩阵乘法在 RK3588 大核上可以跑到 15 毫秒左右提升超过 10 倍。这个数字不是终点但已经足够说明问题。3.3 卷积实现im2col 还是直接卷积卷积是 CNN 里最耗时的算子。实现方式主要有两种im2col GEMM和直接卷积。课程里两种都会讲但默认用 im2col原因是它可以复用已经优化好的 GEMM 代码。im2col 的思路是把输入特征图的每个滑动窗口展开成一行形成一个矩阵然后和卷积核矩阵做 GEMM。这样做的好处是卷积变成了矩阵乘法你只需要优化一个算子。坏处是内存膨胀展开后的矩阵大小是原始输入的 K 倍K 是卷积核面积。对于 3x3 卷积内存膨胀 9 倍在 RK3588 的 4GB 内存上跑大模型可能会 OOM。直接卷积则是在滑动窗口上直接计算内存占用小但需要针对不同的 kernel size 写不同的优化代码。课程里会以 3x3 卷积为例讲怎么用 NEON 做直接卷积。核心思路是每次处理 4 个输出通道用 4 个向量寄存器累加然后一次写回。for (int oc 0; oc OC; oc 4) { float32x4_t acc0 vdupq_n_f32(0); float32x4_t acc1 vdupq_n_f32(0); for (int ic 0; ic IC; ic) { for (int kh 0; kh 3; kh) { for (int kw 0; kw 3; kw) { float32x4_t in vdupq_n_f32(input[...]); float32x4_t w vld1q_f32(weight[...]); acc0 vfmaq_f32(acc0, in, w); } } } vst1q_f32(output[...], acc0); }这里有个细节vdupq_n_f32把单个输入值广播到 4 个通道然后和 4 个权重做 FMA。这样一次计算 4 个输出通道效率比逐个通道计算高得多。但要注意权重的内存布局必须把输出通道放在最内层否则vld1q_f32加载的不是连续的 4 个权重。注意im2col 和直接卷积没有绝对优劣取决于模型结构和硬件。RK3588 上小模型用 im2col 更方便大模型用直接卷积更省内存。课程里会给出一个判断标准如果展开后的矩阵超过 L3 缓存大小3MB就考虑直接卷积。4. 实操过程与核心环节实现4.1 开发环境搭建交叉编译工具链配置RK3588 是 aarch64 架构你的开发机大概率是 x86_64。所以第一步是配置交叉编译工具链。课程里推荐用 ARM 官方提供的 GNU Toolchain版本选 10.3 或以上因为需要支持 ARMv8.2 的 FP16 指令。下载解压后把bin目录加到 PATHexport PATH/opt/gcc-arm-10.3-2021.10-x86_64-aarch64-none-linux-gnu/bin:$PATH然后验证aarch64-none-linux-gnu-gcc --version编译你的引擎时关键编译选项如下aarch64-none-linux-gnu-gcc -O3 -mcpucortex-a76 -mtunecortex-a76 \ -marcharmv8.2-afp16 -ftree-vectorize -ffast-math \ -c gemm.c -o gemm.o解释一下这几个选项。-mcpucortex-a76让编译器针对 A76 做调度优化包括指令延迟和流水线。-marcharmv8.2-afp16启用 FP16 支持虽然我们的权重是 float32但中间计算可以用 FP16 加速。-ftree-vectorize让编译器自动向量化虽然关键算子我们会手写 NEON但辅助代码让编译器自动优化能省不少事。-ffast-math允许编译器做激进的浮点优化比如重排结合律这在推理场景下是可以接受的。有个坑要注意-ffast-math会导致NaN和Inf的处理不符合 IEEE 标准。如果你的模型里有除法或者 log可能会出问题。课程里会讲怎么在关键位置用volatile或者内联汇编阻止编译器过度优化。4.2 内存池实现为什么 malloc 在推理引擎里是禁忌推理引擎的内存分配有两个特点一是频繁每层算子都可能需要临时缓冲区二是大小固定同一个模型每次推理的内存需求是一样的。这两个特点决定了malloc/free不适合因为它的开销不可预测而且容易产生碎片。课程里实现一个简单的内存池启动时一次性分配一大块内存然后按需切分。核心结构typedef struct { uint8_t* base; size_t size; size_t offset; } mempool_t; void* mempool_alloc(mempool_t* pool, size_t size) { size (size 63) ~63; // 64 字节对齐 if (pool-offset size pool-size) { return NULL; } void* ptr pool-base pool-offset; pool-offset size; return ptr; }这个实现很简单但有几个关键点。第一对齐到 64 字节前面说过是为了缓存行。第二不做 free因为推理引擎的内存生命周期是“整个推理过程”推理结束后一次性重置offset即可。第三大小估算要留余量因为不同算子的临时缓冲区可能重叠你需要做一个内存规划找出最大并发需求。内存规划是课程 Day 16-18 的重点。基本思路是遍历计算图为每个张量计算生命周期从产生到最后一个消费者然后做区间调度找出峰值内存。这个算法不复杂但能显著减少内存占用。实测下来一个 10 层的 MLP不做规划需要 2MB 临时内存做了规划只需要 512KB。4.3 图执行器拓扑排序与算子调度计算图是一个有向无环图节点是算子边是张量。执行器的任务是把图按依赖关系排序然后依次调用算子。拓扑排序是标准算法但实现时要注意几点。第一入度计算。每个算子节点记录它的输入张量来自哪些算子入度就是输入的数量。入度为 0 的节点先入队。第二就绪队列。当一个算子执行完毕它输出张量的所有消费者节点的入度减一。减到 0 就入队。第三内存复用。当一个张量的所有消费者都执行完毕它的内存可以回收。这就是前面内存池offset重置的时机。代码大概长这样void execute_graph(graph_t* g, mempool_t* pool) { queue_t q; queue_init(q); for (int i 0; i g-num_nodes; i) { if (g-nodes[i].in_degree 0) { queue_push(q, i); } } while (!queue_empty(q)) { int idx queue_pop(q); node_t* n g-nodes[idx]; n-compute(n, pool); for (int i 0; i n-num_outputs; i) { tensor_t* out n-outputs[i]; for (int j 0; j out-num_consumers; j) { node_t* consumer out-consumers[j]; consumer-in_degree--; if (consumer-in_degree 0) { queue_push(q, consumer-index); } } } } }这个执行器是单线程的。课程后期会讲怎么改成多线程但多线程的复杂度主要在于内存池的线程安全。简单做法是每个线程一个内存池但这样内存占用会翻倍。更好的做法是用原子操作管理offset但要注意对齐。提示RK3588 的大小核架构下多线程调度要小心。如果线程被调度到小核性能反而下降。建议用pthread_setaffinity_np把工作线程绑到大核主线程留在小核处理 IO。5. 常见问题与排查技巧实录5.1 NEON 优化后性能反而下降这是新手最常遇到的问题。你辛辛苦苦写了 NEON 版本结果比 C 版本还慢。原因通常有三个。第一数据依赖。NEON 指令有延迟如果你写的代码里后一条指令依赖前一条的结果流水线就会停顿。解决办法是增加独立的数据流比如同时计算多个输出通道让指令之间没有依赖。第二加载瓶颈。NEON 的计算能力很强但内存带宽有限。如果你的 kernel 里加载指令比计算指令还多那瓶颈就在内存。解决办法是复用已加载的数据比如把输入广播到多个通道减少重复加载。第三编译器干扰。有时候编译器会把你的内联汇编优化掉或者插入额外的指令。解决办法是用volatile修饰汇编块或者用asm volatile并加上memoryclobber。排查方法用perf stat看 IPC每周期指令数。如果 IPC 低于 1说明流水线停顿严重如果 IPC 高但性能低说明指令数太多需要减少冗余计算。5.2 交叉编译时链接失败常见错误是undefined reference to sqrtf或者memcpy。这是因为交叉编译工具链的 libc 可能不包含某些函数或者链接顺序不对。解决办法在链接命令里加上-lm和-lc并且确保它们放在目标文件之后。如果还不行检查工具链的 sysroot 是否完整。RK3588 的官方 SDK 里通常有预编译的 sysroot直接用那个最省事。另一个坑是静态链接 vs 动态链接。如果你在开发机上用动态链接部署到板子上可能找不到对应的 so。建议推理引擎用静态链接生成一个独立的可执行文件部署时直接拷贝过去就能跑。5.3 模型输出结果不对推理结果不对排查顺序应该是先查输入数据再查权重加载最后查算子实现。输入数据的问题通常是预处理不一致。训练时用的归一化参数mean、std和推理时不一致结果会差很多。建议把预处理参数写死在代码里和训练脚本对齐。权重加载的问题通常是字节序。ARM 是小端x86 也是小端所以通常没问题。但如果你从某些格式转换权重可能会遇到大端数据。检查方法是打印几个权重值和训练时的值对比。算子实现的问题通常是边界处理。卷积的 padding、池化的取整、激活函数的截断这些地方最容易出错。建议每实现一个算子就用 numpy 生成一组随机数据对比输出。课程里会提供一个 Python 脚本自动做这个对比。5.4 常见问题速查表现象可能原因排查方法解决方案性能低于预期未绑核taskset -c 4-7 ./engine绑到大核结果偏差大预处理不一致对比训练脚本对齐归一化参数内存占用高未做内存规划打印峰值内存实现生命周期分析编译报错工具链不匹配检查 sysroot用官方 SDKNEON 崩溃对齐问题检查指针地址用posix_memalign多线程结果错乱竞态条件用valgrind --toolhelgrind加锁或原子操作5.5 独家避坑技巧第一个技巧用perf record找热点。不要凭感觉猜哪里慢直接跑perf record -g ./engine然后用perf report看火焰图。通常你会发现 80% 的时间花在 20% 的代码上优化那 20% 就够了。第二个技巧NEON 代码先用 C 内联函数写再用汇编重写。ARM 提供了arm_neon.h里面的vaddq_f32这些函数写起来像 C编译器会生成 NEON 指令。先用这些函数把逻辑跑通确认结果正确再把热点循环改成内联汇编。这样调试成本低很多。第三个技巧RK3588 上跑推理时关掉 CPU 频率调节。默认的ondemand调速器会导致频率波动性能不稳定。用cpupower frequency-set -g performance锁定最高频率实测性能波动从 20% 降到 5% 以内。第四个技巧权重用 FP16 存储计算时转 FP32。RK3588 的 A76 支持 FP16 的 NEON 指令但 FP16 的精度对某些模型不够。折中方案是权重存 FP16加载到寄存器后转 FP32 计算。这样内存带宽减半计算精度不变。转换指令是vcvt_f32_f16一条指令搞定。6. 从课程到实战我踩过的那些坑这个课程的大纲不是凭空写的是我自己从零实现一个推理引擎时踩过的坑总结出来的。说几个印象深刻的。第一个坑是张量 strides 的计算。我一开始为了省事每次访问元素都现算 stride结果性能惨不忍睹。后来改成预计算性能直接翻倍。这个教训让我明白在热路径上任何多余的乘法都是不可接受的。第二个坑是卷积的 im2col 内存膨胀。我一开始无脑用 im2col结果跑一个 224x224 的输入展开后的矩阵有 200MB板子直接 OOM。后来改成直接卷积内存降到 20MB。这个经历让我意识到算法选择必须考虑硬件约束不能只看理论复杂度。第三个坑是NEON 的对齐问题。我用vld1q_f32加载一个没有对齐的指针在 x86 上跑得好好的到 ARM 上直接段错误。后来查手册才知道虽然vld1q_f32不要求对齐但某些微架构上未对齐访问会触发异常。统一用posix_memalign之后问题消失。第四个坑是多线程的内存池竞争。我一开始用全局内存池多线程跑的时候结果随机出错。用valgrind查了半天才发现是offset的竞态。后来改成每个线程独立内存池问题解决但内存占用翻倍。再后来用原子操作加 CAS 循环才做到既线程安全又不浪费内存。这些坑每一个都让我卡了一两天。课程里会把这些坑提前标出来让你直接绕过。但我也要说有些坑必须自己踩过才能记住。所以课程里会留一些“故意不优化”的版本让你先跑出错误结果再自己动手修。这种学习方式比直接看正确答案有效得多。最后分享一个小心得推理引擎的性能优化80% 的收益来自 20% 的改动。不要一上来就想着手写汇编先把算法复杂度降下来再把内存访问模式调好最后才考虑指令级优化。我见过太多人一上来就写 NEON结果算法本身是 O(n^3) 的优化半天还不如换个算法。顺序很重要。
