边缘端部署这件事，每次跟人聊起来都有人叹气。不是模型跑不动，是工具链太碎了。TorchScript 要兼容语法，ONNX 要处理算子映射，TFLite 绑定了 TF 生态。每多一层中间格式，就多一个出错的可能。
pytorch/export 这个 Smithery Skill 做的事非常窄，也正因为窄，它够直接。它就是 ExecuTorch 导出流程的一个封装，把 PyTorch 模型变成 .pte 文件，一条链路走到底。不经过 ONNX，不经过 TorchScript，中间没有任何第三方 IR。
但看数据很有意思。Smithery 上这个 Skill 被浏览了四千多次，安装量只有三十。差了两个数量级。这个数字本身就在说一件事：知道边缘部署重要的人很多，真正动手在做的人很少。工具链的复杂度劝退了大部分。
说真的，这篇文章不打算把 ExecuTorch 的十二种后端都讲一遍。我就把这个 Skill 的导出链路拆开看看，每一步在做什么、哪里容易卡住、跟 TorchScript 和 ONNX 的差别到底在哪。如果你正在琢磨怎么把模型搬到手机上，应该能省不少试错时间。
环境准备
前置条件不复杂。Python 3.10 以上，PyTorch 2.2 以上，外加一个 executorch 包。
pip install executorch
跑完验证一下，能 import 就没问题：
python -c "import executorch; print('executorch ready')"
Windows 用户需要注意，executorch 的完整功能在 Linux 和 macOS 上支持更好，Core ML 这类硬件后端只在 macOS 上可用。如果你主力机是 Windows，建议在 WSL 或者远程 Linux 环境里跑导出流程。
还有一个容易被忽略的细节：模型必须调到 eval 模式。训练态的 batch norm 和 dropout 行为跟推理态不一样，导出前忘了调 model.eval() 是新手最常见的卡点。ExportedProgram 在导出时会对模型做一次完整 trace，训练态的随机性会让 trace 结果不可复现，最后的表现就是导出的 .pte 跑出来结果跟 Python 端不一致。
操作流程
这个 Skill 的导出链路只有三步，但每一步背后都有值得展开的东西。先看完整代码：
from executorch.exir import to_edge_transform_and_lower
from torch.export import export
exported = export(model.eval(), example_inputs)
edge = to_edge_transform_and_lower(exported)
with open("model.pte", "wb") as f:
f.write(edge.to_executorch().buffer)
第一步，export。torch.export.export(model, inputs) 走 Dynamo tracer，把模型的前向计算图完整抓下来。跟 torch.jit.trace 的关键差别在于，新版 export 用 Dynamo 做图捕获，能正确处理 Python 原生控制流。trace 遇上 if 分支只记录一条路径，Dynamo 会把分支结构保留在导出图中。
第二步，lower。to_edge_transform_and_lower 做两件事。先把导出图转成 ExecuTorch 需要的 edge dialect，然后按指定的 backend 做算子分区。比如传 XnnpackPartitioner()，它会自动识别 CPU 上能加速的卷积和矩阵乘法，交给 XNNPACK。不支持的算子留在 portable fallback 里，用纯 CPU 跑，不会因为一个算子不支持就让整个部署流程崩掉。
第三步，序列化。.to_executorch().buffer 输出二进制 buffer，写进 .pte 文件就完事。这个 .pte 就是最终交给移动端 runtime 的东西，C++、Swift、Kotlin 都能加载。
动态形状是另一个高频需求。如果你希望模型在运行时接受不同尺寸的输入，必须在导出时声明 bounds：
from torch.export import Dim
dynamic_shapes = {"x": {0: Dim("batch", max=64)}}
export(model, inputs, dynamic_shapes=dynamic_shapes)
不声明的话，export 假设输入尺寸固定，会基于固定尺寸做大量优化。好处是快，坏处是换个尺寸就崩溃。声明 bounds 时注意上限别设太高，ExecuTorch 会根据上限预分配内存，设得越大内存占用越大。
调试方面，这个 Skill 的 SKILL.md 给了一个很实用的入口：strict=False。严格模式是默认的，遇到不合规算子直接报错。但有时候你只想先看看图长什么样，不想被错误淹没，draft export 就很实用。配合 TORCH_LOGS="+dynamo,+export" 和 tlparse 工具，能把 trace 日志可视化，定位问题比盲猜快得多。
关键设计
这个 Skill 最值得说的设计选择，是它完全站在 ExecuTorch 的原生路径上，拒绝做任何格式转换。
做过模型部署的人都知道，格式转换是最大的不确定性来源。PyTorch 转 ONNX 要处理算子兼容性，ONNX 再转 TensorRT 又要调 opset 版本，每一步都可能掉精度。ExecuTorch 的策略是直接从 PyTorch FX Graph 出发，Dynamo 捕获的图就是最终的中间表示。没有中间商赚差价。
但代价也很明显。这个 Skill 目前只服务 ExecuTorch 生态。如果你的目标是 NVIDIA GPU 上的服务端推理，这条路不通，你得回到 ONNX 加 TensorRT 那条线。ExecuTorch 的定位就是边缘设备（手机、嵌入式、IoT），它那个 50KB 的最小 runtime 就是为这个场景设计的。
后端分区器的设计也有巧思。它不是“整个模型要么全加速要么全不加速”的粗暴逻辑，而是按算子粒度做分区。模型里 XNNPACK 能加速的部分交给 XNNPACK，其余留给 portable fallback。这种“部分加速加完整覆盖”的策略是刻意为之，允许在不完美的硬件支持上实现尽可能好的性能。
还有一个经常被忽略的约束：同一个模型部署到不同硬件，需要生成不同的 .pte 文件。iOS 上的 Core ML 和 Android 上的 XNNPACK 不共享同一个 .pte。这个设计增加了构建流程的复杂度，一模型一后端一文件，但对面向数十亿用户的产品来说，用构建时的复杂度换运行时的最优性能，这笔账是算得过来的。
使用场景
LLM 的端侧部署是这个 Skill 最典型的用武之地。
Llama 模型从 PyTorch checkpoint 到手机上能跑的 .pte，完整链路就是导出、降低、序列化三步。ExecuTorch 甚至给 Llama 提供了一个独立的一键导出脚本 export_llm.py，把动态形状配置和 attention 优化都内置了。跑完直接拿到 .pte，用 ExecuTorch 提供的 C++ 或 Swift 或 Kotlin runtime 加载就能推理。
语音模型是另一个快速增长的方向。Whisper 和 Parakeet（Meta 的端侧语音识别模型）都提供了模型专属的导出脚本。这类模型对延迟极其敏感，用户说一句话等三秒才有反馈，体验直接崩。端侧推理把延迟从网络往返时间压到了本地计算时间，效果的提升是立竿见影的。
但也不是所有模型都适合走这个链路。如果你的模型用了大量自定义算子，或者依赖了 ExecuTorch 还不支持的 PyTorch 特性，export 的 strict 模式会直接失败。draft export 能帮你看清问题在哪，但修起来可能要改模型结构。ExecuTorch 的算子覆盖还在快速补全中，现阶段遇到不支持的情况不是小概率事件，需要有心理准备。
洞察与反思
四千浏览对三十安装，这个比例让我重新想了想边缘部署的现状。
边缘端 AI 不缺需求。
-
手机上的实时翻译 -
智能相册里的图片搜索 -
唤醒后立刻响应的语音助手
这些场景对端侧推理的需求真实且迫切。但从数据上看，真正动手把模型部署到端上的团队，比例低得惊人。问题不在模型本身。PyTorch 生态里做端侧部署的选择看起来很多，但实际用起来每个都有坑。
TorchScript 的 trace 在遇到 if/else 时只记录一条分支，这在动态模型上是致命的。ONNX 的算子映射永远差几个，版本升级还经常引入不兼容。TFLite 绑定了 TensorFlow 生态，对 PyTorch 用户不友好。ExecuTorch 走了另一条路：直接从 PyTorch 原生图出发，不转换，只优化。
但它的生态还在早期。三十次安装说明真正的早期采用者还不够多。这个数字在一年后能不能增长一个数量级，取决于 ExecuTorch 的算子覆盖速度和文档完善程度。Meta 已经把这条路在内部跑通了（几十亿用户规模），但外部开发者要跟上还需要时间。
说到这，可能跟你预期的方向不太一样。边缘部署的瓶颈不是模型效果，是工具链的成熟度。ExecuTorch 目前在正确的方向上，但它能不能成为 PyTorch 端侧部署的默认选择，还得看未来一年社区和 Meta 的推进速度。
资源地址
| 资源 | 地址 |
|---|---|
| Smithery Skill | https://smithery.ai/skills/pytorch/export |
| ExecuTorch GitHub | https://github.com/pytorch/executorch |
| ExecuTorch 文档 | https://pytorch.org/executorch |
| torch.export 文档 | https://pytorch.org/docs/stable/export.html |
总结
三步导出，三行代码。export → to_edge_transform_and_lower → to_executorch 这个链路本身不复杂，但它的真正价值在于省略了一整条格式转换流水线。少一层中间格式，就少一个掉精度的可能。
如果你正在评估把模型搬到端上的方案，这个 Skill 值得放进候选列表。它不解决所有问题，但它在解决正确的问题。移动端推理的最后一公里，就是从这个 .pte 文件开始的。
说了这么多，其实就想表达一件事。别在工具链选择上耗太久，拿一个你最熟悉的 PyTorch 模型，跑一遍导出看看。三分钟内拿到一个能用的 .pte，你就知道这条路适不适合你了。