Тот же кластер, утилизация на 33 пункта выше: изменился порядок
Мы создали учитывающий ограничения распределитель GPU и сравнили его с планировщиком FIFO в семи тестовых сценариях. На идентичном оборудовании при выполнении идентичных задач утилизация GPU выросла максимум на 33 процентных пункта, а приоритетно-взвешенный результат вырос в каждом сценарии — максимум на 105%. Оборудование не менялось. Изменился порядок, в котором принимались решения о распределении.
Перед тем как перейти к цифрам, отметим один момент, связанный с измерениями. Каждый приведённый ниже показатель отражает улучшение относительно результата FIFO в том же сценарии. Утилизация указана в процентных пунктах, а ценность — как процентное увеличение приоритетно-взвешенного результата.
Решение в точной формулировке
«Поддерживать занятость GPU» — не решение, которое может выполнить система. Решение уже и гораздо сложнее: какой GPU запускает какую задачу, на каком временном шаге и с каким приоритетом. Формально это один бинарный выбор для каждой комбинации GPU, задачи и временного шага, а результатом становится сетка — каждый GPU на всём горизонте планирования, с названием задачи в каждой ячейке или без него.
За эту сетку конкурируют четыре типа рабочих нагрузок: обучение, инференс в реальном времени, пакетный инференс и квантование. Они делятся на две формы распределения, и именно в этом разделении заключается сложность. Обучение, пакетный инференс и квантование имеют пакетную природу: после запуска каждой задаче нужен непрерывный блок GPU, удерживаемый без прерываний до завершения. Инференс в реальном времени устроен противоположным образом: он эластичен и определяется кривой спроса, меняющейся на каждом временном шаге, увеличиваясь и уменьшаясь вместе с трафиком.
Две несовместимые формы, конкурирующие за одно и то же оборудование на одном и том же временном шаге, — основная проблема. Внутри одного типа есть и вторая неоднородность: для одной и той же базовой модели задачи обучения могут длиться от нескольких часов до нескольких дней и требовать от одного GPU до десятков.
Цена FIFO при конкуренции
Во всех сравнениях используется планировщик на основе FIFO: инференс в реальном времени обслуживается из фиксированного резерва, а все остальные задачи размещаются в порядке поступления, без учёта приоритета.
При определённых условиях это разумная политика. Когда в кластере есть запас мощности, порядок распределения ничего не стоит с точки зрения утилизации: при любой последовательности помещается всё, поэтому FIFO и любой более сложный подход заполняют одну и ту же долю пула. Именно конкуренция делает стоимость порядка видимой и начинает дополнительно отнимать ёмкость. В результате возникают две разные статьи затрат, и их стоит рассмотреть по очереди.
Резервирование. Инференс в реальном времени не может ждать появления мощности: GPU должны быть доступны в тот момент, когда они понадобятся трафику. Планировщик, размещающий задачи в порядке поступления, не умеет освобождать GPU во время спада и возвращать их перед следующим пиком. Поэтому единственный способ гарантировать доступность — взять максимальный дневной спрос каждого приложения реального времени и зарезервировать такое количество GPU на весь день. Цена этого решения оплачивается каждый час, кроме пикового. Приложение, которому в полдень нужны шесть GPU, а в 4 утра — два, удерживает все шесть в течение суток, и четыре простаивающих GPU недоступны пакетной задаче весь день. Они не используются, но и свободными не являются. Поэтому в двух сценариях, где доминирует резервирование, базовый показатель находится примерно на уровне половины кластера: 51,6% в смешанном контрольном сценарии и 53,6% в сценарии с преобладанием обучения. Примерно половина пула — причём значительная часть простаивающей половины зарезервирована, а не свободна. Эта цена возникает независимо от наличия конкуренции; конкуренция лишь делает её заметной.
Порядок. При реальной конкуренции то, какие задачи вообще удастся разместить, зависит от порядка их размещения, а не только от имеющейся ёмкости. Порядок — не правило разрешения ничьей, применяемое после решения вопроса о ёмкости. Порядок и есть решение о ёмкости. FIFO размещает каждую задачу по мере её поступления, не оценивая её ценность и не проверяя, что ещё должно поместиться в пределах горизонта. Поэтому высокоприоритетная работа ждёт позади той, что поступила первой, а ёмкость закрепляется в конфигурациях, которыми последующие задачи воспользоваться не могут.
Эти два фактора складываются. Блок, удерживаемый под максимальный дневной спрос реального времени, недоступен для любой пакетной задачи в очереди в любой час, а оставшаяся ёмкость распределяется в порядке случайного поступления запросов.
Это эквивалент GPU тому, как если бы авиакомпания выделяла самолёты первому позвонившему чартерному перевозчику, а затем обнаруживала, что лететь по действительно прибыльному маршруту уже не на чем. А GPU, зарезервированные на весь день ради пика продолжительностью в пару часов, — это буквально те самые самолёты, оставленные на земле из предыдущего материала: они стоят в режиме ожидания, ничего не зарабатывают и недоступны никому другому.
[Рисунок: расположенные рядом сетки распределения — распределитель сверху, FIFO снизу, один и тот же сценарий]
В пяти тестовых сценариях, созданных для настоящей конкуренции, распределитель улучшил оба показателя одновременно. Утилизация выросла с диапазона 52–85% до 72–88%. Приоритетно-взвешенная ценность увеличилась от 24,6% до 105,1%, в среднем на 52%. Каждый сценарий, оба показателя — и никаких компромиссов, которые пришлось бы объяснять.
Самым сильным отдельным результатом стал сценарий с преобладанием обучения на 8 GPU: утилизация выросла с 53,6% до 87,0%, а ценность более чем удвоилась, увеличившись на 105%. Тридцать три процентных пункта фиксированного, уже обесценивающегося актива были возвращены за счёт возврата зарезервированной мощности из режима ожидания и размещения остального в порядке приоритета. (Этот показатель отражает один вариант базового порядка.)
Распределитель устраняет оба этих поведения. Спрос в реальном времени рассматривается как кривая, а не как верхний предел: он распределяется в соответствии со спросом на каждом временном шаге, а пакетные задачи занимают периоды спада, при этом учитывается ограничение на число GPU, между которыми задача реального времени может переключаться на соседних временных шагах. Пакетные задачи размещаются по приоритету на всём горизонте, а не в порядке поступления. Ниже описано, как именно.
Утилизация необходима. Приоритет превращает её в ценность.
Утилизация измеряет занятость: какая доля доступного времени GPU выделена под какую-либо задачу. Она ничего не говорит о ценности этой задачи. Один сценарий полностью разделяет эти два показателя, причём разрыв направлен так, что его легко не заметить.
В масштабном тесте — 30 задач на 64 GPU — FIFO и распределитель показали идентичную утилизацию: по 44,9%, и идентичную пропускную способность: завершены 27 из 30 задач. При этом распределитель обеспечил на 15,9% больше приоритетно-взвешенной ценности. По всем панелям мониторинга показатели одинаковы. Фактически кластер выдал существенно разный результат.
Целевая функция, не учитывающая приоритет, может заполнить кластер ровно до того же уровня, завершить ровно столько же задач — и всё равно выдать меньше. В предыдущем материале утверждалось, что занятость плохо показывает, зарабатывает ли кластер; теперь это утверждение подтверждено измерениями.
Формализация задачи
Альтернатива — не более длинный список эвристических правил. Некоторые ограничения имеют смысл только глобально, и ни одно локальное правило не способно их выразить: непрерывные блоки, бюджет допустимого изменения состава GPU на всём горизонте, гарантия того, что выполняющаяся работа никогда не будет вытеснена. Чтобы соблюдать их, задачу необходимо сформулировать как единое целое.
Правомерное распределение определяется пятью ограничениями:
- Один GPU обслуживает не более одной задачи на каждом временном шаге.
- Каждая задача соблюдает диапазон своего спроса, а уже выполняющаяся работа наследуется и сохраняется.
- Пакетные задачи занимают непрерывные блоки GPU, размер которых является степенью двойки.
- Для задач реального времени существует жёсткое ограничение на число GPU, между которыми они могут переключаться на соседних временных шагах.
- Начатая задача не может быть прервана.
Целевая функция состоит из двух слагаемых. Выделение GPU под пакетную задачу приносит вознаграждение, равное её приоритету, умноженному на вес временного затухания. Невыполнение спроса реального времени влечёт штраф, пропорциональный размеру дефицита.
Относительный размер этих весов — это вся политика уровня обслуживания, выраженная одним числом. Вес штрафа за спрос реального времени в 5–10 раз больше веса распределения. Поэтому одна единица неудовлетворённого спроса реального времени стоит столько же, сколько 5–10 временных шагов GPU пакетной работы с тем же приоритетом. Такая асимметрия намеренна: она означает, что обязательства по задержке обеспечиваются внутри той же оптимизации, которая размещает пакетную работу, а не отдельным автомасштабированием, конкурирующим с планировщиком за те же GPU.
Именно это делает безопасным эластичный подход к спросу реального времени. Распределитель может передать GPU пакетной работе во время спада, поскольку последующее недообслуживание спроса реального времени оценивается гораздо дороже, чем заработок этой пакетной работы: доступность защищает штраф, а не статическое резервирование.
Вес времени затухает по мере продвижения по горизонту по причине, имеющей смысл только в онлайн-системе: к следующему запуску планировщика поступят новые задачи. Ёмкость, использованная сейчас, ценнее ёмкости, обещанной позже.
Распределитель, уже учитывающий ограничения
Формальная модель определяет, как выглядит правомерное распределение с хорошей оценкой. Обработка входящего запроса — отдельная задача, которой занимается отдельный компонент. Речь идёт о комбинаторном распределении NP-трудности, а планировщик запускается заново при каждом поступлении задачи, поэтому решение должно быть готово в промежутке между двумя API-запросами. Этот бюджет задержки — фиксированное ограничение, вокруг которого спроектирована архитектура. Поэтому на критическом пути используется эвристика, а формальная модель находится за ней и служит спецификацией, которой эвристика должна соответствовать.
Эта эвристика — не обычный жадный распределитель. Её правила и есть структурные ограничения формальной модели, а значит, каждая создаваемая ею сетка по конструкции является правомерным распределением. Не просто обычно корректным. Корректным по замыслу.
Именно применение такого подхода ко всему горизонту, а не к одному поступлению за раз, обеспечивает рост утилизации. Распределитель видит все задачи в очереди до размещения любой из них; он может сохранять свободный пул в формах, которые действительно сможет занять оставшаяся работа, так что пакетной задаче, которой нужен непрерывный блок определённого размера, всё ещё будет где разместиться, когда наступит её очередь. Приоритет определяет, кто первым получит доступ к этому месту. У FIFO нет ни одного из этих представлений: он закрепляет ёмкость за первой запросившей задачей, а поступившая позже задача, которой нужна конкретная форма размещения, может не найти подходящего места. Тогда она остаётся невыполненной, а GPU-часы, которые она потребила бы, остаются незатребованными.
В пяти сценариях с конкуренцией он работает за 1–2 миллисекунды, а при 64 GPU и 30 задачах — за 15 миллисекунд, то есть достаточно быстро, чтобы запускаться при каждом входящем запросе.
Система поддерживает два режима. Быстрый режим запускает только распределитель и возвращает его сетку; это критический путь. Полный режим использует эту сетку как начальную точку для формальной модели, которая пытается её улучшить; он подходит для периодического пересмотра, а не для принятия решений по каждому запросу.
Результаты
| Сценарий | Утилизация | Ценность | Рост ценности | Задержка |
|---|---|---|---|---|
| Смешанный контроль (8 GPU, 10 задач) | 51,6% → 72,4% | 7 093 → 10 980 | +54,8% | 1 мс |
| Конкуренция в реальном времени (8 GPU, 8 задач) | 75,0% → 80,2% | 3 233 → 4 029 | +24,6% | 1 мс |
| Преобладание обучения (8 GPU, 16 задач) | 53,6% → 87,0% | 8 553 → 17 545 | +105,1% | 2 мс |
| Крупный смешанный (14 GPU, 16 задач) | 76,8% → 82,7% | 13 977 → 20 101 | +43,8% | 2 мс |
| Переподписанный (8 GPU, 9 задач) | 85,4% → 87,5% | 4 311 → 5 760 | +33,6% | 1 мс |
| Масштабный тест (64 GPU, 30 задач) | 44,9% → 44,9% | 44 233 → 51 248 | +15,9% | 15 мс |
| Одинаковый приоритет (14 GPU, 16 задач) | 76,8% → 87,5% | 25 219 → 31 052 | +23,1% | 2 мс |
Утилизация улучшилась во всех сценариях, кроме одного, где показатели в точности сравнялись. Ценность выросла во всех семи.
Масштабный тест важен тем, что результат сохраняется при увеличении размера: 64 GPU, 30 задач, 15 миллисекунд, на 15,9% больше ценности.
Тест с одинаковым приоритетом важен, поскольку отвечает на очевидное скептическое возражение. Если назначить всем задачам одинаковый приоритет, так чтобы никакой сигнал приоритета не отличал их друг от друга, распределитель всё равно повышает утилизацию с 76,8% до 87,5%, а ценность — на 23,1%. Выигрыш не является исключительно следствием упорядочивания по приоритету. Само планирование размещения на всём горизонте тоже вносит вклад.
Ничего не сработает, если данные о спросе неверны
Всё изложенное выше предполагает, что планировщик знает, сколько GPU-часов требуется каждой задаче и каким будет трафик реального времени. И то и другое — прогнозы, а не входные данные, и качество планировщика не может быть выше их качества.
Один универсальный оценщик не работает, поскольку четыре типа рабочих нагрузок имеют качественно разные факторы стоимости. Здесь вновь проявляется аргумент в пользу специализации из предыдущего материала: та же логика, благодаря которой специализированная модель превосходит универсальную, применима к оценщикам, обеспечивающим планировщик данными.
Обучение — это не одна рабочая нагрузка. Оно меняется по двум независимым, свободно комбинируемым осям. Стратегия определяет, какая часть модели обновляется (полная тонкая настройка по сравнению с методами эффективной настройки параметров, такими как LoRA). Методика определяет целевую функцию оптимизации и цикл обучения (SFT, DPO, RLHF, RLVR, CPT). Различия незначительными не назовёшь: по сравнению с полной тонкой настройкой LoRA сокращает число обучаемых параметров до 10 000 раз, а объём памяти GPU — примерно в 3 раза, при использовании одной и той же базовой модели. DPO устраняет и модель вознаграждения, и цикл сэмплирования RLHF. Оценка только по размеру модели усредняет запуски, различающиеся на порядки по двум величинам, о которых принимает решение планировщик: длительности и числу GPU. Наш прогнозист обучения учитывает 22 признака, включая категориальную переменную, различающую 10 конкретных вариантов обучения.
Квантование — это планируемая задача, а не фоновая работа. Квантование одной крупной модели может потребовать много часов GPU-времени на оборудовании, которого ожидают другие задачи. Для него используется отдельный прогноз, построенный на уровнях калибровки по числу параметров, с отдельной обработкой каждого алгоритма (bitsandbytes, AWQ, GPTQ) и запасом надёжности перед округлением до целого числа GPU-часов. В предыдущих работах этой области квантование полностью исключалось из сферы планирования.
Инференс в реальном времени вообще не оценивается для каждой задачи. Вместо этого он прогнозируется как непрерывно перекалибруемый недельный профиль спроса, составленный на основе почасовой истории трафика и преобразованный в число GPU с учётом той же стоимости переключений, которую обеспечивает формальная модель. Поэтому прогноз и оптимизатор согласованы в вопросе стоимости изменений конфигурации, а не расходятся и не противодействуют друг другу. Именно этот прогноз заменяет пиковое резервирование. Кривая спроса для каждого временного шага — единственное, что позволяет планировщику уверенно освобождать GPU во время спада, зная, что их можно вернуть перед следующим пиком.
Это возвращает нас к аргументу о порядке. Именно более точные оценки спроса делают возможным приоритетное размещение: невозможно хорошо упорядочить задачи, не зная, сколько ресурсов они потребят.
Оптимизировать день, фиксировать час
Очевидное возражение против всего этого заключается в том, что прогнозы ошибаются. Что происходит тогда?
Нежелательный сценарий имеет название, которое стоит позаимствовать: эффект конца света. Оптимизатор, не видящий за пределы своего горизонта, принимает текущие решения, разрушающие временные шаги сразу за его границами, поскольку с точки зрения модели после окончания горизонта ничего не существует.
Архитектура отвечает на обе проблемы одновременно. Планировщик оптимизирует горизонт в 24 часа, но фиксирует только текущий временной шаг и перезапускается каждые 30–60 минут. При запуске в 9 утра распределение на 9 утра становится реальным; план с 10 утра до 5 вечера существует лишь для того, чтобы решение на 9 утра принималось моделью, знающей о существовании будущего. Реальное распределение на 10 утра будет получено во время запуска в 10 утра на основе свежих данных.
В результате ошибка прогноза поглощается повторной оптимизацией, а не накапливается. Каждый запуск наследует то, что действительно выполняется, и фиксирует это на месте, поэтому последующие планы обновляются, а не хаотично меняются.
Есть и дополнительный эффект. План на горизонте сам по себе является продуктом прогнозирования: он заранее выявляет риск покрытия запросов реального времени и предсказуемые окна простоя, что полезно независимо от того, будут ли конкретные распределения когда-либо зафиксированы.
Именно поэтому существует вес временного затухания. К следующему запуску состав рабочей нагрузки изменится.
К чему это можно обобщить
Авиакомпании не добились оптимальной утилизации, вычисляя идеальное расписание. Они добились её, встроив операционную дисциплину в порядок происходящих событий (последовательность разворота самолёта, окна технического обслуживания, составление расписаний экипажей) и позволив этой дисциплине накапливать эффект.
Здесь произошло то же самое. Тридцать три процентных пункта утилизации в самом сложном сценарии с плотной загрузкой и в среднем на 52% больше приоритетно-взвешенного результата — на том же оборудовании, с теми же рабочими нагрузками, за пару миллисекунд — стали результатом кодирования физических возможностей кластера в порядок принятия решений. Структура победила изощрённость.
В предыдущем материале утверждалось, что специализация и оркестрация — две половины одной задачи: специализация уменьшает потребности каждой рабочей нагрузки, а оркестрация решает, куда направить полученную разницу. Ни один из рычагов не окупается сам по себе. Вот как выглядит вторая половина, когда она действительно построена.
GPU уже были установлены, уже задействованы и уже обесценивались. Выигрыш заключался в том, как мы решили ими распорядиться.
Дополнительные материалы
- Управление GPU: почему простаивающие GPU — это новые самолёты на земле
- Более новые модели, то же преимущество
- Почему специализация неизбежна
- Специализация превосходит масштаб: стратегическая переменная, которую упускает большинство решений о закупке ИИ
- Деградация текста: производственная проблема, которую не отслеживает большинство бенчмарков
- Прямая оптимизация предпочтений за пределами чат-ботов
---
Изучите Dharma AI на Hugging Face, чтобы попробовать наши интерактивные демонстрации, скачать наши модели с открытым исходным кодом и узнать, как специализированные системы ИИ превосходят универсальные модели в реальных корпоративных приложениях.
Модели, упомянутые в этой статье 1
Пространства, упомянутые в этой статье 1
Сообщество
· Зарегистрируйтесь или войдите, чтобы оставить комментарий
Модели, упомянутые в этой статье 1
Пространства, упомянутые в этой статье 1
Переведено автоматически с английского. Оригинал статьи — по ссылке ниже.