El próximo 100X para el rendimiento del hardware de IA será más difícil

Para aquellos de nosotros a quienes nos gusta el hardware y esperábamos una gran revelación sobre el procesador de IA TPUv5e y el sistema circundante, la interconexión y la pila de software en la conferencia Hot Chips 2023 de esta semana, el discurso de apertura de Jeff Dean y Amin Vahdat, los dos más importantes técnicos de Google, fue un poco decepcionante. Pero de todos modos la charla de Google nos dio algo de alimento para los experimentos mentales de IA.

Han pasado diez años desde que Dean, quien ha sido fundamental en tantas de las tecnologías que Google ha creado que probablemente nunca se le debería permitir subir a un avión o escalar rocas, hizo algunos cálculos en un trozo de papel y descubrió que Si Google agregara funciones de inteligencia artificial a su motor de búsqueda del mismo nombre, tendría que duplicar el tamaño de su centro de datos y enviaría a Google por el camino de la creación de sus motores matemáticos matriciales personalizados de Unidad de Procesamiento Tensor, o TPU.

Diez años después, la IA es más compleja y requiere un uso intensivo de computación, y el tan discutido hierro TPUv4, si bien es útil ahora y durante muchos años, parece un poco obsoleto. Los sistemas TPUv4 han sido aumentados por el TPUv5e, muy probablemente basado en procesos de 5 nanómetros y muy probablemente con al menos el doble del rendimiento máximo bruto, ejecutándose en los centros de datos de Google. (Hicimos una inmersión profunda en el sistema TPUv4 en octubre del año pasado y aún tenemos que actualizarlo con la interconexión del interruptor óptico que se reveló a principios de este año y que se discutirá en detalle en Hot Chips esta semana).

Y como esperábamos, algunos detalles sobre la variante TPUv5e utilizada tanto para entrenamiento como para inferencia se revelaron en el evento Google Cloud Next 2023 que se llevó a cabo al mismo tiempo que Hot Chips 2023, y llegaremos a todo eso en breve. También esperamos que una vez que las instancias en la nube estén disponibles ejecutando TPUv5e, ofrezcan alrededor de un 30 por ciento más de rentabilidad que las instancias TPUv4 anteriores en Google Cloud. Incluso podría llegar a tener una mejor relación calidad-precio. Tendremos que ver.

Elegimos las charlas de Google en Hot Chips en lugar de la conferencia magistral de Google Next porque cuando Dean habla, los arquitectos de sistemas deben escuchar. Dean ha participado en casi todas las tecnologías centrales de Google: la forma MapReduce de analizar big data, la superposición relacional BigTable para el sistema de almacenamiento distribuido Spanner, el software TensorFlow y Pathways que sustenta los modelos de IA más grandes de la familia PaLM, el Hardware de TPU, y ahora el modelo de lenguaje grande Gemini que le dará una oportunidad a los modelos GPT-4 y GPT-5 de OpenAI. (Bueno, todos esperan que haya dinero en alguna parte de esto fuera de las fábricas de semiconductores y los fabricantes de hardware). Dean dirigió Google Research durante muchos años y cofundó el equipo de Google Brain que reunió a los mejores investigadores de IA y su adquisición de DeepMind y donde Actualmente es el científico jefe.

Su presentación principal estuvo dividida con Amin Vahdat, quien al igual que Dean también es miembro de Google y actualmente es vicepresidente de ingeniería de la empresa, fue profesor de ciencias informáticas e ingeniería en la Universidad de California en San Diego y director de su centro de sistemas en red antes de unirse a Google en 2010, donde fue líder técnico de redes, luego líder técnico de computación, almacenamiento y redes y, más recientemente, ahora está a cargo del equipo de aprendizaje automático, sistemas e inteligencia artificial en la nube de la empresa como además de ser responsable de la investigación de sistemas en Google. MSCA desarrolla y mantiene Compute Engine y Borg, el conjunto de motores de cómputo CPU, TPU y GPU, la red que los une y toda la pila de software de inteligencia artificial que utilizan Google y sus clientes de la nube en la producción.

Dean y Vahdat prácticamente definen y crean la infraestructura de Google. No está claro qué papel desempeña actualmente Urs Hölzle, también miembro de Google y primer vicepresidente de ingeniería de la empresa, luego vicepresidente de búsqueda y durante más de dos décadas vicepresidente senior de ingeniería a cargo del equipo de infraestructura técnica. su nuevo hogar en Auckland, Nueva Zelanda. En Hot Chips, Dean trazó el terreno para la IA y Vahdat habló sobre las crecientes demandas y el hardware para atravesar ese terreno.

El director de investigación de Google, Peter Norvig, acuñó hace mucho tiempo el dicho de que “más datos superan a los algoritmos inteligentes”, y eso sigue siendo cierto y es la base misma de los grandes modelos de lenguaje que tanto entusiasman a todos con la IA en estos días. (Norvig también recordó a todos que mejores datos también superan a más datos).

Dean dijo que Google se centra en tres enfoques diferentes para impulsar los modelos de IA (escasez, computación adaptativa y redes neuronales dinámicas) y también estaba tratando de que la serpiente de la IA se comiera la cola en lugar de mordisquearla y que realmente los sistemas expertos de IA comenzaran a diseñar. Procesadores de IA para acelerar todo el ciclo de desarrollo de chips y así ayudar a que el hardware en constante mejora llegue al campo para satisfacer los modelos de más rápido crecimiento.

Dean explicó que con los modelos de IA creados hasta ahora, todo el modelo, con sus crecientes capas y su enorme cantidad de parámetros, impulsado por miles de millones, luego decenas de miles de millones, luego cientos de miles de millones de fragmentos simbólicos de datos, se activaba cada vez que la IA. El modelo entrenado con un nuevo token o un token se presentó frente a un modelo terminado para realizar inferencias de IA. Pero con marcos como Pathways, que sustenta la familia de modelos PaLM en Google, el mundo está pasando de tener modelos de IA separados y especializados para diferentes tareas a tener un modelo básico único.

Recientemente, repasamos la escala de todos los modelos de IA más importantes cuando hablamos de la startup de IA Inflection AI, y le recordamos que se estima que el modelo supersecreto GPT-4 de OpenAI, por ejemplo, tiene entre 1 billón y 1,76 billones de parámetros y en algún lugar en la gama de 3,6 billones de tokens que tiene Google con su modelo PaLM-2, que abarca más de cien idiomas. Se trata de una gran cantidad de parámetros para mantener en la memoria de los motores informáticos y de una gran cantidad de datos para impulsar un modelo para entrenarlo. Por supuesto, el corpus de conocimientos lingüísticos globales aumenta cada año en una cierta cantidad, y el recuento de parámetros puede aumentarse para impulsar una inferencia de mejor calidad. Los modelos grandes se utilizarán como base para entrenar modelos más pequeños, o para activar secciones del modelo más grande que han sido ajustadas para tener cierto conocimiento especial, como lo muestra Dean usando el marco Pathways:

Con los modelos dispersos, las piezas del modelo de IA se activan según se necesitan, y sólo esas piezas. No está claro cómo sabe el modelo qué piezas activar, y esa es la salsa secreta en el marco de Pathways que se ha perfeccionado con el modelo Gemini que sin duda utiliza las técnicas de las que habla Dean. Es importante tener en cuenta que el marco Pathways no es de código abierto como el anterior y presumiblemente mucho más rudimentario marco TensorFlow creado por Google que fue de código abierto en noviembre de 2015. Por lo tanto, solo sabremos lo que Google nos dice sobre Pathways y Gemini. Esperamos que Google publique pronto un artículo sobre el modelo Gemini AI. Google publicó un artículo en octubre de 2021 sobre las redes de centros de datos reconfigurables de Gemini, en el que Vahdat fue uno de los coautores, pero esto no parece tener nada que ver con el LLM de Gemini.

En cualquier caso, estos modelos básicos pueden manejar muchas modalidades diferentes (imágenes, sonido, texto, video) y también activar el modelo de manera escasa, lo que reduce drásticamente el costo computacional para realizar más capacitación e inferencia de producción.

"En lugar de tener este modelo gigante, los modelos dispersos pueden ser mucho más eficientes", explicó Dean. “Simplemente recurren a las piezas correctas del modelo general, y el aspecto de las piezas correctas también es algo que se aprende durante el proceso de capacitación. Luego se pueden especializar diferentes partes del modelo para diferentes tipos de entradas. Y el resultado final es que terminas con algo en lo que tocas solo el 1 por ciento correcto o el 10 por ciento correcto de un modelo muy grande y esto te brinda una capacidad de respuesta mejorada y una mayor precisión, porque ahora tienes una capacidad de modelo mucho mayor que la que tenías. Podría entrenar de otra manera y luego recurrir a las partes adecuadas”.

Según Dean, hay otro aspecto de la escasez que es importante que los arquitectos de sistemas contemplen, algo que es diferente de la escasez de grano fino de la que se habla comúnmente con los aceleradores, donde la escasez dentro de un solo vector o tensor (normalmente donde dos de cada cuatro Los valores en una matriz se establecen en cero, convirtiéndolos de densos a dispersos) y eso también es diferente de la escasez de grano grueso donde los módulos grandes dentro de un modelo se activan o no. Esta escasez se ve así, y consolidamos un par de gráficos de Dean en una página para que puedas asimilarlo todo:

"La mayoría de los trabajos actuales sobre escasez utilizan el mismo tamaño y estructura para cada experto", dijo Dean. “Así que aquí tienes un grupo de expertos ecológicos para ellos. Aquí tiene alguna función de enrutamiento aprendida que aprende qué experto es bueno en qué tipo de cosas y luego envía algunos de los ejemplos al experto apropiado. Y el equilibrio computacional generalmente se logra al tener un cálculo de igual tamaño por experto y un flujo igual de la cantidad de ejemplos para cada experto. Para los arquitectos informáticos, esto significa que el rendimiento aleatorio entre aceleradores es realmente importante. Esto es cierto para todos los modelos dispersos: desea poder enrutar rápidamente las cosas de una parte del modelo a la otra de la manera correcta. Sin embargo, una cosa que quizás desee poder hacer es, en lugar de tener costos computacionales fijos, variar el costo computacional de diferentes partes del modelo. Y no tiene sentido gastar la misma cantidad de cálculo en cada ejemplo, porque algunos ejemplos son 100 veces más difíciles. Y deberíamos gastar 100 veces más cálculo en cosas que son realmente difíciles que en cosas que son muy simples”.

Resulta que algunos de los pequeños expertos podrían necesitar sólo una pequeña cantidad de cálculo y se utilizarían tal vez para el 90 por ciento de las indicaciones en un modelo utilizado en producción. Los expertos crecen para hacer cosas más complejas, con diferentes estructuras computacionales y posiblemente con más capas, y son más computacionalmente intensivos y, por lo tanto, más costosos de ejecutar. Y si está ejecutando un servicio de inteligencia artificial, querrá poder atribuir el costo al valor de la respuesta experta entregada para poder cobrar adecuadamente.

Esto no es una teoría para Google; la razón por la que la empresa habla de ello es porque el marco Pathways hace esto:

Eso es escasez y computación adaptativa. Lo último que hay que buscar, dice Dean, como se menciona en el cuadro anterior, son las redes neuronales dinámicas, lo que significa que se puede agregar o quitar capacidad de un sistema en ejecución, algo que hemos tenido para servidores de propósito general durante algunas décadas ( aunque no en una plataforma X86, por extraño que parezca, y aquí es donde Arm y RISC-V podrían alcanzar a los mainframes y los sistemas RISC/Unix). Lo que ocurre con las CPU y sus cargas de trabajo (ciertamente existe una asignación dinámica a nivel de hipervisor) también se aplica a las GPU, TPU y otros motores informáticos de IA. Desea poder agregar o restar capacidad dinámicamente de un grupo de núcleos para cualquier modelo determinado mientras ejecuta inferencia o entrenamiento. El modelo PaLM con 500 mil millones de parámetros de Google se entrenó en Pathways y lo hizo con asignación dinámica de recursos en un par de pods con 6,144 motores TPUv4, pero los motores TPUv4 en realidad se distribuyeron en seis pods con un total de 24,576 motores, todos vinculados. a través de una red de centro de datos de alta velocidad. Como esto:

Un módulo TPUv4 es efectivamente una fila de computación con enlaces de cobre para un cubo toroidal de 4x4x4 de motores TPU y enlaces ópticos en un toroide de estos cubos con 64 de ellos interconectados en las caras del cubo. PaLM tardó 56 días en entrenarse y esta es una instantánea del día 5.71. Las cargas de trabajo cambiaron mucho con el tiempo y el trabajo de PaLM intentó mantenerse unido, más o menos, por razones de proximidad y latencia, pero se movía por el clúster un poco como autómatas celulares.

Estas son las conclusiones clave que Dean quería transmitir a los arquitectos de sistemas:

Aquí es donde Vahdat tomó el relevo y mostró la curva exponencial en el crecimiento del tamaño del modelo a la que se enfrenta la industria de la IA:

No hay absolutamente ninguna razón para creer que la complejidad del modelo y, por lo tanto, los requisitos de capacidad informática vayan a disminuir. Pero los modelos están creciendo a un ritmo de 10 veces por año y, en el mejor de los casos, el rendimiento de las GPU y TPU está creciendo entre 2 y 3 veces por año, según nuestra estimación. Las empresas tienen que compensarlo escalando, lo cual es difícil, y mejorando sus modelos, lo cual también es difícil. Todavía tenemos algunos trucos de formato numérico que podemos usar y también algunos trucos de escasez, pero creemos que ambos se quedarán sin espacio pronto.

Esta es la razón por la que Google ya ha implementado motores TPUv5e en su flota (y probablemente lo hizo hace dos años si hablamos de ello ahora) y por qué el TPUv6 con una posible extensión de letra como i o e probablemente esté en proceso en este momento y listo para su lanzamiento. pronto se implementará para ayudar a respaldar la comercialización del modelo Gemini.

Para obtener una mejora de 100 veces en el rendimiento por TCO hasta ahora, y Vahdat dio una conferencia completa sobre cómo es así como se necesita medir el valor relativo de la IA o las plataformas informáticas de propósito general, y siempre hemos estado de acuerdo con esto antes de que existiera la IA. sistemas: Google tuvo que hacer un montón de cosas:

"El tipo de infraestructura informática que tenemos que construir para afrontar este desafío tiene que cambiar", dijo Vahdat en su parte del discurso de apertura. “Y creo que es realmente importante tener en cuenta que no estaríamos donde estamos hoy si intentáramos hacer esto con informática de propósito general. En otras palabras, en realidad, la sabiduría convencional que hemos desarrollado durante los últimos 50 o 60 años se ha tirado por la ventana. Creo que es justo decir que en Google y, lo que es más importante, en toda la comunidad, los ciclos de aprendizaje automático ocuparán una fracción cada vez mayor de lo que buscamos hacer”.

Una cosa en la que Google se está centrando es la optimización del hardware y el software para gestionar las cargas de trabajo y el consumo de energía de forma dinámica en grupos de sistemas:

Con trabajos vinculados a la memoria, el voltaje y el amperaje pueden variar enormemente, y tratar de gestionar el consumo de energía en un grupo de miles a decenas de miles de motores de computación es, como dijo Vahdat, “entre difícil e imposible”. Al no crear puntos calientes masivos en el clúster, lo que probablemente ocurrió mientras Google entrenaba el modelo PaLM, eso aumenta la longevidad de los dispositivos y reduce las interrupciones, que son muy disruptivas en el trabajo sincrónico como el entrenamiento de IA, al igual que lo es para la simulación de HPC. y modelado. En lugar de retroceder hasta un punto de control y comenzar desde allí, sería mejor evitar la interrupción en primer lugar.

Así es como se juega con las frecuencias y voltajes centrales para equilibrar un poco las cosas.

Si Google está hablando de esto, entonces Borg probablemente tenga esto al menos para los clústeres de TPU. Pero tal vez no. En cualquier caso, la idea es que hay una conversación constante entre un plano de control que analiza la ubicación de los trabajos en el clúster y los parámetros de energía para esos trabajos, y la ubicación y el movimiento de esos trabajos a medida que se ejecutan es un proceso continuo. No solo juegas Tetris una vez para colocar trabajos, como lo hacen los programadores de trabajos como Borg y Omega dentro de Google, sino que los reemplazas según sea necesario a medida que las limitaciones de energía afectan el desempeño o las limitaciones de desempeño afectan el poder.

Lanzar nuevos chips TPU más rápido es parte de eso, y Google ha utilizado sus propias herramientas EDA mejoradas con inteligencia artificial para ayudar a diseñar fragmentos de los chips TPUv4i y TPUv4 y presumiblemente también del TPUv5e. En este momento, según Dean, se necesitan unos tres años para sacar un chip. Eso es de seis a doce meses para el diseño y la exploración, un año para implementar el diseño, seis meses para grabarlo con una fundición y doce meses para ponerlo en producción, probarlo y ponerlo en marcha. No está claro en qué medida la IA puede acortar el ciclo de desarrollo de chips o en qué medida puede reducir el esfuerzo humano, y Dean no ofreció ninguna estimación. Pero está claro que cuanto más se acerque el diseño del hardware a los modelos de IA emergentes, mejor.

Presentamos aspectos destacados, análisis e historias de la semana directamente desde nosotros a su bandeja de entrada sin nada intermedio. Suscríbase ahora