把模型塞进SRAM阵列，第一次跑通要几步

上个月做端侧方案评估，卡在一个很别扭的地方。模型本身不大，一个语音唤醒加一层视觉前端，参数量压到几百KB，可功耗和延迟怎么调都下不来。后来查下来，瓶颈不在算力，而在搬数据。算一次，权重从内存搬到计算单元，算完再搬回去，这部分开销比计算本身还大。

存算一体就是为了解决这个问题的。它的做法是让计算发生在存数据的地方，不用来回搬。SRAM是芯片里的高速小仓库，读写快、断电就忘，用成熟CMOS工艺做，能上先进节点。微纳核芯这套SRAM存算一体，我拿到的是评估套件，不是能直接插上就用的成品板，所以下面这套流程你手上的版本菜单名可能不一样，大步骤是通的。

先说清楚它的好和不好，省得你跑到一半才发现方向不对。

能效这块确实是它的立身之本。公开综述里提到，数字存算路线复用常规数字电路和成熟EDA流程，精度可控，量产风险不大，能效比GPU提升大约三到五倍。我这边跑一个小卷积网络，功耗表上的数字比同任务在通用NPU上低一截，具体倍数不敢说，因为测试条件不一样。

精度是确定的。SRAM存算是数字电路，不是模拟那套电荷累加，所以结果可复现，同一输入跑十次出来一样。做产品的人会在意这个。

延迟可预期。权重放在阵列里，一次读就是一次算，没有缓存miss那种抖动。对实时性要求高的场景是好事。

缺点也得摆出来。SRAM基本单元是6个晶体管组成的锁存结构，密度本来就低，做存算还要加控制管，常见8T、10T甚至更多，所以阵列容量上不去。我这次的模型是硬压到能塞进单块阵列的，再大就得切分，切分之后跨阵列通信的开销会吃掉一部分收益。另外静态漏电流偏高，待机功耗要单独看。工具链生态也薄，文档和报错信息都比较省。

下面走流程。

1. 先确认你手上有什么。套件一般三样。一块带存算阵列的评估板、一根调试线、一套SDK。板子上电，用串口工具连上，波特率按文档设，正常会看到启动打印。看不到就换线，我第一根线是只能充电的那种。

2. 装工具链。SDK里通常有个环境脚本，跑一遍把编译器和模型转换工具加进路径。跑完敲一下版本命令，有回显就对了。

3. 先跑官方例程，别急着换自己的模型。例程里带一个已经量化好的小模型和一份映射配置。命令大概是 make demo 这种形态，编译完会输出一个映射报告，告诉你哪层权重落在阵列的哪个位置、占了多少行。这份报告是后面所有问题的入口。

4. 换成你自己的模型。这一步要过量化，把浮点权重压成整数，因为阵列里做的是定点乘加。量化脚本一般带校准数据，喂几百条真实输入进去，让它统计每层的数值范围。

5. 编译并看映射报告。重点看两件事，有没有层被切到阵列外面回落到CPU，以及阵列占用率。回落不报错，但性能会掉。

6. 跑推理，比对结果。拿同一批输入分别喂给PC上的浮点模型和板子，逐条比。差得离谱先查输入预处理，差一点点是量化损失。

踩坑主要三个。一是量化掉点，校准数据和你实际场景分布不一致，分类边界会糊，换一批更贴近现场的校准数据通常能救回来。二是容量超了不报错，只是悄悄切分，实际一半在CPU上跑，看映射报告才能发现。三是输入归一化不一致，板子端和训练端的均值方差没对齐，程序跑得通，结果全错，这个最费时间。

环节	传统流程	SRAM存算
权重读取	每算一次搬一次	权重常驻阵列
中间结果	可随时打印	阵列内不可见，靠仿真
容量	看DRAM	看阵列行数，很紧
精度	浮点为主	需量化，数字电路可复现

我的判断是，这套东西现在适合模型小、功耗敏感、出货量大的场景，不适合拿来做通用大算力。工具链的成熟度还得再等一两轮迭代。

往后看，我猜接下来两年SRAM存算会先在端侧小模型上落地，语音唤醒、传感器融合、视觉前端这类，而不是直接去碰大模型的主战场。容量和生态这两道坎，短期内绕不过去。

学完这套流程，下一步可以试的，是把同一个模型分别编译到阵列和CPU两条路径上，跑同一批数据做功耗对比。那个数字比任何参数表都实在。