六月的第一周我在整理RISC-V小组的季度计划时突然意识到过去三个月的信息密度比前两年任何一个时间段都要高。RISC-V这个指令集架构过去给人的印象总停留在嵌入式MCU、FPGA软核和RTL级开源核但2026年6月到8月的技术动态基本把整个产业的叙事彻底拉高了规范层面的RVA profile推进到了新迭代高端应用处理器开始把向量扩展和AI加速当成默认配置软件生态从“能跑”慢慢走向“好跑”。作为组里负责跟踪生态动态的人我把这三个月里看到的架构更新、芯片发展、工具链变化以及我们自己做过的一些复现实验整理成这篇笔记。无论是刚开始接触RISC-V的新人还是已经在做相关开发的工程师应该都能从里面找到可以参考的坐标。1. 规范与profile推进RVA24的轮廓和它背后的紧迫感1.1 profile是什么为什么每一次profile调整都值得关注RISC-V给人印象最深的特点之一就是“模块化”基础指令集加一堆可选扩展想怎么组合就怎么组合。但自由也是有代价的。如果每颗芯片支持的扩展集合都不一样操作系统、编译器、虚拟机和上层应用就没办法做统一适配只能“一芯一调”这在实际的软件交付流程里几乎不可接受。为了解决这个问题RISC-V引入了profile的概念你可以直接把它理解成Android系统的API Level或者普通桌面CPU的微架构级别定位。它规定了一个“运行级实现”必须支持的最小扩展集合比如面向应用处理器的RVA、面向嵌入式的RVM、面向微控制器的RVP。只要芯片厂商按某个profile来设计软件团队就可以按同一份规范去适配不用为每一颗底层芯片单独写分支。RVA23是应用级profile里相当重要的一版它把rv64gc、向量扩展RVV 1.0、标量加密扩展等东西整合成了相对统一的基线。到2026年6月至8月技术圈里的讨论焦点已经开始转向RVA24。这并不意外因为RVA23发布已经有一段时间应用处理器的算力需求、AI负载比重、虚拟化和安全场景的复杂度都在快速变化。RVA24能不能落地在很大程度上决定了未来两三年里我们会不会看到一批“软件生态整齐划一”的RISC-V笔记本、服务器和车规芯片。对于普通开发者来说这比某颗CPU的跑分数字重要得多。1.2 这个季度看得见的新扩展方向这三个月里RISC-V各个扩展工作组最活跃的议题集中在了几个方向。第一个是缓存块预取操作类扩展主要是为了给高性能处理器更明确的访存行为提示让乱序执行和预取器能更聪明地工作。第二个是“可能为全零指令”这类扩展它在指令编码层面预留了解析空间未来指令集演进时可以无缝填进更多功能老代码不会被破坏。第三个是IO保护也就是用类似页表的机制去限制外设DMA的访问范围。这一类扩展对服务器和车规场景特别重要因为它直接关系到设备驱动漏洞的隔离能力。这些扩展不像当初向量扩展那么抓眼球但它们要解决的都是“从单机跑到大规模部署”之间的工程问题。我印象比较深的是小组内部一次分享里有同事提出一个类比基础指令集是毛坯房profile是精装交付标准而这些新扩展就是给精装房铺的弱电管线和消防通道。硬件厂商不能只看客厅够不够漂亮更要看整栋楼能不能住人。理解了这一点就不会觉得这些偏底层的改动跟自己没关系。1.3 我们如何把规范变化翻译成实验清单规范文档是枯燥的直接逐条读很容易走神。我们小组现在的做法是把每一个感兴趣的扩展变成一条可以验证的问题。比如看到Zicbop进入草案就问“QEMU是否已经支持了Linux内核里是否已经有相关指令的封装”看到虚拟化相关特性更新就问“KVM的RISC-V后端目前走到了哪一步”每一条问题对应一个小实验实验做完就把结果记录在小组共享文档里。这样既有输入又有输出不会变成“看了就忘”。具体操作上我比较推荐直接盯住riscv-isa-manual这个官方仓库关注release分支和PR合入记录同时配合QEMU的changelog。QEMU对新扩展的模拟支持往往比真实芯片更早用来验证指令有没有被正确解码和执行非常合适。下一章我会专门讲怎么用QEMU做一轮最小复现这里先不展开。总之规范层面的进展必须落到“某个指令我能在模拟器里跑通”才算是真正掌握。2. 高端芯片与硬件动态多核、AI加速与车规落地2.1 应用处理器的“核战”共识6月到8月RISC-V应用处理器领域最明确的趋势就是“往上走”。前几年提到RISC-V的SoC大家默认就是几个核的嵌入式处理器跑个RTOS或者轻量Linux就差不多了。但这三个月里我看到的公开资料和讨论已经有相当一部分转向了256核乃至更高核心数的服务器SoC设计。这些设计普遍采用chiplet方案把计算die、IO die、内存控制器分开再通过统一的片上互联协议串起来做法和x86/ARM阵营的高端服务器已经很接近。这里有一个关键变化值得注意多核互联的一致性问题。以前RISC-V芯片多是单簇设计几个核共享一个L2就完了。到了几十上百个核的规模缓存一致性协议、互联拓扑、中断路由、内存模型这些都需要往企业级方向靠。这已经不是单纯堆CPU核能解决的问题而是整个SoC体系结构的设计方法论问题。对我们这些搞软件的人来说这意味着原来在ARM服务器上积累的SMP调优、NUMA感知、中断亲和性经验可以在RISC-V平台上继续发挥作用不用推倒重来。2.2 向量扩展和AI加速从“选配”走向“标配”过去大家聊RISC-V的AI能力经常会陷入一个争论走向量算力路线好还是单独挂NPU好。从这几个月行业交流的方向来看答案越来越清晰两者不是二选一而是协同工作。RVV 1.0向量扩展已经成为应用级profile的一部分基本上新的应用处理器都会带上中长向量能力用来跑一些中等算力的算子比如语音特征提取、图像预处理、部分矩阵运算。而大规模神经网络推理则交给专门的可编程AI加速内核。这种分工背后是成本和功耗的考量。向量单元是通用计算的一部分几乎不增加太多额外芯片面积却能把一批常见算子跑起来。专门NPU虽然算力密度高但面积大、工具链复杂不可能每颗芯片都挂。所以厂商更愿意做“向量打底、AI内核兜底”的配置。对开发者来说这意味着RVV intrinsics编程不再是一个小众技能而是未来做端侧推理优化绕不开的基本功。我自己的体会是评测一颗RISC-V AI芯片千万别只看NPU的TOPS数字。有效算力取决于整个数据通路向量单元能不能顺利接管归一化、量化、填充这些“杂活”内存带宽能不能喂饱计算单元算子库有没有针对性的实现。这几个月我跑了几个小模型的端侧推理发现同样的架构设计不同厂商的算子库实现差异可以达到好几倍。选择平台时工具链和算子库成熟度比纸面峰值算力更值得花时间考察。2.3 车规与工业领域的安全牌车规芯片是RISC-V这几年一直在啃的硬骨头2026年年中的进展主要集中在安全机制上。越来越多设计方案开始强调功能安全岛、锁步核、错误检测与恢复RAS能力目标直指ISO 26262认证的需求。这个方向不像消费电子那样追求极致性能而是追求“可证明的正确性”芯片内部要有足够的冗余和自检机制即使发生故障系统也能安全地降级或者退出运行。我们小组有一位同事以前做汽车电子他提到一个很现实的观点车规RISC-V的推广难点不只是设计本身还在于整个生态链的认证周期。一颗芯片从流片到上车可能需要三到五年的验证和认证周期很多车厂不敢轻易切换。2026年这一段能看到越来越多的Tier1和车厂开始做技术预研把RISC-V作为可选方案放到评估清单里。这个信号的含金量比某颗芯片发布本身还要高因为生态一旦进入车厂的采购漏斗接下来的落地速度会明显加快。3. 软件生态与OS适配这个季度最值得盯的几块3.1 Linux内核RISC-V的“上游化”进度三个月时间里Linux内核主线对RISC-V的支持明显在走向“一等公民”的位置。多个架构特性的对齐工作持续推进比如BPF在RISC-V后端上的完善、RCU和调试机制的适配、ACPI在RISC-V平台上的合入进展、以及针对服务器的RAS和热管理支持。过去在ARM64上能用的那套系统巡检、性能分析和故障定位手段正在逐步迁移到RISC-V上。这背后最大的意义不是代码量而是“软件兼容性承诺”。内核如果只是一个开发板能启动、但很多子系统缺失的平台大家做软件选型时还是会犹豫。现在RISC-V相关补丁越来越多地伴随着“具体的服务器场景需求”出现这比任何宣传口号都更有说服力。对开发者来说如果你想跟踪内核侧进展最直接的方式就是订阅linux-riscv邮件列表看每轮patch的review意见比看二手新闻要准确得多。3.2 编译器、运行时与AI框架从“能编译”到“能优化”应用处理器跑起来了接下来自然轮到编译器。GCC和LLVM这两个主力编译器在RISC-V后端上的自动向量化能力这几个月给我的感觉是明显上了一个台阶。以前写RVV代码多少要依赖手写intrinsics编译器能把简单循环自动向量化就已经不错了。现在面向特定微架构的调优选项更丰富标量替换、循环展开、内存别名分析这些优化在RISC-V后端上也逐渐成熟。对普通C/C项目来说“开O2就能白嫖一点向量收益”的情况正在变多。另外一个让我比较兴奋的点是Rust的推进速度。Rust在RISC-V target上的支持已经非常务实无论是riscv64gc-unknown-linux-gnu还是针对嵌入式场景的target triple都能在官方工具链里直接使用。很多RISC-V厂商也开始提供Rust的板级支持包我们小组测试过用Rust写一个小的系统服务编译链接的顺畅程度和C工程基本没有差距而且在内存安全方面确实省心很多。AI框架方面最受关注的还是PyTorch和ONNX Runtime在RISC-V上的移植。过去这类框架在这个平台上更多是“能编译”性能完全没法看。但从6月到8月的趋势来看关键算子库的优化数量在增加特别是在CPU推理路径上RVV向量化的覆盖面越来越大。这意味着端侧跑模型推理时不再需要把所有算子都挪到NPUCPU本身也能分担一部分工作。如果你手里有一块RISC-V开发板我非常建议编译一个ONNX Runtime的CPU版跑一遍主流模型会明显感觉到这两年软件层面的进步。3.3 固件与虚拟化服务器场景绕不开的功课高性能场景除了内核和编译器还逃不开固件和虚拟化。U-Boot对RISC-V的支持比较成熟这没问题真正在往前赶的是UEFI生态和ACPI表完善。因为只有在固件级把ACPI落实了操作系统才有可能做到标准的PCIe枚举、中断路由、时钟管理和热插拔而不需要依赖一堆设备树补丁。RISC-V服务器要进入数据中心这一步是必经之路。虚拟化方面KVM在RISC-V上的状态也在快速成熟。我们小组用QEMU嵌套跑过KVM虚拟机虽然距离大规模商用还有一段距离但这个方向已经能用起来。IOMMU、中断控制器虚拟化、直通设备这些服务器虚拟化关键特性都有对应的实现或正在推进的补丁。对于从事云基础设施研发的读者我建议持续跟踪这个子方向。RISC-V在开放授权上天然适合做定制化云芯片虚拟机稳定性的每一点进步都会让这个市场更快打开。4. 开发者入门与复现QEMU下的RV64实战4.1 为什么强烈建议从QEMU开始很多朋友学习RISC-V时的第一反应是买开发板这当然没问题但我个人强烈建议在买板子之前先用QEMU把环境跑通。原因很简单QEMU是免费、可重复、无硬件故障风险的而且它对新指令扩展的模拟往往比真实芯片更超前。你可以在几分钟内启动一个完整的RV64 Linux系统编译软件、跑测试、验证指令集特性全程不需要焊接和插线。更重要的是用QEMU可以把学习过程“最小化”。遇到问题时你能确定是软件配置错误、代码bug、还是模拟器的问题不会因为开发板供电不稳、线缆接触不良这些硬件琐事分心。先把软件流程搞清楚再上板子就有了对照的基准排错会快很多。4.2 用Buildroot最小化跑通RV64 Linux整个过程最快的方式是用Buildroot它能把交叉编译工具链、内核、rootfs全部打包处理好。我直接给一套可以照着跑的流程。git clone https://gitlab.com/buildroot.org/buildroot.git cd buildroot make qemu_riscv64_virt_defconfig make -j$(nproc)等待编译完成以后Buildroot会生成一系列镜像文件。执行它自带的启动脚本就能看到模拟的最小系统开机./output/images/start-qemu.sh如果想手动启动也可以直接用这一条命令qemu-system-riscv64 -machine virt -nographic \ -kernel output/images/Image \ -drive fileoutput/images/rootfs.ext2,formatraw,ifvirtio \ -append root/dev/vda rw consolettyS0 \ -m 2G启动之后你可以执行cat /proc/cpuinfo确认里面出现的指令集标志比如rv64imafdc_zba_zbb_zbc_zbs_zicsr_zifencei_zihintpause_zawrs_zfa_zfh_zfhmin_zkt_zvbb_zvbc_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkb_zvkt这样的长串。看到这些字符串说明QEMU把RISC-V的很多扩展都暴露给了guest系统。4.3 跑一条向量指令确认扩展真的生效光登录系统还不够我建议你亲手编译一个用到了向量扩展的小程序这样才能真正验证工具链和模拟器链路。下面这个例子做一次简单的向量浮点加法。先写C代码#include riscv_vector.h #include stdint.h #include stdio.h int main(void) { float a[8] {1, 2, 3, 4, 5, 6, 7, 8}; float b[8] {8, 7, 6, 5, 4, 3, 2, 1}; float c[8] {0}; const float *pa a; const float *pb b; float *pc c; size_t vl __riscv_vsetvlmax_e32m1(); vfloat32m1_t va __riscv_vle32_v_f32m1(pa, vl); vfloat32m1_t vb __riscv_vle32_v_f32m1(pb, vl); vfloat32m1_t vc __riscv_vfadd_vv_f32m1(va, vb, vl); __riscv_vse32_v_f32m1(pc, vc, vl); for (size_t i 0; i 8; i) { printf(%f , c[i]); } printf(\n); return 0; }然后编译riscv64-linux-gnu-gcc -O2 -marchrv64gcv -mabilp64d -o vecadd vecadd.c把编译出来的vecadd传到guest里执行终端会打印出1到8累加的结果。如果你的QEMU版本较老对向量扩展支持不完整启动QEMU时可能需要额外加-cpu rv64,vtrue。跑这个实验最大的意义不是算法本身而是确认你在真实应用里可以直接采用RVV编程模型工具链、模拟器、运行时都支持到位了。4.4 为什么别拿QEMU当跑分工具很多朋友跑通环境之后第一反应就是放个benchmark进去测性能然后得出结论“RISC-V很慢”。这里必须提醒一句QEMU是二进制翻译模拟器它的执行速度不等于任何一颗真实RISC-V芯片的速度。你在模拟器里测出的数字受宿主机CPU、QEMU翻译效率、内存访问路径的影响非常大只能用来验证软件功能是否正确完全不能用来做性能对比。我自己在这件事上踩过坑。早些年用QEMU跑一套加解密程序看到结果比x86原生慢了几个数量级一度以为是RISC-V架构不行。后来拿到真实开发板才发现QEMU的翻译开销掩盖了大部分真实性能特征。所以正确的做法是用QEMU做功能验证和调试把性能评估放到真实硬件或者厂商提供的仿真环境里去做。5. 社区讨论热度与小组的跟踪方法5.1 这个季度社区在讨论什么6月到8月RISC-V社区邮件列表和各个工作组例会的信息量都很大。讨论比较集中的一方面是和profile相关的“最小集”问题哪些扩展应该进入RVA24哪些延迟到下一版不同厂商基于自身产品定位给出的答案并不完全一致。这种争论其实很健康因为profile一旦确定下来就不方便随意修改大家需要把各种各样的需求在早期博弈清楚。另一个讨论热点是软件包移植和测试基础设施。随着RISC-V设备数量增长越来越多的开源软件包开始加入官方CI矩阵在riscv64架构下跑测试。这个变化非常重要因为它意味着“RISC-V没软件”的尴尬正在被大量自动化测试慢慢消解。我们小组接到的很多移植任务早期需要发邮件去恳求上游仓库加上riscv64的target现在反过来不少上游项目会主动在变更日志里提到“补充了对riscv64的验证”。这个态度的转变比某一次大版本发布更能说明生态的健康程度。5.2 我建议按这个清单做周度跟踪信息源太多时容易焦虑所以我给小组内部整理了一个精简的跟踪清单效果还不错分享出来供大家参考。关注内容推荐入口跟踪节奏适合谁指令集规范更新riscv-isa-manual仓库、RISC-V官网每周芯片设计、底层软件Linux内核riscv补丁linux-riscv邮件列表、patchwork每周内核开发者、系统工程师编译器进展GCC/LLVM上游issue和patch单双周编译优化、应用开发者发行版移植状态Fedora RISC-V、openSUSE RISC-V邮件列表每月运维、软件包维护者AI框架支持PyTorch、ONNX Runtime GitHub issues每月人工智能应用开发者开发板及硬件资讯各大板厂官网、Hacker News每月爱好者、集成商我个人的经验是不要只盯网页新闻新闻是经过了筛选和加工的结果往往滞后于真实进展。直接看PR合入记录、邮件列表讨论、issue中的技术细节反而能在最短时间内抓住生态的真实脉搏。哪怕每天只花十五分钟扫一眼一个月积累下来你就能明显感觉到自己对RISC-V动态的理解比看转载文章时深得多。另外小组内部可以约定一种“复现式汇报”的方式。每个人跟踪一个方向遇到重大更新时不仅要在周会上口头分享还要带上一个最小复现实验比如跑一段程序、编译一个补丁、或者启动一个新镜像。这样做的好处是汇报内容不会停留在“某项目发布了某特性”而是变成“我们验证过特性是这样工作的”。这几个月我们用这种方式消化了大量RISC-V动态效果比单纯读文章好很多。最后再分享一个我反复踩过坑才确认的经验无论看到多么令人兴奋的新扩展或者新芯片发布动手之前先确认软件工具链版本是否跟上。RISC-V的硬件往往走在工具链前面如果编译器、QEMU、内核的版本不匹配你很可能在一个老旧的工具链里折腾半天也复现不出新特性。最稳妥的方式是先更新到各项目的latest版本再去看相关文档。别问我为什么知道光是把工具链版本对齐这件事就够我单独再写一篇分享了。