Google y Meta abren el código de TorchTPU

El día de la PyTorch Conference 2026, Google Cloud anunció que TorchTPU, desarrollado junto con el equipo de PyTorch de Meta, ya tiene su código abierto en GitHub. Según Google, la TPU pasa a ser, igual que la GPU y la CPU, una opción de dispositivo nativa de PyTorch, y el código existente funciona prácticamente sin cambios.

El anuncio lo firman Mark Lohmeyer, vicepresidente de IA e infraestructura de cómputo de Google Cloud, y Bill Jia, vicepresidente de ingeniería. El repositorio está en la organización google-pytorch; los back-ends de vLLM y SGLang que lo acompañan se incorporaron a las organizaciones de cada proyecto.

Un código abierto, una cadena de frameworks conectados

TorchTPU admite depuración en modo eager y también puede apoyarse en torch.compile para aumentar el aprovechamiento de la TPU y reducir el consumo de memoria. Ese mismo día se integraron numerosos proyectos de capas superiores e inferiores:

  • Inferencia: vLLM y SGLang tienen cada uno un back-end nativo de PyTorch. El primero admite batching continuo, cuantización y paralelismo multichip; el segundo usa RadixAttention para reutilizar la caché KV. llm-d 1.0, lanzado junto con Red Hat e IBM, se encarga del enrutamiento consciente de la caché de prefijos y de la separación entre prefill y decode.
  • Entrenamiento: TorchTitan ya validó modelos como Llama 3 70B/405B, Qwen 3 8B/32B, Qwen 3 235B (MoE) y FLUX.1 12B; el framework de aprendizaje por refuerzo VeRL incorporó un back-end de TPU y una receta de referencia de GRPO, por ahora en versión preliminar.
  • Ecosistema: Hugging Face Transformers v5 carga modelos en TPU con una sola línea, device_map="tpu", y además cuenta con una integración continua en TPU que se ejecuta cada noche; Ray puede combinar CPU, GPU y TPU en una misma canalización.

Google ofrece dos grupos de cifras de rendimiento. TorchTitan alcanza un 52 % de MFU con Qwen 3 8B y escala de forma casi lineal hasta 8192 chips Ironwood (TPU v7x). La socia Zenteiq, con llm-d y GKE, pasó de 1470 millones a 5970 millones de tokens generados al día por cada 1000 TPU v6e, una mejora de más de 4 veces. Ambos grupos proceden de mediciones propias de Google o de sus socios, y el anuncio no incluye la configuración completa para reproducirlos.

Por qué Meta respalda el proyecto

Jana van Greunen, directora de ingeniería de PyTorch en Meta, aportó una declaración en el anuncio:

"We cannot be constrained by a single hardware architecture."

No podemos quedar atados a una única arquitectura de hardware.

Ella señaló que TorchTPU ya sostiene “escenarios críticos de producción” en los grandes modelos, la publicidad y los sistemas de recomendación de Meta. Cuántas TPU se usan y qué proporción de la capacidad de cómputo de Meta representan no se reveló esta vez. Hugging Face, Inferact (la empresa detrás de vLLM) y RadixArk (detrás de SGLang) también emitieron declaraciones, todas centradas en la “diversidad de hardware”.

La misma semana, AWS también presentó la suya

Si se pone TorchTPU junto a TorchNeuron, anunciado por AWS el día anterior, se ve que ambas compañías siguen el mismo camino. TorchNeuron es el back-end nativo de PyTorch para Trainium, de código abierto bajo Apache 2.0, en Beta pública desde el 20 de octubre y compatible con Trainium2 y Trainium3; al usuario le basta con .to('neuron'). También presenta Transformers v5 y TorchTitan como carta de presentación, y el mismo director de ingeniería de PyTorch de Meta firmó además un testimonio para AWS.

La diferencia está en los detalles. AWS hizo público su criterio de prueba: una prueba ciega con 100 000 modelos de Hugging Face y unos 154 000 resultados de las pruebas upstream de PyTorch, de los cuales unos 39 000 fueron omitidos a propósito por Neuron, incluidas funciones que la primera versión no admite, como tensores dispersos y formas dinámicas. Google solo enumeró la lista de compatibilidad; qué operadores vuelven a la CPU y qué funciones faltan no aparece en el anuncio con un nivel de detalle equivalente.

Ambas dependen de las interfaces independientes del dispositivo que la comunidad de PyTorch ha construido en los últimos años, como el punto de extensión PrivateUse1 y torch.accelerator. Hasta ahora, quien quería usar TPU con PyTorch dependía sobre todo de PyTorch/XLA, que traduce el código a través del compilador XLA, y su experiencia de depuración siempre fue criticada. Con el back-end nativo, la barrera de migración baja de “cambiar el código” a “cambiar el nombre del dispositivo”.

Para los desarrolladores, la prueba más realista son los modelos que no figuran en la lista oficial de validación. La documentación de TorchTPU solo menciona los modelos de TPU v6e e Ironwood; si las generaciones anteriores funcionan y con qué rendimiento, Google aún no lo ha aclarado. El plugin de agente de TPU que lo acompaña también sigue en una fase muy temprana de vista previa.

Fuentes: blog oficial de Google Cloud, blog oficial de PyTorch (anuncio de TorchNeuron), CocoLoop, repositorio de TorchTPU en GitHub; las cifras de MFU y de rendimiento siguen el criterio de medición propia de Google y sus socios.