Ai2 выпустил планировщик GPU: три механизма против очередей и простоя

Ai2 описал новый планировщик для своего GPU-кластера. Он строится на трёх механизмах: бюджетах времени, справедливом распределении ресурсов (fair-share) и тайм-слайсинге. Задач три: направлять вычисления в самые значимые исследования, сокращать ожидание в очереди и не давать ускорителям простаивать. Поэтому это рассказ об архитектуре решения, а не отчёт о результатах.

Три механизма в одной системе

Судя по описанию, каждый механизм закрывает отдельную проблему общего кластера.

Бюджеты времени задают, сколько GPU-часов может потратить команда или проект. Лимит делает потребление видимым и заставляет планировать эксперименты заранее, а не запускать всё подряд.

Fair-share следит, чтобы никто не занял кластер надолго. Если команда уже израсходовала много, её новые задачи уступают место тем, кто использовал меньше. Это классическая идея для Slurm и других планировщиков HPC, и Ai2 применяет её к исследовательской работе.

Тайм-слайсинг позволяет нескольким задачам по очереди делить один ускоритель. Дорогое железо тогда не простаивает между короткими запусками, а мелкие эксперименты не ждут, пока освободится целая машина.

Приоритет по влиянию

Самое интересное здесь формулировка «high-impact research». Обычно планировщики опираются на формальные признаки: кто первым встал в очередь, сколько уже потрачено, какая у пользователя квота. Ai2 заявляет, что учитывает и ценность работы. Это может быть решение руководителей проектов, тип задачи или стадия эксперимента. От ответа зависит, получится ли у системы честное распределение или просто ещё один способ договариваться о квотах.

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

Что заявлено в материале:

• три механизма: бюджеты времени, fair-share, time-slicing;
• цель по приоритетам: поддержка исследований с высоким влиянием;
• цель по очереди: сократить время ожидания;
• цель по утилизации: держать GPU занятыми;
• количественные результаты, размер кластера и детали реализации: не раскрыты.

Что из этого можно взять себе

Модель переносится на любую команду, у которой GPU меньше, чем желающих ими воспользоваться. Несколько практических выводов.

Первое: начинайте с учёта. Без данных о том, кто и сколько GPU-часов тратит, ни бюджеты, ни fair-share не заработают. Измеряйте минимум два показателя: медианное время в очереди и долю времени, когда ускорители реально считают.

Второе: разделяйте классы задач. Длинное обучение и короткая отладка требуют разных правил. Тайм-слайсинг полезен для второго класса. Для первого он может обернуться потерей эффективности из-за переключения контекста и конкуренции за память GPU.

Третье: заранее решите, как выражается «влияние». Если критерий не записан, приоритеты превратятся в переговоры, а жёсткие бюджеты начнут обходить.

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