将 ExecuTorch 引入 Arm Cortex-M CPU

精选项目Featured projects

• 
  

简而言之TL;DR

• 在微控制器上部署 PyTorch 模型，历来需要将模型转换为其他框架的格式、维护独立的工具链，并排查跨框架的数值不匹配问题。ExecuTorch 完全省去了这一步转换。
  Deploying PyTorch models on microcontrollers has historically required converting to other framework formats, maintaining separate toolchains, and debugging cross-framework numerical mismatches. ExecuTorch eliminates this conversion step entirely.
• Cortex-M 后端支持 PyTorch 模型直接运行在 Arm Cortex-M CPU 上，并通过 Arm CMSIS-NN 加速。它通过单一工作流支持所有性能等级（Scalar、DSP 和 MVE/Helium）。
  The Cortex-M backend enables PyTorch models to run directly on Arm Cortex-M CPUs with Arm CMSIS-NN acceleration. It supports all capability tiers (Scalar, DSP, and MVE/Helium) from a single workflow.
• 我们在 Alif Ensemble E8 上对 MLPerf Tiny 套件中的五个模型中的四个进行了基准测试。每个模型的运行时间都不超过 21.5 毫秒，且在单个 Cortex-M55 内核上使用的 RAM 不到 90 KiB。
  We benchmark four of the five models from the MLPerf Tiny suite on the Alif Ensemble E8. Each model runs in 21.5 ms or less and uses under 90 KiB of RAM on a single Cortex-M55 core.
• 对于异构 SoC，除委托给 Ethos-U NPU 执行外，Cortex-M 后端还提供 CPU 执行路径。
  For heterogeneous SoCs, the Cortex-M backend also provides the CPU execution path alongside Ethos-U NPU delegation.
• 二进制体积极小。ExecuTorch 核心运行时占用的闪存空间不到 20 KiB，算子选择性构建只会链接模型所需的算子，因此代码总量会随模型大小变化，而非随框架大小变化。
  Minimal binary footprint. The ExecuTorch core runtime is under 20 KiB of flash, and operator selective build links only the operators your model needs, so total code size scales with the model rather than the framework.

背景Background

微控制器为数十亿台常开设备提供动力，包括可穿戴设备、工业传感器、语音接口和智能家电。这些设备的运行受到极端限制：SRAM 通常不到 1 MB，闪存只有个位数 MB，功耗预算以毫瓦计。尽管存在这些限制，在这些平台上运行有实际意义的机器学习工作负载的需求日益增长，硬件也在不断演进以满足这一需求。现代基于 Cortex-M 的微控制器单元（MCU）如今已集成 DSP 和向量指令集架构（ISA）、大型紧耦合存储器（TCM），以及 Arm Ethos-U NPU 等高能效 NPU，使资源受限设备上的机器学习推理变得更加可行。Microcontrollers power billions of always-on devices: wearables, industrial sensors, voice interfaces, and smart home appliances. These devices operate under extreme constraints: often less than 1 MB of SRAM, single-digit megabytes of flash, and power budgets measured in milliwatts. Despite these limitations, there’s growing demand to run meaningful ML workloads on these platforms and the hardware is evolving to meet it. Modern Cortex-M based microcontroller units (MCUs) now include DSP & vector ISAs, large tightly-coupled memories (TCMs), and power-efficient NPUs such as the Arm Ethos-U NPU that make ML inference more practical in resource constrained devices.

截至目前，在 Cortex-M 上部署机器学习意味着必须离开 PyTorch 生态系统。开发者不得不将模型转换为其他格式，为训练和部署分别维护工具链，还要调试转换过程中引入的数值差异。对于使用 PyTorch 进行训练的团队而言——顶级机器学习会议上发表的研究代码中，超过 90% 都使用 PyTorch——这一步转换给每次迭代都增添了阻力。Until now, deploying ML on Cortex-M meant leaving the PyTorch ecosystem. Developers had to convert models to alternative formats, maintain separate toolchains for training and deployment, and debug numerical mismatches introduced during conversion. For teams that train in PyTorch, which accounts for over 90% of the research code published at top ML conferences, this translation step adds friction to every iteration cycle.

ExecuTorch 的设计目标就是消除这一差距。通过 Ethos-U NPU，Arm MCU 已可获得支持；而 Cortex-M 后端则将支持扩展到 Cortex-M CPU，因此模型既能在配备加速器的芯片上运行，也能在未配备加速器的芯片上运行。训练好的 PyTorch 模型可在同一技术栈中完成导出、量化和针对设备的降级处理；这套技术栈也用于为移动设备、桌面设备和服务器提供模型服务。ExecuTorch was designed to eliminate this gap. Arm MCU support has been available through the Ethos-U NPU, and the Cortex-M backend extends it to Cortex-M CPUs, so a model can run on parts with or without an accelerator. The trained PyTorch model is exported, quantized and lowered for the device within the same stack that serves models on mobile, desktop and server.

Cortex-M 后端The Cortex-M Backend

ExecuTorch Cortex-M 后端通过提前编译器转换，将标准 PyTorch 算子替换为由 CMSIS-NN 支持的自定义算子。在推理时，这些算子会直接调用 Arm 的 CMSIS-NN 库。CMSIS-NN 是一个开源集合，包含针对 Cortex-M 处理器优化的神经网络内核。The ExecuTorch Cortex-M backend replaces standard PyTorch operators with CMSIS-NN-backed custom operators through ahead-of-time compiler passes. At inference time, these operators call directly into Arm’s CMSIS-NN library, an open source collection of optimized neural network kernels for Cortex-M processors.

主要属性：Key properties:

• 由 CMSIS-NN 加速。量化运算（线性运算、卷积、加法、乘法、softmax、激活函数等）会被替换为优化实现，这些实现直接调用 CMSIS-NN 函数及其他优化的 Cortex-M 实现。
  CMSIS-NN accelerated. Quantized operations (linear, conv, add, mul, softmax, activations, etc.) are replaced with optimized implementations that call CMSIS-NN functions and additional optimized Cortex-M implementations directly.
• 面向目标平台的编译。在编译时指定 CPU 变体（M0 至 M85）和 ISA 等级，从而选择正确的 CMSIS-NN 后端，消除运行时分派开销。
  Target-aware compilation. The CPU variant (M0 through M85) and ISA tier are specified at compile time, so the correct CMSIS-NN backend is selected, eliminating runtime dispatch overhead.
• 专用量化器。使用 PyTorch 的 PT2E 量化框架生成 INT8 量化图，并满足 CMSIS-NN 内核的数据布局要求。
  Purpose-built quantizer. Produces INT8 quantized graphs matching the data layout requirements of CMSIS-NN kernels, using PyTorch’s PT2E quantization framework.
• 单一编译器工具链。Cortex-M 降低路径直接处理 ExecuTorch 边缘方言，使编译流水线保持简洁且易于调试。
  Single compiler toolchain. The Cortex-M lowering path operates directly on the ExecuTorch edge dialect, keeping the compilation pipeline simple and debuggable.

Cortex-M 能力等级Cortex-M Capability Tiers

该后端面向完整的 Cortex-M 系列：The backend targets the full Cortex-M spectrum:

Tier	Cores	Key Feature	Use Case
Scalar	M0, M0+, M3, M23	Standard ARM instructions	Ultra-low-cost, minimal silicon
DSP	M4, M7, M33, M35P	SIMD multiply-accumulate	Mid-range MCUs, signal processing
MVE (aka Helium)	M55, M85	128-bit vector ops, beat-based execution	High-performance MCU ML inference

Arm Helium 技术能带来最大的性能提升。CMSIS-NN 利用 Helium 基于拍的执行模型，对数据移动和计算进行流水线处理，从而显著提升边缘机器学习架构中常见的深度卷积和逐点卷积的吞吐量。尽管如此，同一套工作流程适用于所有变体。目标配置会自动选择合适的后端。Arm Helium technology is where the biggest performance gains are. CMSIS-NN leverages Helium’s beat-based execution model to pipeline data movement and compute, providing significant throughput gains for the depthwise and pointwise convolutions common in edge ML architectures. That said, the same workflow targets all variants. The target configuration selects the appropriate backend automatically.

ExecuTorch 对嵌入式设备友好ExecuTorch is Embedded Friendly

与必须在运行时适配各种硬件的移动端或云端环境不同，微控制器部署面向的是固定的硬件配置。嵌入式开发者对部署目标有精确了解，包括具体的 CPU 内核、可用的 ISA 扩展、SRAM 分配情况以及闪存容量。Unlike mobile or cloud environments that must accommodate varied hardware at runtime, microcontroller deployments target a fixed hardware profile. Embedded developers possess precise knowledge of their deployment target, including the exact CPU core, available ISA extensions, SRAM allocation, and flash capacity.

ExecuTorch 的提前编译（AOT）技术栈旨在充分利用这一点。ExecuTorch 会在编译时做出针对目标平台的决策：图级优化、内存规划、权重打包和内核选择都会在编译时考虑目标平台的特性。ExecuTorch’s ahead-of-time stack is designed to exploit this. ExecuTorch makes target-specific decisions at compile time: graph-level optimizations, memory planning, weight packing, and kernel selection are all target-aware at compile time.

具体来说，对于 Cortex-M，这意味着：Concretely, for Cortex-M this means:

• 图级计算消除。在 lowering 阶段会移除冗余的数据类型转换、量化/反量化对以及内存格式转置，因此只有必要的计算会被下发到设备执行。
  Graph-level compute elimination. Redundant dtype conversions, quantize/dequantize pairs, and memory format transposes are removed during lowering, so only necessary compute reaches the device.
• 量化参数折叠。导出时预先将缩放因子和零点运算转换为整数乘数/移位形式，使量化内核推理完全采用定点运算。
  Quantization parameter folding. Scale and zero-point arithmetic is precomputed into integer multiplier/shift form at export, so quantized kernel inference stays entirely in fixed-point.
• AOT 权重布局转置。在导出时，卷积权重会从 PyTorch 原生布局（OIHW）转置为 CMSIS-NN 所需的格式（OHWI）。转置开销只在编译期间产生一次，推理时不会产生。
  AOT weight layout transposition. Convolution weights are transposed from PyTorch’s native layout (OIHW) to CMSIS-NN’s expected format (OHWI) at export time. The permute cost is paid once during compilation and never at inference.
• 异构存储器间的静态内存规划。所有张量和暂存缓冲区都会提前分配并布局，支持跨多个存储区域（例如 TCM 和 SRAM）。开发者还可以自定义内存放置方式，将对延迟敏感的缓冲区放入高速本地存储器。无需堆分配器，不会产生内存碎片，也无需运行时内存管理。
  Static memory planning across heterogeneous memories. All tensor and scratch buffers are allocated and laid out ahead of time, with support for spanning multiple memory regions (e.g., TCM and SRAM). Developers can also customize placement to put latency-critical buffers in fast local memory. No heap allocator, no fragmentation, and no runtime memory management required.
• 针对目标的算子替换。CortexMPassManager 会在编译时（而非运行时）选择与您的内核 ISA 等级（Scalar、DSP 或 MVE）匹配的 CMSIS-NN 内核变体。
  Target-specific operator replacement. The CortexMPassManager selects CMSIS-NN kernel variants matched to your core’s ISA tier (Scalar, DSP, or MVE) at compile time, not at runtime.

开发者工作流程Developer Workflow

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 库一起链接到固件中，然后烧录到设备上。运行时，推理会执行预编译的计算图，运行时开销极低，且不会为张量动态分配内存。The resulting .pte binary is linked into firmware alongside the ExecuTorch runtime and CMSIS-NN library, then flashed to the device. At runtime, inference executes the precompiled graph with minimal runtime overhead and no dynamic memory allocation for tensors.

将 Cortex-M 后端与 Ethos-U 配合使用Using the Cortex-M Backend Alongside Ethos-U

许多 Cortex-M MCU 会搭配 Arm Ethos-U NPU，例如 U55、U65 或 U85。ExecuTorch 的 EthosUPartitioner 通过 Vela 编译器将受支持的操作委托给 NPU，而分区之外的操作则在同一计算图中由 Cortex-M CPU 执行。Many Cortex-M MCUs pair the CPU with an Arm Ethos-U NPU such as the U55, U65, or U85. ExecuTorch’s EthosUPartitioner delegates supported operations to the NPU via the Vela compiler, and operations left outside the partition run on the Cortex-M CPU within the same graph.

Cortex-M passes 在 Ethos-U 分区之后运行，并复用图中已有的量化参数。这样，使用 EthosUQuantizer 量化的模型便可在量化、布局和形状约束符合 Cortex-M 后端要求的 CPU 运算中使用 CMSIS-NN。否则，这些运算会回退到 ExecuTorch 的可移植内核；这些内核能够正常运行，但未经加速。The Cortex-M passes run after Ethos-U partitioning and reuse the quantization parameters already in the graph. This allows a model quantized with EthosUQuantizer to use CMSIS-NN for CPU operations whose quantization, layout and shape constraints meet the Cortex-M backend requirements. Otherwise they fall back to ExecuTorch’s portable kernels, which are functional but not accelerated.

实际好处在于，NPU 算子覆盖率并非非此即彼的门槛。即使模型中有少数操作未委托给 NPU 执行，也可以通过 CPU/NPU 混合执行在今天发布；随着覆盖率提升，还能将计算图中更多部分迁移到 NPU 上。The practical benefit is that NPU operator coverage is not an all-or-nothing gate. A model with a handful of undelegated operations can ship today on mixed CPU/NPU execution, and move more of the graph onto the NPU as coverage grows.

MLPerf Tiny 基准测试套件MLPerf Tiny Benchmark Suite

我们在 Alif Ensemble E8 上，对五个 MLPerf Tiny Inference 基准模型中的四个测量了推理延迟和内存用量。这些基准模型代表了一组常见的深度神经网络，能够反映 TinyML 工作负载的特点。Alif E8 集成了多个 Cortex-M55 内核，以及 Ethos-U55 和 U85 NPU；我们的测量使用了单个以 400 MHz 运行的 M55 高性能内核，未使用 Ethos-U NPU。ExecuTorch 的预先内存规划可确保 RAM 用量具有确定性且有界，在持续工作负载下不存在内存碎片风险。我们使用 ExecuTorch 的算子选择性构建功能，仅包含推理所需的算子，从而将 Flash 占用降至最低。所有模型均使用 CortexMQuantizer 进行了 INT8 量化，测试则使用 Alif ML Embedded Evaluation Kit 作为测试框架。这些是我们自行测得的数据，并非官方的 MLPerf Tiny 提交结果，因此无法与 MLCommons 排行榜上发布的结果直接比较。We measured inference latency and memory usage across four of the five MLPerf Tiny Inference benchmark models on the Alif Ensemble E8. These benchmark models represent a set of common deep neural networks representative of TinyML workloads. The Alif E8 integrates multiple Cortex-M55 cores alongside Ethos-U55 and U85 NPUs; we measured on a single M55 high performance core running at 400 MHz, with the Ethos-U NPUs unused. ExecuTorch’s ahead-of-time memory planning means RAM usage is deterministic and bounded, with no fragmentation risk under sustained workloads. ExecuTorch’s operator selective build was used to only include those necessary for inference, creating a minimal flash footprint. All models were INT8 quantized using the CortexMQuantizer and the Alif ML Embedded Evaluation Kit was used as a test harness. These are our own measurements rather than an official MLPerf Tiny submission, so they are not directly comparable to published results on the MLCommons leaderboard.

这四种模型的运行内存均低于 90 KiB，其中三种低于 60 KiB，异常检测自编码器仅需 5.2 KiB。由于运算符选择性构建只会链接各模型实际使用的运算符，因此代码占用保持在 15 至 37 KiB 之间。All four models run in under 90 KiB of RAM, three of them in under 60 KiB, and the anomaly detection autoencoder in 5.2 KiB. Code footprint stays between 15 and 37 KiB because operator selective build links only the operators each model uses.

Model	Task	Latency (ms)	Inferences per second	Peak RAM (KiB)	Flash (KiB)
					Model	Code *	Total
DS-CNN	Keyword Spotting	5.825	172	26.00	37.67	36.03	73.70
MobileNet v1 0.25	Visual Wake Words	21.450	47	85.15	253.07	36.03	289.10
ResNet-8	Image Classification	15.290	65	55.14	89.77	29.82	119.59
Autoencoder	Anomaly Detection	1.208	828	5.20	272.03	14.97	287.00

使用 GCC 15.2.1 编译的代码包含 ExecuTorch 核心运行时（-Oz）和内核（-O3），并禁用了日志记录。* Code compiled with GCC 15.2.1 includes ExecuTorch core runtime (-Oz) and kernels (-O3) with logging disabled.

演示：实时人员检测器Demo: Real-time Person Detector

为了展示 Cortex-M 后端在实践中的能力，我们在搭载 Arm Cortex-M85 的 Renesas EK-RA8D1 开发板上部署了一个 µYOLO 人体检测模型。该部署可轻松满足 MCU 级别的内存限制：To show what the Cortex-M backend enables in practice, we deployed a µYOLO person detection model on a Renesas EK-RA8D1 board, powered by the Arm Cortex-M85. The deployment fits comfortably within MCU-class memory constraints:

• 任务：实时人员检测
  Task: Real-time person detection
• 模型：µYOLO，经过剪枝的深度可分离 CNN 主干网络，搭配线性预测头
  Model: µYOLO, pruned depthwise separable CNN backbone with linear predictor head
• Model size: 452 KiB (INT8 .pte file)
• 闪存总容量：640 KiB
  Total flash: 640 KiB
• 峰值 RAM：254 KiB
  Peak RAM: 254 KiB
• 推理延迟：480 MHz 下每帧推理耗时 24 ms
  Inference latency: 24 ms per frame inference @ 480 MHz
• 端到端吞吐量：12.7 FPS
  End-to-end throughput: 12.7 FPS
• 输入：128×128 RGB 摄像头帧
  Input: 128×128 RGB camera frame

这个资源受限、始终在线的边缘视觉示例可用于机器人感知、占用监测、安全系统、智能摄像头以及由人员出现触发的设备等应用。This example of resource-constrained, always-on vision on the edge supports applications such as robotics sensing, occupancy monitoring, safety systems, smart cameras, and presence-triggered devices.

同样重要的是，这个示例展示了 ExecuTorch 所支持的开发工作流。模型定义、训练代码、导出流程和嵌入式部署都处于同一个基于 PyTorch 的生态系统中。中间表示仍可执行，因此可以在导出和下沉过程中比较模型输出，而不必把部署视为一个黑盒。生成的计算图也可以使用 Model Explorer 等工具进行检查，而 ETDump 则会提供每个算子的执行开销，便于在目标设备上进行性能分析。这些工具结合起来，使开发者能够不断迭代模型架构、准确率、内存用量和延迟，同时持续检查各种转换是否保留了模型行为。这样，开发者无需先导出模型、等部署后才发现数值或性能回退，而是可以检查并执行转换流水线中的各个中间阶段。Just as importantly, the example demonstrates the development workflow enabled by ExecuTorch. The model definition, training code, export flow, and embedded deployment live within the same PyTorch-based ecosystem. Intermediate representations remain executable, making it possible to compare model outputs throughout export and lowering rather than treating deployment as a black box. The resulting graphs can also be inspected with tools such as Model Explorer, while ETDump exposes per-operator execution costs for profiling on the target. Together, these tools make it possible to iterate on model architecture, accuracy, memory use, and latency while continuously checking that transformations have preserved model behaviour. Instead of exporting a model and only discovering numerical or performance regressions after deployment, developers can inspect and execute intermediate stages of the transformation pipeline.

模型定义、训练和导出流程均可在 ExecuTorch 仓库中找到。为了无需实体目标设备即可轻松启动演示，仓库内的应用以 Corstone FVP 为目标平台。设备端演示的板级启动基于 ra-fsp-examples 仓库中的代码，并使用 RA Smart Configurator 进行配置、使用 Arm GNU Toolchain 构建，以及使用 J-Link Flash 烧录。对于上述测量，开销最大的算子的权重被放置在 DTCM 中，并启用了指令缓存。这使推理延迟从 191 ms 降至 24 ms，性能提升近 8 倍。The model definition, training and export flow are available in the ExecuTorch repository. To facilitate an easy bring-up of the demo without the need for a physical target, the in-tree application is targeted for the Corstone FVP. Board-specific bring-up for the on-device demo was based on code from the ra-fsp-examples repo, configured with the RA Smart Configurator, built using the Arm GNU Toolchain, and flashed using J-Link Flash. For measurements above, the weights of the most expensive operators were placed in DTCM, and the instruction cache was enabled. This resulted in an inference latency reduction from 191 ms to 24 ms, a nearly 8x improvement.

快速开始Getting Started

ExecuTorch 仓库目前已提供 Cortex-M 后端：The Cortex-M backend is available today in the ExecuTorch repository:

Resource	Description
Cortex-M Backend Documentation	Supported operators, target configuration, and build setup
Arm Backend Examples	Full example directory with setup scripts
CMSIS-ExecuTorch Project Template	Docker build + Keil Studio + AVH simulation
Zephyr RTOS Integration	ExecuTorch on Zephyr with CMSIS Toolbox
Raspberry Pi Pico 2 Example	Cortex-M33, MNIST digit classification

平台Platforms

Platform	CPU	Available via
Arm Corstone-300 FVP	Cortex-M55 + Ethos-U55	In-tree examples, exercised in CI
Arm Corstone-320 FVP	Cortex-M85 + Ethos-U85	In-tree examples, exercised in CI
Alif Ensemble E8	Cortex-M55 (MVE)	Alif ML Embedded Evaluation Kit
Raspberry Pi Pico 2	Cortex-M33 (DSP)	In-tree example
Renesas EK-RA8D1	Cortex-M85	Out-of-tree board port; in-tree demo runs on Corstone FVP

接下来是什么What’s Next

• 扩展混合精度支持。将 A8W4 和 A16W8 混合精度支持扩展至全部算子。
  Expanded mixed-precision support. Extending A8W4 and A16W8 mixed-precision support across the full operator set.
• 浮点内核。CMSIS-NN 8.0.0 引入了 fp32 和 fp16 MVE 内核。通过 Cortex-M 后端开放这些内核，可让非全量化模型使用相同的 lowering 路径，而无需单独的部署流程。
  Floating-point kernels. CMSIS-NN 8.0.0 introduced fp32 and fp16 MVE kernels. Exposing them via the Cortex-M backend enables non-fully quantized models to use the same lowering path without separate deployment flows.
• 更广泛的算子覆盖范围。除了传统 CNN，还支持注意力算子、层归一化及其他常见架构模式，并支持 FFT 等 CMSIS-DSP 算子，让特征提取也能作为计算图的一部分运行。
  Broader operator coverage. Adding support for attention operators, layer normalization, and other popular architecture patterns beyond traditional CNNs, along with CMSIS-DSP operators such as FFT so feature extraction can run as part of the graph.
• 更多端到端示例：语音活动检测、手势识别、预测性维护，以及流式唤醒词检测。流式唤醒词检测是 MLPerf Tiny 的第五项基准测试，需要用于多帧推理的测试基础设施。
  More end-to-end examples. Voice activity detection, gesture recognition, predictive maintenance, and streaming wake word, the fifth MLPerf Tiny benchmark, which needs test infrastructure for multi-frame inference.
• 额外的硬件验证。扩大已验证平台和开发套件的范围。
  Additional hardware validation. Expanding the set of validated platforms and development kits.

我们很高兴这为嵌入式机器学习社区带来了新的可能。如果你正在边缘设备上部署机器学习，无论是在 1 美元的传感器节点上，还是在运行语音命令的 Cortex-M55 上，ExecuTorch 现在都能提供一条从 PyTorch 训练到设备端推理的直通路径。We’re excited about what this unlocks for the embedded ML community. If you’re deploying ML at the edge, whether on a $1 sensor node or a Cortex-M55 running voice commands, ExecuTorch now provides a direct path from PyTorch training to on-device inference.

Learn more at ExecuTorch Documentation | ExecuTorch repo | Cortex-M Backend | ExecuTorch Discord