RISC-V AI 加速：开放指令集之后，难的是系统协同

RISC-V 的吸引力在于开放与可扩展：团队可以增加向量、DMA、自定义加速指令，而不必接受封闭指令集。但“可扩展”也意味着软件栈必须承担更多组合复杂度。

Many-tiny-core 的经验

许多小核可以降低单核复杂度，却把问题推向共享内存和同步。论文中的 many-tiny-core 平台使用 SIMD 浮点流、指令重复和专用 DMA 来减少主存访问，并实现分布式 softmax 等原语。

这说明 RISC-V AI 的优化不是单独一条 ISA 扩展，而是：

算法分块 -> DMA 调度 -> 片上数据复用 -> 多核同步 -> 编译器映射

任何一环缺失，峰值算力都无法兑现。

全栈评测

gem5 与 MLIR 工具链的评测工作提醒我们：硬件模拟器、编译器 lowering 和运行时调度都会改变结论。一个内核在仿真中快，不代表在板卡上快；一个模型能编译，不代表所有算子都高效。

RVA23 的作用

RVA23 为应用处理器提供较稳定的向量与系统基线，有利于操作系统和通用软件生态。但 AI 推理还依赖张量布局、量化指令和内存带宽。RVA23 是起点，不是加速器设计。

RISC-V Roofline 实验 比较峰值算力、有效带宽和算术强度。先用它判断瓶颈方向，再讨论是否需要更多核心或专用 NPU。

开放 ISA 不等于开放性能

RISC-V 规范定义的是指令语义和扩展机制，不规定流水线深度、缓存层级、向量单元宽度、DMA 引擎或片上互连。两个都宣称支持 RVV 的处理器，可能在向量吞吐、内存一致性、循环启动和编译支持上完全不同。因此，选型时不能只记录“支持 RISC-V”，还要记录具体扩展、微架构和软件版本。

对 AI 负载，至少要把能力分成四层：

层次	需要回答的问题
ISA	是否有向量、位操作、浮点/量化指令？是否支持 RVA23 基线？
微架构	发射宽度、向量长度、load/store 带宽、缓存与 TCM 容量
加速器	NPU 是独立单元、协处理器还是自定义指令？数据如何进入片上？
软件栈	编译器能否稳定 lowering？运行时是否支持目标算子与动态形状？

开放扩展降低了试验硬件设计的门槛，却把组合验证责任交给系统团队。一个自定义矩阵指令可能在孤立 kernel 中很快，但若没有对应算子库、量化格式和调试工具，最终项目会被维护成本拖住。

Many-tiny-core 的真实难点

许多小核的优势是面积和能效：在低电压、低频率下并行工作，避免单个超大核的功耗墙。论文中的平台把核心组织成可共享数据的阵列，并用专用 DMA、SIMD 浮点流和分布式原语减少主存往返。这个方向的价值在于“数据流优先”，而不是简单把核数从 8 增加到 128。

以一次矩阵乘为例，若每个核独立从共享 DDR 读取同一块权重，增加核心会近似线性提高总线压力。若权重先被广播到共享 SRAM，再从本地 tile 复用，带宽增长会慢得多。若 softmax 或归约需要跨核同步，同步开销又会随核心数和通信拓扑增长。

所以 many-tiny-core 需要一个分层执行模型：

全局任务拆分
  -> 大块数据 DMA 到共享 SRAM
  -> 每核读取本地 tile
  -> 本地向量计算
  -> 分层归约 / 同步
  -> 结果合并写回

在这条链中，DMA 不是外围装饰，而是决定重叠程度的核心部件。理想情况下，下一块数据在计算当前块时预取；若 DMA 与计算共享同一端口，或者 cache 一致性需要软件维护，重叠效果会下降。

全栈评测为什么重要

论文中的全栈评测工作覆盖模型、编译器和 ISA 模拟，而不是只跑一个手写 kernel。这是正确的方向，因为 AI 编译器在 lowering 过程中会改变数据布局、循环顺序、向量化和融合策略。一个模型在 PyTorch 图中看起来只有矩阵乘，落到目标后端后可能被切成大量小 kernel，每个 kernel 都有启动、同步和边界处理成本。

MLIR 等多层中间表示提供了优化机会，也带来新的验证面：算子是否被正确映射、量化语义是否保持、内存分配是否符合目标限制、模拟器是否准确建模了 cache 和 DMA。只比较仿真器的周期数，容易把“编译器尚未支持”误判为“硬件不适合”。

评估报告应至少包含：

• 模型版本、权重精度与输入形状；
• 编译器、运行时、驱动和 ISA 扩展版本；
• 是否使用 SIMD、向量长度和线程/核心数；
• 权重与激活的放置层级；
• 是否启用 DMA、双缓冲和算子融合；
• 模拟与实板结果分别是什么。

RVA23 是生态基线，不是 AI 保证

RVA23 为应用级 RISC-V 处理器提供更稳定的系统与向量功能集合，有利于操作系统、运行时和通用软件形成可移植目标。它解决的是生态碎片化，不是自动解决 AI 的矩阵布局和低精度计算。

一个符合 RVA23 的 CPU 可能适合边缘控制、网络和通用计算，却未必比专用 NPU 更适合大模型推理。反过来，只支持自定义 AI 加速指令的设备可能跑分很高，却难以运行完整 Linux 软件栈。选型的核心是让 ISA 基线与任务需求匹配，而不是追逐“最开放”或“最高峰值”。

用 Roofline 做第一道筛选

Roofline 把算力和带宽放在同一张图。对每个算子或模型块，先估算算术强度 $I$，再计算硬件拐点：

$$I_{\text{ridge}} = \frac{P_{\text{peak}}}{BW_{\text{eff}}}$$

若 $I < I_{\text{ridge}}$，提升峰值算力的收益有限，应优先改善数据复用、缓存、DMA 和算子融合。若 $I > I_{\text{ridge}}$，再考虑提高向量利用率、增加核心或换更强 NPU。

这只是第一道筛选。真实系统还要考虑尾延迟、功耗、热和编译器质量。对端侧设备，持续性能往往由热设计决定；对多核共享内存系统，同步和一致性可能比理论带宽更早成为瓶颈。

失败边界

RISC-V AI 项目常见失败包括：

• 只验证单个矩阵 kernel，没有验证完整模型和动态形状；
• 向量单元很强，但 load/store 带宽不足；
• 核数增加后，共享总线饱和，尾延迟反而上升；
• 编译器把量化算子回退到标量路径；
• 模拟器忽略 cache miss、DMA 启动和同步成本；
• 依赖私有扩展，升级工具链后无法复现。

一个负责任的结论应该描述“在什么模型、什么数据布局、什么软件版本下，RISC-V 平台的哪一部分收益来自 ISA，哪一部分来自微架构，哪一部分来自专用加速器”。只有拆开这三层，才能判断方案能否迁移到下一个产品。

编译器 lowering 的实际影响

AI 模型进入 RISC-V 设备之前，通常要经过图优化、算子选择、量化重写、循环分块和向量化。即使硬件支持某个扩展，编译器也可能因为缺少 pattern、动态 shape 或精度不匹配而退回到标量实现。一个高效的算子库应该覆盖常见模型，但新模型仍会出现未支持的组合。

选择平台时，可以要求供应商演示三类 lowering：

• 标准矩阵乘与卷积如何映射到向量/NPU；
• softmax、layernorm 和归约如何跨核同步；
• 动态 batch 或变长序列如何处理。

若团队无法解释这些路径，性能移植就只能靠逐算子调优。长期维护成本会高于一次硬件采购成本。

内存一致性与安全隔离

many-tiny-core 系统通常有 scratchpad、共享 SRAM、TCM 和外部 DDR 多个层级。共享数据需要明确协议：由谁写、何时可见、是否需要 fence、cache 如何刷新。缺少一致性时，计算快的核可能读到旧数据；使用全局锁又可能把并行变成串行。

安全隔离也会影响数据流。不同模型、租户或安全域之间可能需要内存保护、DMA 地址窗口和 IOMMU。若加速器能访问任意物理地址，一条恶意描述符就可能读出密钥区。安全机制必须覆盖数据搬运路径，而不只是 CPU 指令。

功耗与热

RISC-V 的能效优势常来自低电压、低频率和简单核心，但把多个核心、向量单元和 NPU 同时开启后，峰值功耗可能超过封装散热能力。持续推理的可持续算力往往低于短时峰值。设计报告应同时给出：

指标	需要回答的问题
峰值算力	在何种频率、电压和温度下达到？
持续算力	热稳定后还能维持多少？
空闲功耗	是否适合间歇推理设备？
唤醒延迟	从低功耗状态到首个 token 的时间？
能量/任务	完成一次真实请求需要多少焦耳？

这比单一 TOPS 数字更接近部署决策。对电池设备，唤醒和静态功耗甚至可能比峰值性能更重要。

一张最小验收矩阵

维度	最小测试
模型	摘要、问答、视觉或领域模型各一个
形状	batch 1、batch 16、短序列、最大上下文
算子	矩阵乘、注意力、softmax、量化、动态控制
硬件	单核、全核、不同频率与电压
软件	编译器版本、运行时、线程数、DMA 开关
环境	低温、热稳定、输入中断、共享总线

若平台只在单一 demo 上表现好，不能证明通用性。RISC-V 的开放生态意味着组合很多，也意味着必须把测量条件写清楚。

团队还应维护一个“不可移植特性”清单：哪些性能来自私有扩展，哪些依赖特定编译器版本，哪些只能在固定 shape 下成立。迁移到下一代芯片时，这份清单比峰值 benchmark 更能预测风险。

一个可移植的软件基线至少要覆盖 C/C++ 编译器版本、RVA23 配置、向量长度、操作系统和数学库。把这些条件写进基准记录，才能区分“芯片更快”和“编译器更适配”。如果某个结果只能在自定义扩展上出现，就应将它标为平台特性，而不是通用 RISC-V 结论。

最终评估应同时展示工具链版本、可用扩展、数据移动模型和完整模型延迟。只看峰值 TOPS，无法判断 RISC-V 平台能否承担真实推理负载。

把软件基线当作硬件的一部分来验收，才能避免“芯片能跑、系统却不好用”的常见落差。

如果供应商只提供峰值算力和 kernel demo，应要求补充完整模型、内存带宽、编译器版本和失败回退证据。没有这些条件，RISC-V 加速器的真实可用性仍然未知。

同样重要的是持续集成：每次工具链或内核更新都应重跑精度、延迟和内存回归。开放 ISA 带来组合自由，也意味着团队必须自己承担兼容性验证责任。

可移植性不是一句宣传语，而是一套持续运行的回归证据。

如果无法给出可重复的软件基线，开放 ISA 带来的选择自由也会变成维护负担。

把工具链与硬件分开评估，才能看出性能提升究竟来自架构还是编译器适配。

这也是建立可重复软件基线最重要的现实理由。

只有把工具链、算子覆盖和硬件配置写入回归记录，峰值性能才具有可比较的工程意义。