Ai2 revela agendador de GPUs que prioriza investigación de alto impacto sin perder ocupación

El equipo de infraestructura de IA del Allen Institute for AI (Ai2) detalla cómo construyó el programador que dirige sus clústeres de GPU: en lugar de reservar máquinas para los proyectos considerados más importantes, el sistema trata prioridad como un atributo dinámico de los jobs — trabajos estratégicos asumen recursos en la hora, y lo que fue interrumpido vuelve a la fila. El relato está en el blog oficial del instituto.

¿Qué ha cambiado Ai2 en el programador de GPUs?

El punto de partida es un clúster compartido por varios equipos de investigación, cada uno con plazos y ambiciones diferentes. La elección de Ai2 fue mantener un único pool de GPUs y resolver la disputa por prioridad. En la práctica, cada job carga una clase de prioridad; cuando un trabajo de prioridad alta entra en la fila y no hay capacidad libre, el programador interrumpe jobs de prioridad menor, devuelve esos trabajos a la fila y entrega los recursos al recién llegado.

Como entrenamientos distribuidos ya necesitan convivir con fallas de hardware, el instituto reaprovecha esa misma disciplina — checkpoints periódicos y reejecución — para hacer la preempción barata. La ganancia aparece en los dos lados: quien tiene prioridad no espera horas por una ventana libre, y la capacidad que quedaría reservada y ociosa continúa produciendo resultados.

¿Por qué no crear particiones dedicadas en el programador de GPUs?

El camino tradicional es rebanar el clúster: un bloque para investigación de punta, otro para experimentos exploratorios, un tercero para ajuste fino. Funciona para garantizar acceso, pero cobra caro, porque cada partición carga la propia ociosidad — si el bloque noble está vacío durante la madrugada, estas GPUs no ayudan a nadie.

Al cambiar la reserva por prioridad, el Ai2 transforma capacidad ociosa en trabajo útil: la fila de baja prioridad usa todo lo que no está siendo usado y es desalojada apenas cuando alguien más importante necesita. El costo es de ingeniería, no de hardware: preempción confiable, una política de prioridades que no sea capturada por un solo equipo y jobs capaces de empezar sin perder días de entrenamiento.

Lo que el planificador de GPUs requiere de quien entrena modelos distribuidos

Prioridad con preempción solo funciona si el job sabe morir y renacer. En la práctica, esto significa checkpoints frecuentes lo bastante para limitar el retrabajo, reinicio rápido del pipeline, consistencia entre los varios nodos de un entrenamiento distribuido y telemetría para medir cuánto tiempo útil fue perdido en cada interrupción.

El mensaje vale para cualquier equipo que rueda entrenamiento largos: resiliencia deja de ser un detalle de robustez y pasa a ser un requisito de programación. Un job que lleva horas para reiniciar inviabiliza la estrategia, por mejor que sea el planificador.

¿Por qué el planificador de GPUs importa para quien desarrolla en Brasil?

Compute sigue siendo el cuello local: laboratorios universitarios, grupos de investigación y startups dividen clusters pequeños y caros, o alquilan GPU por hora en nube. Cualquier práctica que aumente la ocupación de un pool compartido reduce el costo por experimento, incluso sin comprar una sola placa nueva.

La discusión dialoga directamente con iniciativas de infraestructura abierta para la academia, como la NSF OMAI: Ai2 coloca en el aire infraestructura de IA totalmente abierta para la academia. Para CTOs que pagan por hora de GPU, la lección es la misma: priorización y preempción tienden a salir más baratas que mantener capacidad dedicada parada esperando el próximo proyecto importante.

Lo que el planificador de GPUs de Ai2 todavía no resuelve

Es un relato de ingeniería, no un benchmark comparativo contra otros planificadores, los resultados dependen del perfil de carga del propio instituto y no vienen acompañados de series históricas estandarizadas. Tampoco hay receta lista para el problema político de definir quién es "alto impacto", ni una discusión detallada sobre portabilidad para otros orquestadores o ambientes multicloud con GPUs heterogéneas. Quien quiera replicar va a necesitar calibrar prioridades y políticas de checkpoint en la propia realidad.

Preguntas frecuentes sobre el programador de GPUs

¿Qué es el programador de impacto de Ai2?

Es el sistema que distribuye las GPUs de los clusters del instituto usando clases de prioridad y preempción: jobs más importantes pueden interrumpir jobs de prioridad menor, que vuelven a la fila y son retomados después.

¿Por qué no simplemente comprar más GPUs?

Porque el problema no es solo volumen, sino ubicación. Un pool único con prioridad evita la ociosidad típica de las particiones dedicadas y hace la misma capacidad rendir más experimentos por período.

¿Una empresa con pocas GPUs puede aplicar la idea?

Sí, a escala menor: basta un programador con prioridades, jobs con checkpoint frecuente y reinicio rápido. La ganancia es proporcional a la disputa interna por recursos.