LLM шығындары туралы есеп: бухгалтерия мен CTO үшін қолмен салыстырусыз

Неліктен LLM бойынша сандар сәйкес келмейді

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

Тіпті бірдей пайдалану көлемі бірдей соманы бермейді. Бір сценарийді әртүрлі модельдер арқылы іске қосуға болады, ал олардың кіріс және шығыс токендерге арналған тарифтері бөлек. Бір жерде кэш бөлек есептеледі, бір жерде есептелмейді. Сондықтан "2 млн токен" деген жолдың өзі көп нәрсені түсіндірмейді. Инженерлер үшін бұл — usage, ал бухгалтерия үшін — әлі шығын емес.

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

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

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

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

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

Бір форматта не болуы керек

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

Ең алдымен кезеңді көрсетіңіз. Әр экспортта есеп айын және деректерді қашан алғаныңызды жазыңыз. Провайдердегі usage кешігіп толуы немесе сұраулардың бір бөлігі UTC бойынша келесі күнге өтіп кетуі кезінде бұл даулардың бір бөлігін бірден жояды. "2026 жылғы мамыр, экспорт 2026 жылғы 3 маусымда" дегендей қарапайым белгілеу көп уақыт үнемдейді.

Келесі қадам — бизнес-контекст. Әр жолда немесе жолдар тобында команда, өнім және бюджет иесі болуы керек. Әйтпесе шығындар тез арада ешкім өзінікі деп санамайтын "AI үшін" деген ортақ шотқа айналады. Егер бір сервисті support, mobile және data team бірге қолданса, шығынды ай соңында қолмен емес, бірден бөліңіз.

Техникалық бөлік те қарапайым болуы керек. Тек модельді емес, провайдерді және сұрау түрін де белгілеңіз. Бір модель әр провайдерде әртүрлі бағада болуы мүмкін және әртүрлі ережемен биллингтеледі. Сұрау түрі де нәтижеге әсер етеді: chat, embeddings, rerank, batch және fine-tuned inference-ті бір бағанға араластырмаған дұрыс.

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

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

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

Есептеу бірлігін қалай таңдау керек

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

Бірдей көлемдегі сұраулардың өзі бір модельдің ішінде де әртүрлі бағаға түсуі мүмкін. Себебі қарапайым: input пен output бөлек тарификацияланады, ал cache көбіне өз ставкасымен жүреді. Барлығын "жалпы токен" деген бір жолға біріктірсеңіз, есеп қысқарады, бірақ мәнін жоғалтады. Команда input-ты 20% азайтуы мүмкін, бірақ қымбат output өссе, шот өзгермейді.

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

Әртүрлі тапсырма түрлерін араластырмаңыз

Chat, embeddings және batch тапсырмаларын бөлек белгілеусіз бір жерге қоса салуға болмайды. Олардың баға логикасы да, бизнес үшін пайдасы да әртүрлі. Chat-та әдетте input пен output маңызды. Embeddings-та шығын көбіне жаппай индекстеумен байланысты. Batch-та баға төменірек болуы мүмкін, бірақ көлемі жоғары.

Қарапайым мысал: support командасы чат-модельге 8 млн токен жіберді, ал каталог іздеуі embeddings арқылы 40 млн токен өткізді. Егер мұны бір жалпы сома ретінде жазсаңыз, іздеу токен тұтынуы жағынан қымбат болып көрінеді, ал ақшаны шын мәнінде чат-модель жеп қоюы мүмкін.

Ай соңындағы дауларды айтарлықтай азайтатын тағы бір ереже бар: есепті кезеңге бір ғана валюталық курс бекітіңіз. Операциялардың бір бөлігін күндік курспен, бір бөлігін инвойс курсымен қайта есептемеңіз. Бір ережені бір рет таңдап, оны барлық жолға қолданыңыз.

Жақсы есептеу бірлігі есепті жалықтырарлық етеді. Бұл — жақсы белгі. Формат сұрақ тудырмаса, талқылау арифметика туралы емес, нақты шығындар туралы болады.

Есепті қадам-қадаммен қалай жинауға болады

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

Әуелі ақшадан емес, шикі usage деректерінен бастаңыз. Сандарды бір форматқа келтіргеннен кейін ақшаны кейін есептейсіз.

Алдымен кезеңді таңдаңыз, мысалы күнтізбелік айды, және уақыт белдеуін белгілеңіз. Содан кейін барлық провайдерден сол аралыққа usage экспорттаңыз. Әр экспортта бірдей өрістер болсын: күн, модель, API кілті немесе project ID, кіріс және шығыс токендер саны, cached tokens, сұраулар саны және провайдер берсе, бастапқы құны.

Келесі қадам — әр API кілтін командамен, өніммен және қажет болса ішкі cost center-мен байланыстыру. Бұл байланысты ай соңында қолмен түзетпей, бөлек анықтамалықта сақтаған дұрыс. Одан кейін модельдер мен тарифтердің атауын қалыпқа келтіріңіз. Бір провайдер версияның толық атауын жазады, екіншісі қысқа alias қолданады. Есеп үшін бұл бір ғана сущность болуы керек, әйтпесе бір модельдің шығыны бірнеше жолға бөлініп кетеді.

Содан кейін токендерді бір тарифтер кестесі бойынша ақшаға қайта есептеңіз. Онда input, output және cached tokens бағасы, валюта және ай ішінде тариф өзгерсе, оның күшіне енген күні болуы керек.

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

Фіналға дейін нені тексеру керек

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

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

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

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

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

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

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

Әр команда үшін айлық лимитті, нақты шығынды, ақшамен және пайызбен ауытқуды, сондай-ақ сома қатты өзгерсе, қысқа түсіндірмені көрсеткен пайдалы. Ұзақ талдау қажет емес. Бір түсінікті сөйлем жеткілікті: "12 мың пайдаланушы үшін білім базасын іздеуді іске қостық" немесе "QA ішінде long-context модельді екі апта сынадық". Мұндай түсіндірмесіз секіріс қате сияқты көрінеді.

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

Айлық есептің мысалы

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

Мұндай жинақ бюджеттің қайда кетіп жатқанын тез көрсетеді. Алғашқыда support қымбатырақ көрінеді деп ойлауға болады: онда диалогтар мен кіретін хабарламалар көп. Бірақ жинақталғаннан кейін басқа нәрсе көрінеді. Негізгі соманы output береді, өйткені модель кіріс мәтінді жай ғана оқып қоймай, ұзақ жауаптар, қайта баяндаулар және қысқаша түйіндер жазады.

Аналитиктерде бұл әсіресе айқын. Олар есептерді, кестелерді және жиналыс жазбаларын жүктейді де, жауап ретінде ұзақ summary алады. Сұраулар саны support-қа қарағанда аз, бірақ жауаптар ұзын болғандықтан, output жолы тез өседі. Бұл мысалда айлық шоттың 80%-дан астамын output береді.

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

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

Ең жиі жіберілетін қателер

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

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

Екінші қате — тек model alias-тармен жұмыс істеу. Кодта команда "support-main" немесе "gpt-4.1" сияқты атауды көреді, бірақ тарификация сұрау сәтіндегі нақты модельге, провайдерге және версияға байланысты. Егер бір alias әртүрлі күндерде әртүрлі модельге бағытталса, alias бойынша орташа баға жалған көрініс береді. Есеп үшін мына байланыс керек: alias, нақты модель, провайдер және ставка.

Үшінші қате — ішкі эксперименттерді клиенттік трафикпен бірге қосу. Сонда жаңа функцияны сынау, промпттарды бағалау және жүктеме тесттері өнім шығындары сияқты көрінеді. CTO шығынның өскенін көреді, ал бухгалтерия нені R&D-ге, нені нақты сервиске жатқызуға болатынын түсінбейді.

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

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

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

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

Егер кемінде бір тармақ бос болса, есепті қайта жинауға тура келуі әбден мүмкін.

Жіберер алдындағы қысқа тексеру

Жіберер алдында тағы бір жылдам қарап шығу керек. Ол 10-15 минут алады, бірақ кейін хаттар мен қоңырауларда бірнеше сағат үнемдейді.

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

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

Кейін жалпы қорытындыны провайдер немесе шлюз деректерімен салыстырыңыз. Сома түсінікті айырмашылыққа дейін сәйкес келуі тиіс, мысалы дөңгелектеу немесе ҚҚС бар бөлек жолдың әсерінен. Кез келген айтарлықтай ауытқуды бір сөйлеммен бірден түсіндірген дұрыс: "support-та пилот іске қосылғандықтан 42% өсті, 6 күнде 18 млн токен".

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

Келесі айда нені өзгерту керек

Егер осы айда есепті қолмен жинаған болсаңыз, бәрін бірден қайта құруға тырыспаңыз. Базалық ережелерден бастаңыз. Өрістер сөздігін бекітіңіз: модельдің бір атауы, команданың бір атауы, бір валюта және usage-ты есептеудің бір тәсілі. Бір файлда "gpt-4.1-mini", екіншісінде "GPT 4.1 mini", ал үшіншісінде жай ғана "mini" тұрса, салыстыруға көп уақыт кетеді.

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

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

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

Егер қолмен салыстыру әлі де тым көп болса, сұрауларды бір API шлюзі арқылы жинақтаған дұрыс. Трафик бір нүкте арқылы өтсе, usage бір форматқа жақынырақ келеді, әрі деректерді әртүрлі кабинеттерден жинаудың қажеті азаяды. OpenAI-үйлесімді стекпен жұмыс істеп жүрген командалар үшін бұл әсіресе ыңғайлы: мысалы, AI Router-де тек base_url-ды api.airouter.kz-ке ауыстырып, қазіргі SDK мен промпттарды сақтап, кейін теңгемен бір айлық B2B-инвойс алуға болады. Есептілікте бұл әдемі схема үшін емес, қолмен біріктіру азайып, даулы жолдар кемитін болғандықтан пайдалы.

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