Бірнеше командаға әділ GPU кезегі керек пе?

Бірнеше команда бір GPU-ларды немесе сыртқы API-лардың ортақ жиынтығын пайдаланса, мәселе көбіне кезек мәселесі сияқты көрінбейді. Әуелі ол шағым түрінде байқалады: чат кенеттен бір минут жауап береді, түнгі есеп таңға дейін аяқталмайды, провайдер жағында 429 қателері пайда болады, ал ештеңе өзгертпеген команда өз сервисінің неге баяулағанын сұрайды.

Әдетте себеп қарапайым. Барлық тапсырма бір кезекте тұрады, ал жоспарлаушы оларды бірдей деп санайды. Бірақ бір құжатты жіктеу сұрауы, ұзақ жауап генерациясы, модельді қосымша оқыту және бағалауды жаппай іске қосу уақыт, жад және пайдаланылатын үдеткіштер саны жағынан бірдей емес. Әділ GPU кезегі алгоритм таңдаудан басталмайды. Ол нақты нені бөлісіп отырғаныңызды дұрыс анықтаудан басталады.

FIFO интерактивті сервисті пакет жұмысына тәуелді етеді

FIFO тапсырмаларды келіп түскен ретімен өңдейді. Алгоритм түсінікті, іске асыруы жеңіл және қысқа жұмыстың бір түріне әбден жарайды. Аралас жүктемеде ол көп адам елемей кететін бір ғана кепілдік береді: кім бұрын келсе, тапсырманың көлемі мен иесіне қарамастан, ресурсқа бұрын ие болады.

Сегіз GPU слоты бар бір кезекті елестетіңіз. Аналитика командасы 09:00-де бағалауға арналған 400 тапсырманы қояды. Әр тапсырма ұзақ жауап жасап, слотты бірнеше минут ұстайды. 09:03-те өнім командасы ассистентке пайдаланушы сұрауларын қабылдай бастайды. Олардың сұраулары бірнеше секундқа ғана созылады, бірақ бағалау тапсырмаларының артында тұрады. Үдеткіштер 70 пайызға ғана жүктелуі мүмкін, ал пайдаланушы жолы іс жүзінде қолжетімсіз болып қалады.

Бұл FIFO қатесі емес. Бұл FIFO-дан күтілетін нәрсені дұрыс түсінбеу. Кезек келу ретін сақтайды, бірақ мыналарды ажыратпайды:

• қысқа және ұзақ жұмысты;
• адам дәл қазір күтіп отырған сұрау мен фондық есептеуді;
• бір тапсырма мен мың тапсырмадан тұратын топтаманы;
• бір команданың жұмысын және қалғандарының жүктемесін.

Көп қадамды тапсырмаларда FIFO әсіресе нашар жұмыс істейді. Егер бір диспетчер batch тапсырмасына төрт слот берсе, ол кезекте ондаған қысқа интерактивті сұрау жиналып қалса да, ұзақ кезең аяқталғанша слоттарды ұстап тұруы мүмкін. GPU санын көбейту кейде көмектеседі, бірақ қызмет көрсету ретін өзгертпейді. Келесі жаппай іске қосуда қымбатырақ кластерде дәл сондай жағдай қайталанады.

Дегенмен FIFO-ның өз орны бар. Оны тапсырмалар құны алдын ала белгілі бір тар класс ішінде, мысалы бір сервистің қысқа операцияларында қалдыруға болады. Бірақ оны ортақ пулдың жаһандық саясатына айналдырмаңыз.

Қатаң приоритет шұғыл жұмысты қорғайды, бірақ басқаларды оңай аш қалдырады

Қатаң приоритетті кезек әрдайым ең жоғары, бос емес кластан жұмыс алады. Ол кідіртуге болмайтын жолды жақсы қорғайды: қолжетімділікті тексеру, жұмысты тоқтату, инцидентті өңдеу, белсенді диалогтағы адам сұрауы. Бірақ дәл осы кезек «шұғыл» белгісі үшін жасырын күрестің көзіне тез айналады.

P0 класы уақыттың көп бөлігінде бос болмаса, P1 ресурс ала алмайды. P1 үнемі бос болмаса, batch класы шексіз күтуі мүмкін. Бұл starvation деп аталады. Нақты жүйеде ол шексіз күту сияқты емес, иелері кезекке сенуден қалғандықтан қолмен басталып, кейін тоқтатылатын тапсырмалар сияқты көрінеді.

«Әр сервиске жеке приоритет берейік» деген танымал кеңес саясаттың мүлде болмағанынан да жаман. Бірнеше айдан кейін дерлік әр сервис жоғары класқа ие болады, өйткені оның иесі кідірісін маңызды деп атай алады. Барлығы жоғары приоритетті болса, ешкім қорғалмайды.

Қатаң приоритеттерді кідіріс шынымен әділдіктен маңыздырақ болатын аз ғана жағдайға қалдырыңыз. Әр осындай класс үшін үш шектеу қойыңыз:

1. Шұғыл жұмыс бүкіл пулды жеп қоймас үшін қатар орындалу лимиті.
2. Ескірген тапсырмалар жиналмас үшін кезек ұзындығына немесе күту уақытына шек.
3. Сұраудағы бір өрісті өзгерту арқылы айналып өтуге болмайтын рұқсат ережесі.

Приоритет «кімді кідіртуге болмайды?» деген сұраққа жауап береді. Ол «қалған сыйымдылықты қалай әділ бөлеміз?» деген сұраққа жауап бермейді.

Weighted fair queuing пайдаланылған сыйымдылықты бөледі, бірақ бірдей кідіріске уәде бермейді

Weighted fair queuing, немесе WFQ, бөлек жұмыс ағындарын ұстап, оларға салмақтарына пропорционал қызмет көрсетеді. Егер A командасының салмағы 4, ал B командасының салмағы 2 болса, тұрақты жүктеме кезінде A қызмет көрсетілген құнның шамамен екі есесін алуы керек. Мұнда әңгіме кезектегі хабарлар саны туралы емес, дәл осы құн туралы.

Kubernetes API Priority and Fairness құжаттамасы API server сұраулары үшін ұқсас идеяны сипаттайды: әртүрлі приоритет деңгейлері қатар орындалуға бөлек шектер алады, ал деңгей ішіндегі fair queuing бір ағынның басқаларын ығыстыруына жол бермейді. Сол жерде өзін нашар ұстайтын, серверге сұрауларды толтыра беретін клиент мәселесі де бөлек көрсетілген. Бұл пайдалы мысал, себебі кезек әдемі математика үшін емес, ортақ ресурсты пайдаланатын көршілерді оқшаулау үшін құрылады.

Linux жүйесіндегі fq дисциплинасы да ағындарды бөліп, оларды раундтармен өңдейді және квант қолданады. Квант дегеніміз ағынның бір раундта бере алатын жұмыс көлемі. Квант үлкен болса, басқа ағындар келесі мүмкіндікті ұзақ күтеді. GPU мен API үшін бұл тікелей ескерту: бір кезекке бірден тым үлкен жұмыс бөлігін берсеңіз, формалды түрде әділ алгоритм интерактивті кідірісті қайтадан нашарлатады.

WFQ барлық сұрау бірдей уақытта аяқталады деп уәде бермейді. Ұзақ тапсырма қысқадан бәрібір ұзақ орындалады. Оның уәдесі басқа: бірнеше ағын белсенді кезде бір ағын қолжетімді үлестің бәрін шексіз иелене алмайды.

Іс жүзінде есептеу жоспарлаушыларында WFQ жуықтауы қолданылады. Әр ағын үшін келесі тапсырманың виртуалды аяқталу уақыты сақталады:

finish = max(flow_finish, virtual_time) + estimated_cost / weight

Диспетчер finish мәні ең кіші тапсырманы таңдайды. Тапсырма берілгеннен кейін flow_finish пен жалпы виртуалды уақытты жаңартады. Пакеттердің мінсіз желісін модельдеудің қажеті жоқ. Бір формуланы дәйекті қолданыңыз, күйді атомарлы сақтаңыз және бір жіберушінің әр сұрау үшін жаңа ағын құруына жол бермеңіз.

Сұрауларды емес, құнды есептесеңіз ғана әділдік сақталады

Екі сұраудың HTTP көлемі бірдей болғанымен, құны мүлде бөлек болуы мүмкін. Бірі қысқа мәтіннен екі өрісті шығаруды сұрайды. Екіншісі ұзақ контекст беріп, толық жауапты талап етеді, бірнеше құралды іске қосады және қате болғанда шақыруды қайталайды. Екеуі де «бір сұрау» деп есептелсе, ауыр жұмыс артықшылық алады.

GPU үшін ыңғайлы өлшем мынадай болуы мүмкін:

құн = пайдаланылған_слоттар * өлшенген_секундтар + жад_үшін_айыппұл

LLM inference үшін алдын ала бағалау әдетте іске қосылғанға дейін жасалады:

estimated_cost = input_tokens + 2 * max_output_tokens

Шығыс токендерінің алдындағы коэффициент модель мен режимге байланысты. Оны физикалық тұрақты деп санауға болмайды. Аяқталған сұраулар журналын алып, болжамды уақытты нақты уақытпен салыстырыңыз және коэффициенттерді үнемі өзгертіңіз. Жиын көлемі мен генерация параметрлері белгілі batch тапсырмаларында бағалау еркін пайдаланушы мәтініне қарағанда дәлірек болады.

Үш түрлі шектеуді араластырмаңыз:

• Қызмет көрсету үлесі бәсеке кезінде команда қанша жұмыс алатынын анықтайды.
• Қатар орындалу лимиті команда бір уақытта қанша тапсырманы іске қосып ұстай алатынын шектейді.
• Жылдамдық лимиті команданың жаңа жұмысты қаншалықты тез жасай алатынын шектейді.

WFQ салмағы қатар орындалу лимитін алмастырмайды. Үлкен салмағы бар команда әділ түрде көбірек үлес алуы мүмкін, бірақ жоспарлаушы мұндай тапсырмаға рұқсат берсе, оның бір тапсырмасы бүкіл GPU-ды бәрібір алып қоюы ықтимал. Жылдамдық лимиті де салмақты алмастырмайды: команда мың ауыр тапсырманы баяу жіберіп, кезекті бірнеше сағат бойы босатпауы мүмкін.

Бір абстрактілі «лимиттің» орнына ресурстар бойынша жеке есеп жүргізіңіз. Жергілікті модель үшін бұл GPU секундтары, жад және слоттар саны болуы мүмкін. Сыртқы модель үшін минуттағы сұраулар, минуттағы токендер, қатар орындалатын шақырулар және ақша бюджеті маңызды. Қосындының әр бөлігі нені білдіретінін түсіндіре алмайынша, бұл шамаларды бір санға қоспаңыз.

Ағын пайдаланушы немесе API кілті емес, команда мен жұмыс класы болуы керек

Ағынды таңдау жоспарлаушы кімдерді көрші деп санайтынын анықтайды. Мұндағы қате кез келген алгоритмнің мәнін жояды.

Егер ағын пайдаланушыға тең болса, бір команда жүздеген сервистік аккаунт ашып, жүздеген үлес ала алады. Ағын API кілтіне тең болса, дәл сондай әсер кілттерді ауыстырғанда немесе қолданбаны микросервистерге бөлгенде пайда болады. Ағын тек командаға тең болса, оның ауыр түнгі есебі өз интерактивті сервисімен бәсекелеседі, ал бизнеске бұл әдетте қажет емес.

Жақсы бастапқы схема:

flow_id = organization_id + workload_class + resource_pool

organization_id үлес иесін анықтайды. workload_class интерактивті жұмысты batch және қызметтік операциялардан бөледі. resource_pool сыртқы API-ды күтіп тұрған тапсырманың жергілікті GPU кезегіндегі орынды алып қоюына жол бермейді.

Ережелермен қорғай алмайтын кластарды көбейтпеңіз. Әдетте мына кластар жеткілікті:

• interactive белсенді пайдаланушы жолындағы сұраулар үшін;
• batch бағалау, индекстеу, жаппай генерация және эксперименттер үшін;
• system тоқтату, health checks және сирек қолдау операциялары үшін.

Класты клиент тақырыбы емес, сенімді сервер белгілеуі керек. Клиент ниетін хабарлай алады, бірақ диспетчер оны маршрут, сервистік аккаунт, тапсырма түрі немесе бөлек рұқсат арқылы тексеруге міндетті. Әйтпесе кез келген batch шақыру өзін интерактивті деп жариялай алады.

Қысқа сұрауларды көлемді бағалау мен шағын квант қорғайды

Ағындар бойынша WFQ командаларды бір-бірінен қорғайды, бірақ бір команданың ішіндегі қысқа жұмысты үнемі қорғай бермейді. Егер interactive класына контексті өте үлкен бір сұрау түсіп, оның артында он қысқа сұрау тұрса, ағын ішіндегі қарапайым тәртіп қайтадан head-of-line blocking жағдайын туғызады.

Мәселені шешудің ең қатаң тәсілі shortest remaining processing time деп аталады: қалған уақыты ең аз жұмысты бірінші орындау. Бұл орташа кідірісті жақсы азайтады, бірақ қысқа тапсырмалар ағыны тоқтамаса, ұзақ тапсырмаларды үнемі кейінге ысыруы мүмкін. Өндірісте оның шектелген нұсқасын қолданған дұрыс.

Интерактивті класты болжамды құны бойынша бірнеше өлшем себетіне бөліңіз. Кішкентай тапсырма тез бастау мүмкіндігін алады, бірақ шектеулі санды беруден кейін диспетчер келесі себеттен жұмыс алуға міндетті болады. Бұл мінсіз теория емес, есесіне саясат нақты трафикке төтеп береді және оны сервис иелеріне түсіндіруге болады.

Тағы бір қарапайым жолы бар: бір бөліктің көлемін шектеу. Генерация үшін бұл ұзақ жауаптың болжамды толық ұзындығын соңына дейін резервтемейтінін білдіреді. Диспетчер шектеулі токен санын немесе шектеулі есептеу уақытын береді, содан кейін жұмысты жалғастыру керек пе, соны шешеді. Мұндай тәсіл орындаушыда тоқтату мен жалғастыру мүмкіндігін талап етеді. Егер орындаушы тапсырманы қауіпсіз жалғастыра алмаса, оны бөліктерге бөлгендей болмаңыз. Толық құнын есептеп, ауыр тапсырмалар санын шектеген дұрыс.

Қысқа сұрауларды тек таймаут арқылы қорғау мүмкін емес. Таймаут пайдаланушы күтіп болғаннан кейін іске қосылады. Кезек жұмысқа не жіберілетінін іске қосылғанға дейін шешуі керек.

GPU мен сыртқы API үшін бюджеттер және күту нүктелері бөлек болуы керек

Сыртқы модельге шақыру жасайтын тапсырма желіні немесе провайдердің жауабын күтіп тұрған кезде жергілікті GPU слотының орнын иеленбеуі керек. Бұл анық көрінеді, бірақ воркерлерде жиі бұзылады: процесс тапсырманы алып, ортақ слотты резервтейді де, сыртқы API-ға жүгінеді және күту кезінде слотты ұстап тұрады.

Жолды кезеңдерге бөліңіз. Жергілікті дайындау қысқа CPU лимитін алады. Сыртқы API шақыруы нақты провайдердің кезегі арқылы өтеді. Жергілікті кейінгі өңдеу өз ресурсын қайта алады. Әр кезеңнің өз семафоры және құн есептегіші болсын.

Сыртқы API үшін token bucket пен әділ кезектің үйлесімі пайдалы:

provider: external-model-a
limits:
  requests_per_minute: 900
  tokens_per_minute: 180000
  max_in_flight: 24
scheduler:
  algorithm: wfq
  flow: organization_id + workload_class
  weights:
    interactive: 6
    batch: 1
  max_queue_age_seconds:
    interactive: 45
    batch: 7200
retry:
  max_attempts: 3
  budget_per_flow_percent: 10
  backoff: exponential_with_jitter

Бұл фрагмент нақты апаттың алдын алады: batch ағыны қатар орындалатын шақыруларды соншалық көбейтпейді, нәтижесінде интерактивті сұраулар да онымен бірге 429 алмайды. Сонымен қатар қайталап жіберулер ағын бюджетінің он пайызынан асып кетпейді. Мұндағы сандар әмбебап емес. Оларды провайдер квоталарынан, байқалатын кідірістен және рұқсат етілетін күту уақытынан шығару керек, өлшемсіз өндірісте сол күйі көшірмеңіз.

Google Cloud квоталары туралы құжаттама ауыр және жеңіл әдістерге бөлек квота тағайындауды, ал 429 кезінде кідіріспен қайталап көруді ұсынады. Бұл орынды кеңес, бірақ ортақ диспетчер үшін бір backoff жеткіліксіз: қайталау сол лимит пен әділдік саясаты арқылы қайта өтуі керек. Әйтпесе ескі тапсырмалар әр жаңа әрекетте кезекті айналып өтеді.

Болдырмау мен қайталап жіберу төтенше жүктемеде кезектің әділ болуын анықтайды

Пайдаланушы бетті жапты, бірақ оның генерациясы GPU-ды тағы екі минут пайдалана берді. Batch job уақытша қате алып, бірден жүздеген қайталау жіберді. Клиент таймауты аяқталды, ал сервер воркері сыртқы API-ды әлі күтіп тұр. Үш жағдайдың бәрі ешкім төлеуге дайын емес жұмысты тудырады, бірақ кезек оны әлі де басқа жұмысқа тең деп санайды.

Әр тапсырмада deadline, cancel_token және идемпотенттілік идентификаторы болуы керек. Диспетчер мерзімді кезекке қою алдында, орындаушыға беру кезінде және ұзақ кезеңдер арасында тексереді. Орындаушы ресурсты нақты босата алатын жерлерде тоқтатуды тексеруі керек: модельді іске қосар алдында, batch бөліктерінің арасында, провайдерге келесі шақыру алдында және жауап қайтқаннан кейін.

Қайталаулар үшін бөлек ережелер қойыңыз:

1. Операция қауіпсіз немесе идемпотенттілік кілтімен қорғалған қателерді ғана қайталаңыз.
2. Қайталауды жалпы кезектің басына емес, бастапқы ағынға қайтарыңыз.
3. Қайталауды тапсырма иесінің әрекет бюджеті есебінен жүргізіңіз.
4. Клиенттер сұрауларды бір мезетте қатар қайталамауы үшін кідіріске кездейсоқ құрамдас қосыңыз.
5. Әрекет лимиті әлі біткен жоқ болса да, deadline өткенде қайталауды тоқтатыңыз.

429-дан кейін бірден retry жасау уақытша мәселеге реакция сияқты көрінеді. Іс жүзінде ол жүктеменің ұзаққа созылуына жиі себеп болады. Егер провайдер ағынды токендер бойынша шектесе, сол ұзақ сұрауды 100 миллисекундтан кейін қайталау сол бұзушылық туралы екінші жазба жасаумен ғана тең.

Саясатты орташа жауап уақытымен емес, жасанды артық жүктемемен тексеріңіз

Орташа кідіріс әділдік туралы өте аз ақпарат береді. Ол шағын команда бір сағат күтіп отырғанда да жақсы көрінуі мүмкін, өйткені ірі команда көптеген қысқа тапсырма жіберіп, орташа мәнді төмендетеді.

Метрикаларды иесі, класы және ресурс пулы бойынша бөлек жинаңыз. Минималды жиын мынадай:

• басталғанға дейінгі күту уақытының p50, p95 және p99 мәндері;
• әр ағын бойынша қызмет көрсетілген жұмыстың нақты құны;
• іске қосылған тапсырмалар саны мен кезек ұзындығы;
• басталғанға дейінгі тоқтатулар, орындау кезіндегі тоқтатулар және тоқтатудан кейінгі жұмыс;
• 429, таймауттар және жалпы көлемдегі қайталаулар үлесі.

Содан кейін қызықсыз, бірақ көрсеткішті тест өткізіңіз. A командасы ауыр batch тапсырмаларын үздіксіз жіберсін. B командасы қысқа интерактивті сұрауларды тұрақты жиілікпен жіберсін. C командасы кейде жұмыс көлемін күрт арттырсын. Алдымен сценарийді FIFO-да, кейін қатаң приоритетте, соңында сол қатар орындалу лимиттерімен WFQ-да іске қосыңыз. Тек аяқталған жұмыстардың жалпы санын емес, B сұрауларының басталу уақытын, A ресурсының үлесін және C өз жұмысының кем дегенде бір бөлігін күте алды ма, соны салыстырыңыз.

Егер WFQ командаларға дұрыс үлес берсе, бірақ интерактивті сұраулар әлі де тым ұзақ күтсе, мәселе көбіне салмақта емес. Квант көлемін, ең үлкен тапсырманы, бір уақытта бос емес слоттар санын және ағын ішіндегі тәртіпті тексеріңіз. Қолжетімді GPU-дың бәрін алып қойған тапсырма бұрыннан туғызған кідірісті жоспарлаушы жоя алмайды.

Кезекші инженерге түсіндіруге болатын оқшаулаудан бастаңыз

Бірден мінсіз жаһандық жоспарлаушы құру міндетті емес. Алдымен бүкіл жұмысқа арналған бір ортақ кезекті жойыңыз. Интерактивті жұмысты batch-тен бөліңіз, әр командаға қатар орындалу лимитін енгізіңіз, нақты құнды өлшеңіз және қайталаулардың кезекті айналып өтуіне тыйым салыңыз. Осыдан кейін салмақтар пайдалы мәнге ие болады.

Ережелер тұрақтанған кезде, оларды келісім ретінде бекітіңіз. Әр ағынға кім иелік ететінін, қандай кластарға рұқсат берілетінін, бәсеке кезінде қандай үлес кепілденетінін, көршілер бос тұрған кезде не болатынын және қандай күту уақыты мерзімі өткен деп саналатынын көрсетіңіз. Мұнсыз WFQ кодтағы алгоритм болып қалады, ортақ ресурс саясатына айналмайды.

Егер шақырулар AI Router арқылы өтсе, кілт деңгейіндегі лимиттер API шлюзіндегі тұтынушыларды бөле алады. Бірақ кезек саясаты мен жұмыс классификациясын қолданбада немесе бөлек диспетчерде ұстаған дұрыс. Әйтпесе кілт кіріс жылдамдығын шектегенімен, келесі бос слотты кімнің ұзақ тапсырмасы алуға құқылы екенін шешпейді.

Әділдік әр команда бірдей алуы керек дегенді білдірмейді. Ол ресурс тапшы болған кезде алдын ала келісілген үлестердің сақталуын білдіреді. Кезектің өзі дәл осы сәт үшін қажет.