将 PyTorch 训练的模型部署到小型设备的开发者，现在可以省去转换为其他框架格式的步骤。ExecuTorch 的新后端支持 Arm 微控制器的 CPU，让没有神经网络加速器的设备也能使用同一套工具流程进行部署。
1. 在同一套工具中准备，无需转换模型格式
以往的 Arm 支持面向 Ethos-U 神经网络加速器，此次则新增了 Cortex-M CPU 执行路径。这意味着无需转到其他框架，并不意味着可以省去针对设备的导出，以及将数值表示为小整数的量化步骤。
后端会在运行前，将模型算子转换为对 Cortex-M 优化算子库 CMSIS-NN 的调用。支持范围从仅使用基本指令的内核，到支持信号处理指令和向量运算的内核，针对各内核的算子选择在编译时完成。
2. 将运行开销转移到预先准备阶段
表示算子连接结构的计算图优化、权重布局和内存规划也会预先完成。通过确定模型计算所用的多维数值数组张量及临时缓冲区的位置，消除推理期间为张量动态分配内存的需要。这能减轻运行负担，但开发者需了解目标 CPU、指令支持和内存容量，必要时还需指定放入高速内存的数据。
部署顺序为导出、使用校准数据量化、重新导出、转换为设备算子、保存文件。专用量化器会生成符合 CMSIS-NN 布局要求的 8 位整数计算图。以下为原文示例中的导出部分。
# 1. Export
model = MyModel().eval()
example_inputs = (torch.randn(1, 1, 49, 10),)
exported = torch.export.export(model, example_inputs)将生成的文件与运行时及 CMSIS-NN 库一同放入固件后，设备便可执行预先准备好的计算图。
3. 继续执行加速器无法处理的算子
在配备 Ethos-U 的设备上，支持的算子交给加速器，其余算子则在同一计算图中由 CPU 承担。若 CPU 算子的量化、数据布局和形状条件符合要求，就使用 CMSIS-NN 执行；否则使用未加速的通用内核，即实际执行算子的实现代码。即使部分算子无法由加速器执行，部署路径仍然存在，但不能认为这些部分也获得了加速。
4. 在相同条件下考察延迟与内存
作者测量了面向小型设备的推理测试 MLPerf Tiny 的五个模型中的四个。未测量的第五项是连续唤醒词检测，需要支持多帧推理的测试基础设施。因此，本次单次推理数据并未验证连续输入任务。下表列出了相同硬件和量化条件下各模型的延迟与内存需求。
表：四个模型的推理延迟和内存用量。闪存代码指仅包含所需算子的代码大小，闪存总量则包含模型。
条件：Alif Ensemble E8，Cortex-M55 高性能单核 400 MHz，未使用 Ethos-U NPU，使用 CortexMQuantizer 进行 INT8 量化，Alif ML Embedded Evaluation Kit，仅构建所需算子，GCC 15.2.1，核心运行时 -Oz、内核 -O3，禁用日志。由于是自行测量而非正式提交，不能直接与 MLCommons 公开排名结果比较。
单位：延迟 ms，内存 KiB
| 模型 | 延迟 | 峰值 RAM | 闪存代码 | 闪存总量 |
|---|---|---|---|---|
| DS-CNN | 5.825 | 26.00 | 36.03 | 73.70 |
| MobileNet v1 0.25 | 21.450 | 85.15 | 36.03 | 289.10 |
| ResNet-8 | 15.290 | 55.14 | 29.82 | 119.59 |
| 自编码器 | 1.208 | 5.20 | 14.97 | 287.00 |
在此条件下，四个模型的 RAM 用量均低于 90 KiB。
5. 实际设备上的内存布局也会影响性能
条件：人员检测演示，Renesas EK-RA8D1，Cortex-M85 480 MHz，INT8 µYOLO，128×128 RGB 输入
峰值 RAM 为 254 KiB，闪存总量为 640 KiB。将高开销算子的权重放入与 CPU 紧密耦合的数据存储器 DTCM，并启用指令缓存后，推理延迟从 191 ms 降至 24 ms。
演示的整体吞吐量为每秒 12.7 帧，需要与推理时间区分开来。
后续工作包括扩大混合精度的应用范围，即对不同计算或权重采用不同位数，以及接入浮点内核、支持更多算子和开展硬件验证。
此次变化的价值在于减少转换工具，而实际部署性能仍需结合目标设备的算子支持和内存布局来判断。