Очередь на GPU без вечного «срочно»: что показал опыт AI2

Когда несколько команд делят один кластер, слово «срочно» быстро перестаёт что-либо значить. Инженеры Allen Institute for AI 9 октября подробно описали перестройку своей очереди GPU-задач. Раньше приоритет можно было повышать почти без цены, а некоторые долгие задания нельзя было прервать. В итоге исследователи удерживали ресурсы на всякий случай, инженеры договаривались об остановке вручную, а короткая отладка ждала часами. Новый подход распределяет не закреплённые серверы, а бюджет времени, который команда может тратить на свои задачи. Это обзор конкретного внутреннего опыта, не инструкция «скопируйте код и получите те же числа».

Почему обычный приоритет сломался

В описанном кластере работают тысячи ускорителей H100, B200 и B300, а запросов на GPU постоянно в два-три раза больше доступной мощности. Система с уровнями приоритета предполагала, что люди честно выберут важность задания. Но когда высокий приоритет не сокращал другой лимит команды, рациональным действием было пометить так всё. По данным авторов, в какой-то момент 100% запланированных задач имели HIGH. Низкие уровни перестали получать время. Задание, которое нельзя вытеснить, могло долго занимать машину даже тогда, когда возникала более ценная работа.

Дополнительный симптом — «парковка» почти пустой задачи, к которой исследователь подключится позже. Так появлялся быстрый личный доступ к GPU, но для общей системы ресурс выглядел занятым. Осуждать отдельного пользователя здесь мало полезно: он отвечал на длинную очередь и отсутствие короткого отладочного слота. Чтобы изменить поведение, разработчики изменили правила распределения, а не только интерфейс выбора приоритета.

Бюджет времени вместо собственности на сервер

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

Авторы различают оплачиваемое бюджетом и свободное, но вытесняемое время. Последнее позволяет не оставлять GPU пустым, если запланированные работы ещё не готовы. Для долгой тренировки введён «контракт»: задача указывает минимальное время, нужное для осмысленного прогресса. На этот период её защищают от вытеснения, затем она может продолжаться или быть поставлена в очередь повторно. Нулевой минимум означает выполнение на свободной мощности без гарантии. Такой договор возможен только там, где длинная работа умеет сохранять состояние и возобновляться. Если checkpoint отсутствует, вытеснение может уничтожить часы прогресса.

Какие результаты измерили

После постепенного запуска авторы сообщили о 98% GPU-часов, которые команды должны были получить с учётом реального спроса, и примерно 98% занятости кластера до и после изменения. Это две разные метрики: справедливая выдача времени и отсутствие простоя. Для коротких отладочных задач p90 ожидания, по их данным, упал с двух часов до 30 секунд. На крупнейшем H100-кластере медианное ожидание сократилось с пяти минут до 24 секунд. Число ремонтов, где требовалось ручное участие из-за работающей задачи, снизилось на 74%. Эти значения относятся к их инфраструктуре и периоду наблюдения; переносить их в рекламный прогноз для чужого кластера нельзя.

Есть и неудачная сторона. Интерактивная сессия раньше могла жить неделю, а с новым правилом защищённый период ограничен восемью часами. Исследователь, который хранил промежуточное состояние только внутри сессии, после вытеснения тратил время на восстановление. Команда AI2 собирается вынести часть такой работы в CPU-кластер и сделать восстановимые сессии. Она также наблюдает за возможной фрагментацией ресурсов, из-за которой очень крупным заданиям сложнее получить много GPU одновременно. Честный обзор должен сохранить эти оговорки рядом с удачными цифрами.

Что можно перенять маленькой команде

Не обязательно строить сложный планировщик. Сначала посчитайте, кто просит ресурс, как долго ждут короткие и длинные задачи, сколько GPU реально работают и сколько времени теряется из-за ручного согласования. Разделите разработку, исследование и производственный inference. Для каждого класса объявите правила остановки и сохранения состояния. Если очередь маленькая, еженедельный бюджет в таблице может быть прозрачнее самодельного алгоритма. В сравнении локального сервера и облака обсуждается, почему стоимость простаивающего ресурса зависит от режима владения.

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

Главная идея опыта не в новой волшебной формуле. Организация сделала ограниченный GPU-час видимым управленческим решением, а потом проверила, не ухудшила ли справедливость реальную работу исследователей.

Вопросы об очереди

Можно ли просто запретить HIGH? Это уберёт ярлык, но не дефицит. Нужны критерии распределения времени и быстрый путь для короткой отладки.

Бюджет означает, что GPU простаивает, если команда не запустилась? В описанной системе нет: свободные часы может занять другая вытесняемая работа.

Любую тренировку можно прерывать? Нет. Без надёжного checkpoint и проверки восстановления потери могут превысить пользу от справедливой очереди.

Значат ли 98% гарантированную эффективность модели? Нет. Показатель относится к выделенным GPU-часам; качество научного результата оценивается отдельно.