Цена «за миллион токенов» почти ничего не говорит о бюджете продукта сама по себе. На итоговый счёт влияют длина истории, доля повторяющегося контекста, число шагов агента, поиск, кэширование и режим обработки. Разбираем расчёт на понятных сценариях и показываем, где AI API дорожает незаметно.
Коротко
- Считать нужно отдельно входные, кэшированные и выходные токены, а также вызовы инструментов.
- Длинная история чата оплачивается заново при каждом запросе, если её не сокращать и не кэшировать.
- В агентных системах один пользовательский запрос может превратиться в 5–20 обращений к модели.
- Batch, prompt caching и маршрутизация запросов между моделями часто сокращают расходы сильнее, чем смена провайдера.
Базовая формула стоимости
Для обычного текстового запроса расчёт выглядит так:
Стоимость = входные токены × тариф входа + выходные токены × тариф выхода + инструменты + хранение кэша.
Все токенные тарифы обычно указываются за 1 млн токенов. Поэтому стоимость одного запроса можно оценить формулой:
(input_tokens / 1 000 000 × input_price) + (output_tokens / 1 000 000 × output_price)
Например, если запрос содержит 3 000 входных токенов, ответ — 700 токенов, а условная модель стоит $1 за миллион входных и $5 за миллион выходных токенов, один вызов обойдётся примерно в $0,0065. При 100 тысячах таких вызовов это уже $650 без учёта поиска, повторных попыток и агентных шагов.
Открыть живое сравнение цен AI API и калькулятор нагрузки →
Почему чат дорожает с каждым сообщением
В простом интерфейсе пользователь видит одно новое сообщение. API часто получает всю предыдущую переписку, системную инструкцию, найденные документы и описание доступных инструментов. На двадцатом сообщении вход может быть в десять раз длиннее, чем на первом.
Если средняя история выросла с 2 000 до 20 000 токенов, стоимость ответа увеличится даже при неизменной длине результата. Практический контроль состоит из четырёх шагов:
- ограничить окно последних сообщений;
- суммировать старую часть диалога;
- вынести постоянную инструкцию в prompt cache, если провайдер это поддерживает;
- логировать фактические токены каждого запроса, а не оценивать их по числу сообщений.
Три сценария бюджета
| Сценарий | Что создаёт расход | Главный риск | Что оптимизировать |
|---|---|---|---|
| Чат поддержки | История диалога, база знаний, ответ | Повторная отправка длинной истории | Суммаризация, кэш, компактная модель для классификации |
| RAG по документам | Поиск, фрагменты документов, генерация | Слишком много нерелевантного контекста | Качество retrieval, reranking, лимит фрагментов |
| AI-агент | Планирование, инструменты, проверка результата | Неограниченные циклы и повторные попытки | Лимит шагов, дешёвая модель-маршрутизатор, контроль ошибок |
RAG: цена определяется не только моделью
В системе поиска по документам токены генерации могут оказаться не самой большой статьёй расходов. В бюджет входят эмбеддинги, векторный поиск, reranking, хранение индекса и контекст, который отправляется модели.
Если retrieval возвращает двадцать больших фрагментов вместо пяти точных, вы платите больше и часто получаете хуже ответ. Поэтому работа над качеством поиска одновременно повышает точность и снижает стоимость. Полезная метрика — не цена одного токена, а стоимость корректного ответа: общий расход, поделённый на количество ответов, прошедших проверку качества.
AI-агенты: один запрос пользователя — это не один вызов API
Агент может сначала составить план, затем выполнить поиск, вызвать код, перечитать результат, исправить ошибку и только после этого написать ответ. В интерфейсе это выглядит как одна операция, в биллинге — как цепочка обращений.
Для агента нужно учитывать:
- среднее и максимальное число шагов;
- долю шагов, на которых нужна самая сильная модель;
- цену серверных инструментов и веб-поиска;
- число повторных попыток после ошибки;
- размер контекста, который переносится между шагами.
Без лимита шагов редкий сбой способен съесть экономию за весь день. Производственная система должна останавливать цикл по бюджету, времени и числу действий.
Где реально экономить
1. Маршрутизировать задачи
Классификацию, извлечение полей, модерацию и простое резюме обычно нет смысла отдавать самой дорогой модели. Сильную модель стоит включать для сложного рассуждения, спорных случаев и финальной проверки.
2. Использовать кэширование
Большая системная инструкция, справочник или повторяющийся документ могут составлять основную часть входа. Кэширование уменьшает цену повторной обработки, но хранение кэша также может тарифицироваться. Оно выгодно только при достаточной частоте повторного использования.
3. Переносить несрочные задачи в Batch
Провайдеры предлагают сниженные тарифы для асинхронных пакетных задач. Этот режим подходит для обогащения каталога, классификации архива, генерации описаний и ночных отчётов, где ответ не нужен за секунды.
4. Ограничивать выход
Выходные токены часто дороже входных. Чёткая схема ответа, лимит длины и структурированный JSON уменьшают расход и упрощают дальнейшую обработку.
API или локальная модель
Облачный API удобен при переменной нагрузке: нет затрат на оборудование, обновления и простой GPU. Локальная модель становится интереснее, когда запросы стабильны, данные нельзя отправлять наружу или задержка и полный контроль важнее доступа к самой сильной модели.
Сравнивать нужно полную стоимость: оборудование, электричество, инженерное сопровождение, мониторинг, резервирование и фактическую загрузку. Для персонального компьютера можно начать с нашего подбора локальной модели по памяти и устройству.
Какие метрики поставить в продукте
- стоимость одного пользовательского действия;
- токены входа и выхода по модели и функции;
- доля кэшированного входа;
- среднее число шагов агента;
- стоимость успешного результата;
- расход на повторные попытки и ошибки;
- стоимость по клиенту, команде или проекту.
Лимит на месяц без лимита на один запрос не защищает продукт. Нужны оба уровня: общий бюджет и предельная стоимость отдельной операции.
Как выбрать модель без ложной экономии
Самая дешёвая модель по прайс-листу может оказаться дороже в работе, если ей требуется больше контекста, повторных попыток или ручной проверки. Самая дорогая может быть выгоднее, если решает задачу с первого раза. Поэтому сравнение должно проходить на собственном наборе запросов.
- Соберите 50–200 реальных задач.
- Зафиксируйте критерии правильного результата.
- Прогоните одинаковые запросы через несколько моделей.
- Измерьте качество, задержку и полную стоимость.
- Выберите модель или маршрутизацию для каждого класса задач.
Источники и актуальность
Тарифы меняются, поэтому AI Feed обновляет таблицу отдельно от этой методики. Для проверки используются официальные страницы OpenAI, Anthropic, Google Gemini и xAI. Дата цен и время последнего обновления отображаются непосредственно в мониторинге AI API.
Вывод: бюджет AI-продукта определяется архитектурой чаще, чем логотипом провайдера. Сначала измерьте фактические токены и число вызовов, затем оптимизируйте контекст, маршрутизацию и режим обработки — и только после этого сравнивайте цены моделей.
