- Mientras entrenaba modelos de lenguaje y multimodales a gran escala desde un estado limpio, Reka construyó infraestructura de entrenamiento desde cero, y el mayor cuello de botella no fue conseguir cómputo sino la variación en la calidad del clúster y la inestabilidad operativa.
- Incluso con las mismas GPU H100, según el proveedor y el clúster se acumulaban fallas de nodos, problemas de cableado, errores de GPU, cuellos de botella de I/O y del sistema de archivos, eliminación de checkpoints y retrasos de entrega, creando una situación parecida a una lotería de hardware.
- A diferencia de la experiencia con TPU e infraestructura interna de Google, en entornos externos de GPU las diferencias en entrenamiento multinodo, cableado y calidad del soporte hacían que el MFU y el tiempo de inactividad variaran mucho entre clústeres.
- Hubo que asumir múltiples clústeres, movimiento de grandes volúmenes de datos y limitaciones de codebases externas, y Reka migró a una base sobre PyTorch mientras construía por su cuenta monitoreo, checkpoints eficientes y un sistema de archivos personalizado.
- Debido al cómputo limitado, en lugar de un escalado sistemático al estilo Big Tech tuvieron que apoyarse en pocos experimentos cortos y contenidos, además de Yolo runs, y así lograron crear Reka Flash 21B y un modelo edge de 7B.
Construir infraestructura de entrenamiento desde cero
- Mientras entrenaba modelos de lenguaje multimodales potentes, Reka construyó nueva infraestructura necesaria para entrenar desde cero modelos de lenguaje y multimodales a gran escala.
- La dificultad principal no era elegir entre TPU o GPU, sino asegurar suficiente calidad operativa para mantener entrenamiento real funcionando de forma estable en infraestructura y entornos de código externos.
La lotería del hardware en la era de los LLM
- La primera condición para entrenar modelos es asegurar cómputo, pero en la práctica la mayor variable fue la diferencia entre proveedores, clústeres y la calidad de conexión de los aceleradores.
- Incluso con las mismas GPU H100, la calidad general del clúster variaba mucho, y aquí “hardware” se refería más a la calidad total del clúster que al chip en sí.
- Reka alquiló clústeres de cientos a miles de chips de varios proveedores de cómputo, y su estado iba desde niveles relativamente manejables hasta fallos cada pocas horas.
- Algunos clústeres sufrían fallas frecuentes de nodos por problemas de cableado o errores de hardware en la GPU.
- Incluso entre clústeres del mismo proveedor había grandes diferencias de robustez.
- Aunque los nodos fueran estables, si el I/O y el sistema de archivos eran malos, guardar checkpoints podía agotar el tiempo de espera o hacer caer de forma importante la utilización del clúster.
- Algunas fuentes de cómputo requerían capas de software completamente distintas para poder correr trabajos, lo que añadía costos de migración para equipos con codebase propia.
- Era difícil saber de antemano qué hardware tocaría, qué tan robusta sería la experiencia y cuánto toleraría fallas.
- Si un proveedor no entregaba a tiempo, podía provocar retrasos de meses, y a veces otros proveedores tampoco podían conseguir recursos durante semanas o meses.
- Algunos proveedores incluso borraron checkpoints por error.
Herramientas internas para MFU y respuesta ante fallas
- El Model Flop Utilisation (MFU) variaba entre clústeres, y encontrarse con nodos mal cableados o problemas del proveedor desperdiciaba una cantidad no menor de cómputo.
- En entornos con sistemas de archivos muy ineficientes, bastaba con que alguien iniciara una transferencia masiva de datos entre clústeres para que el MFU de un entrenamiento se desplomara.
- El nivel de soporte del proveedor también variaba mucho.
- Iba desde soporte amable hasta respuestas indiferentes.
- También hubo respuestas tipo “ChatGPT style” o intentos de culpar al usuario por todos los problemas.
- Cada clúster tenía sus propios dolores y modos de falla, y parecía que cada uno requería hotfixes separados.
- Para crear entornos utilizables, Reka construyó varias herramientas internas.
- Herramientas de monitoreo
- Checkpoints eficientes
- Varias optimizaciones
- Instalación de un sistema de archivos personalizado para almacenamiento de datos escalable
- Esta combinación de herramientas redujo el tiempo de inactividad y mejoró de forma significativa el MFU incluso sobre hardware deficiente.
Diferencias entre la experiencia con GPU y TPU
- Reka entrenó la mayoría de sus modelos con GPU.
- En comparación con la experiencia previa usando principalmente TPUs para entrenar modelos de lenguaje a gran escala en Google, CUDA y nccl eran un entorno poco familiar.
- La tasa de fallas de GPU fue muy distinta a la experiencia con TPUs en Google.
- El UL2 20B de Google siguió corriendo por error durante un mes sin fallar.
- Consideran que en un entorno de GPU habría fallado dentro de los primeros días.
- Sin embargo, esta diferencia podría estar más relacionada con la capacidad del equipo de hardware que administra los aceleradores y la calidad del soporte del proveedor que con el chip mismo.
- El entrenamiento multinodo en GPU no se sentía como un concepto de primera clase para entrenamiento distribuido al estilo de un TPU pod, sino como algo añadido después.
- Parecía que cada proveedor cableaba de manera distinta para habilitar entrenamiento multinodo, y esa diferencia aumentaba la variación entre ubicaciones.
La carga de operar múltiples clústeres
- La infraestructura interna de Google era un entorno accesible desde cualquier parte sobre Borg, Xmanager y Colossus.
- En entornos externos hubo que configurar manualmente nuevos ambientes en múltiples clústeres, algo muy distinto a la experiencia previa.
- A menos que uno mismo construya un gran pool de aceleradores en un solo lugar, parece inevitable terminar usando pools de aceleradores repartidos entre varios clústeres.
- La escasez de GPU hace que la adquisición termine naturalmente en forma de clústeres distribuidos.
- El entrenamiento de modelos grandes requiere decenas de TB de datos, así que mover los datos en sí mismo se vuelve una carga importante.
- A escalas muy grandes, replicar datos tampoco es simple y además cuesta caro.
- La forma ideal sería una capa de orquestación que envíe trabajos a varios servidores, pero para una startup ligera y nueva es difícil contar tan temprano con una infraestructura de entrenamiento de ML tan sofisticada.
- Reka mitigó el problema con varios workflows internos y sigue avanzando hacia una infraestructura de experimentación de nivel mundial.
- Según comentan, este tipo de configuración improvisada es bastante común fuera del grupo de élite o de las grandes corporaciones.
Codebases externas y la elección de PyTorch
- Sus codebases preferidas eran T5X y Mesh Tensorflow, pero en Reka no eran opciones realistas.
- Tienen poco soporte fuera de Google.
- Están en cierto grado de deprecación.
- No eran amigables para integrantes del equipo sin experiencia previa en Google.
- Reka eligió PyTorch por ser más vainilla, parecer más estable y estar más ampliamente usado.
- Al comienzo tuvieron que adaptarse a entornos de desarrollo externos como pip, git y docker.
- También es posible que usar codebases de Google fuera de Google de forma estable y amigable no hubiera sido fácil.
- Sintieron que la calidad de codebases externas estaba bastante por debajo de las codebases a las que estaban acostumbrados en Google.
- Consideran que muchas codebases internas de Google fueron escritas directamente por investigadores de ML como Noam Shazeer, Barret Zoph, Adam Roberts y Hyung Won Chung.
- Entre códigos hechos por otras empresas, algunos resultaron especialmente decepcionantes en calidad.
- En algunas codebases era necesario escribir convertidores aparte para cambiar la configuración de paralelización del modelo, y esos cambios no venían automatizados.
- También faltaba soporte para entrenamiento encoder-decoder a gran escala o para prefixLM.
- Según cuentan, flash attention seguía sin ofrecer soporte para entrenamiento prefixLM, es decir, máscaras personalizadas, aun cuando existía una demanda razonable en issues de GitHub.
- Existía la idea de que debían usar Jax, pero para moverse rápido en una startup eligieron PyTorch.
Cómputo limitado y Yolo runs
- El escalado sistemático de modelos normalmente ejecuta múltiples etapas de experimentación, por ejemplo 1B → 8B → 64B → 300B, avanzando desde modelos pequeños hacia grandes y eligiendo ganadores para seguir escalándolos.
- En una startup había mucho menos cómputo disponible para hacer grandes barridos de hiperparámetros.
- Reka dependió mucho de Yolo runs, y consideran que al final funcionó bien.
- Con solo una pequeña cantidad de experimentos de menor escala y ablaciones cortas lograron llegar a un sólido Reka Flash 21B, a un modelo edge de 7B y a su mayor modelo core previsto.
- Con un número limitado de ejecuciones es difícil encontrar una buena receta, y como el espacio de búsqueda es muy grande había que cambiar muchas variables a la vez.
- En vez de la sistematicidad estilo Big Tech, tuvieron que depender mucho más del Yolo, del instinto y de la intuición.
- La intuición acumulada por el equipo en carreras previas de ML ayudó a acertar con pocos intentos.
- Incluso si se tiene experiencia previa entrenando buenos modelos en trabajos anteriores, las diferencias en infraestructura de entrenamiento, datos, integración de ideas nuevas y problemas del entorno pueden generar diferencias nada pequeñas en los resultados.
- Una experiencia previa sólida redujo mucho el espacio de búsqueda y puede ser una de las explicaciones sencillas de por qué lograron entrenar modelos fuertes con pocos intentos, pocos recursos y pocos experimentos.
Resultados en menos de un año y desafíos pendientes
- La falta de cómputo y los proveedores de cómputo inestables crearon dificultades mucho mayores de lo esperado.
- Reka fundó la empresa, levantó capital, compró chips y construyó todo desde cero.
- En menos de un año, afirman haber alcanzado un nivel comparable a Gemini Pro/GPT-3.5 y superado a muchos modelos.
- Temas como el pipeline de datos y la evaluación humana siguen quedando para tratar más adelante.
1 comentarios
Comentarios de Hacker News
En este contexto, una startup termina pareciendo una organización con poca gente y mucho dinero para gastar en un clúster de entrenamiento.
El texto presupone que hay varios proveedores de renta de servidores, y que esos servidores van a distintas startups o empresas ya establecidas.
Al final, varios creadores de LLM entrenan texto e imágenes con hardware similar y datos similares, haciendo más o menos lo mismo, y cada uno intenta diferenciarse con su “salsa secreta”.
Esa salsa secreta puede marcar una diferencia en la calidad de salida de un LLM, pero en conjunto se ve como una enorme duplicación de trabajo que consume mucha energía.
Al final, solo un porcentaje muy pequeño logrará siquiera un éxito moderado, pero es el costo que se paga en la frontera del progreso.
Un monopolio planificado podría ser más eficiente, pero es raro que una estructura así le gane al mercado en innovación.
Parece que los fundadores esperan ser adquiridos solo porque pueden entrenar un LLM “casi de vanguardia”, y esa capacidad e infraestructura quizá valgan lo suficiente como para construir algo encima.
Claro que esa historia es mucho más difícil de explicarles a los inversionistas.
En realidad, sospecho que muchas startups están contratando escritores y fotógrafos para crear datos de entrenamiento no contaminados y muy bien etiquetados.
Si miras el lado de civitai, se ve hasta dónde se puede llegar con un presupuesto de cómputo pequeño solo con etiquetado muy detallado.
La mayoría de los casos de uso de LLM se pueden respaldar ajustando modelos base ya existentes.
Si entrenas un modelo base desde cero, estás entrando a un mercado difícil de monetizar, y basta con que un actor grande lance un nuevo modelo base para que pueda hacer más del 95% de lo que hace tu modelo.
Por contexto, Yi Tay fue tech lead de Google PaLM, UL2, Flan, Bard, etc., y ahora es cofundador de Reka.
Reka ha lanzado modelos multimodales pequeños e interesantes que también se han publicado por aquí.
Como alguien que viene de Google y ahora entrena LLM en una startup independiente, le pedí que escribiera este texto: https://twitter.com/YiTayML/status/1765105066263052718
La grabación de la conversación está aquí: https://sub.thursdai.news/p/thursdai-feb-15-2024-openai-chan...
Gracias a este texto conocí reka.ai, y parece que en HN todavía no se ha hablado mucho de los LLM de Reka [1].
Por curiosidad, durante la última hora probé prompts en su interfaz de chat [2] comparándolo con ChatGPT 4, Gemini Advanced, Claude 3 y Mistral Large, y publiqué los resultados en [3].
En general, Reka Flash no parece ser ni mucho peor ni mucho mejor que los otros modelos.
Por supuesto, para estar seguros harían falta muchas más pruebas.
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] https://chat.reka.ai/chat
[3] https://gally.net/temp/20240307llmcomparison.html
Vale la pena señalar que el autor simplemente asume que los lectores entienden “la naturaleza salvaje” como un lugar que no es Google.
El texto le da mucho crédito a los equipos de infraestructura y hardware de Google, y me gustaría leer también la perspectiva de alguien que estuvo ahí y luego hizo trabajo relacionado en otro lugar.
Más exactamente, se acerca a “durante toda mi carrera usé TPU de Google dentro de Google y estaba familiarizado con sus patrones de falla, pero no conocía en absoluto los patrones de falla de las GPU”.
Cuando venía de usar principalmente GPU y probé TPU, los trabajos seguían fallando por razones difíciles de depurar.
La capa de indirección entre los chips x86 y los dispositivos TPU muchas veces me hizo romperme la cabeza durante horas, de una forma que no me pasa con x86+NVIDIA+PyTorch.
Hace 10 o 15 años, Google produjo muchos científicos de datos valuados en más de 10 millones de dólares, es decir, ingenieros de Sawzall, y ellos también salieron a “la naturaleza salvaje” y tuvieron reacciones similares.
Más que dejar un registro útil para la comunidad, este texto parece tener más el objetivo de impulsar la empresa del autor y su marca personal.
En mi caso, creo que nunca he experimentado una falla de GPU ni siquiera en entrenamiento a gran escala.
Mi trabajo actual de entrenamiento por lotes usa un archivo JSON de 20 GB que tarda 6 horas solo en cargarse, lleva más de 15 días corriendo sin problemas y usa una Tesla T4 más vieja.
Las GPU tienen problemas de restricciones de memoria, pero si puedes planear y rodearlos, en la práctica nunca he visto un crash.
Me parece una metáfora bastante clara, y si eres una startup haciendo proyectos de infraestructura a gran escala, tienes que construir tu propia logística, como si montaras un campamento en plena naturaleza.
Se lee como una escena en la que Seven of Nine se separa del Collective y se da cuenta de que tiene que depender de las insignificantes capacidades humanas.
Las observaciones sobre proveedores fueron útiles.
Supongo que no se pierde todo el progreso del entrenamiento, así que ¿el sufrimiento está sobre todo en diagnosticar el problema y volver a levantar el clúster, y no hay que preocuparse por pérdida de datos?
Pero, ¿cuál es el producto que venden?
La página principal de Reka.AI parece un clon típico de ChatGPT donde se paga por token.
No sé qué lo diferencia de otras empresas, y el precio también parece similar al de ChatGPT 3.5-Turbo.
El problema de entrenar un LLM desde cero es un tema muy importante, que influye en la velocidad y amplitud de iteración en AI tanto como las mejoras del hardware bruto.
El artículo es interesante, pero algo superficial; si has trabajado durante años con clústeres de GPU de alguna forma, no resulta técnicamente profundo ni sorprendente.
La perspectiva de un ex Googler estuvo buena, pero no me queda claro por qué sus antiguos colegas recomendaban JAX por encima de PyTorch para hacer LLM fuera de Google.
Ojalá esta empresa nueva publique más adelante un informe más técnico sobre su recorrido de entrenamiento. Por ejemplo, algo como este PDF: https://github.com/facebookresearch/metaseq/tree/main/projec...
Probablemente también haya algo de sesgo de Google mezclado.
La gran pregunta es cómo una startup pequeña sin el historial y pedigrí correctos consigue financiamiento para un producto de LLM.
El mundo de las startups de LLM se está pareciendo al de los hedge funds y el private equity.
Los requisitos previos para una inversión semilla y para levantar capital parecen ser: A) una trayectoria prestigiosa y el pedigrí correcto, B) una red sólida de inversionistas lista para entrar incluso antes de que el producto haya empezado.
Probablemente esa sea también la razón por la que los VC invierten en estas empresas.
En todo el mundo hay muy pocas personas con la experiencia adecuada para levantar capital, y solo quienes pueden levantar capital pueden adquirir esa experiencia, así que se forma una barrera de entrada natural.
Al menos hasta que el costo de cómputo baje lo suficiente, parece que será así.
Al leer la parte de “fundamos una empresa, recaudamos dinero, compramos chips y en menos de un año construimos todo desde cero, igualando a Gemini Pro/GPT 3.5 y superando a muchos modelos”, me da curiosidad cuál habrá sido el presupuesto gastado en chips o GPU en la nube para llegar al nivel de un LLM como GPT 3.5.
¿Habrá sido, aunque sea en orden de magnitud, algo como 2 a 5 millones de dólares?
Me parece que el título debería ser “from the ground up” en vez de “ground zero”: https://en.wikipedia.org/wiki/Hypocenter
Como modismo, es un uso completamente aceptable.
Podría querer decir que los LLM son una bomba nuclear metafórica para la industria tecnológica, aunque sinceramente a mí también me confundió.
No me gustaría aprender de ese tipo de autor.
Los sistemas de Google son estables porque Google invirtió decenas de miles de millones de dólares durante 25 años en desarrollar hardware de data centers, software y procesos.
Incluso un equipo muy capaz en una organización más pequeña y menos madura inevitablemente producirá resultados de mucha menor calidad.
Otra cosa a considerar son las prioridades.
Google prioriza la estabilidad y retira los componentes que fallan repetidamente, incluso si las fallas son relativamente poco frecuentes.
Un data center más pequeño y menos sofisticado puede seguir usando componentes que fallan con frecuencia, o ni siquiera monitorear la tasa de fallas de ciertos componentes.
Los data centers pequeños también pueden comprar y usar componentes viejos de Google y piezas menos confiables.
Por lo tanto, que las máquinas sean inestables no dice nada necesariamente sobre la capacidad del equipo de hardware.
Si la baja estabilidad del hardware retrasa el trabajo, se puede mejorar el software para tolerar hardware inestable, o migrar a un proveedor de hardware más estable y más caro.