ExecuTorch 新增 Arm Cortex-M CPU 后端，PyTorch 模型可直接部署到微控制器

PyTorch：Blog· RJ Ascani (Meta), Adrian Lundell (Arm), Siddartha Pothapragada (Meta), Digant Desai (Meta), Zingo Andersen (Arm), Måns Nilsson (Arm), Erik Lundell (Arm)·2026-10-15 22:40· 34 分钟前AI 评分57

将 ExecuTorch 引入 Arm Cortex-M CPU

AI 导读

PyTorch 官方与 Arm 合作宣布 ExecuTorch 的 Cortex-M 后端，使 PyTorch 模型无需转换为其他框架格式即可直接运行在 Arm Cortex-M CPU 上，并利用 CMSIS-NN 加速，单一工作流支持 Scalar、DSP 和 MVE/Helium 全部能力层级。

正文

TL;DR

• 在微控制器上部署 PyTorch 模型历来需要转换为其他框架格式、维护独立的工具链，并调试跨框架的数值不匹配问题。ExecuTorch 完全消除了这一转换步骤。
• Cortex-M 后端使 PyTorch 模型能够借助 Arm CMSIS-NN 加速直接在 Arm Cortex-M CPU 上运行。它通过单一工作流支持所有能力层级（Scalar、DSP 和 MVE/Helium）。
• 我们在 Alif Ensemble E8 上对 MLPerf Tiny 套件中五个模型中的四个进行了基准测试。每个模型在单个 Cortex-M55 核心上运行时间不超过 21.5 ms，且使用的 RAM 低于 90 KiB。
• 对于异构 SoC，Cortex-M 后端还提供了与 Ethos-U NPU 委托并行的 CPU 执行路径。
• 极小的二进制体积。ExecuTorch 核心运行时占用不到 20 KiB 的闪存，而算子选择性构建仅链接模型所需的算子，因此总代码大小随模型而非框架扩展。

背景

微控制器驱动着数十亿台常开设备：可穿戴设备、工业传感器、语音接口和智能家电。这些设备在极端约束下运行：通常 SRAM 不足 1 MB，闪存仅为个位数兆字节，功耗预算以毫瓦计。尽管存在这些限制，在这些平台上运行有意义的 ML 工作负载的需求仍在增长，硬件也在不断演进以满足这一需求。现代基于 Cortex-M 的微控制器单元（MCU）现已包含 DSP 和向量 ISA、大型紧耦合存储器（TCM），以及诸如 Arm Ethos-U NPU 等高能效 NPU，使 ML 推理在资源受限设备中更加实用。

迄今为止，在 Cortex-M 上部署 ML 意味着要离开 PyTorch 生态。开发者不得不将模型转换为其他格式，为训练和部署维护独立的工具链，并调试转换过程中引入的数值不匹配问题。对于使用 PyTorch 训练的团队——在顶级 ML 会议上发表的研究代码中，PyTorch 占比超过 90%——这一转换步骤为每个迭代周期都增加了摩擦。

ExecuTorch 正是为消除这一鸿沟而设计的。Arm MCU 支持此前已通过 Ethos-U NPU 提供，而 Cortex-M 后端将其扩展到 Cortex-M CPU，因此模型既可在带加速器的部件上运行，也可在不带加速器的部件上运行。训练好的 PyTorch 模型在与移动端、桌面端和服务器端模型相同的技术栈内完成导出、量化和针对设备的 lowering。

Cortex-M 后端

ExecuTorch Cortex-M 后端通过提前编译器 pass，将标准 PyTorch 算子替换为由 CMSIS-NN 支持的自定义算子。在推理时，这些算子直接调用 Arm 的 CMSIS-NN 库，这是一个面向 Cortex-M 处理器的开源优化神经网络内核集合。

关键特性：

• CMSIS-NN 加速。量化操作（线性、卷积、加法、乘法、softmax、激活等）被替换为优化实现，直接调用 CMSIS-NN 函数以及额外的优化 Cortex-M 实现。
• 目标感知编译。CPU 变体（M0 到 M85）和 ISA 层级在编译时指定，因此会选择正确的 CMSIS-NN 后端，消除运行时调度开销。
• 专用量化器。使用 PyTorch 的 PT2E 量化框架，生成与 CMSIS-NN 内核数据布局要求匹配的 INT8 量化图。
• 单一编译器工具链。Cortex-M 降级路径直接作用于 ExecuTorch 边缘方言，保持编译流水线简单且易于调试。

Cortex-M 能力层级

该后端覆盖完整的 Cortex-M 系列：

Arm Helium 技术是性能提升最大的地方。CMSIS-NN 利用 Helium 基于 beat 的执行模型来流水化数据搬运与计算，为边缘机器学习架构中常见的深度卷积和逐点卷积带来显著的吞吐量提升。话虽如此，同一套工作流可面向所有变体。目标配置会自动选择相应的后端。

ExecuTorch 对嵌入式友好

与必须在运行时适配多种硬件的移动或云环境不同，微控制器部署面向固定的硬件配置。嵌入式开发者对其部署目标有精确的了解，包括确切的 CPU 核心、可用的 ISA 扩展、SRAM 分配和闪存容量。

ExecuTorch 的提前编译栈正是为利用这一点而设计。ExecuTorch 在编译时做出目标特定决策：图级优化、内存规划、权重打包和内核选择在编译时都是目标感知的。

具体而言，对于 Cortex-M，这意味着：

• 图级计算消除。冗余的数据类型转换、量化/反量化对以及内存格式转置在降级过程中被移除，因此只有必要的计算会到达设备。
• 量化参数折叠。缩放和零点运算在导出时预先计算为整数乘数/移位形式，因此量化内核推理完全保持在定点运算中。
• AOT 权重布局转置。卷积权重在导出时从 PyTorch 的原生布局（OIHW）转置为 CMSIS-NN 期望的格式（OHWI）。置换开销在编译期间一次性支付，推理时不再产生。
• 跨异构内存的静态内存规划。所有张量和暂存缓冲区都提前分配和布局，并支持跨越多个内存区域（例如 TCM 和 SRAM）。开发者还可以自定义放置位置，将延迟关键的缓冲区放入快速本地内存。无需堆分配器、无碎片、无需运行时内存管理。
• 目标特定的算子替换。CortexMPassManager 在编译时（而非运行时）选择与你的核心 ISA 层级（标量、DSP 或 MVE）匹配的 CMSIS-NN 内核变体。

开发者工作流

import torch
from torchao.quantization.pt2e.quantize_pt2e import convert_pt2e, prepare_pt2e

from executorch.backends.cortex_m.edge_compile_config import cortex_m_edge_compile_config
from executorch.backends.cortex_m.passes.cortex_m_pass_manager import CortexMPassManager
from executorch.backends.cortex_m.quantizer.quantizer import CortexMQuantizer
from executorch.backends.cortex_m.target_config import CortexM, CortexMTargetConfig
from executorch.exir import to_edge_transform_and_lower

# 1. Export
model = MyModel().eval()
example_inputs = (torch.randn(1, 1, 49, 10),)
exported = torch.export.export(model, example_inputs)

# 2. Quantize and calibrate
quantizer = CortexMQuantizer(use_explicit_layout=True)
prepared = prepare_pt2e(exported.module(), quantizer)
for sample in calibration_data:
    prepared(sample)
quantized = convert_pt2e(prepared)

# 3. Re-export the quantized model
quantized_exported = torch.export.export(quantized, example_inputs)

# 4. Lower to Edge and apply the Cortex-M passes
pass_manager = CortexMPassManager(
    target_config=CortexMTargetConfig(cpu=CortexM.M55),
    use_explicit_layout=True,
)
edge = to_edge_transform_and_lower(
    quantized_exported,
    compile_config=cortex_m_edge_compile_config(),
    transform_passes=pass_manager,
)

# 5. Serialize for integration into firmware
et_program = edge.to_executorch()
with open("model.pte", "wb") as f:
    f.write(et_program.buffer)

生成的 .pte 二进制文件与 ExecuTorch 运行时和 CMSIS-NN 库一起链接到固件中，然后烧录到设备上。在运行时，推理执行预编译的计算图，运行时开销极小，且张量无需动态内存分配。

在 Ethos-U 之外同时使用 Cortex-M 后端

许多 Cortex-M MCU 将 CPU 与 Arm Ethos-U NPU（如 U55、U65 或 U85）搭配使用。ExecuTorch 的 EthosUPartitioner 通过 Vela 编译器将支持的操作委托给 NPU，而分区之外的操作则在同一个计算图中由 Cortex-M CPU 运行。

Cortex-M 通道在 Ethos-U 分区之后运行，并复用计算图中已有的量化参数。这使得使用 EthosUQuantizer 量化的模型可以对其量化、布局和形状约束满足 Cortex-M 后端要求的 CPU 操作使用 CMSIS-NN。否则，它们会回退到 ExecuTorch 的可移植内核，这些内核功能可用但未加速。

实际好处是 NPU 算子覆盖率并非全有或全无的门槛。一个包含少量未委托操作的模型今天就可以通过 CPU/NPU 混合执行发布，并随着覆盖率的增长将更多计算图迁移到 NPU 上。

MLPerf Tiny 基准测试套件

我们在 Alif Ensemble E8 上测量了五个 MLPerf Tiny Inference 基准模型中的四个的推理延迟和内存使用情况。这些基准模型代表了一组具有 TinyML 工作负载代表性的常见深度神经网络。Alif E8 集成了多个 Cortex-M55 核心以及 Ethos-U55 和 U85 NPU；我们在单个运行于 400 MHz 的 M55 高性能核心上进行测量，未使用 Ethos-U NPU。ExecuTorch 的提前内存规划意味着 RAM 使用是确定且有界的，在持续工作负载下没有碎片化风险。使用 ExecuTorch 的算子选择性构建仅包含推理所需的算子，从而创建最小的闪存占用。所有模型均使用 CortexMQuantizer 进行 INT8 量化，并使用 Alif ML Embedded Evaluation Kit 作为测试框架。这些是我们自己的测量结果，而非官方 MLPerf Tiny 提交，因此无法与 MLCommons 排行榜上已发布的结果直接比较。

所有四个模型都在 90 KiB 以下的 RAM 中运行，其中三个在 60 KiB 以下，异常检测自编码器在 5.2 KiB 中运行。代码占用保持在 15 到 37 KiB 之间，因为算子选择性构建仅链接每个模型使用的算子。

* 使用 GCC 15.2.1 编译的代码包括 ExecuTorch 核心运行时（-Oz）和内核（-O3），并禁用了日志记录。

演示：实时人员检测器

为了展示 Cortex-M 后端在实际中的能力，我们在由 Arm Cortex-M85 驱动的 Renesas EK-RA8D1 板上部署了一个 µYOLO 人员检测模型。该部署轻松适应 MCU 级内存限制：

• 任务：实时人员检测
• 模型：µYOLO，剪枝的深度可分离 CNN 骨干网络，带线性预测头
• 模型大小：452 KiB（INT8 .pte 文件）
• 总闪存：640 KiB
• 峰值 RAM：254 KiB
• 推理延迟：@ 480 MHz 下每帧推理 24 毫秒
• 端到端吞吐量：12.7 FPS
• 输入：128×128 RGB 摄像头帧

这个资源受限、始终在线的边缘视觉示例支持机器人传感、占用监测、安全系统、智能摄像头和存在触发设备等应用。

同样重要的是，该示例展示了 ExecuTorch 所支持的开发工作流。模型定义、训练代码、导出流程和嵌入式部署都位于同一个基于 PyTorch 的生态系统中。中间表示保持可执行，使得在整个导出和降级过程中比较模型输出成为可能，而不是将部署视为黑盒。生成的图还可以使用 Model Explorer 等工具进行检查，而 ETDump 则暴露每个算子的执行开销，以便在目标上进行性能分析。这些工具共同使得在模型架构、精度、内存使用和延迟上进行迭代成为可能，同时持续检查变换是否保持了模型行为。开发者无需在导出模型后等到部署后才发现数值或性能回归，而是可以检查和执行变换流水线的中间阶段。

模型定义、训练和导出流程可在 ExecuTorch 仓库中获取。为了便于在无需物理目标的情况下轻松启动演示，树内应用面向 Corstone FVP。设备端演示的板级启动基于 ra-fsp-examples 仓库中的代码，使用 RA Smart Configurator 进行配置，使用 Arm GNU 工具链构建，并使用 J-Link Flash 烧录。对于上述测量，开销最大的算子的权重被放置在 DTCM 中，并启用了指令缓存。这使得推理延迟从 191 ms 降低到 24 ms，提升了近 8 倍。

入门

Cortex-M 后端现已在 ExecuTorch 仓库中提供：

平台

下一步

• 扩展混合精度支持。将 A8W4 和 A16W8 混合精度支持扩展到完整的算子集。
• 浮点内核。CMSIS-NN 8.0.0 引入了 fp32 和 fp16 MVE 内核。通过 Cortex-M 后端暴露它们，使非全量化模型能够使用相同的降级路径，而无需单独的部署流程。
• 更广泛的算子覆盖。 新增对注意力算子、层归一化以及其他流行架构模式的支持，不再局限于传统 CNN，同时加入 FFT 等 CMSIS-DSP 算子，使特征提取可以作为图的一部分运行。
• 更多端到端示例。 语音活动检测、手势识别、预测性维护和流式唤醒词，即第五个 MLPerf Tiny 基准测试，它需要用于多帧推理的测试基础设施。
• 更多硬件验证。 扩展已验证平台和开发套件的集合。

我们对这为嵌入式 ML 社区带来的可能性感到兴奋。如果你正在边缘部署 ML，无论是在 1 美元的传感器节点上，还是在运行语音命令的 Cortex-M55 上，ExecuTorch 现在都提供了从 PyTorch 训练到设备端推理的直接路径。

了解更多，请访问 ExecuTorch 文档 | ExecuTorch 仓库 | Cortex-M 后端 | ExecuTorch Discord

文章 Bringing ExecuTorch to Arm Cortex-M CPUs 首次发表于 PyTorch。

来源：PyTorch：Blog · pytorch.org