В мире искусственного интеллекта, где каждый терафлоп на счету, управление вычислительными ресурсами перестало быть просто технической задачей администрирования. Это стало стратегическим вопросом, определяющим скорость научных открытий. В Allen Institute for AI (Ai2) команда инфраструктуры AI столкнулась с классической дилеммой: как распределить ограниченные ресурсы (GPU) между сотнями исследователей, чьи потребности в вычислениях многократно превышают доступную мощность?
Решение, которое они нашли, — это не просто новый алгоритм сортировки очередей, а фундаментальная смена парадигмы. Вместо того чтобы полагаться на субъективные приоритеты и ручное вмешательство, Ai2 перешла к системе, основанной на прозрачном бюджетировании времени GPU, иерархическом справедливом распределении (fair-share) и строгих контрактах на время выполнения. Этот подход не только устранил такие проблемы, как «сquatting» (захват ресурсов) и инфляцию приоритетов, но и позволил поддерживать полную загрузку кластера, превращая хаотичный запрос в управляемый инвестиционный процесс.
01Пирамида метрик эффективности кластера
Прежде чем углубляться в технические детали нового планировщика, важно понять, как Ai2 оценивает успех своей инфраструктуры. Команда использует концепцию «пирамиды» из четырех метрик, которые строятся друг на друге. Это помогает изолировать проблемы и понять, на каком уровне возникает узкое горлышко.
Основанием пирамиды является доступность (Availability). Это базовый уровень: насколько часто оборудование здорово, исправно и готово к работе. Если сервера лежат из-за аппаратных сбоев, никакое планирование не поможет. Следующий уровень — заполненность (Occupancy). Это доля времени, в течение которого доступные ресурсы фактически назначены на конкретную рабочую нагрузку. Пустующие GPU — это упущенная возможность. Третий уровень — влияние (Impact). Это метрика, показывающая, насколько часто самые ценные и стратегически важные рабочие нагрузки получают ресурсы. И вершиной пирамиды является утилизация (Utilization) — доля мощности GPU, использованная за весь жизненный цикл рабочей нагрузки.
Статья, которую мы анализируем, сфокусирована именно на улучшении уровня «Влияние». Проблема заключалась в том, что старые методы планирования не могли гарантировать, что ресурсы будут направлены на те проекты, которые приносят наибольшую научную ценность, часто из-за того, что ресурсы блокировались менее важными задачами или просто простаивали из-за плохой координации.
02Трагедия общин в мире GPU
Чтобы понять масштаб проблемы, нужно взглянуть на инфраструктуру Ai2. Институт управляет тысячами GPU, включая NVIDIA H100, B200 и B300, собранными в кластеры от 88 до 1024 устройств. Эти мощности обслуживают около 150 внутренних исследователей, работающих над самыми разными задачами: от обучения больших языковых моделей (LLM) и визуальных языковых моделей (VLM) до симуляций обучения с подкреплением для робототехники и пост-обучения для научных агентов.
Спрос на вычислительные ресурсы в Ai2, как и в большинстве ведущих AI-лабораторий, значительно превышает предложение. В любой момент времени количество запросов на GPU в 2-3 раза превышает доступное количество устройств. Это означает, что каждый доступный час работы GPU конкурирует за внимание 2-3 различных исследовательских групп.
Исторически Ai2 использовал планировщик на основе приоритетов. Исследователи могли выбирать, хотят ли их рабочие нагрузки подвергаться прерыванию (preemptability). У каждой команды был лимит на одновременное использование GPU для задач, защищенных от прерывания. Задачи, допускающие прерывание, могли использовать свободные GPU, превышая этот лимит. Эта система привела к предсказуемым, но разрушительным патологиям.
Одной из самых серьезных проблем стало «сquatting» (захват ресурсов). Исследователи обнаруживали, что не могут запустить отладочные задачи с достаточной скоростью, чтобы решать проблемы в реальном времени. Чтобы избежать ожидания в очереди, они оставляли «пустые» рабочие нагрузки, которые ничего не делали, но занимали GPU, чтобы быть готовыми подключиться к ним в любой момент. Это приводило к тому, что мощные GPU простаивали, ожидая подключения, которое могло никогда не состояться.
Другой проблемой стала «инфляция приоритетов». Поскольку высокий приоритет давал преимущества, со временем 100% запланированных рабочих нагрузок начали использовать уровень HIGH. Это означало, что задачи с низким приоритетом полностью лишались доступа к GPU. Кроме того, поскольку возможность прерывания была опциональной, инженеры на дежурстве тратили большую часть времени не на решение технических проблем, а на переговоры с владельцами непрерываемых рабочих нагрузок о их «организованном завершении» на серверах, требующих обслуживания.
03От монополий к бюджетам времени
Первоначальные попытки решить эти проблемы заключались в более строгом контроле над установкой приоритетов и, в конечном итоге, в назначении монополий на GPU для самых важных проектов. Однако Ai2 быстро поняла, что это лишь усугубляло проблему. Назначая командам монополии над наборами GPU, они создавали идеальную лабораторию для наблюдения за «трагедией общин» в действии. Исследователи, зная, что ресурсы закреплены за ними, часто не использовали их эффективно, в то время как другие команды простаивали.
Проблема усугублялась сезонностью исследовательской работы. Команды готовы запускать эксперименты и обучение в разное время. Если одна команда получала монополию на GPU, но в данный момент не запускала задачи, эти GPU простаивали, а другая команда, нуждающаяся в вычислениях, ждала в очереди. Ai2 оказалась в ситуации, когда они вручную решали задачу о рюкзаке (knapsack problem), пытаясь втиснуть динамически меняющиеся исследовательские потребности в статическое расписание.
Решение пришло из экономики. Классическое решение трагедии общин — приватизация общего ресурса, чтобы владельцы были заинтересованы в максимизации ценности своего имущества. Но приватизация самих GPU была слишком грубым инструментом. Вместо этого Ai2 решила выделить не сами устройства, а время GPU.
Предсказание спроса на будущее требует знания результатов новых научных экспериментов, что невозможно сделать с точностью. Однако приоритетность исследовательских усилий — это вопрос стратегии, который можно обсудить и решить заранее. Ai2 позволила руководству думать как инвесторам: до того, как появятся рабочие нагрузки, решить, как финансировать каждое исследовательское направление временем GPU, основываясь на суждениях о его потенциальном влиянии.
04Иерархическое справедливое распределение (Fair-Share)
На основе этой идеи была разработана иерархическая система, в которой менеджеры могут пропорционально распределять время GPU между проектами и исследователями. Как показано на диаграмме, это переводит стратегию программы напрямую в гарантированную долю времени GPU. Например, Проект A1 знает, что он имеет 35% претензии на общую мощность, независимо от того, сколько других проектов находятся в очереди в других отделах.
В этой новой системе каждый запрос на время GPU должен быть профинансирован из бюджета. Если бюджета нет, задача не защищена от прерывания. В старой системе высокий приоритет не стоил ничего, и команды могли бесконечно заполнять свой лимит одновременных GPU. Теперь ничего не бесплатно: любая попытка обмануть планировщик расходует выделенный пользователю бюджет. Захват ресурсов (squatting) теперь стоит команде их собственного бюджета, что делает обман планировщика дороже, чем честная защита своего бюджета на совещаниях.
Процесс пересмотра бюджетов постоянно совершенствуется, но ключевые требования остаются неизменными: у исследователей должны быть частые возможности отстаивать свои потребности, а решения должны приниматься менеджерами, обладающими наибольшим контекстом о компромиссах. Таким образом, распределение ресурсов внутри исследовательского проекта определяет ведущий исследователь, внутри программы — главный исследователь (PI), а между программами — ведущий менеджер программы или даже генеральный директор.
Вместе с инструментом бюджетирования был построен планировщик иерархического справедливого распределения (hierarchical fair-share scheduler). Алгоритм не нов: он восходит к Hadoop Fair Scheduler 2009 года и сегодня активно используется в SLURM Fair Tree и YARN Fair Scheduler. Новизна Ai2 заключается в входах: дерево отражает структуру исследовательских программ, а веса — это бюджеты, установленные менеджерами, а не статические квоты.
Планировщик отслеживает заполненность за скользящее окно просмотра (по умолчанию 7 дней) и сортирует рабочие нагрузки, начиная с тех, у которых недоиспользованные выделения, и заканчивая теми, у которых переиспользованные. Таким образом, за недельный период каждая группа получает свое выделенное время GPU, если она активно отправляет рабочие нагрузки с достаточным спросом.
05Контракт на время выполнения (Scheduling Contract)
Дополнительной сложностью распределения ресурсов в распределенном обучении является то, что рабочие нагрузки могут работать очень долго. Задачи обучения регулярно выполняются часами, днями и иногда даже неделями. Однажды запланированная рабочая нагрузка может оставаться на своих GPU в течение недели или более, не предоставляя другим возможности получить их бюджетное время. Это свойство системы сделало возможным «squatting» и заставило инженеров на дежурстве вести переговоры с владельцами долго работающих задач для решения проблем обслуживания.
Чтобы решить эти проблемы, Ai2 ввела «контракт на планирование». В обмен на доступ к кластеру рабочая нагрузка должна объявить свое минимальное время выполнения (minimum runtime) — кратчайший период занятости, необходимый для достижения значимого прогресса. В течение этого времени рабочая нагрузка защищена от прерывания. Это дает исследователю гарантию прогресса, а планировщику — право на перераспределение ресурсов после того, как прогресс достигнут, автоматически повторно помещая возобновляемые рабочие нагрузки в очередь.
Альтернативно, пользователь может установить минимальное время выполнения равным нулю, что указывает на то, что время GPU должно быть не выделенным (unallocated). Такие задачи всегда подвержены прерыванию, но они бесплатны в том смысле, что не списываются ни с какого бюджета. Это позволяет использовать GPU для быстрых отладочных задач, не тратя основной исследовательский бюджет.
Жизненный цикл рабочей нагрузки выглядит следующим образом:
- Рабочая нагрузка отправляется с указанием минимального времени выполнения и того, является ли она возобновляемой.
- Рабочая нагрузка планируется в соответствии с алгоритмом fair-share, взвешенным соотношением фактической заполненности к выделенному времени в окне просмотра.
- Рабочая нагрузка выполняется в течение своего минимального времени выполнения, что списывается с ее выделений.
- Рабочая нагрузка может продолжать работать, пока связанные выделения продолжают приоритизировать ее над другими. Это время также списывается с ее выделений.
- Рабочая нагрузка может быть прервана и повторно помещена в очередь, что возвращает нас к шагу 2.
- Рабочая нагрузка завершается, освобождая свои претензии на ресурсы.
Вместе эти соглашения добавляют нарезку времени (time-slicing) в планировщик. Запущенные рабочие нагрузки могут быть удалены и повторно помещены в очередь автоматически, позволяя fair-share сходиться и не поощряя захват ресурсов. Они также позволяют нездоровым узлам освобождать свои рабочие нагрузки по мере достижения ими минимального времени выполнения, так что действия по ремонту могут быть полностью автоматизированы. Этот последний пункт оказался важнее, чем предполагалось при планировании работы. Он сократил ремонты, требующие участия человека, на 74%, что стало огромной экономией времени для инженеров на дежурстве.
06Симуляции и тестирование гипотез
Известно, что изменения в политике планирования могут иметь непредвиденные последствия. Нуль-суммовый характер проблемы означает, что предоставление времени одному исследователю означает отнятие времени у другого. Пользователи, проигрывающие в этом обмене, склонны искать новые обходные пути. Перед развертыванием системы на основе бюджетов Ai2 хотела быстрый способ предсказать, где могут возникнуть более длительные времена ожидания, и протестировать конфигурационные параметры, такие как длина окна просмотра или максимальное значение для минимального времени выполнения (они выбрали 8 часов).
Команда создала среду симуляции, которая принимает набор рабочих нагрузок и их график отправки в качестве входных данных и позволяет планировщику принимать решения о прерывании и назначении GPU. Зная количество запрашиваемых GPU и общее время выполнения каждой рабочей нагрузки, симулятор мог прыгать вперед к моментам планирования и предоставлять анализ времени ожидания в очереди, событий прерывания и распределения времени GPU между проектами за многие симулированные дни всего за несколько секунд. Симулятор запускался как на исторических данных об отправке, так и на сконструированных сценариях, которые требовали лучшего понимания.
Одна из гипотез, которую хотели проверить, касалась «отладочных рабочих нагрузок» (debug workloads). Эти задачи требуют небольшого количества GPU и минимального времени выполнения 15 минут или меньше, чего достаточно, чтобы пользователь увидел, успешно ли запускается задача или она аварийно завершается из-за ошибки. Исследователи хотели знать, будут ли эти задачи видеть меньшее время ожидания в очереди, чем крупные задачи обучения, которые часто требуют множества GPU и часов времени выполнения для достижения значимого прогресса. Интуитивно эти мелкие задачи должны подниматься в верхнюю часть очереди, так как маленькая задача может поместиться в больше мест, чем большая. Но точная задержка очереди была важна: короткое ожидание в минуту или две открывает новую практику разработки, но ожидание в десять минут становится нецелесообразным.
Симуляции требовали ручного создания тестовых данных, потому что исторические записи не содержали достаточного объема таких отладочных рабочих нагрузок. Результаты поддержали гипотезу: p90 времени ожидания отладочных рабочих нагрузок упало примерно с 6 часов до всего 5 минут. Это изменение позволило исследователям отлаживать код практически в реальном времени, не теряя дней на ожидание ресурсов.
07Результаты внедрения
Имея результаты симуляций, команда начала развертывание кластер за кластером в конце июля. Результаты, которые их интересовали, заключались в том, получают ли рабочие нагрузки, которые они выбрали для финансирования, свое время, поддерживает ли новая система полную заполненность и могут ли исследователи рассуждать о планировщике, чтобы принимать обоснованные решения.
С момента развертывания Ai2 наблюдала, как пользователи и команды последовательно получают свое выделенное время GPU. Система успешно перешла от хаотичного распределения ресурсов на основе криков и приоритетов к прозрачному, экономически обоснованному процессу. Исследователи теперь могут планировать свои эксперименты, зная свои бюджетные ограничения, а инженеры инфраструктуры освободились от необходимости постоянно вмешиваться в споры о том, чья задача важнее.
Важно отметить, что новая система не просто техническое улучшение, а культурный сдвиг. Она заставляет исследовательские группы думать о вычислительных ресурсах как о бюджете, который нужно эффективно расходовать, а не как о безграничном благе. Это приводит к более осознанному проектированию экспериментов, лучшей подготовке кода и более эффективному использованию общего вычислительного потенциала института.
08Что это значит на практике
Для организаций, управляющих крупными кластерами GPU, опыт Ai2 предлагает несколько ключевых уроков. Во-первых, приоритеты сами по себе не работают. Когда приоритеты не имеют стоимости, они обесцениваются. Введение «стоимости» в виде бюджета времени GPU заставляет пользователей взвешивать свои потребности и избегать захвата ресурсов.
Во-вторых, гибкость важнее жесткого закрепления ресурсов. Иерархическое справедливое распределение с окном просмотра позволяет системам адаптироваться к сезонности и burst-характеру рабочих нагрузок, обеспечивая высокую общую утилизацию без необходимости ручного перераспределения.
В-третьих, автоматизация жизненного цикла задач критически важна. Введение контрактов на минимальное время выполнения не только защищает прогресс исследователей, но и позволяет полностью автоматизировать обслуживание оборудования, сокращая операционные издержки на 74%. Это показывает, что хорошее планирование — это не только про то, кто получит GPU, но и про то, как легко система может перераспределить ресурсы при необходимости.
Наконец, симуляции перед развертыванием могут сэкономить месяцы проблем. Тестирование гипотез о времени ожидания и поведении системы в контролируемой среде позволило Ai2 избежать непредвиденных последствий и быстро настроить параметры под реальные потребности исследователей. Для российских компаний и исследовательских центров, сталкивающихся с аналогичными проблемами распределения ограниченных вычислительных ресурсов, эти принципы могут быть адаптированы с учетом локальных особенностей инфраструктуры и регуляторных требований, предлагая путь от хаотичного использования к управляемой эффективности.
Источник: Hugging Face ↗