El lanzamiento de Gemini la semana pasada representó el máximo esfuerzo de Google por consolidar su liderazgo como empresa de inteligencia artificial, especialmente tras el año en que los modelos GPT de OpenAI se posicionaron como la plataforma de inteligencia artificial generativa más popular a nivel mundial.

Para desarrollar esta nueva familia de modelos, la compañía llevó a cabo una significativa expansión de su infraestructura, con el objetivo de demostrar que es posible entrenar modelos prescindiendo de las GPU de Nvidia.

A pesar de la reticencia de Google a proporcionar detalles específicos sobre la construcción de los tres modelos Gemini, hemos obtenido información a través de entrevistas, documentos de investigación y declaraciones públicas recabadas por DCD.

Gemini Ultra, el modelo más grande de la serie, se entrenó en varios data centers, un avance respecto a modelos anteriores que se entrenaban en instalaciones únicas, como PaLM-2.

"No revelamos exactamente los detalles de cuántas ubicaciones, pero se entrenó en varios sitios y varios clústeres dentro de esos sitios", dijo el CEO de Google Cloud, Thomas Kurian, a DCD.

"Utilizamos una tecnología llamada multi-host para permitirnos distribuir el entrenamiento. La razón por la que normalmente distribuimos el entrenamiento es para asegurarnos de que, si un lado, por ejemplo, tiene problemas de energía u otras cosas, tengamos resiliencia. También nos permite implementar un clúster más grande de máquinas, debido a consideraciones de espacio y energía".

Se espera que multi-host se implemente en Google Cloud para los clientes, lo que debería darnos una mejor comprensión de las limitaciones de latencia (y, por lo tanto, las restricciones de distancia) de las instalaciones que operan juntas en una ejecución.

Para lograrlo, Google conecta los TPU SuperPods (que tienen 4.096 chips cada uno) utilizando la red intra-cluster (distancia entre dos objetos que pertenecen al mismo clúster) e inter-cluster (distancia entre dos objetos que pertenecen a dos clústeres diferentes) de Google, según un informe de Google DeepMind. La compañía explota el paralelismo de modelos dentro de un SuperPod y el paralelismo de datos a través de varios SuperPods.

En el centro de todo esto está la plataforma de red de Google, Jupiter.

Depende de una red de conmutación óptica interna (ahora conocida como OCS pero anteriormente llamada Mission Apollo) que reemplaza la columna vertebral del centro de datos.

En las topologías de red tradicionales, las señales saltan hacia atrás y hacia adelante entre lo eléctrico y lo óptico. "Todo ha sido salto por salto, conviertes de nuevo a lo electrónico, lo devuelves a la óptica, y así sucesivamente, dejando la mayor parte del trabajo en el dominio electrónico", explicó Amin Vahdat, líder del equipo de infraestructura de sistemas y servicios de Google, a DCD a principios de este año.

"Esto es caro, tanto en términos de costo como de energía".

Con su OCS personalizada, la compañía "deja los datos en el dominio óptico tanto tiempo como sea posible", utilizando pequeños espejos para redirigir haces de luz desde un punto de origen y enviarlos directamente al puerto de destino como una conexión cruzada óptica.

Esto reduce drásticamente la latencia, así como los costos, lo que hace posible la implementación de Multi-host.

Para Ultra, la OCS se utilizó para reconfigurar dinámicamente cubos de chips 4x4x4 en topologías de toro 3D arbitrarias en alrededor de 10 segundos. "Decidimos retener un pequeño número de cubos por SuperPod para permitir hot standbys y mantenimiento continuo", dice el informe.

Cada versión de Gemini (Nano, Pro y Ultra) se entrenó en las TPU de Google, utilizando una mezcla de TPUv5e y TPUv4.

Se entrenó al modelo Pro en cuestión de semanas, "aprovechando una fracción de los recursos de Ultra", según el informe de Google DeepMind.

"El entrenamiento de Gemini Ultra utilizó una gran flota de aceleradores TPUv4", agrega.

Aunque TPUv5e tiene una mejora de 2.3× en rendimiento-precio en comparación con TPUv4 para entrenar modelos de lenguaje grandes (según Google), solo se anunció oficialmente en noviembre. Es probable que estuviera disponible internamente en Google antes, pero probablemente no en cantidades lo suficientemente grandes para Ultra.

Sin embargo, el hecho de que los modelos competitivos de ChatGPT se entrenaran en el hardware de Google marca un paso importante para romper el control de Nvidia sobre el desarrollo de IA, argumenta la compañía.

"He estado viendo múltiples publicaciones y artículos desinformados recientemente afirmando 'no hay aprendizaje automático sin las GPU de Nvidia' o 'el aprendizaje automático solo se hace con CUDA de Nvidia'", dijo Max Sapozhnikov, jefe de crecimiento de Cloud TPU de Google, en Twitter/X.

"Es genial ver que este mito se está desmitificando: hay MUCHO aprendizaje automático excelente sucediendo en TPUs sin ninguna dependencia de GPU o CUDA de Nvidia".

Añadió: "Anthropic, Midjourney, Salesforce y muchos otros ya están construyendo sus sistemas en TPUs, aprovechando los beneficios del costo y la eficiencia energética del hardware, así como las optimizaciones del compilador XLA".

Anthropic también utiliza el hardware Trainium de Amazon, después de que AWS invirtiera en la empresa junto con Google.

Google aún no ha compartido el punto de diseño térmico (TDP) de sus últimas TPUs, pero un artículo de investigación de 2021 revela que la TPUv3 tenía un TDP de 450W (660W si se incluye la potencia para el sistema de memoria DSA más su parte de la potencia del host del servidor), en comparación con los 280W/460W del chip anterior.

La compañía ha refrigerado por líquido sus TPUs desde 2018. "Hemos implementado sistemas a gran escala que tienen huellas muy densas y cuentan con características avanzadas como la refrigeración líquida, lo que le permite obtener significativamente más rendimiento del sistema", dijo Kurian.

Aunque la refrigeración líquida es necesaria para el aumento de las temperaturas en los data centers de alta densidad, tiene un efecto secundario no deseado: los rayos cósmicos.

A principios de este año, investigadores de NTT y la Universidad de Hokkaido advirtieron en un artículo que "si los semiconductores se enfrían con agua, se espera que el recuento de neutrones térmicos aumente significativamente".

Todo el hardware a gran escala puede ser susceptible a problemas de radiación, y a medida que los nodos de proceso se hacen más pequeños, ese riesgo aumenta. Esto puede corromper datos o, lo que es más preocupante, llevar a una corrupción silenciosa de datos. El investigador de radiación de semiconductores Andrew Keller le dijo a DCD el año pasado.

Keller se propuso averiguar con qué frecuencia un data center en Denver, Colorado, con 100,000 FPGAs operativas se vería afectado por la radiación. Descubrió que tal implementación experimentaría un problema de memoria de configuración cada media hora en promedio y un problema de corrupción de datos silencioso cada 0.5-11 días.

No está claro cuán susceptibles son las TPUs de Google a la radiación, pero la compañía incluyó una mención de ellas en el lanzamiento inicial de su artículo de investigación. "Las fallas genuinas de las máquinas son comunes en todos los aceleradores de hardware a escalas tan grandes, debido a factores externos como los rayos cósmicos". Curiosamente, el artículo se actualizó silenciosamente para eliminar esa mención; hemos preguntado a Google por qué.

Con Gemini Ultra, Google dijo que esperaba que "los eventos de corrupción de datos impactaran en el entrenamiento cada semana o dos. Detectar y eliminar rápidamente el hardware defectuoso requirió varias nuevas técnicas que aprovechan la repetición determinista para aislar cálculos incorrectos, combinadas con escáneres proactivos de corrupción de datos en máquinas inactivas y hot standbys".

La compañía agregó que su "infraestructura completamente determinista" le permitió identificar rápidamente las causas raíz (incluidas las fallas de hardware) durante el desarrollo que condujo al modelo Ultra, y esto fue un ingrediente crucial para un entrenamiento estable".

Finalmente, el artículo revela que la compañía prescindió del "enfoque convencional de hacer checkpoints periódicos de pesos en el almacenamiento persistente del clúster". En cambio, la compañía "utilizó copias redundantes en memoria del estado del modelo y, en caso de fallas no planificadas de hardware, nos recuperamos rápidamente directamente desde una réplica del modelo intacta".

Esto difiere de las ejecuciones de entrenamiento de PaLM y PaLM-2, lo que llevó a "una sustancial aceleración en el tiempo de recuperación, a pesar de los recursos de entrenamiento significativamente mayores que se estaban utilizando".

El goodput, esencialmente el número de bits de información útil entregados por la red a un destino específico por unidad de tiempo, "para el trabajo de entrenamiento a la mayor escala aumentó del 85-97%", según dijo la compañía.