Google publica TorchTPU como código abierto y el TorchNeuron de Amazon entra en beta

Google publicó TorchTPU como código abierto el martes 20 de octubre, el día inaugural de la PyTorch Conference en San José, y convirtió sus Tensor Processing Units en un destino nativo para el código PyTorch. TorchNeuron, de Amazon, anunciado el día anterior, entró en beta pública ese mismo día para Trainium2 y Trainium3. En la versión de Google, un modelo pasa a una TPU cambiando la cadena de dispositivo; en la de Amazon, el cambio del ejemplo de la compañía es model.to('neuron'). Ambos están en GitHub y ambos atacan el mismo coste: el tiempo de ingeniería que un equipo dedica a hacer que una base de código PyTorch funcione en algo que no es hardware de Nvidia.

Lectura relacionada: Amazon busca desprenderse de 8.000 millones en chips de Nvidia mediante un vehículo financiero · DeepSeek libera como código abierto una pila de software para los chips Ascend de Huawei, con la vista puesta en CUDA.

Ninguno es un chip nuevo. Cada uno es un backend de software que se sitúa entre PyTorch y un acelerador, intercepta las operaciones del framework y las convierte en algo que el chip puede ejecutar. TorchTPU apunta a las TPU y TorchNeuron a Trainium. Ambos se enganchan mediante el punto de extensión PrivateUse1 de PyTorch, el mecanismo que permite a un fabricante de hardware registrar un dispositivo sin hacer un fork del framework. Ese punto de extensión explica por qué dos nubes rivales pudieron publicar backends nativos en la misma semana. Ninguna de las dos es dueña de PyTorch.

Qué contienen realmente las dos publicaciones

TorchTPU es el proyecto más antiguo. Google dice que el trabajo empezó a mediados de 2025 con el equipo de PyTorch de Meta, y el blog de PyTorch lo describe como «una colaboración de código abierto entre Google y Meta que presenta un backend de PyTorch nativo y bien fundamentado para las TPU de Google». Sustituye la ruta anterior a través de PyTorch/XLA, que Google presentó en 2020 sobre tensores perezosos. Esa versión obligaba a los desarrolladores a marcar regiones compilables en el código fuente, tenía tiempos de compilación largos y no admitía el modo de ejecución eager de PyTorch. TorchTPU se ejecuta en modo eager por defecto, admite torch.compile, registra unos 450 operadores Aten e implementa las colectivas de TPU a nivel de grupo de procesos, de modo que el código distribuido escrito para DTensor, FSDP y API similares funciona sin una biblioteca de comunicación aparte.

El anuncio de Google enumera cuatro repositorios: el propio TorchTPU, además de backends de TPU para vLLM y SGLang y una integración con TorchTitan. Los motores de servicio importan más que el titular. vLLM y SGLang son dos de los principales motores para servir modelos de pesos abiertos, y un backend que solo funcionara dentro de un script de entrenamiento dejaría la inferencia en las GPU. Google también menciona integraciones con llm-d 1.0, Ray, TorchRec, Hugging Face Transformers v5, donde device_map="tpu" carga un modelo en una TPU, y LiteRT, su entorno de ejecución en dispositivo, que se unió al ecosistema PyTorch. Una suite de agentes para TPU en vista previa pretende responder preguntas de migración y corregir errores durante una adaptación.

La afirmación sobre cobertura es concreta; la de rendimiento no lo es. Google dice que validó 4.917 de los modelos de Hugging Face más descargados en más de 500 familias de arquitecturas, y la entrada de PyTorch afirma que TorchTPU ya se usa en producción para inferencia y entrenamiento por «algunos de los mayores clientes de Google Cloud», sin nombrarlos. Ejecutar un modelo tal cual y ejecutarlo bien son resultados distintos, y el propio texto de Google señala que el máximo rendimiento exige formas, sharding y operadores alineados con la arquitectura de la TPU.

«Con TorchTPU, las TPU se suman a las GPU y las CPU como opción nativa para PyTorch.» — Mark Lohmeyer y Bill Jia, Google Cloud, 20 de octubre de 2026

El anuncio de Amazon es más estrecho, y su documentación es más explícita sobre las carencias. TorchNeuron registra Trainium como un dispositivo neuron, admite eager y torch.compile, expone herramientas para kernels personalizados a través de la Neuron Kernel Interface y envía datos de perfilado mediante el torch.profiler estándar a un visor llamado Neuron Explorer. Admite DDP, FSDP2, paralelismo de tensores y de pipeline, DTensor y DeviceMesh. Hugging Face añadió compatibilidad con Trainium en Transformers, Diffusers, TRL y su biblioteca de kernels, así que device_map="neuron" también funciona allí. El paquete es pip install torch-neuronx, y el código está bajo Apache 2.0 en aws-neuron/torch-neuronx.

Las carencias las documenta Amazon, no las descubren los críticos. La primera versión no admite formas dinámicas ni simbólicas, tensores dispersos, autograd en modo forward ni varias funciones menores. En una ejecución de agosto de 2026 de las suites de pruebas upstream de PyTorch, Amazon registró unos 154.000 resultados de pruebas. Unos 69.000 se omitieron por un motivo válido y unos 39.000 fueron omisiones deliberadas de Neuron; el grupo mayor, alrededor de 22.000, eran operadores sin implementación nativa en Neuron. TNW resumió el mismo material como unas 22.000 pruebas de PyTorch omitidas. Ambas cifras son correctas: una cuenta toda la suite y la otra solo las omisiones que apuntan a una cobertura de operadores ausente.

Una línea de código, y los meses que la rodean

La cadena de dispositivo es la demostración, no la migración. El texto de Google dice que un cambio de una línea pone un modelo en marcha, y luego añade la advertencia sobre el máximo rendimiento. La demostración de Amazon ejecutó el mismo script de entrenamiento en Trainium y en un chip convencional y afirmó que el modelo aprendió «las mismas cosas al mismo ritmo»; no se publicaron cifras de rendimiento, coste ni convergencia.

Lo que ha cambiado es la dirección del trabajo. Antes de estos backends, migrar a TPU o a Trainium significaba adaptarse a una pila específica del fabricante, reescribir kernels, revalidar los cálculos numéricos y mantener un fork frente al PyTorch upstream. Ahora el primer intento es un cambio de configuración y el trabajo restante es el ajuste. Es una factura más pequeña en un momento en que los compradores vigilan los costes. Amazon habla de tiempo de ingeniería. Google habla de elegir entre TPU, GPU y CPU bajo un mismo modelo operativo.

El reportaje de TechCrunch sobre la pareja expuso la lectura estratégica sin rodeos: «Amazon y Google están claramente trabajando para acabar con la ventaja de Nvidia». El mismo artículo añadía que nada de esto significa que los desarrolladores vayan a abandonar en masa el hardware de Nvidia. Un fabricante puede eliminar una barrera sin ganar al cliente.

La participación de Meta apunta a la opcionalidad. Jana van Greunen, directora de ingeniería de PyTorch en Meta, dijo que TorchTPU permite a Meta «desplegar nuestras cargas de trabajo de PyTorch en las TPU de Google, dar retroalimentación directa a los equipos de ingeniería y construir la flexibilidad de ecosistema que todos necesitamos». Eso describe una segunda vía a producción, no una salida de Nvidia. Meta codiseñó el backend.

Los intereses comerciales son lo bastante grandes para explicar la coordinación. Amazon dice que su negocio de chips personalizados superó una tasa de ingresos anuales de 25.000 millones de dólares, y su consejero delegado, Andy Jassy, afirmó en abril de 2026 que podría valer 50.000 millones (TNW). Google anunció sus TPU de octava generación en abril de 2026, con la 8t para entrenamiento y la 8i para inferencia, y tiene un acuerdo ampliado con Anthropic por varios gigavatios de capacidad de TPU. Según Yahoo Finance, también trabaja para suministrar a OpenAI. Cada carga de trabajo que se ejecute en esos chips sin reescritura es capacidad que la nube puede llenar con silicio que controla.

Los benchmarks son de los fabricantes

La cifra estrella de Google es real pero estrecha. Dice que TorchTitan, su pila de referencia de entrenamiento, alcanzó hasta un 52 por ciento de utilización de FLOPs de modelo en Qwen 3 8B al escalar a 8.192 TPU Ironwood, y que el nuevo modo eager DeferAndFuse puede ser un 50 por ciento o más rápido que la ejecución eager estricta. Ambas son mediciones de Google, en hardware de Google, con la configuración de software de la compañía. Son prueba de que la pila de software es menos cuello de botella que antes. No demuestran que una TPU sea más rápida o más barata que una GPU para un trabajo concreto.

La cifra más útil de Amazon viene de un cliente, no de una suite. Deepgram, que vende modelos de voz, aparece citada diciendo que Trainium procesa «alrededor de un 60 por ciento más de segundos de audio de entrada por dólar que nuestras líneas base actuales de GPU» tras una migración de varios meses. La línea base es la propia flota de Deepgram, no una pieza concreta de Nvidia, y la medida son segundos de audio por dólar en una carga de voz. Es significativo para quien sirva voz y no es un resultado general.

Por qué un backend no deshace CUDA

Un backend elimina una capa de coste de cambio. No elimina las demás. La ventaja de CUDA no es una única API que PyTorch pueda abstraer. Es el conjunto acumulado de bibliotecas, kernels ajustados, perfiladores, depuradores y respuestas a los problemas de otros que se ha construido alrededor del hardware de Nvidia durante más de una década. Un equipo con un kernel de atención personalizado, un optimizador fusionado y un año de trabajo de rendimiento tiene activos que una cadena de dispositivo no traslada.

El material de lanzamiento lo concede en algunos puntos. El texto de Google sobre TorchTPU dice que su implementación colectiva por defecto compila cada colectiva en un módulo separado, lo que puede costar entre un 30 y un 40 por ciento de extremo a extremo, y que las formas dinámicas acotadas aún se están construyendo; torch.compile fuerza actualmente dynamic=False. La primera versión de TorchNeuron omite las formas dinámicas y las demás funciones citadas. Código abierto no significa terminado. TorchNeuron es una beta pública, y la documentación de Google describe una madurez que varía según la función.

PyTorch es ahora terreno neutral. Meta escribió el framework en 2016 y lo transfirió a la Linux Foundation en 2022, así que un backend de Google o de Amazon puede llegar como trabajo de ecosistema en lugar de un desvío propietario. La conferencia de la fundación es donde aterrizaron ambos lanzamientos. Ese arreglo da a los fabricantes una razón para mejorar la capa compartida: una corrección que llega a PyTorch ayuda a su hardware sin pedir a los desarrolladores que adopten una pila de fabricante.

El trabajo más consecuente puede estar en las pull requests. Amazon dice que está enviando cambios a PyTorch principal para eliminar suposiciones de CUDA codificadas de forma rígida, y la entrada de TorchNeuron los enumera. Google contribuyó LiteRT al ecosistema PyTorch y trabajó a través de Hugging Face, vLLM y SGLang en lugar de rodearlos. Esos cambios son lo que abarataría la próxima migración.

Qué contaría como prueba

Un benchmark independiente resolvería más que cualquiera de las dos entradas de lanzamiento. La prueba es fácil de especificar: el mismo modelo, tamaños de lote y precisión, medidos en una TPU, una instancia de Trainium y una GPU de Nvidia, con el coste por token incluido. Un cliente con nombre que describiera una migración completada y la factura antes y después tendría un peso similar. También lo tendría el código upstream fusionado: cobertura de operadores y cambios agnósticos del dispositivo aceptados en PyTorch en lugar de quedarse en un repositorio de fabricante.

Salvedades

Los dos lanzamientos son anuncios de software, no resultados de rendimiento. Ninguna de las dos compañías publicó cifras independientes y comparables de rendimiento de ninguna de las dos pilas en un modelo común frente a hardware de Nvidia. TorchNeuron es una beta pública con carencias de funciones documentadas, y la documentación de TorchTPU describe una madurez variable, una penalización declarada en su ruta colectiva por defecto y trabajo inacabado en formas dinámicas. La cifra del «85 por ciento» que aparece en la cobertura no es un solo número: Amazon dice que el 85 por ciento de los investigadores y desarrolladores de IA escriben en PyTorch, mientras que TechCrunch dice que PyTorch lo usan el 85 por ciento de las aplicaciones de IA «según algunos cálculos». Ambas están atribuidas y miden poblaciones distintas. La migración también será gradual: un backend abarata probar un segundo proveedor, y las compras siguen rigiéndose por el coste medido por token y por las fechas de entrega.

Los dos backends pueden descargarse ya. El benchmark que resolvería cuánto vale la migración aún no se ha publicado.

Imagen de portada: «Google Data Center, Council Bluffs Iowa», de Chad Davis, CC BY 2.0, vía Wikimedia Commons.