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 裡它有沒有從實驗階段晉升到穩定。