Ai2 внедрила для своих GPU-кластеров планировщик, который распределяет не разовые приоритеты задач, а заранее выделенные бюджеты GPU-времени. Система должна одновременно давать исследовательским группам предсказуемую долю вычислений и не оставлять ускорители незанятыми. Значение изменения — в переносе решений о том, какие работы важнее, из оперативных споров в механизм управляемого распределения ресурсов, как описывает команда инфраструктуры Ai2.

Почему глобальный приоритет перестаёт работать.

В общей очереди высокий приоритет становится дефицитным и потому быстро обесценивается: у команд появляется стимул помечать критичными почти все задания или удерживать выделенные GPU дольше необходимого. В прежней схеме Ai2 это приводило к «захвату» ресурсов, инфляции приоритетов и ручным переговорам об остановке задач, которые нельзя было прервать. Эти последствия и заявленные результаты перехода собраны в описании нового подхода.

Для ML-кластера проблема не сводится к длине очереди. Обучение на нескольких GPU требует регулярной синхронизации по сети, поэтому размещение ускорителей на подходящих узлах влияет на ход работы. Одновременно кластер обслуживает короткие отладочные запуски, долгие обучения и сервисные задачи с разными требованиями к памяти и числу GPU. Как объясняет обзор систем планирования ML-нагрузок, справедливость между пользователями приходится балансировать с локальностью размещения, возможностью приостановки и разделением ускорителей во времени.

Бюджет как формализованное право на вычисления.

В модели Ai2 руководители распределяют доли GPU-времени между направлениями, проектами и исследователями. Такая иерархия связывает стратегические решения с ресурсами: группа получает пропорциональное право на часть мощности, а не пытается каждый раз заново выиграть место в единой очереди. Защищённым от вытеснения считается задание, на которое выделен соответствующий бюджет. Если команда запускает работу без практической ценности или держит её слишком долго, она расходует собственную долю, а не получает преимущество перед остальными.

Fair-share в этой схеме измеряется не в моменте, а на скользящем окне — у Ai2 по умолчанию оно составляет семь дней. Планировщик отслеживает, какая группа использовала меньше или больше своей доли, и поднимает в очереди недоиспользованные распределения. Гарантия действует при достаточном спросе: группа, не отправляющая задач, не может фактически занять выделенное ей время. В первичном описании системы отдельно разделены доступность исправного оборудования, занятость назначенным заданием времени, выбор наиболее ценных работ и фактическая загрузка GPU внутри работы.

Третий элемент — временной контракт. Он ограничивает период, в течение которого задача защищена от вытеснения, после чего её можно остановить и вернуть в очередь. По приведённым данным, Ai2 установила предел защищённого исполнения в восемь часов. Это снижает зависимость от ручного вмешательства при проблемах с хостами, но делает интерактивные сессии анализа и отладки прерываемыми. Для таких сценариев командам необходимо учитывать возможное завершение выделенного временного среза.

Какие показатели заявлены после внедрения.

Ai2 приводит результаты 30-дневного периода: команды получили 98% причитавшихся им GPU-часов, а занятость кластера сохранилась на уровне 98%. Для отладочных задач p90 времени ожидания, по этим данным, сократился с двух часов до 30 секунд, а число ручных операций по восстановлению снизилось на 74%. Эти цифры характеризуют конкретную инфраструктуру и заявлены самой стороной внедрения, поэтому их нельзя автоматически переносить на кластеры с другой конфигурацией, составом задач и политикой прерываний.

Также не следует смешивать занятость и полезную загрузку. Высокая occupancy означает, что доступное время назначено работам, но не доказывает, что GPU эффективно выполняли вычисления в течение всего жизненного цикла задания. Полезная utilization зависит от подготовки данных, сетевой синхронизации, размера батча, простоев внутри приложения и соответствия задачи выбранному типу ускорителя. Новая схема прежде всего меняет порядок доступа к мощности и делает его проверяемым.

Как этот подход соотносится с исследованиями.

Бюджетное fair-share-планирование относится к более широкому классу методов, где очередь учитывает накопленное потребление ресурсов. В обзоре алгоритмов GPU-планирования описаны, в частности, временные аренды в Tiresias: после каждого среза приоритет может перейти работе с меньшим объёмом уже полученного GPU-времени. Там же рассматриваются профилирование производительности и адаптация к неоднородному оборудованию. Подход Ai2 добавляет к этим техническим механизмам явный административный слой бюджетов.

Другие работы показывают, что единственного универсального правила для кластера нет. Авторы исследования с моделью, вдохновлённой энергосистемами сообщили об улучшениях загрузки, пропускной способности и времени завершения в симуляторе с восемью NVIDIA Tesla V100 за счёт прогнозирования, оптимизации и обратной связи. В отдельном препринте о динамическом многокритериальном планировании авторы получили более высокую загрузку и меньше случаев длительного ожидания по сравнению со статическими FIFO- и SJF-политиками. Это результаты моделей и экспериментов, а не прямое подтверждение показателей Ai2, но они указывают на общую проблему фрагментации и голодания задач.

Что проверить при внедрении.

Если Вы строите общий GPU-кластер, полезно разделить три уровня решений: кто получает долю ресурсов, как она измеряется во времени и когда задачу допустимо вытеснить. Бюджеты не заменяют мониторинг доступности оборудования и фактической загрузки, а временные срезы требуют, чтобы рабочие процессы переносили остановку и повторную постановку. Для многогпу-задач также остаются критичными размещение на узлах и сетевая топология. Практический вывод из опыта Ai2 состоит не в выборе единственного алгоритма, а в том, что правила справедливости, приоритетов и прерываний должны быть заранее определены, измеримы и понятны всем пользователям кластера.