做AI芯片软件栈验证的时候,我遇到的最大问题不是代码逻辑,而是手里没有一块趁手的RISC-V AI芯片开发板。芯片还在设计验证阶段,开发板价格离谱,总不能所有事情都等流片回来再干。我试着把QEMU作为模拟运行环境,配合AGENT来生成配置、排查启动日志、装工具链,效果比预期好很多,现在这套流程已经成了我个人做RISC-V AI软件验证的固定起点。这篇文章是系列第1篇,先把这块虚拟AI芯片的实验台完整拉起来,顺便聊聊AGENT在里面到底帮我省了什么事。1. 为什么拿QEMURISC-V当AI芯片的临时试验台1.1 没有硬件时,模拟器不是妥协,是常态很多人听到模拟器三个字,第一反应是性能差、不真实。但在芯片流片前后这个阶段,QEMU的价值完全不是跑得快,而是能复现、能改动、能自动化。真实芯片一旦焊在板子上,寄存器就固定死了,你没法临时改一个CPU扩展的频率,也没法在跑挂的时候把整颗芯片重新拉起来看波形。QEMU里这些都不是问题,参数一行改掉,几十秒重启,一个环境就换好了。我做AI芯片软件栈验证,重点关注的是编译工具链、运行时库、算子库、操作系统驱动这一整条软件链路能不能在目标架构上正常工作。这条链路不依赖具体的芯片物理实现,而是依赖指令集架构(ISA)。只要QEMU把指令集语义模拟对了,软件栈在上面跑的结论就具备很高的参考价值。这是模拟器在这个场景下不可替代的根本原因。选择RISC-V也不是随大流。RISC-V的指令集是开放的,核心冻结、扩展迭代都是混沌状态的,你可以用标准V扩展做常规向量计算,也可以用自定义扩展挂AI加速指令。QEMU对RISC-V的支持现在已经非常成熟,尤其是virt平台配合OpenSBI固件,起一个SMP多核的Linux环境就几条命令的事。相比ARM的固定IP授权和复杂的板级支持包,RISC-V这条路的可玩性和可控性明显高出一截。1.2 RISC-V V扩展跟AI负载的关系这里要澄清一个误区:QEMU里跑Linux,并不是真的在模拟一颗带NPU的AI芯片。QEMU本身没有完整的NPU MAC阵列模型,除非你自己写一个QEMU设备模型把AI加速器外设模拟出来。更常见的做法是,把CPU配置为带向量扩展(Vector Extension,简称RVV)的RISC-V核心,然后在这个环境里跑涉及大规模向量计算的AI软件负载。为什么这样可以?因为AI计算密集的部分,基本都能落到向量化指令上。无论是卷积的im2col、矩阵乘的分块,还是Transformer里大量的GELU、LayerNorm,最终都是对连续内存的一块数据做同一种运算。这正是RVV擅长的场景。RVV不是把多个数据塞进一个寄存器那样简单,它还有可变向量长度、掩码、分段加载等机制,软件里写一次,硬件向量长度变了也能适配。用带RVV的QEMU环境做实验台,验证的是程序在真实向量硬件上的行为正确性,而不必关心具体微架构的流水线细节。后面我会写一个向量加法的测试程序跑在这个实验台上,通过它确认CPU确实使能了V扩展,并且指令结果符合预期。这一步过不了,后续的算子库、推理引擎验证全都无从谈起。2. AGENT在我的搭建流程里具体干了什么活2.1 把任务拆成AGENT能接住的意图很多人用AGENT觉得不顺手,根源在于把一个模糊任务直接丢过去,然后期望它一步到位。环境搭建这种活,需要拆解成几个有明确验收标准的子任务:选一个合适的RISC-V Linux根文件系统方案;编译或下载QEMU能直接引导的内核镜像;写一条可行的QEMU启动命令,包含机器型号、CPU、内存、存储、串口;启动后验证CPU指令集、内存、网络是否正常工作。我用的AGENT是一个能执行shell命令、能读日志的终端助手。我会在对话里逐个发起子任务,而不是一次性说帮我搭一个RISC-V AI环境。比如第一轮我只让它根据我宿主机CPU和内存情况,列出QEMU RISC-V virt平台最稳的启动参数并说明理由。它给完参数后,我确认没问题再放行下一步。这样每次交互都有明确的输入和输出,AGENT出错时我也能定位到具体环节。2.2 让AGENT生成Buildroot配置并编译根文件系统我选择了Buildroot,原因是可重复性强,一个defconfig文件就能固定整条工具链和根文件系统,适合后续在不同机器上复现。AGENT在这里帮了大忙:它先检查Buildroot版本支持的RISC-V目标板,然后生成了这样一组命令:make qemu_riscv64_virt_defconfig make -j$(nproc)qemu_riscv64_virt_defconfig是Buildroot官方为QEMU RISC-V virt平台预置的配置,里面已经带上了必要的内核驱动和串口设置。编译产物里有两个关键文件:Image(内核镜像)和rootfs.ext2(根文件系统镜像)。编译时间取决于机器,我的一台8核16线程的机器大概跑了二十多分钟。这里有个细节值得多说一句:编译前一定要确认Buildroot里工具链的RISC-V架构扩展配置。默认配置是rv64gc,也就是基础指令集加整数乘法除法、原子指令、浮点。要跑向量测试,得在Target architecture的Enable Vector Extension选项里打开V扩展。这个选项藏在Target options菜单下,不熟悉菜单的人容易漏掉。AGENT直接帮我改写了configs/qemu_riscv64_virt_defconfig,把BR2_RISCV_ISA_CUSTOM_RVV(视版本而定)打开,这比我用make menuconfig手动翻菜单快多了。2.3 一个实际的AGENT交互过程我把当时的对话整理了个片段,能比较好地说明AGENT的辅助模式:我问它:我编译完Buildroot,启动QEMU后内核跑起来但根文件系统挂载失败,日志显示VFS: Unable to mount root fs,你觉得问题在哪?它先让我贴完整日志,然后指出:-append参数里的 root 设备名和实际 virtio 设备名不匹配。Buildroot 环境里的磁盘驱动是virtio_blk,设备节点是/dev/vda,但我启动参数里写的是root/dev/sda。改过来之后还要确认 rootfs.ext2 有没有放到 QEMU 的 virtio 驱动能识别的ifvirtio参数里。这个排查过程如果是我自己搞,大概要翻内核文档、试好几次。AGENT直接把最可能的两个原因列出来,我再结合日志确认,效率高很多。不是说AGENT不会错,而是在环境搭建这个场景里,它见过的组合模式比我多,给出方向性诊断的速度确实快。3. 拉起虚拟RISC-V AI芯片的关键参数:一次讲透3.1 机器型号、CPU与内存配置QEMU模拟的是RISC-V的virt通用平台,类似于ARM生态里的virt平台,专门给软件开发验证用。-M virt指定机器型号,-smp 4给4个虚拟CPU,-m 8G分配8G内存。AI负载虽然是计算密集型的,但很多算法处理流程里要加载模型权重,内存小了根本不够。CPU参数是这块实验台的核心。QEMU里RISC-V CPU的扩展是按位开关控制的,同一个CPU模型可以灵活启停扩展。不同QEMU版本写法有些差异,比如老版本用-cpu rv64,vtrue,新版本更倾向于显式写-cpu rv64,rvvtrue,vlen256。我当时先问了Agent,让它给我打印当前QEMU版本的CPU扩展参数提示:qemu-system-riscv64 -cpu help看了输出之后,我再结合Buildroot里启用的V扩展,最终用的启动命令是下面这条:qemu-system-riscv64 \ -M virt \ -cpu rv64,rvvtrue,vlen256,elen64 \ -smp 4 \ -m 8G \ -kernel Image \ -drive filerootfs.ext2,formatraw,ifvirtio \ -append root/dev/vda rw consolettyS0 \ -device virtio-net-pci,netdevnet0 \ -netdev user,idnet0 \ -nographicvlen256表示虚拟CPU的向量寄存器长度为256位,elen64表示向量元素最大位宽为64位。这个组合对于AI软件栈验证比较合理,既能覆盖大多数标量数据类型,又不至于让QEMU的译码执行慢得离谱。需要提一句的是,rvvtrue在部分QEMU版本里也可以写作vtrue,如果你照抄命令报无效参数,用-cpu help查看当前版本支持的属性名即可,这是一个通用兜底方法。3.2 virtio设备与存储、网络的衔接QEMU里最常见的坑是设备指定了,但Guest内核里没有对应的驱动,导致设备看起来有,实际用不了。virt平台上我统一用virtio设备家族,包括virtio-blk做磁盘和virtio-net做网卡。内核里这些驱动都是标配,Buildroot的qemu_riscv64_virt_defconfig也默认打开了,所以不存在驱动缺失的问题。网络部分我用的user mode网络,也就是QEMU用户态模拟的NAT,Guest里的网卡是virtio-net-pci,宿主机的QEMU进程把Guest的网络请求转发到宿主机网络栈。这种方式不需要宿主机开tap接口,不用root权限,最省事。默认情况下Guest能拿到10.0.2.15这类地址,可以直接访问外部网络,但外部网络无法主动连进Guest。对实验台来说,能下载软件包、能拉代码就够用了。-device virtio-net-pci,netdevnet0 \ -netdev user,idnet0启动进入系统后,ip addr看到eth0地址,ping一下外网域名能通,网络这步就算过了。3.3 串口控制台与无图形环境-nographic参数把串口重定向到当前终端,适合SSH到服务器上工作,不用依赖图形界面。配套的内核参数consolettyS0让内核日志和登录shell都走串口。Buildroot默认的getty配置会在这条串口上起登录会话,所以一片黑底白字里能看到Welcome to Buildroot登录提示,这就算系统完全起来了。这也是一个排查重点:如果-append里漏了consolettyS0,内核日志会走虚拟终端,而你已经用-nographic把显示输出切到串口了,结果就是屏幕上什么都没输出,看起来像是启动卡死,实际系统可能跑得好好的。我第一次用QEMU就栽在这上面,一堆日志只在虚拟终端里刷,串口上安静得可疑。所以这里强调一句:串口控制台的内核参数和QEMU的-nographic必须配套出现。4. 启动阶段真实踩坑:Agent帮我把日志读明白了4.1 VFS挂载失败:设备名对不上第一次启动的结果是内核可以引导,OpenSBI打印完一堆固件信息之后,内核日志里出现:[ 1.123456] VFS: Cannot open root device vda or unknown-block(0,0): error -6 [ 1.234567] Please append a correct root boot option; here are the available partitions:这个日志很让人崩溃,因为它同时告诉你找不到根设备和这是哪些可用分区,而分区列表通常很长。Agent的直接作用就是让我把分区列表一并贴给它,它扫一眼就指出:列表里的253:0对应的是/dev/vda,而我的root参数写的是/dev/sda。Buildroot的virt平台默认用的是virtio块设备,设备节点是vda,不是传统的sd开头。改掉之后重启,根文件系统顺利挂载,系统进入登录提示。这个坑很小,但很容易浪费十几分钟。事后总结,凡是QEMU virt平台配Buildroot,直接记住root/dev/vda即可,这是这个组合的固定答案。4.2 Vector扩展的验证:CPU信息里到底有没有V系统起来之后,第一件事不是跑AI代码,而是确认CPU使能了V扩展。在Guest里执行:cat /proc/cpuinfo注意看isa这一行。如果只看到rv64imafdc,说明内核是64位RISC-V基础指令集加整数乘除法、原子指令、单双精度浮点,但向量扩展并没有生效。如果看到rv64imafdcv,说明V扩展已经进入ISA位。我第一次编译Buildroot时忘了开启Vector选项,启动后isa里死活没有v,但QEMU命令行明确加了rvvtrue。这个矛盾一度让我很困惑。Agent的分析是:QEMU侧允许该CPU启用V扩展,但内核镜像本身在编译时没有使能CONFIG_RISCV_ISA_V这个配置项,内核不认识V扩展,自然也不会把它写到CPU信息里。换句话说,模拟器给了指令集,但操作系统这层没有打开开关,上层软件依然用不了。解决方法是重新配置Buildroot的内核选项,打开CONFIG_RISCV_ISA_V:make linux-menuconfig在Platform selection里找到Enable Vector Extension support,打开之后重编内核。这个选项直接决定Linux内核能否管理和暴露RISC-V的向量扩展,如果没开,即便/proc/cpuinfo写了v,系统调用prctl设置向量长度这类操作也会不可用。4.3 向量指令集跑起来:一个小程序验证确认/proc/cpuinfo的isa包含v之后,我写了一个最小的RVV测试程序。这段代码用的是RISC-V向量Intrinsics,不是手写汇编,方便阅读。功能就是两个长度为8的浮点数组按元素相加:#include riscv_vector.h #include stdio.h int main() { 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}; size_t vl vsetvl_e32m1(8); vfloat32m1_t va vle32_v_f32m1(a, vl); vfloat32m1_t vb vle32_v_f32m1(b, vl); vfloat32m1_t vc vfadd_vv_f32m1(va, vb, vl); vse32_v_f32m1(c, vc, vl); for (int i 0; i 8; i) { printf(%.0f , c[i]); } printf(\n); return 0; }在Guest里用gcc -marchrv64gcv -mabilp64d -o vadd vadd.c编译。重点关注-marchrv64gcv,这个参数告诉编译器:目标架构是64位RISC-V,基础指令集加V扩展。编译完运行,输出9 9 9 9 9 9 9 9,说明向量寄存器装载、向量浮点加、向量存储三个环节全链路跑通。这里顺便说一个Agent提醒我的细节:如果只加-marchrv64gcv但没加-mabilp64d,编译可能因为ABI不匹配报错。RISC-V世界里-march管指令集,-mabi管数据模型和函数调用约定,两者必须配套。rv64gcv对应lp64d是Linux环境下最常见的组合。4.4 Agent在这个环节真正省力的点回顾踩坑过程,AGENT帮我的不只是每次给个答案,而是反复纠正我对模拟器—内核—根文件系统—编译器这条链条的理解。比如CONFIG_RISCV_ISA_V这个内核配置,如果没人提醒,我可能会去重新编译工具链,压根想不到问题在内核。如果没有AGENT把/proc/cpuinfo的isa输出和内核配置关联起来,我自己要从setfacl这类冷门文档里找答案,效率会低很多。不过我也要泼一点冷水:AGENT给的建议必须结合实际输出验证,不能盲抄。它曾经很自信地建议我打开CONFIG_VECTOR_2_4_5之类我完全没见过的内核选项,查了一下才知道那是别的东西的配置,与RISC-V无关。所以正确的姿势是让AGENT解释它的推理依据,再对照当前环境的事实判断,两边确认一致才动手。5. 实验台跑通后,验证AI计算和后续扩展5.1 用工具链和SDK把实验台武装起来这套基础环境跑通后,下一步就是在实验台上装齐AI软件栈。我建议优先做两件事:安装带RISC-V向量支持的编译工具链,至少保证gcc能输出rv64gcv目标;安装一份RISC-V向量数学库或基础算子源码,用来跑矩阵乘、卷积这类AI里的核心算子。Buildroot生成的rootfs里已经自带一套交叉工具链,但Guest里可能没有完整的gcc。如果要在Guest里编译程序,可以用make busybox-menuconfig这种笨办法去翻包,更高效的做法是直接在Buildroot里勾选gcc和make包,重新生成rootfs。或者干脆走交叉编译路线,在宿主机用riscv64-linux-gnu-gcc编译好二进制再拷进rootfs,这在CI里更可控。我个人偏向在Guest里直接编译,因为这样才能顺手验证头文件路径、链接行为这些跟目标环境强相关的东西。交叉编译器即使架构对了,头文件版本和-march默认值也可能和Guest环境有微妙差异,这些差异在AI算子这种对底层敏感的代码里会被放大。5.2 最小AI算子的模拟验证路径有了gcc和RVV支持,可以继续往AI方向走。一个比较常见的路线是移植一个轻量的矩阵乘法实现,把它从标量循环改成向量化版本,然后对比结果。比如一个MxK乘KxN的矩阵乘,最朴素的内层循环是一个点积,写成向量代码后每次处理vl个元素,性能逻辑上会有成倍提升。QEMU虽然是模拟执行,不会给出真实的性能数据,但能验证矢量化的正确性。这个点我要特意说明:在QEMU上做AI软件验证,你验收的是功能正确而不是性能达标。真实芯片上可能还有缓存、多核互连、DMA搬运等机制,QEMU不会也不该模拟这些东西。实验台的定位是:在拿到真实芯片之前,先把软件栈的所有bug排干净,让真实芯片到手的当天就能跑出有效结论。5.3 把AGENT固化到自动化验证流程里我现在的用法已经不只是让AGENT帮我搭环境,而是把整个流程沉淀成脚本,让AGENT在CI的每次构建里自动做三件事:起QEMU、编译向量算子测试、检查运行结果里的关键日志。这样每次改动内核配置或QEMU参数,都能快速回归一遍,不让环境问题污染上层的软件验证结果。如果你也想走这条路,我建议把QEMU启动命令、Buildroot defconfig、向量测试源码一起纳入版本管理。仓库里放一个简单的Makefile,make qemu拉起实验台,make test在Guest里跑算子验证。这套东西一旦成型,后续换机器、换内核版本、换工具链版本都是几分钟的事。我个人实际操作中最大的体会是:AGENT不是替你下决策的人,它更像一个读过很多文档、且不怕反复试错的助理。环境搭建这种活,试错成本主要在人机交互的往返上,AGENT恰恰能把往返时间压得很低。你把日志贴过去,它能快速给出方向;你把方向拿回来验证,它再根据新日志修正判断。这一套打下来,一个人干一个团队的活,真不是夸张的说法。这系列的第2篇,我打算继续在这个实验台上移植一个真实AI算子,比如GEMM的RVV优化版本,再跑通一个最小的推理样例。到时候这套QEMU环境的价值会更直观地显现出来:你不只是在配环境,而是真的在一块虚拟RISC-V AI芯片上,把软件栈从零到一立起来了。