1. 为什么RISC-V会出现在AI芯片的选型桌上这几年只要聊到AI芯片绕不开的就是英伟达的CUDA生态、Google的TPU、各家NPU的架构路线。很多人觉得RISC-V只是MCU和嵌入式领域的事跟AI算力这种“高端局”没什么关系。但实际情况恰恰相反我过去一年接触到的AI芯片项目里RISC-V几乎成了标配——不管是做端侧推理芯片、边缘计算SoC还是服务器加速卡设计团队都会认真考虑“要不要用RISC-V怎么用”。这个现象背后是有真实驱动力在推的。AI芯片本身是一个迭代极快的领域。AI算法从CNN到Transformer再到多模态模型每隔一两年就有一次大的架构变化。这对芯片设计提出了一个苛刻要求指令集架构ISA必须具备快速演进、灵活扩展的能力。传统封闭指令集虽然性能成熟、工具链完善但每一次能力扩展都要走完整的内部流程周期动辄以年为单位。RISC-V天然是模块化、可扩展的你要加一个自定义算子指令或者调整向量处理单元的行为在架构层面就有明确的扩展机制不需要动整个指令集的根基。AI芯片的另一个痛点是成本。AI场景碎片化严重云端训练、云端推理、车规级、端侧语音、端侧视觉每个场景对算力、功耗、精度的要求都不一样。过去面对这种碎片化主流做法是同一个IP反复改或者干脆堆通用算力。RISC-V的生态里开源核比如Rocket、BOOM、CVA6、香山可以自由获取商业核Andes、SiFive、Synopsys ARC-V也有灵活的授权模式这让团队可以用更低的启动成本去定制适合特定AI场景的芯片。但“用RISC-V做AI芯片”不是一句口号就能落地的。它不是一个简单的二选一问题而是有明确的切入方式。我在不同团队、不同项目的实践和观察中把RISC-V切入AI芯片的方式归纳为三种可复用的“姿势”第一种在通用RISC-V核内部做扩展把AI能力直接融进指令流里。第二种RISC-V做控制面AI计算交给专用的加速器、NPU或协处理器通过总线或接口协同。第三种把多个RISC-V向量核组合成大规模计算阵列用类GPU的组织方式去承接AI工作负载。这三种姿势对应的是不同的产品定位、团队能力和市场目标。很多人一开始就想搞清楚“哪条路最优”但实际做下来这三条路的适用边界非常清晰几乎没有谁绝对取代谁。接下来我把每一条路的核心逻辑、技术要点和坑都拆开讲一讲。在动手之前还有一个底层认知需要先建立起来RISC-V虽然是一个指令集架构但它在AI场景下更像是“一套搭积木的规则”。它给了你基础指令、向量指令、自定义指令槽位、特权级规范等一堆积木块你怎么搭、搭成什么样完全取决于你要做的东西是什么。理解这一点后面所有技术细节才有着落。2. 姿势一在同构核里直接扩展AI能力——指令扩展与向量路线的边界2.1 轻量级AI算子如何用自定义指令塞进CPU流水线第一种姿势也是最“正统”的RISC-V玩法在RISC-V核内部通过扩展指令集来加速特定AI计算。RISC-V规范里专门预留了4个custom指令空间custom-0、custom-1、custom-2、custom-3你可以在这几个空间里定义自己的专用指令比如一个“矩阵乘累加”指令、一个“量化缩放”指令。为什么这件事在ARM或者x86上做起来很别扭在RISC-V上却很顺关键在于RISC-V的指令编码空间有清晰的自定义分区。ARM的指令集虽然也允许扩展协处理器指令但整体架构的准入和验证成本非常高而且基本是IP授权方说了算。RISC-V则不同它在规范层面就鼓励你进行自定义而且Linux、GCC、LLVM这些基础软件生态对自定义指令的支持路径是公开的、有先例的。我之前参与过一个端侧语音唤醒芯片的项目要在很小的功耗预算里做FFT和滤波运算。团队最初用的是通用MCU核算力不够后来切换到RISC-V核在custom-0空间里加了FFT蝶形运算专用指令同时利用RISC-V的AEI辅助执行单元接口把FFT加速器挂在流水线旁。实测下来FFT计算时间缩短了约65%功耗只增加了不到15%。但这里有个关键的工程边界问题自定义指令不是想加多少就加多少的它受限于解码器的并行度、寄存器的读写端口、流水线的执行宽度以及最重要的——编译器的支持。你定义了一条新指令就得让GCC或LLVM识别并自动生成这条指令否则只能内联汇编里手工调用可编程性大打折扣。如果团队没有能力改编译器后端自定义指令这条路很容易变成“写了个手撸汇编的专用核”维护成本极高。所以对于做同构扩展的团队我的实际建议是先定义清楚你的AI算子里哪些是“一生用很多次”的稳定热点把它做成指令哪些是“换一个模型就要改”的动态逻辑把它放到软件层或微码层去。指令集一旦发布就是硬件的永久承诺改一条指令的代价可能比改十个软件模块还要大。2.2 RVV向量扩展同构路线里最“通用”的AI武器除了自定义指令同构路线里更大的看点是RVVRISC-V Vector Extension向量扩展。RVV是RISC-V官方的向量指令集它定义了一套完整的可配置向量长度VLEN、向量寄存器组v0-v31、向量算术、访存、规约等指令。RVV和ARM的SVE、x86的AVX在设计哲学上非常不同。最核心的一点是RVV的向量长度是软件可配置的代码可以写一次在不同硬件实现上跑出不同的向量宽度。这意味着同一个软件栈可以无缝跑在VLEN128的小核上也可以跑在VLEN512的大核上不需要重新移植。对于AI计算来说RVV能覆盖的范围非常可观。典型的AI算子——卷积、矩阵乘、逐元素激活、归一化、池化——都具备天然的并行性用RVV可以写出一套高度优化的计算内核。FPU浮点单元在AI场景中和RVV是强绑定的比如融合乘加运算FMA在RVV里对应的是vfmacc这类指令一条指令同时完成乘法和加法直接对应AI推理中大量使用的乘累加计算模式。我记得刚开始调RVV算子时最容易忽视的就是FPU的流水线延迟和寄存器堆的写后读冲突指令调度没调好的话向量化之后性能可能反而不如标量循环这是一个非常容易踩的坑。RVV的版本演进也是一个大问题。RVV 0.7.1和RVV 1.0之间存在不少不兼容的地方。很多早期芯片用的是0.7.1但官方和工具链早已切换到1.0。如果团队选型时不谨慎拿到一个旧版的硬件IP生态支持会非常痛苦。我在实际项目中见到过因为选了一个0.7.1的IP导致后期编译器版本、操作系统补丁、第三方算子库全部对不齐的情况这个坑一旦踩进去整个项目周期可能要多出三到五个月来填。同构扩展这条路适合什么产品我的判断是适合算力需求明确且对口窄的场景——比如特定传感器数据处理、端侧音频AI、可穿戴设备的轻量级推理。它的优点是系统简单、延迟低、功耗控制好、软件栈统一不需要跨核心通信缺点是峰值算力有明显上限无法应对大模型、训练、高吞吐推理。这条路的边界就是“核内扩展的物理极限”一旦AI算子的规模超过流水线和寄存器堆的承载能力就必须走向异构方案。3. 姿势二RISC-V做主管NPU/协处理器做专家——异构SoC怎么分工才能不打架3.1 为什么大多数AI SoC选了“主控核加速器”而不是“纯加速”第二种姿势是当前AI芯片落地最主流的方式RISC-V核作为主控CPUAI计算交由专用的NPU、DSP或协处理器完成。几乎所有做端侧AI芯片的厂商包括不少国内外的AIoT芯片都是这个套路——一颗RISC-V主控核搭配一个自研或授权的AI加速器。这种架构的核心逻辑在于分工AI推理中的矩阵乘法、卷积、注意力计算等大计算量任务属于典型的“规则的暴力计算”适合用专用的脉动阵列systolic array、乘累加树或向量DSP去完成而AI任务的控制流——启动加速器、搬移数据、管理内存、做后处理、处理中断——属于典型的“不规则控制逻辑”适合用通用CPU核来做。为什么主控核往往选RISC-V而不是ARM归根结底还是成本和控制力。RISC-V核作为主控不需要为用不到的ARM生态特性付费指令集透明、可裁剪而且RISC-V的软件生态已经能够完整承载Linux、RTOS、标准C库等基础软件。更重要的是主控核需要和NPU深度协同RISC-V允许你自定义与NPU交互的专用指令或寄存器接口这种深度的系统集成自由度在ARM体系里很难拿到。3.2 加速器接口的工程细节与中断、DMA的协作逻辑异构架构的挑战全部集中在“两者怎么沟通”上。我在实际项目中看到的最常见错误就是只画出架构图觉得没问题但在接口细节上留下大量隐患。主控核与NPU之间的数据通路通常有三种选择处理器总线上挂NPU寄存器接口CPU通过MMIO操作加速器。简单但每次交互都需要CPU介入性能受限。NPU做总线主设备通过DMA直接访问内存DDR或SRAM。这是主流方式CPU只需要下发描述符descriptorNPU执行完成后触发中断。紧耦合的接口比如RISC-V的AEI辅助执行单元接口或自定义的协处理器接口把NPU的一些轻量计算直接集成进CPU流水线。一般用于深度耦合的专用IP。在工程实现上我第一次做这类设计时最大的认知提升在于数据搬运的时间往往比计算时间更致命。很多AI芯片算力标得很高实际跑模型时吞吐上不去瓶颈经常在DMA的带宽和延迟上。比如NPU需要从DDR读取输入特征图计算完写回输出如果DMA描述符链设计得不好等待间隙就会让NPU的算力闲置。另一个容易被忽视的是中断处理。NPU完成一个batch的计算后通常需要发中断通知CPU。RISC-V目前的标准中断控制器PLIC对于AI场景有一些明显的瓶颈:中断向量数量有限、中断响应延迟不够理想。新的RISC-V AIAAdvanced Interrupt Architecture规范就是为了解决这类问题而设计的引入了IMSICIncoming MSI Controller机制支持更高吞吐的消息信号中断。如果团队规划的是高吞吐AI SoC主控核的中断控制器最好直接面向AIA设计而不是沿用老的PLIC方案。主控核和加速器的缓存一致性也是一个关键决策点。最简单的方案是主控核和NPU各管各的地址空间通过共享内存加同步机制来协作——软件上要做缓存维护clean/invalidate代码复杂续航和性能都会受影响。高级一点的方案是引入硬件一致性的接口让主控核与NPU通过一致总线连接。这需要额外的硬件开销但软件编写和调试的体验会有一个质的提升。选择异构路线时还有一个容易被低估的问题工具链和调试手段的复杂度会骤然上升。原来单核裸机开发一个JTAG调试器就够了现在你要调主控核的Linux驱动、NPU的固件、DMA的描述符链、中断的响应链路再叠加缓存一致性问题排错难度呈现指数级上升。不过异构路线的好处也非常明显可扩展性极强。NPU算力不够的时候可以换更强的NPU IP或者挂多颗NPU主控核的基本架构不需要动。这种独立性让产品可以快速响应市场不同档位的算力需求这也是它能成为主流的原因。3.3 工程案例一套端侧视觉SoC的主控与NPU分工我参与过一个端侧视觉AI芯片的设计用的是单核RISC-V支持V扩展作为主控搭配一个自研的轻量NPU。我们的核心分工RISC-V主控负责运行Linux系统、处理摄像头驱动、调用NPU推理、执行AI后处理逻辑NMS、阈值过滤、网络协议栈。NPU负责卷积、矩阵乘、全连接等重型算子一次推理触发多个算子链。DMA负责摄像头帧数据搬运到内存、NPU读取输入/写回输出、推理结果显示到显示控制器。当时最深刻的体会是产品经理最看重的是“芯片能跑什么模型”硬件工程师看重的是“总线带宽和吞吐”但真正决定项目成败的其实是主控核的中断延迟和DMA调度算法。我们花了将近一个半月来调NPU任务调度最终通过把多个连续算子合并成一个“任务批”减少了一半以上的中断次数系统的整体推理帧率提升了将近40%。这个优化如果没做芯片的账面算力和实际用户体验会严重脱节。4. 姿势三把RISC-V向量核组装成“类GPU”计算阵列——面向大算力的集群化路线如果说前面两种姿势还偏保守的话第三种姿势就是真正把RISC-V的能力边界往前推了一个量级用多个RISC-V向量核组成大规模并行计算阵列以类似GPU的方式去承接AI工作负载。这条路线的基本想法是既然单个RISC-V核的向量单元RVV已经能执行高效的并行计算那么我把几十个、上百个这样的核组织成一个计算阵列通过片上网络NoC连接再配以合适的内存子系统是不是就能逼近GPU的计算形态这在技术上已经不是什么科幻设想了。RISC-V国际基金会的很多技术会议里都有相关工作业界也有服务器级AI推理芯片在进行这类实践。比如用香山处理器或自研的RV64GV核作为计算单元把多个核组成网格状拓扑再用高速互连协议比如用户自定义的NoC、或者AXI/CXL等标准总线组织通信。这套架构对于AI推理场景的适配性非常自然因为Transformer模型的矩阵乘法天然就是分块并行的每个计算核负责一个分块核间只需要在少数几个步骤同步结果。但“看起来很美”和“实际可落地”之间隔着一道巨大的工程鸿沟。第一道坎是内存带宽和层级。GPU的强势在于HBM高带宽内存配合巨大的片上SRAM数据能快速喂给计算单元。RISC-V向量核阵列要做到类似的效果必须解决多核同时访问DDR的带宽问题。这就要求在SoC中设计足够高带宽的内存控制器、足够的缓存层级、以及合理的核间数据共享机制。我在和一些团队交流时发现他们普遍低估了内存带宽对AI推理性能的约束总是先着眼于计算核的数量结果阵列做到一定程度发现性能上不去了一分析全是数据供给的问题。第二道坎是互连和同步。多核协同计算核与核之间需要频繁的数据交换。传统的总线在几十个核的场景下还行但上百个核之后总线可能成为瓶颈。向量核阵列的互连拓扑、路由算法、缓存一致性的处理方式都会直接影响系统的可扩展性。这里没有统一的成熟方案很多团队是在GEM5仿真和实际FPGA验证中不断迭代。第三道坎是上层软件栈。这一类大算力阵列的定位必然要面对复杂的AI工作负载。用户用PyTorch/TensorFlow训练好的模型如何高效地部署到这套阵列上这涉及到编译器把计算图映射到多个核上、运行时调度器、算子库、甚至是并行编程模型。RISC-V的软件生态虽然发展迅速但和GPU的CUDA生态比起来仍然是新兵训练营。我见过不止一个团队把硬件模块设计的很漂亮最后卡在“模型部署工具链做不出来”这个软件问题上。那么这条路线适合谁来做我的判断是适合有较强编译器团队和系统软件能力的机构适合面向特定垂直场景例如私有化AI推理服务器、特殊的嵌入式高算力场景做深度定制。如果团队以硬件为主、软件为辅选择第三条路的风险会比较大。对于我来说对第三种姿势的关注点始终落在“它能不能真正把RVCRISC-V Vector Core的算力转换成用户可用、软件可映射的AI算力”这件事上。如果只是在PPT上说“我们有128个向量核”而编译器连一个YOLO模型都部署不流畅那这个路线的商业价值就还有很长的路要走。但反过来一旦跨过软件工具链这道门槛RISC-V集群化路线在成本、可裁剪性、定制能力上的优势会让它在特定AI细分市场拿到非常有竞争力的位置。5. 三条路线都躲不开的工程底座——编译工具链、系统软件与验收指标5.1 编译器与工具链决定你能否真正“用起来”的那条腿前面三种姿势听起来各有侧重但落地时有个共同依赖编译器、工具链、系统软件的质量。在AI芯片行业硬件只是战斗力的一半另一半是“能不能把模型高效地映射到硬件上”。我甚至倾向于认为软件工具链的优先级应当排在硬件架构设计之前——至少要在架构定义阶段就和软件规划保持同步。先看同构扩展路线。如果团队决定在RISC-V核内加自定义指令那么GCC/LLVM的后端支持必须在研发早期就启动。LLVM的TableGen机制里定义新指令比GCC稍微友好一些但即便如此从指令定义到调度器、寄存器分配器、模式匹配规则的适配仍是一项以人月甚至人年计的工作。很多团队没预算做这件事最后只能用手写内联汇编的方式调用加速指令可维护性和可移植性都很差。再看RVV向量扩展路线。RVV代码的优化高度依赖编译器自动向量化的质量和算子库的手工调优。GCC的自动向量化对RVV的支持仍不够成熟LLVM相对好一些但在面对复杂循环结构时依然会有大量“该向量化却没向量化”的情况。实际项目里更靠得住的手段是使用O3优化加手工NEON风格的向量内建函数intrinsics甚至直接在Hotspot算子内写内联汇编。异构路线中软件栈的复杂度更大了。NPU通常有自己的指令集和编译器这时候你要维护的就不只是一个RISC-V工具链还有NPU的编译器、运行时驱动、以及两者的协同框架。这里有一个我见过的非常普遍的误区团队在早期只关注RISC-V主控核的裸机程序能跑通忽略了NPU算子映射效率等到系统集成时才发现NPU的计算利用率不到30%返工成本让人崩溃。一种值得参考的路径是在项目早期就引入“算子库性能验收”作为硬性指标。比如规定好一批核心算子Conv3x3、MatMul、Softmax、LayerNorm等必须在指定编译器版本下达到一定的cycle数达不到就不能进入下一阶段。把软件栈的工程目标对齐到硬件研发的关键节点上可以避免后期大量的返工。5.2 系统软件与操作系统适配Linux只是起点实时性不可忽视RISC-V的另一个优势是Linux支持已经相当成熟。无论是主线内核还是各大发行版对RISC-V的支持都非常积极。对于AI边缘设备来说跑Linux意味着可以用上完整的POSIX生态、文件系统、网络协议栈、用户态应用程序框架这对产品化是很关键的一步。但我在项目中反复踩过的点是Linux跑起来只是“能用了”AI场景往往还有实时性要求。端侧AI设备通常需要处理实时视频流、传感器数据、实时交互这意味着需要一定的实时性保障。RISC-V生态里RTOS方面有RT-Thread、Zephyr、FreeRTOS等也有像Xenomai这样的Linux实时扩展。但RTOS和Linux之间的选择不是拍脑袋就能定的——它直接影响NPU驱动、中断处理和数据通路的架构设计。我们做的视觉SoC当时就面临一个两难Linux方便但又担心实时性不够RTOS实时性好但应用开发和调试都要更原始一些。我们的折中方案是用单核RISC-V跑Linux处理主业务同时用另一个小核RISC-V跑裸机RTOS专门处理硬实时任务传感器采集、PWM控制两个核之间用共享内存Mailbox通信。这个架构落地后实时性问题和主业务开发效率都得到了兼顾。5.3 验收指标不能只看峰值算力要看端到端的系统表现最后要强调的是AI芯片的验收指标。很多人喜欢用TOPSTera Operations Per Second来标榜AI芯片的算力但这个指标非常容易被“注水”。TOPS是理论峰值实际使用时受限于数据带宽、算子时间复杂度、编译器的映射效率和缓存行为真实吞吐可能只有峰值的10%到30%。我在评审方案时更看重下面几项指标实际模型推理的延迟和吞吐比如跑ResNet50、YOLOv5s、Llama-2-7B的FP32/INT8性能。每瓦有效性能FPS/Watt——AI边缘设备功耗敏感这个指标比纸面TOPS有意义得多。主流框架算子覆盖率和平均算子利用率——这直接反映软件栈的成熟度。从拿到模型到芯片跑通的“端到端部署周期”——如果这个周期要三个月再过半年模型都换了部署效率就会成为商业模式的天花板。这些指标的设定应当贯穿三条路线的技术决策始终。否则很容易出现“实验室数据很好看一到用户现场就露馅”的情况。6. 三条路怎么选以及我踩过的几个坑讲了三种姿势最后说说我在实际项目里怎么判断“该走哪条路”以及几个值得分享的坑。先给一个粗略的选型框架。如果你的产品算力需求在几十GOPS到几百GOPS之间、对功耗特别敏感、模型相对固定那姿势一同构核扩展指令/RVV是比较合理的起点因为它系统最简单、成本最低。如果你的产品是边缘AI盒子、摄像头、机器人主控这类需要跑Linux、跑多种模型、算力在几百GOPS到几TOPS档位的那姿势二RISC-V主控NPU/协处理器是最高效的路线——这也是目前产业界主流的做法。如果你的团队瞄准的是服务器推理、高吞吐AI计算、有很强的编译器能力储备那姿势三向量核阵列值得押注但相应的研发投入和风险是最高的。具体到选型执行层面有几个坑我想专门提出来。第一个坑是RVV版本选错。我前面提到过RVV 0.7.1和1.0的区别这里再强调一次。如果一个硬件IP是RVV 1.0之前的版本你在软件上用的所有RVV intrinsics、汇编语法、甚至部分指令语义都可能有出入后续适配LLVM新版本时会非常痛苦。选型时第一件事就是确认向量扩展的版本号不要只听销售说“支持向量扩展”。第二个坑是自定义指令和编译器/调试器支持没有同步落地。自定义指令不是设计完硬件就完事了GDB、LLDB、性能分析工具perf都需要同步支持否则开发调试的效率会非常低。我在一个项目里体会过prolonged debug session带来的挫败——指令本身是好的但调试器反汇编反不出来、backtrace全是乱码这种体验会透支整个软件团队的信心。所以要么你有足够的人手去维护完整工具链要么从一开始就别加那么多自定义指令走RVV标准路线。第三个坑是忽视安全性设计。AI芯片往往会处理用户隐私数据视频、语音、生物特征。RISC-V在安全方面提供了PMP物理内存保护、WorldGuard部分实现、以及最新的相关安全扩展但它不是默认开启的。很多团队在设计早期图省事不规划安全边界等产品要过安全认证时才发现主控核和NPU共享同一套物理内存且没有任何访问控制要补课就非常被动。第四个坑是软件生态建设的预算和时间被严重低估。RISC-V本身是开源指令集但“开源”不等于“免工程投入”。从拿到开源核到它能稳定运行AI模型中间隔着SoC集成、BSP开发、驱动适配、算子库优化、应用框架移植等多个大环节。每个环节都是硬核的工程量。不少团队天真地以为开源免费快结果做进去才发现开源只是帮你省了指令集授权的钱工程成本一分都不会少。我个人的倾向是如果团队是第一次做RISC-V AI芯片没有太多历史包袱优先考虑“RISC-V主控核标准RVV少量NPU加速”的组合这是控制风险和时间表最稳妥的路径。等到第一款芯片流片量产、团队积累了完整的软硬件协同经验之后再考虑往向量核阵列或更高自定义度的方向演进。每次只突破一个维度成功的概率会高很多。回到开头那句话RISC-V切入AI芯片其实没有唯一正解。它更像是一个开放式的工具箱给你提供了三种不同形态的“积木搭建方案”。关键不是非此即彼地站队而是看清自己所处的产品赛道、团队能力和市场节奏把最合适的姿势用到极致。做芯片本身是长跑选择越多反而是好事因为这意味着你总能找到一条自己走得通的路。