GPU-менеджмент: как порядок задач увеличил утилизацию на 33%

В индустрии искусственного интеллекта сложился парадокс, который многие компании игнорируют, продолжая сжигать бюджет на аренду видеокарт. Мы привыкли думать, что главная проблема — это нехватка вычислительных мощностей или «глупость» моделей. Однако, как показывают новые исследования от Dharma-AI, истинным ограничением становится не интеллект, а утилизация. В корпоративном секторе AI-кластеры часто работают на 50% своей потенциальной мощности, просто потому, что система планирования задач (scheduler) устарела и не умеет работать с гетерогенной нагрузкой.

В этой статье мы подробно разберем кейс, где команда Dharma-AI продемонстрировала, что изменение порядка принятия решений о распределении ресурсов может дать прирост утилизации на 33 процентных пункта и рост приоритетной ценности вывода на 105%. Никакого нового железа не покупалось. Не менялась архитектура моделей. Изменилась только логика того, как GPU выделяются под обучение, инференс и квантование. Это не просто оптимизация кода, это фундаментальный сдвиг в архитектуре управления инфраструктурой.

01Проблема: два несовместимых формата нагрузки

Чтобы понять, почему традиционные подходы терпят неудачу, нужно взглянуть на то, как на самом деле выглядят рабочие нагрузки (workloads) в реальном AI-кластере. Существует четыре основных типа задач, которые конкурируют за одни и те же GPU:

1. Обучение (Training): Долгие, ресурсоемкие задачи, требующие непрерывного доступа к большим блокам GPU.
2. Пакетный инференс (Batch Inference): Задачи, которые можно запускать группами, но они также требуют выделенных ресурсов на время выполнения.
3. Квантование (Quantization): Процесс сжатия моделей, который часто откладывается на «потом», но требует значительных вычислений.
4. Инференс в реальном времени (Real-time Inference): Сервисы, обслуживающие пользователей, где задержка критична.

Ключевая сложность заключается в том, что эти задачи делятся на два принципиально разных типа распределения ресурсов:

• Пакетные задачи (Training, Batch Inference, Quantization): Они «жадные». Как только задача началась, она требует непрерывного блока GPU без перерывов до самого завершения. Если вы начали обучать модель, вы не можете «откусить» от нее GPU на 5 минут, чтобы отдать их другому процессу, и продолжить позже. Это бинарное состояние: либо весь блок занят, либо свободен.
• Эластичная нагрузка (Real-time Inference): Эта нагрузка похожа на воду. Она зависит от кривой спроса, которая меняется каждую секунду. В часы пик нужно 10 GPU, в 3 часа ночи — 2 GPU. Она гибкая и может масштабироваться вверх и вниз.

Проблема возникает, когда эти два несовместимых формата пытаются разместить на одном hardware в одно и то же время. Пакетная задача требует «целого куска», а эластичная нагрузка постоянно меняет свой размер. Если планировщик не учитывает эту разницу, он либо оставляет GPU пустыми, либо блокирует критически важные сервисы.

02Почему FIFO (First-In-First-Out) стоит дорого

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

В спокойные времена, когда в кластере есть запас мощности, FIFO работает нормально. Все помещается, порядок не важен. Но как только возникает конкуренция (contention), стоимость порядка становится очевидной. FIFO наказывает кластер двумя способами:

1. Стоимость резервации (The Reservation Cost)

Сервисы реального времени не могут ждать. Если трафик вырастет через час, GPU должны быть готовы уже сейчас. Планировщик FIFO не умеет «освобождать» GPU в периоды спада трафика и возвращать их в пул. Поэтому он вынужден резервировать максимальное количество GPU, необходимое сервису за весь день, на весь день.

Представьте сервис, которому в обед нужно 6 GPU, а в 4 утра — всего 2 GPU. При стратегии FIFO система зарезервирует 6 GPU на 24 часа. Четыре GPU будут простаивать вхолостую, недоступные для других задач, таких как обучение или пакетная обработка. Это не просто пустая трата; это «мертвый груз». В сценариях, где доминирует резервация, утилизация кластера падает до 51-53%. Почти половина парка GPU просто стоит, ожидая пика, который наступает лишь несколько часов в сутки.

2. Стоимость порядка (The Ordering Cost)

Когда ресурсов не хватает, порядок, в котором задачи поступают в очередь, становится решением о распределении емкости. FIFO ставит задачу в очередь просто по факту ее появления, не взвешивая ее ценность и не глядя на то, что еще нужно будет выполнить в будущем.

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

03Решение: Constraint-Aware Аллокатор

Команда Dharma-AI предложила альтернативу: аллокатор, aware (осведомленный) о ограничениях (constraint-aware). Вместо того чтобы принимать решения локально и мгновенно, как это делает FIFO, этот аллокатор рассматривает расписание как единую сетку (grid) на всем горизонте планирования. Он видит все ожидающие задачи, их приоритеты и требования к ресурсам, прежде чем принять первое решение.

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

1. Один GPU — одна задача: В каждый момент времени GPU не может быть занят двумя задачами одновременно.
2. Непрерывность для пакетных задач: Задачи обучения и пакетного инференса занимают непрерывные блоки GPU, размер которых кратен степени двойки (например, 2, 4, 8, 16 GPU). Это требование архитектуры распределенного обучения.
3. Ограничение на «дрейф» для инференса: Сервисы реального времени могут менять количество выделенных GPU между временными шагами, но это изменение ограничено (cap), чтобы избежать нестабильности.
4. Защита запущенных задач: Если задача уже началась, ее нельзя прервать (preemption). Это критично для длительных процессов обучения.

Целевая функция (objective function) аллокатора имеет два компонента:

• Награда: За выделение GPU пакетной задаче. Размер награды равен приоритету задачи, умноженному на вес времени (time-decay weight). Вес времени уменьшается по мере удаления в будущее, потому что в онлайн-системе новые задачи могут появиться в любой момент, и «золото» сейчас ценнее, чем «золото» завтра.
• Штраф: За неудовлетворенный спрос на инференс в реальном времени. Штраф пропорционален размеру дефицита GPU.

Ключевой параметр здесь — соотношение весов. Штраф за неудовлетворенный инференс в 5-10 раз превышает награду за выполнение пакетной задачи. Это означает, что одна единица неудовлетворенного спроса на инференс «стоит» как 5-10 GPU-часов пакетной работы. Эта асимметрия гарантирует, что эластичность инференса не нарушит SLA (Service Level Agreement), а пакетные задачи будут заполнять «провалы» в спросе на инференс.

04Как работает аллокатор на практике

Поскольку задача распределения ресурсов является NP-трудной комбинаторной оптимизацией, запуск полного математического решения для каждого входящего запроса невозможен из-за задержек. Архитектура решает эту проблему с помощью двух режимов:

1. Fast Mode (Быстрый режим): Использует эвристический алгоритм, который «горячий путь» (hot path). Этот эвристик не является жадным алгоритмом в обычном смысле. Его правила строго следуют структурным ограничениям формальной модели. Каждый сетка, которую он генерирует, является легальным распределением «по дизайну». Он работает за 1-2 миллисекунды на 8 GPU и 15 мс на 64 GPU. Это позволяет запускать его на каждый входящий запрос.
2. Full Mode (Полный режим): Использует сетку из быстрого режима как начальную точку для формальной модели, которая пытается улучшить результат. Этот режим подходит для периодического пересмотра расписания, а не для принятия решений в реальном времени.

Главное преимущество такого подхода — глобальный взгляд. Аллокатор видит все задачи в очереди. Он может «удерживать» свободный пул ресурсов в такой форме, чтобы оставшаяся работа действительно могла поместиться. Если пакетной задаче нужен блок из 4 GPU, аллокатор убедится, что этот блок останется свободным, когда придет очередь этой задачи. FIFO же, напротив, может раздать ресурсы по кусочкам первым пришедшим задачам, оставив «осколки», в которые уже ничего не влезет.

05Результаты бенчмарков: цифры говорят сами за себя

Команда протестировала аллокатор против FIFO в семи сценариях, моделирующих реальные условия конкуренции за ресурсы. Результаты были впечатляющими и последовательными.

В сценарии «Training-heavy» (8 GPU, 16 задач), где нагрузка была смещена в сторону обучения, утилизация выросла с 53,6% до 87,0% — это прирост в 33 процентных пункта. Приоритетная ценность вывода увеличилась на 105%, то есть почти вдвое. Это означает, что за те же деньги компания получила в два раза больше полезной работы.

В сценарии «Mixed control» (8 GPU, 10 задач) утилизация поднялась с 51,6% до 72,4%, а ценность выросла на 54,8%. Даже в сценарии «Real-time contention», где конкуренция была за инференс, утилизация выросла с 75,0% до 80,2%, а ценность — на 24,6%.

Особого внимания заслуживает Scale Test (64 GPU, 30 задач). Здесь утилизация осталась на уровне 44,9% для обоих планировщиков, но аллокатор увеличил приоритетную ценность на 15,9%. Это доказывает, что аллокатор не просто «забивает» кластер любыми задачами, а выбирает наиболее ценные. Даже при одинаковой утилизации, правильный порядок и выбор задач дают существенный экономический эффект.

Также был проведен тест с Uniform Priority (все задачи имеют одинаковый приоритет). Даже в этом случае аллокатор улучшил утилизацию с 76,8% до 87,5% и ценность на 23,1%. Это опровергает аргумент скептиков, что выигрыш достигается только за счет приоритизации. Сам факт планирования на горизонте (look-ahead planning) дает значительный прирост эффективности за счет лучшего использования пространства.

06Точность прогнозов: слабое звено цепи

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

• Обучение: Не является однородным процессом. Разница между полным дообучением (full fine-tuning) и методами типа LoRA может достигать 10 000 раз по количеству обучаемых параметров и 3 раза по памяти. Аллокатор использует специализированный прогнозист, учитывающий 22 признака, включая тип стратегии (SFT, DPO, RLHF) и техники.
• Квантование: Часто игнорируется как фоновая задача, но может занимать часы работы GPU. Для него создан отдельный прогнозист, учитывающий тип алгоритма (bitsandbytes, AWQ, GPTQ) и уровни калибровки.
• Инференс: Не оценивается по отдельным задачам. Вместо этого строится непрерывный профиль спроса на неделю, обновляемый на основе исторических данных трафика. Этот профиль заменяет статическую резервацию, позволяя аллокатору уверенно забирать GPU в периоды спада.

07Что это значит на практике

Для руководителей AI-инфраструктуры и MLOps-инженеров этот кейс несет несколько важных выводов:

1. Утилизация — это не цель, а средство. Высокая утилизация кластера сама по себе не означает эффективность. Если кластер на 100% загружен низкоприоритетными задачами, а критичный инференс страдает от задержек, это провал. Аллокатор Dharma-AI показывает, что можно одновременно повысить утилизацию И повысить ценность вывода.
2. Откажитесь от статической резервации. Резервирование GPU под пиковую нагрузку реального времени — это устаревшая практика, ведущая к огромным потерям. Переход к динамическому распределению на основе прогнозов спроса позволяет «освобождать» ресурсы в периоды спада и использовать их для пакетных задач.
3. Планирование на горизонте критично. Локальные решения (FIFO) не могут учесть глобальные ограничения (непрерывные блоки, приоритеты). Алгоритмы, которые видят всю очередь задач и планируют расписание наперед, дают существенный прирост эффективности даже без изменения приоритетов.
4. Интеграция прогнозов и оптимизации. Точность планировщика напрямую зависит от качества прогнозов. Инвестиции в специализированные модели оценки ресурсов для разных типов задач (обучение, квантование, инференс) окупятся многократно за счет роста утилизации.

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

Источник: Hugging Face ↗