PyTorch a publié l'ExecuTorch MLX Delegate le 18 mai — un nouveau backend ExecuTorch qui compile et roule les modèles PyTorch sur les GPU Apple Silicon via le framework MLX d'Apple. Throughput rapporté 3-6× plus haut sur les workloads generative AI comparé aux delegates ExecuTorch existants sur macOS. La toolchain est standard : export avec `torch.export`, lower avec `to_edge_transform_and_lower` en utilisant le `MLXPartitioner`, rouler le fichier `.pte` résultant avec le runtime ExecuTorch. Couverture de modèles supportés : 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, plus les modèles de speech Whisper, NVIDIA Parakeet TDT et Mistral Voxtral avec streaming offline et real-time. Le delegate est expérimental et sous développement actif. github.com/pytorch/executorch.

La significance architecturale c'est le pont entre la stack d'export de PyTorch et le runtime ML natif d'Apple. Avant ça, faire rouler des modèles PyTorch sur Mac voulait dire : le backend MPS de PyTorch (Metal, correct mais pas best-in-class), conversion vers CoreML (natif Apple mais demande la pipeline de conversion), llama.cpp ou Ollama (runtime séparé, pas dans l'écosystème PyTorch), ou MLX directement (le framework d'Apple mais demande de réécrire le modèle). Le MLX Delegate te laisse rester en PyTorch land — même `torch.export`, même quantization TorchAO, même runtime ExecuTorch — et avoir de la performance GPU native Apple à travers les kernels Metal de MLX. Les 90 ATen ops que le delegate supporte actuellement, c'est la contrainte de gating : tout ce qui se décompose en ces ops roule ; les ops customs ou les décompositions non-supportées tombent sur d'autres paths ou plantent.

Positionne ça dans la stack d'infrastructure on-device AI. Les Foundation Models d'Apple et CoreML couvrent l'inférence native Apple ; llama.cpp et Ollama dominent l'exécution LLM quantizée sur hardware consumer ; MLX c'est le framework array d'Apple. Le MLX Delegate fait de PyTorch un citoyen first-class sur Mac pour la generative AI, avec la même toolchain que les utilisateurs Linux/server ont. Le chiffre 3-6× c'est contre les delegates ExecuTorch macOS existants spécifiquement — pas contre MPS, pas contre CoreML, pas contre llama.cpp. La comparaison honnête, ce serait MLX-Delegate vs Ollama pour le même modèle sur le même Mac ; ce benchmark est pas dans le writeup. Ce qui est concret : la couverture MoE (Qwen 3.5 35B-A3B) est rare pour les runtimes on-device, et le support de streaming de speech en real-time (Voxtral) est non-trivial à engineer.

Lundi matin : si tu shippes des modèles PyTorch qui ont besoin de rouler sur Mac dans le contexte consumer ou developer-machine, le MLX Delegate c'est le path d'export à essayer — commence avec une des familles de modèles supportées (Llama, Qwen, Phi, Gemma) et benchmark contre ton path MPS ou CoreML actuel. Si tu maintains des ops customs qui se décomposent en primitives ATen, check si ta décomposition fit dans le support set des 90 ops ; si non, t'auras un offload partiel au mieux. Le tag expérimental compte : les APIs et features supportées vont changer, donc bake pas le MLX Delegate dans un path load-bearing en prod tout de suite. La question long-terme c'est si MLX devient le backend GPU par défaut pour PyTorch sur Mac — ça dépend de la trajectoire de stabilité du delegate et si Apple contribue plus profondément au repo PyTorch upstream. Watch le GitHub ExecuTorch pour la promotion d'expérimental à stable sur les 2-3 prochains releases ExecuTorch.