Жасырын reasoning токендері шығын есебін неге бұзады?

LLM шығындары көбіне миллион токеннің бағасы қате болғандықтан емес, есептеу моделі дұрыс құрылмағандықтан бұзылады. Команда prompt_tokens мәніне completion_tokens санын қосып, тарифке көбейтеді де, әдемі, бірақ кейде ойдан шығарылған сан алады. Кейін reasoning, prompt caching, streaming, құралдар контексті немесе провайдерлер арасындағы маршрутизация пайда болады. Ескі калькулятор есептей бергенімен, оның бастапқы болжамдары енді дұрыс емес.

Жасырын reasoning токендері бөлек мистикалық комиссия емес. Әдетте бұл модель жұмысының бір бөлігі, ол output ретінде тарифтеледі, бірақ API-де әртүрлі көрсетіледі. Негізгі қауіп басқа жерде: әр провайдерде атауы бірдей өрістердің мағынасы әртүрлі болуы мүмкін, ал атауы бөлек өрістер бір санатты сипаттауы ықтимал. Аналитиканы жазбас бұрын семантиканы бекітпесеңіз, шығынды екі рет есептейсіз немесе оны «басқа» санатына жасырасыз.

Жауаптағы Usage қаржылық моделіңізбен бірдей емес

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

Бұл сұрақтардың жауаптары жиі әртүрлі болады. Кэштен оқылған контекст кәдімгі input-тан арзан болуы мүмкін, бірақ контекст терезесінде орын алады. Ішкі пайымдау ақылы output құрамына кіріп, пайдаланушы бір қысқа абзац қана көруі мүмкін. Шлюз деңгейіндегі response cache жауабы токендері провайдерге мүлде жетпеуі мүмкін. Мұндайда HTTP жауабы сәтті болғанымен, usage нөл болуы ықтимал.

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

Бақылаудың ең аз моделі кемінде мына екі қабатты сақтауы керек:

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

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

Араластыруға болмайтын төрт себет

Практикалық есеп төрт себеттен басталады: кәдімгі input, кэштен оқу, кэшке жазу және output. Ішкі reasoning әдепкі бойынша бесінші ақылы себет болмауы керек. Көбіне бұл output құрамына кіретін, оны талдауға арналған бөлік.

Оларды былай белгілейік:

I = кәдімгі кіріс токендері
R = кэштен оқылған токендер
W = кэшке жазылған токендер
O = барлық ақылы шығыс токендері
T = провайдер ашып көрсетсе, O ішіндегі reasoning немесе thinking

Баға үшін мына формуланы қолданыңыз:

cost = I * p_input + R * p_cache_read + W * p_cache_write + O * p_output + fixed_fees

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

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

0 <= T <= O
visible_output_approx = O - T

Мұндағы approx сөзі әдейі қолданылған. Көрінетін мәтінді клиент жағындағы қарапайым токенайзермен сенімді түрде қайта есептеу мүмкін емес. Провайдер reasoning-ді қысқаша қорытындылауы, жасыруы, қызметтік бөліктер қосуы немесе мультимодальды бөліктерді өзгеше санауы мүмкін. Ақша үшін жауаптағы немесе биллинг выгрузкасындағы O маңызды, message.content жолындағы токендер саны емес.

Маңызды ерекшелік бар. Кейбір API кэштелген бөліктері кіріп кеткен жалпы input мәнін ғана береді, ал кейбірі input_tokens санын cache read және cache write көрсеткіштерінен бөлек береді. Бірінші жағдайда жауапта бөлініс болмаса, I, R және W мәндерін адал түрде шығару мүмкін емес. input_total_reported мәнін сақтап, егжей-тегжей деңгейін unavailable деп белгілеңіз және үлес ойлап таппаңыз.

Reasoning жаңа шығынды емес, output құрамын көрсетеді

Ең жиі кездесетін қате мынадай: инженер completion_tokens: 1200 және reasoning_tokens: 900 мәндерін көреді де, output ретінде 2100 токен жазады. Егер API құжаттамасында reasoning completion құрамына кіретіні айтылса, бұл қосарланған есеп.

OpenAI-де completion_tokens_details.reasoning_tokens output ішіндегі егжей-тегжейлі көрсеткіш, ал completion_tokens генерацияның жалпы есептегіші болып қалады. Anthropic құжаттамасында extended thinking үшін бұл одан да анық жазылған: output_tokens тарификацияға арналған қорытынды сан, ал output_tokens_details.thinking_tokens осы ақылы output-тың ішкі пайымдауға кеткен бөлігін көрсетеді. Google Gemini thoughtsTokenCount мәнін usageMetadata ішінде input, кэш, candidate токендері және қорытынды көрсеткішпен бірге жариялайды. Бұл схемалар сырттай ұқсас болғанымен, нақты модель мен endpoint құжаттамасын тексермей, бір формуланы қолдануға болмайды.

Ереже қарапайым: әр егжей-тегжейлі өрісті алдымен subset, additive немесе unknown деп белгілеңіз.

• subset ата-ана есептегішіне кіріп қойған, талдау үшін пайдаланылады;
• additive базалық есептегішке қосылады, өйткені API оны базадан алып тастаған;
• unknown құжаттама мен шотты салыстырмайынша, ақша формуласына қолданылмайды.

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

{
  "provider": "example-provider",
  "endpoint": "responses",
  "model_pattern": "*",
  "usage_rules": {
    "output_total": "usage.completion_tokens",
    "reasoning": "usage.completion_tokens_details.reasoning_tokens",
    "reasoning_relation": "subset"
  }
}

Бір танымал API осылай жұмыс істейді екен деп, барлық интеграцияға reasoning_relation: "subset" қолданбаңыз. Модель нұсқасы, нативті endpoint және прокси жауап формасын өзгертуі мүмкін. Нормализатор өріс атауына қарап болжам жасамай, объектінің қайдан келгенін білуі тиіс.

Көрінетін және ақылы бөліктердің айырмасын да бақылаңыз. Anthropic суммаризацияланған немесе жасырын thinking кезінде көрінетін токендер ақы төленетін бастапқы reasoning санымен сәйкес келмейтінін тікелей ескертеді. Бұл қалыпты жағдай. Қате өнім командасы пайдаланушы көрген таңбаларға ғана қарап, «тұрақты бағаға қысқа жауаптар» деп уәде бергенде басталады.

Кэштеу input бағасын өзгертеді, бірақ контексті жоймайды

Prompt caching пен response caching әртүрлі міндет шешеді, ал атаулары тым ұқсас. Оларды бір «кэш» бағанына біріктіруге болмайды.

Prompt caching провайдерде контекст өңделіп жатқан кезде орындалады. Модель ұзын ортақ префиксті қайта алады, бірақ есептеудің бір бөлігін кэштен пайдаланады. Сондықтан usage ішінде cache read, cache write немесе екеуі де болуы мүмкін. Cache write ағымдағы сұрау кэшке сақталатын префикс жасағанын немесе жаңартқанын білдіреді. Cache read сұраудың бұрын жасалған бөлікті пайдаланғанын көрсетеді. Сериядағы алғашқы шақыру кәдімгі input-тан қымбат, ал кейінгілері арзанырақ болуы мүмкін. Бір сұраудың орташа бағасына ғана қарасаңыз, қыздыру құнын байқамайсыз.

Response caching модельге жүгінбей тұрып, бірдей сұрауға дайын нәтижені қайтарады. OpenRouter құжаттамасында cache hit кезінде биллинг есептегіштері нөлге түсетіні көрсетілген, өйткені шақыру провайдерге жетпейді. Бұл prompt cache hit емес және бастапқы сұрауда модель нөл токен өңдеді дегенді білдірмейді. Бұл басқа оқиға түрі: жауапты модельден жоғары тұрған қабат берді.

Оларды бөлек сақтаңыз:

{
  "cache": {
    "provider_prompt_read_tokens": 18400,
    "provider_prompt_write_tokens": 0,
    "gateway_response_cache": "miss"
  }
}

Келесі бірдей сұрауда мынадай нәтиже көруіңіз мүмкін:

{
  "usage": {
    "prompt_tokens": 0,
    "completion_tokens": 0,
    "total_tokens": 0
  },
  "cache": {
    "gateway_response_cache": "hit"
  }
}

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

Кэш үнемділікке кепілдік бермейді. Оған қайталанатын префикс, қолайлы өмір сүру мерзімі және сұраудың тұрақты бөлігін дұрыс орналастыру керек. Команда ұзын нұсқаулықты пайдаланушының динамикалық хабарынан кейін орналастырып, cache read неге нөл екенін түсінбей қалады. API префикстерді кэштесе, ұзын өзгермейтін system prompt, құрал сипаттамалары және анықтамалық құжаттар өзгермелі деректерден бұрын орналасуы тиіс.

Нормализатор белгісіздікті нөлмен алмастырмай, сақтауы керек

Бір шлюз prompt_tokens, екіншісі input_tokens, үшіншісі usageMetadata берсе, || 0 бар он шақты өрнек жазу тартымды көрінеді. Осылайша жоқ егжей-тегжей шығынның жоқтығы сияқты көрінетін есептер пайда болады.

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

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

type MaybeNumber = number | null;

type UsageLedger = {
  input_uncached: MaybeNumber;
  cache_read: MaybeNumber;
  cache_write: MaybeNumber;
  output_total: MaybeNumber;
  reasoning_output: MaybeNumber;
  reported_total: MaybeNumber;
  reasoning_relation: "subset" | "additive" | "unknown";
  source_schema: string;
};

function numberOrNull(value: unknown): MaybeNumber {
  return typeof value === "number" && Number.isFinite(value) ? value : null;
}

function openAIStyle(raw: any): UsageLedger {
  const u = raw.usage ?? {};
  return {
    input_uncached: numberOrNull(u.prompt_tokens),
    cache_read: numberOrNull(u.prompt_tokens_details?.cached_tokens),
    cache_write: numberOrNull(u.prompt_tokens_details?.cache_write_tokens),
    output_total: numberOrNull(u.completion_tokens),
    reasoning_output: numberOrNull(u.completion_tokens_details?.reasoning_tokens),
    reported_total: numberOrNull(u.total_tokens),
    reasoning_relation: "subset",
    source_schema: "openai-compatible-chat"
  };
}

Бұл мысал кәдімгі input мәселесін әлі шешпейді. Егер prompt_tokens cached input-ты қамтыса, мұнда input_uncached атауы тым нақты қойылған. Нақты адаптерде құжаттама белгілі endpoint үшін бөліністі растағанша, оны input_reported_total деп атаңыз. Содан кейін мынадай есеп жасаңыз:

ordinary_input = input_reported_total - cache_read

Мұны тек үш шарт бір уақытта орындалса ғана есептеңіз: cache read шынымен input total құрамына кірсе, екі мән бір сұрауға қатысты болса және айырма теріс болмаса. Шарттардың бірі бұзылса, null қайтарып, invalid_usage_relation жалауын қосыңыз және бастапқы JSON-ды сақтаңыз.

Anthropic үшін формула басқа. Prompt caching туралы құжаттамасында жалпы input input_tokens, cache_creation_input_tokens және cache_read_input_tokens қосындысы ретінде анықталған. Мұнда input_tokens пайдаланушы жіберген бүкіл контекстке емес, соңғы кэш нүктесінен кейінгі бөлікке қатысты. Cache read-ті «жалпы input» мәніне қосып, кейін жеңілдік ретінде тағы шегерсеңіз, бағаны қайтадан бұрмалайсыз.

Инварианттарды әр жазба үшін тексеріп отырыңыз:

if reasoning_output != null and output_total != null:
    assert reasoning_output <= output_total

if cache_read != null and cache_read < 0:
    reject record

if reported_total != null and input_total != null and output_total != null:
    compare reported_total with input_total + output_total

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

Контекст лимиті, генерация лимиті және rate limit әртүрлі сұрақтарға жауап береді

Қаржылық есепті API шектеулерімен жиі араластырады, өйткені екі сала да токендер туралы айтады. Бірақ контекст лимиті «сұрау мен жауап модель терезесіне сыя ма?» деген сұраққа жауап береді. Генерация лимиті «модель ағымдағы output үшін қанша жұмсай алады?» дегенді білдіреді. Rate limit «сұрауларды немесе токендерді белгілі аралықта қаншалықты жылдам тұтынуға болады?» деп сұрайды. Баға «бұл қанша тұрады?» дегенге жауап береді. Бір токен осы есептердің екеуіне немесе үшеуіне бірдей қатысуы мүмкін.

Күрделі reasoning бар сұрау үшін генерация қорын былай есептеген пайдалы:

requested_output_cap = max_completion_tokens
actual_output = visible_text + tool_arguments + reasoning + other_output
actual_output <= requested_output_cap

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

Мұны барлық сұрауға max_tokens мәнін жай ғана көтеріп емдемеңіз. Бұл тәсіл қателердің бір бөлігін жылдам жоятындықтан танымал. Бірақ ол қысқа фактілерді шығару жеткілікті тапсырмаларда ұзақ ішкі пайымдауға жол ашады. Тапсырма сыныптарын бөліңіз: ақпарат шығару, жіктеу, мәтін генерациясы, құжаттарды талдау, бағдарламалау, құралдармен жоспарлау. Әр сыныпқа output жоғарғы шегін және рұқсат етілген reasoning режимін белгілеңіз, содан кейін тұрақты мысалдар жиынында сапаны тексеріңіз.

Rate limit-ті де бағадан шығару мүмкін емес. Провайдер cache read-ті input токендері лимитіне қосуы немесе инференске жеткен токендерді ғана санауы мүмкін. Anthropic құжаттамасы тиімді кэштеу input_tokens түрін өзгертетінін, бірақ өңделген контекстің толық көлемін түсіну қажеттігін жоймайтынын бөлек ескертеді. Кезекті өзіңіздің «кәдімгі input» есептегішіңізбен құрсаңыз, ұзын кэштелген диалогтарда 429 қатесіне күтпеген жерден тірелуіңіз мүмкін.

Streaming кезінде соңғы usage келгенше күтіңіз

Streaming кезінде нақты құнды алынған чанктердің ұзындығына қарап есептеуге болмайды. Мәтіндік оқиғалар пайдаланушы көретін output-ты көрсетеді, бірақ кэш, reasoning және тіпті жалпы usage туралы қорытынды мәліметті қамтуға міндетті емес. OpenRouter-де stream үшін usage [DONE] алдында бір рет финалдық хабарламада қайтарылады. Anthropic-те қорытынды сандардың бір бөлігі message_delta ішінде келеді. Басқа API-де де ұқсас ережелер бар, бірақ оқиғалардың нақты тәртібін олардың құжаттамасынан тексеру керек.

Өңдеушіні екі кезеңді етіп жасаңыз. Stream кезінде ол пайдаланушыға арналған контентті жинап, алдын ала request_started күйін тіркейді. Соңғы usage келгеннен кейін қаржылық жазбаны жабады. Байланыс одан ерте үзілсе, сұрауды нөл деп жазбай, usage_pending немесе stream_interrupted деп белгілеңіз.

Жұмыс реті мынадай:

1. request_id, модель, reasoning параметрлері және басталу уақыты бар жазба жасаңыз.
2. Оқиғалардың мазмұны мен метадеректерін сақтаңыз, бірақ соңғы бағаны есептемеңіз.
3. Қорытынды usage оқиғасын оқып, оны схема адаптері арқылы өткізіңіз.
4. Осы модель мен маршрут үшін қолданылған прайс нұсқасымен бағаны есептеңіз.
5. Соңғы usage болмаса, сервер журналымен немесе статистика endpoint-імен кейінгі салыстыруды орындаңыз, егер ол қолжетімді болса.

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

Бір сұрауды тиынына дейін тарқата білу керек

Ойдан шығарылған шотты емес, есеп жүйесі түсінуі тиіс жазба формасын қарастырайық. Адаптер мынадай қалыпқа келтірілген usage алды делік:

{
  "model": "provider/model-x",
  "input_reported_total": 24000,
  "cache_read": 18000,
  "cache_write": 0,
  "output_total": 1400,
  "reasoning_output": 950,
  "reasoning_relation": "subset",
  "gateway_response_cache": "miss"
}

Егер осы схеманың құжаттамасы cache read input_reported_total құрамына кіретінін растаса, кәдімгі input 6000-ға тең. Одан кейін бір ғана input бағасын емес, бөлек тарифтерді қолданыңыз:

ordinary_input_cost = 6000 * p_input
cache_read_cost     = 18000 * p_cache_read
cache_write_cost    = 0 * p_cache_write
output_cost         = 1400 * p_output
request_cost        = төрт жолдың қосындысы

reasoning_output = 950 формулаға бесінші жол ретінде кірмейді. Ол екі пайдалы көрсеткіш береді:

reasoning_share = 950 / 1400
visible_output_approx = 1400 - 950

Біріншісі қандай сценарийлер output бюджетін пайымдауға жұмсайтынын көруге көмектеседі. Екіншісі «екі сөйлемдік жауап неге ұзын жауап сияқты қымбат?» деген шағымды тексеруге көмектеседі. Бірақ екінші көрсеткішті пайдаланушы көретін мәтін көлемінің уәдесі ретінде қолданбаңыз, ол жуық мән.

Енді келесі сұрау дәл сондай мәтінді қайтарды, бірақ шлюз деңгейінде response cache hit болып, usage нөлге тең делік. Шлюз ережелері сондай болса, бұл жауаптың бағасы нөл болуы мүмкін. Бірақ reasoning_share = 0 деп жазбаңыз. Бұл сұрауда reasoning орындалған жоқ. Дұрысы, not_applicable деп белгілеу, өйткені метрика болмаған модель жұмысын сипаттайды.

Айлық есептерді дәл осындай ұсақ-түйек бұзады. Cache hit-ті кәдімгі сұраулармен араластырсаңыз, reasoning-тің орташа үлесі кенет «жақсарады». Шын мәнінде модель шақырылмаған жауаптардың үлесін ғана арттырдыңыз.

Дашборд бір ғана графикті емес, себептерді көрсетуі керек

Total tokens графигі белгі ретінде пайдалы, бірақ шешім қабылдауға жеткіліксіз. Ол өскен кезде инженер бір минут ішінде себебін көруі тиіс: базалық контекст ұлғайды ма, cache read тоқтады ма, cache write пайда болды ма, output өсті ме, reasoning үлесі артты ма немесе басқа модельге маршрут өзгерді ме.

Негізгі дашбордта бес өлшем қалдырар едім: модель бойынша құн, кәдімгі input, cache read пен cache write, жалпы output, output ішіндегі reasoning үлесі. Егжей-тегжейі белгісіз сұраулар санын бөлек көрсетіңіз. Ол өссе, мәселе модельде емес, телеметрияда.

Қатаң ескерту ережелері де керек. Total tokens өскен сайын ескерту қоймаңыз. Әрекет етуді қажет ететін оқиғаларға қойыңыз:

• сұраулар көлемі өзгермесе де cache write күрт өсті;
• промпт үлгісі өзгергеннен кейін cache read төмендеді;
• модель ауысқан соң белгілі бір тапсырмадағы reasoning үлесі артты;
• stream соңғы usage-сіз аяқталды;
• сіздің есебіңіздегі баға сервер статистикасымен рұқсат етілген дөңгелектеу қатесінен артық мөлшерде сәйкес келмеді.

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

Мұндағы ең пайдалы әдет қарапайым: промптты, модельді, reasoning effort-ті немесе кэштеуді өзгертпес бұрын қысқа бақылау сұрауларын орындап, usage деректерін сапа бағасымен бірге сақтаңыз. Сонда талқылау «қымбаттап кетті» немесе «модель тым ұзақ ойлайды» деген сөздермен шектелмейді. Кэшке түспей қалған input көлемін, ішкі пайымдауға кеткен output мөлшерін және қойылған лимит жауапты қай жерде қысқартқанын көресіз.

Токендерді провайдерлер арасында бірдей етуге тырыспаңыз. Оларды тексерілетін етіңіз. Бастапқы өрістер, анық семантика, бөлек тарифтер, streaming-тің соңғы салыстыруы және reasoning-ті екі рет есептеуге тыйым салу сізге жаңа модельдер мен кезекті «үйлесімді» API-ге төтеп беретін есеп береді.