Инференсті автоскейлинг: кезек пен кідірістен келетін сигналдар

Кластер неге пайдасыз қозғалады

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

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

Түнде бұл одан да қатты байқалады. Күндіз 30 сұраудан тұратын кезек екі-үш минутқа қалыпты болуы мүмкін. Түнде сол кезек бір ғана пакет тапсырма немесе бір ауыр промпт үшін дабыл сияқты көрінеді.

Тағы бір тұзақ — GPU-дың суық іске қосылуы. Жаңа инстанс бірден көмектесе бастамайды. Оған көтеріліп, модельді жадыға жүктеп, контейнерлерді қыздырып, маршрутқа қосылу керек. Осы уақыт ішінде p95 кідіріс пен күту уақыты өседі. Автоскейлер өсімді көріп, қуат бәрібір жетіспейді деп ойлауы мүмкін, ал шын мәнінде қажетті тораптар әлдеқашан іске қосылған, жүйеге тек уақыт беру керек.

Тағы бір жиі қате — тек CPU немесе GPU-ға қарау. LLM-инференс үшін бұл метрикалар жеткіліксіз, әрі көбіне кешігеді. Кезек әлдеқашан толып, пайдаланушылар күтіп отыр, ал GPU жүктемесі әлі шекке жетпеген, себебі сұраулар тіпті өңдеуге түспеген.

Әдетте кластерді төрт нәрсе орынсыз қозғайды: метрика терезесінің тым қысқа болуы, күн мен түнге бірдей шек қою, суық іске қосылуды елемеу және кезек ескерілмеген тек CPU немесе GPU-ға сүйену.

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

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

Қандай сигналдарды кезектен алу керек

Бір ғана кезек ұзындығы көбіне алдайды. 20 сұраудан тұратын кезек 14:00-де қалыпты, ал 14:03-те проблема болуы мүмкін, егер ол секунд сайын өсіп жатса және GPU-лар бос емес болса.

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

Бірінші сигнал — кезек тереңдігі. Бірақ оның өзі аз нәрсе айтады. Одан да маңыздысы — өсу жылдамдығын есептеу: секундасына қанша сұрау кезекке түседі және жүйе қаншасын жұмысқа ала алады. Егер кезек 15 деңгейінде тұрып, өспесе, бұл төзімді. Егер бір минутта 15-тен 80-ге өссе, әрекет ету керек.

Екінші сигнал — инференс басталғанға дейінгі күту уақыты. Бұл бос кезек ұзындығына қарағанда пайдаланушы тәжірибесіне жақынырақ. Орташа мәннен гөрі p95-ке қараған дұрыс: тыныш ағын баяу “құйрықтарды” жасырып жібере алады, ал SLA-ны дәл солар бұзады.

Үшінші сигнал — сұрауларды «кезекте» және «жұмыста» деп бөлу. In-flight сұраулар көп болса, кезек қысқа болғанның өзінде жаңа инстанс керек болуы мүмкін. Керісінше, ұзын кезек кейде тек бір воркер ауыр тапсырманы алып қойғандықтан пайда болады. Бұл бөлінусіз нақты тар жерді түсіну қиын.

Тәжірибеде көбіне төрт метрика жеткілікті:

• ағымдағы кезек тереңдігі
• соңғы 30-60 секундтағы кезек өсу жылдамдығы
• инференс басталғанға дейінгі күту уақытының p95 мәні
• кезекте тұрған сұраулардан бөлек, жұмыстағы сұраулар саны

Тағы бір пайдалы қадам — қысқа және ұзын сұрауларды бөлек пулдарға бөлу. 200 токендік чат пен ұзын құжатты өңдеу бір GPU үшін таласпауға тиіс. Әйтпесе бірнеше ауыр тапсырма басқалардың бәрінің кідірісін бұзады.

Бұл әсіресе трафиктің бір бөлігі жылдам диалогтық модельдерге, ал бір бөлігі өз GPU-ларындағы үлкен open-weight модельдерге баратын жерде байқалады. Егер бір контурда сыртқы модельдер де, өз GPU-пулдары да болса, AI Router-дегідей қысқа және ұзын сұрауларға бөлек кезектер көбіне бүкіл кластерді бірден дөрекі масштабтаудан пайдалырақ.

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

Кідірісті өз-өзіңді алдамай оқу жолы

Кідіріс бір ғана санмен қаралса, оңай шатастырады. Пайдаланушы толық жауап уақытын сезеді, бірақ автоскейлинг үшін бұл жеткіліксіз. Кластер уақыттың қай жерде жоғалып жатқанын түсінуі керек: кезекте ме, желіде ме, модель рантаймында ма, әлде сұрауды қайта жіберуде ме.

Алдымен end-to-end кідіріс пен модельдің таза жұмыс уақытын бөліңіз. Егер сұрау кезекте 1,5 секунд күтіп, модель 400 мс есептесе, мәселе модельде емес. Егер кезек бос, ал модель уақыты екі еселенсе, онда әңгіме воркер қуатында емес, промпт өлшемінде, жауап ұзындығында, суық іске қосылуда немесе провайдер жағындағы проблемада.

Трафик AI Router сияқты шлюз арқылы өтсе, мұндай бөлу әсіресе пайдалы. Бірдей сұрау API-қабатынан тез өтіп, GPU кезегінде ұзақ тұрып қалуы мүмкін. Кезеңдер бойынша бөлу болмаса, график тек жалпы кідіріс өсімін көрсетеді де, команда дұрыс емес жерді масштабтайды.

Орташа мән жағымсыз шұңқырларды дерлік әрдайым тегістеп жібереді. Кемінде p50 мен p95-ті бірге қараңыз. p50 жүйенің қалыпты күйін көрсетеді, ал p95 — SLA-ны бұзатын құйрықты.

Әдеттегі көрініс былай болады: p50 бірқалыпты тұрады, ал p95 күрт жоғары көтеріледі. Бұл кездейсоқ шу емес. Көбіне бұл жергілікті жүктеме артуы, ұзын сұраулардың кенет көбеюі немесе әлі үлкен болмай тұрса да кідіріс құйрығын бүлдіре бастаған кезек.

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

Тағы бір қате — бір графикке клиент қателерін және ретрайларды араластыру. Егер клиент байланысын екінші секундта үзіп, кейін сол сұрауды қайта жіберсе, орташа кідіріс пен p95 бұрмалана бастайды. Масштабтау шешімдері үшін мұндай оқиғаларды бөлек шығарған дұрыс: 4xx, клиент жауып тастауы, клиент жағындағы таймауттар және қайта әрекеттер.

Кідірісті кезек тереңдігімен дәл сол сәтте салыстырыңыз, шамамен сол кезеңде емес. Егер p95 өссе, ал кезек өзгермесе, басқа себеп іздеңіз. Егер кезек пен p95 бірге өссе, қуат жетіспейді. Егер кезек өсіп, бірақ модельдің таза уақыты өспесе, тезірек масштабтау керек. Егер модель уақыты өздігінен өссе, алдымен жүктеме профилін тексеріп алыңыз, содан кейін ғана GPU қосыңыз.

Күндіз және түнде қандай шектер жұмыс істейді

Күні бойы бірдей шек қою әдетте артық секірулерге әкеледі. Күндіз трафик тығызырақ, әрі қателіктің бағасы жоғары: кезек тез өседі, p95 жоғарылайды, пайдаланушылар оны бірден байқайды. Түнде сол секіріс көбіне қысқа болады, ал егер кластер дәл сондай қатты әрекет етсе, GPU-лар жай ғана қосылып, бос тұрады.

Күндіз scale up шегі әдетте төменірек қойылады. Мағынасы қарапайым: кезек кідірісте көрінбей тұрып-ақ аздап ертерек қуат қосу. Егер жұмыс трафигі 9:00-ден 19:00-ге дейін жүрсе, p95 SLO шегінен асып кеткенін күтуден гөрі күту уақытының ерте өсуіне жауап берген дұрыс.

Түнде логика басқа. Шекті көтеруге және scale up алдында ұзақтау күту терезесін қоюға болады. Осылай қысқа, өзі басылатын секірістерді сүзгіден өткізесіз. Бұл әсіресе банктерде, ритейлде және SaaS-та пайдалы, мұнда түнде фондық тапсырмалар, пакетпен жүргізілетін есептер және ішкі жүйелерден келетін сирек секірістер болады.

Бастапқы схема әдетте былай көрінеді:

• күндіз кезек тереңдігі айқын өссе немесе күту уақыты 2-3 минут бойы шектен жоғары тұрса, scale up ертерек іске қосылады
• түнде сол сигнал ұзағырақ тұруы керек, көбіне 5-10 минут
• scale down үшін бөлек таймер керек, ол баяуырақ және қатаңырақ болады
• қуатты азайту шегі өсу шегінен төмен болуы тиіс, сонда тораптарды ары-бері сүйремейсіз

Scale up пен scale down-ды міндетті түрде бөлу керек. Егер қуатты бір таймермен қосып-өшірсеңіз, кластер шекара маңында дірілдей бастайды. Тәжірибеде қуатты азайтуды ұлғайтудан 2-4 есе баяуырақ жасаған дұрыс. Мысалы, GPU-ды 3 минуттық шамадан тыс жүктемеден кейін қосуға болады, ал алып тастауды тек 15-20 минут тыныш жұмыстан соң ғана.

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

Егер трафик апта күндеріне қатты өзгерсе, күн мен түнге бөлу де аздық етеді. Дүйсенбі таңы мен сенбі түні — бөлек режимдер, әрі шектері де жиі әртүрлі болуы керек.

Автоскейлинг ережесін қадамдап қалай құру керек

Жақсы ереже бір ғана SLA мақсатын таңдай басталады. Әдетте бұл не сұраудың кезекте күту уақыты, не толық p95 кідірісі болады. Бірден екі тең мақсат қоймаңыз. Әйтпесе автоскейлер шатасады: бір метрика GPU қосуды сұрайды, екіншісі тынышталып үлгереді.

Инференсті автоскейлинг үшін рөлдерді былай бөлу ыңғайлы: бір метрика шешім қабылдайды, қалғандары сақтандырады. Мысалы, команда күту уақытын 1,5 секундтан асырмай ұстайды, ал p95-ті жүйе шынымен жылдамдады ма, әлде тек кезекті басқа жерге ысырып қойды ма — соны тексеру үшін қолданады.

Одан кейін ережені ретімен жинаған дұрыс.

1. Мақсат мәнін қойыңыз. Бизнес те, инженерлер де түсінетін бір сан алыңыз. Мысалы: «Сұраулардың 95%-ы кезекте 1,5 секундтан артық күтпейді».
2. Кезек тереңдігі бойынша scale up үшін ерте триггер қосыңыз. Бұл кезек жаман болғандықтан емес, ол p95 бұзылмас бұрын өсетіндіктен керек. Егер бір GPU үшін әдетте 8-10 белсенді сұрау қауіпсіз болса, шекті дәл апат сәтіне емес, ауырсыну аймағынан сәл төмен қойыңыз.
3. Тегістеу терезесін енгізіңіз. Көптеген жұмыс жүктемелері үшін 2-5 минут жеткілікті. Онсыз кластер өзі басылатын қысқа секірістерден қозғала береді.
4. Әр өлшем өзгерісінен кейін cooldown қойыңыз. Scale up-тан кейін жүйеге 3-10 минут беріп, жаңа репликалар қызсын, кезекті алып үлгерсін және нақты кідіріс көрінсін. Scale down үшін терезе әдетте ұзағырақ болады.
5. Ережені кешегі трафикте тексеріңіз. Күндізгі шыңды және түнгі тыныш сағаттарды бөлек қараңыз. Жақсы ереже пайдаланушылар байқамай тұрып қуатты қосады және төмендеуден кейін артық GPU-ларды ұстамайды.

Жұмыс істейтін қарапайым шаблон бар: кезек шектен 3 минут қатарынан жоғары тұрса — 1-2 реплика қосу; кезек 15 минут бойы нормада болып, p95 те нормада болса — 1 репликаны алып тастау. Қадамдарды кішкентай ұстаған дұрыс. Күрт масштабтау көбіне қымбатқа түседі және болжауды қиындатады.

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

Мысал: банктің жұмыс күні және тынық түн

Банкте таңғы пик әдетте дәл 9:00-де емес, бірнеше минут бұрын басталады. Қызметкерлер ішкі жүйелерді ашады, құжат іздеуді, хат тексеруді және қысқа қорытындыларды іске қосады. Ағын күрт өседі, ал 9:00-ден 11:00-ге дейін кезек тереңдігі жаңа GPU-лар қызарып, трафикті қабылдап үлгергеннен де тез өсіп жатады.

Мұндай фазада автоскейлингті тек GPU жүктемесіне сүйеп құруға болмайды. Ол мәселені кеш көрсетеді. Оның орнына үш сигналдың байланысына қараған дұрыс: кезек тереңдігі, сұрауларды күту уақыты және p95 кідірісі. Егер кезек қалыпты деңгейден 60-90 секунд жоғары тұрса, ал күту уақыты норма шегінен асса, автоскейлер бір инстанс қана емес, бірден шағын қадам қосқаны жөн.

Таңертең ереже жиі төрт нәрсеге тіреледі: ауысым басталғанға дейін жылы ең аз қуатты ұстап тұру, scale up-ты бір реттік секіріске емес, тұрақты кезекке қарай қосу, ұзақ қыздыру кезінде қуатты 2-3 репликамен арттыру және трафик тынышталмайынша scale down-ды кейінге қалдыру.

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

Түнде көптеген командалар бірдей қате жібереді: сирек секірісті көріп, бүкіл пулды оятады. Тәжірибеде 22:00-ден кейін есептерді қайта санау немесе құжаттарды белгілеуге арналған бір batch қысқа секіріс беруі мүмкін, бірақ бұл бүкіл интерактивті контурды көтеру керек деген сөз емес. Түнгі профильге бақылау терезесі ұзағырақ болатындай ереже қойған дұрыс.

Жақсы түнгі сценарий қарапайым. 1-2 минуттық сирек секірісті елемейсіз. Егер кезек ұзақтау тұрып, пайдаланушылар шынымен күтіп жатса, онда қуат қосасыз. Бір түнгі batch-ты бірден жеке кезекке және өз лимитіне шығару жақсы. Өз GPU-инфрақұрылымында модель ұстайтын командалар үшін бұл әсіресе пайдалы: интерактивті сұраулар зардап шекпейді, ал фондық тапсырма кластерді себепсіз үдетпейді.

Командалар жиі жіберетін қателер

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

Егер кезек роутер, батчер немесе модель серверінің алдында өссе, GPU қалыпты көрінуі мүмкін. Графикте 55% жүктеме, ал күту уақытының p95 мәні әлдеқашан жоғары кеткен. Пайдаланушыны орташа темір емес, нақ сол күту уақыты мазалайды.

Егер сізде AI Router сияқты LLM-шлюз болса, тек GPU-ға емес, шлюздің кіреберісіндегі кезекке де қараған пайдалы. Ол жерде жүктеме артықтығы көбіне воркерлердің өзінен бұрын байқалады.

Сигнал таңдаудағы қате

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

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

Тағы бір жиі қате — интерактивті сұраулар мен ұзын batch-тапсырмаларды бір кезекке араластыру. Сонда бір ауыр өңдеу чаттың, іздеудің немесе оператор көмекшісінің метрикаларын бүлдіреді.

Бұл жерде ереже қарапайым: интерактивті сұраулар бөлек кезекке түсуі керек, batch-тапсырмалар — өз воркер пулына, ал трафиктің әр класына өз масштабтау шектері қажет.

Реакция уақытына қатысты қате

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

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

Сондықтан scale out пен scale in бір ережемен өмір сүрмеуі керек. Өсу тезірек болуы мүмкін, ал қуатты азайту сақтықпен жасалғаны дұрыс: бақылау терезесімен, cooldown-мен және ең аз жылы пулмен. Бұл агрессивті үнемдеу сияқты әсерлі емес, бірақ кластерді пайдасыз дірілдетпейді.

Қысқа тексеру тізімі

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

• Үш метриканы бөлек ұстаңыз: кезек тереңдігі, өңдеу басталғанға дейінгі күту уақыты және модельдің таза жұмыс уақыты. Оларды бір кідіріске қоссаңыз, жүйе басқа проблеманы емдей бастайды.
• p95-ті секунд сайын емес, тынық терезеде есептеңіз. Әдетте 5-10 минуттық терезе және сұрау саны бойынша төменгі шек жеткілікті: сирек секіріс артық GPU масштабтауды қоспауы үшін.
• Қуатты төмендеткеннен жылдамырақ көтеріңіз. Жаңа қуатты 1-2 нашар терезеден кейін қосқан дұрыс, ал алып тастауды ұзағырақ тынық кезеңнен кейін ғана жасаңыз.
• Бүкіл күнге бір режим қоймаңыз. Күндіз және түнде жүктеме әртүрлі, сондықтан шектер не кесте де бөлек болғаны жөн.
• Командаға әр артық GPU іске қосудың бағасын көрсетіңіз. Адамдар артық scale up оқиғаларының құнын көргенде, олар scale down-ға байыптырақ қарайды.

Тағы бір жиі тұзақ бар. Команда тек p95 кідірісіне қарайды, өсімді көреді де, GPU жетіспейді деп ойлайды. Бірақ p95 кіреберістегі кезек, суық іске қосылу, rate limit немесе сыртқы провайдердің ұзақ жауабы салдарынан да өсуі мүмкін. AI Router сияқты шлюз үшін маршрутизацияға дейінгі кідірісті, кезекте күтуді және модельдің өзіндік уақытын ажырату әсіресе пайдалы.

Түнгі режим әрдайым бөлек логиканы талап етеді. Күндіз сіз көбіне пайдаланушы жауабын қорғайсыз. Түнде екі-үш сирек сұрау үшін бос GPU-ларды ұстап тұру маңызды емес. Сондықтан түнде scale up үшін жоғарырақ шек, scale down алдында ұзағырақ кідіріс немесе кластердің ең аз өлшемін кесте бойынша бекіту қолданылады.

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

Алғашқы баптаудан кейін не істеу керек

Алғашқы шектер ешқашан ұзақ тұрмайды. Инференсті автоскейлингті бір жүктеме тестімен емес, тірі трафикпен қайта қарап отыру керек. Жүйе кемінде бір апта жұмыс істесін де, сағат бойынша метрикаларды алыңыз: кезек тереңдігі, p95 кідірісі, сұрау күту уақыты, GPU бос еместігі және суық іске қосылулар саны.

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

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

Төрт нәрсені үнемі салыстырып отырған пайдалы: мақсатты уақыттан ұзақ күткен сұраулар саны, бірдей кезек тереңдігінде p95 қалай өзгеретіні, қанша инстанс босқа көтеріліп, жүктемені дерлік алмағаны және scale down-ның қаншалықты жиі бірден жаңа scale up-қа ауысатыны.

Жүктеме тесттерін де бөлек жүргізген дұрыс. Қысқа және ұзын промпттар GPU, жад және кезекке әртүрлі жүктеме профилін береді. Егер оларды бір тестке араластырсаңыз, шынайы жағдайда нашар жұмыс істейтін орташа шек шығады. Екі сценарийді бөлек өткізіп, жүйе SLA бойынша қай жерде кешеуілдей бастайтынын қараған әлдеқайда ыңғайлы.

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

Егер командаға метрикаларды бір жерде жинап, кейбір модельдерді Қазақстанда жергілікті ұстау үшін бірыңғай OpenAI-үйлесімді шлюз керек болса, AI Router-ге қарауға болады. Бұл трафиктің бір бөлігі сыртқы модельдерге кетіп, бір бөлігі өз GPU-ларда қалатын кезде және автоскейлинг ережелерін бір бақылау схемасында салыстыру қажет болғанда ыңғайлы.