先别急着谈算力RISC-V入局AI芯片的逻辑和很多人想的不一样过去两年我做了不少端侧AI和边缘计算的方案选型一个很明显的趋势是越来越多团队在评估AI芯片时第一句话不再是用哪颗GPU而是要不要看看RISC-V。这个转变有点微妙。早期RISC-V给人的印象是IoT小核、够用但跑不了重负载但它偏偏就在AI芯片这个赛道里撕开了口子。原因倒不复杂——AI芯片的需求早就分层了训练侧确实还是大算力、大生态的天下但推理侧、端侧、可穿戴、工业现场、机器人这些场景拼的是能效比、定制化程度和成本控制这几项恰好是开源指令集擅长的。这篇文章我想聊的核心话题是RISC-V切入AI芯片的三种实际技术路径。你可以把它们理解成三种姿势第一种是让通用核心自己扩展向量能力也就是RVV路线第二种是RISC-V主核搭配AI协处理器一个管控制一个管算力第三种是把AI的关键操作直接做成专用指令走深度定制路线。三种姿势对应完全不同的芯片架构、软件栈和团队配置。无论你是做SoC规划的技术负责人还是想了解AI芯片底层设计的工程师这篇文章都会给你一个相对完整的判断框架。文本内容主要来自我这些年在端侧AI芯片评估、开源指令集软件栈适配过程中的实践总结不涉及具体未公开产品数据但原理和踩坑经验都真实可复用。1. 先弄清楚一件事AI芯片到底缺什么RISC-V能补什么1.1 AI计算的需求已经分层不是所有场景都要训练卡很多人对AI芯片的理解还停留在GPU跑大模型这个单一画面上但实际上AI计算的负载已经分化得非常细。训练侧是一类需要的是超大的矩阵运算能力、高带宽存储、复杂的并行调度这个领域确实被少数厂商牢牢把持。但推理侧完全是另一回事一个端侧语音唤醒模型整个神经网络可能只有几MB要求是毫秒级响应、微瓦级功耗、实时性必须稳定一个工业质检的视觉模型需要的是在大批量产线上稳定跑7×24小时对时延抖动、温度变化、生命周期都有要求一个机器人的视觉SLAM加避障模型需要同时处理多路传感器数据但功耗预算可能只有几瓦。这个分层带来的直接影响是AI芯片的定义被拓宽了。当一个场景的核心诉求是用最少的电做完一次推理或者在极低成本设备上嵌入AI能力时传统GPU的通用性反而成了负担——片上存储太大、总线位宽太宽、调度开销太多每一项都在浪费功耗和面积。RISC-V在这时候的价值就体现出来了它的指令集是开放的可以针对特定算力需求做裁剪和扩展。你不用为了一个几十毫瓦的语音唤醒场景拉来一颗完整的GPU方案也不用为了一个特定的卷积结构去等厂商的软件栈支持。这种算力需求定制化的演进是RISC-V能切入AI芯片市场的底层驱动力。1.2 RISC-V的开源可控让改指令集这件事第一次变得平民化在RISC-V出现之前想动指令集的基本只有少数几家拥有CPU架构授权的公司。x86和Arm的指令集虽然功能完备但都属于闭源授权模式你可以在上面设计SoC但你没有权利去修改指令集本身。这就带来一个很实际的困难当你的AI算法非常特殊希望硬件在指令层面直接加速某种数据流时你只能等主核厂商的下一代架构去支持或者在片外再挂一颗ASIC用总线通信来弥补效率和灵活性都受限。RISC-V从设计之初就允许做自定义扩展。这个允许是深入到架构层级的基础指令集I、整数乘法除法M、原子操作A、单精度浮点F、双精度浮点D、压缩指令C这些都是标准化的但RISC-V规范同时预留了大片的自定义操作码空间。任何团队都可以在自己的实现里加入自定义指令而不需要获得任何组织的审批。这直接改变了AI芯片的设计范式你可以把算法特征提前到指令集层面去考虑而不是等芯片流片回来之后再去适配算法。我见过不少团队早期用Arm核做AI方案的规划需要在等软件优化和上专用NPU之间纠结很久。换成RISC-V之后思路完全不同先看算法瓶颈在哪再决定是扩展向量单元、加协处理器接口还是干脆定制指令自由度大很多。这也是为什么近几年新成立AI芯片公司里RISC-V的出现频率显著高于以前。1.3 三种姿势全景图从通用性优先到算力效率优先在展开具体技术细节之前先给你一张总览图方便后续理解。切入姿势核心思路典型算力表现软件栈复杂度适用场景姿势一RVV向量扩展扩展通用处理器的向量运算能力用标准RVV指令跑AI算子中等适合轻量级推理较低依托标准工具链语音唤醒、简单分类、边缘信号处理姿势二RISC-V主核AI协处理器主核负责调度协处理器负责大算力卷积/矩阵运算较高能效出色中等需自定义驱动和算子库视觉检测、机器人、汽车ADAS姿势三AI专用指令深度定制将AI关键模式卷积、矩阵乘、激活做成专用指令极致压缩指令开销最高但灵活度降低高需自研编译器支持追求极致能效的专用芯片需要说明的是这三种姿势并不是互斥的。实际商业芯片里经常能看到它们的组合一颗RISC-V主核本身带RVV能力又接了一颗专门的AI协处理器或者一颗AI协处理器内部又用了深度定制的专用指令来进一步加速特定算子。分三类讲是为了让你把架构决策的逻辑拆清楚方便做选型。2. 姿势一向量扩展RVV让通用核自己扛起AI负载2.1 RVV的底子数据级并行和大位宽ALURISC-V向量扩展RVV的设计目标很简单用一条指令同时处理一组数据也就是SIMD单指令多数据思路。但和Arm NEON、x86 SSE/AVX这些传统SIMD不一样RVV从1.0规范开始就把向量长度无关作为核心设计原则。什么意思你写的向量代码不绑定固定的向量位宽VLEN实际芯片上向量单元是128位还是512位由具体实现决定编译器根据CSR寄存器动态适配。这个设计对AI负载非常友好。AI运算中最常见的操作就是矩阵乘法和向量点积这些操作的共同特点是对一组数据做同样的运算数据之间没有依赖天然适合数据级并行。RVV把这种并行能力以标准指令的形式放进了通用处理器的执行流水线里所以一颗RISC-V核心只要配备了RVV单元就等于有了直接在通用核心上跑AI算子库的硬件基础。具体到指令层面RVV引入了一些值得关注的机制。比如vsetvli指令用来设置向量长度它决定了本次向量运算处理多少个元素LMUL向量寄存器组倍数用来把一个逻辑向量寄存器映射到多个物理寄存器上以便增加单条指令处理的数据量尾部处理tail and mask机制则解决了当数据长度不能被向量长度整除时多余位置的处理问题。这些机制单独看有些抽象但放到AI算子实现里都对应着具体的性能收益。我记得第一次用RVV实现一个INT8卷积层的时候最直接的感受是寄存器真的是大。一个256位向量寄存器能塞下32个INT8数据一次乘加指令完成32个乘法累加这在传统微控制器上几乎是不可想象的数据吞吐。对于1MB以内的轻量模型单核带向量扩展完全可以支撑实时推理。2.2 用RVV跑AI从量化到算子的中间过程理论上讲RVV可以让通用核心跑AI但真正落地远不止写上几条向量指令那么简单。整个流程要经历算法选型、量化、算子映射、数据排布优化、性能调优几个阶段路径。第一步是量化。RVV的位宽是固定的浮点和整数各有不同的向量指令但对端侧AI来说纯FP32推理往往不是功耗最优解。常见做法是把权重量化到INT8甚至INT4。量化方式不同指令选择完全不同如果做INT8矩阵乘核心循环是vfmacc浮点乘加还是vmadd整数乘加取决于你走的是模拟量化还是整型量化。实测下来在RVV上做W8A8整型量化权重8位、激活8位能效大约是FP32推理的三倍以上代价是需要额外处理量化/反量化操作和时间常数的合并这会带来额外的向量指令开销。第二步是把算子映射到向量指令。以卷积为例常见的实现策略是把卷积转换成矩阵乘im2col然后用向量指令按行做点积累加。这个过程有两个关键点一个是数据排布也就是内存里的通道方向、空间方向如何与向量寄存器的lane对应。排布不对哪怕指令用得再漂亮访存带宽也会卡住整体性能。另一个是边界处理卷积补零、padding、非对齐访问都会引入尾元素处理RVV的mask机制在这里非常有用不用像手工SIMD那样拼命写循环剩余部分。第三步是算子融合。这是RISC-V做端侧AI真正拉开差距的地方。比如卷积后面跟ReLU再加池化如果三个算子都到内存里转一圈访存开销就非常可观。实践中可以把三者融合成一个合并的向量循环乘加完之后直接用向量比较指令做ReLU再直接做池化的取最大值。RVV在这类算子级融合上非常灵活因为所有指令都在通用寄存器和通用数据路径上完成不需要跨核心通信调度开销低。2.3 向量方案的成绩单和天花板别指望它单挑重型算力先说成绩。在几百MHz的中端RISC-V核心上配合RVV 256位向量单元INT8推理跑一个MobileNet类模型大概能做到几十到一百FPS左右的水平具体取决于内存带宽和缓存结构。对于语音唤醒、关键词识别、基础手势识别这类轻场景性能完全够用。功耗上因为不需要额外的NPU硬件整体SoC面积和静态功耗都可以控制在极低水平。但天花板也很明显。RVV本质上是在通用数据路径上做数据级并行它没有为AI负载专门设计高密度MAC阵列也没有为卷积特有的数据重用提供专门的硬件支持。当模型变大、算力需求变高时RVV会先触及两个瓶颈第一个是算力密度。通用核心的ALU面积占比、寄存器堆访问端口、指令发射宽度都受限于通用处理器的设计约束不可能像专用MAC阵列那样把大量乘法器紧密排列。第二个是数据搬运。RVV核心依赖缓存和总线获取数据卷积过程中大量数据复用需要反复经过取指、访存、写回的过程。专用AI加速器常用片上SRAM和直接数据流架构来降低搬运开销这部分是RVV难以模拟的。所以我的判断是姿势一适合起步、适合轻量场景但不适合把AI能力作为芯片核心卖点的产品。如果你的产品定义里AI推理已经占据了芯片功耗和面积的较大份额那就得考虑下一种姿势。3. 姿势二RISC-V主核 AI协处理器各干各的最稳3.1 为什么异构成为主流选择控制与算力本质上是两种需求把AI算力从主核里拆出来用一颗专门的协处理器或NPU去承担这是目前RISC-V AI芯片里最常见的架构选择。你可以在很多定位在视觉、机器人和边缘AI的SoC上看到这种组合一颗或者多颗RISC-V CPU负责操作系统、调度、通信、预处理旁边挂一个AI协处理器专门跑卷积、Transformer等重算子。这种分工的背后是两类需求的根本性差异。控制逻辑需要的是低延迟、强中断处理能力、复杂分支预测和生态兼容性这些是通用CPU的强项。而AI负载需要的是大规模并行乘法累加、数据流级别的重用优化和极致的能效控制这些恰好是通用CPU不擅长的。把两者绑在同一套通用执行单元里要么牺牲通用性要么牺牲算力效率。分开做成异构架构两边都能用最合适的设计范式。我接触过的一个典型应用场景是工业缺陷检测系统需要同时处理相机采集、通讯协议、用户界面逻辑又要实时跑视觉检测模型。这种场景如果全交给一颗带向量扩展的通用核来做CPU负载一高实时性立刻不稳定。而有了AI协处理器主核只负责把图像数据交给协处理器协处理器算完把结果丢回中断主核继续忙自己的控制工作整体体验完全不同。不是性能指标的差别是系统稳定性的维度差别。3.2 指令集层面的轻定制从CSR到矩阵扩展提到协处理器很多人会误解成CPU之外挂个独立芯片用总线连起来。实际上在现代SoC设计里RISC-V主核与AI协处理器的耦合方式有非常多的层次从松到紧大致是独立内存映射的加速器、紧耦合的扩展单元、以及指令集层面的矩阵扩展。最松的方式是走内存映射。主核把输入数据的地址写到协处理器的某个寄存器协处理器通过DMA把数据搬到自己的SRAM里运算算完再通过DMA写回最后拉一个中断信号通知主核。早期很多NPU都是这种方式优点是主核和协处理器完全解耦软件上只需要驱动适配缺点是通信开销大每次任务卸载都有不小的DMA配置和数据搬运延迟。紧耦合的方式是挂载到CPU的总线上作为执行单元的直接扩展。主核执行一条特殊指令时直接把数据从通用寄存器送往协处理器的计算单元结果也可以直接写回通用寄存器。这种方式被很多RISC-V芯片用来做轻量级的AI加速例如在CPU核内集成一个专门的矩阵乘法单元通过一条自定义指令触发一个周期内完成小规模的矩阵乘累加。好处是延迟极低、不需要DMA适合模型层里穿插着大量小规模矩阵运算的场景比如Transformer的自注意力部分。矩阵扩展在RISC-V生态里也越来越受重视。RISC-V International已经把矩阵扩展纳入长期规划用意就是给高性能计算和AI负载提供标准化的矩阵运算指令。和自定义指令不同标准化矩阵扩展能让工具链、编译器、算子库都提前支持避免每次都要自研全套软件栈。不过目前落地还处在早期阶段选择这条路需要自己对软件生态有较强的掌控力。3.3 从产品角度评估这条路性能收益、面积代价和调试复杂度从产品规划角度主核协处理器的路线有三个必须想清楚的问题。第一协处理器的算力目标要与模型强绑定。协处理器的峰值算力听着很动人但实际有效算力取决于片上存储、数据通路和算子的匹配度。一个常见的失误是协处理器算力标得很高自家模型却因为数据排布不匹配实际吞吐只有峰值的两三成。选型和架构设计阶段最好直接拿真实模型做算子级评估而不是只看TOPS数字。第二面积和功耗预算会明显上涨。协处理器不是凭空多出来的算力它需要专门的SRAM、MAC阵列、数据调度逻辑和总线接口这些都会增加SoC的面积和功耗。对于一颗面向低成本市场的AIoT芯片协处理器面积占比超过一定阈值后芯片成本就会失控。这时就要权衡到底是把AI做重一点还是把AI负载拆一部分回主核用RVV来跑。第三软件栈的复杂度上了一个台阶。主核只管下发任务但整个AI应用要正常工作还需要驱动层、运行时调度层、算子编译工具链的协同。如果是标准化的协处理器产品方可以直接拿到厂家提供的算子库如果是自研的协处理器那团队的编译器能力就得跟上来。4. 姿势三把AI关键操作用专用指令焊进芯片4.1 DSA思路当通用计算模板覆盖不了算法特征时就自己订一套RISC-V切入AI芯片的第三种姿势是走域专用架构DSA的路线。DSA的思路是针对某个领域的计算模式设计专门的硬件结构和指令集把算法特征直接映射进硬件执行模型里从而获得极高的能效比。AI负载其实是非常典型的域专用负载。卷积的滑动窗模式、矩阵乘的数据复用模式、激活函数的非线性模式、池化的降采样模式这些在一个很小的问题空间里反复出现。与其用通用SIMD指令一条条去模拟这些模式姿势一或者用独立协处理器内部做专用硬件姿势二第三种姿势选择了另一条路径把AI的这些关键模式直接定义为CPU的专用指令让处理器在执行流水线里就能完成高密度矩阵运算。这个选择的核心动机是减少指令开销和搬运开销。在深度定制指令的处理器里一条指令可能就包含了取出一个小矩阵、做一整个矩阵乘加、把结果写回寄存器组的过程。对可比的算力需求来说深度定制的指令密度比通用向量指令高得多能效自然也更好。这就是为什么很多追求极致能效比的AI芯片公司选择在RISC-V基础上深度定制专用指令而不是单纯叠加RVV或者外挂NPU。4.2 典型技术特征MAC阵列、脉动阵列、紧耦合存储深度定制AI指令集的核心通常会包含几个共同的技术特征。第一是高密度的MAC阵列。一个AI专用处理器内部会集成大量乘法累加单元这些MAC阵列以脉动阵列或者空间阵列的形态组织。脉动阵列的特点是数据像心跳一样在阵列里流动每个处理单元只做最基本的乘加操作数据把数据从输入端传到阵列权重则常驻在每个单元内部。用RISC-V的自定义指令来控制阵列的关键是把数据传输和计算调度尽量融合一条指令让阵列执行一整轮的矩阵运算而不是靠通用寄存器的反复读写去驱动。第二是紧耦合的大容量片上SRAM。AI专用处理器的性能瓶颈往往不是MAC阵列本身而是数据供给。为了让MAC阵列每个周期都满载运行需要把模型权重和中间激活数据尽量留在片上SRAM里。深度定制指令集在这里的用处是用专门的load/store指令把数据块搬到紧耦合内存里再触发计算指令避免指令流在搬运和计算之间频繁切换。第三是片内数据流加速。卷积计算的特点是数据复用高同一个输入像素会被多个输出通道使用同一个权重会被多个空间位置使用。深度定制指令集可以通过专门的数据路由方式让硬件在计算过程中自动完成这些复用调度而不是像通用向量机那样依赖于编译器生成特定的数据排布。4.3 定制处理器必须面对的代价工具链、生态和验证难度深度定制AI指令集的诱惑很大但代价也最沉重必须提前想清楚。最大的代价在工具链。标准RISC-V指令集之所以有繁荣的软件生态核心就是GCC、LLVM、GDB这些开源工具链把编译、汇编、调试打通了。一旦你加入自定义指令你就必须让编译器能理解这些指令的语义至少要支持在C/C代码里以内建函数intrinsic方式调用。这意味着你要么自己维护一个LLVM分支要么花大量精力对接汇编器让内嵌汇编可以编译。很多团队低估了这条路的工程量一个自定义向量指令集从LLVM后端开发到能跑出可用的算子代码通常是以人月甚至人年为单位计算的。第二个代价是编程模型和通用性的下降。深度定制的指令特别适合你算法栈中占主导的那几类算子但遇到业务变化、模型结构变化时新算子可能无法高效映射到这些专用指令上结果变成拿着专用指令去拼凑通用计算性能还不如标准RVV。这不是架构设计有错而是DSA路线的天然特性用灵活性换能效用适应面换峰值算力。所以这条路线只适合算法相对固定、模型演进可控的垂直场景。第三个代价是验证和调试难度的指数级上升。硬件验证阶段自定义指令需要精心构造针对性测试用例才能验证指令语义的正确性软件调试阶段指令级的调试工具、性能分析器和模拟器通常都需要自行开发或适配。这块的人力投入往往被项目初期忽视到了流片前才发现验证覆盖率不够这类教训在我接触过的项目里不算少见。5. 三种姿势怎么选算力段位、功耗预算和软件生态决定一切5.1 参数对照表看似都在做AI本质是三种完全不同的芯片做选型的时候我会建议团队把三种姿势放在几个核心维度上做一个系统评估而不是简单比较谁的TOPS高。评估维度姿势一RVV向量扩展姿势二主核协处理器姿势三AI专用指令定制峰值算力低到中中到高高到极高单位算力能效一般较好最好硬件面积增量小中到大中灵活性高中低软件栈投入低中高算法演进适应性强中弱典型量产周期短中长适合团队软件/IP团队SoC团队有编译器能力的垂直团队这张表有一个容易误读的地方姿势三的面积增量为什么不是最大因为它的设计目标是高能效高集成度可以把很多原本属于协处理器的硬件塞进CPU的数据路径里节省独立单元的布局但代价是设计复杂度极高验证时间拉长。所以选型不是比表格里谁最优而是看你的团队最缺乏哪项资源。5.2 选型决策流程先定场景再定架构最后定指令集策略我的建议是选型按照这个顺序走下来能过滤掉大部分不合适的方案。第一步明确算力需求的上限。把要部署的模型跑一遍统计MAC总量、峰值内存带宽需求、单次推理延时可接受范围。算力需求低于某个阈值比如几十GOPS直接选姿势一用RVV解决省去所有异构软件栈的麻烦。中等算力几十到数百GOPS且产品需要同时运行复杂控制逻辑姿势二是稳妥选择。算力要求极高且算法长期固定、功耗预算严苛再考虑姿势三。第二步评估软件生态的投入产出。如果团队里编译器、算子优化的人才储备不足姿势三要非常谨慎。反过来说如果团队本身就是做芯片工具链出身那深度定制路线反而是建立长期技术壁垒的机会。第三步考虑产品迭代的节奏。行业变化快、模型更新频繁的场景硬件架构的灵活性比峰值算力更重要。这个时候把AI能力全部焊死在专用指令里可能等产品上市时算法已经换了芯片却改不了。反而是主核协处理器或者RVV方案通过软件升级还能继续适配。我在不少项目里看到的一个通病是芯片规划过早进入我要做一个多强的AI算力的思维忽略了产品实际的模型演进空间。做选型不是选参数最强的而是要选软硬件生命周期匹配的。6. 落地阶段最容易踩的坑提前帮你排一排6.1 工具链自动向量化远没有你想的那么简单很多团队上RVV之后的第一件事是信心满满地写好C代码然后让编译器自动向量化跑AI算子结果性能惨不忍睹。这几乎是每个RISC-V向量开发者的共同经历。GCC/LLVM的自动向量化对一般循环有效但对卷积这种结构复杂、带有窗口滑动和padding的算子自动生成的代码往往有大量冗余load/store数据重用完全没体现出来。我现在的做法是核心算子绝不依赖自动向量化直接使用内建函数intrinsic手写关键循环。RVV的intrinsic虽然写起来繁琐但能精确控制每个数据的排布和每条指令的执行。作为参考一个手写RVV的INT8卷积算子相比编译器自动向量化版本性能差距通常在三倍以上。如果你的团队刚接触RVV这个心理预期要提前建立向量优化的核心工作是帮编译器理解数据流而不是写完C代码就完事。6.2 自定义指令与开源生态的割裂是最容易被低估的隐性成本做自定义指令设计的时候团队往往会花很多时间讨论指令的硬件实现、指令编码、性能收益很少有人认真对待这条指令如何暴露给软件的问题。结果到了软件适配阶段发现整条工具链都要动汇编器要支持新助记符、编译器后端要能生成新指令、反汇编器要能正确解析、调试器要能单步执行新指令、性能分析器要能识别新指令的耗时。任何一个环节缺失都会拖慢整个软件开发生命周期。更隐蔽的问题是生态兼容性。如果你用了自定义指令那么意味着所有第三方库、开源算子库、AI框架的算子实现都无法直接用到你的芯片上都要由自己的团队来实现和优化。这个工作量在芯片量产前不容易显现但一旦客户把自己的模型搬上来发现一半算子没有优化体验会非常糟糕。6.3 验证和原型阶段的效率问题决定你能不能按期流片AI芯片的验证复杂度远高于普通SoC。协处理器或自定义指令的计算正确性需要大量的数据级测试覆盖率。很多团队习惯用纯RTL仿真去跑AI算子结果一个中等规模的卷积算子仿真就要跑几个小时整个验证周期被拉得很长。更高效的做法是尽量早地把关键算子搬到FPGA原型环境里用真实的指令流跑起来。虽然FPGA频率只能做到几十MHz但验证的并行度可以大幅提升尤其适合做指令语义验证和软件栈早期开发。我自己习惯在芯片设计阶段同步搭建一个基于QEMU或开源模拟器的指令集模拟器环境。这样软件团队可以提前开发算子库和驱动等RTL冻结后软件已经跑通大半。很多RISC-V项目里软件团队和硬件团队互相等的问题根源往往不是管理问题而是没有提前搭建软硬件协同验证环境。6.4 给团队配置的一些参考建议最后聊一点团队组织的事。经常有人问我我们想用RISC-V做AI芯片团队需要什么样的人我的经验是无论选择哪一种姿势团队里至少要有一名真正理解工具链内部的软件工程师。硬件设计高手很多但能在最小指令集实现、编译器后端、算子优化三个层面之间来回切换的人非常稀缺。这个角色要能回答这个算子从C语言到最终机器指令每一步发生了什么哪一步开销最高如何在硬件上省掉。如果没有这个人我强烈建议先不做深度定制路线优先选择RVV加标准化协处理器的组合把自研范围控制在最需要差异化的算子层而不是一开始就钻进指令集设计的深水区。说到底RISC-V切入AI芯片这件事最大的价值不是某一个指令扩展的跑分有多好看而是它把硬件适配算法这件事的决策权交还给了芯片设计者。无论选哪种姿势你都是在用自己的判断去回答同一个问题我的产品需要多少灵活性又愿意为多少能效付出代价。这个问题没有标准答案但想清楚它比选哪条技术路线更重要。
RISC-V入局AI芯片的三种路径：RVV、协处理器与专用指令怎么选
先别急着谈算力RISC-V入局AI芯片的逻辑和很多人想的不一样过去两年我做了不少端侧AI和边缘计算的方案选型一个很明显的趋势是越来越多团队在评估AI芯片时第一句话不再是用哪颗GPU而是要不要看看RISC-V。这个转变有点微妙。早期RISC-V给人的印象是IoT小核、够用但跑不了重负载但它偏偏就在AI芯片这个赛道里撕开了口子。原因倒不复杂——AI芯片的需求早就分层了训练侧确实还是大算力、大生态的天下但推理侧、端侧、可穿戴、工业现场、机器人这些场景拼的是能效比、定制化程度和成本控制这几项恰好是开源指令集擅长的。这篇文章我想聊的核心话题是RISC-V切入AI芯片的三种实际技术路径。你可以把它们理解成三种姿势第一种是让通用核心自己扩展向量能力也就是RVV路线第二种是RISC-V主核搭配AI协处理器一个管控制一个管算力第三种是把AI的关键操作直接做成专用指令走深度定制路线。三种姿势对应完全不同的芯片架构、软件栈和团队配置。无论你是做SoC规划的技术负责人还是想了解AI芯片底层设计的工程师这篇文章都会给你一个相对完整的判断框架。文本内容主要来自我这些年在端侧AI芯片评估、开源指令集软件栈适配过程中的实践总结不涉及具体未公开产品数据但原理和踩坑经验都真实可复用。1. 先弄清楚一件事AI芯片到底缺什么RISC-V能补什么1.1 AI计算的需求已经分层不是所有场景都要训练卡很多人对AI芯片的理解还停留在GPU跑大模型这个单一画面上但实际上AI计算的负载已经分化得非常细。训练侧是一类需要的是超大的矩阵运算能力、高带宽存储、复杂的并行调度这个领域确实被少数厂商牢牢把持。但推理侧完全是另一回事一个端侧语音唤醒模型整个神经网络可能只有几MB要求是毫秒级响应、微瓦级功耗、实时性必须稳定一个工业质检的视觉模型需要的是在大批量产线上稳定跑7×24小时对时延抖动、温度变化、生命周期都有要求一个机器人的视觉SLAM加避障模型需要同时处理多路传感器数据但功耗预算可能只有几瓦。这个分层带来的直接影响是AI芯片的定义被拓宽了。当一个场景的核心诉求是用最少的电做完一次推理或者在极低成本设备上嵌入AI能力时传统GPU的通用性反而成了负担——片上存储太大、总线位宽太宽、调度开销太多每一项都在浪费功耗和面积。RISC-V在这时候的价值就体现出来了它的指令集是开放的可以针对特定算力需求做裁剪和扩展。你不用为了一个几十毫瓦的语音唤醒场景拉来一颗完整的GPU方案也不用为了一个特定的卷积结构去等厂商的软件栈支持。这种算力需求定制化的演进是RISC-V能切入AI芯片市场的底层驱动力。1.2 RISC-V的开源可控让改指令集这件事第一次变得平民化在RISC-V出现之前想动指令集的基本只有少数几家拥有CPU架构授权的公司。x86和Arm的指令集虽然功能完备但都属于闭源授权模式你可以在上面设计SoC但你没有权利去修改指令集本身。这就带来一个很实际的困难当你的AI算法非常特殊希望硬件在指令层面直接加速某种数据流时你只能等主核厂商的下一代架构去支持或者在片外再挂一颗ASIC用总线通信来弥补效率和灵活性都受限。RISC-V从设计之初就允许做自定义扩展。这个允许是深入到架构层级的基础指令集I、整数乘法除法M、原子操作A、单精度浮点F、双精度浮点D、压缩指令C这些都是标准化的但RISC-V规范同时预留了大片的自定义操作码空间。任何团队都可以在自己的实现里加入自定义指令而不需要获得任何组织的审批。这直接改变了AI芯片的设计范式你可以把算法特征提前到指令集层面去考虑而不是等芯片流片回来之后再去适配算法。我见过不少团队早期用Arm核做AI方案的规划需要在等软件优化和上专用NPU之间纠结很久。换成RISC-V之后思路完全不同先看算法瓶颈在哪再决定是扩展向量单元、加协处理器接口还是干脆定制指令自由度大很多。这也是为什么近几年新成立AI芯片公司里RISC-V的出现频率显著高于以前。1.3 三种姿势全景图从通用性优先到算力效率优先在展开具体技术细节之前先给你一张总览图方便后续理解。切入姿势核心思路典型算力表现软件栈复杂度适用场景姿势一RVV向量扩展扩展通用处理器的向量运算能力用标准RVV指令跑AI算子中等适合轻量级推理较低依托标准工具链语音唤醒、简单分类、边缘信号处理姿势二RISC-V主核AI协处理器主核负责调度协处理器负责大算力卷积/矩阵运算较高能效出色中等需自定义驱动和算子库视觉检测、机器人、汽车ADAS姿势三AI专用指令深度定制将AI关键模式卷积、矩阵乘、激活做成专用指令极致压缩指令开销最高但灵活度降低高需自研编译器支持追求极致能效的专用芯片需要说明的是这三种姿势并不是互斥的。实际商业芯片里经常能看到它们的组合一颗RISC-V主核本身带RVV能力又接了一颗专门的AI协处理器或者一颗AI协处理器内部又用了深度定制的专用指令来进一步加速特定算子。分三类讲是为了让你把架构决策的逻辑拆清楚方便做选型。2. 姿势一向量扩展RVV让通用核自己扛起AI负载2.1 RVV的底子数据级并行和大位宽ALURISC-V向量扩展RVV的设计目标很简单用一条指令同时处理一组数据也就是SIMD单指令多数据思路。但和Arm NEON、x86 SSE/AVX这些传统SIMD不一样RVV从1.0规范开始就把向量长度无关作为核心设计原则。什么意思你写的向量代码不绑定固定的向量位宽VLEN实际芯片上向量单元是128位还是512位由具体实现决定编译器根据CSR寄存器动态适配。这个设计对AI负载非常友好。AI运算中最常见的操作就是矩阵乘法和向量点积这些操作的共同特点是对一组数据做同样的运算数据之间没有依赖天然适合数据级并行。RVV把这种并行能力以标准指令的形式放进了通用处理器的执行流水线里所以一颗RISC-V核心只要配备了RVV单元就等于有了直接在通用核心上跑AI算子库的硬件基础。具体到指令层面RVV引入了一些值得关注的机制。比如vsetvli指令用来设置向量长度它决定了本次向量运算处理多少个元素LMUL向量寄存器组倍数用来把一个逻辑向量寄存器映射到多个物理寄存器上以便增加单条指令处理的数据量尾部处理tail and mask机制则解决了当数据长度不能被向量长度整除时多余位置的处理问题。这些机制单独看有些抽象但放到AI算子实现里都对应着具体的性能收益。我记得第一次用RVV实现一个INT8卷积层的时候最直接的感受是寄存器真的是大。一个256位向量寄存器能塞下32个INT8数据一次乘加指令完成32个乘法累加这在传统微控制器上几乎是不可想象的数据吞吐。对于1MB以内的轻量模型单核带向量扩展完全可以支撑实时推理。2.2 用RVV跑AI从量化到算子的中间过程理论上讲RVV可以让通用核心跑AI但真正落地远不止写上几条向量指令那么简单。整个流程要经历算法选型、量化、算子映射、数据排布优化、性能调优几个阶段路径。第一步是量化。RVV的位宽是固定的浮点和整数各有不同的向量指令但对端侧AI来说纯FP32推理往往不是功耗最优解。常见做法是把权重量化到INT8甚至INT4。量化方式不同指令选择完全不同如果做INT8矩阵乘核心循环是vfmacc浮点乘加还是vmadd整数乘加取决于你走的是模拟量化还是整型量化。实测下来在RVV上做W8A8整型量化权重8位、激活8位能效大约是FP32推理的三倍以上代价是需要额外处理量化/反量化操作和时间常数的合并这会带来额外的向量指令开销。第二步是把算子映射到向量指令。以卷积为例常见的实现策略是把卷积转换成矩阵乘im2col然后用向量指令按行做点积累加。这个过程有两个关键点一个是数据排布也就是内存里的通道方向、空间方向如何与向量寄存器的lane对应。排布不对哪怕指令用得再漂亮访存带宽也会卡住整体性能。另一个是边界处理卷积补零、padding、非对齐访问都会引入尾元素处理RVV的mask机制在这里非常有用不用像手工SIMD那样拼命写循环剩余部分。第三步是算子融合。这是RISC-V做端侧AI真正拉开差距的地方。比如卷积后面跟ReLU再加池化如果三个算子都到内存里转一圈访存开销就非常可观。实践中可以把三者融合成一个合并的向量循环乘加完之后直接用向量比较指令做ReLU再直接做池化的取最大值。RVV在这类算子级融合上非常灵活因为所有指令都在通用寄存器和通用数据路径上完成不需要跨核心通信调度开销低。2.3 向量方案的成绩单和天花板别指望它单挑重型算力先说成绩。在几百MHz的中端RISC-V核心上配合RVV 256位向量单元INT8推理跑一个MobileNet类模型大概能做到几十到一百FPS左右的水平具体取决于内存带宽和缓存结构。对于语音唤醒、关键词识别、基础手势识别这类轻场景性能完全够用。功耗上因为不需要额外的NPU硬件整体SoC面积和静态功耗都可以控制在极低水平。但天花板也很明显。RVV本质上是在通用数据路径上做数据级并行它没有为AI负载专门设计高密度MAC阵列也没有为卷积特有的数据重用提供专门的硬件支持。当模型变大、算力需求变高时RVV会先触及两个瓶颈第一个是算力密度。通用核心的ALU面积占比、寄存器堆访问端口、指令发射宽度都受限于通用处理器的设计约束不可能像专用MAC阵列那样把大量乘法器紧密排列。第二个是数据搬运。RVV核心依赖缓存和总线获取数据卷积过程中大量数据复用需要反复经过取指、访存、写回的过程。专用AI加速器常用片上SRAM和直接数据流架构来降低搬运开销这部分是RVV难以模拟的。所以我的判断是姿势一适合起步、适合轻量场景但不适合把AI能力作为芯片核心卖点的产品。如果你的产品定义里AI推理已经占据了芯片功耗和面积的较大份额那就得考虑下一种姿势。3. 姿势二RISC-V主核 AI协处理器各干各的最稳3.1 为什么异构成为主流选择控制与算力本质上是两种需求把AI算力从主核里拆出来用一颗专门的协处理器或NPU去承担这是目前RISC-V AI芯片里最常见的架构选择。你可以在很多定位在视觉、机器人和边缘AI的SoC上看到这种组合一颗或者多颗RISC-V CPU负责操作系统、调度、通信、预处理旁边挂一个AI协处理器专门跑卷积、Transformer等重算子。这种分工的背后是两类需求的根本性差异。控制逻辑需要的是低延迟、强中断处理能力、复杂分支预测和生态兼容性这些是通用CPU的强项。而AI负载需要的是大规模并行乘法累加、数据流级别的重用优化和极致的能效控制这些恰好是通用CPU不擅长的。把两者绑在同一套通用执行单元里要么牺牲通用性要么牺牲算力效率。分开做成异构架构两边都能用最合适的设计范式。我接触过的一个典型应用场景是工业缺陷检测系统需要同时处理相机采集、通讯协议、用户界面逻辑又要实时跑视觉检测模型。这种场景如果全交给一颗带向量扩展的通用核来做CPU负载一高实时性立刻不稳定。而有了AI协处理器主核只负责把图像数据交给协处理器协处理器算完把结果丢回中断主核继续忙自己的控制工作整体体验完全不同。不是性能指标的差别是系统稳定性的维度差别。3.2 指令集层面的轻定制从CSR到矩阵扩展提到协处理器很多人会误解成CPU之外挂个独立芯片用总线连起来。实际上在现代SoC设计里RISC-V主核与AI协处理器的耦合方式有非常多的层次从松到紧大致是独立内存映射的加速器、紧耦合的扩展单元、以及指令集层面的矩阵扩展。最松的方式是走内存映射。主核把输入数据的地址写到协处理器的某个寄存器协处理器通过DMA把数据搬到自己的SRAM里运算算完再通过DMA写回最后拉一个中断信号通知主核。早期很多NPU都是这种方式优点是主核和协处理器完全解耦软件上只需要驱动适配缺点是通信开销大每次任务卸载都有不小的DMA配置和数据搬运延迟。紧耦合的方式是挂载到CPU的总线上作为执行单元的直接扩展。主核执行一条特殊指令时直接把数据从通用寄存器送往协处理器的计算单元结果也可以直接写回通用寄存器。这种方式被很多RISC-V芯片用来做轻量级的AI加速例如在CPU核内集成一个专门的矩阵乘法单元通过一条自定义指令触发一个周期内完成小规模的矩阵乘累加。好处是延迟极低、不需要DMA适合模型层里穿插着大量小规模矩阵运算的场景比如Transformer的自注意力部分。矩阵扩展在RISC-V生态里也越来越受重视。RISC-V International已经把矩阵扩展纳入长期规划用意就是给高性能计算和AI负载提供标准化的矩阵运算指令。和自定义指令不同标准化矩阵扩展能让工具链、编译器、算子库都提前支持避免每次都要自研全套软件栈。不过目前落地还处在早期阶段选择这条路需要自己对软件生态有较强的掌控力。3.3 从产品角度评估这条路性能收益、面积代价和调试复杂度从产品规划角度主核协处理器的路线有三个必须想清楚的问题。第一协处理器的算力目标要与模型强绑定。协处理器的峰值算力听着很动人但实际有效算力取决于片上存储、数据通路和算子的匹配度。一个常见的失误是协处理器算力标得很高自家模型却因为数据排布不匹配实际吞吐只有峰值的两三成。选型和架构设计阶段最好直接拿真实模型做算子级评估而不是只看TOPS数字。第二面积和功耗预算会明显上涨。协处理器不是凭空多出来的算力它需要专门的SRAM、MAC阵列、数据调度逻辑和总线接口这些都会增加SoC的面积和功耗。对于一颗面向低成本市场的AIoT芯片协处理器面积占比超过一定阈值后芯片成本就会失控。这时就要权衡到底是把AI做重一点还是把AI负载拆一部分回主核用RVV来跑。第三软件栈的复杂度上了一个台阶。主核只管下发任务但整个AI应用要正常工作还需要驱动层、运行时调度层、算子编译工具链的协同。如果是标准化的协处理器产品方可以直接拿到厂家提供的算子库如果是自研的协处理器那团队的编译器能力就得跟上来。4. 姿势三把AI关键操作用专用指令焊进芯片4.1 DSA思路当通用计算模板覆盖不了算法特征时就自己订一套RISC-V切入AI芯片的第三种姿势是走域专用架构DSA的路线。DSA的思路是针对某个领域的计算模式设计专门的硬件结构和指令集把算法特征直接映射进硬件执行模型里从而获得极高的能效比。AI负载其实是非常典型的域专用负载。卷积的滑动窗模式、矩阵乘的数据复用模式、激活函数的非线性模式、池化的降采样模式这些在一个很小的问题空间里反复出现。与其用通用SIMD指令一条条去模拟这些模式姿势一或者用独立协处理器内部做专用硬件姿势二第三种姿势选择了另一条路径把AI的这些关键模式直接定义为CPU的专用指令让处理器在执行流水线里就能完成高密度矩阵运算。这个选择的核心动机是减少指令开销和搬运开销。在深度定制指令的处理器里一条指令可能就包含了取出一个小矩阵、做一整个矩阵乘加、把结果写回寄存器组的过程。对可比的算力需求来说深度定制的指令密度比通用向量指令高得多能效自然也更好。这就是为什么很多追求极致能效比的AI芯片公司选择在RISC-V基础上深度定制专用指令而不是单纯叠加RVV或者外挂NPU。4.2 典型技术特征MAC阵列、脉动阵列、紧耦合存储深度定制AI指令集的核心通常会包含几个共同的技术特征。第一是高密度的MAC阵列。一个AI专用处理器内部会集成大量乘法累加单元这些MAC阵列以脉动阵列或者空间阵列的形态组织。脉动阵列的特点是数据像心跳一样在阵列里流动每个处理单元只做最基本的乘加操作数据把数据从输入端传到阵列权重则常驻在每个单元内部。用RISC-V的自定义指令来控制阵列的关键是把数据传输和计算调度尽量融合一条指令让阵列执行一整轮的矩阵运算而不是靠通用寄存器的反复读写去驱动。第二是紧耦合的大容量片上SRAM。AI专用处理器的性能瓶颈往往不是MAC阵列本身而是数据供给。为了让MAC阵列每个周期都满载运行需要把模型权重和中间激活数据尽量留在片上SRAM里。深度定制指令集在这里的用处是用专门的load/store指令把数据块搬到紧耦合内存里再触发计算指令避免指令流在搬运和计算之间频繁切换。第三是片内数据流加速。卷积计算的特点是数据复用高同一个输入像素会被多个输出通道使用同一个权重会被多个空间位置使用。深度定制指令集可以通过专门的数据路由方式让硬件在计算过程中自动完成这些复用调度而不是像通用向量机那样依赖于编译器生成特定的数据排布。4.3 定制处理器必须面对的代价工具链、生态和验证难度深度定制AI指令集的诱惑很大但代价也最沉重必须提前想清楚。最大的代价在工具链。标准RISC-V指令集之所以有繁荣的软件生态核心就是GCC、LLVM、GDB这些开源工具链把编译、汇编、调试打通了。一旦你加入自定义指令你就必须让编译器能理解这些指令的语义至少要支持在C/C代码里以内建函数intrinsic方式调用。这意味着你要么自己维护一个LLVM分支要么花大量精力对接汇编器让内嵌汇编可以编译。很多团队低估了这条路的工程量一个自定义向量指令集从LLVM后端开发到能跑出可用的算子代码通常是以人月甚至人年为单位计算的。第二个代价是编程模型和通用性的下降。深度定制的指令特别适合你算法栈中占主导的那几类算子但遇到业务变化、模型结构变化时新算子可能无法高效映射到这些专用指令上结果变成拿着专用指令去拼凑通用计算性能还不如标准RVV。这不是架构设计有错而是DSA路线的天然特性用灵活性换能效用适应面换峰值算力。所以这条路线只适合算法相对固定、模型演进可控的垂直场景。第三个代价是验证和调试难度的指数级上升。硬件验证阶段自定义指令需要精心构造针对性测试用例才能验证指令语义的正确性软件调试阶段指令级的调试工具、性能分析器和模拟器通常都需要自行开发或适配。这块的人力投入往往被项目初期忽视到了流片前才发现验证覆盖率不够这类教训在我接触过的项目里不算少见。5. 三种姿势怎么选算力段位、功耗预算和软件生态决定一切5.1 参数对照表看似都在做AI本质是三种完全不同的芯片做选型的时候我会建议团队把三种姿势放在几个核心维度上做一个系统评估而不是简单比较谁的TOPS高。评估维度姿势一RVV向量扩展姿势二主核协处理器姿势三AI专用指令定制峰值算力低到中中到高高到极高单位算力能效一般较好最好硬件面积增量小中到大中灵活性高中低软件栈投入低中高算法演进适应性强中弱典型量产周期短中长适合团队软件/IP团队SoC团队有编译器能力的垂直团队这张表有一个容易误读的地方姿势三的面积增量为什么不是最大因为它的设计目标是高能效高集成度可以把很多原本属于协处理器的硬件塞进CPU的数据路径里节省独立单元的布局但代价是设计复杂度极高验证时间拉长。所以选型不是比表格里谁最优而是看你的团队最缺乏哪项资源。5.2 选型决策流程先定场景再定架构最后定指令集策略我的建议是选型按照这个顺序走下来能过滤掉大部分不合适的方案。第一步明确算力需求的上限。把要部署的模型跑一遍统计MAC总量、峰值内存带宽需求、单次推理延时可接受范围。算力需求低于某个阈值比如几十GOPS直接选姿势一用RVV解决省去所有异构软件栈的麻烦。中等算力几十到数百GOPS且产品需要同时运行复杂控制逻辑姿势二是稳妥选择。算力要求极高且算法长期固定、功耗预算严苛再考虑姿势三。第二步评估软件生态的投入产出。如果团队里编译器、算子优化的人才储备不足姿势三要非常谨慎。反过来说如果团队本身就是做芯片工具链出身那深度定制路线反而是建立长期技术壁垒的机会。第三步考虑产品迭代的节奏。行业变化快、模型更新频繁的场景硬件架构的灵活性比峰值算力更重要。这个时候把AI能力全部焊死在专用指令里可能等产品上市时算法已经换了芯片却改不了。反而是主核协处理器或者RVV方案通过软件升级还能继续适配。我在不少项目里看到的一个通病是芯片规划过早进入我要做一个多强的AI算力的思维忽略了产品实际的模型演进空间。做选型不是选参数最强的而是要选软硬件生命周期匹配的。6. 落地阶段最容易踩的坑提前帮你排一排6.1 工具链自动向量化远没有你想的那么简单很多团队上RVV之后的第一件事是信心满满地写好C代码然后让编译器自动向量化跑AI算子结果性能惨不忍睹。这几乎是每个RISC-V向量开发者的共同经历。GCC/LLVM的自动向量化对一般循环有效但对卷积这种结构复杂、带有窗口滑动和padding的算子自动生成的代码往往有大量冗余load/store数据重用完全没体现出来。我现在的做法是核心算子绝不依赖自动向量化直接使用内建函数intrinsic手写关键循环。RVV的intrinsic虽然写起来繁琐但能精确控制每个数据的排布和每条指令的执行。作为参考一个手写RVV的INT8卷积算子相比编译器自动向量化版本性能差距通常在三倍以上。如果你的团队刚接触RVV这个心理预期要提前建立向量优化的核心工作是帮编译器理解数据流而不是写完C代码就完事。6.2 自定义指令与开源生态的割裂是最容易被低估的隐性成本做自定义指令设计的时候团队往往会花很多时间讨论指令的硬件实现、指令编码、性能收益很少有人认真对待这条指令如何暴露给软件的问题。结果到了软件适配阶段发现整条工具链都要动汇编器要支持新助记符、编译器后端要能生成新指令、反汇编器要能正确解析、调试器要能单步执行新指令、性能分析器要能识别新指令的耗时。任何一个环节缺失都会拖慢整个软件开发生命周期。更隐蔽的问题是生态兼容性。如果你用了自定义指令那么意味着所有第三方库、开源算子库、AI框架的算子实现都无法直接用到你的芯片上都要由自己的团队来实现和优化。这个工作量在芯片量产前不容易显现但一旦客户把自己的模型搬上来发现一半算子没有优化体验会非常糟糕。6.3 验证和原型阶段的效率问题决定你能不能按期流片AI芯片的验证复杂度远高于普通SoC。协处理器或自定义指令的计算正确性需要大量的数据级测试覆盖率。很多团队习惯用纯RTL仿真去跑AI算子结果一个中等规模的卷积算子仿真就要跑几个小时整个验证周期被拉得很长。更高效的做法是尽量早地把关键算子搬到FPGA原型环境里用真实的指令流跑起来。虽然FPGA频率只能做到几十MHz但验证的并行度可以大幅提升尤其适合做指令语义验证和软件栈早期开发。我自己习惯在芯片设计阶段同步搭建一个基于QEMU或开源模拟器的指令集模拟器环境。这样软件团队可以提前开发算子库和驱动等RTL冻结后软件已经跑通大半。很多RISC-V项目里软件团队和硬件团队互相等的问题根源往往不是管理问题而是没有提前搭建软硬件协同验证环境。6.4 给团队配置的一些参考建议最后聊一点团队组织的事。经常有人问我我们想用RISC-V做AI芯片团队需要什么样的人我的经验是无论选择哪一种姿势团队里至少要有一名真正理解工具链内部的软件工程师。硬件设计高手很多但能在最小指令集实现、编译器后端、算子优化三个层面之间来回切换的人非常稀缺。这个角色要能回答这个算子从C语言到最终机器指令每一步发生了什么哪一步开销最高如何在硬件上省掉。如果没有这个人我强烈建议先不做深度定制路线优先选择RVV加标准化协处理器的组合把自研范围控制在最需要差异化的算子层而不是一开始就钻进指令集设计的深水区。说到底RISC-V切入AI芯片这件事最大的价值不是某一个指令扩展的跑分有多好看而是它把硬件适配算法这件事的决策权交还给了芯片设计者。无论选哪种姿势你都是在用自己的判断去回答同一个问题我的产品需要多少灵活性又愿意为多少能效付出代价。这个问题没有标准答案但想清楚它比选哪条技术路线更重要。
