Configuración de infraestructura y scripts open source para entrenar un modelo de 70B en bare metal

 (imbue.com)
1 puntos por GN⁺ 2024-06-29 | 1 comentarios | Compartir por WhatsApp
  • Imbue entrenó desde cero un modelo de 70B parámetros con un equipo pequeño sobre su propia infraestructura bare metal y publicó los procedimientos operativos y scripts, desde la construcción del clúster hasta la recuperación ante fallas
  • El clúster estaba compuesto por 4,088 GPUs H100 y 511 servidores GPU, con 8 GPUs por servidor participando en entrenamiento sincrónico a gran escala a través de InfiniBand
  • La implementación real fue un proceso repetitivo de aprovisionamiento de máquinas individuales, puesta a punto del fabric InfiniBand, checks de salud de hosts, diagnóstico de errores de entrenamiento y mejoras de automatización, y hubo que manejar cerca de un 10% de fallas de arranque de máquinas y una gran cantidad de alertas de puertos
  • Las herramientas publicadas incluyen checks de salud de hosts, un parche de logging para NCCL, pruebas de estrés de GPU, pruebas de red NVLink e InfiniBand, un parser de logs de eventos de UFM y un script generador de cargas de burn-in para InfiniBand
  • En el entrenamiento de LLM a gran escala, un solo host o enlace inestable puede retrasar toda la ejecución, por lo que los checks automáticos de salud, aislamiento de fallas, reinicios y desactivación de puertos se vuelven claves para una operación sostenida

Construcción de un clúster para entrenar su propio modelo de 70B

  • Imbue entrenó durante varios meses un modelo de 70B parámetros desde cero en su propia infraestructura, y este modelo supera a zero-shot GPT-4o en tareas relacionadas con razonamiento
  • El alcance de lo publicado cubre un proceso de infraestructura end-to-end, desde el arranque inicial del clúster y la instalación del SO hasta la recuperación automática de errores durante el entrenamiento
  • Las herramientas de infraestructura publicadas junto con esto son las siguientes
    • Host-level health checks: scripts para verificar si un host puede entrar al entrenamiento sin errores conocidos
    • Parche de NCCL: mejora el registro para dejar más logs en situaciones de error y cuelgues
    • GPU stress test: valida que la GPU pueda asignar tensores grandes y ejecutar operaciones estándar
    • Networking tests: comprueba la comunicación NVLink entre GPUs de la misma máquina y la comunicación InfiniBand entre GPUs de distintas máquinas
    • UFM event log parser: parsea logs de eventos de Unified Fabric Manager para decidir qué puertos de red desactivar
    • InfiniBand burn-in workload generator: genera una carga de burn-in de InfiniBand que estresa todos los enlaces disponibles

Configuración del clúster y la red

  • El clúster principal distribuía 4,088 GPUs H100 en 511 servidores GPU, y cada servidor incluía 8 GPUs
  • La razón de usar 511 servidores GPU fue que algunas conexiones debían reservarse para nodos de Unified Fabric Manager (UFM) dedicados a la administración de la red InfiniBand
  • Cada GPU estaba conectada directamente a una tarjeta ConnectX-7, y podía enviar y recibir simultáneamente a 400Gbps con otras GPUs de la red InfiniBand a través de su propia tarjeta ConnectX-7
  • La topología InfiniBand tenía una estructura fully non-blocking, donde en teoría todas las GPUs podían comunicarse al mismo tiempo con otras GPUs a velocidad máxima
    • Una arquitectura de switches InfiniBand de 3 niveles proporcionaba el throughput total de la red
    • La comunicación de entrenamiento se realizaba sobre InfiniBand, no sobre Ethernet
  • Ethernet se usaba para datasets, checkpoints y otras transferencias de datos
    • Si la comunicación de entrenamiento se enviaba por Ethernet, debía pasar de la GPU al CPU y luego salir por una tarjeta Ethernet de 100Gbps, por lo que era mucho más lenta
    • También es posible entrenar sobre Ethernet con RoCE, pero requiere mucho trabajo adicional tanto en hardware como en software y, en general, es menos confiable que InfiniBand
  • Una red Ethernet de administración separada se usaba para acceder al BIOS, a la fuente de poder y a controladores de interfaz de máquina de bajo nivel
    • Sin esta red de administración, habría sido necesario configurar manualmente cientos de máquinas con memorias USB, teclado y monitor
  • En entrenamiento de alto rendimiento a gran escala, InfiniBand, Ethernet, GPUs y nodos deben funcionar casi a la perfección
    • Si solo una de más de 12,000 conexiones es inestable, toda la ejecución de entrenamiento puede volverse más lenta

Aprovisionamiento de máquinas individuales

  • Después de crear una conexión Ethernet al clúster con la red de administración inicial, obtuvieron credenciales de acceso al BMC (Baseboard Management Controller)
    • El BMC es un procesador de servicio para monitorear hosts de forma remota
    • Proporciona estado de hardware, configuración de BIOS y APIs de administración de energía
  • En el primer servidor instalaron manualmente Ubuntu 22.04 con iDRAC, el BMC de Dell
    • Permitía montar una imagen ISO desde una computadora local para arrancar y ofrecía una consola virtual basada en navegador
    • El objetivo era que esta instalación manual fuera la única de todo el proceso

  • MAAS y arranque PXE

    • Después de preparar la primera máquina, instalaron Ubuntu MAAS (Metal-as-a-Service) para aprovisionar el resto de los servidores
    • Con arranque PXE y herramientas automatizadas de iDRAC, indicaron a cada máquina que arrancara desde la red
    • Los servidores recibían una IP desde MAAS por DHCP, descargaban un kernel inicial y realizaban automáticamente la instalación persistente del SO aunque el disco local estuviera vacío
    • En la práctica, como la integración entre MAAS y BMC no era estable, recopilaron por adelantado las direcciones MAC de todas las máquinas usando la API de iDRAC
    • MAAS fue en general confiable durante todo el entrenamiento, pero al principio hubo problemas específicos de configuración
      • Las diferencias grandes de reloj provocaban fallas en la validación de certificados HTTPS y bloqueaban instalaciones con apt
      • El servidor MAAS asumía a la vez las funciones de DHCP, DNS, proxy HTTP, NTP, gestión de configuración de cloud-init y base de datos fuente de verdad para MAC, IP, hostname y metadatos, lo que dificultaba rastrear la causa raíz

  • Fallas de arranque y observabilidad básica

    • Como suele pasar en la configuración de clústeres GPU a gran escala, cerca de 10% de las máquinas falló al arrancar, y la causa principal fueron problemas físicos del servidor
      • Cable Ethernet desconectado o mal cableado
      • Problemas de hardware de iDRAC
      • Fallas en la fuente de poder
      • Unidades NVMe defectuosas
      • Cableado interno faltante
      • Tarjetas de red o GPUs no detectadas
    • Imbue automatizó las verificaciones para estos problemas, envió algunas máquinas a reinspección con Dell y abrió los tickets necesarios con el personal del datacenter
    • Como hicieron la configuración de infraestructura por cuenta propia, pudieron usar de inmediato las máquinas sanas mientras esperaban reparaciones
    • En todos los servidores instalaron Docker, el driver de GPU para datacenter, Prometheus node exporter, NVIDIA DCGM exporter y un pool RAIDZ de ZFS sobre todos los discos fuera del SO
    • ZFS permitió mantener la máquina operativa incluso si fallaba un disco, y con compresión transparente redujo mucho el espacio usado por datasets de texto plano y logs repetitivos
    • Al instalar paquetes de software en paralelo sobre 400 nodos, apareció un cuello de botella de ancho de banda
    • También surgieron por primera vez alertas de alta temperatura en varios componentes del despliegue del datacenter, y la mayoría de los problemas térmicos iniciales se mitigó con actualizaciones de firmware

  • Verificación de entrenamiento GPU en un solo nodo

    • Verificaron que cada máquina pudiera manejar de forma independiente cargas de trabajo reales de GPU
    • Varias máquinas fallaron en el entrenamiento GPU de un solo nodo por los siguientes problemas
      • La mayoría de los errores relacionados con GPU se resolvió volviendo a asentar las tarjetas en sus slots
      • En los logs del servidor Ubuntu, las conexiones PCIe aparecían como limited width: x4 < x16
      • Incluso después de actualizar el firmware del bus del switch PCIe, en cerca de una cuarta parte de los hosts del clúster hubo que volver a asentar cables PCIe internos
      • Había unidades NVMe que no aparecían como defectuosas, pero bloqueaban toda la máquina al acceder a ellas
      • Linux mostraba el orden de los discos de forma aleatoria, por lo que MAAS instalaba el SO en la unidad equivocada
      • Lecturas incorrectas de temperatura hacían que los ventiladores giraran siempre al 100%
      • El escalado dinámico de frecuencia del CPU limitaba los núcleos activos a 2GHz
      • Falló la aplicación de GDR, es decir, GPUDirect RDMA Peer Memory Client

Aprovisionamiento de InfiniBand

  • InfiniBand tenía una sola entidad de control para toda la red gracias a su diseño centralizado, y permitía tratar 320 switches de red como una sola fabric
  • La primera tarea fue identificar qué switch estaba conectado a qué máquina y, comparándolo con el diagrama de cableado, renombrar los switches según su ubicación física

  • Diseño incorrecto de la fabric y recableado

    • Al principio, UFM no podía detectar los 320 switches de red ni encontrar los hosts que debían estar en la fabric
    • Tras verificarlo con el socio del centro de datos, los switches estaban encendidos y cableados, pero no se detectaban
    • Al revisar la lista de cableado de red, se descubrió que la fabric superior no estaba compuesta por una sola fabric unificada, sino por 8 redes separadas sin una ruta de enrutamiento común
    • Después del recableado, se añadió una verificación para confirmar que todas las conexiones físicas coincidieran con el nuevo diseño

  • Alertas de temperatura y errores de puerto

    • Después de resolver los problemas de cableado físico, UFM se conectó a todos los switches InfiniBand, pero casi todos los puertos de los switches reportaban temperaturas excesivamente altas
    • Incluso antes de la transferencia real de datos, algunos puertos superaban los 70 grados Celsius; la causa era una estructura en la que el aire caliente recirculaba hacia el frente a través del espacio vacío entre switches en el rack de red
    • Muchos puertos mostraban altas tasas de error o link flapping, alternando entre estado normal y fallido, y este problema solo aparecía cuando el puerto realmente se usaba, por lo que era difícil detectarlo de antemano
    • Toda la fabric tenía 10,000 enlaces y una alta redundancia, pero cuando cerca del 10% de la fabric mostraba problemas, incluso funciones como adaptive routing no podían evitar suficientemente los enlaces que se cortaban de forma irregular
    • El socio del centro de datos limpió y reinstaló los puertos con alertas, y desactivó los transceptores restantes con alertas mientras esperaban reemplazo
    • Durante este período, se realizaron entrenamientos multinodo con 100 a 200 máquinas para encontrar un subconjunto estable de InfiniBand

  • Burn-in de InfiniBand y GPUDirect RDMA

    • Para diagnosticar los problemas de InfiniBand con más eficiencia, se creó una carga de trabajo especial que empujaba simultáneamente la mayor cantidad posible de datos a todos los puertos de toda la fabric
    • Esto era distinto de ejecutar un solo all-reduce grande en todo el clúster
      • porque NCCL optimiza la comunicación dentro de un solo nodo mediante NVLink y la ruta de sockets SXM
    • UFM envió alertas de transferencia de datos de más del 97% de la capacidad teórica en la mayoría de los puertos, y algunos switches se cayeron temporalmente
    • Los puertos que seguían activos al final del día se consideraron suficientemente robustos, y el resto se desactivó o se dejó para reparación posterior
    • Se habilitó GPUDirect RDMA para que las GPU se comunicaran sin sobrecarga de CPU

  • Conjunto de máquinas estables y mantenimiento

    • Como regla práctica en clústeres de GPU con hardware reciente, hay que asumir que alrededor del 3% de las máquinas falla cada semana
    • No es que todas las máquinas fallen con una probabilidad uniforme del 3%, sino que algunas máquinas problemáticas fallan repetidamente de varias maneras
    • Si hay muchas máquinas en la misma fabric, en lugar de perseguir continuamente problemas aleatorios de máquinas se puede ampliar un conjunto de máquinas golden conocidas por ser estables
    • El mantenimiento de InfiniBand consistía principalmente en responder a alertas de UFM, reemplazar cables y transceptores, y diagnosticar switches defectuosos
    • Las regresiones a gran escala solían originarse por dos factores
      • Una actualización de firmware aplicada solo a la mitad del clúster corrompió el estado de UFM y obligó a reiniciar UFM en todos los switches InfiniBand
      • Reiniciar en masa muchas GPU boxes al mismo tiempo saturaba las actualizaciones de estado de UFM y obligaba a reiniciar el servicio de UFM

Sistema de health checks del host

  • Imbue encontró varias fallas de una sola máquina que hacían fallar o ralentizaban la ejecución del entrenamiento, y escribió health checks para determinar si un host estaba lo suficientemente sano para entrenar
  • El código está publicado en cluster-health
  • Muchos checks están especializados para el entorno de runtime de Imbue, pero el objetivo era devolver un sí/no desde un solo punto de entrada sobre el estado de preparación para entrenamiento

  • Health checks rápidos

    • GPU Health Check: verifica la cantidad de GPU, activación de ECC, errores ECC, topología de NVLink y errores
    • Disk Space Health Check: verifica que el uso de disco del host no supere el 95%
    • Docker Health Check: verifica la ejecución de contenedores conectados a GPU y los permisos de contenedores de monitoreo y profiling
    • Dmesg Health Check: busca errores Xid y SXid de GPU o switches NVIDIA, y verifica si las líneas del log de dmesg pueden clasificarse dentro de una lista de logs esperables
    • iDRAC Health Check: revisa errores de iDRAC en máquinas Dell e ignora mensajes de error no críticos
      • Este check no está incluido en la publicación open source
    • Disk Health Check: verifica el montaje de zpool, la conexión de Docker y si la CPU se congela al acceder al disco
    • InfiniBand Health Check: verifica aumentos en la tasa de error de InfiniBand y firmware antiguo del driver
    • Nvlink Health Check: verifica errores de NVLink en la máquina
      • Empíricamente no causaban fallas de entrenamiento, pero podían ralentizarlo
    • GDR Health Check: verifica si GDR está habilitado en la máquina
    • VBIOS Health Check: verifica si la versión de VBIOS de la GPU y el firmware de la baseboard H100 están actualizados
    • Flint Health Check: usa flint y hca_self_test para verificar la versión del driver Mellanox OFED, el firmware de la tarjeta, el firmware del transceptor y el estado de compilación del driver NVIDIA
    • PSB Health Check: consulta dispositivos PCIe para verificar si la velocidad y el ancho de conexión entre GPU, PSB y tarjeta de red coinciden con lo esperado
      • Como es un script desarrollado por Dell, por ahora no se puede compartir

  • Health checks más largos

    • Inicializa cálculos matriciales con PyTorch para medir el ancho de banda de NVLink, la velocidad de cómputo de la GPU y la memoria
    • Configura el flag de GDR para probar tanto InfiniBand como NVLink
    • Usa ib_write_bw y --use_cuda para enviar datos a la tarjeta IB y medir el ancho de banda de PCIe y de la tarjeta InfiniBand
    • Se ejecuta durante unos 15 minutos para detectar enlaces InfiniBand con flapping
    • Ejecuta diagnósticos multinodo para verificar si NCCL puede inicializarse y si hay bloqueos aleatorios
      • Si se bloquea, el código bifurcado de NCCL deja logs adicionales
    • Como la detección de problemas puede tomar de 12 a 24 horas, se ejecuta principalmente en nodos nuevos o en situaciones sospechosas
    • Revisa eventos de throttling de clock de GPU en DCGM exports, excluyendo gpu_idle y power_cap, que son esperables
    • Un entrenamiento multinodo que usa al mismo tiempo todas las GPU, tarjetas InfiniBand, CPU y discos es el que mejor revela eventos de energía

Diagnóstico de errores comunes durante el entrenamiento

  • Crash justo después de iniciar

    • Los crashes justo después de iniciar eran los errores más fáciles de manejar, porque resultaba relativamente sencillo reproducirlos y repetirlos.
    • Primero se verificaba que la versión del código, la configuración y las variables de entorno fueran correctas.
    • Las abstracciones intermedias, como el caché de imágenes de Docker o configuraciones opacas de secrets, podían dificultar identificar la causa.
    • También se confirmaba que todas las máquinas estuvieran en línea y que fuera fácil agregar e inspeccionar stack traces y logs.
      • Imbue usa la pila de Loki, Prometheus y Grafana.
    • En ejecuciones distribuidas sincrónicas, a menudo el primer error provocaba errores en cadena no relacionados.
    • Al crear un sistema de reinicio automático, se volvió aún más importante agregar logs y errores para que no se mezclaran entre reinicios distintos.
    • Los errores vistos con frecuencia fueron los siguientes:
      • Forward order differs across ranks...: por una característica de la implementación de PyTorch FSDP, podía resolverse reintentando la ejecución.
      • CUDA out of memory...: se resolvía revisando la configuración y el código, y revirtiendo cambios recientes en el código.
      • CPU/RAM OOM: convenía detectarlo a partir de la invocación del OOM Killer en los logs de dmesg del host, fuera del contenedor.

  • Crash a mitad del entrenamiento

    • Una vez que el hardware empezaba a operar, lo prioritario era volver a ejecutar todas las verificaciones de salud de diagnóstico y contar con un sistema que reiniciara automáticamente excluyendo los hosts no saludables.
    • Errores aleatorios de hardware como Xid y SXid podían hacer crashear una ejecución sin un stack trace útil de Python.
    • Algunos casos, como row remapping, podían recuperarse con un reinicio, pero los errores ECC no corregibles por lo general requerían mantenimiento de hardware o reemplazo de componentes.
    • Datos de entrenamiento con formato especialmente malo también provocaban crashes.
      • Un único documento muy grande dentro del corpus podía causar OOM en GPU o CPU.
      • Se usaba un data loader totalmente determinista para vincular fácilmente el crash con el número de epoch o step.
      • Para verificar si los datos eran la causa, se desactivaba la carga de datos o se la reemplazaba por datos falsos compuestos solo de ceros.
    • Cortes momentáneos de Ethernet o falta de espacio en disco podían no aparecer con mensajes de error útiles, por lo que se registraban métricas de red y del estado de los nodos para comprobar correlaciones.

  • Bloqueo sin stack trace

    • Los errores que se quedaban colgados o agotaban el tiempo sin stack trace eran especialmente difíciles de depurar, porque había poca información y era complicado reproducirlos de forma confiable.
    • Un mensaje representativo era de la forma Watchdog caught collective operation timeout....
    • Si uno o más hosts no lograban completar una operación de NCCL o se desconectaban de una conexión NCCL o InfiniBand, todos los demás hosts quedaban bloqueados de forma sincrónica en esa operación de tensor hasta NCCL_TIMEOUT.
    • Por la naturaleza de la biblioteca NCCL, era difícil encontrar qué host era el causante.
    • Imbue añadió cambios de logging a un fork de NCCL para hacer más visibles los mensajes u operaciones in-flight al momento del crash e identificar el host o GPU problemático.
    • A menudo, para encontrar el host que estaba fallando, había que revisar qué host no generó un mensaje de log específico.
    • Se depuraban procesos detenidos en tiempo real con Py-Spy y GDB para distinguir entre bloqueos de NCCL, bloqueos del driver y race conditions o deadlocks en código Python.

Caídas de velocidad de entrenamiento vistas con MFU

  • Una caída general de velocidad o un MFU (Model FLOPs Utilization) inferior a los niveles observados previamente puede deberse a varias causas.
  • Primero ayuda volver a revisar la configuración, el código y las variables de entorno.
    • modelo incorrecto
    • tamaño de batch incorrecto
    • configuración incorrecta de UFM o NCCL
    • CUDA_DEVICE_MAX_CONNECTIONS incorrecto
  • Para diagnosticar el tipo de problema, resultó más útil medir el MFU inmediato por batch que un promedio suavizado.

  • Causas según el patrón de MFU

    • Si se mantenía estable en menos de 1/10 del MFU esperado justo después de iniciar el entrenamiento, normalmente se trataba de un problema de hardware InfiniBand, como un switch muerto en la capa T2 o T3.
      • Los problemas de hardware entre la GPU y la NIC también podían ser la causa, y aparecían en dmesg como PCIe x16 lanes limited by ....
    • Si se mantenía estable en 30% del MFU esperado justo después de iniciar, es posible que la configuración GDR o las variables de entorno GDR de un host fueran incorrectas.
    • Si se mantenía estable en 60~80% del MFU esperado justo después de iniciar, normalmente la causa era un enlace InfiniBand degradado o defectuoso.
      • Si la NIC InfiniBand conectada a una GPU específica estaba defectuosa, NCCL intentaba usar la NIC de otra GPU del mismo host pasando por NVLink local.
      • El throttling de CPU también podía ser la causa, por lo que era necesario ajustar la configuración del BIOS de un host específico.
    • Si ocurría una caída de 10x de forma regular en un solo batch, casi siempre estaba relacionada con checkpointing o evaluación, y podía confirmarse cotejándola con la cuenta de epochs o steps.
      • Configurar alertas automáticas solo a partir de anomalías de MFU aumentaba mucho los false positives.
    • Si una caída de 10x en un solo batch ocurría rara vez y de forma aleatoria, y se recuperaba de inmediato, a menudo se debía a que se había programado una carga de trabajo intensiva en CPU en uno de los hosts en ejecución.
      • También podían ser la causa problemas intermitentes de red o cuellos de botella en el data loader.
    • Si la gráfica de MFU descendía gradualmente a medida que avanzaba la ejecución y volvía a 100% al reiniciar, se verificó con perfiles de Python y NVIDIA que la causa era la recolección automática de basura.
      • Al desactivar la recolección automática de basura y ejecutar garbage collection a intervalos específicos en todos los hosts, desapareció la caída de throughput.
    • Si el rendimiento era bueno al principio pero después caía con frecuencia a 70% de lo esperado, había correlación con NVIDIA GPU clock throttle reasons.
      • Las causas eran temperatura de la GPU, falla o degradación de los ventiladores de enfriamiento del host y fallas en la fuente de poder.
    • Si el rendimiento era bueno pero había mucho ruido de alta frecuencia entre 90~100% del MFU esperado, normalmente se trataba de un problema de hardware InfiniBand, como una degradación moderada en capas superiores de la red o un enlace inestable.

  • Preguntas para revisar regresiones de throughput

    • Verificar si antes había funcionado correctamente.
    • Verificar si hubo cambios recientes, como merges de código o actualizaciones de drivers.
    • Verificar si se está ejecutando en hosts saludables y si servicios dependientes como Docker Hub o GitHub están funcionando.
    • Verificar si se ejecutó con el mismo código, entorno, configuración, versiones, lista de hosts, orden de ranks y random seed que la ejecución anterior que funcionó bien.
    • Verificar si es reproducible.
    • Verificar si hay correlación con otros procesos, crontabs diarios o métricas del host, DCGM y UFM.
    • Verificar si la herramienta de medición de métricas es correcta.
    • Verificar si el problema también ocurre en código reducido, como con un modelo más pequeño, datos falsos o quitando el guardado y carga de checkpoints.

Herramientas de automatización y mejoras operativas

  • Aunque el entrenamiento pudiera comenzar con buen rendimiento, al final algo terminaba fallando, así que necesitaban herramientas y sistemas que minimizaran la intervención humana
  • Como Imbue es un equipo pequeño, no tenía suficiente personal para seguir haciendo reparaciones manuales, así que automatizó tantos procesos como fue posible
  • La mayoría de los problemas en las ejecuciones de entrenamiento se redujeron a máquinas defectuosas o componentes de red

  • Exclusión automática de máquinas defectuosas

    • Desarrollaron un sistema que reinicia automáticamente las ejecuciones que fallan desde el checkpoint más reciente
    • El proceso de reinicio ejecuta health checks en todas las máquinas disponibles y clasifica el estado de salud de cada máquina según los checks que haya pasado
    • Después, vuelve a ejecutar el trabajo de entrenamiento en las máquinas más saludables

  • Respuesta automática a componentes de red

    • Todos los fallos observados en componentes de red fueron detectados por UFM y registrados en el log de eventos de UFM
    • En la práctica, solo algunos eventos de entre decenas eran realmente problemáticos, y la mayoría estaban relacionados con links caídos o un conteo alto de symbol error
    • Los scripts analizan el log de eventos de UFM, deshabilitan links y puertos asociados con eventos recientes, crean tickets de mantenimiento y los vuelven a habilitar una vez completada la reparación

  • Espejo de sistema de archivos local

    • La velocidad de Ethernet dentro y fuera del clúster podía convertirse en un cuello de botella para el entrenamiento distribuido a gran escala
    • Una conexión Ethernet compartida de alrededor de 10 Gbit/s se saturaba rápidamente cuando cientos de workers descargaban al mismo tiempo datasets y checkpoints del modelo
    • Imbue construyó dentro del clúster un sistema de archivos local que refleja el almacenamiento en la nube para reducir la cantidad de archivos que debían obtenerse desde S3
    • Para lidiar con el churn de máquinas que se desactivaban o reemplazaban con frecuencia, replicaron cada archivo por triplicado
    • Usaron consistent hashing para distribuir la carga de manera uniforme y minimizar el movimiento de archivos durante el churn
    • Debido al espacio limitado en disco, también desarrollaron herramientas para rastrear el ciclo de vida de los archivos y eliminar los innecesarios

  • Docker registry distribuido local

    • Para transferir imágenes de Docker usaron Kraken
    • Kraken es software open source que permite transferir imágenes de Docker de forma peer-to-peer, y según Imbue casi no les dio problemas

  • Monitoreo de rendimiento e identificación de hosts defectuosos

    • Configuraron Torch profiler y NVIDIA Nsight Systems
    • Nsight Systems fue útil para entender cuánto tiempo tomaban el forward/backward pass y la comunicación de NCCL
    • Ayudó a determinar, según el tamaño del modelo y la cantidad de workers, si el cuello de botella era de comunicación o de cómputo
    • Fue algo difícil de usar porque requería Docker privileged mode, desactivar checks de seguridad relacionados con eventos de monitoreo de rendimiento y pausar el entrenamiento para guardar perfiles
    • También escribieron herramientas para detectar batches de entrenamiento lentos e identificar la causa
      • La herramienta más útil monitoreaba el tiempo de cada batch y, cuando un batch era anormalmente lento, volcaba los stack traces de todos los workers
      • Esto facilitó identificar hosts específicos con problemas sutiles de hardware o software
    • Antes de que los health checks maduraran lo suficiente, si el entrenamiento fallaba en un conjunto específico de máquinas no estaba claro cuál de ellas era la causante
      • Por ejemplo, si un grupo de 48 máquinas fallaba, lanzaban ejecuciones más pequeñas en 6 grupos de 8 máquinas y en 8 grupos de 6 máquinas
      • Las máquinas que aparecían en grupos fallidos en ambas etapas se consideraban, con alta confianza, como las problemáticas

Principios operativos obtenidos durante la implementación

  • Si se aseguran 10–20% más máquinas de las que requiere una ejecución de entrenamiento específica, es más fácil volver a ejecutar cuando una máquina falla
  • Si la red del clúster se configura para que todas las máquinas estén conectadas de forma cercana entre sí, se puede usar cualquier subconjunto funcional
  • Como los fallos de hardware y software encontrados durante el entrenamiento vuelven a ocurrir, vale la pena escribir pruebas y soluciones automatizadas para cada tipo de falla
  • Para cada mensaje de error opaco, resulta útil crear herramientas que lo hagan más interpretable
  • Para mantener la reproducibilidad, adoptaron la regla de cambiar incluso las modificaciones más simples de una en una
  • Al introducir herramientas externas o cuando una persona nueva entra al proceso, vuelven a validar las afirmaciones, especialmente si pasos posteriores dependen de esos resultados
  • Todo el proceso requirió mucha supervisión e iteración, pero fue decisivo tener control total de la infraestructura y poder depurar problemas en todas las capas de abstracción

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-06-29
Comentarios de Hacker News
  • Durante varios meses, con un pequeño equipo de investigación e ingeniería, entrenaron desde cero en su propia infraestructura un modelo de 70 mil millones de parámetros, y superó a GPT-4o zero-shot en tareas relacionadas con razonamiento.
    Para usar su propio clúster en entrenamiento de alto rendimiento, todos los componentes —InfiniBand, Ethernet, GPU y nodos— tenían que funcionar perfectamente, y que una sola de más de 12,000 conexiones fuera inestable podía ralentizar todo el entrenamiento.
    Publicaron scripts open source y una guía de punta a punta para configurar la infraestructura, y esto es una de las tres partes del toolkit para entrenar un modelo de 70 mil millones. Las herramientas de evaluación y optimización de hiperparámetros, CARBS, se pueden ver aquí: https://imbue.com/research/70b-intro/
    • El nivel de detalle fue realmente bueno, y es la primera vez que veo un artículo que muestra con tanto detalle interno el trabajo de ingeniería detrás de un modelo así.
      Tengo dos dudas. Primero, me pregunto qué cambiaría si entrenaran un modelo de 400 mil millones de parámetros. En el clúster completo parece haber suficiente memoria de video, pero me interesa saber cuál sería la evaluación real.
      Segundo, me pregunto si ven esta arquitectura como la forma final del entrenamiento de modelos. Parece demasiado frágil; quisiera saber si existen mejores mecanismos o arquitecturas de entrenamiento compartido, o una mejor estructura de clúster.
    • Me pregunto qué pasó con el mundo 3D parecido a Minecraft que estaba creando el equipo. ¿Cambiaron de rumbo?
    • Es interesante lo de “superó a GPT-4o zero-shot”. Me pregunto si este modelo llegó hasta RLHF, o si solo fue preentrenamiento.
      Si fue lo segundo, quisiera saber cómo le ganó a GPT-4.
    • La frase de que una sola de más de 12,000 conexiones fuera inestable podía ralentizar todo el entrenamiento me pareció bastante peculiar, como si ya la hubiera visto antes.
      De hecho, esta frase y gran parte del artículo parecen haber sido publicados casi palabra por palabra en Twitter, LinkedIn y Reddit. ¿Es simplemente spam?
      https://x.com/imbue_ai/status/1805629547473518695
      https://reddit.com/r/learnmachinelearning/comments/1dobgbs/t...
      https://www.linkedin.com/posts/mattboulos_training-a-70b-mod...
  • Si dicen “511 computadoras con 4,092 GPU H100, 8 por computadora”, ¿entiendo bien que solo las GPU cuestan más de 100 millones de dólares?
    Me pregunto qué parte de esto, y más o menos cuándo, podría entrar en el ámbito de un desarrollador aficionado con presupuesto de PC gamer.
    • Es interesante que gasten 100 millones de dólares en GPU y aun así estén trasteando con cajas Dell con puertos Ethernet defectuosos.
      Los problemas que tuvieron suenan entretenidos.
    • Parece correcto. Levantaron 200 millones de dólares de NVIDIA, así que probablemente haya sido básicamente en forma de GPU: https://news.crunchbase.com/ai-robotics/new-ai-unicorn-imbue...
    • Si solo las GPU cuestan más de 100 millones de dólares, la mayoría de los lectores que no tienen financiamiento a esa escala probablemente deberían pasar al siguiente post de HN.
  • Realmente genial. Cisco colaboró recientemente con NVIDIA y sacó equipos que ofrecen 800G por puerto, aunque no recuerdo si era RoCE.
    Aquí parece que las GPU tienen una estructura con acceso a InfiniBand, y es hermoso. Es uno de esos artículos directamente útiles.
  • Hace unos días también hablaron de esto en el podcast Latent Space: https://www.latent.space/p/llm-training-2024
    Fue un buen episodio, y vale la pena para escuchar las razones detrás de este tipo de decisiones.
    • No estoy acostumbrado a estas entrevistas, así que sentí que estaba fuera de mi zona de competencia. Si hay preguntas que debería haber hecho y se me pasaron, agradecería sugerencias.
  • Me da curiosidad el consumo total de energía necesario para crear el modelo. Quisiera saber si hay cifras incluyendo electricidad y enfriamiento.
    Zuckerberg dijo en un podcast que están planeando el próximo modelo de 1 GW, lo que en la práctica significa un centro de datos con una planta eléctrica mediana adjunta, así que me da aún más curiosidad.
  • Es un artículo realmente valioso y aprendí mucho al leerlo. El código open source que publicaron también es excelente.
    Tengo varias preguntas. Me pregunto por qué armaron su propio clúster y cómo fue la experiencia con un socio cloud al lidiar con equipos o switches defectuosos.
    También quisiera saber, además de la comunicación all-to-all, qué priorizaron al elegir la arquitectura del clúster y qué resultó ser lo más valioso en la práctica; cómo era la infraestructura de logging más allá de estar basada en Loki; por qué necesitaban un registro Docker local; y si usaron otras imágenes además de nvidia-container-runtime.
  • Pregunta sincera: ¿por qué hay tanto hardware de PC mezclado aquí?
    Me pregunto si no podrían conectar las GPU a un backend PCI e InfiniBand, dejar solo un controlador de coordinación ARM muy pequeño y hacer que se coordinen entre sí. No sé si es inercia de diseños anteriores o si falta mercado para controladores GPU especializados.
    • Si lo que preguntas es por qué pagar extra por CPU y RAM, no todo puede hacerse en la GPU. Por ejemplo, está la descompresión de .png.
      Si analizaras muy a fondo el código de entrenamiento y preprocesaras mucho los datos, quizá podrías arreglártelas con recursos de CPU/RAM muy ligeros, pero como las GPU son caras, CPU/RAM representan una parte pequeña del costo total del sistema, así que no necesariamente vale la pena dedicar tiempo de desarrollo a optimizar hasta ese punto.

Un proveedor de nube de hiperescala probablemente buscaría incluso ese 0.x% de eficiencia en costos. Por ejemplo, podría querer preprocesar .png a .webp (sin pérdida y multihilo) o .jpeg (con pérdida), pero cambiarlo a un formato que la GPU pueda descomprimir quizá reduzca el costo de CPU durante el entrenamiento, aunque probablemente no convenga porque aumentaría los costos de almacenamiento y transferencia
Más precisamente, si el trabajo de CPU es el cuello de botella del entrenamiento, hay que optimizarlo al máximo con preprocesamiento de datos y ajustes en los scripts de entrenamiento. Aquí se habla de la brecha entre “suficientemente rápido” y “más rápido”: la CPU no es lo bastante rápida para el entrenamiento < la CPU es apenas lo suficientemente rápida para el entrenamiento < la CPU es más rápida de lo necesario para el entrenamiento

  • Si cada máquina lleva 250 mil dólares en GPU, es tonto preocuparse por ahorrar unos miles de dólares en hardware de control. El riesgo de usar una nueva configuración de hardware es demasiado alto
    Otro problema es que todo el hardware relacionado con GPU, los drivers y la experiencia operativa están del lado de las PC. Para correrlo en ARM habría que empezar casi desde cero, y también se necesitaría mucho trabajo adicional para estabilizarlo. Al final, se paga un costo grande por ahorrar un poco en el procesador
  • Mantener las GPU alimentadas con datos constantemente es una tarea bastante complicada en el entrenamiento de deep learning
    No tengo experiencia con LLM/NLP, pero en cargas de trabajo de imagen y audio a veces es difícil aprovechar por completo incluso GPU RTX 2/3/4xxx con una CPU común de 4 a 8 núcleos. No es tan difícil que la CPU o la E/S se conviertan en el cuello de botella
  • 4,092 GPU H100 es una escala grande
    Dicen que están haciendo “self-coding”; me pregunto si eso se acerca más a soluciones no-code o low-code
    En su sitio web también hay bastantes artículos que podrían resultar interesantes: https://imbue.com/our-work/
  • Me pregunto cuánto habrá costado. Desde partir de la nada hasta llegar a un archivo de modelo usable, ¿cuánto habrá sido sumando costos de hardware, tiempo de desarrollo, electricidad y refrigeración?
  • Me pregunto si muchos desarrolladores aficionados podrían entrenar un modelo juntos de forma distribuida, como seti@home o folding@home
    Esos proyectos tenían la característica de poder dividir el trabajo en paquetes bastante independientes, pero no sé si el entrenamiento de modelos también se puede dividir así
    • Es muy probable que no funcione bien. Entre desarrolladores aficionados, casi nadie —o directamente nadie— podría asegurar 400 Gbps de throughput de red entre sus GPU