瑞萨RA8P1嵌入式AI开发四部曲之Arm Vela编译器

Vela是什么？让Ethos-U55多快的秘密全在这里

解锁Ethos-U55的极致推理性能

本文承接第一篇的RUHMI实战，重点进入Arm Ethos-U Vela编译器。相比“模型能不能跑起来”，本篇更关注“模型是否真正高效地跑在NPU上”：哪些算子被映射到Ethos-U55，哪些算子发生CPU fallback，以及内存模式如何影响最终推理延迟。

Vela是什么：一句话定位

Vela可以理解为Arm Ethos-U NPU的后端编译器。它接收已经量化的.tflite模型，结合目标NPU类型、系统内存配置和优化参数，生成包含NPU command stream的优化模型，并输出算子映射、CPU fallback、内存占用和性能估算等报告。

• 哪些算子真正映射到了Ethos-U55 NPU？

• 哪些算子发生了CPU fallback？

• 当前内存模式和存储配置是否会影响最终推理延迟？

也正因为如此，理解Vela之前，需要先理清它和RUHMI、MERA、Runtime以及Ethos-U driver之间的关系。

RUHMI、MERA、Vela到底谁负责什么？

在RA8P1 Ethos-U55平台上，模型部署并不是由某一个工具独立完成的，而是由模型转换、图优化、后端编译、运行时调度和NPU驱动协同完成。第一次接触RUHMI、MERA、Vela和Ethos-U driver时，最容易困惑的往往不是命令怎么写，而是它们各自负责哪一段流程、彼此之间如何衔接。

完整推理软件栈：从模型到NPU执行

AI Model（.tflite / 量化后的INT8模型）

↓

Arm Vela Compiler ←—— 本文重点

↓

Optimized Model（.tflite，含NPU command stream）

↓

TFLM / Runtime（推理运行时）

↓

Ethos-U driver（NPU驱动）

↓

Ethos-U55 NPU Hardware（RA8P1片内）

如果需要进一步查看Ethos-U软件栈和Vela源码，可以参考Arm官方仓库。

ethos-u · GitLab

ethos-u · GitLab

https://gitlab.arm.com/artificial-intelligence/ethos-u

artificial-intelligence / ethos-u / Vela · GitLab

artificial-intelligence / ethos-u / Vela · GitLab

https://gitlab.arm.com/artificial-intelligence/ethos-u/ethos-u-vela

注意：

Vela与Ethos-U driver存在版本匹配要求。实际工程中，建议保持编译器、运行时和驱动版本一致，避免出现模型可以编译但运行异常的问题。

一句话看懂工具链关系

可以把整个流程理解成一条分工明确的流水线：RUHMI负责把部署流程变得易用，MERA负责模型编译与优化，Vela负责面向Ethos-U NPU生成后端执行内容，而Runtime和Ethos-U driver负责在板端完成调度和执行。

RUHMI

工程师最直接接触的入口

无论使用AI Navigator图形界面，还是使用命令行，RUHMI都负责把模型转换、代码生成和工程集成流程包装成更容易操作的形式。

MERA

RUHMI背后的核心编译引擎

主要负责模型解析、图优化和代码生成，并支持来自TFLite、ONNX、PyTorch等不同来源的模型。

Vela

Arm官方提供的Ethos-U NPU后端编译器

它的任务更聚焦：把适合NPU执行的子图编译成Ethos-U可以识别的command stream（命令流），并输出算子映射、内存占用和性能估算等信息。

因此，在常规RUHMI--npu流程中，工程师通常不需要手动调用Vela。它会在后台参与编译过程。只有当需要进一步分析算子映射、CPU fallback、内存使用或推理性能时，才需要单独使用ethosu-vela进行深入调优。

简单总结：RUHMI让部署流程更容易上手，MERA负责模型编译与优化，Vela负责生成面向Ethos-U NPU的执行内容，Runtime和Ethos-U driver负责在板端把这些内容真正跑起来。理解这层分工后，再看后面的参数配置和性能调优，就会清晰很多。

有了这层分工之后，再看完整推理软件栈就会更直观：量化模型先经过Vela编译，生成包含NPU command stream的优化模型；随后由Runtime加载和调用模型，再通过Ethos-U driver把可加速部分调度到RA8P1片内Ethos-U55 NPU上执行。

下面这张流程图可以把上述关系再串起来：从模型导入、编译优化，到生成部署产物，再到板端运行和性能分析，每一层工具都承担不同角色。

点击可查看大图

能力模块 01

模型编译转换

说明：输入.tflite（INT8量化），输出含NPU命令流的优化.tflite。

能力模块 02

Graph Partition

说明：自动划分哪些算子在NPU执行，哪些算子发生CPU fallback。

能力模块 03

Operator Mapping

说明：将支持的算子映射到Ethos-U55硬件指令。

能力模块 04

Memory Optimization

说明：优化SRAM/外存使用，减少数据搬运开销。

能力模块 05

性能估算报告

说明：输出CSV报告：算子映射、内存使用、延迟估算和CPU fallback分析。

输入/输出	更适合处理的任务
输入	.tflite模型文件（必须已量化为INT8或INT16）
.ini配置	系统配置文件（NPU型号、内存架构、带宽）
输出1	优化后的.tflite模型（含NPU command stream）
输出2	性能分析CSV报告（算子映射、SRAM占用、延迟估算）

Vela使用详解（实战操作）

基本命令

左右滑动查看完整内容

# 基本使用：编译模型
vela model.tflite


# 指定输出目录
vela model.tflite --output-diroutput/


# 生成详细报告（算子映射 内存使用 延迟估算）
vela model.tflite --verbose-all

指定NPU配置（RA8P1必须项）

RA8P1搭载的Ethos-U55为256 MAC版本，编译时必须明确指定：

左右滑动查看完整内容

# RA8P1必须使用 ethos-u55-256
velamodel.tflite --accelerator-config ethos-u55-256


# 常见Ethos-U55配置（MAC数越大算力越强）：
# ethos-u55-32 ethos-u55-64 ethos-u55-128 ethos-u55-256

内存配置（关键调优参数）

内存配置是影响推理延迟最大的参数之一，直接决定激活值和模型权重放在哪里：

左右滑动查看完整内容

# RA8P1推荐配置：片内SRAM（低延迟）
velamodel.tflite
  --system-config RA8P1
  --memory-mode Sram_Only


# 内存模式说明：
# Shared_Sram   -> 片内SRAM与CPU共享，
# Dedicated_Sram -> 注意：Ethos-U55 不支持该内存模式，RA8P1 不要使用。
# Sram_Only    -> 全部数据在SRAM，适合小模型（RA8P1推荐）

对比维度	Sram_Only	Shared_Sram
模型权重与命令流	全部放在片内SRAM中，访问路径最短。	权重可放在Flash中，减轻SRAM压力。
激活张量	放在片内SRAM，适合追求最低延迟。	同样放在片内SRAM，保证运行时数据访问效率。
性能表现	通常最快，适合小模型和性能优先场景。	速度相对较慢，主要受权重从Flash读取影响。
SRAM占用	占用较大，模型、命令流和激活值都需要SRAM空间。	SRAM占用更省，适合模型较大或片内存储紧张的场景。
选型建议	如果模型能放进SRAM，优先选择它来获得最低延迟。	如果模型较大、需要放到Flash，则选择它在容量和性能之间折中。

完整RA8P1推荐命令

左右滑动查看完整内容

# 完整RA8P1推荐编译命令
vela model_int8.tflite
 --accelerator-configethos-u55-256
 --configra8p1.ini
 --system-configRA8P1 
 --memory-modeSram_Only 
 --optimisePerformance 
 --output-dir./vela_output 
 --show-cpu-operations
 --verbose-all

关键调优参数速查表

参数	含义与RA8P1推荐配置
--accelerator-config ethos-u55-256	RA8P1上的Ethos-U55为256 MAC版本，必须指定。
--config ra8p1.ini	.ini配置文件用于描述MCU平台的内存带宽、时钟和内存布局等信息，必须指定。
--system-config RA8P1	指定使用RA8P1系统配置，必须指定。
--memory-mode Sram_Only	将模型相关数据尽量放在片内SRAM，通常可获得更低延迟，但会增加SRAM占用。
--optimise Performance	优化目标为推理性能（默认值）。
--output-dir ./vela_output	指定输出的目标文件路径。
--show-cpu-operations	显示发生CPU fallback（回退到CPU执行）的算子。
--verbose-all	生成详细日志。

注意：

Vela 5.0.0开始引入Regor编译机制。如果需要沿用Vela 4.x中的传统Python编译路径，可添加--debug-force-legacy-core参数。

调试与问题分析

如何读懂Vela报告

报告项目	含义与关注点
NPU utilization	NPU执行时间占比，目标>80%
CPU fallback ratio	CPU fallback比例，表示回退到CPU执行的算子占比，目标<20%
SRAM usage	片内SRAM使用量，必须小于RA8P1可用量（约1.5~2MB）
Cycle estimation	预估推理延迟（cycle数）

以上篇MNIST手写数字识别模型为例，经过Vela转换后的结果如下图所示：

(该模型结构对Ethos-U55非常友好，算子全部映射到NPU执行，不存在CPU fallback 带来的切换开销。)

点击可查看大图

如下图所示，通过--show-cpu-operations参数可以查看算子部署情况，明确哪些算子发生CPU fallback。

点击可查看大图

常见问题排查

问题现象 01

模型没有跑在NPU（全CPU执行）

排查方向：

1. 检查模型是否为INT8量化

2. 检查算子是否在支持列表（见附录）

3. 确认--accelerator-config参数正确

问题现象 02

性能提升不明显

排查方向：

1. 带宽受限：检查模型权重存储位置

2. 检查是否存在大量CPU fallback算子。

3. 检查内存布局是否合理，包括权重、命令流和激活缓冲区的位置。

问题现象 03

SRAM使用量超限

排查方向：

1. 减小输入尺寸

2. 使用更激进的量化

3. 考虑Layer-by-Layer推理

关键经验：减少CPU fallback

如果Vela报告显示大量算子发生CPU fallback，推理性能会显著下降。常见原因包括：

1. 模型包含Ethos-U55不支持的算子（查阅附录支持算子表）

2. 模型未正确量化（需为INT8而非FP32/FP16）

3. 某些算子的参数超出NPU硬件限制（如kernel size过大）

解决思路：在训练/导出阶段调整模型结构，替换不支持的算子层。

附录：算子支持查询方式

完整算子支持列表较长，正文中不再展开。实际项目中，建议以官方operator_support文档和Vela编译报告为准：先确认模型是否为量化模型，再检查关键算子是否满足Ethos-U映射约束；如果报告中出现大量CPU fallback，通常需要回到模型结构或导出配置进行调整。

算子支持

https://github.com/renesas/ruhmi-framework-mcu/blob/main/docs/operator_support.md

小结

通过本文，我们已经从Vela的基本定位、完整推理软件栈、常用命令、关键参数配置，到CPU fallback分析和内存模式选择，系统梳理了如何让Ethos-U55 NPU真正发挥性能。

可以说，第一篇解决的是“如何把模型跑起来”，而本篇进一步回答了“如何让模型更高效地跑在NPU上”。但在真实项目中，推理性能并不只由NPU算力决定。即使模型已经成功映射到Ethos-U55，如果模型权重、命令流和激活缓冲区放置不合理，数据搬运和存储带宽仍然可能成为新的瓶颈。

下一篇，我们将继续从工程落地角度出发，重点讨论RA8P1上模型存储介质的选择与优化，看看MRAM、SRAM、OSPI Flash和SDRAM应该如何分工，才能让RA8P1 AI推理速度再上一个台阶。

• ARM ARM 关注

  关注

  135

  文章

  9694

  浏览量

  400366