PyTorch publicó el ExecuTorch MLX Delegate el 18 de mayo — un nuevo backend ExecuTorch que compila y corre modelos PyTorch en GPUs Apple Silicon vía el framework MLX de Apple. Throughput reportado 3-6× más alto en cargas de AI generativa comparado a delegates ExecuTorch existentes en macOS. La toolchain es estándar: exporta con `torch.export`, baja con `to_edge_transform_and_lower` usando el `MLXPartitioner`, corre el archivo `.pte` resultante con el runtime ExecuTorch. Cobertura de modelos soportados: 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, más modelos de voz Whisper, NVIDIA Parakeet TDT y Mistral Voxtral con streaming offline y en tiempo real. El delegate es experimental y bajo desarrollo activo. github.com/pytorch/executorch.

La significancia arquitectónica es el puente entre la pila de exportación de PyTorch y el runtime ML nativo de Apple. Antes de esto, correr modelos PyTorch en Mac significaba: el backend MPS de PyTorch (Metal, decente pero no el mejor), conversión a CoreML (nativo de Apple pero requiere el pipeline de conversión), llama.cpp u Ollama (runtime separado, no en el ecosistema PyTorch), o MLX directamente (el framework de Apple pero requiere reescribir el modelo). El MLX Delegate te deja quedarte en tierra PyTorch — el mismo `torch.export`, la misma cuantización TorchAO, el mismo runtime ExecuTorch — y obtener rendimiento GPU nativo de Apple a través de los kernels Metal de MLX. Las 90 ATen ops que el delegate soporta actualmente es la restricción de compuerta: cualquier cosa que se descomponga a esas ops corre; ops customs o descomposiciones no soportadas caen a otros caminos o fallan.

Posiciona esto en la pila de infraestructura AI on-device. Los Foundation Models de Apple y CoreML cubren inferencia nativa Apple; llama.cpp y Ollama dominan la ejecución LLM cuantizada en hardware de consumo; MLX es el framework array de Apple. El MLX Delegate hace a PyTorch un ciudadano de primera clase en Mac para AI generativa, con la misma toolchain que tienen los usuarios Linux/server. El número 3-6× es contra delegates ExecuTorch macOS existentes específicamente — no contra MPS, no contra CoreML, no contra llama.cpp. La comparación honesta sería MLX-Delegate vs Ollama para el mismo modelo en el mismo Mac; ese benchmark no está en el writeup. Lo que es concreto: la cobertura MoE (Qwen 3.5 35B-A3B) es rara para runtimes on-device, y el soporte de streaming de voz en tiempo real (Voxtral) es no trivial de ingeniar.

Lunes: si envías modelos PyTorch que necesitan correr en Mac en el contexto consumer o developer-machine, el MLX Delegate es el camino de exportación para probar — empieza con una de las familias de modelos soportadas (Llama, Qwen, Phi, Gemma) y haz benchmark contra tu camino MPS o CoreML actual. Si mantienes ops customs que se descomponen a primitivas ATen, verifica si tu descomposición cabe en el set de soporte de 90 ops; si no, obtendrás offload parcial en el mejor de los casos. El tag experimental importa: APIs y características soportadas cambiarán, así que no horneas el MLX Delegate en un camino load-bearing de producción todavía. La pregunta de largo plazo es si MLX se vuelve el backend GPU por defecto para PyTorch en Mac — eso depende de la trayectoria de estabilidad del delegate y si Apple contribuye más profundamente al repo PyTorch upstream. Vigila el GitHub de ExecuTorch para promoción de experimental a estable en los próximos 2-3 releases de ExecuTorch.