LLM тарифтерін салыстыру: түпкілікті бағаны қалай әділ есептеу керек

Бағаны салыстыру неге қиын

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

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

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

Жақсы мысал - банк қолдауындағы чат. Пайдаланушы 80 токендік қысқа сұрақ қояды, ал модель 900 токенмен жауап береді. Тек кіріс бағасына қарасаңыз, ең төмен ставкалы провайдерді оңай таңдап, оны тиімді деп ойлап қаласыз. Іс жүзінде мұндай сценарийдегі шоттың көп бөлігін көбіне шығыс құрайды.

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

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

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

Прайстарда қандай бірліктер кездеседі

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

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

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

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

Тағы бір онша байқалмайтын тарификация бірлігі - жылдамдық лимиттері. Провайдер төмен баға бере алады, бірақ RPM немесе TPM-ді қатты шектейді. Онда командаға резервтік арна ұстап, трафикті бірнеше аккаунтқа бөліп немесе қымбатырақ тарифке көшуге тура келеді. Формалды түрде токен арзан, ал іс жүзінде іске қосу қымбатырақ болады.

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

Қайта есептеу кестесін қалай жинау керек

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

Прайстағы бір ғана цифр көбіне жеткіліксіз. Нақты шотта кіріс, шығыс, кэш, қайталау және контекст шектеулері бар. Егер бұлар кестеде болмаса, кесте әдемі көрінеді, бірақ өтірік айтады.

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

Келесі қадамда өз сандарыңызды қойыңыз. Егер сізде қолдаудағы орташа жауап үш есе ұзақ болса, "200 кіріс және 50 шығыс токен" деген жарнамалық мысалды алмаңыз. 3-7 күндік логты шығарып, кіріс пен шығыс бойынша орташа мәнді, медиананы және 90-процентильді есептеген дұрыс. Сонда арзан кіріс ұзын жауапта бағаны қалай көтеретінін бірден көресіз.

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

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

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

Дөңгелектеу бар жолдарды бірден белгілеп қойыңыз. Бір провайдер нақты токендерді есептейді, екіншісі 1000 токенге дейін дөңгелектейді, үшіншісі сұрау үшін минималды пакет алады. Қысқа хабарламаларда айырмашылық анық сезіледі. Пайдаланушы 120 токен жіберсе, ал биллинг оны 1000 деп есептесе, қағаздағы баға мен ай соңындағы баға мүлде бөлек болады.

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

Түпкілікті бағаны қадамдап қалай есептеу керек

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

1. Бір типтегі сұранымдардан үлгі жинаңыз. Қолдау чаттарын, білім базасынан іздеуді және ұзақ құжат генерациясын араластырмаңыз. Әр сценарийдің кірісі, шығысы және шығыны бөлек болады.
2. Осы үлгі үшін кіріс токендерінің орташа санын, шығыс токендерінің орташа санын және кэштен келген жауаптардың үлесін өлшеңіз. Егер провайдер cached input-ты бөлек есептесе, бұл бірден нәтижені өзгертеді.
3. Әр провайдердің ставкаларын алып, оларды өз көлеміңізге көбейтіңіз. Кіріс, шығыс және кэшті бөлек есептеңіз, бір жолмен емес. Дәл шығыс токендерінің бағасы көбіне арзан тарифті қымбатқа айналдырады.
4. Әдетте ұмытылатын шығындарды қосыңыз: қателерден кейінгі қайталанған сұраулар, қайта іске қосылатын тайм-ауттар, нормадан ұзақ жауаптар және классификация не модерация үшін қызметтік шақырулар. Продакшнда бұл шоттың бір бөлігі, шу емес.
5. Нәтижені түсінікті масштабқа аударыңыз: 100 сұраным бағасы, бір күн бағасы және бір ай бағасы. Сонда бір шақырудағы бірнеше ондық цент айырмашылықтың айтарлықтай шығын жолына қалай айналатынын байқайсыз.

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

Мысал: банк қолдауындағы чат

Банк қолдауындағы чатта пайдаланушы көбіне өте қысқа жазады: "Карта неге өтпеді?" немесе "Лимитті қалай көтеремін?". Бірақ бот сирек дәл сондай қысқа жауап береді. Ол қауіпсіздік ережелерін ескеруі, клиентке қадамдар ұсынуы және артық уәде бермейтін ұқыпты тұжырым жасауы керек.

Сондықтан мұндай тапсырмаларда шығыс токендері әдетте кірістен көп болады. Тек кіріс бағасына қарасаңыз, көрініс көбіне қате шығады.

Мысалы, бір диалог былай көрінеді:

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

Бұл жердегі есеп қарапайым. A провайдерінде кіріс арзан: 450 кіріс токені бар болғаны $0.00009 тұрады. Бірақ 900 шығыс токені әлдеқайда қымбат - $0.0027, және бюджетті дәл солар жейді.

B провайдерінде керісінше. Кіріс қымбатырақ - диалогқа $0.00027, бірақ ұзақ жауап бар болғаны $0.00108 тұрады. Бір әңгімеде айырмашылық мардымсыз көрінеді, алайда ағынмен келгенде тез өседі.

Банк үшін бұл үйреншікті жағдай. Қолдау бір ғана диалогпен өмір сүрмейді. Егер бот айына 10 000 өтініш өңдесе, B нұсқасы тек осы бір сценарийдің өзінде $14.40 үнем береді. Платеждер бойынша дауларды, картаны қайта шығару сұрақтарын және лимиттерге қатысты өтініштерді қоссақ, айырмашылық одан да айқын болады.

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

Қай кезде арзан кіріс баға түпкілікті соманы қымбаттатады

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

Жақсы мысал - қорытындылар, есептер және қолдау үшін ұзақ жауаптар. Егер модель 3000 кіріс токенін алып, 6000 токен қайтарса, арзан кірістің пайдасы аз. Кіріске 0,1, шығысқа 1,2 бағасы бар провайдер кіріс 0,3, шығыс 0,5 болатын нұсқадан оңай қымбатқа түсуі мүмкін.

Дәл осындай жағдай RAG-агенттерде де болады. Қағаз жүзінде сұраным қысқа сияқты көрінеді, бірақ әр шақыруға жүйе үлкен контекст қосады: білім базасынан үзінділер, диалог тарихы және қызметтік нұсқаулар. Пайдаланушы 30 сөз жазады, ал биллинг 12 000 немесе 20 000 кіріс токенін есептейді. Егер күніне мыңдаған сұрау болса, кіріс ставкасының айырмасы ұсақ нәрсе болып қалмайды.

Шығын байқалмай өсетін жерлер

Көбіне бюджетті бағаның өзі емес, тарификация формасы ұлғайтады.

• Тайм-ауттан немесе қатеден кейінгі қайталап шақыру бірдей контекст қайта жіберілсе, шығынды дерлік екі еселейді.
• Үлкен блоктарға дейін дөңгелектеу төмен ставканың пайдасын жояды. 1100 токендік сұрауды 2000 деп не минималды пакет ретінде санауы мүмкін.
• Мультимодальды сұраулар тек мәтінге қарасаңыз, есепті бұзады. Сурет, аудио және видео көбіне бөлек тарификацияланады.
• Ұзақ чат тарихы жауаптар қысқа болса да, кірісті баяу жинай береді.

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

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

Сондықтан бір бірлік бағасына емес, дайын әрекеттің құнына қараған пайдалы: чат жауабы, әңгіме қорытындысы немесе құжат тексеруі. Сонда салыстыру әділ болады.

Тарифтерді салыстырудағы қателер

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

Екі нұсқаны елестетіңіз. Біріншісінде кіріс 1 мың токенге 0,05, шығыс 0,40 тұрады. Екіншісінде кіріс 0,12, шығыс 0,18. 300 кіріс және 900 шығыс токені бар сұрауда бірінші нұсқа 0,375 береді, ал екіншісі 0,198 болады. Витринада арзан көрінгені - бірінші, бірақ шотта ол дерлік екі есе қымбат.

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

Тағы жүйелік токендер ұмытылады. Есепке жүйелік промпт, диалог тарихы, JSON схемалар, tool calls, белгілеу және кэшке кірген не кірмеген токендер кіруі керек. Ұзақ сессияларда бұл елеулі сомаға айналады. 700 токендік жүйелік промпт 15-20 хабарлама кезінде бюджеттің біразын жеп қояды, егер провайдердегі caching әлсіз болса немесе тек сұранымның бір бөлігіне ғана жұмыс істесе.

Келесі қате - отказ пен қайталау бағасын есептемеу. Модель бос жауап қайтаруы, JSON-ды бұзуы, refusal-ға кетуі немесе қолданба қайталанған шақыру жіберетіндей жауап беруі мүмкін. 5-10% қайталау да прайстағы бірнеше цент айырмасынан қаттырақ әсер етеді.

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

Таңдау алдында жылдам тексеру

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

Дұрыс кесте барлық провайдерді бір бірлікке келтіреді. Онда 1 млн кіріс токенінің бағасы, 1 млн шығыс токенінің бағасы, кэш шарттары, лимиттер және қайталау шығындары бар. Әйтпесе бір жеткізуші тек 1K деп жазғандықтан арзан көрінеді, екіншісі 1M деп жазады, ал үшіншісі қымбат шығысты прайстың төменгі жағына жасырады.

Бес нәрсені тексеріңіз:

• барлық провайдер мен модель үшін бір кесте бар ма, бірліктер араласпаған ба;
• тек әдеттегі сұрау емес, орташа және ең нашар сценарийлер есептелген бе;
• 100, 1000 және 10 000 шақыру бағасы көріне ме;
• лимиттер, кэш, ретрай және қате кейінгі қайталаулар ескерілген бе;
• қолданбаның логикасын қайта жазбай модельді ауыстыруға бола ма.

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

100, 1000 және 10 000 шақыруға арналған сандар айырмашылықтың қашан ұсақ нәрсе болмайтынын тез көрсетеді. Жүз сұранымда екі провайдер сәл ғана айырылуы мүмкін. Он мыңда сол айырма айқын шығын жолына айналады.

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

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

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

Есептеулерден кейін модельді прайстың бір жолы бойынша таңдамаңыз. Өз деректеріңізден 2-3 нақты сценарий алып, оларды бір кестеден өткізіңіз: қысқа чат, шығысы көп ұзақ жауап және қайталанатын сұраулар бар тапсырма. Содан кейін ақша нақты қай жерде кетіп жатқанын тез көресіз.

Жақсы жұмыс кестесі тек кіріс пен шығысты емес, сұраудың бүкіл жолын есептейді: жүйелік промпт, диалог тарихы, жауаптың орташа көлемі, ретрайлар және кэш. Тіпті Excel немесе Google Sheets-тегі қарапайым модель де провайдердің сайтындағы әдемі прайстан көбірек пайда бере алады.

Модельді ауыстыру шегін бекітіңіз

Айдың соңын күтпеңіз, таңдауыңыз қымбат болып шыққанын түсіну үшін. Команда модельді немесе провайдерді қашан ауыстыратынын алдын ала жазып қойған дұрыс. Мысалы, орташа жауап тұрақты түрде 800-1000 токеннен асса, арзан кіріс бюджетті құтқармауы мүмкін. Қате немесе ретрай үлесі өссе, токен бағасы төмен болса да түпкілікті құн жоғарылайды.

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

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

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

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