«Бюджеты вместо расписаний»: Ai2 перевела распределение GPU со шкалы приоритетов на fair-share и time-slicing

Пирамида из четырёх метрик

9 октября 2026 года команда AI Infrastructure института Ai2 опубликовала разбор «Impactful scheduling for GPU clusters» — о том, как в институте перестроили распределение дефицитного GPU-времени. Исходную задачу там описывают как пирамиду из четырёх метрик: в основании доступность железа, выше — заполненность (occupancy), затем польза (impact) решений планировщика и на вершине — утилизация (utilization), то есть доля GPU-мощности, реально использованная за всё время работы задачи.

Масштаб задан прямо: речь идёт о тысячах GPU NVIDIA H100, B200 и B300, собранных в кластеры от 88 до 1024 ускорителей, и о пуле примерно из 150 внутренних исследователей, чьи задачи покрывают обучение LLM и VLM, RL-симуляции для робототехники и постобучение для научных агентных сценариев. Спрос при этом устойчиво превышает предложение: в любой момент в очереди висят заявки на 2–3 раза больше GPU, чем есть в наличии, то есть каждый свободный GPU-час оспаривают два-три разных исследовательских проекта.

Что было не так со шкалой приоритетов

Исторически в Ai2 работал приоритетный планировщик, а задачи могли отказаться от преемптивности — права планировщика снять их с GPU. На каждый проект действовал лимит одновременных GPU для непременяемых задач, а преемптивные могли превышать лимит на простаивающих машинах. Эта схема породила предсказуемые патологии: «сквоттинг», когда пользователи держали пустышки-задачи, чтобы подключиться к ним в нужный момент, и инфляцию приоритетов, при которой в итоге 100% задач шли с приоритетом HIGH, а нижние уровни оставались без GPU-времени вовсе.

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

Авторы связывают это с известной областью: проблема распределения ресурсов лежит на стыке алгоритмов, экономики и системного администрирования, а её классика описана ещё в работе о Dominant Resource Fairness 2011 года, где приведён пример компании, выдававшей выделенные машины только под высокую утилизацию — и получавшей код с искусственными бесконечными циклами для накрутки этой метрики.

Бюджеты вместо расписаний

Ответом стало не расписание, а бюджетирование. Вместо выделения машин командам стали выделять долю GPU-времени: иерархическая система позволяет менеджерам пропорционально распределять время между проектами и исследователями, за которые они отвечают. Каждый запрос на GPU-время должен быть оплачен из бюджета — иначе задача не защищена от преемпции.

Смысл смены рамки в том, что халявы больше нет: раньше HIGH-приоритет ничего не стоил, а непременяемость позволяла бесконечно удерживать лимит, поэтому ими пользовались все; теперь любая уловка при получении GPU списывается из бюджета того, кому она выгодна, а «сквоттинг» тратит бюджет команды впустую. Цель сформулирована как экономическая: сделать игру с планировщиком дороже, чем честный спор за больший бюджет. Названы и уровни решений: внутри исследовательского проекта время распределяет ведущий исследователь, внутри программы — principal investigator, между программами — ведущий менеджер программы или CEO. В качестве иллюстрации приведён проект, за которым закреплена 35%-ная заявка на общую ёмкость кластера, независимо от того, сколько других проектов стоят в очереди.

Fair-share в скользящем окне

Вместе с бюджетами в Ai2 построили иерархический fair-share планировщик, который управляет фактической заполненностью распределений по дереву программы. Сам алгоритм, отмечают авторы, не нов: fair-share в скользящем окне восходит к Fair Scheduler в Hadoop 2009 года и сегодня живёт в SLURM Fair Tree и YARN Fair Scheduler; новое здесь — входные данные, потому что дерево повторяет структуру исследовательских программ, а веса задают менеджеры своими бюджетами вместо статических квот.

Заполненность планировщик оценивает в скользящем окне, по умолчанию — 7 дней, и сортирует задачи так, чтобы недобравшие распределения шли выше перебравших; за неделю каждая группа может рассчитывать получить своё время, если активно подаёт задачи с достаточным спросом. Различаются два вида заполненности: оплаченная, которая списывается с бюджета, влияет на расчёт fair-share и защищена от преемпции в пределах минимального времени работы, и неоплаченная, которая не списывается ни с кого, с самого начала не защищена и может быть вытеснена любым оплаченным запросом — именно она позволяет держать GPU занятыми даже тогда, когда распределения плохо совпадают со спросом.

Эффект описывает пользователь, которого в публикации приводит Chris Clark: «Новый планировщик даёт ощущение, что у нас на 30% больше вычислений. В старой схеме, если в какие-то моменты нам не нужен был весь лимит, эта мощность по сути терялась. Теперь мы можем позже выйти за лимит и всё равно увидеть свои задачи в расписании быстро и без преемпции — по сути возвращая эту мощность себе. Наши нагрузки часто пульсируют, так что это вернуло нам значительный объём вычислений».

Контракт планирования

Отдельная трудность распределённого обучения — длительность задач: тренировки идут часами, днями, а иногда и неделями, и однажды поставленная задача может держать GPU неделю и больше, не оставляя другим шанса получить забюджетированное время. Именно это свойство и делало возможным «сквоттинг», и именно оно вынуждало дежурных инженеров договариваться с владельцами долгих задач о ремонтах.

Решение названо «контрактом планирования»: в обмен на доступ к кластеру задача должна объявить минимальное время работы — сколько заполненности ей нужно, чтобы продвинуться осмысленно; в этот период она защищена от преемпции, а дальше планировщик получает право перераспределить ресурсы, автоматически возвращая возобновляемые задачи в очередь. Пользователь может выставить минимальное время в ноль — тогда GPU-время считается неоплаченным, такие задачи всегда можно вытеснить, но они и ничего не стоят бюджету. Жизненный цикл задачи описан по шагам: подача с минимальным временем и признаком возобновляемости, постановка по fair-share с весом отношения фактической заполненности к выделенному времени, работа в течение оплаченного минимума, продолжение, пока распределения дают ей приоритет, возможная преемпция с возвратом в очередь и завершение с освобождением ресурсов.

Именно это добавило в планировщик time-slicing: работающие задачи можно снимать и ставить обратно автоматически, из-за чего fair-share сходится, а сквоттинг теряет смысл; заодно нездоровые хосты получили возможность сами сливать задачи по достижении минимального времени работы. Последнее оказалось важнее, чем ожидалось при планировании: починки, требующие участия человека, сократились на 74%, что дало существенную экономию на дежурствах.

Симуляции и реальные результаты

Перед выкаткой в Ai2 собрали небольшой симулятор: он принимает набор задач с расписанием подачи и даёт планировщику решать о преемпции и назначении GPU, позволяя за секунды проиграть много дней и посчитать ожидание в очереди, события преемпции и распределение GPU-времени по проектам. На нём проверяли, в частности, гипотезу о «debug-задачах» — маленьких заданиях на 15 минут минимального времени и меньше: симуляции показали падение ожидания p90 примерно с 6 часов до 5 минут.

Выкатка шла кластер за кластером с конца июля 2026 года. За 30-дневный тестовый период команды получили 98% положенных им GPU-часов, а 13 из 15 распределений вышли на 95% и выше, худший случай — 90%. Заполненность кластера удержалась на 98% до и после изменения при том, что спрос превышал ёмкость в 2–3 раза в оба периода, а 18% выданного GPU-времени было неоплаченным — именно так сохраняли высокую загрузку, когда оплаченные сценарии ещё не были готовы к запуску.

Реальные числа оказались лучше прогноза: ожидание debug-задач по p90 упало с 2 часов до 30 секунд против предсказанных симуляцией 6 часов — 5 минут. Задержка в очереди улучшилась и как побочный эффект time-slicing: на крупнейшем кластере H100 медианное ожидание упало с 5 минут до 24 секунд, а p90 — примерно на треть, с 2,8 часа до 1,8 часа. По трём исходным проблемам отчитались так: короткие debug-задачи стартуют меньше чем за минуту, из-за чего сквоттинг теряет ценность, приоритет теперь влияет только на сортировку внутри команды, а нездоровые хосты сливают задачи автоматически.

Чего не учли

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

Не все сценарии выиграли. Интерактивные сессии для анализа данных и отладки кода раньше можно было держать до недели, а с time-slicing на защищённое время работы действует потолок в 8 часов, после которого сессия становится преемптируемой при превышении распределения — и исследователям приходилось заново собирать состояние. После опроса исследователей в план добавили два проекта: CPU-кластер рядом с локальным хранилищем под задачи подготовки данных и «восстанавливаемые» сессии, которые можно сохранить и поднять в другом месте без ручной пересборки. Отдельно названа возможная проблема фрагментации ёмкости: защита минимального времени работы может замедлить ожидание для самых крупных задач, и это сейчас проверяют одновременно симулятором и замерами в продакшене.

Что это значит

Практический вывод из разбора — не в конкретном алгоритме, а в смене рамки: там, где спрос в 2–3 раза превышает предложение, шкала приоритетов и опциональная непременяемость раз за разом вырождаются в «сквоттинг» и инфляцию приоритетов, а перевод спора о GPU-времени в бюджеты превращает его из операционной задачи в административный процесс. Ключевыми условиями авторы называют частые возможности для исследователей отстаивать нужное им время и решения на уровне менеджеров с наибольшим контекстом о компромиссах.

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