Стоимость токенов в API: как посчитать цену запроса и месячный бюджет

Поэтому вопрос «сколько стоит AI-бот» нельзя считать по принципу «ну там же просто чат». Просто чат — это когда два человека переписываются в Telegram. В AI-продукте за каждым ответом может стоять несколько API-запросов и отдельный счётчик токенов.

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

Сообщение, API-запрос и сценарий — это не одно и то же

Сначала нужно развести три сущности.

Сообщение пользователя — то, что человек написал в интерфейсе.

API-запрос — полный пакет данных, который система отправила модели: сообщение пользователя, системный промпт, история, контекст, документы, служебные инструкции.

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

Деньги считаются по токенам и API-запросам. Месячный бюджет — по сценариям и нагрузке.

Вот здесь обычно и начинается ошибка. Бизнес считает сообщение. Разработчик считает вызовы. Провайдер считает токены. Платит, как обычно, бизнес.

Из чего складывается стоимость одного API-запроса

Стоимость запроса обычно состоит из нескольких частей: входные токены, кэшированные входные токены, выходные токены и дополнительные вызовы модели.

У OpenAI в прайсе отдельно указаны input, cached input и output tokens; также есть Batch-режим со скидкой 50% для асинхронной обработки. Например, на актуальной странице OpenAI для GPT-5.4 mini указаны $0.75 за 1 млн input tokens, $0.075 за 1 млн cached input tokens и $4.50 за 1 млн output tokens.

Формула: как посчитать стоимость одного запроса

Базовая формула простая:

стоимость = количество токенов / 1 000 000 × цена за 1 млн токенов

Если у вас 10 000 входных токенов, а цена входа — $1 за 1 млн токенов, расчёт будет таким:

10 000 / 1 000 000 × 1 = $0.01

То есть 10 000 таких токенов стоят один цент.

Но один API-запрос обычно состоит из нескольких частей. Поэтому считаем каждую отдельно:

стоимость API-запроса = входные токены + кэшированные токены + выходные токены

Точнее:

стоимость API-запроса = стоимость входа + стоимость кэша + стоимость выхода

Если сценарий включает несколько обращений к модели:

стоимость сценария = сумма всех API-вызовов

А месячный бюджет считается уже по нагрузке:

месячный бюджет = стоимость сценария × количество сценариев в месяц

Перед расчётом нужно проверить:

• какую модель используете;
• цену входных токенов;
• цену выходных токенов;
• цену кэшированных токенов;
• есть ли отдельные ставки для Batch API;
• есть ли дополнительные расходы на инструменты, поиск, хранение или платформенные функции.

Цены нельзя брать из старого скриншота. API-прайсы живут своей жизнью. Перед запуском или пересчётом бюджета нужно сверять ставки на официальных страницах провайдера. У OpenAI, Anthropic и Google структура тарификации различается: вход, выход, кэш, Batch, инструменты и хранение могут считаться отдельно.

Как посчитать цену одного запроса: простой пример

Возьмём условный запрос к модели уровня GPT-5.4 mini. По актуальному прайсу OpenAI для этой модели указаны: $0.75 за 1 млн input tokens, $0.075 за 1 млн cached input tokens и $4.50 за 1 млн output tokens.

Допустим, один API-запрос выглядит так:

• 2 000 обычных входных токенов;
• 1 000 кэшированных входных токенов;
• 700 выходных токенов.
• Считаем:

Один такой API-запрос стоит примерно $0.0047.

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

Если таких запросов 10 000 в месяц:

$0.004725 × 10 000 = $47.25 в месяц

Если 100 000 запросов:

$0.004725 × 100 000 = $472.50 в месяц

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

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

Что считать единицей расчёта в разных AI-продуктах

Одна из частых ошибок — считать «один запрос» одинаково для всех продуктов.

Для простого чат-бота один запрос — это реплика пользователя и ответ модели.

Для RAG-бота один сценарий включает вопрос, поиск по базе знаний, подстановку найденных фрагментов и генерацию ответа.

Для суммаризации один документ может превратиться в несколько API-вызовов, если он большой.

Для CRM-ассистента один сценарий может включать данные клиента, сделку, историю заявок, комментарии менеджеров и регламент ответа.

Поэтому сначала нужно определить единицу расчёта.

Бот поддержки, который отвечает на короткие вопросы, и AI-ассистент в CRM, который анализирует карточку клиента и готовит письмо менеджеру, — это разные нагрузки.

В интерфейсе оба могут выглядеть как чат. Для бюджета это две разные машины.

Как посчитать месячный бюджет AI API

Чтобы посчитать месячный бюджет, нужно пройти четыре шага.

1. Определить основные сценарии

Не стоит считать «AI-бота вообще».

Лучше разделить его работу на сценарии:

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

У каждого сценария будет своя стоимость.

2. Оценить стоимость каждого сценария

Для каждого сценария нужно посчитать:

• сколько токенов уходит на вход;
• какая часть входа может быть кэширована;
• сколько токенов модель генерирует на выходе;
• сколько внутренних вызовов API запускается;
• какая модель используется.

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

3. Умножить на количество обращений

Формула:

месячный бюджет = стоимость сценария × количество сценариев в месяц

Если сценариев несколько, считаем каждый отдельно и складываем:

месячный бюджет = расходы на сценарий А + расходы на сценарий Б + расходы на сценарий В

Пример:

короткие вопросы: 8 000 обращений × $0.001 = $8;

RAG-вопросы: 2 000 обращений × $0.006 = $12;

суммаризация документов: 500 документов × $0.04 = $20;

генерация отчётов: 300 отчётов × $0.08 = $24.

Итого:

$8 + $12 + $20 + $24 = $64 в месяц

Это не универсальная цена. Это шаблон расчёта. В реальном проекте нужно подставлять свои сценарии, модель, длину входа, длину выхода и нагрузку.

4. Добавить запас на пиковую нагрузку

Расчёт без запаса выглядит красиво только до первого живого пользователя.

В реальности появляются длинные ответы, повторные вопросы, тесты сотрудников, рост базы знаний, пиковые дни и пользователи, которые любят вставить в чат пол-романа с вопросом: «Ну что думаешь?»

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

Почему нельзя считать только «средний запрос»

Средний запрос удобен. И опасен.

Он сглаживает тяжёлые сценарии. А бюджет часто съедают именно они.

Например, в среднем бот отвечает на 500 токенов. Но 10% запросов требуют длинного ответа, подстановки документов и нескольких API-вызовов. В отчёте всё выглядит нормально, пока эти 10% не начинают повторяться каждый день.

Лучше считать три сценария.

Если считать только средний сценарий, можно сильно ошибиться. Особенно в RAG, CRM-ассистентах, аналитических отчётах и агентных цепочках.

Средний пользователь — удобная фикция. Живой пользователь всегда приходит со своим файлом, странным вопросом и прекрасной идеей «а давайте ещё вот это добавим».

Примеры расчёта для разных AI-сценариев

Ниже не точные цены для всех случаев, а логика расчёта. Конкретные цифры зависят от модели, прайса, длины входа, длины выхода, кэша и количества вызовов.

Чат-бот поддержки

Единица расчёта: одно обращение или диалоговая сессия.

Главный риск: история диалога и длинные ответы.

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

Расходы растут, если:

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

Для поддержки важна дисциплина контекста. Не нужно каждый раз отправлять модели всё, что пользователь сказал за последние три дня. Модель прочитает. Счётчик тоже.

RAG-бот по базе знаний

Единица расчёта: вопрос с подбором контекста.

Главный риск: большой вход.

Пользователь может спросить одну строку:

«Как оформить возврат?»

Но система найдёт 3–5 фрагментов базы знаний, добавит их в промпт и попросит модель сформировать ответ.

В этом сценарии главный источник расходов — не вопрос пользователя, а документы, которые система подкладывает в запрос.

Расходы растут, если:

• в запрос попадает слишком много документов;
• фрагменты слишком длинные;
• поиск работает неточно;
• контекст добавляется «на всякий случай»;
• ответы не ограничены по длине.

Для RAG важно считать весь контекст, который система отправляет модели.

Суммаризация документа

Единица расчёта: один документ или один фрагмент документа.

Главный риск: объём входа и несколько вызовов модели.

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

Особенно аккуратно нужно считать:

• договоры;
• отчёты;
• расшифровки встреч;
• коммерческие предложения;
• технические задания;
• длинные регламенты.

Нельзя оценивать стоимость суммаризации по одному тестовому абзацу. Один абзац не равен документу на 80 страниц. Бюджет это быстро объяснит.

AI-ассистент в CRM

Единица расчёта: одна задача менеджера.

Главный риск: служебные данные.

CRM-ассистент может подготовить ответ клиенту, оценить заявку, подсказать следующий шаг, проверить данные или собрать краткую сводку по сделке.

В модель могут уходить:

• данные клиента;
• история заявок;
• комментарии менеджеров;
• статусы заказа;
• предыдущие письма;
• регламент ответа;
• ограничения по тону;
• данные из карточки сделки.

Если отправлять всё без отбора, запрос быстро раздувается.

Хорошая архитектура CRM-ассистента не кормит модель всей базой. Она выбирает нужные данные. Иначе это не ассистент, а дорогой читатель CRM.

Генератор коммерческих текстов и отчётов

Единица расчёта: один готовый результат.

Главный риск: длинный выход.

Вход может быть умеренным: бриф, параметры, примеры, требования к структуре. Но выход часто большой: письмо, отчёт, коммерческое предложение, описание услуги, карточка товара, сценарий, план публикаций.

Если модель генерирует 3–5 вариантов, стоимость растёт ещё быстрее.

В таких сценариях нужно заранее задавать:

• максимальную длину ответа;
• количество вариантов;
• формат результата;
• нужен ли полный текст или сначала структура;
• нужно ли делать несколько итераций.

Генерация текста — это не бесплатно, даже если текст выглядит как «просто слова». В API слова идут через кассу.

Почему два одинаковых чат-бота могут давать разный API-счёт

Два чат-бота могут выглядеть одинаково.

Оба стоят на сайте. У обоих поле ввода. У обоих кнопка «Отправить». Оба отвечают текстом.

Но внутри они могут работать по-разному.

Поэтому вопрос «сколько стоит чат-бот на API» без описания сценариев почти бесполезен.

Правильный вопрос звучит так:

какие данные бот отправляет модели, сколько модель отвечает, сколько раз вызывается API и сколько таких сценариев будет в месяц?

Вот тогда уже можно считать.

Что чаще всего забывают при оценке расходов

Формула расчёта простая. Ошибки начинаются не в математике, а во входных данных.

Самая опасная ошибка — выбирать модель по цене за 1 млн токенов и не считать сценарий.

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

Токены — не вся стоимость AI-функции

API-токены — важная часть расходов. Но не вся стоимость продукта.

Кроме токенов, в смете могут быть: разработка; сервер; база данных; векторная база; хранение документов; интеграции с CRM; поиск по базе знаний; логирование; мониторинг; модерация; тестирование; администрирование; обновление базы знаний; техническая поддержка.

У OpenAI, например, отдельные встроенные инструменты и сервисы могут иметь собственную стоимость: web search, containers, file search storage и tool calls указаны отдельно от базовой стоимости токенов. У Gemini также отдельно указаны цены и условия для инструментов вроде Google Search grounding, Maps, URL context и File Search.

Поэтому API-счёт — это строка эксплуатационных расходов. Иногда крупная. Иногда небольшая. Но точно не единственная.

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

Что делать, если расчёт получился слишком дорогим

Дорогой расчёт не всегда означает, что от AI-функции нужно отказаться.

Часто это значит, что её нужно нормально спроектировать.

Что можно проверить:

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

Batch API у OpenAI даёт 50% скидку для асинхронной обработки, а у Gemini API платный тариф также указывает Batch API как режим с 50% cost reduction.

Но Batch подходит не для всех задач. Если пользователю нужен ответ прямо сейчас, асинхронная обработка может быть неуместна.

Оптимизация расходов — отдельная тема. Здесь важно другое: сначала нужно увидеть, где именно возникает стоимость. Без расчёта оптимизация превращается в гадание.

API-бюджет считают до запуска, а уточняют после первых логов

Стоимость токенов — это не абстрактная техническая деталь. Это часть себестоимости AI-функции.

Если вы строите AI-бота, CRM-ассистента, RAG-поиск, генератор отчётов или инструмент суммаризации, считать нужно не сообщения, а сценарии.

В расчёте важно учитывать:

• входные токены;
• кэшированные токены;
• выходные токены;
• дополнительные вызовы модели;
• разные сценарии нагрузки;
• месячное количество обращений;
• пиковые периоды;

изменения промптов и логики после запуска.

До запуска бюджет считают по гипотезам. После запуска — по логам.

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

Хороший API-бюджет — это не таблица, которую сделали один раз и забыли. Это рабочий инструмент проектирования.

Сначала считаем. Потом запускаем. Потом смотрим логи. Потом уточняем.

Скучно? Да.

Зато дешевле, чем внезапно узнать, что ваш «маленький AI-бот» питается как взрослый дата-центр.