Cómo Ai2 arregló la gestión de colas en miles de GPU H100 y B200
Ai2 gestiona miles de GPU H100 y B200. Tras sufrir saturación e inflación de prioridades, rediseñó su sistema de colas cambiando incentivos por presupuestos.
👁 112 lecturas
El Allen Institute for AI (Ai2) ha publicado una autopsia técnica sobre la reconstrucción completa del sistema de colas en sus clústeres de GPU. El informe ilustra a la perfección cómo una infraestructura bien diseñada sobre el papel puede colapsar cuando choca con la presión del uso real diario.
Ai2 administra miles de tarjetas NVIDIA H100, B200 y B300 repartidas en clústeres de entre 88 y 1024 GPU. De estos recursos dependen unos 150 investigadores internos con necesidades totalmente dispares: desde el entrenamiento a gran escala de modelos de lenguaje (LLM) y modelos de visión-lenguaje (VLM), hasta simulaciones de aprendizaje por refuerzo para robótica o post-entrenamiento de agentes científicos. Es un abanico de cargas de trabajo que exige tanto sesiones de cómputo ininterrumpidas de semanas como acceso inmediato para depurar código en tiempo real, dos mundos muy difíciles de conciliar con una simple escala de prioridades.
Google · Tus fuentesBrilla más alto en tu Google - con un solo clicAñadir a fuentes preferidas →La tragedia de los recursos compartidos en un clúster
La saturación no era nueva: la demanda de tiempo de cálculo superaba a la oferta de forma crónica. En cualquier momento dado, la cola de tareas solicitaba entre dos y tres veces más tarjetas de las disponibles físicamente. En la práctica, dos o tres proyectos de investigación competían simultáneamente por cada hora libre de GPU.
El sistema anterior combinaba niveles de prioridad con la opción de solicitar ejecuciones no interrumpibles (sin preemption). Cada equipo disponía de un cupo máximo de tarjetas blindadas frente a expulsiones forzosas, mientras que las tareas interrumpibles podían ocupar hardware ocioso por encima de ese límite. La teoría parecía sensata, pero generó tres vicios operativos muy claros:
El primero fue el llamado «GPU squatting»: los investigadores lanzaban procesos vacíos (cargas no-op) para mantener tarjetas reservadas y conectarse al instante cuando necesitaban depurar código, ya que levantar una tarea nueva desde cero implicaba esperas inasumibles. El segundo vicio fue la inflación descontrolada de prioridades: en un punto crítico, el 100% de los trabajos programados utilizaba la prioridad máxima HIGH, lo que dejó sin acceso alguno a las categorías inferiores. El tercero afectó de lleno al equipo de guardia: los ingenieros pasaban la mayor parte de sus turnos negociando manualmente con los investigadores para que detuvieran tareas no interrumpibles que corrían sobre nodos con fallos de hardware detectados.
En Ai2 reconocen que tardaron en identificar la raíz del problema. Sus primeros parches consistieron en restringir el uso de prioridades altas y, más adelante, en puentear el propio planificador asignando clústeres enteros en exclusiva a proyectos concretos. Con el tiempo comprendieron que estaban ante una clásica tragedia de los bienes comunes: cada usuario, actuando de forma completamente racional en favor de su propio proyecto, degradaba el rendimiento del recurso compartido para el resto.
La solución definitiva consistió en sustituir el planificador por prioridades por un modelo basado en tres pilares: presupuestos cerrados de horas de GPU asignados a cada proyecto de antemano, reparto jerárquico equitativo (hierarchical fair-share) y contratos explícitos de fraccionamiento temporal (time-slicing), que fijan las ventanas exactas en las que cada iniciativa tiene derecho a reclamar máquinas. El cambio más relevante fue organizativo: la disputa sobre cuánta potencia de cálculo merecía cada proyecto dejó de ser una negociación tensa en plena incidencia técnica para convertirse en un reparto presupuestario administrativo y transparente.
Es una lección clave si gestionas infraestructura de cálculo compartida: el fallo de Ai2 no residía en el algoritmo del scheduler, sino en el diseño de los incentivos. Si bloquear una GPU no acarrea ningún coste visible para el investigador, la bloqueará; si asignar la prioridad máxima es gratis, todo el mundo la usará. Al hacer que cada reserva tenga un impacto presupuestario medible y público dentro de la organización, la conducta de los usuarios se autorregula mucho mejor que con cualquier algoritmo de expulsión forzosa.
More on this from FULGOR
herramientas de ia·Gemini agent vs. ChatGPT vs. Claude: que elegir para tu empresaComparamos Gemini agent, ChatGPT Business y Claude Team: diferencias clave, precios oficiales, privacidad de datos en la UE y que opcion conviene a tu negocio.