LLM-сервисті жүктемелік тестілеу: пик, кезектер, тар жерлер

Пикте не бұзылады

Пик кезінде тек модельдің жауап беру уақыты ғана ұзармайды. Сұрау көбіне модельге жеткенше-ақ кідіріп қалады. Шлюз кілтті тексереді, rate limit қолданады, PII-ді жасырады, аудит-лог жазады, модельге дейінгі маршрутты таңдайды да, содан кейін ғана сұрауды әрі қарай жібереді. Осы қадамдардың кез келгені 50-100 мс-қа баяуласа, жалпы кідіріс тез ұлғая бастайды.

Мұндай жағдайда орташа latency іс жүзінде пайдасыз. Ол қысқа секірістерді тегістеп, кезекті жасырады. Графикте бәрі тыныш сияқты көрінеді: орта есеппен 2,3 секунд. Бірақ кейбір пайдаланушы 8-12 секунд күтіп отырады немесе таймаут алады. Сондықтан жүктемелік тестте тек average емес, p95, p99 және таймауттар үлесі де қаралады.

Кезек сирек бір жерде ғана жиналады. Ол API-шлюзде, базаға арналған connection pool-да, лог жазу кезегінде, тіпті postprocessing worker-лерінде де жинала береді. Көбіне бәрі екінші қатардағыдай көрген қадам дәл шектейді. Аудит немесе контент белгілеу кезегі өсіп тұрғанда, процестер жад ұстап қалады, қосылымдар босамайды, ал бірнеше минуттан соң жүйе модельдің өзі үлгермей жатыр сияқты әсер береді. Шын мәнінде модель бұрынғы қарқынмен жауап бере беруі мүмкін.

Ретрайлар картинаны өте тез нашарлатады. Бір таймаут қайталау іске қосады, сосын тағы біреуі, сөйтіп трафик екі-үш минут ішінде 10% емес, шамамен екі есе өседі. Егер клиент, SDK және шлюз сұрауды бөлек-бөлек қайталай берсе, жүйе пикті өзі үдетеді. Сырттан қарағанда бәрі қарапайым: кідіріс өседі, сосын қателер үлесі көбейеді, ал кейін кіріс ағыны азайғаннан кейін де кезек кетпей қояды.

Көбіне бүкіл сұрауды бір баяу этап тоқтатады. Мысалы, модель токендерді тұрақты береді, бірақ сервис PII-ді маскалау үшін немесе аудитті жергілікті қоймаға жазу үшін бос worker күтумен ұзақ отырады. Пайдаланушы баяу LLM API көреді, ал тар жер модельде емес, айналасындағы қабатта жатады.

Пикте ең қымбат компонент емес, ең тар компонент сынады. Сондықтан жақсы прогон жүйе кезекті сіз өңдеп үлгергеннен жылдамырақ өсіре бастаған сәтті іздейді.

Қандай сценарийлерді сынау керек

Жүктемелік тест үшін бір ғана "орташа" сұрау жеткіліксіз. Пикте жүйе сіз күткен жерден емес, басқа жерден бұзылады: қысқа чаттар дұрыс өтеді, ал ұзын жауаптар кезекті бітейді. Streaming тұрақты тұрады, ал tool calling backend-тегі операциялар санын күрт көбейтеді.

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

Қысқа чат пен жылдам жауап кез келген сервисте керек дерлік: қолдау, ішкі ассистент, білім базасынан іздеу. Ол жүйе қанша сұрауды артық кідіріссіз көтере алатынын көрсетеді.

Ұзын контекст пен үлкен шығару мүлде басқа проблемаларды ашады. Пайдаланушы келісімшартты немесе ұзақ хат алмасуды жүктеп, 1500-2000 токендік қорытынды сұрайды. Мұндай тест генерация уақытының, жадтың және кезектердің өсуін тез көрсетеді.

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

Обычный жауаптар мен tool calling араласқан поток та міндетті. Модель іздеу, CRM немесе калькуляторға жүгінгенде, бір сұрау бірнеше операциядан тұратын тізбекке айналып кетеді.

Соңында күрт burst те керек. Біртіндеп өсіру емес, жіберілімнен, пуш-хабарламадан немесе жұмыс күні басталғаннан кейінгі секіріс. Дәл осындай режим rate limit-ті, балансировщикті және connection pool-ды жиі сындырады.

Тәжірибелік шаблон былай көрінеді: 70% қысқа чат, 20% үлкен жауаптары бар ұзын сұраулар, 10% tool шақыруы бар сұраулар. Бұдан кейін burst қосыңыз: екі минут ішінде кіріс ағынын 3-5 есе көтеріп, бірінші не деградацияға ұшырайтынын қараңыз.

Сұрауды тоқтату мен қайта жіберуді бөлек тексеріңіз. Пайдаланушылар жиі "стоп" басады, промптты өзгертеді де, қайта іске қосады. Егер сервис ескі қосылымдарды тез жаппаса, орташа RPS болса да, жасырын жүктеме пайда болады.

Егер сіз AI Router сияқты шлюз арқылы жұмыс істесеңіз, тек модельдің өзін сынаумен шектелмеңіз. Сол сценарийлерді streaming арқылы, сыртқы провайдерге маршрутизациямен және өз hosted-моделіңізде өткізіңіз. Сонда жүйенің қай жері әлсірейтіні бірден көрінеді: генерацияда ма, proxy қабатында ма, аудит-логтарда ма, PII маскалауда ма, әлде tools үшін сыртқы backend-те ме.

Бірінші прогонға дейін нені өлшеу керек

Тестке дейін бір ғана санды емес, метрикалар жиынтығын бекітіп алыңыз. Тек RPS ештеңе айтпайды. LLM-сервис үшін секундына сұрау саны да, бір мезеттегі сұраулар саны да маңызды. Жүйе қысқа жауаптармен 20 RPS-ты еркін ұстап, дәл сол 20 RPS-та ұзын генерация кезінде құлап қалуы мүмкін.

Бірінші токенге дейінгі уақыт пен жауаптың соңына дейінгі уақытты бөлек өлшеңіз. Пайдаланушы үшін бұл екі түрлі кідіріс. Егер бірінші токен тез келсе, интерфейс ұзақ жауапта да тірі сияқты көрінеді. Егер TTFT өссе, проблема көбіне модельде емес, оның алдында жатады: балансировщикте, роутингте, кілтті тексеруде, PII маскалауда немесе GPU алдындағы кезекте.

Кезекті де дашбордтағы бір жолмен емес, кезең-кезеңімен көру керек. Көбіне бес нүкте жеткілікті: API-ге кіру, роутинг және модельді таңдау, препроцессинг кезегі, инференс кезегі, postprocessing және logging. Сонда қай жерде құйрық жиналып жатқанын бірден түсінесіз. Егер кезек тек инференс алдында өссе, GPU шегін немесе провайдер лимитін іздеңіз. Егер сұраулар модельге жетпей тұрып-ақ тұрып қалса, CPU, желі, rate limit, логтар базасы және кірістегі барлық синхронды тексерулерді қараңыз.

Қателерді де түріне қарай бөлу пайдалы. 429, таймауттар және 5xx клиент үшін ұқсас көрінеді, бірақ әртүрлі емделеді. 429 көбіне кілт, провайдер немесе модель пулындағы лимитті білдіреді. Таймауттар ұзын жауаптарды, баяу ретрайларды және тығыз желіні жақсы көреді. 5xx көбіне proxy, worker, logging немесе сыртқы тәуелділік істен шыққанда пайда болады.

Кіріс пен шығыс өлшемін токенмен белгілеу дерлік барлық метрика үшін керек. Онсыз бірдей жүктеменің неге әртүрлі жүргенін түсіну қиын. 300 кіріс токені және 150 шығыс токені бар сұрау — бір класс жүктеме. 8000 кіріс токені және ұзын генерациясы бар сұрау — мүлде басқа класс.

Тағы іске қоспай тұрып CPU, GPU, желі және диск жүктемесін түсіріп алыңыз. Орташа мәнге ғана емес, пиктерге де қараңыз. Диск жиі ұмытылады, бірақ дәл сол аудит-логтарды, кэшті және трассировка жазбасын баяулатуы мүмкін. Егер сізде AI Router сияқты маршрутизация қабаты болса, метрикаларды провайдер, өз GPU-инфрақұрылымы және нақты модель бойынша бөлу пайдалы. Әйтпесе тек "орташа температураны" көресіз.

Жүгіру жоспарын қалай құрастыру керек

Бастауды абстракт RPS-тен емес, нақты трафиктен жасаған дұрыс. Қарапайым күн мен ең тығыз сағаттың логтарын алыңыз. Орташаға емес, сұрау профиліне қараңыз: қысқа чат қанша, ұзын диалог қанша, құжатпен бірге келетін сұрау қанша, таймаутпен үзілетін сұрау қанша.

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

Одан кейін трафикті топтарға бөліңіз. LLM үшін бұл жалпы көлемнен маңыздырақ. 200 токендік сұрау мен 20 000 токендік сұрау жүйені мүлде басқаша жүктейді, бірақ екеуі де бір API шақыруы болып саналады.

Жұмыс жоспары әдетте былай көрінеді:

1. Логтардан 3-5 сұрау түрін таңдаңыз: қысқа чат, ұзын чат, үлкен контексті бар RAG, batch-тапсырма, streaming генерация.
2. Әр түр үшін кіріс ұзындығы мен жауаптың әдеттегі көлемін бекітіңіз. Орташа мәнмен шектелмей, ауыр құйрықты да қалдырыңыз.
3. Екі жүктеме деңгейін қойыңыз: қалыпты және пик. Біріншісі базаны береді, екіншісі жүйе қай жерде сыр беретінін көрсетеді.
4. Прогревті бөлек этапқа шығарыңыз. Алдымен қосылымдарды, кэшті, worker pool-ды және модельді қыздырып алыңыз, сосын негізгі прогонды бастаңыз.
5. Ағынды сатымен көтеріңіз, мысалы әр 5-10 минут сайын. Бірден секіру көп шу береді, бірақ кезек басталатын сәтті нашар көрсетеді.

Сатылар шек нүктесін көруге көмектеседі. Оған дейін latency біртіндеп өседі. Одан кейін p95 пен қателер саны бірден жоғары көтеріледі. Дәл сол жерді тереңірек қазу керек: кіріс кезегі, провайдер лимиті, баяу retrieval, қызып кеткен GPU немесе тар connection pool.

Нақты пик сағатына ұқсайтын бір сценарийді қосқан пайдалы, лабораториялық жүктемені емес. Мысалы, 70% қысқа қолдау сұрауы, 20% құжаттар бойынша RAG, 10% ұзын аналитикалық сұрау. Мұндай қоспа бір ғана "орташа" сұрауды прогон жасағаннан гөрі шынайырақ сурет береді.

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

Күрделі математикасыз кезекті қалай есептеу керек

Кезек жүйеге келетін жұмыс оны аяқтаудан жылдам болғанда өседі. Алғашқы есеп үшін екі сан жеткілікті: келу жылдамдығы мен өңдеу жылдамдығы. Егер сізге секундына 50 сұрау келіп, ал сервис 40-ын ғана аяқтаса, кезек секундына 10 сұрауға өседі. Бір минутта 600 сұрау жиналады.

Бұл ереже тестте де, продакшнда да жұмыс істейді. Орташа кідіріс алдымен қалыпты болып көрінуі мүмкін, бірақ құйрық тез бұзылады. Пайдаланушы мұны RPS графигінен көрмейді, бірақ 20-30 секундтық жауап арқылы сезеді, ал әдетте 3-5 секунд жеткілікті еді.

Тек сұрауларға емес, токендерге де қараңыз. 20 RPS болатын екі поток жүйені мүлде басқаша жүктеуі мүмкін. 200-300 токендік қысқа сұраулар оңай өтеді, ал үлкен контексті бар ұзын генерация RPS өзгермесе де, модельді бітеп тастайды.

Төрт этапты бөлек есептеген ыңғайлы: авторизация мен rate limit бар сұрауды қабылдау, роутинг, PII маскалау және база бойынша іздеу сияқты модельге дейінгі қадамдар, модельдің өзі prompt tokens/s және completion tokens/s-пен, содан кейін контентті тексеру, logging, қаптау және жауапты жіберу сияқты модельден кейінгі қадамдар. Сонда тығын қайда екенін тез көресіз.

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

Сұраудың кезекте қанша өмір сүретінін қараңыз, тек онда қанша сұрау жатқанын емес. Қарапайым бағалау мынадай: егер кезекте 400 сұрау болып, ал этап секундына 40-ын өңдесе, жаңа сұрау шамамен 10 секунд күтеді. Бұл шамамен ғана, бірақ алғашқы есепке жетеді.

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

Модельден басқа тар жерді қайдан іздеу керек

Көбіне кідірісті модель емес, оның айналасындағы тізбек береді. Сұрауды этаптарға бөліп қарасаңыз, қай жерде құйрық жиналатыны тез көрінеді: API-шлюзге кіру, кілтті тексеру, контекст іздеу, модель шақыру, жауапты тексеру, logging және клиентке жіберу.

API-шлюз жиі бірінші болып шектеледі. Пикте кілт, квота және key-level rate limit бойынша қарапайым тексерудің өзі әр сұрауға 20-50 мс қосуы мүмкін. Бір сұрауда бұл байқалмайды, бірақ жүздеген бір мезеттегі шақыру кезінде мұндай ұсақ нәрсе модель алдындағы кезекке тез айналады.

RAG-поиск та күткеннен көп уақыт алады. Векторлық іздеу, rerank, құжаттарды оқу және ұзын контекст жинау бірінші токенге дейін-ақ бір секундты оңай алып қояды. Егер модель тұрақты жауап беріп, p95 өсіп жатса, себеп база, кэш немесе prompt жинағышта болуы мүмкін.

Postprocessing инференстен кем емес өткізу қабілетін жейді. JSON-валидация, ұзын жауаптарды парсингтеу, схема тексеру, фильтрлер, тіпті үлкен ағынға салынған қарапайым regex-тер CPU мен жадты жүктейді. Команда көбіне тек GPU-ға қарайды, ал валидациясы бар бір сервис бүкіл контурдың RPS-ын едәуір қысқарта алады.

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

Провайдер лимиттері де суретті бұзады. Сіздің серверлер жүктемені жай көтеріп тұрғанымен, сыртқы провайдер RPM немесе TPM-ге ертерек тіреліп, 429 қайтарады немесе уақыт созады. Бір шлюз бар схемада локал өңдеуге кеткен уақытты және upstream уақыты бөлек түсірген пайдалы. Әйтпесе қате қабатты оңай айыптап қаласыз.

Желіні бұрынғыдан сирек тексереді, ал ол соған тұрарлық. DNS, TLS handshake, keep-alive жоқ қысқа қосылымдар, аймақтар арасындағы артық секірістер және баяу балансировщик жағымсыз, үзік құйрық береді. Әсіресе бұл қысқа сұрауларда жақсы көрінеді: модель тез жауап береді, ал уақыттың көбі қосылуға кетеді.

Дәл қай жер тар екенін қалай түсінуге болады

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

Сосын контур бөліктерін бір-бірден ажыратыңыз: RAG, logging, PII маскалау, JSON-валидация. Мұндай тест жалпы latency графигіне қарағанда әлдеқайда шынайы жауап береді.

Бір trace ішінде этаптар бойынша тайминг алыңыз: gateway, auth, retrieval, upstream, postprocess, logging, response flush. Егер model latency бірқалыпты болып, ал gateway-дегі queue 30-дан 300 сұрауға өссе, тар жер табылды деуге болады.

Пик сағатының мысалы

Сағат 19:00-де интернет-дүкен акция бастайды да, трафик бірнеше минуттың ішінде өзгереді. Басталғанға дейін сервис, мысалы, минутына 40 сұрауды ұстап тұрған. Push пен email жіберілгеннен кейін ағын тез 500-700-ге өседі, бірақ сұраулар бірдей болмай қалады.

Адамдардың шамамен жартысы жеткізу туралы қысқа сұрайды: "Қашан келеді?", "Өзі барып ала аламын ба?", "Бөліп төлеуге бола ма?" Мұндай жауаптар қысқа, сондықтан модель оларды оңай көтереді. Қалған бөлігі ұзын сипаттама бойынша тауар таңдауды сұрайды: "Дизайн үшін ноутбук керек, мынадай сомаға дейін, тыныш салқындатуы бар, батареясы мықты". Мұнда сұрау ұзағырақ, prompt-қа көбірек контекст кетеді, ал RAG көбіне каталог пен қалдықтар базасын іздейді.

Сол уақытта операторлар да күтпейді. CRM менеджерлер қысқа қорытуын көруі үшін диалогтарды суммаризацияға жібере береді. Модель үшін бұл қалыпты жұмыс. Бүкіл жүйе үшін — бірдей кезектерді, бірдей worker-лерді және көбіне логтарға арналған бірдей базаны жейтін тағы бір ағын.

19:03-та модель бұрынғыдай жылдам жауап береді. 19:05-та контексті каталогтан іздеу кезегі өседі. 19:07-де logging оқиғалар тасқынына байланысты баяу жаза бастайды. 19:10-да пайдаланушылар кідірісті сезіп үлгереді, ал GPU әлі шегіне жеткен жоқ.

Жүктемелік тесттің мәні де осында. Егер RAG этапы секундына 80 сұрауды ғана өңдей алса, ал оған 100 келсе, кезек әр секунд сайын 20 сұрауға өседі. Бір минуттан кейін күту режимінде 1200 сұрау жиналады. Модельдің өзі осы кезде "сау" болып қала беруі мүмкін: оның p95-і іс жүзінде өзгермейді, ал пайдаланушыдағы толық жауап кідірісі 2-3 секундтан 10-15 секундқа дейін өседі.

Ең жағымсыз әсер — қысқа жеткізу сұрақтары да баяулай бастайды. Олар арзан, бірақ ауыр тауар таңдауларымен және диалог суммаризациясымен бір жалпы кезекте тұрады. Егер logging синхронды жазса, ал жеке деректерді маскалау сол бір pipeline ішінде жүрсе, кідіріс одан сайын өседі.

Мұндай пик сағатта тар жер көбіне модельде емес. Әдетте ол контекст іздеуде, логтарда, базаға арналған connection pool-да немесе жылдам және ауыр тапсырмаларды араластырған ортақ worker pool-да жатады.

Тесттегі жиі қателер

Көп команда әдемі график алады да, нақты жүктемеде бәрібір қателеседі. Себебі әдетте біреу-ақ: тест live traffic-ке емес, лабораторияға ұқсайды.

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

Сол себепті команда "қалыпты" орташа latency-ді көріп, тынышталып қалады. Бірақ пайдаланушыны орташа емес, құйрық ұрады: p95, p99, таймауттар және қате секірістері. Егер сұраулардың 90%-ы тез, ал 10%-ы 20 секунд күтсе, сервис қазірдің өзінде бұзылғандай көрінеді.

Тағы бір қате — клиент пен SDK-ның өздері ретрай жасайтынын ұмыту. Графикте сіз секундына 100 сұрау көресіз, ал шын мәнінде жүйе 130 немесе 150 алады, өйткені кейбір шақыру таймауттан кейін қайта жіберілген. Кезек күрт өседі де, себебі тек модельде сияқты көрінеді. Шындығында жүктемені дәл сол қайталаулар ұлғайтады.

Проблемалар жиі модельден тыс жатады. Командалар тек инференсті тестілеумен шектеледі, бірақ сұраудың толық жолын емес: балансировщик, API-шлюз, авторизация, PII маскалау, аудит-логтар, rate limit, провайдерге дейінгі желі және стримді клиентке қайтару. Егер компания бір OpenAI-үйлесімді шлюз арқылы жұмыс істесе, тест модельді вакуумда шақырумен емес, толық маршрутпен жүруі керек.

Жеке тұзақ — провайдер лимиттері мен желі. Сіздің жүйе пикті ұстап тұрса да, сыртқы провайдер RPS-ті, минуттағы токен санын немесе бір мезеттегі сұрауларды шектей алады. Әр hop-тағы бірнеше қосымша миллисекунд та кезекке жиналып қалады.

Соңында, кэштенген және кэштенбеген трафикті бір үйіндіге араластырмаңыз. Егер тесттің жартысы prompt cache-ке түссе, сандар тым әдемі көрінеді. Кейін релиз шығады, кэш суиды да, кідіріс кенет екі есе өседі. Әр профильді бөлек есептеп, әрқайсысында құйрық қалай өзгеретінін қараған әділ.

Жүктемелік тест тек жүйеңіздің кәдімгі күніне ұқсаса ғана жұмыс істейді, ыңғайлы синтетикалық прогонға емес.

Релиз алдындағы жылдам тексеріс

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

Қолыңызда трафиктің екі профилі болсын. Біріншісі қалыпты жүктемені көрсетеді: prompt-тың орташа өлшемі, үйреншікті жауап ұзындығы, сұраулардың бірқалыпты ағыны. Екіншісі пикті имитациялайды: бір мезеттегі сессиялар көбірек, күрт секірістер, ұзын жауаптар және JSON-шығару немесе үлкен модельді шақыру сияқты ауыр операциялар үлесі. Егер бір ғана орташа сценарий болса, тест көбіне тым тыныш сурет сызады.

Жүктемені шығармай тұрып мына қысқа чек жеткілікті:

• әр этапта бөлек кезек көрінеді: кіріс шлюзі, PII маскалау, роутинг, провайдер немесе өз модельді шақыру, logging;
• команда бір мезеттегі сұраулардың шегін "шамамен" емес, нақты санмен біледі;
• timeout-тар әр қадамға нақты қойылған: қосылымға, бірінші токенге және толық жауапқа;
• ретрайлар upstream баяулап кетсе, шторм тудырмайды;
• мониторинг тек орташа latency-ді емес, құйрықты, 429-ды және 5xx-ті де ұстайды.

Кезектерді жалпы бір сызықпен емес, этаптар бойынша тексерген ыңғайлы. Егер жалпы latency 4-тен 12 секундқа өссе, себеп модельде болмауы мүмкін. Көбіне уақыт одан бұрын кетеді: сұрау бос worker күтеді, провайдер rate limit-іне тіреледі немесе postprocessing-та тұрып қалады. LLM-шлюзі бар схема әсіресе осыны айқын көрсетеді: модельдің өзі тұрақты жауап бере алады, ал тар жер роутингте, кілт лимиттерінде немесе сыртқы провайдерде жасырынып тұрады.

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

Прогоннан кейін не істеу керек

Орташа latency-ге емес, бірінші боп тұрып қалған этапқа қараңыз. Кейде модель баяу жауап береді, бірақ көбіне алдымен кіріс limiter-і, connection pool, worker кезегі, logging немесе audit сақтау орны беріледі. Сәтсіздік нүктесін санмен бекітіңіз: қай RPS-та немесе қанша бір мезеттегі сұрауда кезек өсті, қайда таймауттар басталды және қай компонент бірінші болып қате шашты.

Сосын апатты өзі үдететін нәрсені алып тастаңыз. Артық ретрайлар көбіне жағдайды одан сайын нашарлатады: бір баяу жауап үш жаңа сұрауға айналып, жүйені кез келген пиктен де тез бітеп тастайды. Егер кезек қауіпсіз шектен асып кетсе, backpressure қосыңыз: жаңа тапсырмаларды қабылдауды қысқартыңыз, 429 немесе 503-ті ертерек беріңіз, кезекте күту үшін қысқа timeout қойыңыз және сұрауды 30-60 секунд бойы "сәті түседі" деп ұстамаңыз.

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

Прогоннан кейін көбіне төрт шешім жеткілікті:

1. Клиентте және шлюзде автоматты ретрайларды шектеу.
2. Кезек ұзындығына қарай backpressure енгізу, таймаут күтіп отырмай.
3. Қысқа және ұзын сұрауларға бөлек маршруттар жасау.
4. Модельдер арасындағы fallback пен кілт деңгейіндегі лимиттерді қайта тексеру.

Fallback-ты бөлек тестілеу керек. Оның "өзінен өзі істеп кететініне" сенуге болмайды. Негізгі модель баяуласа, резервтік маршрут бағаны екі еселеп жібермеуі, жауап форматын бұзбауы немесе бүкіл трафикті сол провайдерге басқа alias арқылы қайта жібермеуі тиіс. Кілт деңгейіндегі лимиттер де маңызды: бір шуылдақ клиент қуатты оңай жеп, басқалардың SLA-сын бұза алады.

Кішкентай мысал: егер трафиктің 80%-ы 300 кіріс токенге дейінгі қысқа сұраулар болса, ал 20%-ы бірнеше мың токендік ұзын тапсырмалар болса, оларды бір пулда ұстау көбіне жақсы идея емес. Кезектерді бөлу модельді ауыстырмай-ақ айтарлықтай нәтиже беруі мүмкін.

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