PyTorch 5 月 18 日发布了 ExecuTorch MLX Delegate —— 一个新的 ExecuTorch 后端,把 PyTorch 模型通过Apple 的 MLX 框架编译并跑在 Apple Silicon GPU 上。报告在生成式 AI 工作负载上吞吐量比现有 macOS 的 ExecuTorch delegate 高 3-6×。工具链是标准的:用 `torch.export` 导出、用 `to_edge_transform_and_lower` 加 `MLXPartitioner` lower、用 ExecuTorch runtime 跑出来的 `.pte` 文件。支持的模型:Llama 3.2 1B、Qwen 3(0.6B、1.7B、4B)、Phi-4 mini(3.8B)、Gemma 3(1B、4B)、Qwen 3.5 35B-A3B Mixture-of-Experts,加上语音模型 Whisper、NVIDIA Parakeet TDT、Mistral Voxtral(离线和实时流)。Delegate 处于实验阶段、在活跃开发中。github.com/pytorch/executorch。
架构上的意义是 PyTorch 的导出栈和 Apple 原生 ML runtime 之间的桥。在这之前,在 Mac 上跑 PyTorch 模型的选项是:PyTorch 的 MPS 后端(Metal,还行但不是最优),转 CoreML(Apple 原生但要走转换 pipeline),llama.cpp 或 Ollama(独立 runtime,不在 PyTorch 生态里),或者直接用 MLX(Apple 的框架但得把模型重写)。MLX Delegate 让你留在 PyTorch 这边 —— 同一个 `torch.export`、同一个 TorchAO 量化、同一个 ExecuTorch runtime —— 同时通过 MLX 的 Metal kernel 拿到 Apple 原生 GPU 的性能。当前支持的 90 个 ATen op 是关卡:能分解成这些 op 的就跑;自定义 op 或者无法支持的分解会 fall back 或失败。
把这件事放到设备端 AI 基础设施栈里看。Apple 的 Foundation Models 和 CoreML 覆盖 Apple 原生推理;llama.cpp 和 Ollama 在消费级硬件上主导量化 LLM 执行;MLX 是 Apple 的 array 框架。MLX Delegate 让 PyTorch 在 Mac 上成了生成式 AI 的一等公民,工具链跟 Linux/服务器用户的一样。3-6× 这个数是专门跟现有 macOS 上的 ExecuTorch delegate 比的 —— 没跟 MPS 比、没跟 CoreML 比、没跟 llama.cpp 比。诚实的对比应该是同一台 Mac、同一个模型,MLX-Delegate vs Ollama;这个 benchmark 写法里没有。具体的部分是:MoE 的覆盖(Qwen 3.5 35B-A3B)在设备端 runtime 里少见,而且语音的实时流支持(Voxtral)工程上不简单。
周一上手:如果你交付的 PyTorch 模型需要在 Mac 上跑(消费者或开发者机器场景),MLX Delegate 是值得试一下的导出路径 —— 先从一个支持的模型家族(Llama、Qwen、Phi、Gemma)开始,跟你现有的 MPS 或 CoreML 路径 benchmark 一下。如果你在维护一些自定义 op、它们会分解到 ATen 原语,检查一下你的分解是不是 fit 在那 90 op 的支持集里;如果不 fit,最好的情况也就是 partial offload。实验性这个标签很重要:API 和支持的功能还会变,所以暂时别把 MLX Delegate 塞到承重的生产路径里。长期问题是 MLX 会不会成为 PyTorch 在 Mac 上的默认 GPU 后端 —— 这要看 delegate 的稳定性轨迹,以及 Apple 是否会更深地往 PyTorch 上游贡献。盯紧 ExecuTorch GitHub,看接下来 2-3 个 ExecuTorch release 里它有没有从实验阶段晋升到稳定。