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

Пик кезінде ақша қайда кетеді
Ең жиі қате - күні бойғы GPU орташа жүктемесіне қарап, қор жеткілікті деп ойлау. Орташа мән көбіне жалған тыныштық береді. Егер 10:00 мен 16:00 аралығында карталар 45% бос болмаса, бұл 11:20-де жүйе нормадағыдан үш есе жоғары секірісті жай ғана көтереді деген сөз емес.
Пик орташа мәнге емес, қысқа уақыт аралығына соққы береді. Бірнеше минуттың өзі жеткілікті: көптеген пайдаланушы бір мезетте ұзақ сұраулар жіберсе, модельдер жауап беріп үлгергенше кезек өсе бастайды. Сырттан қарағанда бәрі қарапайым көрінеді: «бәрі жұмыс істеп тұрды да, кенет баяулап кетті». Ішінде сол сәтте-ақ құйрық жиналып жатады, әрі сұрау ағыны төмендесе де, ол бірден жоғалмайды.
Әдетте ақша төрт жерде кетеді. Команда қорды тым аз ұстап, ең қымбат сағатта сұрауларды жоғалтады. Жүйе модельдерді тым кеш көтереді, ал суық старт қосымша секундтар қосады. Кезек өсіп, пайдаланушылар сұрауды қайта жібереді, сол арқылы жүктеме одан әрі күшейеді. Немесе керісінше, команда тым үлкен резерв жоспарлап, сағаттап босқа тұрған GPU үшін ақша төлейді.
Суық старт жұмыс уақытында ерекше жағымсыз. Модельді жадқа жүктеу, қыздыру, кейде адаптерлерді немесе бөлек конфигурацияны тарту керек. Қағазда бұл 20-40 секунд. Тірі ағын үшін бұл кезектің алға ұзап кетуіне-ақ жетеді. Егер сервис чат қолдауда жауап берсе, оператор жай күтіп отырады. Ал бұл скоринг, құжат тексеру немесе колл-орталыққа көмек болса, әр қосымша секунд тез арада тікелей шығынға айналады.
Артық қор дауысы бәсең, бірақ әсері кем емес. Мысалы, команда сирек болатын, аптасына бір рет 10 минутқа ғана созылатын пик үшін модельдердің жылы пулын ұстап отыр делік. Қалған уақытта карталардың бір бөлігі бос тұрады, ал инфрақұрылым есебі әр сағат сайын жүре береді. Бұл жүктеме ауысымға, апта күніне немесе аймаққа қарай біркелкі емес болса, тіпті айқын байқалады.
Пик кезінде бизнес көбіне не клиенттің күтуі үшін, не бос резерв үшін төлейді. Қауіпті мүлде жою мүмкін емес. Міндет әлдеқайда қарапайым: кәдімгі секірісті ұзын кезексіз өткізіп, тыныш сағаттарды қымбат бос тұруға айналдырмайтындай қор ұстау.
Қор мөлшеріне не әсер етеді
Қор мөлшері орташа трафикте емес, кезек, ұзақ жауаптар және ауыр модель бір уақытта тоғысқан сәтте бұзылады. Бір сағаттағы 300 сұрау тыныш өтуі де мүмкін, егер олардың жартысы екі минуттың ішінде келсе, GPU-ды толтырып тастауы да мүмкін.
Бірінші фактор - бір мезеттегі белсенділік. Пик кезінде сізде әдетте 8 белсенді диалог болса, бір қор. Егер ондай диалог 30 болып, пайдаланушылардың бір бөлігі нақты уақыттағы жауапты күтсе, резерв мүлде басқа болады. Сондықтан сағаттағы сұрауларды ғана емес, жүйе бір уақытта қаншасын өңдеп тұрғанын да санаған пайдалы.
Екінші фактор - модельдің өзі. Кіші модель аз жад алады және GPU-ды тез босатады. Ауыр reasoning-модель картаны ұзағырақ ұстайды, әсіресе жауап ұзын болып, токен лимиті жоғары болса. Сол себепті сұрау саны бірдей екі модель GPU жүктемесін бірнеше есе әртүрлі көрсетуі мүмкін.
Үшінші фактор - жауап ұзақтығы. 80 токендік қысқа жауап дерлік білінбейді. 1200 токендік жауап генерацияны ұзағырақ алып, дәл сол кіріс ағынында да кезекті өсіреді. Егер команда барлық сценарийге ұзын жауап беруге рұқсат етсе, қорды әдетте жоғарырақ ұстауға тура келеді.
Тағы бір қарапайым өнімдік шекара бар: қандай кідірісті көтере аласыз. Ішкі көмекші үшін 6-8 секунд кейде қалыпты. Ал оператор чаты немесе дауыстық сценарий үшін - жоқ. Мақсатты кідіріс қаншалықты қатаң болса, жылы пул да соншалықты үлкен болуы керек, өйткені сіз пикті кезекте жай ғана «күтіп өте» алмайсыз.
Қыздыру және түсіру уақыты да бөлек есептеледі. Егер модельді жүктеу 60-90 секунд алса, ол 3 минуттық қысқа пикті құтқармайды. Ал оны спадтан кейін тағы 10 минут жадта ұстасаңыз, GPU босқа тұра бастайды. Көбіне артық шығын дәл осы арада жасырынып жатады.
Тәжірибеде бес санды көз алдында ұстап жүрген пайдалы: ең нашар сағатта бір мезетте қанша сұрау түседі, әр модель қанша жад сұрайды, қалыпты жауап пен ұзын құйрықта токен көлемі қандай, өнім үшін қандай кідіріс рұқсат етіледі және модельді жүктеу мен түсіруге қанша секунд кетеді.
Егер трафик AI Router сияқты бірыңғай шлюз арқылы өтсе, мұндай кесінділерді жалпы трафиктен емес, модельдер, маршруттар және қол жеткізу кілттері бойынша жинау оңайырақ. Сонда қор шын мәнінде қай жерде керек, ал қай жерде GPU-ды алдын ала қыздырудың қажеті жоқ екені көрінеді.
Есепке дейін қандай дерек жинау керек
Күндік орташа трафиктің пайдасы аз. Жылы пул «орташа» сағатта емес, сұраулар тығыз түскен қысқа сәтте бұзылады. Сондықтан жүктемені минуттар бойынша, ал ең сезімтал сервистер үшін тіпті одан да жиі шығарып алған дұрыс.
Алдымен кіретін сұраулар бойынша қатар жинаңыз: әр минутта қанша келді, ағым ауысым бойы қалай өзгерді, қай жерде күрт секіріс болды. Сосын P95 пен P99 есептеңіз. Бұл метрикалар қалыпты минутты емес, жүктеменің жоғарғы 5% және 1% бөлігін көрсетеді, дәл сол жерде қуат қоры әдетте таусылады.
Тек орташаға қарасаңыз, есеп әдетте тым тыныш болып шығады. Бір күнде сізде минутына 20 сұрау болуы мүмкін, ал 11:30-да ол 75-ке жетеді. GPU үшін бұл жай ауытқу емес, мүлде басқа жұмыс режимі.
Бүкіл трафикті бір топқа қоспаңыз. Қысқа чат, ұзын аналитикалық сұрау және құжаттардың жаппай классификациясы модельдерді әртүрлі жүктейді. Кем дегенде екі кесінді жеткілікті: модель түрі бойынша және пайдалану сценарийі бойынша.
Сонда қай сұрауларды ортақ пулда ұстауға болатыны, ал қайсысын бөлек есептеген дұрыс екені көрінеді. Бір ағын шағын қорда тыныш өмір сүреді, ал екіншісі сұрау жиілігі бірдей болса да, үнемі кезек жасап жатады.
Тек сәтті жауаптарға қарамаңыз. Болдырмаулар, тайм-ауттар, қайталап жіберулер және кезек ұзындығы көбіне орташа кідіріске қарағанда мәселені ертерек көрсетеді. Егер пиктік 10 минутта кезек өсіп, кейбір клиенттер сұрауды бірнеше секундтан соң тастап кетсе, қуат әлдеқашан жетпей жатыр, тіпті күндік график қалыпты көрінсе де.
Трафик әдеттегідей емес күндерді бөлек белгілеңіз. Ритейлде бұл акциялар, банктерде - төлем күндері, SaaS-та - релиздер мен жаңа функцияны жаппай қосу. Мұндай даталарды тыныш күндермен араластырмау керек, әйтпесе қуатты жоспарлау жалған сурет береді.
Егер жүктемені бірыңғай LLM-шлюз арқылы есептесеңіз, дәл сол кесінділерді модельдер, провайдерлер және кілттер бойынша сақтаған пайдалы. Сонда тек жалпы пик емес, оны жасаған нақты сценарий де көрінеді. Бұл «сақтық үшін» артық қор алудан әлдеқайда дәл.
Жылы пулды қадамдап қалай есептеу керек
Жылы пулды GPU санынан емес, пайдаланушыға беруге дайын жауап уақытынан есептеген дұрыс. Бірдей қор қысқа мәтін тексеруге жеткілікті болуы мүмкін, бірақ ұзын генерациясы бар чат үшін тым аз болуы ықтимал. Сондықтан алдымен әр сценарий үшін мақсатты кідірісті белгілеңіз. Мысалы, құжаттан өрістерді алу үшін 2 секундқа дейін, ал жұмыс чаты үшін 8 секундқа дейін.
Содан кейін бір ретпен, болжамсыз есептеңіз.
- Соңғы 2-4 аптадағы ең ауыр сағатты алыңыз да, тек минуттағы сұрауларды емес, токендерді де есептеңіз. LLM үшін бұл әділдеу: 80 қысқа сұрау мен 80 ұзын диалог GPU-ды мүлде басқаша жүктейді.
- Токендерді бір модель көшірмесінің өткізу қабілетіне айналдырыңыз. Егер бір көшірме керек контекстпен секундына 35 токен берсе, ал пикте сервиске секундына 90 токен керек болса, қор кемінде үш жылы көшірмені жабуы тиіс.
- Ұзын жауаптар мен құйрықтарға резерв қосыңыз. Мұнда орташа мән ең көп алдайды. Егер сұраулардың 10-15%-ы үлкен контекстпен келсе немесе ұзын генерация сұраса, үстінен тағы 20-30% қор керек болады, әйтпесе кезек ең ыңғайсыз сәтте өсіп кетеді.
- Модель ауысқандағы қыздыруды ескеріңіз. Салмақтарды жүктеу, жадты дайындау және жаңа процесті іске қосу секундтан минутқа дейін созылуы мүмкін. Егер модельді тез көтере алмасаңыз, ол әр сағатта керек болмаса да, кемінде бір көшірмесін алдын ала ұстаңыз.
- Аптаның ең ауыр сағатына есепті тексеріңіз. Орташа күнге емес, бір уақытта кіріс ағыны жоғары және жауаптар ең ұзын болатын аралыққа қараңыз. Қалыпты нәтиже қарапайым көрінеді: кезек қатарынан бірнеше минуттан артық өспейді, ал P95 кідіріс белгіленген шектен аспайды.
Қысқа мысал. Егер дүйсенбіде 10:00 мен 11:00 аралығында команда минутына 120 сұрау алса, және олардың жартысы ұзын чатқа кетсе, орташа жауап ұзақтығымен есептеу қауіпті. Бұл сағатты толық алып, қорды дәл соған тексерген дұрыс. Осындай терезелерде GPU қай жерде босқа тұратынын, ал қай жерде жетпей жатқанын анық көруге болады.
Егер трафикті AI Router арқылы жүргізсеңіз, қорды әр модель немесе маршруттар тобы бойынша бөлек есептеген жақсы. Сұраулардың жалпы саны көбіне теңгерімсіздікті жасырады: бір модель жүктеменің көп бөлігін алып, бүкіл есепті бұзуы мүмкін.
Қалыпты пик пен шуды қалай ажыратуға болады
Ақша тұрақты жүктемеде емес, ең қатты секіріске реакция жасағанда жанып кетеді. Егер бір ерекше сағат сізді күні бойы қосымша жылы GPU ұстауға мәжбүр етсе, есеп әлдеқашан ауытқыған.
Қалыпты пик қайталанады. Оның белгілі уақыты, ұқсас ұзақтығы және шамалас көлемі бар. Шуға басқаша белгілер тән: бір күрт секіріс, кейін тыныштық, немесе тарату, есеп беру күні, релиз не көрші сервистегі ақаудан кейінгі өршу.
Ең жақсы және ең жаман күнді емес, қатарынан 20-30 ұқсас күнді салыстырыңыз. Жүктемені 15 минут сияқты қысқа терезелермен қараңыз. Егер бір сағатта медиана мен 90-процентиль тұрақты өссе, бұл жұмыс пигі. Егер тек максимум шырқап кетіп, әдеттегі деңгей дерлік өзгермесе, бұл шу.
Маусымдылықты да бір реттік науқанмен шатастыру оңай. Ай соңы, жалақы күндері, дүйсенбі таңғысы және контакт-орталықтағы кешкі сағаттар - қайталанатын оқиғалар. Бір күндік промо-акция, ескі диалогтарды импорттау немесе тестілерді жаппай жүргізу қор көлемін анықтамауы керек.
Мұнда қарапайым ереже көмектеседі: қор аптасына бірнеше рет болатын секірістерге ұсталады. Маркетинг науқандары мен инцидент күндері бөлек белгіленеді. Күту өз шегіңізден асып кетсе, мысалы 2-3 секундтан асса, кезек қосылады. Сирек модельді күніне екі рет шақырсаңыз, оны алдын ала қыздырудың қажеті жоқ.
Кезек шегін сезіммен емес, күтудің құнымен қойған дұрыс. Егер секіріс 5 минутқа созылса, ал жаңа модель көшірмесін қыздыру да шамалас уақыт алса, кезек көбіне арзанырақ. Ал егер кезек 20-30 минут өсіп, SLA-ға соға бастаса, қор шынымен керек.
Сирек модельдерге қатысты ереже одан да қатаң. Оларды күн бойы бір бөлім немесе сирек сценарий үшін жадта ұстамаған жөн. Жиі қолданылатын модель жылы қалады, ал сирегі кесте бойынша, бірінші сұрау түскенде немесе сыртқы маршрутқа жүктеледі. AI Router схемасында бұл ыңғайлы: тұрақты трафикті болжамды жылы пулға жіберіп, сирек пиктер үшін бос тұрған GPU-ға ақша төлемейсіз.
Егер мұндай сұрыптаудан кейін пик әлі де қайталанып, кезекке соқса, бұл енді шу емес. Бұл сіздің кәдімгі жүктемеңіздің бір бөлігі.
Жұмыс ауысымына арналған есеп үлгісі
Банктың қолдау чаты ең көп 12:00 мен 14:00 аралығында жүктеледі, сол кезде клиенттер аударым, лимит және карта бұғатталуын тексереді. Қарапайым сұрақтарды команда жеңіл модельге жібереді, ал ұзын диалог тарихы мен құжаттары бар даулы жағдайлар ауыр модельге кетеді.
Есептеу үшін команда айдағы ең жоғары секірісті алмайды. Мұндай максимум көбіне таратуға, мобильді қосымшадағы ақауға немесе бір реттік акцияға байланысты болады. Жылы пул үшін кәдімгі жұмыс ауысымының пигіне қараған пайдалырақ, мысалы соңғы апталардағы бес минуттық терезелер бойынша 95-перцентильге.
Айталық, түскі жұмыс пигі минутына 30 сұрауға тең. Оның 83%-ы жеңіл модельге, 17%-ы ауыр модельге кетеді. Қазіргі баптауларда жеңіл модельдің бір жылы көшірмесі минутына 12 сұрауды ұстайды, ал ауыр модель - 3.
Лёгкая модель: 30 x 0,83 = 24,9 -> 24,9 / 12 = 2,1 -> нужно 3 копии
Тяжёлая модель: 30 x 0,17 = 5,1 -> 5,1 / 3 = 1,7 -> нужно 2 копии
Сонда түскі пикке 5 модель көшірмесінен тұратын жылы пул шығады. Егер жеңіл модель 1 GPU алып, ауыр модель 2 GPU алса, жалпы қор 7 GPU болады. Бұл кез келген сирек секіріс үшін резерв жоспарлағаннан әлдеқайда нақты.
Енді айлық максимуммен салыстырайық. Күндердің бірінде банк минутына 44 сұрауға дейін секіріс алды, бірақ ол қосымшадағы қате салдарынан бір минуттан аз ғана созылды. Егер осы максимумға сүйенсек, 4 жеңіл және 3 ауыр көшірмені ұстау керек болар еді. Екі артық көшірме күн сайын дерлік бос тұрады.
30-60 секундтық қысқа кезек бұл мәселені әдетте жояды. Ол күрт секірісті сеанстардың бір бөлігі аяқталып үлгергенше тегістейді және әр шуылдаған минут үшін резерв сатып алмауға мүмкіндік береді. Сондықтан жұмыс ауысымы үшін пулды айлық рекордқа дейін үлкейтпей, 3 жеңіл және 2 ауыр көшірмені ұстау орындырақ.
Егер түсте кідіріс қалыпты өсіп, кезек бір минуттан ұзақ созылмаса, қор дұрыс таңдалған. Егер кезек ұзақ тұрса, бүкіл топты емес, бірінші болып шекке тірелген модельдің қуатын қосыңыз.
GPU бос тұрып қалуына әкелетін қателер
Көбіне жылы пул трафик өсімінен емес, қате жорамалдардан ұлғаяды. Команда бір ауыр күнді көреді де, дәл сондай қорды әр жұмыс кешіне жоспарлайды, сөйтіп апталап артық қуатты босқа ұстап отырады.
Ең қымбат қате - қорды айдағы ең жоғары күн бойынша есептеу. Мұндай пик көбіне бір реттік тарату, есеп, релиз немесе көрші сервистегі ақаумен байланысты болады. Оны норма деп алсаңыз, бір-екі сағатқа керек темірдің ақысын бүкіл ай бойы төлейсіз. Одан гөрі ауысымдар бойынша типтік пиге қарау және сирек секірістерге бөлек жоспар ұстау пайдалы.
Тағы бір жиі проблема - batch тапсырмалар мен чатты бір пулға араластыру. Олардың ырғақтары бөлек. Чатқа төмен кідіріс және қысқа кезек керек, ал batch үлкен көлемді фонда сабырмен өңдей береді. Егер екеуін бір GPU-ға отырғызсаңыз, түнгі пакет өңдеу жад пен декодтау орнын алып, күндізгі чат тоқтап қалады. Соңында команда тағы да карта қосады, бірақ мәселе трафикті бөлу ғана еді.
Көп адам минуттағы сұрау санын ғана есептеп, жауап ұзындығын елемейді. Бұл қақпан. Жүз қысқа жауап пен жүз ұзын есеп пулды мүлде әртүрлі жүктейді. Егер күндіз пайдаланушылар қысқа жауап сұрап, кешке ұзын генерация іске қосса, орташа RPS өзгермеуі мүмкін, ал GPU уақыты айтарлықтай өседі.
Бір картаның істен шығуын да алдын ала ескерген дұрыс. Егер пул кәдімгі пикке дәл есептелсе, кез келген ақау қалыпты ауысымды кезек пен тайм-аутқа айналдырады. Содан кейін командалар жиі қате қорытынды жасап, тұрақты түрде артық резерв ұстай бастайды, ал шын мәнінде оларға N+1 схемасы бойынша түсінікті қор керек еді, тұрақты overprovision емес.
Бюджетке бөлек соққы беретін нәрсе - барлық модельді бірдей қыздыру. Жиі модельдерді мүмкіндігінше әрдайым жылы ұстаған дұрыс. Сирек модельдерді тек кесте бойынша, маршрутизатор сигналы бойынша немесе алғашқы сұраулардан кейін ғана. Егер сирек модельді де негізгісіндей қыздырсаңыз, ол күніне бірнеше рет қана шақырылса да, сағаттап жад алып тұрады.
Дені сау пулдың жақсы белгісі қарапайым: жиі модельдер тұрақты жұмыс істейді, сиректері сұранысқа сай тез көтеріледі, ал қор нақты жүктеме профилі бойынша есептеледі, күнтізбедегі ең шуыл күн бойынша емес.
Іске қоспас бұрын тез тексерулер
Іске қоспас бұрын тек формуланы емес, оның айналасындағы тәртіпті де тексерген жөн. Дәл есептің өзі де бұзылады, егер команда кеше шыққан графикке қарап, модельдің нақты кідірісін білмесе және шексіз кезек ұстаса.
Алдымен дерек көкжиегін тексеріңіз. Егер кемінде 2-4 апталық тарих болса, қайталанатын үлгілер көрінеді: ауысымның таңғы басталуы, түскі пик, кешкі спад, есептілік немесе жаппай тарату күндері. Екі-үш күннен ғана қарап, кездейсоқ шуды норма деп қабылдап, артық қор сатып алу оңай.
Сосын әр модельдің кідірісіне бөлек қараңыз. Орташа мән мұнда да көбіне сақтықты ұйықтатады. Іске қосу үшін P95-ті білген пайдалы: дәл ол қарбалас сағатта пайдаланушылардың едәуір бөлігі не көретінін көрсетеді. Бір модель 1,2 секундта жауап берсе, ал екіншісі 4-5 секундқа кетсе, жалпы пулды олар бірдей деп есептеуге болмайды.
Тағы бір міндетті сүзгі - кезек. Оны әрі ұзындығы, әрі күту уақыты бойынша шектеу керек. Әйтпесе жүйе артық жүктемені тым ұзақ көтереді де, сіз мәселені кеш көресіз. Тәжірибеде қысқа, түсінікті отказы бар кезек көбіне ұзын кезектен жақсы: ол SLA-ны жеп қоймайды және GPU жетіспеушілігін жасырып қалмайды.
Іске қоспас бұрын бес нәрсені салыстыру жеткілікті:
- трафик тарихы кемінде 2-4 аптаға жетеді ме;
- әр модель үшін кідіріс P95 бар ма, әлде тек орташа сандар ма;
- кезек лимиті сұрау саны және күту уақыты бойынша қойылған ба;
- команда перегруз кезінде алдымен нені сөндіру керегін біле ме;
- трафик өскеннен кейін пулды қайта қарау уақыты белгіленген бе.
Соңғы тармақ жиі түсіп қалады. Трафик 20-30% өсті, ал пул сол күйі қалды, өйткені «әзірге көтеріп тұр». Бұл қымбат әдет: әуелі кідіріс құйрықтарын ұстайсыз, кейін асығыс түрде қорқыныштың үстінен тағы GPU қосасыз.
Егер сіз AI Router арқылы жұмыс істесеңіз, тексерудің бір бөлігін тезірек өтуге болады: деректерді аудит логтарынан алып, кілттер бойынша rate limits-ті қарап, бір клиенттің секірісін нақты өсімнен ажыратыңыз. Осындай салыстырудан кейін жылы пул әдетте ықшамырақ көрінеді, бірақ тынысы кең болады.
Әрі қарай не істеу керек
Есептен кейін бүкіл қорды бірден бекітпеңіз. Алдымен жүктемесі ұқсас бір модель тобын алыңыз, мысалы операторларға арналған чат немесе қызметкерлерге арналған ішкі көмекші. Осындай пилотта бағалау қай жерде сыр бергені тезірек көрінеді: жауап ұзақтығында ма, бір мезеттегі сұрау санында ма, әлде қыздыру уақытында ма.
GPU жүктемесіне ғана емес, күту бағасына да қараңыз. Кейде 2-5 секундтық кезек тағы бір тұрақты жылы инстанстан арзанырақ болады, әсіресе ол жарты ауысым бойы бос тұрса. Егер кідіріс сценарийді бұзбаса, шағын буфер көбіне артық резервтен тиімді.
Басында төрт қадам жеткілікті: 2-4 аптаға пилот қосып, кіріс сұраулар, жауап уақыты және генерация ұзақтығы бойынша логтарды жинау; пік сағаттардағы резерв құны мен қысқа кезек құнын бөлек есептеу; жергілікті ұстаған дұрыс сценарийлерді және сыртқы маршрутизацияға жіберу оңай сценарийлерді бөлу; бір айдан кейін алғашқы бағалауға емес, жаңа логтарға сүйеніп пулды қайта есептеу.
Мұндай бөлу артық шығынды тез алып тастайды. Жергілікті хостинг әдетте төмен кідіріс, болжамды баға және өз сақтау контуры маңызды жерде керек. Сыртқы маршрутизацияны сирек, қымбат немесе маусымдық модельдер үшін қолданған ыңғайлы, оларды күні бойы жылы күйде ұстап отырудың мәні жоқ.
Егер командаға деректерді Қазақстанда сақтау талабы болса, пилотты AI Router арқылы airouter.kz-та тексеруге болады. Сервисте бір OpenAI-үйлесімді endpoint бар, деректер ел ішінде сақталуы мүмкін, ал продакшен үшін аудит логтары, PII маскалау және кілт деңгейіндегі лимиттер қолжетімді. Бұл SDK мен кодты өзгертпей-ақ нақты сұрауларды өткізіп көруге, содан кейін қай модельдерді өз инфрақұрылымыңызда қалдырып, қайсысын шлюз арқылы жіберетінін шешуге ыңғайлы жол.
Бір айдан кейін сурет қарапайым болуы керек: керек сағаттарда кезек қысқарады, ал бос тұрып қалған GPU азаяды. Егер бұлай болмаса, жылы пулды автоматты түрде кеңейтпеңіз. Алдымен маршруттарды, лимиттерді, жауап ұзындығын және LLM-нің нақты қай сағатта пішін алып жатқанын тексеріңіз.
Жиі қойылатын сұрақтар
Қорды есептегенде не маңыздырақ: орташа трафик пе, әлде пик пе?
Күн ішіндегі орташа жүктемеге емес, минуттық қысқа пиктерге және P95 не P99 көрсеткіштеріне қараңыз. Дәл сол аралықтарда кезек ең жылдам өседі, әрі модельдің қанша жылы көшірмесі шыдайтыны сол жерде көрінеді.
GPU жетпей жатқанын қалай түсінуге болады?
Қарбалас минуттарда кезек, тайм-ауттар, сұрауларды қайталау және P95 кідіріс өссе, GPU жетіспей жатыр деген сөз. Орташа кідіріс көбіне тыныш көрінеді, тіпті кейбір пайдаланушылар тым ұзақ күтіп тұрса да.
Есепке дейін қанша уақыттық трафик тарихын жинау керек?
Алғашқы есеп үшін әдетте 2–4 апталық лог жеткілікті. Сол уақыт ішінде ауысымдар бойынша қайталанатын үлгілерді, түскі пиктерді, ай соңын және бір дүрлігуі бар күндерден бөлек қалыпты терезелерді көресіз.
Қорды неге тек минуттағы сұраулармен есептеуге болмайды?
Өйткені жауап ұзақтығы мен контекст көлемі жүктемені қатты өзгертеді. Бірдей сұрау ағыны қысқа жауаптарда жеңіл өтеді де, ұзын генерация кезінде GPU-ды тез толтырып тастауы мүмкін.
Модельді қашан жылы күйде ұстаған, ал қашан сұрау бойынша жүктеген дұрыс?
Жиі қолданылатын модельді сұраныс тұрақты сағаттарда жадта ұстаған дұрыс. Сирек модельді кесте бойынша, бірінші сұрау түскенде немесе сыртқы маршрутқа жіберген тиімді; әйтпесе карталар күннің көп бөлігінде бос тұрады.
Ең жоғары айлық пикке бөлек қор қосу керек пе?
Әдетте жоқ. Егер бір рет болған пик ақау, тарату немесе акция салдарынан шықса, оны қысқа кезекпен еңсеру күн сайын артық көшірмелерге ақша төлеуден арзанырақ.
Базалық есептің үстіне қандай резерв қосқан дұрыс?
Базалық есептің үстіне ұзақ жауаптар мен бір картаның істен шығуына арналған қорды қосыңыз. Тәжірибеде орташа пік үстіне қалыпты резерв жеткілікті болады, егер кезекті ұзындығы және күту уақыты бойынша шектесеңіз.
Модель ұзақ қызса не істеу керек?
Егер прогрев ондаған секундтан не минуттан асса, жұмыс сағаттарында кемінде бір көшірмені жылы күйде ұстаңыз. Әйтпесе қысқа пик жаңа көшірме кезекті түсіріп үлгермей аяқталып кетеді.
Чат пен batch-ті бір пулда араластырған дұрыс па?
Ондай жүктемелерді бөлген дұрыс. Чатқа жылдам жауап керек, ал batch күте алады; екеуін бір GPU-ға отырғызсаңыз, фондық өңдеу тірі диалогтарға кедергі жасап, қорды босқа үлкейтеді.
AI Router жылы пулды дәлірек есептеуге қалай көмектеседі?
Егер трафик AI Router арқылы өтсе, модельдер, маршруттар және қол жеткізу кілттері бойынша срездерді қараңыз. Сонда қай сценарий пик жасап тұрғанын түсіну оңай болады да, сұраныс жоқ жерде артық GPU-ды қыздырмайсыз.