Google anunció este 20 de octubre de 2026, durante PyTorch Conference, que TorchTPU ya está disponible como código abierto en GitHub. Desarrollado junto con el equipo de PyTorch de Meta, permite ejecutar cargas de PyTorch de forma nativa en las TPUs de Google con cambios mínimos de código, según el anuncio de Google Cloud.

💻 La idea es conservar las APIs que ya conoces: usar torch.device("tpu"), depurar en modo eager y optimizar mediante torch.compile con XLA, sin reescribir el modelo en JAX. TorchTPU trabaja con tensores normales de PyTorch, primitivas distribuidas como torch.distributed y herramientas del ecosistema como Ray, TorchRec, Hugging Face y LiteRT.

🛠️ Para servir modelos, Google lanzó nuevos backends de vLLM y SGLang basados en PyTorch, desarrollados con Inferact y RadixArk, respectivamente; antes ya existían rutas para TPU basadas en JAX. Los nuevos motores conservan los planificadores, servidores de API y administradores de caché de cada proyecto, mientras agregan kernels Pallas y optimizaciones para TPU, como detalla el anuncio de los motores de inferencia.

⚙️ Para coordinar muchos servidores llegó llm-d 1.0, un stack abierto y nativo de Kubernetes que Google impulsa con Red Hat, IBM y una comunidad de más de 500 colaboradores de 25 organizaciones. El proyecto, alojado en CNCF Sandbox, puede dirigir solicitudes hacia réplicas que ya guardan su contexto y separar el procesamiento inicial del prompt —prefill— de la generación de tokens —decode—; en GKE permite combinar TPUs y GPUs detrás de un mismo endpoint.

🧠 El entrenamiento también tiene su parte: Google presentó un fork de TorchTitan adaptado a TPU, con recetas para modelos densos, mezclas de expertos y difusión. Su explicación técnica describe SimpleFSDP, Graph Trainer y kernels especializados para escalar sin tener que diseñar desde cero toda la distribución del modelo.

¿Qué cambia para quienes desarrollan y operan modelos?

La apuesta es poder elegir hardware sin abandonar el flujo de trabajo de PyTorch, tanto al entrenar como al poner modelos a responder solicitudes. Eso no significa que cualquier modelo alcance automáticamente el mismo rendimiento: los anuncios incluyen recetas, optimizaciones y resultados para cargas específicas.

  • Hugging Face: en Transformers v5, Google indica que se pueden desplegar modelos en TPU pasando device_map="tpu". Diffusers incorpora ejecución nativa con eager, torch.compile y paralelismo de tensores; además, hay pruebas nocturnas continuas de Transformers sobre infraestructura TPU.
  • Inferencia para distintos escenarios: los nuevos motores contemplan llamadas a herramientas, salidas estructuradas, entradas de imagen y video, embeddings, caché automática de prefijos y descarga de caché KV a memoria del servidor. Incluyen decodificación especulativa con MTP, EAGLE-3, DFlash, DSpark y borradores de n-gramas; paralelismo de datos, tensores, expertos, pipeline y contexto; caché KV FP8 y checkpoints FP8, FP4 —MXFP4 y NVFP4—, INT8 e INT4.
  • Mover contexto sin detener el cálculo: TPU Sync es una biblioteca abierta en C++ que transfiere y administra caché KV directamente desde los buffers de los tensores, sin una copia intermedia adicional en el servidor. Permite comunicar hosts separados de prefill y decode, y trasladar caché entre memoria del acelerador, DRAM y Google Cloud Managed Lustre; vLLM la conecta mediante su interfaz KV y SGLang también la usa con HiCache.
  • Disponibilidad de los motores: Google afirma que ambos ya operan a escala con clientes en acceso preliminar y que SGLang-TorchTPU está en producción en Meta. Entre las familias compatibles menciona Qwen, DeepSeek, GLM, Kimi, GPT-OSS y Gemma4; ampliar la cobertura y ofrecer soporte desde el lanzamiento de nuevos modelos sigue en la hoja de ruta. vLLM también anunció capacidad TPU gratuita para desarrolladores que contribuyan activamente a ambos motores.
  • Resultados de inferencia, no tarifas universales: Google reporta en InferenceX un mínimo de 2.01 centavos por millón de tokens para Qwen 3.5 sobre Ironwood, también identificado como TPU 7x, y resultados de contexto largo y agentes en AgentX. Con Inferact integró un megakernel Pallas para Kimi K3, de 2.8 billones de parámetros, que ejecuta todo el paso de decode en un kernel y supera 700 tokens por segundo para un usuario en Ironwood; también presentó una evaluación preliminar de ese modelo
  • Qué agrega llm-d 1.0: APIs v1 estables, alta disponibilidad del router, actualizaciones sin interrupciones, control de prioridad y equidad entre usuarios, enrutamiento por sesión, prioridad por turno y estado nativo de Responses API. DisaggregatedSet, construido sobre LeaderWorkerSet, coordina actualizaciones de prefill y decode manteniendo versiones compatibles; los componentes pueden adoptarse por separado.
  • Caché y operación del clúster: el router de llm-d usa Gateway API Inference y considera prefijos guardados, carga y latencia prevista; GKE Inference Gateway lo ofrece como servicio administrado con enrutamiento entre regiones. La caché puede descargarse mediante OffloadingConnector de vLLM, Mooncake o HiCache de SGLang hacia memoria del servidor, SSD o Managed Lustre. En la conferencia, Google mostró 1,000 agentes aislados en Agent Substrate sobre GKE, usando un endpoint común con vLLM, SGLa
  • Las mediciones de llm-d tienen condiciones: en una carga de agentes de programación sobre Ironwood, Google reporta más de 85% de reducción en la mediana del tiempo al primer token y 2.4 veces el rendimiento frente a un Kubernetes Service convencional, a octubre de 2026. Por separado, Zenteiq reportó pasar de 1,470 millones a 5,970 millones de tokens diarios por cada 1,000 aceleradores TPU v6e, más de cuatro veces el rendimiento agregado, al usar GKE Inference Gateway con llm-d.
  • Trabajo asíncrono y capacidad ociosa: llm-d-async-processor toma solicitudes de colas como Pub/Sub o Redis y las combina con tráfico en tiempo real, aplicando prioridades y cuotas. Google señala que en entrenamiento por refuerzo los aceleradores pueden estar inactivos entre 40% y 60% del tiempo; con time-slicing en TPU y GPU reporta elevar la ocupación agregada desde aproximadamente 40% hasta más de 70%. Prism ofrece un panel abierto para explorar benchmarks, apoyado en recetas llm-d-benchma
  • Recetas de entrenamiento: TorchTitan TPU contempla Llama 3 de 70B y 405B, Qwen 3 de 8B y 32B, Qwen 3 MoE de 235B y FLUX.1 de 12B. También puede encargarse de actualizar parámetros en pipelines de postentrenamiento como VeRL, GRPO y aprendizaje por refuerzo, sincronizando pesos con motores como vLLM-TorchTPU.
  • Cómo se optimiza el entrenamiento: las definiciones siguen siendo módulos PyTorch sin código específico de CUDA, con soporte de C10D y DeviceMesh. Las recetas pueden activar Splash Attention, proyección final y pérdida fusionadas, y kernels agrupados para expertos; las funciones JAX de Pallas se integran como operadores mediante torch.tpu.pallas.jax_op, incluidos kernels de tokamax.
  • Resultados y límites de TorchTitan: SimpleFSDP expresa la distribución de parámetros dentro del grafo para que XLA pueda programar comunicaciones y cálculo; Google reporta en FLUX un rendimiento equivalente al 99% del de JAX MaxDiffusion. Graph Trainer captura forward, pérdida y backward en un grafo FX y aplica políticas de memoria, recomputación y descarga; también permite recorrer capas mediante scan o dividir forward y backward, con más de 29% de utilización de FLOPS del modelo en Qwen3 2

El hilo conductor del lanzamiento de llm-d 1.0 es que un agente de varios pasos no se comporta como una consulta aislada: reutilizar contexto y repartir bien las solicitudes importa tanto como ejecutar rápido el modelo. TorchTPU aborda la ejecución en el acelerador; llm-d se encarga de coordinar la flota.

💬 Si ya trabajas con PyTorch, ¿qué probarías primero en TPU: entrenamiento con TorchTitan o inferencia con vLLM y SGLang?

¿Pero deveras? 🌵💚