Инженеры Dharma-AI опубликовали продолжение исследования об управлении GPU-кластерами. В прошлой заметке они утверждали, что утилизация, а не «интеллект» модели, становится главным ограничением корпоративного ИИ. Теперь команда представила собственный планировщик, учитывающий ограничения кластера, и сравнила его с классическим FIFO на семи бенчмарках. На одинаковом железе и одинаковых нагрузках загрузка GPU выросла на величину до 33 процентных пунктов, а приоритезированная ценность вывода — до 105%.
Ключевой вывод: дело не в железе, а в порядке принятия решений о размещении задач.
Почему FIFO теряет до половины кластера
«Держать GPU занятыми» — это не команда, которую может выполнить система. Решение, которое она принимает, уже и сложнее: какой GPU запустит какую задачу, в какой момент времени и с каким приоритетом. Формально это один бинарный выбор на каждую комбинацию GPU, задачи и временного шага.
С конкуренцией за ресурсы сталкиваются четыре типа нагрузок: обучение, инференс в реальном времени, пакетный инференс и квантование. Первые три — пакетные: им нужен непрерывный блок GPU до завершения. Инференс в реальном времени, наоборот, эластичен и меняется каждый шаг. Две несовместимые формы конкурируют за одно железо — в этом суть проблемы.
FIFO-планировщик, с которым сравнивали новый аллокатор, работает так: инференсу выделяется фиксированный резерв, остальные задачи встают в очередь по мере поступления. Когда в кластере есть запас, такой порядок ничего не стоит. Но при конкуренции он обходится дорого в двух местах:
- Резерв. Чтобы гарантировать доступность инференса в пик, планировщик резервирует максимум суточной потребности на весь день. Приложению, которому нужно шесть GPU в полдень и два в четыре утра, выделяется шесть на 24 часа. Четыре простаивающих GPU недоступны пакетным задачам весь день.
- Порядок. При реальной конкуренции то, какие задачи вообще поместятся, зависит не от объёма мощности, а от последовательности размещения. FIFO ставит задачу по мере поступления, не взвешивая её ценность и не проверяя, что ещё должно поместиться в горизонте планирования.
Эти два эффекта складываются. В сценариях, где доминирует резервирование, базовая загрузка падает примерно до половины кластера: 51,6% в смешанном контрольном и 53,6% в сценарии с упором на обучение.
Что изменил новый аллокатор
Dharma-AI формализовали задачу: пять ограничений определяют допустимое размещение — GPU обслуживает не более одной задачи за шаг; каждая задача соблюдает свой диапазон спроса; пакетные задачи занимают непрерывные блоки GPU размером в степень двойки; у задач реального времени есть жёсткий лимит на смену GPU между шагами; начатая задача не прерывается.
Целевая функция состоит из двух слагаемых: выделение GPU пакетной задаче приносит награду, равную её приоритету, умноженному на вес с затуханием во времени; невыполнение спроса реального времени влечёт штраф, пропорциональный размеру дефицита. Вес штрафа в 5–10 раз больше веса награды: одна единица неудовлетворённого спроса реального времени стоит как 5–10 GPU-шагов пакетной работы равного приоритета. Это осознанная асимметрия: обязательства по задержке обеспечиваются внутри той же оптимизации, а не отдельным автозамасштабированием.
Аллокатор — не «жадный» эвристический планировщик. Его правила — это структурные ограничения формальной модели, поэтому каждое создаваемое размещение допустимо по построению. Он видит все задачи в очереди до размещения любой из них, удерживает свободный пул в формах, которые может занять оставшаяся работа, и отдаёт приоритет первым. FIFO не видит ни того ни другого. Такой подход к планированию размещения задач на GPU-кластере дополняет запуск 2.4T-параметрической модели на GB300 NVL72, где вопросы эффективного использования GPU становятся ещё острее.
На пяти сценариях с конкуренцией утилизация выросла с диапазона 52–85% до 72–88%. Приоритезированная ценность выросла на 24,6–105,1%, в среднем на 52%. Сильнейший результат — в сценарии с упором на обучение на 8 GPU: загрузка поднялась с 53,6% до 87,0%, ценность более чем удвоилась (+105%).
Утилизация и приоритет — разные вещи
Утилизация измеряет занятость, но не ценность работы. Масштабный тест это разделяет полностью: 30 задач на 64 GPU, FIFO и аллокатор дали одинаковую загрузку — 44,9% — и одинаковую пропускную способность: 27 из 30 задач завершены. При этом аллокатор дал на 15,9% больше приоритезированной ценности. Дашборды показывают одно и то же, а кластер произвёл разный результат.
Тест с одинаковыми приоритетами отвечает на скептический вопрос: если переопределить все задачи на идентичный приоритет, аллокатор всё равно поднимает загрузку с 76,8% до 87,5%, а ценность — на 23,1%. Выигрыш не сводится к сортировке по приоритету: планирование размещений на всём горизонте вносит самостоятельный вклад.
Точность прогнозов спроса
Планировщик работает, только если знает, сколько GPU-часов нужно каждой задаче и какой трафик реального времени ожидается. Оба параметра — прогнозы, а не входные данные. Универсальный оценщик не подходит: у четырёх типов нагрузок качественно разные драйверы затрат.
Обучение неоднородно: стратегия (полный файнтюнинг против LoRA) и техника (SFT, DPO, RLHF, RLVR, CPT) комбинируются независимо. LoRA сокращает обучаемые параметры до 10 000 раз, а память GPU — примерно в 3 раза. Оценка по размеру модели усредняет прогоны, различающиеся на порядки. Прогнозатор обучения Dharma-AI использует 22 признака, включая категориальную переменную для 10 конкретных вариантов обучения.
Квантование — планируемая задача, а не фоновая работа: квантование одной большой модели может занять часы GPU-времени. Для него строится отдельный прогноз по калибровочным уровням в зависимости от числа параметров, с учётом алгоритмов (bitsandbytes, AWQ, GPTQ) и запасом до округления до целых GPU-часов.
Инференс реального времени оценивается не по задачам, а как непрерывно перекалибруемый недельный профиль спроса на основе почасовой истории трафика. Профиль сопоставляется с числом GPU с учётом той же стоимости смены, которую enforce формальная модель. Именно этот прогноз заменяет пиковое резервирование.
Горизонт в сутки, решение — на текущий шаг
Прогнозы ошибаются, и архитектура это учитывает. Планировщик оптимизирует 24-часовой горизонт, но фиксирует только текущий шаг и перезапускается каждые 30–60 минут. Запуск в 9:00 даёт реальное размещение на 9:00; план на 10:00–17:00 существует только для того, чтобы решение на 9:00 принимала модель, знающая, что будущее существует. Реальное размещение на 10:00 придёт из запуска в 10:00 со свежими данными.
Ошибка прогноза поглощается повторной оптимизацией, а не накапливается. Каждый запуск наследует фактически выполняющиеся задачи и закрепляет их, поэтому последовательные планы обновляются, а не «дёргаются». Побочный эффект: план горизонта сам по себе — прогнозный продукт, показывающий риски покрытия реального времени и предсказуемые окна простоя до их наступления.
Технические характеристики: аллокатор отрабатывает за 1–2 мс на пяти сценариях с конкуренцией и за 15 мс на 64 GPU и 30 задач. Система имеет два режима: быстрый — только аллокатор, возвращающий сетку размещения (горячий путь); полный — использует эту сетку как отправную точку для формальной модели, которая пытается её улучшить (подходит для периодического пересмотра, а не для решений на каждый запрос). Для сравнения: модель Needle 2 с 45M параметров умещается в бинарник 14 МБ и может работать на скромном железе, что снижает потребность в больших GPU-кластерах.
Частые вопросы
Что именно изменилось в кластере, если железо то же?
Изменился порядок принятия решений о размещении задач. Вместо обслуживания в порядке поступления аллокатор видит все задачи в очереди, планирует их на всём горизонте и удерживает свободный пул в формах, которые может занять оставшаяся работа.
Какой выигрыш даёт новый планировщик на практике?
В семи бенчмарках приоритезированная ценность вывода выросла во всех сценариях — от 15,9% до 105,1%. Загрузка GPU выросла в шести из семи сценариев: до 33 процентных пунктов в самом плотном случае.
Почему FIFO-планировщик плох при конкуренции?
Он резервирует максимум суточной потребности инференса на весь день, оставляя простаивающие GPU недоступными для пакетных задач, и размещает задачи в порядке поступления, не учитывая их ценность и будущие потребности. При дефиците ресурсов порядок размещения становится решением о ёмкости.
Всегда ли утилизация — хороший показатель эффективности кластера?
Нет. В масштабном тесте FIFO и аллокатор дали одинаковую загрузку и пропускную способность, но аллокатор — на 15,9% больше приоритезированной ценности. Утилизация не отражает ценность выполненной работы.
Что будет, если прогнозы спроса окажутся неверными?
Ошибка поглощается повторной оптимизацией: планировщик перезапускается каждые 30–60 минут, фиксирует только текущий шаг и пересчитывает план на основе свежих данных. Предсказанные размещения на будущее служат лишь контекстом для текущего решения.
Можно ли применить этот подход без смены оборудования?
Да, в этом суть подхода: 33 процентных пункта загрузки в самом плотном сценарии получены на том же железе и тех же нагрузках. Изменение — в порядке принятия решений, а не в мощности.
Насколько быстро работает аллокатор?
На сценариях с конкуренцией — 1–2 мс, на 64 GPU и 30 задач — 15 мс. Этого достаточно, чтобы запускать планировщик на каждый входящий запрос.
Чем этот планировщик отличается от обычного «жадного» аллокатора?
Его правила — это структурные ограничения формальной модели, поэтому каждое создаваемое размещение допустимо по построению, а не «обычно допустимо». Он планирует размещения на всём горизонте, а не по одному прибытию за раз.
Источник: huggingface.co