Същият клъстер, с 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 милисекунди в петте сценария с конкуренция и за 15 милисекунди при 64 GPU и 30 задачи — достатъчно бързо, за да се изпълнява при всяка входяща заявка.
Системата предлага два режима. Бързият режим изпълнява само разпределителя и връща неговата мрежа; това е горещият път. Пълният режим използва тази мрежа като начална точка за формалния модел, който се опитва да я подобри — подходящ за периодичен преглед, а не за решения при всяка заявка.
Резултати
| Сценарий | Използваемост | Стойност | Ръст на стойността | Латентност |
|---|---|---|---|---|
| Смесен контролен сценарий (8 GPU, 10 задачи) | 51,6% → 72,4% | 7 093 → 10 980 | +54,8% | 1 ms |
| Конкуренция в реално време (8 GPU, 8 задачи) | 75,0% → 80,2% | 3 233 → 4 029 | +24,6% | 1 ms |
| Преобладаващо обучение (8 GPU, 16 задачи) | 53,6% → 87,0% | 8 553 → 17 545 | +105,1% | 2 ms |
| Голям смесен сценарий (14 GPU, 16 задачи) | 76,8% → 82,7% | 13 977 → 20 101 | +43,8% | 2 ms |
| Свръхабониран сценарий (8 GPU, 9 задачи) | 85,4% → 87,5% | 4 311 → 5 760 | +33,6% | 1 ms |
| Тест за мащабиране (64 GPU, 30 задачи) | 44,9% → 44,9% | 44 233 → 51 248 | +15,9% | 15 ms |
| Еднакъв приоритет (14 GPU, 16 задачи) | 76,8% → 87,5% | 25 219 → 31 052 | +23,1% | 2 ms |
Използваемостта се подобри във всеки сценарий с изключение на един, в който остана напълно същата. Стойността се подобри и в седемте.
Тестът за мащабиране е важен, защото резултатът се запазва при този размер: 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 до 17 часа съществува единствено за да бъде взето решението за 9 часа от модел, който знае, че има бъдеще. Реалното разпределение за 10 часа идва от изпълнението в 10 часа, на базата на актуални данни.
Следствието е, че грешката в прогнозата се поема чрез повторна оптимизация, вместо да се натрупва. При всяко изпълнение се наследява това, което действително се изпълнява, и то се фиксира на място, така че последователните планове се обновяват, вместо да предизвикват хаотични промени.
Има и вторична полза. Планът за хоризонта сам по себе си е продукт за прогнозиране: той показва риска за покритието в реално време и предвидимите периоди на неактивност, преди да настъпят, което е полезно независимо дали конкретните разпределения някога ще бъдат ангажирани.
Именно затова съществува и теглото на времевия спад. До следващото изпълнение съставът на работното натоварване ще се е променил.
Към какво може да се обобщи това
Авиокомпаниите не решиха проблема с използваемостта чрез изчисляване на оптимален график. Те го решиха, като кодираха оперативната дисциплина в реда, в който се случват нещата — последователност на обслужването, прозорци за поддръжка, планиране на екипажите — и позволиха на тази дисциплина да се натрупва.
Същото се случи и тук. Тридесет и три пункта използваемост в най-натоварения сценарий и средно 52% повече резултат, претеглен спрямо приоритета, върху същия хардуер, със същите работни натоварвания, за няколко милисекунди — всичко това дойде от кодирането на физически допустимото за клъстера в реда, по който се вземат решенията. Структурата надделя над сложността.
В предишната статия твърдяхме, че специализацията и оркестрацията са двете половини на един проблем: специализацията намалява нуждите на всяко работно натоварване, а оркестрацията решава къде да отиде разликата. Нито един от двата лоста не носи полза самостоятелно. Ето как изглежда втората половина, когато е изградена.
GPU-тата вече бяха инсталирани, вече ангажирани, вече амортизиращи се. Ползата беше в начина, по който избрахме да ги използваме.
Допълнително четене
- Управление на GPU: защо неактивните GPU са новите приземени самолети
- По-нови модели, същото предимство
- Защо специализацията е неизбежна
- Специализацията надделява над мащаба: стратегическа променлива, която повечето решения за закупуване на ИИ пренебрегват
- Дегенерация на текста: производствен режим на отказ, който повечето бенчмаркове не проследяват
- Оптимизация на прякото предпочитание отвъд чатботовете
---
Разгледайте Dharma AI в Hugging Face , за да изпробвате интерактивните ни демонстрации, изтеглите моделите ни с отворен код и да откриете как специализираните ИИ системи превъзхождат универсалните модели в реални корпоративни приложения.
Модели, споменати в тази статия 1
Пространства, споменати в тази статия 1
Общност
· Регистрирайте се или влезте в профила си, за да коментирате
Модели, споменати в тази статия 1
Пространства, споменати в тази статия 1
Преведено автоматично от английски. Оригиналната статия е на връзката по-долу.