RISC-V切入AI芯片这件事，最近两年几乎成了做嵌入式AI、定制芯片和端侧推理的工程师绕不开的话题。原因很朴素：AI芯片的算力需求越来越分化，通用CPU扛不住卷积和矩阵乘，专用的NPU/DSA加速器又需要有人来调度、搬运数据、跑控制流，而RISC-V这个开源指令集恰好能补上“灵活控制器”和“可扩展计算核心”这两个位子。
很多人以为RISC-V做AI芯片就是把RISC-V核和NPU拼在一起，其实这只是其中一种打法。业界实际在走的路线至少有三条，指向完全不同的架构权衡和产品定位——更准确地说，是“让RISC-V做AI芯片的大管家”“让RISC-V的向量扩展亲自上场算”“给RISC-V开小灶做自定义指令”这三大类。这篇内容不聊虚的，直接拆这三条路怎么选、怎么实现、各自踩过的坑，以及我实际测试下来的体会，给正在做方案选型或者准备入局的朋友一个可以直接参考的坐标。
1. 为什么RISC-V能和AI芯片走到一起：先理解AI芯片的“五脏六腑”
要搞懂RISC-V怎么切进AI芯片，得先退一步，看看一颗AI芯片里到底都有什么。无论是手机SoC里的NPU、自动驾驶芯片、还是云端推理卡，从芯片内部结构看，基本都逃不过四个部分：一个或多个CPU核用来跑调度和通用代码，一堆算力阵列（MAC阵列、张量核心、向量ALU）用来做重计算，一套片上存储和总线负责搬运数据，再加上DMA、中断控制器这些周边。真正决定一颗AI芯片架构的，不是算力阵列有多猛，而是“谁说了算”和“算力单元之间怎么协作”。
1.1 RISC-V的模块化设计天然适合“拼接”
RISC-V指令集最特殊的地方在于它不是一个说一不二的“完整指令集”，而是一个可以按需拼装的积木盒。基础指令集RV32I/RV64I只保证最核心的整数运算，M扩展管乘除法，A扩展管原子操作，F/D扩展管单精度和双精度浮点，C扩展管压缩指令，V扩展管向量计算，后面还有一大堆Zb*位操作扩展。这种做法的好处是做AI芯片的人可以只选自己需要的模块：比如端侧AI SoC里选RV64GC加上V扩展和自定义扩展，不用背着x86或Arm那种“全家桶指令”的包袱，节省面积和功耗；而在做一些轻量控制器时甚至可以只用RV32IMC，把核做到极小的规模。
这套模块化思路放到AI场景里，解决的是“控制”和“算力”的匹配问题。AI芯片内部的CPU核通常不需要跑特别复杂的业务逻辑，但它必须能快速响应中断、调度DMA、配置加速器的寄存器，偶尔还要跑一些标量密集的小段代码。RISC-V的核可以裁剪到什么程度，完全由设计者说了算，这在商业IP核授权模式下很难做到——拿Arm Cortex-A系列来说，指令集和微架构绑定，改动空间有限，授权费用和周期也不是中小团队能轻松承受的。RISC-V的“开源指令集”属性不光是成本问题，它意味着工具链、模拟器、操作系统移植这些底层东西都是开放的，团队可以按需修改，甚至可以把自定义指令直接编进编译器的指令选择阶段。
以我接触过的项目为例，很多做端侧AI芯片的团队，SoC里那颗“主控CPU”已经从Arm Cortex-M或A系列换成了RISC-V核，比如平头哥的玄铁E902/C906/C908、SiFive的U74/E76、Andes的D45/AX45系列，配合独立的NPU或KPU加速器。主控核只跑RTOS或轻量Linux，做任务调度和数据搬运，这部分负载根本不需要过强的整数性能，反而是“能效比”和“可裁剪性”更重要——这正是RISC-V的舒适区。
1.2 AI计算负载的特殊性：计算密集与控制密集的分层
AI inference的负载呈现一个很明显的“二八分层”：大约80%到90%的耗时集中在卷积、矩阵乘、归一化、激活函数这些深度神经网络的主要算子里，这部分是典型的计算密集任务，适合用专用加速器或向量单元解决；剩下10%到20%的时间花在数据预处理、任务切分、内存搬运、后处理上，这部分是控制密集和标量密集任务，传统的通用CPU就能handle，但需要一个能“低开销高效率”完成这些杂活的核。
这个分层恰好解释了为什么AI芯片普遍采用“主控CPU+加速器”的异构架构，而不是只用一堆CPU硬算。一个卷积层如果用CPU循环去算，指令数会爆炸，时延和功耗都不可控；但完全交给NPU的话，NPU的调度、输入输出摆放、中间结果的生命周期管理又必须有一个“老板”在外部统筹。这个老板不能太弱，否则会成为瓶颈；也不能太强，否则面积和功耗代价太大。RISC-V就卡在这么个“既要又要”的中间位置——核可以做得足够小，也能通过添加D扩展（浮点单元FPU）来处理normalization、upsample这些带有浮点运算的辅助算子，从而分担加速器的压力。
1.3 开源指令集带来的“自由”到底值多少钱
很多人对开源指令集的认知停留在“省授权费”上，实际在AI芯片领域，更大的价值是三个字：可修改。做AI芯片经常遇到“通用ISA干不了某件事”的尴尬，比如某个算子需要特殊的地址生成模式，或者需要在一条指令里完成“读取+缩放+累加”的组合。如果用的是闭源ISA，你只能对着指令集手册叹气，然后靠外围硬件绕路；而RISC-V允许厂商在保留标准指令集的基础上，用自定义opcode空间实现自己的指令，甚至在不需要向量扩展时直接把这部分功能砍掉，腾出硅片面积给AI算力。
拿FPU来说，RISC-V的F/D扩展作为可选模块，设计者完全可以在纯整数核上不集成FPU来降低功耗，也可以在需要跑激活函数和归一化的核里加上单精度FPU，这种“按需取舍”的粒度是商业ISA很难给的。另一个容易被低估的点是调试和生态的可定制性：基于RISC-V，团队能拿到完整的开源工具链（GCC/LLVM、QEMU、OpenOCD、Zephyr/Linux），出了问题可以自己改工具链而不是等上游厂商排期，这在AI芯片频繁迭代的节奏里价值极大。
2. 姿势一：让RISC-V当“大管家”——CPU+NPU异构SoC的主流打法
先讲最常见、门槛最低、也是市面上商业IP方案最成熟的一条路：把RISC-V核作为主控CPU，外面挂一个或多个AI加速器（NPU、KPU、DSA），通过总线把它们串起来。这套方案的核心思想是“命令和计算分离”——RISC-V核负责指挥，NPU负责干重活。
2.1 架构分工：谁负责“想”，谁负责“算”
在这类SoC里，一颗带浮点单元的RISC-V核（通常是RV64IMAFDC，也就是带M/A/F/D/C扩展的完整配置，甚至可能再带上V向量扩展）承担以下几类工作：初始化NPU的寄存器，把算子的输入数据从DDR搬到NPU的SRAM/TCM，下发任务描述符，等待NPU完成中断，然后在CPU上做NPU不方便处理的算子，比如动态shape的处理、注意力机制里的softmax、后处理的非极大值抑制NMS这些逻辑密集的操作。
NPU这边则是专用的MAC阵列加数据流控制，负责卷积、矩阵乘、逐元素操作这些高度规则的计算。NPU通常带有自己的SRAM和DMA，能独立完成一层网络的计算，但它的输入必须有人“喂”，输出必须有人“取”，这中间的控制流就是CPU的主场。
实际运行时一个典型的inference任务长这样：CPU先把预处理好的图像数据放到DDR的特定地址，然后配置NPU的base address、input shape、layer index等寄存器，写一个“start”位，NPU开始跑；跑完发中断，CPU在中断服务程序里读取NPU状态，决定下一步是继续下发下一层任务还是做后处理。整个流程里CPU不能太慢，否则NPU会空等，inference时延就上去了；但CPU也不需要跑重计算，它的负载主要是“搬数据”和“做决定”。
2.2 为什么选RISC-V当这个“大管家”而不是Arm或自研核
很多团队的答案说出来很直接：省成本、可裁剪、能折腾。商用Arm核在授权模式上对出货量的要求、对工艺节点的限制、对软件捆绑的依赖都比较多，对于AI SoC这种高度定制化的产品来说，“买来一个核再花六个月阉割它不想要的功能”是很亏的。而自研核周期太长、风险太大，除非团队本身就有CPU团队，否则不现实。
相比之下，RISC-V核在开源社区里已经有大量成熟实现，像平头哥的玄铁系列、SiFive的U系列、Andes的AX系列都有商业化的IP和完整的工具链支持。选RISC-V当主控，团队可以把省下来的精力放到NPU和编译器上，这也是大量端侧AI SoC厂商走这条路的直接原因。
2.3 实测中要注意的三个坑
这套方案听起来简单，但我在实际项目里踩过几个坑，值得单独拿出来说。
第一个坑是NPU和CPU之间的数据搬运开销。很多团队在设计时只顾着把NPU的算力堆高，忘了算搬运的时间。举个例子：一颗2 TOPS的NPU跑一个3x3卷积只需几十微秒，但如果你把输入数据放在DDR、NPU通过AXI总线去拉数据，光DDR带宽竞争就可能让时延翻倍。所以现在不少RISC-V AI芯片都会在NPU旁边加大的紧耦合SRAM/TCM，让CPU通过DMA把数据一块块搬进NPU的本地存储，搬完一批算一批，用“乒乓缓冲”的流水线方式掩盖搬运延迟。
第二个坑是RTOS和Linux的选择摇摆。端侧AI SoC经常面临两种负载：实时控制流（比如传感器数据采集）和通用应用（比如跑GUI）。如果只跑RTOS，NPU调度可以做得很可控，但上层AI框架适配吃力；如果跑Linux，功能强但中断延迟大，NPU空等概率高，功耗也更难看。我的经验是，如果产品以AI推理为主、配合少量控制逻辑，用一个支持硬实时扩展的RTOS是更稳的选择；如果需求是全功能Linux加AI，那CPU核至少选双核或四核，一颗核专门收中断处理DMA，另一颗跑上层业务，否则性能会很难看。
第三个坑是FPU的取舍。很多团队为了让RISC-V核“看起来更AI”，一上来就加双精度FPU，配置很高但用不上，徒增面积和功耗。实际测试下来，AI推理里CPU侧的浮点运算（归一化、激活函数、后处理）绝大多数是单精度或半精度就够用的，配一个单精度FPU或直接在核心外做浮点辅助单元，性价比更高。
3. 姿势二：让RISC-V的向量扩展亲自上场——RVV指令集路线
如果说姿势一是“让RISC-V干杂活、AI加速器干重活”，那姿势二就是“让RISC-V脱掉西装亲自去搬砖”——利用RISC-V官方的向量扩展指令集RVV，让CPU核心本身具备向量/张量级别的并行计算能力。这条路在端侧AI芯片和嵌入式AI场景里越来越常见，因为它能省掉一颗独立的NPU，把AI算力直接融合进CPU核，降低系统复杂度和数据搬运开销。
3.1 RVV是什么：从0.7.1到1.0的版本演进
RVV不是一拍脑门出来的新东西，它经过了很长时间的迭代。早期的RVV 0.7.1草案被很多国产RISC-V核采用过，比如玄铁C906、C908的早期版本，但0.7.1和最终定稿的RVV 1.0并不完全兼容，指令编码和语义都有调整，这对做软件生态的团队来说是一个不小的迁移成本。RVV 1.0在2021年正式冻结后，GCC从13版本开始提供相对完善的RVV 1.0支持，LLVM也逐步跟进。
RVV的核心设计是一组可变的向量寄存器，VLEN（向量寄存器长度）可以设计成128位、256位、512位，甚至更高；DLEN则是硬件真正执行时一次能处理的位宽，不一定等于VLEN。配合LMUL（向量寄存器组倍增因子）和vsetvli这条指令，软件可以写出“向量长度无关”的代码：同一个向量循环在不同VLEN的硬件上都能运行，硬件根据实际的VLEN自动切分循环。这种可移植性在AI场景里很有价值，因为同样的代码可以跑在128位VLEN的MCU级芯片上，也可以跑在512位VLEN的AI处理器上。
3.2 AI算子如何映射到RVV指令上
以一个典型的sgemm（单精度矩阵乘）为例，如果不用NPU，代码层实现就是把A矩阵的一行和一个B矩阵的列做向量内积，累加结果写入C矩阵。在RVV上，可以用vle32.v把一个矩阵的行加载到向量寄存器，再用vfmacc.vv执行“向量乘加”，一条指令完成乘法、加法、累加三件事；需要跨行累加的时候用vfredusum.vs做归约。卷积运算则可以先用im2col把输入展开成矩阵形式，再复用矩阵乘的RVV代码，或者用winograd变换降低乘法次数。
这套方案的性能上限取决于VLEN和MAC阵列的规模。一个VLEN为128位的RVV单元，单精度下一条vfmacc能同时处理4个浮点乘加，如果主频1GHz，理论算力大约8 GOPS；VLEN推到512位，就是32 GOPS。这个数字不如专门的NPU（动辄几TOPS），但对于很多IoT、可穿戴、端侧视觉场景已经够用，而且它有一个NPU无法比拟的好处：什么算子都能跑。
3.3 选RVV路线的收益和风险
收益方面，第一是省掉独立的NPU和配套驱动，系统复杂度大幅下降；第二是同一个核既能跑控制逻辑又能跑AI计算，灵活度极高；第三是生态统一，AI开发者写的算子库（比如基于RVV的SIMD库、推理框架的RVV后端）是标准的，不依赖某个NPU厂商的私有工具链。
风险方面，最大的问题是峰值算力有限，遇到大模型、大分辨率输入很容易力不从心。其次是RVV本身的“向量长度无关”设计虽然移植性好，但在性能优化上比NPU难得多，软件要自己处理数据对齐、LMUL选择、register blocking，优化不到位时实际算力可能只有峰值的二三成。还有一个很现实的坑是开发板的工具链成熟度，早期的RVV板子配套GCC支持不完善，编译出来的向量代码效率低下；踩过几次坑之后，我现在的习惯是先看工具链版本是不是GCC 13以上，再决定要不要选RVV平台。
3.4 实测体验：RV V在端侧AI推理里的实际表现
我拿过一款集成RVV 1.0的RISC-V开发板（VLEN 128、主频800MHz）跑过一个轻量级的人脸检测模型，单帧约几个MFLOPs，纯RVV优化后能做到几十毫秒级别，配合单精度FPU做后处理，整帧延迟在可接受范围内。对比同级别带NPU的芯片，NPU方案在纯卷积部分更快，但RVV方案在“灵活性”上完胜：换模型、调算子、跑自定义层都不用重新编译NPU固件。
如果你手头暂时没有RVV开发板，用QEMU先把RVV指令顺手练起来是个好办法。QEMU内置了对RVV的支持，通过-cpu rv64,v=true,vlen=128之类的参数可以模拟向量扩展，配合GCC 13交叉编译，边调边看反汇编，理解指令行为和性能特征上手很快。
4. 姿势三：给RISC-V“开小灶”——自定义指令与领域专用扩展
第三种姿势是把RISC-V当一个“毛坯房”，然后自己动手往里面加专用“家具”——通过RISC-V预留的自定义指令空间，把AI算子直接变成一条指令，让CPU核心在执行这些指令时走专用的加速流水线。这也是RISC-V和商业ISA差异最大的地方，也是最能体现“开源指令集”优势的一条路线。
4.1 自定义指令到底怎么玩
RISC-V指令集编码里预留了若干custom opcode空间，这些指令的编码格式和标准指令一样，但具体含义完全由实现者定义。设计AI芯片时，团队可以先做profiling，找出神经网络里耗时最高的算子，比如卷积、量化、激活函数融合、张量搬运等，然后把它们的核心计算过程固化成一条或几条自定义指令。
举个例子，如果某个模型的卷积层频繁执行“乘加+ReLU+量化”的组合，在标准RISC-V指令集下需要十几条指令完成，还要频繁访存；通过自定义扩展，可以设计一条类似vqconv或mc_conv的指令，输入是几个向量寄存器的地址和一个量化参数寄存器，硬件在专用流水线上直接完成整组操作，把结果写回向量寄存器。一条指令顶一个算子，既减少了指令带宽压力，又降低了CPU的循环开销。
自定义指令不一定要用于重计算，也可以用在“特殊地址生成”“数据重排”“压缩存储访问”这些辅助环节，这些环节看起来不起眼，但在AI计算里非常耗时。我做过的项目里，一条自定义的“带步长的向量加载”指令就把数据重排的开销降到了原来的一半。
4.2 实现路径：协处理器接口、扩展指令集、P扩展与E扩展
RISC-V自定义指令有几种落地方式。第一是在核内部实现自定义执行单元，指令译码后在普通流水线里执行，适合不太复杂、不要求超高吞吐的指令；第二是通过协处理器接口（比如RISC-V的Rococo协处理器接口、TileLink或AXI接口）外接一个专用的加速协处理器，CPU发现自定义指令后把操作数通过接口送给协处理器，协处理器计算完再写回，这种方式适合复杂算子，但延迟大一些；第三种是厂商在自己IP里提供预定义的扩展，比如T-Head的E扩展（CKExt）和玄铁系列自带的一些指令，这些指令可以直接调用，不需要自己从头设计。
标准RISC-V生态里还有一个P扩展（Packe SIMD），它是为了DSP/SIMD应用设计的固定向量长度扩展，比RVV轻量得多，适合那些不需要完整RVV、但想用SIMD指令加速camera、音频、传感器数据的场景。P扩展一度在草案阶段徘徊了很久，2023年后有了较完整的1.0草案，GCC/LLVM也在逐步支持。对AI芯片来说，P扩展往往和自定义指令配合使用：P扩展处理短小精悍的SIMD任务，自定义指令处理热点大算子。
4.3 软件适配：自定义指令最大的坎
自定义指令的硬件设计其实不是最难的，真正的深坑在软件栈。CPU要跑自定义指令，编译器得知道这条指令的存在和调度规则，否则编译器生成的汇编根本不会用到它；推理框架和算子库也得封装一个“intrinsic”接口，方便上层调用。这里有两个选择：一是走GCC/LLVM的原生支持，把自定义指令作为target-specific builtin函数加入编译器后端，工程量大但长期收益好；二是走内联汇编，在执行热点代码里直接嵌asm volatile，开发速度快但难以跨平台和跨编译器优化。
我个人的建议是，如果自定义指令少于十个且都是固定低频场景，可以直接上内联汇编；如果自定义指令成为芯片的核心卖点，必须在编译器后端做原生支持，否则客户用起来会非常痛苦。很多自研AI芯片最后死在“硬件做得不错但软件没人愿意用”，根子就在工具链没有提前布局。
4.4 代表思路与风险提醒
用自定义指令做极致AI加速的代表性思路，包括把RISC-V核和多颗张量核/Tensor核组合起来，RISC-V跑控制流，张量核跑矩阵乘；也有团队直接在RISC-V核的向量寄存器上叠加自定义的浮点格式（比如BF16、FP8处理）和专用运算单元，让同一条向量指令能做更多“AI数学”。
风险方面要认清一个现实：自定义指令越多，芯片的“通用性”越差，软件成本越高。如果团队想在AI芯片之外兼顾一些通用计算场景，过度自定义会把自己锁死。我踩过的坑是，设计阶段为了追求某个算子的极致性能加了一堆特殊浮点指令，结果后期想跑新模型时发现这些指令派不上用场，还白白占了大量译码和调度资源。自定义指令的正确姿势是“小而准”，只加那些在目标负载里命中率高、收益明显的指令，而不是面面俱到。
5. 三种姿势怎么选：一组对比和决策建议
三条路都过了一遍，实际选型时最重要的是搞清楚自己的产品定位和资源禀赋，下面这张表是我在这几年项目经验基础上整理出的横向对比，可以直接当成过滤器用。
| 维度 | 姿势一：CPU+NPU异构 | 姿势二：RVV向量扩展 | 姿势三：自定义指令/DSA |
|---|---|---|---|
| 算力实现主体 | 独立NPU/KPU/DSA加速器 | CPU内的向量ALU阵列 | 自定义执行单元/协处理器 |
| 峰值算力上限 | 高，可堆到数TOPS以上 | 中，受VLEN和主频限制 | 中高，取决于专用流水线宽度 |
| 灵活性 | 中等，NPU适合规整算子，动态算子靠CPU | 高，所有算子都能用向量指令写 | 低，自定义指令只适合固定热点算子 |
| 软件复杂度 | 中高，NPU驱动和算子映射劳动量大 | 中，工具链相对标准，但性能优化难 | 很高，编译器/算子库需深度定制 |
| 生态成熟度 | 高，商业IP成熟，主流SoC标配 | 中高，GCC13/LLVM支持完善，但板子差异大 | 低，各家各法，生态碎片化严重 |
| 典型代表 | 平头哥C908+NPU、SiFive X280+加速器 | C908 RVV、K230的向量核、Ventana | Tenstorrent、Esperanto、各类自研协处理器 |
我的建议可以浓缩成三句话。
如果团队做的是端侧AI SoC、要面向量产市场，优先考虑姿势一：在成熟RISC-V核的基础上外挂NPU/DSA，控制风险低、工具链稳定、客户好接受。
如果团队做的是嵌入式AI、MCU级别或者对芯片面积和功耗极度敏感的产品，姿势二性价比更高，一个带RVV的小核既能处理控制又能跑轻量AI，省掉一颗NPU意味着省掉整套NPU软件栈。
如果团队本身就是做AI处理器的，且有足够软件人力，姿势三值得长期投入，但建议和姿势二结合——标准RVV保持通用性，自定义指令在热区加分，而不是只靠自定义指令打天下。
5.1 现实中的方案往往是“混搭”
还要澄清一个误解：这三种姿势不是互斥的。我见过不少量产芯片实际上是“三合一”：主控RISC-V核带RVV扩展，同时外挂NPU，又在核里加了少量自定义指令专门做数据搬移和量化。比如嘉楠的K230，既有RVV 1.0的向量核，又有独立的KPU加速器；SiFive的X280既可以作为向量计算核单独使用，也能和外部加速器协作。一个AI SoC里“通用核+向量能力+专用加速器”的组合，本身就是对负载分层的最优响应。
5.2 如果从零开始，我建议这样练手
如果你现在刚接触RISC-V AI芯片，想快速体验这三条路的差异，我给一个低成本的练习路径：先用QEMU模拟器加GCC交叉编译，把RVV的sgemm跑通，理解向量代码怎么写、怎么调优；然后找一块带NPU的RISC-V开发板（比如K230、D1s这类），跑一个完整的端侧推理例子，感受一下CPU和NPU之间数据搬运的流程；最后如果真的想碰自定义指令，可以用Verilog写一个最小的RISC-V核（比如VexRiscv），在里面加一条自定义的乘加指令，用内联汇编驱动它。这三步走完，你对RISC-V怎么切进AI芯片会有一个从指令集到SoC的完整理解，比看十篇科普都管用。
做AI芯片选型也好，自己设计芯片也好，我个人的体会是：架构的价值不在于用了多新的技术名词，而在于每一个“为什么这样选”都能落到成本和收益上。RISC-V切入AI芯片的这三种姿势，说到底就是一组关于“通用性vs专用性”“成本vs性能”“软件投入vs硬件收益”的权衡。理解了这个权衡逻辑，无论RISC-V后续版本怎么演进，AI模型怎么迭代，你在做决策时都不会慌。
