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

Неліктен шот ескертусіз өседі

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

Жиі себептердің бірі - трафиктің өсуі, бірақ метрикаларға жеткілікті назар аударылмауы. Өнім жаңа сценарийді іске қосты, команда қолжетімділікті тағы бір бөлімге ашты, пайдаланушылар «қайталау» батырмасын жиірек баса бастады. Сұраулар саны 15-20% өсті, ал токендерге арналған айлық бюджет қайта есептелмеді.

Екінші себеп - сұраулар мен жауаптардың ұзаруы. Бұл көбіне үнсіз жүреді. Промптқа жаңа нұсқаулар қосылады, хабарламаға диалог тарихы тіркеледі, RAG ұзақ құжат үзінділерін араластыра бастайды. Модель одан да егжей-тегжейлі жауап берсе, шығын бірден екі жақтан өседі: кіріс те, шығыс та токендер көбейеді.

Артық шығынның онша байқалмайтын тағы бір көзі - қайталанған сұраулар. Таймауттар, ретрайлар, кезектен келген дубликаттар, ұзақ жүктелуден кейін фронтендтен қайта жіберу. Пайдаланушы бір жауапты көреді, ал жүйе модельге екі не үш рет барып келуі мүмкін. Айлық есепте бұл «күтпеген» өсім сияқты көрінеді, бірақ ақша нақты шақыруларға жұмсалды.

Модельдер қоспасын да бөлек бақылаған жөн. Қымбат модель трафиктің аз ғана бөлігін алса да, бүкіл айлық шығынды едәуір өзгертіп жіберуі мүмкін. Айталық, сұраулардың 90% арзан модельге түседі, ал 10% fallback, эксперимент немесе жаңа маршрут салдарынан қымбатырақ модельге кетеді. Егер сол 10% ұзақ контекстпен жұмыс істесе, бір сұраудың орташа құны өте жылдам өседі.

Бұл көбіне барлық шақыру бір OpenAI-үйлесімді шлюз арқылы өтетін командаларда болады. Сырттай интеграция өзгермейді, бірақ іште маршрут, fallback немесе лимиттер өзгеруі мүмкін. Даму үшін бұл ыңғайлы. Ал күнделікті бақылаусыз бюджет үшін бұл тәуекел.

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

Күн сайын қандай сандарды көру керек

Тек жалпы соманы қарасаңыз, артық шығын тым кеш байқалады. Қалыпты болжам үшін күнделікті кесінді керек: онда тек сома емес, өсімнің себебі де көрінуі тиіс. Әйтпесе бір релиз немесе бір шуылдақ API-кілт апталық қорды екі-ақ күнде жұмсап қояды.

Ең аз дегенде мына метрикаларды бір кестеде немесе бір дашбордта ұстаған дұрыс:

• input және output токендері бөлек
• күніне шақыру саны
• қателер мен қайталанған сұраулар
• модельдер, командалар және API-кілттер бойынша шығын
• әр модельдің нақты құны

Input және output токендерді әрдайым бөлек қарастырған дұрыс. Input өсуі әдетте сұрауларға көбірек контекст, чат тарихы немесе қызметтік мәтін қосылғанын білдіреді. Output өсуі көбіне басқа нәрсені көрсетеді: модель ұзақ жауап бере бастады. Дәл осы нәрсе шотты ең тез үлкейтеді.

Шақыру санын токендермен қатар қараңыз. Егер сұраулар 10% өсіп, токендер 60% артса, мәселе трафиктің өзінде емес. Демек, әр шақыру ауырлай түсті. Себеп жиі қарапайым болады: жүйелік промпт өзгерді, RAG-контекст қосылды немесе жауап лимиті көтерілді.

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

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

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

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

Болжамды қадамдап қалай құруға болады

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

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

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

Есептеудің ыңғайлы реті мынадай көрінеді:

1. Әр сценарий үшін жұмыс күніндегі, демалыс күніндегі және секіріс күніндегі орташа сұрау санын есептеңіз.
2. Сол топтар үшін бір сұрауға шаққандағы орташа токен шығынын есептеңіз.
3. Айдың соңына дейін күтілетін сұрау санын әр сценарийдегі орташа шығынға көбейтіңіз.
4. Нәтижелерді қосып, жалпы токен көлемі мен шамамен соманы алыңыз.

Формула қарапайым: 12 000 сұрау x бір сұрауға 2 500 токен = 30 млн токен. Егер мұндай сценарий үшеу болса, әрқайсысын бөлек есептеп, кейін қосыңыз. Сонда қай ағын бюджетті жеп жатқанын, қайсысы шотқа онша әсер етпейтінін бірден көресіз.

Одан кейін қорытындыны ағымдағы шығынмен емес, ай соңына дейінгі командалық лимитпен салыстырыңыз. Егер болжам ай ортасына қарай лимиттің 85-90% көрсетсе, шотты күтпеңіз. Не өзгергенін тексеріңіз: жауап ұзақтығы өсті ме, команда қымбатырақ модель қосты ма, пайдаланушылар сұрауды жиірек қайталай ма, әлде бір сервис ретрай цикліне кіріп кетті ме.

Кішкене мысал. Команда жұмыс күндері сервис күніне 8 000 сұрау жасап, әр сұрау 1 800 токен жұмсайтынын көреді, ал жұма күндері есеп шығару жүктемесінен кейін 14 000 сұрауға және 2 400 токенге дейін өседі. Мұндай серпілісті айға жайып жіберуге болмайды. Оны бөлек есептеу керек. Әйтпесе есеп тыныш көрінеді, ал шот мүлде басқа болып келеді.

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

Көтерілістерді бюджет бұзбай тұрып қалай есепке алу керек

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

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

Релиздер мен промо-кампаниялар үшін тек жаңа пайдаланушыларды емес, бір адамға шаққандағы сұрау жиілігін де есептеңіз. Іске қосылғаннан кейін адамдар функцияны бірнеше рет қатарынан байқап көреді, сондықтан токендер сессиялар санынан жылдамырақ өседі. Егер өткен айда промо трафикті 40% өсірсе, қайталап талпыныстар мен ұзақ диалогтарға байланысты модель жүктемесі 60-80% өспеді ме, соны тексеріңіз.

Промпт өзгерістерін бөлек қадағалаңыз. Команда нұсқауды өзгертеді, көбірек контекст, мысалдар немесе жауап пішімдеуді қосады да, кейін тек сапаға қарайды. Сол сәтте шот екі нәрседен қатар өседі: кіріс ұлғаяды, ал модель ұзағырақ жауап бере бастайды. Тіпті жауаптағы қосымша 300-500 токен үлкен ағын кезінде тез-ақ елеулі сомаға айналады.

Артық шығынның тағы бір жиі көзі - қымбатырақ модельге fallback. Бұл ақауларда, провайдер лимиттерінде немесе маршрутизация өзгергенде болады. Кейде айлық болжамды жоғары итеру үшін шақырулардың 5%-ы ғана жеткілікті.

Түнгі job-тар, қайта индекстеу, өнім карталарын жаппай генерациялау, чат архивтерін қысқарту сияқты жұмыстарды да бөлек есептеген жөн. Тек күндізгі өнімдік трафикке қарасаңыз, бұл тапсырмалар оңай түсіп қалады.

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

• релиздер мен промо
• промпттар мен жауаптардың ұзаруы
• қымбат модельге fallback
• пакет және түнгі тапсырмалар

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

Қандай аномалияларды бірден ұстау керек

Шотты көбіне бір үлкен ақау емес, алғашқы күні ешкім байқамаған метрикадағы баяу ығысу бұзады. Ең жиі мысал - модель ұзақ жауап бере бастайды да, сұраулар саны өспей-ақ орташа output токендері 20-40% артады.

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

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

Қателер де ақшаға тұрады. Сағаттар бойынша ретрай көбейсе, шығын жиі байқалмай-ақ екі еселенеді: бірінші сұрау құлады, екіншісі қайта жіберілді, сосын клиент сол мәтінді тағы бір рет жіберді. Егер сағат 14:00-де сізде әдетте 1% қате болса, ал бүгін 8% болса, бұл енді шуыл емес.

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

Бес қарапайым алерт жақсы жұмыс істейді:

• модель және сценарий бойынша орташа output токендерінің өсуі
• бір кілт бойынша шығынның секіруі
• сағаттар бойынша қате мен ретрайдың артуы
• жалпы трафиктегі қымбат модельдер үлесінің өсуі
• үш күн қатарынан болжамнан жоғары күндік шығын

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

Мысал: команда қауіпті екінші аптада байқайды

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

Айдың бірінші аптасында бәрі тыныш көрінді. Чат-бот күніне шамамен 2,1 млн токен жұмсады, ішкі көмекші тағы 900 мыңдай токен жұмсады. Жалпы алғанда тәулігіне 3 млн токен шамасында шығып тұрды. Осындай қарқын сақталса, айлық болжам шамамен 93 млн токен болатын. Команда бюджетке дәл ілікті, бірақ артық қорсыз.

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

Екі күннен кейін күндік шығын 4,4 млн токенге көтерілді. Шот әлі келген жоқ, бірақ алерт іске қосылды. Ол тек фактіні емес, соңғы күндердегі қарқынды да қарап отырды. Қайта есептегеннен кейін ай соңындағы болжам 93 млн-нан 129 млн токенге өсті. Командада жағдайды түзетуге шамамен екі аптадай уақыт қалды.

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

Бірнеше күннен кейін орташа жауап шамамен 300 токенге түсті, ал күндік шығын 3,3 млн-ға қайтты. Жаңа болжам шамамен 101 млн токен көрсетті. Бұл әлі де жоспардан жоғары, бірақ бюджеттен тыс құлдыраусыз.

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

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

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

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

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

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

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

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

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

Аптасына бір рет қысқаша тексеру

Апталық тексеруге 15-20 минут жеткілікті, бірақ ол ай соңындағы кез келген есептен жақсырақ бюджет сақтап қала алады. Бірдей сандарды кесте бойынша қарап отырсаңыз, болжам тез арада жорамал болудан қалады.

Әдетте бес қадам жеткілікті:

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

Тағы жақсысы - өсімнің себебін қысқаша жазып қою. «Іздеу релизінен кейін орташа output tokens 900-ден 1400-ге өсті» деген сияқты жазба ұзақ, бірақ қорытындысыз есептен әлдеқайда пайдалы.

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

Келесі қадамдар: шығынды бақылауда ұстау

Шығын сирек өзінен-өзі өседі. Әдетте сандардың иесі болмай қалады. Болжамға жауап беретін, алерттерді қарайтын және аптасына бір рет жоспардан ауытқуды тексеретін бір адамды бекітіңіз. Бұл техлид, FinOps-менеджер немесе өнім иесі болуы мүмкін, бірақ аты-жөні біреу ғана болуы керек.

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

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

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

Егер шақырулар бір OpenAI-үйлесімді шлюз арқылы өтсе, шығынды, rate-limit-терді және аудит-журналдарды бір жерден ұстау ыңғайлы. Қазақстан мен Орталық Азиядағы командалар үшін бұл міндетті AI Router-дағы airouter.kz шешеді: ол арқылы тек қорытынды соманы ғана емес, қандай кілт, модель немесе сервис артық шығын бергенін де оңай түсінесіз.

Айына бір рет болжамды фактпен салыстырып, есептеуді өзіңіз де түзетіп отырыңыз. Егер бұрын орташа жауап 900 токен болса, ал қазір 1400 болса, ескі коэффициент енді өтірік айтады. Жаңа функция қымбат модельдердің үлесін өсірсе, оны да ескеру керек, «бір реттік» секіріс деп жауып қоюға болмайды.

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