Токендердің секірісі: релизден кейін шот келмей тұрып себебін қалай табуға болады

Токендер қашан проблемаға айналады

Өзінің өсуі бірден бұзылуды білдірмейді. Егер релизден кейін пайдаланушылар көбейіп, токендер шамамен сол 10-20% артса, бұл кәдімгі жүктемеге ұқсайды. Мәселе шығын пайдалы әрекеттен жылдамырақ өсе бастағанда пайда болады. Сұраныстар саны сол қалпы, ал бір сценарийге кететін токендер бір жарым-екі есе көбейеді.

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

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

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

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

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

Кәдімгі өсу сирек күрт сатылы секіріс сияқты көрінеді. Бұзылу дәл солай көрінеді: 11:40-та релиз шықты, 11:45-та бір сұранысқа кететін токендер 70% өсті, ал кешке есептегіш нормаға мүлде жақын емес болды. Мұндай жағдайда биллингті күтуге болмайды. Ауытқуды релиз күні-ақ ұстау керек.

Нақты не өскенін қалай түсінуге болады

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

Пайдалы формула қарапайым: токендердің жалпы көлемі = сұраныстар саны x бір сұранысқа кететін орташа токендер. Кейде екі көрсеткіш те аздап өседі де, бірге өте жағымсыз нәтиже береді. Егер шақырулар 30% көбейіп, ал орташа сұраныс ұзындығы 25% артса, жалпы шығын қазірдің өзінде апат сияқты көрінеді.

Күндер немесе сағаттар бойынша мына төрт көрсеткішті салыстырыңыз:

• бір сұранысқа шаққандағы input tokens
• бір жауапқа шаққандағы output tokens
• пайдаланушыға, экранға немесе тапсырмаға шаққандағы сұраныс саны
• өнімдегі бір әрекетке шаққандағы сұраныс саны

Егер input токендер өссе, ең алдымен промпт ұзындығын тексеріңіз. Релизден кейін жүйелік промпт байқатпай үлкейіп кетеді: жаңа ережелер қосылды, схема бар үлкен JSON пайда болды, tool calling үшін ұзақ нұсқаулар қосылды, чат тарихынан көбірек хабарлама жіберілді немесе білім базасынан артық бөліктер кетті. Ең жағымсыз жағдай — қолданба бұрын соңғы 3-5 хабарлама жеткілікті болған жерде бүкіл әңгімені толық жібере бастағанда.

Егер input шамамен өзгермесе, жауап ұзындығына қараңыз. Модель жаңа шаблонға, басқа модельге, max_tokens шектеуінің алынуына немесе жалпы нұсқауларға байланысты ұзақ жауап бере бастауы мүмкін. Бұрын екі-үш жол жететін тапсырма кенет 400-600 токендік түсіндірмеге айналады.

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

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

Шығынды бақылау үшін сценарийлер бойынша қарапайым кесте ұстаған пайдалы: бір әрекетке шаққандағы сұраныстар, бір сұранысқа кететін input токендер және бір жауапқа кететін output токендер. Көбіне бір баған бірден не дұрыс емес екенін көрсетеді.

Релизден кейін не жиі бұзылады

Релизден кейін токендер себепсіз өспейді. Әдетте тесттерде байқалмай қалған ұсақ баптау бұзылады.

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

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

Релизден кейін бұл жиі SDK, мобильді қолданба немесе бэкендтегі жаңа retry саясатына байланысты болады. Егер ешкім таймауттар санын қайталама шақырулар санымен салыстырмаса, токендердің секірісін жүктеме өсуімен шатастыру оңай.

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

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

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

• релизге дейінгі және кейінгі орташа input пен output ұзындығын салыстыру
• бірдей идентификаторы немесе денесі бар қайталама сұраныстарды табу
• бірнеше нақты промптты ашып, ішіне логтар, JSON немесе артық тарих кіріп кетпегенін тексеру
• модель өзгермегенін және жауап ұзындығының лимиті жоғалмағанын растау

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

Себебін қадамдап қалай тексеруге болады

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

Ең жылдам жол — бірдей сценарий бойынша релизге дейінгі және кейінгі орташа input және output tokens мәндерін салыстыру. Егер input өссе, жаңа жүйелік промптты, артық контекстті, чат тарихын немесе құжаттардың қайталануын іздеңіз. Егер output өссе, жауап лимитін, шығару форматын және қолданба ұзақ түсіндіруді сұрап отыр ма, соны тексеріңіз.

Кейін трафикті түсінікті бөліктерге бөліңіз:

1. Релизге дейінгі 24 сағат пен одан кейінгі 24 сағатты бір сұранысқа кететін орташа токендер бойынша салыстырыңыз.
2. Деректерді эндпоинттер, модельдер және API кілттері бойынша бөліңіз.
3. Уақыттағы секірісті deploy-ға, feature flag-қа немесе басқа модельге маршрут ауысуына байлаңыз.
4. 20-50 нақты сұранысты алып, промптқа шынымен не кіргенін қараңыз.
5. Ретрайларды, таймауттарды және бір әрекеттің параллель шақыруларын тексеріңіз.

Үшінші қадамда жиі ешкім күтпеген себеп табылады. Мысалы, бір флаг RAG-ті тек пайдаланушылардың бір бөлігіне ғана қосып жіберіп, промптқа 3 қысқа фрагменттің орнына 12 ұзын үзінді түсе бастады. Графикте бұл жалпы секіріс сияқты көрінеді, ал мәселе бір ғана ағынның ішінде жатыр.

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

Сосын шақыру механикасын тексеріңіз. Релизден кейін қолданба таймаут кезінде сұранысты қайталауы, бір емес екі параллель шақыру іске қосуы немесе кезек арқылы қайталау жіберуі мүмкін. Сырттай бұл кәдімгі жүктеме сияқты көрінеді, бірақ LLM шақыру жиілігі бір жарым-екі есе өскен.

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

Қандай метрикаларды көз алдыңызда ұстау керек

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

Бірінші қабат — бір сұранысқа кететін токендер. Input пен output-ты бөлек қараңыз. Бір сұранысқа шаққандағы input tokens өссе, бұл көбіне ұзын жүйелік промптты, артық контекстті, чат тарихындағы дубликаттарды немесе бұрынғыдан көбірек дерек жіберетін жаңа логиканы білдіреді. Output tokens өсуі көбіне модельдің егжей-тегжейлі жауап бере бастағанымен, жауап ұзындығы лимитінің істемей қалуымен немесе қолданбаның артық қосымша генерациялар жасауымен байланысты.

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

Жұмыс істейтін метрикалар жинағы әдетте мынадай:

• модель және сценарий бойынша бір сұранысқа шаққандағы input tokens
• p50 және p95 мәндерімен бір сұранысқа шаққандағы output tokens
• сервис, API кілті және маңызды маршруттар бойынша минутына сұраныс саны
• 429, 500 және таймауттан кейінгі retry-ді қоса алғандағы қате мен қайталау үлесі
• тек күндік жалпы шығын емес, модель және сценарий бойынша шығын

Қате метрикасы есеп үшін емес, ақша үшін керек. Егер релизден кейін 429 немесе 5xx үлесі өссе, клиенттер мен фондық тапсырмалар жиі қайта шақыра бастайды. Таймауттармен де солай: бір пайдаланушы сұранысы екі не үш LLM операциясын туындатуы мүмкін.

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

Командалар көбіне қай жерде қателеседі

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

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

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

Ұзын debug prompt продта ойлағаннан жиі кездеседі. Оны көбірек контекст жинау үшін екі-үш сағатқа қосады: шикі логтар, хабарламалардың толық тарихы, қызметтік нұсқаулар, жауап мысалдары. Сосын fix шығып кетеді, ал артық мәтін қалып қояды. Егер жүйелік промпт 900-ден 3500 токенге өссе, трафик өспесе де шот өте тез ұшады.

max_tokens шектеулерін және ретрайларды командалар да жиі ұмытады. Бір сәтсіз релиз оңай қымбат циклді іске қосады: модель керек жауап бермейді, қолданба 3-4 рет қайталайды, әр жолы сол ұзын контекстті жібереді және үстіне тым ұзақ жауап сұрайды. Логта бұл жай ғана тұрақсыздық сияқты көрінеді. Шотта — бөлек шығын бап.

Деректерді бір санмен емес, бірнеше кесіндімен бөлу пайдалы: prompt пен completion бөлек, prod пен test бөлек, сәтті жауаптар мен ретрайлар бөлек, релиздің жаңа және ескі нұсқалары бөлек, пайдаланушы, фича немесе cron-задача бойынша шыңдар бөлек.

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

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

Жұмыс аптасынан бір қарапайым мысал

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

Алдымен мәселе тек ұзағырақ жауаптарда шығар деп ойлады. Шынында да, орташа жауап айтарлықтай үлкейді: бұрынғы 120-150 токеннің орнына көмекші жиі 400-500 токенге дейін кететін. Себебі қарапайым еді: промптқа "жақсырақ түсіндіріп, келесі қадамды ұсын" деген нұсқау қосылған. Мұның өзі жағымсыз, бірақ апат емес.

Сосын шақыру жиілігін қарап, одан да қымбат қатені тапты. Фронтендті түзеткеннен кейін сұраныс батырманы басқанда емес, пайдаланушы терген әрбір таңбаға жуық кетіп тұрған. Адам 40 таңбалық сөйлем терсе, жүйе ондаған шақыру жіберіп үлгеретін. Пайдаланушы бір ғана диалогты көрді, ал бэкенд артық өтініштердің тұтас сериясын өңдеді.

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

Бір сағаттың ішінде бірнеше метрика бірдей өсті:

• бір сұранысқа кететін токендер
• бір пайдаланушыға шаққандағы сұраныстар саны
• бірдей мәтінмен қайталанатын шақырулар үлесі

Дәл осындай байланыс ең жағымсыз шотты жасайды. Бір үлкен промпт емес, бірін-бірі күшейтетін бірнеше ұсақ қате.

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

Алерт алдында не тексеру керек

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

Бірнеше қарапайым сұрақтан бастаңыз. Қазіргі system prompt алдыңғы нұсқадан ұзынырақ болып кеткен жоқ па? Модельге соңғы 6-8 хабарламаның орнына бүкіл диалог тарихы кетіп жатқан жоқ па? max_tokens өзгерген жоқ па? Жаңа cron, batch немесе фондық тапсырма қосылған жоқ па? 429, 500 және таймауттан кейін қайталанулар пайда болған жоқ па?

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

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

Әрі қарай не істеу керек

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

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

Әдетте төрт ереже жеткілікті:

• бір сұранысқа кететін токендер мен минутына сұраныстарды бөлек бақылау
• әр сценарий үшін максималды жауап ұзындығын шектеу
• рұқсат етілетін retry санын бекіту
• әр релизден кейін аномалияларды қысқа чек-листпен талдау

Лимиттерді оқиға болғаннан кейін емес, алдын ала қойған дұрыс. Көп командада секіріс бір үлкен қателіктен емес, бірден екі ұсақ қатеден пайда болады: жауап 40% ұзарды, ал клиент артық retry жасай бастады. Екеуі бірге-ақ шығынды бірнеше сағат ішінде-ақ айтарлықтай өсіреді.

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

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

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