Google lanza TPU 8i Max y 8tx: chips para agentes y datos sensibles

Si alguna vez has ejecutado un agente que pasa una hora esperando la respuesta de un usuario o de una API externa, conoces el problema: el acelerador sigue ocupado sin hacer trabajo útil. A eso se suma el contexto largo, que choca con los límites de memoria y la velocidad de transferencia de la caché KV entre nodos. Con su nuevo anuncio, Google intenta resolver ambos problemas a la vez y añade una tercera capacidad: trabajar con datos sensibles sin tener que confiar en el host.

El hardware

La familia de TPU de octava generación consta ahora de cuatro sistemas. Las dos incorporaciones son TPU 8i Max y TPU 8tx.

TPU 8i Max es, en esencia, dos TPU 8i unidos. Google afirma que ofrece el doble de potencia de cálculo, el doble de SRAM y el doble de ancho de banda de HBM. Está dirigido a ventanas de contexto enormes y tareas complejas de agentes. Aquí, la capacidad de memoria y su ancho de banda importan más que los teraflops brutos: con contextos largos, la mayor parte del tiempo se dedica a leer la caché KV, no a multiplicar matrices.

TPU 8tx está diseñado para computación confidencial. Los datos se protegen mediante hardware durante su procesamiento, tanto en la inferencia como en el ajuste fino. Para productos bancarios, sanitarios y jurídicos, esto podría eliminar la principal objeción a los modelos en la nube: «No podemos enviar este tipo de datos fuera de nuestra organización».

El software que acompaña a los chips

Aquí está la parte más práctica del anuncio.

Agent Compute Engine descarga el estado de las sesiones de agentes inactivas y libera los aceleradores. Imagina un agente de atención al cliente que hace una pregunta y espera un día entero la respuesta. Antes, su contexto ocupaba memoria en un chip caro; ahora, el estado se descarga y el chip puede atender otras sesiones.

TPU Sync reduce la latencia de transferencia de la caché KV en más de un 90%, según Google. Esto importa cuando las fases de prefill y decode se ejecutan en nodos distintos: cuanto más rápido se transfiere la caché, menor es la espera hasta el primer token.

XLA Serving Engine incorpora un motor de código abierto en C++ para servir modelos en TPU, GPU y CPU. Para los equipos preocupados por la dependencia de un único proveedor, es una señal importante: una misma capa de servicio de modelos puede ejecutarse en distintos tipos de hardware.

GKE Dynamic Slicing acelera el inicio de los trabajos hasta 5 veces y la recuperación tras fallos hasta 4,5 veces. En entrenamientos y ajustes finos largos, esto supone un ahorro directo: menos tiempo de inactividad del clúster tras la caída de un nodo.

Gemini diseña chips

Otro detalle: Google utiliza Gemini y la capacidad de cálculo de las TPU para crear diseños de distribución de componentes. Según la empresa, el proceso lleva horas en lugar de semanas. Es una afirmación de la propia Google, sin confirmación independiente, pero la tendencia es clara: la IA empieza a acelerar el desarrollo de su propio hardware.

Limitaciones

Todas las cifras, incluidas la reducción del 90% en las transferencias de caché KV y la aceleración de GKE de 5 veces, proceden de materiales de Google y no se han verificado de forma independiente. El anuncio no incluye precios, plazos de disponibilidad ni regiones. Tampoco hay una comparación con Nvidia, así que es pronto para evaluar una posible ventaja en el coste por token. La computación confidencial de 8tx merece un análisis aparte: qué amenazas concretas cubre, cómo funciona la atestación y qué ocurre con el rendimiento cuando la protección está activada.

Qué hacer en la práctica

Si desarrollas productos basados en agentes con sesiones largas, calcula qué proporción del tiempo pasan tus aceleradores inactivos, a la espera. Ahí es donde Agent Compute Engine tendrá impacto. Si trabajas con datos regulados, considera 8tx como un argumento para conversar con tu equipo de seguridad. Si te preocupa la dependencia de un proveedor, explora XLA Serving Engine, de código abierto: puedes probarlo independientemente del chip que elijas. Los equipos de producto deberían esperar a conocer los precios y los resultados de las pruebas de rendimiento antes de reorganizar su infraestructura.