Если GPU не хватает, естественная реакция бизнеса проста: купить ещё. Бенчмарк Hugging Face показывает, почему сначала стоит проверить менее эффектную часть инфраструктуры, планировщик. В лучшем сценарии тот же кластер выполнил те же нагрузки, но его утилизация выросла на 33 процентных пункта только из-за другого порядка распределения задач.
Что именно переставили
В блоге Hugging Face описан constraint-aware allocator, который сравнили с FIFO-планировщиком в семи сценариях. Железо и набор нагрузок не менялись. За место на GPU конкурировали четыре типа заданий: обучение, real-time inference, batch inference и квантизация.
У них несовместимые требования. Обучению, batch inference и квантизации нужен непрерывный блок ускорителей на всё время выполнения. Real-time inference, напротив, эластичен: число нужных GPU меняется на каждом временном шаге вместе со спросом. Дополнительная сложность в том, что даже обучение одной базовой модели может занимать от нескольких часов до нескольких дней и требовать от одного GPU до десятков.
Базовый FIFO работал предсказуемо. Для real-time inference заранее резервировалась мощность по максимальному дневному спросу. Остальные задания размещались в порядке поступления, без учёта приоритета. Если приложению в пик нужны шесть GPU, а ночью два, все шесть оставались закреплены за ним круглые сутки. Четыре простаивающих ускорителя нельзя было отдать пакетной задаче.
Новый allocator изменил две вещи. Он стал считать real-time demand кривой, а не постоянным потолком: пакетные задания занимали провалы спроса, при этом число GPU, которые real-time задача могла менять между соседними временными шагами, было ограничено. Batch-like задания размещались по приоритету на всём горизонте планирования, а не по времени прихода.
Где взялись 33 пункта
Максимальный результат получился в training-heavy сценарии на восьми GPU. Утилизация выросла с 53,6% до 87,0%, а priority-weighted output увеличился на 105%. Иными словами, планировщик не только плотнее заполнил кластер, но и отдал мощность более ценным заданиям.
В пяти сценариях с реальной конкуренцией за ресурсы утилизация сдвинулась из диапазона 52–85% в диапазон 72–88%. Priority-weighted output вырос на 24,6–105,1%, в среднем на 52%. По данным Hugging Face, в этих пяти сценариях улучшились обе метрики одновременно.
Здесь важна граница результата. 33 пункта не являются обещанной прибавкой для любого GPU-кластера. Это лучший из измеренных сценариев, причём авторы отдельно отмечают, что цифра отражает одно базовое упорядочивание FIFO. Когда в кластере есть свободная мощность и все задания помещаются независимо от последовательности, порядок ничего не добавляет к утилизации. В одном scale-тесте на 30 заданиях и 64 GPU оба подхода показали одинаковые 44,9%.
То есть allocator не создаёт вычисления из воздуха. Он возвращает мощность, потерянную в двух местах: в резерве под короткий пик real-time inference и в неудачной последовательности крупных непрерывных задач. FIFO удобен, пока очередь не спорит за один и тот же ресурс. При дефиците порядок уже не административная мелочь, а часть доступной ёмкости.
Что это меняет для бизнеса
Перед заказом дополнительных ускорителей стоит провести контрольный эксперимент на собственной очереди. Зафиксировать один и тот же набор заданий и один горизонт планирования, затем сравнить текущую политику с двумя изменениями: динамическим размещением real-time нагрузки и приоритетной укладкой пакетных задач с учётом их длительности и размера.
Покупку GPU это не отменяет. Но бенчмарк Hugging Face делает закупку не первым, а вторым действием. Если кластер часами держит резерв под редкий пик, а приоритетное обучение ждёт за менее ценным заданием только потому, что пришло позже, дефицит железа может оказаться дефицитом планирования.
Конкретный маркер простой: сравните утилизацию и priority-weighted output на одном и том же trace очереди. Если после отказа от суточного пикового резерва и FIFO растут обе метрики, дополнительные GPU пока преждевременны. Если кластер и так работает без резервных провалов, а порядок не меняет заполнение, тогда проблема действительно в мощности, а не в очереди.