Той самий кластер, на 33 пункти вища утилізація: змінився порядок
Ми створили розподілювач GPU, що враховує обмеження, і порівняли його з планувальником FIFO у семи тестових сценаріях. На ідентичному обладнанні, під час виконання ідентичних робочих навантажень, використання GPU зросло максимум на 33 відсоткові пункти, а пріоритетно зважений результат зріс у кожному з них — максимум на 105%. Обладнання не змінювалося. Змінився порядок, у якому ухвалюються рішення про розподіл.
Перед тим як перейти до цифр, варто зробити одне зауваження щодо вимірювання. Кожен наведений нижче показник приросту виражено як покращення порівняно з результатом FIFO у тому самому сценарії. Використання наведено у відсоткових пунктах; цінність — як відсоткове зростання пріоритетно зваженого результату.
Рішення, сформульоване точно
«Підтримувати GPU зайнятими» — це не рішення, яке система може виконати. Рішення є вужчим і значно складнішим: який GPU запускає яке завдання, на якому часовому кроці та з яким пріоритетом. Формально це один бінарний вибір для кожної комбінації GPU, завдання й часового кроку, а результатом є сітка — кожен GPU протягом усього горизонту планування, із назвою завдання в кожній клітинці або без неї.
За цю сітку конкурують чотири типи робочих навантажень: навчання, обробка запитів у реальному часі, пакетна обробка запитів і квантизація. Вони поділяються на дві форми розподілу, і саме в цьому поділі полягає складність. Навчання, пакетна обробка запитів і квантизація мають пакетний характер: після запуску кожному з них потрібен безперервний блок GPU, утримуваний без переривань до завершення завдання. Обробка запитів у реальному часі — протилежна: вона еластична й керується кривою попиту, яка змінюється на кожному часовому кроці, зростаючи та скорочуючись разом із трафіком.
Конкуренція двох несумісних форм за те саме обладнання на тому самому часовому кроці — основна проблема. Друга неоднорідність виникає всередині одного типу: для тієї самої базової моделі завдання навчання можуть тривати від кількох годин до кількох днів і потребувати від одного GPU до десятків.
Ціна FIFO в умовах конкуренції
Точкою порівняння є планувальник на основі FIFO: обробка запитів у реальному часі здійснюється з фіксованої резервної потужності, а всі інші завдання розміщуються в порядку надходження, без урахування пріоритету.
За відповідних умов це розумна політика. Коли в кластері є запас потужності, порядок розподілу нічого не коштує з погляду використання: усе поміщається незалежно від послідовності, тому FIFO та будь-який складніший підхід заповнюють однакову частку пулу. Саме конкуренція перетворює непомітну вартість порядку на втрату потужності. Тоді це стає дорогим у двох окремих аспектах, і їх варто розглянути по черзі.
Резервування. Обробка запитів у реальному часі не може чекати на потужність; GPU мають бути доступними в момент, коли вони потрібні через трафік. Планувальник, який розміщує завдання в порядку надходження, не має механізму звільняти GPU під час спаду та повертати їх до наступного піку, тому єдиний спосіб гарантувати доступність — взяти максимальний денний попит кожного застосунку реального часу й зарезервувати таку кількість GPU на весь день. Ціна цього сплачується щогодини, коли не спостерігається пік. Застосунок, якому опівдні потрібно шість GPU, а о 4-й ранку — два, утримує всі шість протягом 24 годин, і чотири невикористовувані 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 — приблизно втричі порівняно з повним донавчанням на тій самій базовій моделі. DPO усуває і модель винагороди, і цикл вибірки RLHF. Оцінювання лише за розміром моделі усереднює запуски, що відрізняються на порядки за двома показниками, які визначає планувальник: тривалістю та кількістю GPU. Наш прогнозувальник навчання використовує 22 ознаки, зокрема категоріальну змінну, яка розрізняє 10 конкретних варіантів навчання.
Квантизація — це завдання, яке можна планувати, а не фонова робота. Квантизація однієї великої моделі може споживати години GPU-часу на обладнанні, на яке очікують інші завдання. Для неї використовується окремий прогноз, побудований на рівнях калібрування за кількістю параметрів, з окремою обробкою кожного алгоритму (bitsandbytes, AWQ, GPTQ) і запасом безпеки перед округленням до цілих GPU-годин. У попередніх роботах у цій галузі квантизацію взагалі виводили за межі планування.
Обробка запитів у реальному часі взагалі не оцінюється для кожного завдання. Вона прогнозується як безперервно переналаштовуваний тижневий профіль попиту, побудований з історії погодинного трафіку та перетворений на кількість GPU з урахуванням тієї самої вартості перемикань, яку забезпечує формальна модель. Отже, прогноз і оптимізатор узгоджені щодо вартості зміни GPU, а не суперечать один одному й не борються між собою. Саме цей прогноз замінює пікове резервування. Крива попиту для кожного часового кроку — єдина річ, яка дає змогу планувальнику звільняти GPU під час спаду з достатньою впевненістю, що їх можна буде повернути до наступного піку.
Це повертає нас до аргументу про порядок. Саме точніші оцінки попиту роблять можливим розміщення з урахуванням пріоритету; неможливо добре впорядкувати завдання, не знаючи, що саме вони споживатимуть.
Оптимізувати день, фіксувати годину
Очевидне заперечення всього цього полягає в тому, що прогнози помилкові. Що тоді відбувається?
Режим збою, якого слід уникати, має назву, яку варто запозичити: ефект кінця світу. Оптимізатор, який не бачить за межі свого горизонту, ухвалює поточні рішення, що руйнують часові кроки безпосередньо за його межами, оскільки, з погляду моделі, після завершення горизонту нічого не існує.
Архітектура відповідає на обидві проблеми одночасно. Планувальник оптимізує 24-годинний горизонт, але фіксує лише поточний часовий крок і запускається знову кожні 30–60 хвилин. Якщо запуск відбувається о 9:00, розподіл на 9:00 є реальним; план із 10:00 до 17:00 існує лише для того, щоб рішення на 9:00 ухвалювала модель, яка знає про існування майбутнього. Реальний розподіл на 10:00 буде отримано під час запуску о 10:00 на основі свіжих даних.
У результаті похибка прогнозу поглинається повторною оптимізацією, а не накопичується. Кожен запуск успадковує те, що фактично працює, і закріплює це, тому наступні плани оновлюються, а не спричиняють хаотичних перемикань.
Є й додаткова перевага. План на весь горизонт сам є продуктом прогнозування: він завчасно виявляє ризик покриття потреб реального часу та передбачувані періоди простою, що корисно незалежно від того, чи буде колись зафіксовано саме цей розподіл.
Саме тому існує вага часового спадання. До наступного запуску склад робочого навантаження зміниться.
До чого це узагальнюється
Авіакомпанії не розв’язали проблему використання, обчисливши оптимальний розклад. Вони розв’язали її, закодувавши операційну дисципліну в порядок виконання дій (послідовність підготовки літака до наступного рейсу, вікна технічного обслуговування, планування роботи екіпажів) і дозволивши цій дисципліні накопичувати ефект.
Те саме сталося тут. Тридцять три пункти використання у сценарії з найщільнішим завантаженням і в середньому на 52% більший пріоритетно зважений результат — на тому самому обладнанні, з тими самими робочими навантаженнями, за кілька мілісекунд — стали можливими завдяки кодуванню фізично дозволеного кластером у порядок ухвалення рішень. Структура перемогла складність.
У попередньому матеріалі стверджувалося, що спеціалізація та оркестрація — це дві половини однієї проблеми: спеціалізація зменшує потреби кожного робочого навантаження, а оркестрація визначає, куди спрямувати різницю. Жоден важіль не працює сам по собі. Ось як виглядає друга половина, коли її реалізовано.
GPU вже були встановлені, уже задіяні й уже втрачали вартість. Виграш полягав у тому, як ми вирішили їх використати.
Додаткові матеріали
- Керування GPU: чому простоюючі GPU — це нові літаки на землі
- Новіші моделі, та сама перевага
- Чому спеціалізація неминуча
- Спеціалізація перемагає масштаб: стратегічна змінна, яку не враховує більшість рішень щодо закупівель ШІ
- Деградація тексту: виробничий режим збою, який не відстежує більшість тестів
- Пряма оптимізація за вподобаннями за межами чатботів
---
Відвідайте Dharma AI на Hugging Face, щоб випробувати наші інтерактивні демонстрації, завантажити наші моделі з відкритим кодом і дізнатися, як спеціалізовані системи ШІ перевершують універсальні моделі в реальних корпоративних застосунках.
Моделі, згадані в цій статті 1
Простори, згадані в цій статті 1
Спільнота
· Зареєструйтеся або увійдіть, щоб залишити коментар
Моделі, згадані в цій статті 1
Простори, згадані в цій статті 1
Перекладено автоматично з англійської. Оригінал статті — за посиланням нижче.