Google anuncia los procesadores TPU 8t Sunfish y TPU 8i Zebrafish.

En Google Cloud Next, Google anunció sus aceleradores de IA de próxima generación: el TPU 8t “Sunfish” para entrenamiento y el TPU 8i “Zebrafish” para inferencia, junto con su nueva estructura de centro de datos Virgo. Según las publicaciones del blog de Google, estos chips están optimizados para la era de la inteligencia artificial: entrenar modelos de vanguardia con múltiples expertos a escala de cientos de miles de chips y luego ofrecer esos mismos modelos con baja latencia y objetivos de precio por token competitivos. El 8t y el 8i son dos chips con arquitecturas distintas que comparten una plataforma host y una estructura, pero difieren en la capacidad de memoria, la SRAM integrada, la topología de interconexión y la especialización en el chip. El 8t está diseñado para la multiplicación densa de matrices a gran escala, mientras que el 8i se centra en la caché KV en silicio y la latencia colectiva por token.

Un único superpod de 8t se escala a 9,600 chips, contiene 2 PB de HBM y ofrece 121 EFLOPS de cómputo FP4, casi 3 veces el cómputo por pod de un superpod de Ironwood. 8i combina 288 GB de HBM con 384 MB de SRAM en chip (3 veces Ironwood) dentro de un dominio de escalado de 1,152 chips y afirma un rendimiento por dólar un 80 % mejor que Ironwood para la inferencia LLM. Virgo combina ambas familias de chips en una única estructura de centro de datos que enlaza más de 134 000 chips de 8t a 47 Pb/s de ancho de banda de bisección sin bloqueo, con hasta 4 veces el ancho de banda por acelerador y una latencia sin carga un 40 % menor que la generación anterior.

Qué es realmente un TPU

Antes de adentrarnos en los 8 chips de silicio, conviene explicar qué es una TPU y en qué se diferencia de una GPU, ya que las 8 decisiones de diseño solo tienen sentido en ese contexto.

Una Unidad de Procesamiento Tensorial (TPU) es un ASIC personalizado que Google ha estado perfeccionando desde 2015. Cada generación se ha basado en la misma idea central: en lugar de programar miles de núcleos pequeños de forma dinámica, como lo hace una GPU, una TPU se centra en un número reducido de MXU (unidades de multiplicación de matrices) muy grandes, alimentadas por una memoria SRAM integrada gestionada por software y controladas por un compilador de ejecución anticipada. Cada chip contiene varios TensorCores, cada uno construido alrededor de una MXU de matriz sistólica grande, además de un conjunto más pequeño de SparseCores dedicados a las búsquedas irregulares de recolección-dispersión que dominan las incrustaciones de recomendaciones. Los datos fluyen desde HBM a través de la memoria, a través de la MXU, de vuelta a la memoria y de nuevo hacia afuera, con una Unidad de Procesamiento Vectorial que gestiona las activaciones, normalizaciones y reducciones simultáneamente. No hay un planificador de warps de hardware, ni jerarquía de caché L1 o L2 como en las GPU, ni despacho dinámico.

La ventaja de este diseño es la eficiencia en álgebra lineal densa. Con un compilador que decide con anticipación dónde reside cada tensor y cuándo se activa cada operación colectiva, no hay fluctuación por fallos de caché ni costo del planificador de warps, lo cual es más importante de lo que parece cuando decenas de miles de chips deben mantenerse sincronizados a través de una operación colectiva. La utilización de FLOP de modelos reales en TPU para cargas de trabajo de entrenamiento bien ajustadas tiende a ser mayor que en las GPU tradicionales. La desventaja es que cualquier cosa que no se mapee limpiamente a grandes mulciones de matriz densas, específicamente formas dinámicas, patrones de dispersión irregulares, enrutamiento MoE con distribución desigual de tokens o redes neuronales gráficas, es más difícil de expresar de manera eficiente. Históricamente, las TPU también han tenido menos HBM por chip que sus contrapartes GPU y han tenido un soporte de marco mucho más limitado. XLA y JAX son de primera clase; PyTorch, hasta hace poco, requería una capa de traducción; además, el compilador, el entorno de ejecución, las bibliotecas de red y la pila de software multipod siguen siendo de código cerrado dentro de Google.

La escasez es el ejemplo más claro de la brecha filosófica entre las GPU y las TPU, y la razón es estructural más que de marketing. NVIDIA ha admitido la escasez estructurada 2:4 en los Tensor Cores desde Ampere y, en teoría, el rendimiento para cargas de trabajo escasas duplica el de las cargas de trabajo densas. Un Tensor Core es fundamentalmente una unidad de despacho: toma cargas de operandos explícitas por instrucción MMA, por lo que agregar una variante MMA escasa que acepte un bloque comprimido de 2 de 4 más metadatos de índice es una extensión directa del conjunto de instrucciones existente. En cada ciclo, el hardware extrae solo los valores distintos de cero y sus índices en el array multiplicador, omitiendo implícitamente los ceros.

Una matriz sistólica funciona de forma opuesta. Cada PE (elemento de procesamiento) realiza un cálculo en cada ciclo, con operandos que fluyen a través de la matriz de forma sincronizada mediante rutas directas de registro a registro, de un PE al siguiente. Este flujo de datos determinista es precisamente donde reside la ventaja de eficiencia energética sobre SIMT: no hay lecturas repetidas de SRAM, ni sobrecarga de despacho de instrucciones, y se maximiza la reutilización de operandos. Sin embargo, esto también implica que el hardware no puede omitir un elemento con valor cero por ciclo sin interrumpir la segmentación.

Las TPU aún pueden aprovechar la dispersión a nivel de mosaico; si un mosaico completo del tamaño de MXU está compuesto solo por ceros, el compilador no programa trabajo en él. Sin embargo, la decisión de Google de no agregar aceleración de hardware para la dispersión estructurada es deliberada. Agregar dispersión estructurada M:N a una matriz sistólica se puede lograr utilizando múltiples técnicas, cada una con diferentes ventajas y desventajas. Una de estas técnicas requiere una unidad de compresión ubicada entre la SRAM y los puertos de entrada de la matriz. Pero una matriz sistólica es una tubería, no un despachador. Su garantía de eficiencia proviene de la llegada de operandos en una cadencia determinista, con cada elemento de procesamiento ocupado en cada ciclo. Permitir que se omitan operandos impone uno de dos costos: detener la tubería en los ceros, lo que elimina la ventaja de eficiencia que motivó la arquitectura en primer lugar; o agregar hardware de descompresión dedicado para reconstruir un flujo de ancho completo a partir de la entrada comprimida antes de que ingrese a la matriz, lo que consumiría área del chip y agregaría latencia.

Algunos aceleradores combinan matrices sistólicas con soporte de hardware para la dispersión. AWS creó una a partir de NeuronCore-v3, el motor dentro de Trainium2 y Trainium3. La implementación muestra cómo se ve una matriz sistólica dispersa por hardware. El motor de tensores NeuronCore-v3 es una matriz sistólica de 128×128 que opera sobre una matriz de pesos estacionaria y una matriz de activación de flujo, con la dimensión de contracción alineada con la dimensión de partición de la matriz. En modo disperso, la ruta de datos de entrada se amplía de 2×128 elementos por ciclo en BF16 y FP16 densos a 5×128 elementos por ciclo, y el lado estacionario se alimenta de una representación comprimida de la matriz de pesos en lugar de los pesos densos originales. En tiempo de compilación, el tensor de pesos se procesa en un formato M:N. De cada N elementos contiguos a lo largo de la dimensión de contracción, solo se retienen M, con una máscara de bits compacta que codifica qué posiciones son distintas de cero. El búfer comprimido almacena únicamente los valores M, reduciéndose en un factor de N/M. Cuando se ejecuta la instrucción matmul, el hardware lee los pesos comprimidos y utiliza la máscara de bits para enrutar las activaciones correspondientes desde el bloque estacionario a los elementos de procesamiento correctos. Los PE que se habrían multiplicado por cero no reciben trabajo para esa ranura. Dado que la búsqueda y el enrutamiento de la máscara de bits se realizan en el descompresor que alimenta la matriz, en lugar de en la matriz misma, la tubería mantiene el reloj a su máximo rendimiento en valores distintos de cero, en lugar de detenerse en ceros.

La multiplicación de matrices densas no es la única función de una TPU. Desde hace varias generaciones, las TPU incluyen un SparseCore junto con los TensorCores. SparseCore es un motor específico diseñado para los patrones de acceso de recolección-dispersión irregulares que definen los modelos de recomendación. Un modelo de clasificación de YouTube o un modelo de relevancia de anuncios de búsqueda no se asemejan a un transformador denso. La mayoría de sus parámetros residen en tablas de incrustación que pueden variar desde cientos de gigabytes hasta petabytes, y la mayor parte de su tiempo de cómputo se dedica a realizar pequeñas búsquedas en esas tablas, transformar ligeramente los valores recuperados y combinar los resultados. Ese patrón de acceso es el peor caso para una MXU y solo ligeramente mejor para la jerarquía de caché de una GPU. Los SparseCores están optimizados precisamente para esto: operaciones de recolección-dispersión de alto rendimiento sobre tablas de incrustación residentes en HBM, con soporte de hardware para las operaciones de deduplicación y combinación de las que depende el resto del pipeline de incrustación. El mismo hardware también ayuda con el enrutamiento experto de MoE porque, una vez que la selección top-k produce índices expertos, el resto del proceso de enrutamiento (permutar tokens por experto, distribuirlos entre chips, recopilar las salidas de los expertos y realizar la reducción ponderada) sigue el mismo patrón de recopilación/dispersión/reducción que la canalización de incrustación, con el soporte de ordenación de SparseCore cubriendo el paso top-k en sí.

Con estos antecedentes, aquí están los anuncios.

TPU 8t “Sunfish”

El primer anuncio, TPU 8t con nombre en clave Sunfish, es el chip de entrenamiento. El salto generacional de Ironwood sigue la trayectoria esperada en la mayoría de los aspectos: más memoria, mayor ancho de banda y soporte nativo para tipos de datos más reducidos. Cada chip incorpora un único TensorCore alimentado por seis pilas HBM3e de 12 Hi que suman 216 GB a 6.5 ​​TB/s, frente a los 192 GB distribuidos en ocho pilas de Ironwood. La memoria SRAM Vmem integrada se mantiene en 128 MB.

La mayor parte del salto en el rendimiento computacional proviene del uso nativo de FP4 en la MXU. Ejecutar multiplicaciones de matrices en 4 bits en lugar de 8 bits duplica el rendimiento por ciclo para la misma matriz física, lo que explica cómo Google pasa de los 4.6 PFLOPS de FP8 de Ironwood a los 12.6 PFLOPS de FP4 de 8t. El entrenamiento de precisión mixta aún conserva una copia maestra de FP32 de los pesos para el paso del optimizador; FP4 reduce el tamaño de los tensores de trabajo que consumen la mayor parte del tiempo de cómputo.

La historia de la interconexión es sencilla. El ancho de banda de ICI se duplica a 19.2 Tb/s por chip, el superpod de 9,600 chips agrega 2 PB de HBM y 121 EFLOPS, y se mantiene la topología de toro 3D. El toro tiene sentido para el entrenamiento porque las tareas de frontera están dominadas por colectivos compatibles con anillos: reducciones totales para paralelismo de datos y tensores, recolecciones totales y dispersión de reducción para FSDP, y envíos punto a punto en paralelo a la tubería. Todos estos se mapean claramente a los ejes del toro.

Google también conserva los SparseCore que se han incluido en todas las TPU desde la versión 4. Su propósito original era para modelos de recomendación de estilo DLRM, donde la mayor parte del tiempo de cómputo se destina a la recolección-dispersión irregular contra tablas de incrustación masivas. El mismo hardware también gestiona el enrutamiento MoE. JAX expone la comunicación irregular de todos a todos y un ragged_dot correspondiente como operaciones de primera clase, en las que cada chip puede enviar un fragmento de diferente tamaño a cada par. Esto coincide con la forma real del despacho MoE, porque el enrutamiento top-k depende de los datos y el número de tokens que fluyen a cada experto varía en cada paso. El compilador fusiona la comunicación irregular y la matriz de expertos irregular en una única operación programada, mientras que SparseCore gestiona la ordenación y permutación circundantes. Con la mezcla de expertos como la arquitectura dominante en los modelos de vanguardia, este hardware demuestra su valor en cualquier tarea de entrenamiento moderna, no solo en las cargas de trabajo de anuncios y clasificación para las que fue diseñado originalmente.

Se trata de pasos evolutivos. Los cambios más importantes son TPUDirect y el paso a hosts basados ​​en Axion, ambos orientados a solucionar cuellos de botella que solo se hacen visibles a escala de vanguardia.

Almacenamiento TPUDirect RDMA y TPUDirect

Las generaciones anteriores de TPU utilizaban una ruta mediada por el host para la E/S de red y almacenamiento: los paquetes llegaban primero a la DRAM del host y luego un DMA independiente los copiaba a la HBM de la TPU. Esto implicaba dos transacciones de memoria con la CPU del host en el bucle. TPUDirect RDMA elimina el búfer de rebote. La NIC lee y escribe la HBM de la TPU directamente a través de PCIe peer-to-peer, eliminando al host de la ruta de datos. NVIDIA lleva años ofreciendo una capacidad equivalente con GPUDirect RDMA y afirma una mejora de aproximadamente 10 veces con respecto a la ruta mediada por el host. Google ahora está igualando esa mejora en el lado de la TPU.

TPUDirect Storage extiende el mismo principio al almacenamiento persistente. Los tensores se mueven directamente entre TPU HBM y Managed Lustre a una velocidad agregada de 10 TB/s, lo que, según Google, proporciona un acceso al almacenamiento 10 veces más rápido que la ruta equivalente en Ironwood. A escala de frontera, donde los puntos de control pueden alcanzar cientos de terabytes, la diferencia radica en si una ejecución de entrenamiento de varias semanas transmite puntos de control y conjuntos de datos a velocidad de línea o si bloquea la canalización MXU a la espera de E/S del host.

Anfitriones de axiones de brazo

Todas las generaciones anteriores de TPU se ejecutaban en hosts x86 de terceros. 8t es la primera en usar el procesador Axion de Google, una CPU basada en Arm Neoverse V2, como encabezado del sistema. La función de la CPU host en un pod TPU es real y se vuelve más compleja a escala de frontera: controla la canalización de entrada, decodifica y reorganiza conjuntos de datos de varios petabytes, administra el plano de control JAX/XLA, gestiona la serialización de puntos de control y coordina el envío de SPMD a través de miles de chips. Si el host se bloquea, la MXU permanece inactiva.

Google destaca específicamente el aislamiento NUMA con tecnología Axion en 8t como el mecanismo que evita que la fluctuación del host se filtre en las fases colectivas sincronizadas del entrenamiento. Con 9,600 chips por pod, incluso pequeños fallos por host se acumulan y provocan una pérdida considerable de rendimiento. TPUDirect gestiona la ruta de datos al excluir al host de las transferencias masivas. Axion gestiona la ruta de control al proporcionar a cada TPU suficiente ancho de banda de CPU dedicado para que el preprocesamiento nunca se convierta en el cuello de botella. Google también ha aumentado la proporción de hosts físicos Axion por servidor en la plataforma de octava generación, lo que proporciona a la sobrecarga de orquestación, que aumenta con el número de chips, mayor margen de maniobra que la configuración de host de Ironwood.

TPU 8i “Pez cebra”

El chip de inferencia comparte la plataforma host Axion de 8t, el FP4 nativo y la generación de memoria HBM3e, pero el silicio subyacente está diseñado para un cuello de botella diferente. El entrenamiento está limitado por la capacidad de cómputo; la decodificación de la inferencia está limitada por el ancho de banda de la memoria. La mayoría de las diferencias arquitectónicas de 8i se derivan de esto.

El cambio más significativo reside en la SRAM integrada. El 8i incorpora 384 MB de Vmem, tres veces más que Ironwood. Esto es importante debido a la caché KV. Durante la decodificación de contexto largo, cada token generado requiere la lectura de los estados de clave-valor acumulados de tokens anteriores. En la mayoría de los aceleradores, esta lectura proviene de la HBM, lo que implica que el rendimiento de la decodificación está limitado por el ancho de banda de la memoria en lugar de la capacidad de cómputo. El 8i está diseñado para albergar una cantidad considerable de caché KV completamente en silicio. El ancho de banda de la SRAM integrada es aproximadamente un orden de magnitud superior al de la HBM, por lo que cada lectura KV realizada desde la SRAM en lugar de la HBM se traduce en una menor latencia por token y un mayor número de tokens por segundo con el mismo consumo de energía.

La configuración de TensorCore es la otra gran diferencia. Mientras que 8t usa un solo TensorCore a 12.6 PFLOPS, 8i divide el cálculo entre dos TensorCores con un rendimiento combinado de 10.1 PFLOPS. Un menor rendimiento máximo puede parecer una desventaja hasta que se considera cómo se ve realmente la inferencia a nivel del chip. Las cargas de trabajo de entrenamiento están dominadas por lotes: las grandes multiplicaciones de matrices amortizan la sobrecarga fija, y una sola MXU grande puede mantener una utilización cercana al pico. La decodificación de inferencia es lo opuesto. Los tamaños de lote son pequeños, las ventanas de cálculo por token son cortas, y el chip dedica una fracción considerable de su tiempo a operaciones colectivas, muestreo y enrutamiento en lugar de a la multiplicación de matrices pura. Un solo motor grande se bloquea durante esos intervalos irregulares. La división en dos TensorCores permite a 8i superponer las fases de cálculo de manera más efectiva, con cada TensorCore alimentado por sus propias cuatro pilas HBM conectadas directamente, lo que suma un total de 288 GB a 8.6 TB/s en todo el paquete. El resultado es una mayor utilización sostenida en los tamaños de lote que realmente se ejecutan en el servicio interactivo.

A nivel de escalado, los 1,024 chips activos en un pod de Boardfly suman aproximadamente 295 TB de HBM, 384 GB de SRAM integrada y 10.3 EFLOPS de cómputo FP4. La cantidad de SRAM es la más importante para la inferencia: 384 GB de caché integrada en todo el dominio son suficientes para almacenar un estado KV sustancial sin acceder a la HBM, lo que hace viable el servicio de contexto largo con baja latencia.

El lado del host sigue la misma lógica. Google afirma haber aumentado el número de hosts físicos de Axion por servidor en 8i en comparación con Ironwood. Los servidores de inferencia dedican una fracción considerable del tiempo por token a la tokenización, la lógica de muestreo, el enrutamiento, el procesamiento por lotes y la orquestación del tiempo de ejecución del agente. Estos gastos generales aumentan con la concurrencia, no con el tamaño del modelo, y a las tasas de solicitud que generan las cargas de trabajo de los agentes, el host puede convertirse en el cuello de botella. La solución más sencilla es aumentar la CPU del host por acelerador.

Motor de aceleración colectiva

El otro cambio importante en el chip es el Motor de Aceleración de Colectivos, que reemplaza los cuatro SparseCores que tenía Ironwood. Los SparseCores gestionan el enrutamiento MoE y las búsquedas de incrustación con hardware de recolección-dispersión dedicado, por lo que al eliminarlos de las señales del chip de inferencia, 8i las optimiza para un cuello de botella diferente.

El principal obstáculo que aborda CAE es la latencia colectiva. Cada token decodificado requiere que los chips participantes se sincronicen: las salidas de atención deben reducirse por completo, los metadatos de enrutamiento del experto deben transmitirse y los tokens muestreados deben propagarse al siguiente paso. En las GPU, esta coordinación se realiza mediante software a través de NCCL, que programa las operaciones colectivas como una secuencia de lanzamientos de kernels y operaciones de red. En 8i, CAE es un chip dedicado ubicado en su propio chiplet junto con los TensorCores, y gestiona estas primitivas de sincronización mediante hardware.

Google afirma que la latencia colectiva en el chip es hasta 5 veces menor que la de Ironwood. En lotes de tamaño de entrenamiento, esta mejora quedaría eclipsada por el tiempo de cómputo; la latencia colectiva representa una pequeña fracción del paso. En lotes pequeños y ventanas cortas por token de inferencia interactiva, la latencia colectiva puede predominar sobre el tiempo por token, por lo que la reducción de 5x se refleja en los tokens por segundo y el precio por token.

8i también pasa de la topología de toroide 3D a lo que Google denomina Boardfly, una topología jerárquica inspirada en Dragonfly que sacrifica el ancho de banda colectivo del anillo a cambio de una menor latencia entre todos los nodos. Analizaremos Boardfly en detalle más adelante.

Topología de la mosca de la tabla

8i utiliza una topología diferente a la de 8t porque el entrenamiento y la inferencia tienen patrones de comunicación diferentes.

El toro 3D es ideal para colectivos de anillo: cada chip tiene seis vecinos, los datos rotan alrededor del anillo y ningún chip enruta tráfico arbitrario. El entrenamiento se basa principalmente en estos patrones compatibles con el anillo, razón por la cual 8t conserva el toro. Una reducción total en anillo se adapta perfectamente a un único eje del toro. Los trabajos de Frontier suelen ubicar el paralelismo de datos en un eje, el paralelismo de tensores en otro y el paralelismo de pipeline en el tercero. La topología y la carga de trabajo coinciden.

La inferencia que sirve a un modelo MoE grande tiene un perfil de comunicación diferente. Los expertos están ubicados en muchos chips, y cada token decodificado activa una comunicación de todos a todos: los tokens deben llegar a sus expertos asignados dispersos por la red, y las salidas de los expertos deben regresar. Esto no es un anillo. Es tráfico arbitrario punto a punto, y en un toroide 3D de 1,024 chips, la ruta en el peor de los casos entre dos chips cualesquiera es de 16 saltos. Google desglosa este cálculo para nosotros: “En un toroide 3D, los nodos están dispuestos en una cuadrícula donde cada dimensión se enrolla como un anillo. Para llegar al chip más lejano posible en una configuración de 8 x 8 x 16 (1024 chips), un paquete debe recorrer la mitad de la distancia de cada anillo:

Toroide 3D = 8/2(X) + 8/2(Y) + 16/2(Z) = 16 saltos

Si bien el toroide es altamente eficiente para la comunicación entre vecinos, típica del entrenamiento denso, genera una latencia excesiva para los patrones de comunicación entre todos los nodos. En la era de los modelos de razonamiento y el modelo de entidad-relación (MoE), donde cualquier chip puede necesitar comunicarse con cualquier otro para enrutar un token, este número de saltos es crucial.

En el caso de servicios interactivos sensibles a la latencia, esos saltos adicionales hacen que la latencia por token supere su SLO (Objetivo de Nivel de Servicio).

Boardfly es una jerarquía inspirada en Dragonfly diseñada para comprimir ese diámetro. La estructura tiene tres niveles. El bloque de construcción es un anillo de cuatro chips con 16 conexiones externas. Ocho de estos bloques de construcción forman un grupo, completamente conectados mediante cableado de cobre con 11 enlaces por grupo. Treinta y seis grupos se conectan a través de conmutadores de circuitos ópticos para formar un pod. El resultado es un dominio de escalado de 1,152 chips (1,024 activos) con un máximo de 7 saltos entre cualquier par de chips, una reducción del 56 % con respecto al toroide. Google afirma que esto proporciona una mejora de hasta el 50 % en la latencia para cargas de trabajo con uso intensivo de comunicaciones, como MoE all-to-all.

El mayor alcance también es importante para la replicación de expertos. Un mayor número de chips por estructura ICI implica que cada experto en un MoE grande puede replicarse más veces, lo que suaviza el desequilibrio de enrutamiento y mantiene la latencia de decodificación constante cuando la distribución de tokens es desigual. El enrutamiento Top-k depende de los datos; algunos expertos verán más tokens que otros en cualquier paso dado. La replicación absorbe esa varianza. El ancho de banda de ICI se duplicó a 19.2 Tb/s por chip, en parte para gestionar el tráfico resultante.

Red Virgo

Un superpod de 9,600 chips es grande, pero las pruebas de entrenamiento en entornos de vanguardia requieren cada vez más capacidad. Virgo es la arquitectura de escalabilidad horizontal que conecta los superpods dentro de un centro de datos, gestionando el tráfico RDMA bidireccional entre pods cuando una tarea supera la capacidad de un único dominio de escalabilidad vertical.

Una única estructura Virgo conecta más de 134,000 4 chips 8t con un ancho de banda biseccional sin bloqueo de 47 Pb/s, hasta cuatro veces el ancho de banda por acelerador y una latencia sin carga un 40 % menor en comparación con la generación anterior. La arquitectura es una topología plana de dos capas sin bloqueo, basada en conmutadores de alta base con un diseño multiplanar y dominios de control independientes.

Las arquitecturas Clos tradicionales sobreasignan recursos en los niveles superiores para mantener el número de puertos y los costos bajo control. Esto funciona bien cuando la mayor parte del tráfico es norte-sur, que es el patrón en la nube de propósito general: los clientes acceden a los balanceadores de carga, los balanceadores de carga acceden a los servidores de aplicaciones y los servidores de aplicaciones acceden al almacenamiento. Las cargas de trabajo de entrenamiento de IA son casi en su totalidad este-oeste, de chip a chip a través de la arquitectura, y los colectivos están dominados por la bisección. Cualquier sobreasignación en cualquier nivel afecta directamente el tiempo de paso del entrenamiento. El diseño plano de dos capas de Virgo con conmutadores de alta radix elimina el cuello de botella del nivel spine al construir conmutadores con suficientes puertos por ASIC para terminar una fracción significativa de la arquitectura en dos saltos.

La ingeniería de confiabilidad es crucial a esta escala y depende en gran medida de los conmutadores de circuitos ópticos (OCS) basados ​​en MEMS de Google. OCS permite a Google reconfigurar la topología física entre trabajos sin recablear nada y, lo que es aún más importante, enrutar el tráfico en caso de fallos en chips o enlaces durante la ejecución. Cuando se detecta un fallo, OCS puede reasignar la parte afectada de la estructura en milisegundos, eliminando la necesidad de intervención manual. La telemetría en submilisegundos alimenta la detección automatizada de retrasos y bloqueos. La combinación de detección rápida y redireccionamiento basado en OCS optimiza el tiempo medio entre interrupciones y el tiempo medio de recuperación a una escala de más de 100 000 chips, donde la certeza estadística de algún fallo durante una ejecución de varias semanas se acerca al 100 %. El objetivo de rendimiento efectivo del 97 % que Google indica para los pods 8t depende de esta infraestructura. La misma tecnología OCS aparece en toda la pila TPU: une cubos en superpods en la capa ICI, conecta grupos Boardfly en la capa de escalado 8i y gestiona el tráfico entre pods en la capa Virgo.

Con 134 000 chips, la capacidad de cómputo agregada alcanza aproximadamente 1,690 EFLOPS de FP4, o alrededor de 1.7 ZFLOPS. Google afirma que la arquitectura admite una escalabilidad casi lineal de hasta un millón de chips en un único clúster de entrenamiento lógico, aunque las implementaciones actuales aún no han alcanzado ese límite.

Júpiter y la escala de múltiples centros de datos

Virgo gestiona el tráfico de aceleración este-oeste dentro de un centro de datos, pero no es la capa superior de la pila. Jupiter es la infraestructura norte-sur existente de Google, ahora en su quinta generación, que gestiona el tráfico de front-end y el acceso a los recursos de almacenamiento y computación distribuidos. Jupiter no se anunció en Cloud Next; es la infraestructura existente sobre la que se basa la octava generación.

La última versión de Jupiter ofrece un ancho de banda biseccional de 13 Pb/s por edificio de centro de datos con una disponibilidad del 99.999 %, utilizando conmutadores OCS MEMS Apollo con un consumo aproximado de 108 W por OCS, frente a los aproximadamente 3,000 W de un conmutador de paquetes eléctrico equivalente. Esta es la infraestructura que conecta los centros de datos de Google con el mundo exterior y entre sí.

Para las pruebas de entrenamiento que superan la capacidad y el espacio de un único centro de datos, Jupiter permite la escalabilidad en múltiples ubicaciones. La combinación se realiza en capas: ICI dentro de un pod, Virgo entre pods dentro de una ubicación y Jupiter entre ubicaciones. El conjunto de software Pathways de Google puede gestionar cargas de trabajo en estos dominios de múltiples centros de datos como un único clúster lógico.

Con aproximadamente 1.7 ZFLOPS, una única estructura Virgo es el clúster de entrenamiento de IA más grande anunciado hasta la fecha. Varias estructuras Virgo conectadas por Jupiter pueden gestionar más de un millón de chips TPU, que es la escala a la que apunta Google, aunque las implementaciones actuales aún no la hayan alcanzado.

Rendimiento y utilización

Los FLOPs brutos importan menos que la fracción de esos FLOPs que producen trabajo útil. Google indica un objetivo de rendimiento útil del 97 % para los superpods de 8t, lo que significa que el 97 % del tiempo real se dedica a computación productiva en lugar de a recuperación, bloqueos o sobrecarga de coordinación. Esta cifra depende de la tolerancia a fallos basada en OCS y la telemetría de sub-milisegundos mencionada anteriormente.

La utilización de FLOPs del modelo (MFU) es la otra variable. La MFU mide qué fracción de los FLOPs teóricos máximos el chip realmente soporta en una carga de trabajo real. SemiAnalysis estima que con una MFU de TPU del 40 %, el coste por FLOP de entrenamiento efectivo se reduce aproximadamente un 62 % en comparación con GB300 NVL72, con un punto de equilibrio en aproximadamente un 15 % de MFU de TPU. La economía de TPU divulgada públicamente por Anthropic sugiere que operan muy por encima de ese punto de equilibrio. La combinación de un alto rendimiento (mantener los chips en funcionamiento) y una MFU competitiva (mantener los chips ocupados mientras se ejecutan) es lo que hace que el TCO de TPU funcione a gran escala.

Donde se sientan los 8

Comparar la TPU 8 con las plataformas actuales y futuras de NVIDIA requiere prestar mucha atención a las unidades. NVIDIA indica el ancho de banda de NVLink como agregado bidireccional; una B200 a 1.8 TB/s NVLink 5 ofrece 900 GB/s por dirección. Los FLOPs principales de NVIDIA suelen ser dispersos 2:4; densos son la mitad. Las cifras de la TPU de Google son densas y bidireccionales. Al leer cualquier comparación, compruebe si el ancho de banda es unidireccional o bidireccional y si los FLOPs son densos o dispersos.

 

El rendimiento por chip FP4, 8t a 12.6 PFLOPS denso se sitúa entre los 10 PFLOPS dispersos de GB200 (5 PFLOPS densos) y los 20 PFLOPS dispersos de GB300 (15 PFLOPS densos). La comparación por chip es similar. La comparación de escalado no lo es. Un rack GB300 NVL72 contiene 72 GPU en un dominio NVLink. Un superpod de 8t consta de 9,600 chips en un único toroide 3D. Esto representa 133 veces más chips en un único dominio colectivo, que es la diferencia que separa las plataformas para el entrenamiento de vanguardia.

NVIDIA no se queda de brazos cruzados. Vera Rubin se lanzará en el segundo semestre de 2026 con 50 PFLOPS de inferencia NVFP4 por paquete (aunque SemiAnalysis ha cuestionado si esa cifra asume compresión adaptativa), 288 GB de HBM4 a 22 TB/s y NVLink 6 a 3.6 TB/s bidireccional. Rubin Ultra en el segundo semestre de 2027 combina cuatro chips de retícula para hasta 100 PFLOPS FP4 y 1 TB de HBM4e por paquete. Kyber NVL576 conectará 576 GPU Rubin Ultra en un solo rack con 15 EFLOPS de inferencia FP4. Esto comienza a reducir la ventaja de escalabilidad de Google, aunque 576 GPU siguen siendo un orden de magnitud menor que un superpod de 8t.

Las ventajas del modelo 8 incluyen: mayor escalabilidad del dominio (9,600 chips frente a 72 GPU, o 576 después de Kyber), escalabilidad de una sola estructura (más de 134 000 chips a 47 Pb/s), latencia determinista gracias a la programación estática XLA y TCO para cargas de trabajo que se ajustan al modelo TPU.

Donde 8 presenta desventajas: capacidad HBM por chip (216 GB frente a los 288 GB de HBM4 de Rubin), dispersión (NVIDIA tiene una ruta de hardware 2:4, Google no) y amplitud del ecosistema (CUDA, cuDNN, TensorRT-LLM y la pila de servicios basada en PyTorch llegan primero a NVIDIA; PyTorch nativo en TPU todavía está en vista previa).

Ambas plataformas tienen demanda. Según se informa, Meta está en conversaciones para un acuerdo multimillonario para implementar TPUs de Google en sus centros de datos a partir de 2027, con la posibilidad de alquilar TPUs en la nube ya en 2026. Al mismo tiempo, Google Cloud anunció instancias A5X basadas en NVIDIA Vera Rubin NVL72, con capacidad para escalar a 80 000 GPUs Rubin en un solo sitio y 960 000 GPUs en implementaciones multisitio. Google está desarrollando ambas a gran escala.

Cierre

La TPU de octava generación consta de dos chips en lugar de uno, diseñada para el entrenamiento a gran escala y la inferencia automatizada actuales, en lugar de para cargas de trabajo de IA de propósito general. La 8t aumenta la escalabilidad a 9,600 chips por superpod y la escalabilidad horizontal a más de 134 000 chips por tejido Virgo. La 8i reemplaza los SparseCores por silicio de aceleración colectiva y cambia el toroide 3D por Boardfly para cumplir con los objetivos de latencia requeridos por MoE a gran escala. La hoja de ruta de NVIDIA, con Vera Rubin, Rubin Ultra y Kyber, reducirá algunas de estas brechas entre 2026 y 2027, pero la ventaja del dominio de escalabilidad horizontal persiste por ahora. Para los laboratorios de vanguardia que ejecutan modelos de mezcla de expertos en cientos de miles de chips, la 8 es una alternativa creíble a Grace Blackwell, y las discusiones de Meta sugieren que el mercado está empezando a tenerlo en cuenta.