Оценка стоимости API по токенам сводится к простой формуле: возьмите тарифы за входные и выходные токены в официальном прайсинге, измерьте средний объём токенов на типовой запрос, умножьте на число запросов и отдельно добавьте кэшируемые токены, tool calls, ретраи и соседние вызовы вроде embeddings. Метод даёт рабочую оценку для текстовых запросов, но плохо подходит для мультимодальных сценариев, провайдеров с пакетными скидками и систем, где длина ответа сильно скачет или модель выбирается динамически без логов. Он также не покрывает НДС, хранение, сеть и стоимость внешних сервисов.
Короткий ответ
Базовый расчёт выглядит так: цена за период равна сумме стоимости входных токенов, выходных токенов и всех дополнительных тарифицируемых токенов. Если провайдер публикует цену за 1 000 000 токенов, используйте такую форму.
стоимость = (input_tokens / 1 000 000) × price_input + (output_tokens / 1 000 000) × price_output + (cached_input_tokens / 1 000 000) × price_cached
Главное правило: считайте не один средний запрос, а несколько сценариев с разной длиной контекста и ответа. Для каждого сценария определите состав токенов, цену за один запрос и долю трафика. После этого умножьте цену сценария на число запросов за день или месяц.
| Компонент | Откуда взять | Что часто забывают |
|---|---|---|
| Входные токены | System, developer, user, few-shot, retrieved context, схемы формата ответа | Системный промпт и текст из RAG |
| Выходные токены | Фактические ответы модели или верхняя граница по типовым прогонам | JSON-ключи, длинные объяснения, длинный код |
| Кэшируемые токены | Если провайдер тарифицирует cached input отдельно | Смешение cached и обычного input |
| Накладные вызовы | Embeddings, moderation, повторные запросы, tool calls | Аргументы функций и результат инструмента, который возвращается в модель |
Если расчёт нужен для бюджета, ориентируйтесь на официальную страницу цен, например OpenAI API Pricing, а итог проверяйте по фактическому usage в кабинете, например в usage dashboard.
Что понадобится
- Актуальный прайсинг провайдера. Нужны ставки отдельно для input, output и, если есть, cached input.
- Список моделей и маршрутов. Если приложение переключается между несколькими моделями, их нельзя усреднять в один тариф.
- Набор типовых запросов. Минимум по нескольким сценариям: короткий чат, длинный контекст, RAG, JSON-экстракция, код, суммаризация.
- Инструмент подсчёта токенов. Для локальной прикидки подойдёт tiktoken или счётчики из SDK. Для финального биллинга ориентируйтесь на usage провайдера.
- Таблица. Excel, Google Sheets или любой калькулятор, где удобно хранить формулы по сценариям.
- Логи или пилотный трафик. Без них трудно оценить реальную длину ответов и частоту ретраев.
Если проект ещё не запущен, хватит репрезентативного набора промптов и нескольких десятков тестовых прогонов. Если проект уже работает, лучше выгрузить usage по endpoint, версии промпта и модели. Тогда вы оцените не теоретическую, а фактическую структуру расходов.
Пошаговый план
1. Зафиксируйте модель, тариф и единицу измерения
Начните не с токенов, а с тарифа. Убедитесь, что вы смотрите цену именно той модели, которую реально вызываете в коде. Провайдеры публикуют цены по-разному: за 1 000 токенов, за 1 000 000 токенов, отдельно за input и output, иногда ещё отдельно за cached input, batch и priority режимы. Если в системе есть fallback на другую модель, это нужно считать отдельной строкой.
На этом шаге полезно выписать всё в явном виде: название модели, цена input, цена output, цена cached input, есть ли скидка за batch, какие ограничения по контексту и max output. Даже небольшая путаница здесь потом даст крупную ошибку в бюджете.
2. Разбейте нагрузку на сценарии, а не на один средний запрос
Один усреднённый запрос почти всегда искажает оценку. Чат на 200 токенов и RAG-ответ с длинным контекстом стоят по-разному. Выделите сценарии, которые действительно потребляют деньги: короткие ответы, длинные объяснения, структурированный JSON, ответы по документам, tool calling, генерация кода.
| Сценарий | Что считать во входе | Что считать в выходе | Комментарий |
|---|---|---|---|
| Короткий чат | System + user | Короткий текстовый ответ | Обычно низкая вариативность |
| RAG | System + user + retrieved chunks | Ответ с цитатами или пересказом | Главный источник перерасхода — длинный контекст |
| JSON-экстракция | System + user + schema | Структурированный JSON | Ключи и строгий формат увеличивают output |
| Tool calling | System + user + tool schema + tool result | Аргументы вызова и финальный ответ | Считайте оба шага, а не только первый ответ модели |
Для каждого сценария задайте долю трафика. Если вы не знаете долю заранее, используйте текущие логи или консервативную верхнюю оценку для самых дорогих сценариев.
3. Измерьте входные токены на репрезентативных примерах
Считайте все токены, которые реально уходят в API. Это не только текст пользователя. В бюджет должны попасть системный промпт, developer message, few-shot примеры, инструкции по формату, схемы JSON, описания tool functions, извлечённые документы из RAG и технические префиксы, если вы их вставляете программно.
Локальный подсчёт полезен для планирования, но для биллинга важнее то, что покажет провайдер в usage. У чатовых моделей могут быть скрытые служебные токены сериализации сообщений. Поэтому на этапе пилота сверяйте локальный счётчик с фактическими данными и доверяйте провайдеру там, где цифры расходятся.
4. Оцените выходные токены по фактическим ответам, а не по max tokens
Частая ошибка — брать максимальный лимит ответа как среднее значение. Это почти всегда завышает бюджет. Обратная ошибка — считать только среднее по нескольким коротким ответам и не учитывать длинный хвост. Практичнее измерять типовую длину ответа по нескольким прогонам на каждом сценарии и отдельно смотреть длинные случаи.
Если вы используете structured outputs или строгий JSON, закладывайте более стабильную, но часто не самую маленькую длину ответа: названия полей, скобки, массивы и повторяющиеся ключи тоже токены. Если приложение порождает код, таблицы или длинные пояснения, вариативность ответа возрастает, и один средний замер уже недостаточен.
5. Добавьте всё, что не видно в одном запросе
Стоимость редко ограничивается одной генерацией. В реальной системе есть ретраи, модерация, embeddings для документов и запросов, повторные вызовы после tool call, суммаризация истории, chunking и иногда отдельный reranking. Всё это либо тарифицируется токенами, либо создаёт дополнительные вызовы, которые тоже надо учитывать.
Для RAG полезно считать отдельными строками: индексацию документов, запросные embeddings, основной генеративный ответ и возможные последующие уточнения. Для tool calling считайте как минимум четыре части: схему инструмента, аргументы, которые генерирует модель, результат инструмента, который возвращается обратно в модель, и финальный ответ пользователю.
6. Переведите токены в цену за запрос и за период
После измерений заполните расчёт по каждому сценарию. Формула одна и та же, но значения разные.
цена_за_запрос = (input / 1 000 000) × price_input + (output / 1 000 000) × price_output + (cached / 1 000 000) × price_cached
цена_за_период = сумма по всем сценариям: цена_за_запрос × число_запросов_сценария
Если часть контекста стабильно повторяется и провайдер применяет к ней более дешёвую cached-тарификацию, выделите эти токены отдельной колонкой. Если есть batch-режим или другой тарифный режим, не смешивайте его со стандартными вызовами. Резерв на неопределённость лучше добавлять не процентом на глаз, а явными строками: ретраи, длинные ответы, рост RAG-контекста, непредвиденные tool calls.
7. Проверьте расчёт на пилоте и обновляйте его после изменений промпта
Сделайте короткий прогон на реальном трафике или хотя бы на контрольном наборе запросов. Снимите usage по каждому сценарию и сравните с расчётом. Если разница заметная, обычно причина в одном из трёх мест: вы забыли часть входного контекста, недооценили длину ответа или не посчитали дополнительные вызовы.
Важно обновлять таблицу после каждого изменения системного промпта, JSON-схемы, длины контекста, набора tools и логики маршрутизации между моделями. На практике стоимость чаще растёт не из-за самой модели, а из-за расширения промпта и контекста вокруг неё.
Типичные ошибки
- Считать символы вместо токенов. Для грубой прикидки это допустимо, но для бюджета бесполезно: русский текст, код и JSON токенизируются по-разному.
- Игнорировать системный промпт. Если он отправляется в API на каждом запросе, он тарифицируется на каждом запросе.
- Смешивать input и output. У них часто разные цены, иногда разница существенная.
- Не выделять cached input. Если у провайдера отдельный тариф на кэшируемые токены, ошибка в этой колонке искажает расчёт.
- Забывать tool calls. Многие считают только первый ответ модели и не добавляют аргументы функции, результат инструмента и финальную реплику.
- Использовать один средний сценарий. Это скрывает дорогие длинные запросы, которые и определяют большую часть расхода.
- Оценивать output по max tokens. Так бюджет легко завысить.
- Не считать соседние вызовы. Embeddings, moderation, классификация и reranking часто живут в других endpoint, но расход создают общий.
- Не пересматривать расчёт после изменений промпта. Любое расширение контекста напрямую увеличивает input tokens.
- Забывать про нетокенные расходы. Токенный расчёт не включает НДС, хранение файлов, векторную базу, сетевой трафик и внешние API.
Если вы планируете строгий бюджет, отдельно фиксируйте верхнюю границу для самых дорогих сценариев. Средняя стоимость полезна для прогноза, но лимиты нужны для защиты от редких длинных ответов и всплесков контекста.
Как проверить результат
- Сделайте контрольную выборку. Возьмите по нескольку десятков запросов на каждый сценарий и прогоните их через тот же код, что используется в приложении.
- Сохраните usage по каждому вызову. Нужны как минимум model, input tokens, output tokens, cached tokens, request id и версия промпта.
- Сравните локальный счётчик с биллингом провайдера. Если цифры отличаются, для денег ориентируйтесь на провайдера, а локальный токенайзер используйте только для предварительной оценки.
- Посчитайте фактическую цену за запрос. Разделите стоимость периода на число запросов и проверьте, укладывается ли результат в расчётный диапазон по сценариям.
- Разберите расхождения по компонентам. Смотрите отдельно рост входных токенов, рост выходных токенов, ретраи, tool calls и RAG-контекст. Общая сумма без разреза мало помогает.
Хорошая практика — хранить в логах не только usage, но и размеры прикреплённого контекста: число чанков, общий объём текста из RAG, включён ли tool call, какой response format применялся. Тогда удорожание можно связать с конкретной причиной, а не искать его по всей системе.
Если расчёт нужен для закупки или лимитов, проверьте ещё два режима: обычный день и пиковый день. Средняя недельная картина редко показывает, сколько будут стоить длинные запросы в конце месяца, когда накопится история диалога или вы расширите RAG-контекст.
FAQ
Можно ли считать стоимость по символам или словам
Только для очень грубой оценки. Стоимость считает провайдер по токенам, а число токенов зависит от языка, пунктуации, кода, JSON и способа сериализации сообщений. Для бюджета нужна токенизация или фактический usage.
Нужно ли учитывать system prompt и few-shot примеры
Да. Всё, что отправляется в модель, обычно входит во входные токены. Чем длиннее постоянные инструкции, тем выше цена каждого запроса даже при коротких сообщениях пользователя.
Как считать RAG
Считайте отдельно индексацию документов, запросные embeddings, извлечённые чанки, которые попадают в генерацию, и сам финальный ответ модели. Самый дорогой элемент часто не генерация, а слишком длинный retrieved context.
Как считать tool calling и structured outputs
Нужно включить схему инструмента, аргументы функции, результат инструмента, возвращённый в модель, и финальный ответ. Для structured outputs учитывайте токены JSON-ключей и служебных символов, а не только значения полей.
Что делать, если длина ответа сильно плавает
Не используйте один средний показатель. Разбейте трафик на сценарии, отдельно измерьте длинный хвост и, если возможно, ограничьте ответ параметрами генерации и более жёстким форматом.
Когда расчёт по токенам не даёт надёжного бюджета
Когда у вас мультимодальные запросы, динамический выбор между моделями без логов, сложные скидки по batch или priority режимам, либо когда стоимость сильно зависит от внешних сервисов, а не от самой генерации. В таких случаях токенный расчёт остаётся только одной частью общей сметы.