Hola a todos, soy Weixue AI. Hoy descifraré los detalles del marco GPT-4 y el proceso de capacitación, la composición del conjunto de datos, la estrategia de paralelismo, la compensación de expertos, la compensación de razonamiento, etc. El 14 de marzo de 2023, OpenAI lanzó GPT-4. Sin embargo, el marco de GPT-4 no se hizo público. La razón por la que OpenAI no reveló la estructura de GPT-4 no fue por amenazas potenciales para los humanos, sino por los modelos se pueden copiar. De hecho, esperamos que Google, Meta, Anthropic, Inflection, Character, Tencent, Alibaba, Baidu y otros tengan modelos tan potentes como GPT-4 o incluso más fuertes a corto plazo. Claro, OpenAI tiene increíbles capacidades de ingeniería y lo que han construido es increíble, pero las soluciones que emplean no son mágicas. Este es un esquema práctico con muchas compensaciones complejas. La mayor ventaja de OpenAI es que tienen la mayoría de los casos de uso del mundo real, el talento de ingeniería líder y pueden continuar liderando a otras empresas a través de modelos futuros.
Estado GPT-4
Hemos recopilado una gran cantidad de información sobre GPT-4 de múltiples fuentes y hoy queremos compartir algunas. Esto incluye la arquitectura del modelo, la infraestructura de entrenamiento, la infraestructura de inferencia, la cantidad de parámetros, la composición del conjunto de datos de entrenamiento, la cantidad de etiquetas, la cantidad de capas, la estrategia de paralelismo, la adaptación visual multimodal, el proceso de pensamiento detrás de las diferentes compensaciones de ingeniería, las técnicas únicas implementadas y cómo alivian algunos de los mayores cuellos de botella asociados con la inferencia en modelos enormes.
El aspecto más interesante de GPT-4 es comprender por qué tomaron ciertas decisiones arquitectónicas. Además, describiremos el costo del entrenamiento y la inferencia de GPT-4 en el A100, y presentaremos la escala en comparación con el uso del H100 para arquitecturas modelo de próxima generación.
Primero, veamos el enunciado del problema. De GPT-3 a GPT-4, OpenAI espera escalar en un factor de 100, pero el quid del problema es el costo. Los modelos de transformadores densos no se pueden extender más. Dense Transformer es la arquitectura modelo utilizada por OpenAI GPT-3, Google PaLM, Meta LLAMA, TII Falcon, MosaicML MPT y otros modelos. Podemos enumerar fácilmente 50 empresas que utilizan la misma arquitectura para la formación LLM. Es una buena arquitectura, pero tiene fallas en términos de escalabilidad.
Marco GPT-4
GPT-4 es más de 10 veces más grande que GPT-3. Hasta donde sabemos, tiene alrededor de 1,8 billones de parámetros, repartidos en 120 capas, mientras que GPT-3 solo tiene alrededor de 175 mil millones de parámetros.
OpenAI logró mantener el costo dentro de límites razonables mediante el uso de un modelo Mixed Expert (MoE).
Además, el modelo de OpenAI tiene 16 expertos, y cada experto tiene alrededor de 111 mil millones de parámetros de perceptrón multicapa (MLP). Cada pase adelantado es dirigido por dos expertos.
Aunque la literatura habla de algoritmos de enrutamiento avanzados que eligen a qué experto enrutar cada token, se dice que el modelo GPT-4 actual de OpenAI es relativamente simple.
Además, hay aproximadamente 55 mil millones de parámetros compartidos en el mecanismo de atención.
Solo se utilizan alrededor de 280 mil millones de parámetros y 560 TFLOPS por paso hacia adelante (generando un token). Esto contrasta marcadamente con los aproximadamente 1,8 billones de parámetros y los 3700 TFLOP necesarios por paso hacia adelante para el modelo completamente denso.
Composición del conjunto de datos
OpenAI entrenó a GPT-4 en alrededor de 13 billones de tokens. Esto tiene sentido considerando que RefinedWeb de CommonCrawl contiene aproximadamente 5 billones de tokens de alta calidad. Como referencia, el modelo Chinchilla de Deepmind y el modelo PaLM de Google utilizaron alrededor de 1,4 billones y 0,78 billones de tokens para entrenamiento, respectivamente. Incluso se dice que PaLM 2 está entrenado en alrededor de 5 billones de tokens.
Este conjunto de datos no contiene 13 billones de tokens únicos. Por el contrario, este conjunto de datos contiene varias épocas debido a la falta de tokens de alta calidad. Los datos de texto pasan por 2 épocas, mientras que los datos de código pasan por 4 épocas. Curiosamente, esto es mucho menos que el mejor estado de Chinchilla, lo que indica que el modelo debe entrenarse con el doble de tokens. Esto muestra que los tokens de fácil acceso son difíciles de encontrar en la web. Hay 1000 veces más tokens de texto de alta calidad que los mencionados anteriormente, e incluso más tokens de audio y visuales, pero adquirirlos no es tan fácil como un simple web scraping.
También hay millones de filas de datos de ajuste fino de orientación de ScaleAI, así como internamente. Desafortunadamente, no pudimos encontrar información detallada sobre sus datos de función de alta resolución de aprendizaje por refuerzo (RLHF).
La longitud del contexto (seqlen) de la fase previa al entrenamiento es de 8.000. La versión de 32 000 seqlen de GPT-4 se ajusta en 8000 seqlen después del entrenamiento previo.
El tamaño del lote se incrementó gradualmente durante varios días en el clúster, pero al final, ¡OpenAI usó un tamaño de lote de 60 millones! Por supuesto, dado que no todos los expertos ven todos los tokens, en realidad son solo 7,5 millones de tokens procesados por cada experto.
Estrategias para el paralelismo
La estrategia para paralelizar todas las GPU A100 es muy importante. Aprovechan el paralelismo de tensor de 8 vías, ya que es una limitación de NVLink. Además de eso, también usaron paralelismo de tubería de 15 vías. En teoría, estos conductos son demasiados cuando se considera la relación entre la comunicación de datos y el tiempo de cálculo, pero si están limitados por la capacidad de la memoria, entonces tiene sentido.
FP16 con solo parámetros ocupa alrededor de 30 GB de memoria por GPU cuando se paraleliza puramente mediante canalización + tensores. Una vez que agrega el caché KV y la sobrecarga, en teoría tiene sentido si la mayoría de las GPU de OpenAI son A100 de 40 GB. Probablemente usaron ZeRo Phase 1. También pueden usar FSDP a nivel de bloque o paralelización de datos compartidos híbridos.
En cuanto a por qué no usaron FSDP para el modelo completo, podría deberse a una mayor sobrecarga de comunicación. Si bien la mayoría de los nodos de OpenAI tienen conexiones de red de alta velocidad entre ellos, no todos tienen un alto ancho de banda entre ellos. Creemos que al menos algunas de las conexiones entre clústeres tienen un ancho de banda mucho menor que otras.
tarifa de entrenamiento
La cantidad de operaciones de punto flotante (FLOPS) que utiliza OpenAI para entrenar GPT-4 es de aproximadamente 2,15x10^25, con aproximadamente 25 000 GPU A100, que se ejecutan en 90 a 100 días, y la tasa de utilización es de entre 32 % y 36 %. Entre ellos, la muy baja utilización se debe en parte a una gran cantidad de fallas que requieren reiniciar los puntos de control. Los cortes mencionados anteriormente son muy costosos.
Otra razón es que realizar una operación de reducción global en tantas GPU es muy costoso, especialmente si sospechamos que el clúster es en realidad un grupo de pequeños clústeres con conexiones de red débiles, cada uno con 800 G de ancho de banda sin bloqueo dentro de /1.6T, pero la conexión entre estos clústeres es de solo 200G/400G.
Si una GPU A100 en la nube cuesta alrededor de $ 1 por hora, el costo de solo esta capacitación ascendería a alrededor de $ 63 millones. Esto no incluye todas las pruebas, ejecuciones de entrenamiento fallidas y otros gastos como la recopilación de datos, la optimización de hiperparámetros de RL, el personal, etc. Teniendo en cuenta estos factores, el costo real es mucho mayor. Además, esto supone que tiene alguna organización que compra los chips, el equipo de red y los centros de datos, paga los gastos de capital y los alquila para su uso.
Actualmente, la capacitación previa se puede completar en aproximadamente 55 días utilizando aproximadamente 8192 GPU H100 a un costo de $ 21,5 millones, o $ 2 por hora. Como nota, creemos que 9 empresas tendrán más GPU H100 para fin de año. Si bien no todas las empresas los usarán todos para una sola ejecución de entrenamiento, aquellas que lo hagan podrán entrenar modelos mucho más grandes. Meta tendrá más de 100 000 GPU H100 para fines de este año, pero una parte significativa de ellas se distribuirá en sus centros de datos para la inferencia. Su clúster individual más grande seguirá teniendo más de 25 000 GPU H100. A finales de este año, muchas empresas tendrán suficientes recursos informáticos para entrenar un modelo de la escala de GPT-4.
mecanismo de intercambio experto
MoE es una excelente manera de reducir la cantidad de parámetros durante la inferencia, al mismo tiempo que aumenta la cantidad de parámetros, lo cual es necesario para codificar más información por token de entrenamiento, ya que es muy difícil obtener tokens de calidad suficientemente alta. Si OpenAI realmente estuviera tratando de lograr un rendimiento óptimo, en realidad necesitaría entrenar el doble de marcadores.
Dicho esto, OpenAI hace varias concesiones. Por ejemplo, durante la inferencia, lidiar con MoE es muy difícil porque no se usa cada parte del modelo en cada generación de token. Esto significa que algunas partes pueden estar inactivas mientras que otras están en uso. Para los usuarios del servicio, esto puede afectar seriamente la utilización.
Los investigadores han demostrado que usar de 64 a 128 expertos da mejores resultados de pérdida que usar 16 expertos, pero eso es pura investigación. Hay varias razones para elegir menos especialistas. Una de las razones por las que OpenAI eligió usar 16 expertos es que más expertos tienen dificultades para generalizar muchas tareas. Más expertos también hacen que sea más difícil lograr la convergencia. Durante el entrenamiento a tan gran escala, OpenAI optó por ser más conservador en la cantidad de expertos.
Además, usar menos expertos también ayuda a su infraestructura de razonamiento. Hay varias compensaciones difíciles cuando se pasa a arquitecturas de inferencia mixta expertas. Comencemos con las compensaciones fundamentales en la inferencia de los modelos de lenguaje general (LLM) antes de analizar los desafíos que enfrentó OpenAI y las elecciones que tomaron.
intercambio de razonamiento
Antes de comenzar, nos gustaría mencionar que después de comunicarnos con todas las empresas de LLM (Large Language Model), llegamos a la conclusión de que la biblioteca de inferencia FasterTransformer de Nvidia es bastante mala y que TensorRT es aún peor. Dado que la plantilla de Nvidia no se puede modificar, las personas deben crear sus propias soluciones desde cero. Si el equipo de Nvidia está leyendo esto, debe mejorar la función de inferencia LLM lo antes posible; de lo contrario, la herramienta estándar se convertirá en una herramienta abierta que facilita agregar soporte de hardware de terceros. Se acerca la ola de maquetas a gran escala. Si no hay una ventaja de software en la inferencia, y el código central aún debe escribirse manualmente, entonces el mercado para el MI300 de AMD y otro hardware será aún mayor.
En la inferencia LLM, hay tres compensaciones principales a considerar, a saber, el tamaño del lote (número de usuarios simultáneos) y el número de chips utilizados.
1. Latencia: el modelo debe responder en un plazo razonable. En una aplicación de chat, uno no quiere esperar unos segundos para comenzar a recibir resultados. El llenado previo (tokens de entrada) y la decodificación (tokens de salida) tardan diferentes tiempos en procesarse.
2. Rendimiento: el modelo debe generar una cierta cantidad de tokens por segundo. Para uso humano, se requieren alrededor de 30 marcadores por segundo. Para otros usos, también son aceptables rendimientos más altos y más bajos.
3. Utilización: el hardware que ejecuta el modelo debe lograr una alta utilización o tendrá un costo prohibitivo. Si bien se puede lograr una mayor utilización agrupando más solicitudes de usuario junto con una latencia más alta y un rendimiento más bajo, esto agrega cierta dificultad.
La inferencia LLM implica principalmente equilibrar dos puntos clave, el ancho de banda de la memoria y la potencia informática. En términos simples, cada parámetro debe leerse y asociarse con 2 operaciones de coma flotante. Por lo tanto, la mayoría de los chips (como el H100 SXM) tienen una relación completamente desequilibrada entre el ancho de banda de la memoria (3 TB/s) y la potencia informática del FP8 (2000 TFLOP/s) en un tamaño de lote de 1. Si solo hay un usuario sirviendo, es decir, un tamaño de lote de 1, entonces el tiempo de inferencia está dominado por el ancho de banda de memoria utilizado para transferir los parámetros necesarios para cada generación de token, mientras que el tiempo de cálculo es casi insignificante.
Para escalar de manera eficiente los modelos de lenguaje grandes a muchos usuarios, el tamaño del lote debe ser superior a 1. Múltiples usuarios pueden compartir el costo de lectura de parámetros. Por ejemplo, cuando el tamaño del lote es 256 o 512, cada byte de lectura de memoria corresponde a 512 o 1024 operaciones de coma flotante. Esta relación está más cerca de la relación entre el ancho de banda de la memoria del H100 y FLOPS. Esto ayuda a lograr una mayor utilización, pero a costa de una mayor latencia.
Mucha gente cree que el principal cuello de botella de la inferencia LLM es la capacidad de la memoria, porque el tamaño del modelo determina en cuántos chips puede caber, pero esto no es cierto. Aunque los modelos grandes requieren múltiples chips para la inferencia, y las capacidades de memoria más altas significan que caben en menos chips, en realidad es mejor usar más chips de los necesarios para reducir la latencia y aumentar el rendimiento, y usar tamaños de lote más grandes para lograr una utilización cada vez mayor.
Infraestructura y compensaciones de inferencia de GPT-4
El uso de la arquitectura del modelo Mixed-of-Experts (MoE) de GPT-4 presenta un nuevo conjunto de dificultades que dificultan todo lo anterior. Cada pase de reenvío generado por token se puede enrutar a un conjunto diferente de expertos. Esto dificulta lograr un equilibrio entre el rendimiento, la latencia y el tamaño del lote.
El GPT-4 de OpenAI tiene 16 expertos, 2 de los cuales están asignados a cada pase hacia adelante. Esto significa que si el tamaño del lote es 8, la lectura de parámetros de cada experto solo puede ser del tamaño del lote 1. Peor aún, un determinado experto podría tener un tamaño de lote de 8, mientras que otros expertos podrían tener 4, 1 o 0. El algoritmo de enrutamiento hará que el pase hacia adelante vaya en una dirección diferente cada vez que se genere un token, lo que hará que la latencia entre los tokens y el tamaño del lote experto varíe significativamente.
La infraestructura de inferencia es una de las principales razones por las que OpenAI eligió un número menor de expertos. Si seleccionan más expertos, el ancho de banda de la memoria dificultará aún más el proceso de inferencia. Los clústeres de inferencia de OpenAI suelen alcanzar tamaños de lote de más de 4k, lo que significa que, incluso con un equilibrio de carga óptimo entre los expertos, el tamaño del lote de expertos es solo de alrededor de 500. Esto requiere un uso a muy gran escala para lograrlo.
Por lo que entendemos, OpenAI realiza inferencias en un grupo de 128 GPU. Tienen varios de estos clústeres en múltiples centros de datos y ubicaciones geográficas. El proceso de inferencia utiliza paralelismo de tensor de 8 vías y paralelismo de tubería de 16 vías. Cada nodo que consta de 8 GPU tiene solo alrededor de 13 000 millones de parámetros, lo que representa menos de 30 GB para la precisión de FP16 y menos de 15 GB para la precisión de FP8/int8. Esto permite que la inferencia se ejecute en una GPU A100 de 40 GB siempre que el tamaño de la memoria caché KV no crezca demasiado entre todos los lotes.
Las capas que contienen varios expertos no se pueden dividir entre diferentes nodos, ya que esto haría que el tráfico de la red fuera irregular y sería demasiado costoso volver a calcular el caché KV entre cada generación de token. Para cualquier futura extensión del modelo MoE y enrutamiento condicional, la mayor dificultad es cómo enrutar alrededor de la memoria caché KV.
El modelo tiene 120 capas, por lo que distribuirlo en 15 nodos diferentes es trivial, pero dado que el primer nodo necesita cargar e incorporar datos, es significativo colocar menos capas en el primer nodo del grupo de inferencia. Además, sobre los rumores de decodificación especulativa que han surgido algunas personas, hablaremos de eso más adelante, pero no estamos seguros de creerles. Esto también explica por qué el primer nodo debe contener menos capas.
Costo de inferencia GPT-4
Aunque los parámetros de avance de GPT-4 son solo 1,6 veces los del modelo Davinchi con parámetros 175B, su costo es 3 veces el del modelo Davinchi. Esto se debe principalmente a que GPT-4 requiere clústeres más grandes y tiene una menor utilización.
Creemos que para que 128 GPU A100 infieran la longitud de secuencia de 8k de GPT-4, el costo por 1000 tokens es de 0,0049 centavos; el costo es de 0,0021 centavos. Vale la pena señalar que asumimos una alta utilización y mantenemos un tamaño de lote grande.
Sin embargo, OpenAI aparentemente tiene una utilización muy baja en ocasiones, lo que puede haber sido una suposición falsa de nuestra parte. Asumimos que OpenAI apagaría el clúster durante las horas de menor actividad y usaría esos nodos para reanudar el entrenamiento desde los puntos de control para modelos de prueba más pequeños y para experimentar con varias tecnologías nuevas. Esto ayuda a reducir el costo de la inferencia. Si OpenAI no lo hubiera hecho, su utilización habría sido menor y nuestras estimaciones de costos se habrían más que duplicado.
Atención de consultas de varios encabezados
MQA es algo que otros están haciendo, pero queremos señalar que OpenAI también está adoptando este enfoque. En resumen, solo se necesita un encabezado y la capacidad de memoria de la caché KV se puede reducir considerablemente. Aun así, GPT-4 con una longitud de secuencia de 32k definitivamente no puede ejecutarse en una GPU A100 de 40GB, y una longitud de secuencia de 8k tiene un límite en el tamaño máximo del lote. Sin este límite, las longitudes de secuencia de 8k estarían significativamente limitadas en el tamaño de lote máximo, incluso hasta el punto de ser económicamente antieconómicas.
lote continuo
OpenAI implementa tamaños de lote variables y procesamiento por lotes continuo. Si lo hace, permite cierto nivel de latencia máxima y optimiza el costo de inferencia. Si es nuevo en el concepto de procesamiento por lotes continuo, puede leer esta página de AnyScale, vale la pena leerla.
decodificación especulativa
OpenAI usa decodificación especulativa en la inferencia GPT-4. No estamos seguros de creer completamente en esta afirmación. Las fluctuaciones de latencia de un token a otro y las diferencias entre las tareas de recuperación simples y las tareas complejas parecen sugerir que esto es posible, pero hay demasiadas variables para estar seguros. Para evitar malentendidos, utilizaremos aquí parte del texto de "Descodificación especulativa por etapas para acelerar la inferencia LLM", con algunas modificaciones y algunos colores.
Por lo general, hay dos fases para usar LLM. La primera es la fase de llenado previo, donde las indicaciones se ejecutan a través del modelo para generar el caché KV y los primeros Logits de salida (distribución de probabilidad de salida de token posible). Esto suele ser rápido, ya que toda la sugerencia se puede procesar en paralelo.
La segunda etapa es la etapa de decodificación. Se selecciona un token de los Logits de salida y se retroalimenta al modelo para generar los Logits del siguiente token. Repita este proceso hasta que se genere la cantidad deseada de tokens. Dado que la decodificación debe ocurrir secuencialmente, cada vez que se requiere que los pesos se transmitan a la unidad de cómputo para generar tokens individuales, la intensidad aritmética de esta segunda etapa (es decir, palabras de FLOP de cómputo/ancho de banda de memoria) cuando se ejecuta en mini lotes nodos ) son extremadamente bajos. Por lo tanto, la decodificación suele ser la parte más intensiva en recursos de la generación autorregresiva.
Es por eso que en las llamadas a la API de OpenAI, los tokens de entrada son mucho más baratos que los tokens de salida.
La idea básica de la decodificación especulativa es usar un modelo de borrador más pequeño y rápido para decodificar múltiples tokens con anticipación, que luego se alimentan al modelo formal (modelo de Oracle) como un solo lote. Si las predicciones del borrador del modelo son correctas (es decir, el modelo más grande está de acuerdo), entonces se pueden decodificar varios tokens con un solo lote, lo que ahorra una cantidad considerable de tiempo y ancho de banda de memoria.
Sin embargo, si el modelo más grande rechaza los tokens predichos por el borrador del modelo, los lotes restantes se descartan y el algoritmo vuelve naturalmente a la decodificación estándar token por token. La decodificación especulativa también se puede combinar con un esquema de muestreo de rechazo para tomar muestras de la distribución original. Tenga en cuenta que esto solo es útil en entornos de lotes bajos donde el ancho de banda es el cuello de botella.
La decodificación especulativa cambia el costo computacional por ancho de banda. Hay dos razones clave por las que la decodificación especulativa se convierte en un atractivo objetivo de optimización del rendimiento. En primer lugar, no reduce la calidad del modelo. En segundo lugar, las mejoras de rendimiento que ofrece generalmente no están relacionadas con otros métodos, ya que su rendimiento proviene de convertir la ejecución secuencial en ejecución paralela.
Los métodos de inferencia actuales predicen una sola secuencia para lotes. Sin embargo, esto no se escala bien para tamaños de lote grandes o alineaciones de modelos de bajo calado. Intuitivamente, la probabilidad de que dos modelos coincidan en largas secuencias contiguas de fichas es exponencialmente baja, lo que implica que las ganancias en la decodificación especulativa disminuyen rápidamente a medida que aumenta la intensidad aritmética.
Creemos que si OpenAI usara decodificación especulativa, solo podrían aplicarla a secuencias de aproximadamente 4 tokens. También se especula que Bard usó la decodificación especulativa porque Google espera antes de enviar la secuencia completa al usuario, pero no creemos que esa especulación sea cierta.
Visual multimodal
Actualmente no hay ejemplos de comercialización de estudios en LLM multimodal. Utiliza un codificador visual independiente y un codificador textual, pero con atención cruzada entre los dos. Se dice que su arquitectura es similar a Flamingo, y se han agregado más parámetros sobre la base de GPT-4, con un volumen total de parámetros de 1.8T. Después del entrenamiento previo de solo texto, también se somete a unos 2 billones de ajustes.
Con respecto al modelo visual, OpenAI originalmente esperaba entrenar desde cero, pero debido a que la tecnología aún no está madura, optó por comenzar desde el texto para reducir el riesgo. Se dice que el próximo modelo, GPT-5, está entrenado completamente desde cero con la capacidad de generar imágenes y también procesar audio.
Una aplicación importante de esta capacidad de visión es para agentes autónomos capaces de leer páginas web y transcribir su contenido de imágenes y videos. Los datos en los que entrenaron incluyeron datos conjuntos (LaTeX/texto renderizado), capturas de pantalla de páginas web, muestras de marcos de videos de YouTube y ejecutaron tecnología Whisper en transcripciones.
En medio de toda la sobreoptimización de los LLM, un hecho interesante es que los modelos visuales tienen diferentes costos de entrada y salida que los modelos textuales. Como describimos en nuestro artículo "Crisis de la nube de Amazon", los modelos de texto son extremadamente baratos para cargar datos. Mientras que el costo de IO del modelo visual es unas 150 veces mayor, la cantidad de datos por marcador es de 600 bytes en lugar de los 4 bytes del modelo de texto. Se están realizando muchas investigaciones sobre la compresión de imágenes en este momento.
Esto es muy importante para los proveedores de hardware que optimizan su hardware durante los próximos 2 o 3 años para adaptarse al uso y la proporción de LLM. Pueden encontrarse en un mundo donde casi todos los modelos tienen fuertes capacidades visuales y de audio. Es posible que su arquitectura no se adapte bien a esta situación. En conclusión, es seguro que la arquitectura de los LLM se desarrollará más allá de los actuales modelos densos basados en texto simplificado y los modelos MoE.