1. 为什么非要在 QEMU 里搭一个 RISC-V AI 芯片实验台

最近我一直在折腾一件事：用 AI Agent 辅助搭一套 QEMU 模拟环境，目标是纯软件链路下拉起一块 RISC-V 架构的 AI 芯片实验台。很多人一听就皱眉——芯片实验台不应该是真芯片加开发板吗？模拟器能顶什么用？

我的回答是：能顶大用，尤其在 AI 芯片开发周期里。真实的 SoC 板子流片周期长、价格贵，软件团队想在硬件回来之前就把编译器、运行时、推理框架跑通，唯一的选择就是指令集模拟器。QEMU 在这里不是一个"玩具"，而是整个软件栈预研的基础设施。RISC-V 这几年能火起来，很大一部分功劳要记在 QEMU 这种开放仿真平台身上——你不需要一块真实芯片，就能把 Linux、GCC/LLVM 工具链、PyTorch 运行时全部提前踩一遍。

这个实验台适合谁？三类人最需要：

• 做 RISC-V AI 芯片软件栈开发的工程师，需要在硬件回来前搞定交叉编译、启动流程、驱动验证；
• 做 AI 框架适配的同学，想在 RISC-V 平台上验证算子实现、向量扩展（RVV）的性能基线；
• 单纯想学 QEMU 和 RISC-V 的学生或爱好者，用一套纯软件环境把"芯片级 Linux 系统"跑起来，比买开发板门槛低得多。

还有一个隐藏角色值得一说：Agent。整个搭建过程里，我让 AI Agent 承担了"查文档、生成脚本、分析启动日志、修 bug"的活。传统做法是人在键盘前反复试错，这次我换了个玩法——把 Agent 当协作工程师用。这个思路后面会详细展开。

QEMU 模拟 RISC-V 平台这件事本身不复杂，复杂的是"模拟出来的东西到底能不能当 AI 芯片实验台来用"。如果你的目标只是让内核启动到控制台，那一条 qemu-system-riscv64 命令就够了。但如果要跑 AI 推理、验证向量指令、复现芯片行为，就需要从模拟器特性到内核配置到 rootfs 一步步深挖。这篇文章就是把这条链路完整拆给你看。

2. 方案选型：为什么选 QEMU virt 机器，为什么关注向量扩展

2.1 先别急着选板子，先搞懂 QEMU 的三种 RISC-V 玩法

QEMU 对 RISC-V 的支持分成几层，不同需求踩不同方案。我实际用过三种：

第一种是直接用 QEMU 自带的 virt 平台。这是 QEMU 团队维护的通用虚拟平台，启动快、设备齐全（virtio 网卡、virtio 块设备、串口、RTC 都有），不需要任何真实板级硬件描述，最适合跑 Linux 用户态应用和验证内核功能。缺点也很明显：它不是某款真实芯片的行为级模拟，跑出来的性能不代表真实 SoC 的性能。

第二种是针对特定芯片的模拟，比如支持全志 D1（C906 核心）或者一些开发板的 machine。这种方案能更接近真实芯片的设备树和外设布局，但 QEMU 对每种开发板的支持成熟度参差不齐，经常遇到设备驱动不匹配的问题。如果你做的 AI 芯片基于某种公开的 RISC-V 核，可以找找看有没有对应的 QEMU machine，能省不少事。

第三种是自己动手扩展 QEMU，给自定义的 RISC-V 核和 AI 加速器写设备模型。这是芯片公司的常规操作——硬件 RTL 还没冻结，软件仿真模型先上 QEMU。这种做法门槛高，但价值也最大。

我做实验台选的是第一种，virt 平台。原因很直接：我要验证的不是某个具体芯片的驱动，而是 RISC-V 向量扩展（RVV）在 AI 推理场景下的软件栈是否跑得通。virt 平台对 RVV 的支持非常干净，没有多余的外设干扰，非常适合做算法验证。

2.2 对 AI 芯片来说，RVV 指令集才是灵魂

聊 RISC-V AI 芯片绕不开 RVV（RISC-V Vector Extension）。哪怕是入门的人也应该明白，AI 计算本质是大量的矩阵乘法和张量运算，这些操作天然适合向量化。ARM 那边有 NEON，x86 那边有 AVX，RISC-V 这边就是 V 扩展。一个支持 RVV 1.0 的核，配上合适的编译器，跑起卷积和矩阵乘法来效率能拉开好几个档次。

我搭实验台时特别确认了一件事：QEMU 里模拟出来的 CPU 是否启用 V 扩展。这直接决定了后续能不能在模拟器里跑向量优化的算子。QEMU 模拟器在 CPU 类型上做得很灵活，可以通过-cpu rv64,v=true这类参数打开向量扩展，甚至可以设置 vlen（向量寄存器长度）。这一点对 AI 芯片实验台来说，比模拟多少个核还重要。

我见过不少人栽在这里——拿默认参数启动 QEMU，进去后/proc/cpuinfo里根本没有riscv,isa的 V 标志，然后编译任何用到向量指令的代码都会报非法指令错误。这不是模拟器的问题，是你没把 vector 开关打开。

2.3 AGENT 在这个方案里的真实定位

说完 QEMU 和 RISC-V，再聊 Agent 的角色。我这次用的是个大模型驱动的 Agent 工作流，它做的事情包括：

• 根据我给的硬件目标（RISC-V 64 位 + RVV），生成编译内核的 defconfig 修修补补方案；
• 分析 QEMU 启动卡住的日志，定位是设备树问题、驱动问题还是 rootfs 问题；
• 帮我写 buildroot 配置、写测试用例、生成性能基准脚本。

说白了，Agent 不是来替我做决定的，而是当"读过很多文档的助手"来用的。它最大的价值是省去了我在文档海洋里捞信息的时间。QEMU 的文档、RISC-V 内核的 Kconfig、buildroot 的配置项，这些内容的细节多到一个人根本记不住，让 Agent 先梳理一遍，我再做判断，效率翻倍。

这里我建议你把 Agent 当"资深搜索 + 代码助手"的组合体，不要当"权威"。它给的命令和配置你仍然要自己验证，但用好了确实能少掉大部分头发。

3. 环境搭建实操：从零拉起 QEMU + RISC-V 虚拟硬件

3.1 安装 QEMU：源码编译还是包管理器，我建议各搞一套

QEMU 的安装有两条路线：直接用系统包管理器装，或者源码编译。我强烈建议两条都走。

包管理器的版本胜在稳定、装完即用。在 Ubuntu 上就是一条命令：

sudo apt install qemu-system-misc

注意不是qemu-system-riscv64单独一个包，很多发行版把非 x86 架构的模拟器都塞进了qemu-system-misc。装完验证一下：

qemu-system-riscv64 --version

如果输出正常，说明基础版本到位。但这里有个问题：发行版的 QEMU 通常版本偏旧，对 RVV 1.0 的支持可能不完整，或者缺少一些新加入的特性。所以我会同时从源码编译一个最新版，作为实验台的"主力模拟器"。

源码编译 QEMU 并不难，但有几个坑值得先说：

• 依赖库除了 build-essential，还需要 ninja-build、pkg-config、libglib2.0-dev、libpixman-1-dev；
• 配置时用--target-list=riscv64-softmmu可以只编 RISC-V 系统模拟器，编译时间骤降；
• 最好加--enable-slirp，后面配置网络要用。

命令大概是这样：

git clone https://gitlab.com/qemu-project/qemu.git cd qemu mkdir build && cd build ../configure --target-list=riscv64-softmmu --enable-slirp make -j$(nproc)

编译完成后，build/qemu-system-riscv64就是我们的主力工具。我实测下来，源码编译的版本比系统自带的版本对向量扩展的模拟更完整，启动速度差异不大。

3.2 交叉工具链：没有它，你在虚拟平台上什么都编译不了

QEMU 只是硬件模拟器，你还需要一套能在 x86 宿主机上生成 RISC-V 可执行文件的交叉编译工具链。没有工具链，你连一个 hello world 都跑不到目标平台上。

有三条路可以走：

1. 用发行版自带的交叉工具链。Ubuntu 下装gcc-riscv64-linux-gnu，然后直接用riscv64-linux-gnu-gcc编译；
2. 用 buildroot 自己编一套工具链，好处是版本可控、glibc/musl 可选；
3. 直接下载 Sifive 等团队提供的预编译工具链。

我推荐 buildroot 路线，原因在于后面做 rootfs 也要用到它，一条链路全搞定。buildroot 本身是个极其强大的嵌入式 Linux 构建工具，它能生成完整的交叉工具链、内核、rootfs。下载解压后：

make qemu_riscv64_virt_defconfig

然后（如果你不需要特别定制）直接make。注意第一次编译时间会比较长，因为要从零编译工具链，大概 20 到 40 分钟，取决于机器性能。编完后output/images/目录下就有完整的启动镜像，包括Image（内核）、rootfs.ext2、fw_jump.elf（OpenSBI）等。

如果你只是想快速验证一下交叉编译好不好使，可以先用发行版工具链做个最小测试：

cat > hello.c << 'EOF' #include <stdio.h> int main() { printf("hello riscv\n"); return 0; } EOF riscv64-linux-gnu-gcc -static -o hello hello.c file hello

输出显示ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV)就对了。static 编译是为了避免目标平台上没有动态库的麻烦。

3.3 内核配置：这一步决定实验台能不能跑 AI 负载

拿到一根能跑的 RISC-V Linux 内核只是起点。要让它成为"AI 芯片实验台"的内核，我必须打开一堆和向量扩展、性能监控、AI 加速相关的配置项。

我的做法是先以defconfig为基础，然后手动改几个关键选项：

make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- defconfig make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- menuconfig

在 menuconfig 里重点检查这几项：

• CONFIG_RISCV_ISA_V：必须打开，这是内核支持 RVV 向量扩展的总开关。内核编译本身不一定需要向量扩展，但运行时访问向量寄存器需要内核正确保存恢复上下文；
• CONFIG_FPU：一般默认开，但确认一下没错；
• CONFIG_VIRT_DRIVERS和CONFIG_VIRTIO_PCI：virtio 设备驱动，QEMU 虚拟 IO 的关键；
• CONFIG_DEVTMPFS和CONFIG_DEVTMPFS_MOUNT：系统启动时自动挂载 /dev，没有它容易出现启动后设备节点缺失的问题。

还有一个容易忽略的——CONFIG_STRICT_KERNEL_RWX。这个选项在部分 QEMU 机器上会和某些版本的 OpenSBI 有兼容性问题，如果启动到一半突然死机，可以先关掉试试。

配置完成后编译内核：

make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- -j$(nproc)

编译产物是arch/riscv/boot/Image，一个扁平的内核镜像，QEMU 直接认这种格式。如果想用 U-Boot，那就需要Image.gz或者 vmlinux，但 virt 平台可以绕过 U-Boot 直接启动，省一层麻烦。

3.4 rootfs：别再用 busybox 糊弄了，跑 AI 框架需要完整环境

如果你只是启动内核看个 shell，busybox 根文件系统就够了。但要跑 Python、PyTorch、ONNX Runtime 那套东西，busybox 完全不现实——它连 glibc 的动态链接都支持得不利索，更别说 Python 解释器了。

我这次用的是 buildroot 生成的 rootfs，然后在上面额外塞东西。buildroot 的qemu_riscv64_virt_defconfig默认生成的rootfs.ext2自带 busybox 和一些基础工具，作为一个"地基"非常好用。接下来你要做的，是把交叉编译好的 Python 和依赖全部塞进去。这个过程比较折腾，我后面专门讲。

另外提一句，buildroot 里其实可以勾选 Python3、PyTorch 等包（在Target packages→Interpreter languages和Libraries菜单里），但 PyTorch 这种重框架在 buildroot 里的支持不一定完整，版本也可能滞后。我采取的方案是：buildroot 只管系统环境和基础库，然后手动交叉编译 AI 框架，做精细控制。

4. 关键一步：让 Agent 帮你搞定繁琐的配置与排错

4.1 我如何给 Agent 分配任务

整个环境搭建最大的痛点不是某个单独的技术难，而是"步骤多、易错点分散"。Agent 在这里特别擅长做信息的收集和整合。我的用法是这样的：

首先，我把目标描述清楚："使用 QEMU 的 virt 机器，启动一个 RISC-V 64 位、支持 V 扩展的 Linux 系统，rootfs 是 buildroot 生成的，内核需要支持 virtio、ext4 和网络。请生成完整的启动脚本。"

然后，Agent 会给我一份可执行的 QEMU 命令，包含-machine virt、-cpu rv64,v=true、-kernel Image、-drive file=rootfs.ext2,format=raw,id=hd0、-device virtio-blk-device,drive=hd0、-netdev user,id=net0、-device virtio-net-device,netdev=net0这些关键参数。虽然这些参数我大致都知道，但让它一次性生成完整命令节省了回忆和查 man page 的时间。

更值钱的是排错环节。启动过程经常遇到内核 panic、设备树解析失败、文件系统挂载失败，这些日志又臭又长。我把日志丢给 Agent，让它帮我定位是哪个设备驱动出了问题，应该查哪个内核配置项。这比自己在几千行日志里 grep 效率高得多，而且效果不差——因为 QEMU 的常见问题在公开资料里都有答案，Agent 已经完全"读"过这些资料。

4.2 Agent 生成启动脚本的复盘

下面是我和 Agent 协作后的最终启动脚本，经过了我的修改，可以直接用：

qemu-system-riscv64 \ -M virt \ -cpu rv64,v=true,vlen=128 \ -smp 4 \ -m 4G \ -kernel Image \ -drive file=rootfs.ext2,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev user,id=net0 \ -device virtio-net-device,netdev=net0 \ -append "root=/dev/vda rw console=ttyS0" \ -nographic

逐条拆一下：

• -cpu rv64,v=true,vlen=128：打开向量扩展，向量寄存器长度 128 位。这是实验台能不能做 AI 计算的关键，我踩过坑之后每次都会确认这个参数；
• -smp 4：4 个虚拟核。虽然 QEMU 的 SMP 是模拟出来的，但对于跑多线程推理负载、验证并行性能基线有意义；
• -m 4G：4G 内存。跑 PyTorch 这类框架，2G 以下会非常局促；
• -device virtio-blk-device,drive=hd0：virtio 块设备。我特意不用-drive if=virtio那种老写法，显式指定 device 类型更清晰；
• -netdev user,id=net0+-device virtio-net-device,netdev=net0：用户态网络，虚拟机能通过宿主机的网络栈访问外网，不需要额外的网卡设备权限；
• -nographic：纯串口控制台，不走图形界面，方便在 SSH 会话里操作。

启动成功的标志是串口输出到buildroot login:，然后就能通过 root 账户（默认无密码）登录系统。进去后第一件事：

cat /proc/cpuinfo

看到isa : rv64imafdcv或者类似包含v的字符串，就说明向量扩展生效了。

4.3 让 Agent 生成 AI 验证用例：矩阵乘法和向量汇编

实验台立起来之后，光能开机不算完，得证明它真能跑 AI 相关负载。我让 Agent 生成了一套验证用例，分三个层次。

第一层是向量指令功能验证。直接在 C 里嵌入向量汇编，算一个简单的向量加法。用 RVV 的汇编能直观地确认 CPU 的向量单元工作正常：

#include <stdio.h> int main() { int v1[4] = {1, 2, 3, 4}; int v2[4] = {5, 6, 7, 8}; int v3[4] = {0, 0, 0, 0}; asm volatile ( "vsetivli zero, 4, e32, m1, ta, ma\n" "vle32.v v0, (%0)\n" "vle32.v v1, (%1)\n" "vadd.vv v2, v0, v1\n" "vse32.v v2, (%2)\n" : : "r"(v1), "r"(v2), "r"(v3) : "memory" ); for (int i = 0; i < 4; i++) { printf("%d ", v3[i]); } printf("\n"); return 0; }

编译时注意加-march=rv64gcv，不然编译器不知道目标 CPU 支持向量指令：

riscv64-linux-gnu-gcc -march=rv64gcv -static -o vec vec.c

在虚拟机上跑出6 8 10 12就说明向量存储和计算链路是通的。

第二层是经典矩阵乘法。用纯 C 写一个 256x256 的矩阵乘，作为一个性能基线。第三层是装 Python 和 PyTorch，跑一个 MobileNet 或者 ResNet 的分类推理，这是最接近真实 AI 芯片负载的验证。后面我会单独讲 PyTorch 的交叉编译，这是整个实验台搭建里最掉头发的一步。

5. 在虚拟实验台上跑 AI 框架：PyTorch 的交叉编译与部署

5.1 为什么不能直接 pip install

很多人在这一步会天真地以为，进到 RISC-V 虚拟机的 Linux 里，就能直接 pip install torch。结果是惨不忍睹的——PyTorch 的官方 pip 包根本没有 RISC-V 的预编译 wheel，pip 会尝试从源码编译，然后因为缺少各种依赖或者编译器不支持特定指令集而失败。

正确做法是交叉编译或者用第三方维护的构建脚本。RISC-V 社区其实有人专门做这件事，比如riscv-software-src下面就有针对 RISC-V 的工具链支持和部分软件包维护。但我实测下来最可靠的方式是：在宿主机上用交叉编译链把依赖全部编译成 RISC-V 版本，然后拷进虚拟机的 rootfs 里。

这个方案的依赖链条很长：OpenBLAS（做底层矩阵运算）、Python 3.x、NumPy、PyTorch 自身。每一步交叉编译都可能出幺蛾子，也是 Agent 发挥作用的地方。

5.2 编译 OpenBLAS 做底层加速

PyTorch 在 CPU 上的性能很大程度上依赖 BLAS 库。对于 RISC-V，OpenBLAS 有相对成熟的移植，支持 RVV。交叉编译命令大致如下：

git clone https://github.com/xianyi/OpenBLAS cd OpenBLAS make CC=riscv64-linux-gnu-gcc \ HOSTCC=gcc \ TARGET=RV64G \ CFLAGS="-march=rv64gcv -O2 -fPIC" \ -j$(nproc)

注意TARGET=RV64G很重要，OpenBLAS 需要知道你编译的目标架构才能选择正确的 kernel。编完后会生成libopenblas.a和libopenblas.so，后续编译 PyTorch 时指定这个库的路径。

这块我踩过坑：OpenBLAS 默认会检测宿主机的 CPU 并生成对应的优化 kernel，交叉编译时必须显式指定TARGET，否则编出来的库在 RISC-V 上根本跑不起来。Agent 第一次给我的命令就把TARGET漏了，编译出来的库一测就崩，排查半天才发现。

5.3 交叉编译 Python 与 NumPy

PyTorch 的交叉编译极其复杂，我的建议是分两步：先用 buildroot 辅助生成一个基础 Python，然后用宿主机交叉编译 PyTorch 时链接到这个 Python 的共享库上。

我自己反复试过很多次，最终选了这么一条更省力的路：直接在 buildroot 里勾选 Python3 和 PyTorch 相关的选项。虽然版本可能不是最新的，但 buildroot 把交叉编译的依赖问题全部处理好了。配置菜单路径是Target packages→Interpreter languages→python3，以及Target packages→Libraries→pytorch。

当然，buildroot 的 PyTorch 包有时候编译不过去，尤其是新版 buildroot 对 PyTorch 的依赖处理和上游版本更新之间存在时间差。如果你遇到编译失败，Google 一下 buildroot 邮件列表或者 issue tracker，通常有人已经给出 workaround。实在不行就换一个版本的 buildroot，或者退回用宿主机交叉编译。

5.4 实操验证：在 RISC-V 虚拟机上跑一次推理

把编译好的 Python + PyTorch 拷贝进虚拟机的 rootfs 后，我写了一个最小化的推理验证脚本：

import torch import torch.nn as nn class SimpleNet(nn.Module): def __init__(self): super().__init__() self.fc = nn.Linear(8, 2) def forward(self, x): return self.fc(x) model = SimpleNet() x = torch.randn(1, 8) y = model(x) print(y)

在虚拟机上运行：

python3 test_torch.py

看到正常输出一个[1, 2]形状的 tensor 就说明 PyTorch 已经可以在 RISC-V 实验台上跑起来了。这个验证的意义在于：它证明了你手上的这套 QEMU 模拟环境，已经具备了作为 AI 芯片软件栈开发平台的基本能力。后续你想验证新算子、调试量化算法、测试编译器的向量生成能力，都可以在这个环境里做。

6. 常见问题与排查技巧实录

6.1 启动卡住，串口没有输出

最常见的现象是qemu-system-riscv64跑起来后，终端一片空白，既不报错也没有任何输出。优先怀疑三个点：

• 内核参数没写console=ttyS0。RISC-V virt 平台的标准控制台是串口，不指定的话内核不知道往哪输出；
• 缺少-bios参数。如果你没有提供 firmware，需要确保 QEMU 能找到默认的 OpenSBI。如果用源码编译且没装 OpenSBI，可以先用-bios none跳过固件直接启动内核，很多情况下这是最快的排除方法；
• 内存太小导致内核解压失败。给 512M 以下内存跑现代 RISC-V 内核很容易在早期就挂掉，建议至少 1G 起步。

6.2 报错guest has not initialized the display

这个通常是因为没加-nographic但又没有图形界面环境。解决办法就是明确用-nographic模式跑，并且去掉所有 display 相关参数。

6.3 rootfs 挂载失败VFS: Unable to mount root fs

几乎都是 root 设备名对不上。QEMU virt 平台的 virtio 块设备在 Linux 里是/dev/vda，如果你写的启动参数是root=/dev/sda，那就必然挂载失败。另外确认一下 rootfs 的镜像格式，buildroot 生成的.ext2用format=raw即可，但如果你自己做了 ext4 之类的变更，QEMU 的 drive 参数也要对应调整。

6.4 进入系统后不能联网

-netdev user模式默认就带 DHCP 和 NAT，但不代表虚拟机内部一定会自动配置网卡。进去后先确认有没有eth0设备：

ip link

如果没有，多半是内核没有编入 virtio-net 驱动。检查一下CONFIG_VIRTIO_NET是否打开，以及CONFIG_VIRTIO_PCI。设备树能识别到设备，但内核没有对应驱动的话，lspci一样看不到。

6.5 向量指令执行报 Illegal Instruction

要么是 CPU 参数没加v=true，要么是编译器生成的指令超出了目标支持的版本。注意旧版 QEMU 可能只支持向量扩展草案，而不是 1.0 最终版；如果你的编译器默认生成 1.0 指令，就可能出现非法指令。解决办法是升级源码版 QEMU，并确保-cpu参数正确开启 V 扩展。

6.6 Agent 给的命令报错怎么办

这是我最想强调的一点：现在用 Agent 搭环境的人越来越多，但 Agent 给你的命令并不总是对的。遇到报错不要慌，也别直接换下一个命令——把报错信息原封不动地喂回给 Agent，它会自我修正的。实际上，Agent 帮我解决的最难一个问题就是"为什么 OpenBLAS 交叉编译后在 RISC-V 上 segfault"。

7. 实验台的扩展方向：从模拟到接近真实芯片

既然这个题目叫"AI 芯片的实验台"，那它不能只是一个能跑 Linux 的 QEMU 虚拟机。我觉得至少要往这几个方向扩展，才能名正言顺地当实验台用。

第一个方向是接入自定义加速器模型。QEMU 支持通过 QOM（QEMU Object Model）添加自定义设备。如果你有自己设计的 AI 加速器 RTL 或者 C 模型，可以把它封装成 QEMU 设备，挂到 virt 平台上。这样软件工程师可以提前写驱动，编译器团队可以验证自定义指令的生成，整个软件栈不需要真实硬件就能跑通。

第二个方向是精确的性能建模。QEMU 默认是功能模拟，不模拟时序，所以你测到的"性能"跟真实芯片差距很大。要做准确的性能基线，需要给 QEMU 加周期级别的模拟能力。QEMU 社区已经有一些 patch 在做这方面的工作，比如在模拟器中插入计时器和缓存模型，但成熟度还不够。如果你是认真做芯片软件优化的，可能需要研究一下。

第三个方向是把实验台接上持续集成。QEMU 是命令行工具，非常适合跑自动化测试。我建议把整套环境封装成 CI 脚本，每次代码变更自动启动 QEMU、跑测试用例、生成报告。RISC-V 社区很多项目就是这么干的——你提交一个代码，CI 系统里的 QEMU 就会拉起一个虚拟机帮你跑测试矩阵。

我自己目前的扩展计划是这样的：第一步先把 RVV 1.0 的完整测试套件跑起来，我指的是 RISC-V 官方维护的riscv-tests里的 vector 测试用例。第二步是把一个轻量级的 YOLO 检测模型用 ONNX Runtime 跑起来，看看整个推理链路还缺什么。第三步是尝试在自己的 QEMU fork 里挂一个简单的硬件加速器模型，验证软件栈的可扩展性。

8. 写在最后的几个建议

如果你打算照着这篇文章的思路搭自己的实验台，我个人的经验是"不要先追求大而全"。一开始就跑 PyTorch 非常容易劝退自己，因为交叉编译的坑太多，每一个坑都能耗掉你一个晚上。

我建议的路径是：先把 QEMU 启动到控制台，这一步必须走通，它验证了你的工具链、内核配置和 rootfs 是基本没问题的。然后加一个简单的 C 向量程序，确认 RVV 生效。再往后，用 buildroot 一点点把 Python 环境和依赖加进去，每加一个依赖就测试一次，不要攒一堆问题再排查。

关于 Agent，我的体会是它最大的价值不是给你一个"完美答案"，而是在你手足无措时给你一个"合理的下一步"。很多 QEMU 和 RISC-V 的问题在网络上有零散的回答，Agent 能把这些信息聚合起来变成可执行的命令。但你依然需要理解这些命令背后的原理——真要排查问题的时候，还是得回到文档和源码里去。

最后分享一个小技巧：给 QEMU 加上-d guest_errors参数再启动，在排错阶段能看到很多被吞掉的错误信息。这个参数我几乎每次调试都会带，帮我定位过设备树错误和内存映射冲突，是目前我找到的性价比最高的 QEMU 调试参数。这套实验台搭好之后，接下来的 AI 芯片软件栈相关工作，我都打算在这个环境上做了。