Командалар арасындағы дау-дамайсыз AI шығындарының ішкі биллингі

Неліктен AI шоты дауға себеп болады

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

Мәселе мынада: бәрі бір шығынға әртүрлі өлшеммен қарайды. Қаржы инвойстағы ақшаны көреді. Инженерлер токендерді, модельдерді, retry мен кэштің бос өтуін көреді. Өнім басшысы пайдаланушылар санын, диалогтарды немесе өңделген өтінімдерді қарайды. Бәрі де дұрыс айтады, бірақ бір жүйенің әр бөлігін айтып тұр.

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

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

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

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

Токеннен бөлек нені есептеу керек

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

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

Әр сұрауда түсінікті белгі жиыны болуы керек. Іс жүзінде жақсы жұмыс істейтін минимум мынау: өнім немесе сервис, команда немесе бюджет иесі, prod/stage/dev ортасы, чат, іздеу, қорытындылау немесе жіктеу сияқты сценарий және шығын түрі — қалыпты шақыру, retry, cache hit немесе cache miss.

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

Ортаны әрдайым бөлек есептеу керек. Прод трафигі бизнеспен тікелей байланысты. Тесттер мен бір реттік эксперименттер пайдалы, бірақ оларды жұмыс контурымен араластырмау керек. Әйтпесе өнім командасы жұма кешіндегі біреудің гипотезасын тексергені үшін шот алады.

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

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

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

Шығынды өнімдерге қалай бөлуге болады

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

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

Егер өнім ішінде құны әртүрлі бірнеше сценарий болса, бір кілттің өзі жеткіліксіз. Сондықтан әр сұрауға қысқа функция тегін берген пайдалы, мысалы checkout_assistant, support_chat немесе catalog_search. Сұраулар бірыңғай шлюз арқылы өтсе де, мұндай тег кейін шотты қарапайым сөзбен түсіндіруге көмектеседі: іздеу бюджеттің 18%-ын алды, себебі ол token емес, көп embedding сұрауларын жасады.

Ортақ сервистер бойынша алдын ала келісіп алған дұрыс. Әйтпесе сұрауларды проксилейтін, аудит логтарын сақтайтын немесе PII-ді жасыратын платформа күтпеген жерден біреудің шығын бабы болып шығады. Мұндай нәрселерге бүкіл компанияға ортақ бір формула керек.

Көбіне мынадай қарапайым схема жеткілікті: ортақ шығынның 70%-ы нақты сұрау саны бойынша бөлінеді, 30%-ы сол айда сервисті пайдаланған өнімдер арасында тең бөлінеді, пилоттар бөлек есептеледі, ал продакшен тестті субсидияламайды. Формула мінсіз болуы шарт емес. Ол түсінікті және қайталанатын болуы керек.

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

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

Шотты токенсіз қалай түсіндіруге болады

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

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

Қолайлысы — түсінікті нәтиженің құнын есептеу: қолдау чатындағы бір жауаптың, бір құжат тексерудің, бір қоңырау шолуының немесе бір өңделген өтінімнің құны. Осыдан кейін шығынды ірі өлшеммен көрсету керек. 2,4 млн токен емес, 1000 диалогқа 3200 теңгеден. input өсті емес, бір өтінім 18%-ға қымбаттады.

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

Айдан айға салыстыру тек бір сценарийдің ішінде ғана жұмыс істейді. Егер сәуірде сіз қолдау чатымен есептесеңіз, ал мамырда оған тіркемелерді тексеруді қоссanız, бұл енді басқа сценарий. Егер бұрын бот қысқа жауап берсе, кейін ұзақ қорытынды жасай бастаса, айларды да түсініктемесіз қатар қоюға болмайды.

Есептің ыңғайлы форматы қарапайым: сценарий, көлем, бірлік құны, жалпы сома және ауытқу себебі. Бір қарағанда не болғанын түсінуге болады. Мысалы: қолдау чаты, 48 000 диалог, бір диалог 2,9 теңге, өсу себебі — жауаптардың ұзара түсуі.

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

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

Ішкі биллингтің қадамдық схемасы

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

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

Келесі қадам — барлық сұрауға арналған бірыңғай тег форматын енгізу. Әдетте үш өріс жеткілікті: өнім, орта және сценарий. Мысалы, product=support-bot, env=prod, feature=summary. Мұндай тегтер тек соманы емес, шығын себебін де түсінуге көмектеседі. Оларсыз барлық сұраулар бірдей көрінеді, тіпті бір сервис клиенттерге жауап беріп, екіншісі ішкі тесттерді жүргізсе де.

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

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

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

Егер процесс жалықтыратын болып көрінсе, бұл жақсы белгі. Жалықтырмайтын процесс көбіне түсініксіз, қайталанбайды және әр ай сайын чат-бот неге іздеуден екі есе көп бюджет жегенін қайта түсіндіруді талап етеді.

Мысал: чат-бот, іздеу және қолдау бір шотта

LLM үшін ортақ шот тез арада дау тудырады. Өнім командасы трафикті чат-бот жасады дейді. Іздеу командасы өздерінде сұрау аз дейді. Қолдау тобы тесттердің әсері мардымсыз болды дейді.

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

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

Айына 1 200 000 теңге шықты делік.

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

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

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

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

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

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

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

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

Есеп түсініксіз болып қалған кезде

Есеп қайта шығынды модельдердің атауларымен түсіндірсе, ол дерлік пайдасыз. "X моделі үшін көбірек жұмсадық" деген сияқты сөйлем көп адамға көмектеспейді. Ал мынадай нұсқа әлдеқайда түсінікті: қолдауда ұзақ жауаптардың үлесі 28%-ға өсті, іздеу сенімі төмен кезде екінші сұрауды жасай бастады, таймауттан кейінгі retry шотқа 11% қосты.

Қалыпты есеп бес сұраққа жауап береді: қандай өнім шығын тудырды, өнім ішіндегі қай сценарий өсім берді, қайсысы прод, қайсысы тест болды, қайталанулар мен fallback-қа қанша ақша кетті және модель не промпт қашан ауысты.

Есепте сценарий, өзгеріс күні және бір әрекеттің бағасы болса, дау тез басылады. Адамдар токенмен ойламайды. Олар мынадай тілді жақсы түсінеді: бір іздеу 0,8 теңге тұрады, бір диалог қорытындысы — 2,4 теңге, бір апталық тесттер шоттың 17%-ын жеді.

Жұмысқа кіріспес бұрын жылдам тексеріс

Жаңа схеманы іске қоспас бұрын бес нәрсені тексерген пайдалы.

1. Әр өнімге бюджет иесін тағайындаңыз. Есеп ережелерін растайтын, есепті қарайтын және өз бағыты бойынша сұрақтарға жауап беретін нақты адам керек.
2. Әр кілтті, сервисті және batch-тapсырманы өнім тегіне байлаңыз. Мобильді чат, білім қоры бойынша іздеу және ішкі көмекші бір шлюз арқылы өтсе, тегтер бірден кімнің қанша пайдаланғанын көрсетеді.
3. Тестті боевой жүктемеден ажыратыңыз. Песочница, QA және қолмен тексерулер сұраулары бөлек контурға кетуі керек, әйтпесе жаңа функцияның іске қосылуы боевой шотты байқаусызда үлкейтеді.
4. Ортақ шығын формуласын бастауға дейін жазыңыз. Егер бірнеше өнім бір шлюзді, ортақ логтарды, PII маскалауды немесе модель хостингін қолданса, осы бөлікті қалай бөлетініңізді алдын ала шешіңіз.
5. Есепті токенмен ойламайтын адам оқитынын тексеріңіз. Теңгедегі сома, сұрау саны, бір сценарийдің бағасы және өсімнің қысқа себебі кіріс-шығыс токен бағандарынан әлдеқайда түсінікті болады.

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

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

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

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

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

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

Бір мысалмен талдау да жақсы жұмыс істейді. Мысалы, қолдау өнімінде 1 200 000 теңгелік шот шықты делік. Жобада 800 000 теңге клиенттерге жауаптарға, 250 000 — білім қоры бойынша ішкі іздеуге және тағы 150 000 — таймауттан кейінгі қайталанған шақыруларға кеткені көрінеді. Осындай әңгімеден кейін дау әдетте нақтыға ауысады: команда енді неге қымбат дегенді емес, қай бөлікті өз мойнына алатынын және келесі айда нені түзететінін талқылайды.

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

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