На том же кластере +33 п.п. GPU: виноват порядок, а не железо

На одном кластере, без новых карт, утилизация GPU поднялась на 33 процентных пунктов — поменялся только порядок раздачи слотов между обучением, inference и batch-задачами. Dharma-AI сравнила планировщик с учётом ограничений и FIFO в семи сценариях на одинаковом железе: приоритетная ценность выросла в каждом, максимум +105%.

Где FIFO теряет половину пула

Обычный планировщик держит под real-time inference резерв на весь день по пиковому спросу. Приложению с шестью GPU в полдень и двумя в 4 утра FIFO выделяет шесть на сутки — четыре карты пустуют, но batch-обучение их не получит. В mixed control утилизация застревает на 51,6%, в training-heavy — на 53,6%.

Когда слоты кончаются, порядок постановки уже не «кто первый» — это решение о ёмкости. Высокоприоритетная работа ждёт за тем, кто пришёл раньше, а занятые GPU потом не перекладываются.

Как allocator выигрывает

Альтернатива читает спрос real-time по кривой, а не по суточному потолку, и вставляет batch-работы в провалы между пиками. Обучение, real-time inference, batch inference и квантизация бьются за одну сетку «GPU × timestep»; batch-задачи требуют непрерывного блока карт, inference эластичен по трафику.

На горячем пути эвристика отвечает за 1–2 мс — на 64 GPU и 30 задач это 15 мс, достаточно быстро для каждого входящего запроса. Полная оптимизация модели остаётся для периодического пересмотра, не для каждого API-вызова.

Три сценария из семи

• Training-heavy, 8 GPU: 53,6% → 87,0% утилизации, ценность +105,1%.
• Mixed control: 51,6% → 72,4%, ценность +54,8%.
• Scale test, 64 GPU: утилизация та же — 44,9%, но приоритетная ценность +15,9% при тех же 27 из 30 завершённых задач.

В scale test occupancy и throughput совпали у FIFO и allocator, а полезный выход — нет. Дашборд по загрузке GPU не показывает, чья работа внутри крутится.

Источник: Same Cluster, 33 Points More Utilization: What Changed Was the Order.