ExecuTorch —— 统一在终端设备运行 AI 模型的 PyTorch 方案

# 1 引言

源：https://arxiv.org/html/2605.08195 `marginparsep` 已更改。`topmargin` 已更改。`marginparwidth` 已更改。`marginparpush` 已更改。页面布局违反了 ICML 样式。请勿更改页面布局，或包含如 `geometry`、`savetrees` 或 `fullpage` 等会更改布局的包。我们无法可靠地撤销对样式的任意更改。请移除违规的包或更改布局的命令，然后重试。

ExecuTorch - 统一的 PyTorch 解决方案，用于在设备上运行 AI 模型

匿名作者¹

###### 摘要

在边缘设备上本地执行 AI 对于低延迟和离线操作至关重要。然而，在多样化硬件上部署模型仍然支离破碎，通常需要在 PyTorch 生态系统之外进行模型转换或完全重新实现，而模型最初是在该生态系统中编写的。我们引入了 ExecuTorch，一个统一的 PyTorch 原生边缘 AI 部署框架。ExecuTorch 实现了机器学习模型在异构计算环境中的无缝部署。它可以从嵌入式微控制器扩展到具有专用加速器的复杂片上系统（SoC），为从可穿戴设备、智能手机到大型计算集群的各种设备提供动力。ExecuTorch 保留了 PyTorch 语义，同时允许自定义，支持量化等优化，并支持可插拔的执行“后端”。这些特性共同实现了快速实验，使研究人员能够完全在 PyTorch 内部验证部署行为，从而弥合研究与生产之间的差距。

††脚注文本：¹匿名机构，匿名城市，匿名地区，匿名国家。通信作者：匿名作者。初步工作。正在接受机器学习与系统（MLSys）会议审查。请勿分发。

在边缘设备上本地执行 AI 对于无数需要低延迟或离线操作的重要应用至关重要，从实时翻译到自动驾驶汽车和患者监测 Wang and Jia (2025 (https://arxiv.org/html/2605.08195#bib.bib43)); Wang et al. (2025 (https://arxiv.org/html/2605.08195#bib.bib44)); Ng et al. (2025 (https://arxiv.org/html/2605.08195#bib.bib45)); Kuo et al. (2020 (https://arxiv.org/html/2605.08195#bib.bib46)); Xue et al. (2021 (https://arxiv.org/html/2605.08195#bib.bib47)); Sperling and Ernst (2024 (https://arxiv.org/html/2605.08195#bib.bib48)); Nigade et al. (2024 (https://arxiv.org/html/2605.08195#bib.bib49)); Kang et al. (2024 (https://arxiv.org/html/2605.08195#bib.bib50)); Ponset al. (2023 (https://arxiv.org/html/2605.08195#bib.bib51))。模型架构 Lin et al. (2024 (https://arxiv.org/html/2605.08195#bib.bib25)); Vasuet al. (2023 (https://arxiv.org/html/2605.08195#bib.bib53); 2024 (https://arxiv.org/html/2605.08195#bib.bib54)) 的持续进步以及诸如 NPU Ahsan et al. (2025 (https://arxiv.org/html/2605.08195#bib.bib55)) 等专用加速器的发展，使得设备端推理越来越具有可行性。然而，从研究到生产的过渡仍然支离破碎 Wang and Jia (2025 (https://arxiv.org/html/2605.08195#bib.bib43)); Wang et al. (2025 (https://arxiv.org/html/2605.08195#bib.bib44))：尽管 PyTorch 支撑了超过 70% Foundation (2024 (https://arxiv.org/html/2605.08195#bib.bib71)) 的 AI 研究，但 ML 开发人员要么必须离开 PyTorch 环境使用特定平台的工具，要么接受性能和可移植性方面的权衡。在边缘设备上部署 AI 模型催生了 numerous 解决方案，但现有框架存在关键局限性：

- 模型转换：在具有不同语义的不相连创作环境之间进行模型转换（例如，ONNX Microsoft (2018 (https://arxiv.org/html/2605.08195#bib.bib58))，TensorFlow Lite David et al. (2021 (https://arxiv.org/html/2605.08195#bib.bib56))）
- 强制重新实现：在框架特定格式中强制重新实现（例如，llama.cpp Gerganov (2023 (https://arxiv.org/html/2605.08195#bib.bib61))）
- 紧密耦合：与特定硬件供应商紧密耦合（例如，Qualcomm SNPE Qualcomm Technologies, Inc. (2016 (https://arxiv.org/html/2605.08195#bib.bib63))，Apple CoreML Apple Inc. (2017 (https://arxiv.org/html/2605.08195#bib.bib57))）
- 运行时开销过大（PyTorch Mobile）

这些因素在实验-部署循环中造成了摩擦。需要一种统一的工作流程，在所有设备上从训练到生产保留 PyTorch 语义，同时在保持可移植性的情况下不牺牲性能。

图 1：用户可以将 PyTorch 模型带入 ExecuTorch 进行编译和优化（包括与后端无关和后端特定的优化），以生成可在从 0.01 到 800 瓦平台上运行的 PTE 文件。

ExecuTorch 通过提供 PyTorch 原生开发环境来解决这一挑战，如图 1 (https://arxiv.org/html/2605.08195#S1.F1) 所示。它利用支撑 `torch.compile` 和 `torch.export` 的 PyTorch 核心技术，构建原始 PyTorch 模型的可移植表示，该表示可以作为二进制文件部署到多样化硬件上，并利用设备特定的内核优化。为此，ExecuTorch 实现了后端委托的基础设施，允许模型的不同部分在给定设备的最合适硬件上运行。ExecuTorch 执行提前（AOT）图级编译，与 TorchScript PyTorch Team (2019 (https://arxiv.org/html/2605.08195#bib.bib65)) 等先前方法相比，大大减少了解释器开销和运行时依赖。因此，研究人员可以在部署前在 PyTorch 内验证量化、分析性能并调试模型。

ExecuTorch 的一个优势是实验速度：研究人员可以完全在 PyTorch 内验证运行时行为。其他框架的流水线需要模型转换和单独的验证，往往导致数值不匹配和资源密集的调试周期。ExecuTorch 通过使用 `torch.export` 生成可直接在 PyTorch 急切模式下运行的执行图，同时捕获可以在设备上执行的忠实表示，消除了这一差距。例如，量化的 LLM（大型语言模型）可以在 PyTorch 中测试和调试，然后部署到手机的 NPU 上，并有信心其行为几乎完全一致。

这种对等性是通过几种协同工作的技术实现的。首先，`torch.export` 将模型转换为基于少量（<300）Core ATen 原语构建的与硬件无关的 AOT 图，减轻了边缘环境的负担。这些图消除了 Python 依赖但保留了调试符号，并且——与 ONNX 不同——仍然可以在 PyTorch 中执行以进行部署前验证。其次，ExecuTorch 支持选择性后端委托，允许模型的部分在 Qualcomm Hexagon 或 Apple Neural Engine 等专用加速器上运行，并在需要时回退到 CPU。支持提前（AOT）和即时（JIT）编译模式，硬件供应商可以通过干净的 API 集成，而无需修改核心运行时。第三，感知量化的导出使训练后量化和量化感知训练成为一等步骤。后端声明其能力，ExecuTorch 相应地应用量化，确保在 PyTorch 中验证的量化与设备上的执行相匹配。

ExecuTorch 还通过诸如 KV-cache 量化、滑动窗口注意力和 4-bit 组权重量化等技术解决了设备端 LLM 部署的内存限制，这将模型大小减少了 50% Meta AI (2024 (https://arxiv.org/html/2605.08195#bib.bib66))。这些技术作用于由 `torch.export` 生成的模型图，允许在移动设备上部署之前评估准确性和内存权衡。

我们对 ExecuTorch 在智能手机上针对大型语言模型（LLMs）和传统计算机视觉模型的延迟和吞吐量进行了全面评估，涵盖了 CPU、GPU 和 NPU，并将其与 ONNX Runtime、llama.cpp 和 LiteRT 等广泛使用的替代品进行了比较。在各种设备和工作负载中，我们发现 ExecuTorch 在异构后端上提供了具有竞争力或最先进的性能：它在 CPU 上（通过 XNNPACK）始终保持强劲，在移动 GPU 上（通过 Vulkan）实现高令牌生成吞吐量，在模型良好委托时在 NPU 上（通过 QNN）解锁了巨大的预填充加速，同时在可用全图委托的情况下，通过 CoreML 在 iOS 上匹配原生性能。

除了性能之外，ExecuTorch 在两个层面提供了生产关键的自定义功能：运行时扩展允许开发人员为特定操作实现自定义内核，选择性构建运算符以减少二进制大小，并为嵌入式系统创建自定义数据加载器；AOT 扩展支持内存规划和目标特定的编译器传递，从而针对硬件约束进行进一步优化。

本文有三项主要贡献。首先，我们提出了 ExecuTorch，这是第一个通过本地可执行导出图实现实验对等性的 PyTorch 框架，实现了从微控制器到智能手机的统一部署，无需模型转换或重新实现。其次，我们引入了实验对等性作为设计原则：通过 `torch.export` 和基于能力的后端集成，研究人员在投入生产之前在 PyTorch 中验证部署行为——量化、硬件委托、性能。第三，我们展示了大规模生产可行性：ExecuTorch 为 Meta 系列应用 Meta (2025a (https://arxiv.org/html/2605.08195#bib.bib73)) 和 Reality Labs（例如，Ray-Ban 智能眼镜）Meta (2025b (https://arxiv.org/html/2605.08195#bib.bib74)) 提供了数十亿次每日推理支持。它支持在 12 个硬件后端上执行视觉、音频和大型语言模型，从而在移动、嵌入式和桌面设备上实现高效推理。ExecuTorch 证明，研究人员无需在 PyTorch 的开发速度与边缘部署需求之间做出选择——统一的工作流程可以兼顾两者。

## 2 相关工作

边缘 AI 部署框架在开发速度、性能和可移植性之间做出了不同的权衡。我们通过实验对等性（即能够在模型开发和训练环境中验证部署行为的能力）的视角来评估现有方法。

基于转换的框架，如 ONNX Runtime Microsoft (2018 (https://arxiv.org/html/2605.08195#bib.bib58)) 和 TensorFlow Lite David et al. (2021 (https://arxiv.org/html/2605.08195#bib.bib56))，通过中间表示解耦训练和部署，但转换步骤引入了语义差距，这些差距仅在部署后才会显现。例如，PyTorch 中的 QAT 可能无法忠实地转换为 ONNX 的量化语义。

早期框架如 Caffe Jia et al. (2014 (https://arxiv.org/html/2605.08195#bib.bib29)) 启用了基于 C++ 的设备端部署，但要求在其生态系统内进行完整的模型创作。

基于编译器的方法，如 TVM Chen et al. (2018 (https://arxiv.org/html/2605.08195#bib.bib59)) 和 MNN Jiang et al. (2020 (https://arxiv.org/html/2605.08195#bib.bib60))，通过领域特定编译生成优化内核，但需要学习独立的工具链、调优程序和独立于 PyTorch 的调试工作流。

特定供应商的运行时，如 Apple 的 CoreML Apple Inc. (2017 (https://arxiv.org/html/2605.08195#bib.bib57))、Qualcomm 的 SNPE Qualcomm Technologies, Inc. (2016 (https://arxiv.org/html/2605.08195#bib.bib63)) 和 Apple 的 MLX Hannun et al. (2023 (https://arxiv.org/html/2605.08195#bib.bib20))，提供了出色的平台特定性能，但分散了部署景观，需要并行实现以支持多平台。

PyTorch Mobile PyTorch Team (2019 (https://arxiv.org/html/2605.08195#bib.bib65)) 和 TorchScript PyTorch Foundation (2021 (https://arxiv.org/html/2605.08195#bib.bib16)) 尝试了 PyTorch 原生部署，但受限于高内存占用和狭窄的硬件集成。

特定模型的运行时，如 llama.cpp Gerganov (2023 (https://arxiv.org/html/2605.08195#bib.bib61)) 和 vLLM Kwon et al. (2023 (https://arxiv.org/html/2605.08195#bib.bib70))，通过架构特定的优化实现了强劲的性能，但需要在训练框架之外完全重新实现，打破了迭代速度。vLLM 还需要 Python 运行时，这在嵌入式系统中不可行。

## 3 架构

ExecuTorch 的导出 API 和精简运行时允许在任何目标设备上无缝部署 PyTorch 模型，如图 1 (https://arxiv.org/html/2605.08195#S1.F1) 所示。关键设计目标是提供：

- 统一和可移植的运行时 – 轻量级运行时，具有最小的依赖和执行开销，确保最大的可移植性和在不同部署环境中的一致性行为。
- 可组合和可扩展的架构 – 用于后端、图变换传递和量化工具的模块化接口，允许硬件供应商和开发人员在不修改核心运行时的情况下插入自定义组件。
- 高效的模型执行 – 利用设备能力和对加速器（CPU、GPU、DSP/NPU）的访问，以及量化和内存规划等架构优化，以最小化内存占用和延迟。

ExecuTorch 的两个主要组件是 AOT 导出堆栈和运行时堆栈（图 2 (https://arxiv.org/html/2605.08195#S3.F2)）。在 AOT 方面，ExecuTorch 与 PyTorch 紧密集成。它使用 `torch.export` 从 `torch.nn.Module` 捕获计算图，并使用 `torch.fx` 图传递基础设施实现图级优化，如运算符融合。量化、子图委托和内存规划等图变换在提前执行，允许运行时保持精简并专注于执行预优化的模型图。

在运行时方面，ExecuTorch 提供紧凑且可自定义的执行环境。用户可以链接目标特定的内核和后端库，以为特定硬件定制部署。核心运行时库小巧高效，以确保与资源受限平台的兼容性。

图 2：ExecuTorch 的高级架构，显示两个阶段：模型准备和模型执行。准备流程使用 `torch.export` 导出 PyTorch 模型，将其转换为 ExecuTorch 边缘方言，可选地应用后端委托和图优化，最终将结果序列化为 PTE 格式以进行部署。

## 4 模型准备

在高层次上，模型准备工作流程遵循图 2 (https://arxiv.org/html/2605.08195#S3.F2) 中图示的步骤。

### 4.1 `torch.export` 和 IRs

`torch.export` 是 PyTorch 提供的执行图捕获机制。它使用 PyTorch 2.0 Ansel et al. (2024 (https://arxiv.org/html/2605.08195#bib.bib9)) 中引入的跟踪技术，将在 PyTorch Python 代码中定义的模型转换为静态图数据结构，我们称之为导出 IR。导出 IR PyTorch Developers (2022b (https://arxiv.org/html/2605.08195#bib.bib12)) 是一个具有强保证的 Torch FX 图 Reed et al. (2021 (https://arxiv.org/html/2605.08195#bib.bib10))：(1) 形状健全性：捕获图中的形状满足由每个运算符的语义定义的形状规则；(2) 图规范化：图中不包含 Python 语义，节点仅限于定义的运算符集；(3) 张量元数据可用性：输入、中间值和输出的形状元数据可用；(4) 程序元数据可用性：来源信息记录原始程序的 `torch.nn`