Команда Dharma AI опубликовала в блоге Hugging Face детальное описание аллокатора GPU, который решает проблему утилизации кластеров без замены оборудования. На идентичных кластерах и одинаковых рабочих нагрузках новый планировщик показывает рост утилизации до 33 процентных пунктов, а приоритезированный выход (priority-weighted output) увеличивается в среднем на 52%, достигая 105% в отдельных сценариях.
Ключевые факты
| Параметр | Значение |
|---|---|
| Повышение утилизации GPU | до 33 п.п. (с 53.6% до 87.0% в сценарии с преобладанием обучения на 8 GPU) |
| Рост приоритезированного выхода | от 24.6% до 105.1%, в среднем 52% |
| Изменённый компонент | порядок принятия решений о распределении GPU по задачам и временным шагам |
| Сравнение с | FIFO-планировщиком с фиксированной резервацией под real-time инференс |
Проблема: две несовместимые формы аллокации
Авторы выделяют четыре типа рабочих нагрузок, конкурирующих за GPU: обучение, real-time инференс, пакетный инференс и квантизация. Первые три, а также квантизация, относятся к batch-like задачам: они требуют непрерывного блока GPU на всё время выполнения. Real-time инференс, напротив, эластичен — его потребность меняется от шага к шагу в зависимости от трафика.
Классический FIFO-планировщик с фиксированной резервацией под real-time инференс гарантирует доступность GPU в пике, но за это приходится платить: максимальная дневная потребность приложения резервируется на все 24 часа. Например, приложению, которому нужно 6 GPU в полдень и 2 GPU в 4 утра, выделяются 6 GPU на весь день. Четыре простаивающих GPU становятся недоступны для batch-задач. В сценариях, где доминирует резервация, базовая утилизация падает до 51.6—53.6%.
Вторая проблема — порядок размещения. При реальной конкуренции FIFO ставит задачи в порядке поступления, не учитывая их приоритет и не проверяя, какие задачи ещё должны уместиться в горизонте планирования. Высокоприоритетная работа ждёт за той, что пришла раньше, а ресурсы тратятся на размещения, которые блокируют последующие задачи.
Как устроен новый аллокатор
Constraint-aware аллокатор заменяет оба механизма. Real-time инференс обрабатывается как кривая спроса, а не как фиксированный потолок: выделение GPU меняется по временным шагам, а batch-like задачи занимают освободившиеся ресурсы впадин. Для batch-заタスク вводится глобальная приоритезация на всём горизонте планирования, а не в порядке поступления.
Формально задача сводится к бинарному выбору для каждой комбинации GPU, задачи и временного шага. Результат — сетка, где каждой ячейке (GPU × временной шаг) сопоставлена задача или пустота. Авторы подчёркивают, что решение касается не просто «занять GPU», а того, какая задача выполняется на каком GPU в каждый момент времени.
Результаты бенчмарков
В пяти сценариях с реальной конкуренцией утилизация выросла с диапазона 52—85% до 72—88%. Приоритезированная ценность увеличилась во всех сценариях. Самый сильный результат показал сценарий с преобладанием обучения на 8 GPU: утилизация поднялась с 53.6% до 87.0%, а выход более чем удвоился (+105%).
Особенно показателен тест на масштабируемость: 30 задач на 64 GPU. FIFO и аллокатор показали одинаковую утилизацию (44.9%) и пропускную способность (27 из 30 задач завершены). Однако аллокатор выдал на 15.9% больше приоритезированной ценности. Авторы отмечают, что дашборды, не учитывающие приоритеты, не отразят этой разницы.
Почему это важно
Для инженеров, управляющих кластерами GPU, статья предлагает не абстрактную теорию, а воспроизводимый подход: порядок аллокации — это не деталь реализации, а прямой фактор утилизации. FIFO-планировщики, особенно с фиксированной резервацией, неявно скрывают потери ресурсов, которые становятся заметны только при конкуренции. Аллокатор Dharma AI показывает, что на том же оборудовании можно получить до трети дополнительной вычислительной мощности без дополнительных инвестиций.
Ограничения и контекст
Статья описывает прототип и его бенчмарки. Авторы не раскрывают, как аллокатор поведёт себя на кластерах с тысячами GPU, с гетерогенными архитектурами или в условиях жёстких SLA. Кроме того, приоритеты — субъективная метрика, и её калибровка остаётся на усмотрение оператора. Результаты получены на симулированных и контролируемых сценариях; в production-среде могут потребоваться дополнительные механизмы устойчивости.
Источник: Hugging Face Blog — «Same Cluster, 33 Points More Utilization: What Changed Was the Order» (https://huggingface.co/blog/Dharma-AI/gpu-management-pt2)