Cuatro sistemas TPU en un mismo año. Google nunca había presentado tantos, y el 9 de noviembre de 2026 completó la octava generación con dos más: TPU 8tx, para inferencia confidencial, y TPU 8i Max, que junta dos chips TPU 8i en un solo encapsulado. El mismo día publicó como código abierto TPU Sync, una librería que en sus pruebas baja la transferencia de KV cache entre nodos de varios segundos a unos 230 ms.
Qué se ha presentado
En abril, en Google Cloud Next, llegaron TPU 8t (entrenamiento a gran escala) y TPU 8i (razonamiento en tiempo real), con hasta 2,7 veces más rendimiento de entrenamiento y un 80 % más de rendimiento por precio en inferencia, respectivamente, frente a la generación anterior. Las dos nuevas no cambian de silicio, sino de configuración:
| Sistema | Para qué | Qué cambia |
|---|---|---|
| TPU 8t | Entrenar modelos fundacionales | Base de la generación |
| TPU 8i | Inferencia y razonamiento | Red Boardfly, hasta la mitad de retardo entre chips |
| TPU 8tx | Inferencia confidencial y entrenamiento pequeño | Silicio de 8t con hosts AMD EPYC de 5.ª generación, aislamiento por hardware y red Boardfly: hasta 2 veces menos latencia que 8t |
| TPU 8i Max | Contextos muy largos | Dos chips 8i por encapsulado: doble de cómputo, de SRAM y de ancho de banda de HBM; el doble de silicio en el mismo rack |
La 8tx apunta a un problema concreto: afinar con datos privados, destilar o hacer aprendizaje por refuerzo sin sacar los datos ni los pesos del entorno protegido, y sin moverlos entre clústeres. La 8i Max ataca el "muro de memoria": en inferencia con ventanas de contexto enormes, lo que limita no es el cómputo sino cuánto se puede leer de la HBM por segundo.
Google no ha publicado FLOPS, capacidad de HBM, consumo, precio ni regiones de ninguna de las dos, así que de momento no hay forma de compararlas en cifras absolutas con otros aceleradores.
TPU Sync, la pieza que sí se puede usar ya
Donde hay datos es en TPU Sync, una librería C++ que mueve tensores entre la HBM de la TPU, la DRAM del host, el almacenamiento compartido y la red entre hosts con DMA asíncrono, solapado con el cómputo. Resuelve tres problemas de quien sirve LLMs: la KV cache por niveles, el servicio con prefill y decode separados y la caché de prefijos. Se integra con vLLM y SGLang (vía TorchTPU), con llm-d 1.0 en GKE y con JAX, y se instala con las ruedas tpu-sync-torch y tpu-sync-jax.
Las cifras son de pruebas internas de julio de 2026 en TPU v7x (Ironwood), no en la octava generación:
- Transferencia de KV cache entre prefill y decode: mediana de varios segundos a unos 230 ms con Qwen3 235B, más de un 90 % menos.
- Tiempo hasta el primer token: un 60 % menos de media en 235B y un 90 % en 480B con poca concurrencia; hasta un 90 % menos con caché de prefijos y contextos de 64K.
- Hasta 223 GB/s entre TPU y host en cada host Ironwood, frente al techo de 256 GB/s de PCIe Gen5.
El almacenamiento compartido como tercer nivel y el módulo de transferencia de pesos para RL siguen siendo experimentales.
Qué significa
La lectura de fondo es que Google ya no vende "la TPU" sino una familia ajustada a cada fase: entrenar, razonar, inferir con datos sensibles y servir contextos largos. TPU 8i Max y TPU Sync son dos respuestas al mismo problema: una mete más ancho de banda de memoria por rack y la otra mueve la KV cache sin recalcularla.
Para quien construye sobre Google Cloud, lo práctico hoy es el software. TorchTPU, los backends de vLLM y SGLang y TPU Sync bajan el coste de probar TPU sin reescribir el código de PyTorch, que era la barrera real para salir de las GPU. Las dos TPU nuevas importan sobre todo a quien tiene datos regulados (8tx) o sirve modelos con contextos de cientos de miles de tokens (8i Max); hasta que haya precios y regiones, son una hoja de ruta.
Fuentes
- Our newest TPUs: 8tx and 8i Max, built for the agentic era, Google Cloud Blog
- Introducing TPU Sync: Fast KV cache and weight transfer for inference and RL on TPU, Google Cloud Blog