Стоимость токенов языковых моделей: практический метод расчета расходов на API

Поэтому оценка «у нас короткий промпт» почти ничего не говорит о фактических расходах.

Рабочий метод расчёта начинается с разделения токенов по типам, а заканчивается проверкой данных из реальных ответов API. Такой подход помогает понять, какая часть бюджета уходит на входной контекст, какая — на генерацию, и почему итоговая сумма в работающем сервисе может заметно превысить расчёт по тестовому запросу.

Анатомия тарификации LLM API

Токен — единица, на которую языковая модель разбивает текст при обработке. Это может быть целое слово, его часть или несколько символов. Провайдеры обычно указывают тариф за миллион токенов, отдельно для входных и выходных данных; кэшированный ввод, если он поддерживается, может тарифицироваться по собственной ставке.

Базовую стоимость запроса удобно представить так:

Общая стоимость = входные токены × тариф входа + кэшированные токены × тариф кэшированного ввода + исходящие токены × тариф генерации.

В формуле нужно использовать тарифы именно выбранной модели и провайдера. Универсальной цены токена нет: отличаются и ставки, и правила учёта отдельных типов токенов. Следовательно, оценка бюджета начинается не с усреднённой цены рынка, а с прайс-листа конкретного API.

Выходные токены часто обходятся в несколько раз дороже входных. Встречается соотношение от 2:1 до 6:1, а у некоторых моделей разница может быть ещё больше. Это связано с тем, что генерация ответа идёт последовательно: модель формирует токен за токеном. Поэтому длинный ответ способен стать основной статьёй расходов даже при коротком запросе.

Практический смысл прост: считать следует отдельно вход и выход. Если умножить общее число токенов на один тариф, бюджет будет систематически искажён. Особенно заметна ошибка в сценариях, где сервис принимает короткий вопрос, но возвращает подробный анализ, сводку или развернутую консультацию.

Почему короткий текст не гарантирует низкий счёт

Количество символов — ненадёжная замена токенам. Для английского языка часто используют грубую оценку: около четырёх символов или примерно 0,75 слова на токен. Для русского и других языков с нелатинским письмом разбиение обычно менее компактное: одно слово может состоять из большего количества токенов. Оценка порядка 1,5–2 символов на токен может служить ориентиром, но не точным измерителем.

На фактическую длину токенизированного текста влияют язык, формулировки, специальные символы и конкретная токенизация модели. Поэтому пересчёт по символам подходит для первого приближения, но не для выставления внутреннего лимита бюджета. Если продукт работает на нескольких языках, английская эвристика особенно легко создаёт ложное ощущение точности.

Есть и другая причина расхождения между размером пользовательского сообщения и размером запроса. API может получать полный контекст, а не только последнюю реплику. Например, чат-боту для ответа передают системные правила, предшествующую переписку и описание функций, которые модель вправе вызвать. Все эти данные могут участвовать в тарификации.

Практическая проверка начинается с учёта полного состава запроса:

• системная инструкция, которая задаёт роль и ограничения модели;
• сообщение пользователя и прикреплённые к нему данные;
• история диалога, если она повторно передаётся при каждом обращении;
• описания инструментов и функций, доступных модели;
• параметры и служебные данные, учитываемые конкретным API.

В приложении с длинными диалогами именно повторная отправка истории может постепенно увеличивать входной объём. Пользователь видит одну новую фразу, тогда как модель каждый раз получает значительную часть прежнего контекста. Следовательно, измерять нужно не только отдельный промпт, но и полный запрос на том этапе, где он отправляется в API.

Цена запроса определяется всем контекстом, который получил API, и всеми токенами, которые модель произвела, включая те, что не попали в видимый ответ.

Reasoning-модели: расходы за невидимую часть ответа

У reasoning-моделей, предназначенных для задач с многоэтапным анализом, часть вычислений может отражаться во внутренних токенах рассуждения. Пользователь не видит их в итоговом тексте, но в ряде API они учитываются как исходящие токены и тарифицируются по правилам output.

Это меняет логику оценки: короткий финальный ответ не обязательно означает малый объём генерации. Модель может выполнить больше внутренних шагов, прежде чем сформировать несколько предложений для пользователя. При этом точный объём таких токенов заранее может быть неизвестен и зависит от задачи и поведения модели.

Для бюджета важны не предположения о том, сколько модель «думает», а поля фактического использования, которые возвращает API. Если провайдер предоставляет отдельную разбивку по reasoning-токенам, её стоит сохранять вместе с остальными метриками. Если отдельного поля нет, следует опираться на доступную агрегированную статистику и не пытаться восстановить скрытый объём по длине ответа.

При выборе модели разумно сравнивать не только качество результата и тарифы за миллион токенов, но и расход на типичных задачах. Модель с более низкой ставкой может оказаться дороже в конкретном сценарии, если для получения нужного результата ей требуется больше токенов или повторных обращений. И наоборот, более дорогая модель может быть экономически оправданна, если стабильно решает задачу за один запрос. Это проверяется на рабочих данных, а не выводится из названия модели.

Отдельный уровень выбора — где именно выполняется обработка. В некоторых мобильных продуктах часть функций может работать на устройстве, а часть — через облачный API; это разные модели затрат и ограничений. Например, обсуждая развитие мобильных платформ и вычислений на устройстве, полезно следить за стратегией Qualcomm в сегменте флагманских чипов и ИИ. Для расчёта расходов на облачный API ключевым остаётся фактический объём обращений к провайдеру: локальная обработка сама по себе не создаёт токены в его счёте.

Проверка расходов по метаданным API

Предварительный подсчёт полезен на этапе проектирования, но надёжный аудит строится на данных ответов. Во многих API для этого предусмотрено поле usage, где содержатся значения вроде prompt_tokens, completion_tokens и total_tokens. Точный набор полей зависит от провайдера и модели, поэтому формат следует сверять с используемым API.

Логика проверки состоит из нескольких последовательных действий:

1. Сохранять usage для каждого запроса. Рядом с числом токенов записывают модель, тип задачи, время и результат вызова. Это позволяет не смешивать разные сценарии и тарифы.

2. Разделять вход и выход. Общий total_tokens полезен для контроля объёма, но для стоимости его недостаточно, если входные и исходящие токены имеют разные ставки.

3. Учитывать кэширование отдельно. Если API возвращает число кэшированных входных токенов, его следует сопоставлять с соответствующим тарифом, а не прибавлять к обычному вводу.

4. Сопоставлять usage с тарифами нужной модели. При смене модели или цен таблица расчёта должна обновляться, иначе старые ставки продолжат давать неверную оценку.

5. Сверять расчёт с агрегированным счётом провайдера. Расхождение помогает обнаружить пропущенные типы токенов, повторные вызовы или ошибки в собственной системе учёта.

Поле total_tokens не заменяет раздельный расчёт: оно сообщает общий объём, но не обязательно объясняет его стоимость. Поэтому в журнале расходов желательно сохранять каждую компоненту, которую API отдаёт отдельно. Для reasoning-моделей это особенно полезно, если ответ содержит статистику по внутренним токенам.

Теоретический подсчёт промпта можно автоматизировать локально. Для Python существуют библиотеки токенизации и учёта тарифов, в том числе tiktoken для локальной оценки токенов моделей OpenAI, tokencost для оценки стоимости промптов и генераций, LiteLLM для трекинга между провайдерами и genai-prices для сопоставления структурированных логов с тарифными сетками. Такие инструменты ускоряют предварительный анализ, но не отменяют сверку с usage: окончательным ориентиром остаётся ответ API, который действительно обработал запрос.

От тестового расчёта к бюджету в продакшене

Оценка по одному запросу редко описывает реальные расходы приложения. В продакшене меняются длина контекста и формулировки пользователей, возникают повторные отправки после ошибок, а история диалога накапливается. В результате итоговый счёт может оказаться в 1,5–2 раза выше первоначальной оценки. Этот коэффициент полезен как предупреждение о масштабе возможного расхождения, но не как универсальная поправка для любого продукта.

Лучше рассматривать бюджет как сумму измеряемых сценариев. Например, сервис может отдельно учитывать короткие справочные запросы, длинные диалоги и задачи, где модель вызывает инструменты. Для каждого сценария считают типичный вход и выход по фактическому usage, а затем проверяют, как меняются расходы при росте объёма обращений.

Особое внимание нужно уделить ретраям — повторным запросам после неудачной попытки. Если приложение повторяет обращение автоматически, каждый такой вызов потенциально добавляет расход. Важно собирать число повторов и связывать его с конкретной причиной: сетевой ошибкой, тайм-аутом, невалидным ответом или логикой повторной генерации. Точную стоимость сбоев без метрик конкретного стека заранее определить нельзя.

Для планирования полезно заложить запас к первоначальной оценке. Практический ориентир — резерв порядка 1,5–2 раз, пока система не накопила достаточно продакшн-данных. Это не значит, что фактический счёт обязательно вырастет ровно вдвое. Запас покрывает неопределённость контекста, повторов и поведения пользователей, а после сбора статистики его можно заменить расчётом по измеренным сценариям.

При этом нужно следить за динамикой, а не только за суммой за месяц. Если среднее число входных токенов на запрос постепенно растёт, вероятная причина может быть в расширившейся системной инструкции или увеличении передаваемой истории. Если растёт выход, стоит изучить длину ответов и настройки генерации. Такая детализация превращает вопрос «почему подорожало?» в проверяемую гипотезу.

Снижение затрат: кэш и пакетная обработка

Оптимизация начинается с поиска повторяющихся расходов. Если значительная часть запросов содержит одинаковый префикс — например, общие инструкции или стабильный контекст, — можно рассмотреть Prompt Caching, если такой механизм поддерживается провайдером и подходит формату запросов. Кэширование снижает цену повторно используемого ввода; в некоторых случаях скидка на кэшированные токены может доходить до 80–90% относительно стандартной ставки. Конкретный эффект зависит от модели, условий кэширования и структуры обращений.

Чтобы оценить пользу, нужно сравнить долю повторяющегося контекста с объёмом уникальных данных. Если запросы почти всегда различаются с самого начала, кэш может дать меньший эффект. Если же большая часть системного текста повторяется, потенциальная экономия заметнее. В любом случае в расчёте следует учитывать отдельный тариф на кэшированный ввод, а не считать, что повторная часть бесплатна.

Второй инструмент — Batch API для задач, которым не требуется ответ в реальном времени. Пакетная обработка может давать скидку 50% при стандартном окне выполнения до 24 часов. Она подходит, например, для отложенной обработки массива текстов, когда результат не нужен сразу. Для интерактивного чата с мгновенным ожиданием такая задержка может быть неприемлема, поэтому экономию нужно сопоставлять с требованиями продукта.

Иногда более простая оптимизация состоит в сокращении избыточного контекста: например, в ограничении передаваемой истории или в пересмотре слишком подробных инструкций. Но любое сокращение нужно проверять на качестве результата. Если уменьшение промпта вызывает больше повторных запросов или ухудшает ответы настолько, что пользователи обращаются к модели снова, экономия на одном вызове может обернуться ростом общих затрат.

Стоимость токенов становится управляемой, когда продукт учитывает фактический расход на уровне запросов, разделяет тарифы по типам токенов и связывает метрики с пользовательскими сценариями. Первоначальный расчёт нужен для планирования, но бюджет надёжно уточняется только на данных API. В ближайшей перспективе именно качество такого учёта, наряду с кэшированием и более аккуратной работой с контекстом, будет определять, насколько предсказуемо генеративные функции масштабируются в цифровых сервисах.