Суреттері мен мәтіні бар vision-сұраудың құнын қалай есептеуге болады

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

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

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

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

Жобалау кезінде бұл айырмашылықты жиі елемейді. Команда JPEG сапасын 90-нан 60-қа түсіріп, дискідегі файл көлемі азайғанын көреді де, API шығыны да сондай мөлшерде қысқарады деп күтеді. Ені мен биіктігі өзгермесе, ішкі тарификация мүлде өзгермеуі мүмкін. Керісінше, ұзын қабырғаны 4000-нан 1600 пиксельге дейін қысқарту файл мінсіз сығылмаса да, шығынды айтарлықтай азайтады.

Әр кескін үшін төрт мәнді сақтаңыз:

• барлық түрлендіруден кейінгі ені мен биіктігі;
• жіберілетін файлдың форматы мен өлшемі;
• таңдалған детализация немесе сапа режимі;
• провайдер жауабындағы нақты usage.

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

Google Gemini құжаттамасы кескіндерді мәтінмен және басқа модальділіктермен бірге токенделетін кіріс ретінде қарастырады. Anthropic Vision құжаттамасы масштабтауды қажет етпейтін кескіндер үшін жуық формула береді: токен саны шамамен ені мен биіктігінің көбейтіндісін 750-ге бөлгенге тең. Бұл инженерлік бағалау үшін пайдалы, бірақ барлық модельге ортақ формула емес. Оны басқа API-ға көшіріп, нақты шот ретінде көрсетуге болмайды.

Алдымен шығынды бес себетке бөліңіз

Шоттың әр жолы өз себетіне түскенде бюджет түсінікті болады. Бәрін «сұрау бағасына» сыйғызуға тырыспаңыз.

Бір шақырудың жалпы бағасы мынадай болуы мүмкін:

C = C_text_in + C_image + C_text_out + C_tools + C_transport + C_retry

Мұнда C_text_in жүйелік нұсқауды, пайдаланушы мәтінін, диалог тарихын және модельге қайтаратын болсаңыз, құрал нәтижелерін қамтиды. C_image кескіндерді, беттерді және кадрларды жабады. C_text_out жауапты, соның ішінде JSON, түсіндірмелер мен таңдалған модель шығыс ретінде тарификациялайтын ой қорыту элементтерін қамтиды. C_tools ақылы OCR, веб-іздеу, кескін генерациясы немесе басқа серверлік әрекеттер үшін қажет. C_transport әдетте LLM шотына кірмейді, бірақ сақтау, шығыс трафигі және журналдарға арналған жеке бюджетіңізге кіреді. C_retry тайм-аут, валидация қатесі, жылдамдық шектеуі және сенімсіз нәтиже салдарынан қайталанатын әрекеттерді көрсетеді.

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

C_month = Σ (N_class × C_class) + C_fixed

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

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

Ажыратымдылықты бастапқы файлға емес, ұсақ нысанға қарап таңдаңыз

Жоғары ажыратымдылық кішірейткенде жоғалып кететін бөлшектер тапсырмаға қажет болғанда ғана ақталады. Ұсақ сомалары бар шот сканы, сериялық нөмір, дәрі жапсырмасы және құрылғыдағы пломба бір тәсілді талап етеді. Фотода каска немесе көлік бар-жоғын анықтау үшін басқа тәсіл жеткілікті.

Жаман тәжірибе таныс көрінеді: мобильді қолданба камера түсірген 4032×3024 фотосын жүктейді. Сервер оны сол күйі қайта жібереді, дегенмен модель тек тауар түрін анықтауы керек. Мұндағы пиксель саны 1280×960 өлшемінен шамамен он есе көп. Ауданға жуық пропорциямен токенделсе, шот та сол шамада өседі, ал классификация дәлдігі аз өзгереді.

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

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

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

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

Кескін жанындағы мәтін күткеннен қымбат болуы мүмкін

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

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

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

Алғашқы талдаудан кейінгі ішкі нысан мысалы:

{
  "asset_id": "receipt_8f2c",
  "transform_version": "resize-1600-v3",
  "vision_result": {
    "merchant": "...",
    "date": "...",
    "total": "...",
    "currency": "...",
    "uncertain_fields": ["merchant"]
  },
  "needs_original_image": false
}

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

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

OCR мен vision тапсырманың әртүрлі бөлігін шешеді

«OCR үшін әрқашан LLM қолданыңыз» деген кеңес танымал, өйткені бір шақыру оңай көрінеді: кескін кірді, JSON шықты. Демо үшін бұл ыңғайлы. Шоттар, сауалнамалар, жүкқұжаттар және медициналық бланкілер ағынында мұндай таңдау шығынды арттырып, басқаруды қиындатады.

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

Құжаттарға арналған практикалық схема:

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

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

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

PDF-ті бөлек есепке алыңыз. Мәтіндік PDF әр бетті визуалды рендерингсіз-ақ алынатын мәтін бере алады. Сканерленген PDF көбіне кескіндер жиынына айналып, OCR қолдануы мүмкін. Кейбір платформалар құжат беттерін кескіндерге ұқсас ережелермен тарификациялайды. Мысалы, Gemini құжаттамасында PDF үшін DOCUMENT модальділігінің токендері image tokens тарифімен есептеледі. Сондықтан PDF-ті жай кескіндердің арасына жасырмай, бөлек шығын класы ретінде жүргізіңіз.

Видеоны файл ұзақтығымен емес, кадрлармен есептеңіз

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

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

Алдымен іздейтін оқиғаңызды жазыңыз. Содан кейін іріктеу стратегиясын белгілеңіз:

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

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

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

Провайдердің тарификация бірлігін модель атауына қарап болжауға болмайды

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

Image generation бойынша OpenRouter құжаттамасы нормализатор не үшін қажет екенін жақсы көрсетеді: endpoint деректерінде billable, unit, cost_usd өрістері және ажыратымдылық деңгейіне арналған тариф нұсқасы болуы мүмкін. Бірлік image, megapixel немесе token болуы ықтимал. Кескінді түсіну жағдайы да нақты модель мен провайдерге байланысты. Тек price_per_1m_tokens өрісін сақтап, ол барлық маршрутты қамтиды деп есептеуге болмайды.

Биллинг ішінде тариф ережелерінің анық кестесін жүргізіңіз:

{
  "route": "vision-route-a",
  "billing_unit": "input_token",
  "input_rate": "provider tariff",
  "output_rate": "provider tariff",
  "image_policy": "reported_in_prompt_usage",
  "detail_modes": ["low", "high"],
  "effective_from": "provider price version"
}

Кескінге бекітілген баға қолданылатын маршрутта billing_unit мәнін image деп өзгертіп, тарифті ажыратымдылық немесе сапа бойынша сақтаңыз. Мегапиксельмен есептелетін маршрутта дөңгелектеу ережесін көрсетіңіз. Дөңгелектеу маңызды: 1,01 мегапиксельдің бағасы 1,00 мегапиксельден басқаша есептелуі мүмкін, ал алдын ала бағалауыңыз мұны көрсетуі тиіс.

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

Бюджет формуласында жоғарғы шек болуы керек

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

Әр сұрау класы үшін үш режим белгілеңіз.

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

Төменде бюджет моделіне арналған параметрлер мысалы берілген. Мәндер әдейі айнымалылармен көрсетілген, себебі тариф пен нақты usage мақаладан емес, таңдалған маршруттан алынуы керек.

images_per_request = 2
image_tokens_per_image = measured_p90
text_input_tokens = measured_p90
text_output_tokens = response_cap
retry_rate = observed_retry_rate

request_cost = (
  images_per_request * image_tokens_per_image * input_rate +
  text_input_tokens * input_rate +
  text_output_tokens * output_rate +
  tool_cost
) * (1 + retry_rate)

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

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

Жауаптағы usage презентациядағы калькулятордан маңызды

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

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

{
  "request_id": "req_01",
  "tenant_id": "tenant_42",
  "route": "vision-route-a",
  "model": "selected-model",
  "provider": "selected-provider",
  "input_text_tokens": 812,
  "input_image_tokens": 1540,
  "output_tokens": 247,
  "image_count": 2,
  "frames_sampled": 0,
  "source_pixels": 2419200,
  "transform_version": "resize-1600-v3",
  "attempt": 1,
  "status": "success",
  "tariff_version": "2026-07"
}

Өрістер API-ға байланысты, сондықтан кейбір мәндер кейде null болады. Бұл қалыпты. Белгісіз токендерді нөлмен араластыру қалыпты емес. Нөл шығын болмағанын білдіреді. null шығынды бақылай алмағаныңызды білдіреді.

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

AI Router мұндай есеп ережелері қолданба SDK-сына тәуелсіз жұмыс істейтін нүкте бола алады: OpenAI-мен үйлесімді API маршрут ауысқанда клиентті қайта жазбауға мүмкіндік береді, ал аудит журналдары мен кілт деңгейіндегі rate limits әр команда мен сценарийдің шығынын бөлуге көмектеседі. Бұл бюджетке тек өлшемдерді, тапсырма кластарын және нақты usage деректерін бәрібір жазып отырсаңыз ғана пайдалы. Бір жалпы шотқа қарап отыру жеткіліксіз.

Үнемдеуді сапаны өлшегеннен кейін бастаңыз

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

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

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

Ең арзан модельді таңдаудан бастамаңыз. Қымбат сұраулардың бір класын алыңыз, нақты usage деректерін сақтаңыз, күрделі мысалдар жиынын дайындаңыз және ажыратымдылықты азайту, оқиға бойынша кадр алу немесе OCR-ды таңдамалы vision-талдаумен біріктіру нәтижені бұзбайтынын дәлелдеңіз. Осыдан кейін бюджет болжам емес, басқаруға болатын инженерлік шектеуге айналады.