Стоимость tool calling определяется не числом кнопок или функций в интерфейсе агента. Провайдер считает токены, которые проходят через API на каждом раунде: описание инструментов, историю сообщений, аргументы вызова, результат функции и финальный ответ модели.
Из-за этого короткая задача с одним вызовом может оказаться заметно дороже обычного ответа. Особенно быстро расход растёт, если агент передаёт длинные JSON-схемы, возвращает большие результаты и повторяет весь контекст в нескольких последовательных запросах.
Ниже — практическая схема расчёта для трёх популярных моделей. Цены в таблице приведены как ориентир по официальным страницам провайдеров. Перед запуском проекта их следует перепроверить: тарифы, лимиты контекста, скидки за кэширование и условия batch-обработки могут меняться.
Из чего складывается счёт
У одного цикла агента обычно есть несколько платных частей:
- системная инструкция и история диалога;
- описание доступных функций и их параметров;
- пользовательский запрос;
- ответ модели с именем инструмента и аргументами;
- результат работы внешнего API;
- финальный ответ пользователю.
Описание функции передаётся в виде схемы или специального блока tools. В него входят название, назначение, обязательные поля, типы данных и ограничения. Даже простая схема может занимать десятки или сотни токенов. Если в агенте десять инструментов, модель часто получает описания всех десяти, хотя для текущей задачи нужен один.
Ответ с вызовом функции относится к output-токенам. Результат функции попадает в следующий запрос и становится частью input. При последовательной работе агент отправляет в модель накопленную историю, поэтому каждый новый раунд может быть дороже предыдущего.
Упрощённая формула выглядит так:
Стоимость = input-токены × цена input + output-токены × цена output.
В расчёте нужно использовать единицу тарифа провайдера. Если цена указана за миллион токенов, объём токенов делится на 1 000 000.
Ориентиры по тарифам
Для сопоставления возьмём опубликованные базовые ставки без учёта специальных скидок, кэширования и повышенных тарифов за большой контекст.
| Модель | Input, $ за 1 млн токенов | Output, $ за 1 млн токенов | Что важно проверить |
|---|---|---|---|
| OpenAI GPT-4o | 5,00 | 15,00 | актуальный тариф API и доступность prompt caching |
| Anthropic Claude 3.5 Sonnet | 3,00 | 15,00 | версия модели, кэширование и условия tool use |
| Google Gemini 2.0 Flash | 0,10 | 0,40 | размер контекста и тариф для конкретного региона |
| Google Gemini 2.0 Pro | 1,25 | 5,00 | актуальность модели и лимиты выбранного API |
Это не универсальный прайс-лист на все варианты доступа. Провайдеры разделяют API, пакетную обработку, модели с большим контекстом и отдельные функции кэширования. В коммерческом проекте ставку нужно брать из конкретного раздела биллинга, которым пользуется приложение.
У tool calling нет отдельной обязательной комиссии за сам факт вызова функции. Деньги списываются за токены запроса и ответа, а также за сопутствующие операции платформы, если они предусмотрены договором или инфраструктурой.
Расчёт одного вызова
Рассмотрим агента службы поддержки интернет-магазина. Он получает запрос клиента, вызывает функцию get_order_status, передаёт номер заказа и возвращает статус доставки. Данные заказа небольшие, поэтому для одного раунда допустима такая оценка:
- инструкции и схема функции — 220 input-токенов;
- сообщение клиента — 25 input-токенов;
- ответ с названием функции и аргументом — 35 output-токенов;
- результат API — 90 input-токенов;
- финальный ответ — 55 output-токенов.
Итого: 335 input-токенов и 90 output-токенов.
При указанных выше ставках получится:
- GPT-4o: 335 × 5 / 1 000 000 + 90 × 15 / 1 000 000 = 0,002 без округления, примерно 0,3 цента;
- Claude 3.5 Sonnet: 335 × 3 / 1 000 000 + 90 × 15 / 1 000 000 = 0,002355 доллара;
- Gemini 2.0 Flash: 335 × 0,10 / 1 000 000 + 90 × 0,40 / 1 000 000 = 0,0000695 доллара.
Это стоимость модельной части одного простого сценария. В ней нет платы за сервер, базу данных, внешнюю систему заказов, логи, прокси, оркестратор и повторные запросы после ошибки.
Почему несколько раундов меняют результат
Главная ошибка в оценке бюджета — умножить цену одного вызова на число функций. Агент обычно делает несколько запросов к модели, а история и схемы передаются повторно.
Предположим, что агент подбирает товар и оформляет заявку. В сценарии есть три последовательных раунда:
Модель вызывает search_products. Запрос содержит 500 input-токенов, ответ — 40 output-токенов.
2. После результата поиска модель вызывает check_stock. Новый запрос с историей занимает 750 input-токенов, ответ — 35 output-токенов.
3. Модель вызывает create_order и формирует короткое подтверждение. Запрос занимает 950 input-токенов, ответ — 45 output-токенов.
Суммарно агент отправляет 2200 input-токенов и получает 120 output-токенов. При базовых ставках расчёт выглядит так:
- GPT-4o: 2200 × 5 / 1 000 000 + 120 × 15 / 1 000 000 = 0,0128 доллара;
- Claude 3.5 Sonnet: 2200 × 3 / 1 000 000 + 120 × 15 / 1 000 000 = 0,0084 доллара;
- Gemini 2.0 Flash: 2200 × 0,10 / 1 000 000 + 120 × 0,40 / 1 000 000 = 0,000268 доллара.
При 10 000 подобных сценариев в месяц модельная часть составит примерно 128 долларов для GPT-4o, 84 доллара для Claude 3.5 Sonnet и 2,68 доллара для Gemini 2.0 Flash. Это сравнение полезно для предварительного бюджета, однако оно не говорит, что более дешёвая модель будет равна по качеству более дорогой.
Что сильнее всего увеличивает расходы
Первый фактор — полные схемы инструментов в каждом запросе. В проекте с большим каталогом функций полезно разделять их по маршрутам. Агенту для проверки заказа не нужно передавать инструменты создания возврата, настройки профиля и работы с каталогом.
Второй фактор — объём результата функции. Вместо полного списка из сотен записей лучше вернуть идентификаторы, ключевые поля и краткие ограничения. Подробности можно загрузить отдельным вызовом после того, как модель выберет нужный объект.
Третий фактор — длинная история. Старые сообщения, отладочные данные и необработанные ответы API увеличивают input на каждом раунде. Историю стоит сокращать, суммировать или хранить вне контекста с выборочной загрузкой нужных фрагментов.
Четвёртый фактор — повторные попытки. Невалидный JSON, ошибка авторизации внешнего сервиса или отсутствие обязательного аргумента запускают новый запрос к модели. В метриках такие попытки нужно считать отдельно: средняя цена успешного сценария скрывает расходы на ошибки.
Пятый фактор — большой output. У моделей с дорогим output-тарифом длинное объяснение после вызова может стоить больше, чем сами аргументы функции. Для внутренних шагов задавайте короткий формат ответа и ограничивайте максимальное число токенов там, где это безопасно.
Как снизить стоимость без потери качества
Сначала измерьте токены по каждому раунду, а затем оптимизируйте самые дорогие места.
Составьте 20–50 типовых пользовательских сценариев.
Для каждого сценария запишите названия вызванных функций, объём input и output, количество повторов и итоговый статус.
3. Разделите input на системные инструкции, схемы инструментов, историю и результаты внешних API.
4. Сократите схемы: уберите дублирующие описания, лишние примеры и поля, которые можно вычислить в коде.
5. Ограничьте объём ответа инструментов до данных, необходимых для следующего решения.
6. Сравните последовательные и параллельные вызовы на одинаковом наборе тестов.
7. Проверьте, доступно ли кэширование префикса и действительно ли оно применяется к вашим запросам.
8. Добавьте бюджетные пороги в мониторинг: стоимость на сессию, стоимость успешного действия и стоимость ошибки.
Параллельные вызовы могут уменьшить число раундов, но не всегда уменьшают общий счёт. Если три функции запускаются одновременно, output с несколькими наборами аргументов приходит в одном ответе. Выигрыш появляется тогда, когда сокращается повторная передача контекста или задержка, а суммарное число токенов остаётся под контролем.
Для надёжности полезно разделить модели по ролям. Недорогая модель может классифицировать запрос и выбирать маршрут, а более сильная — выполнять сложное планирование или формировать ответ в ситуациях, где ошибка обходится дорого. Такое разделение нужно проверять на реальных тестах: дополнительный вызов маршрутизатора тоже входит в бюджет.
Что проверить перед запуском
Перед публикацией агента проверьте четыре показателя:
- среднее и 95-й перцентиль input-токенов на сессию;
- среднее и 95-й перцентиль output-токенов;
- число вызовов модели и функций на одну задачу;
- долю повторных запросов после ошибок.
Затем умножьте средние значения на прогноз числа сессий. Для осторожного бюджета используйте отдельный сценарий с повышенной нагрузкой: длинным пользовательским сообщением, большим результатом API и одной неудачной попыткой.
Цены следует сверить с официальными страницами OpenAI, Anthropic и Google непосредственно перед расчётом. Документация по function calling и tool use объясняет формат запросов, а не гарантирует одинаковую схему биллинга для всех моделей. Отдельно проверьте, как выбранный SDK передаёт историю, схемы и результаты инструментов.
Практический следующий шаг — добавить в CI набор сценариев с фиксированными ожиданиями по токенам. Если новая версия схемы функции увеличила input на 40%, это должно стать заметно до релиза. Для рабочего мониторинга подойдут данные Usage API и логи оркестратора; при этом в логи нельзя записывать секреты, персональные данные и полные ответы внешних систем без необходимости.
Источники
- OpenAI, документация по function calling: https://platform.openai.com/docs/guides/function-calling
- OpenAI, тарифы API: https://openai.com/api/pricing/
- Anthropic, документация по tool use: https://docs.anthropic.com/en/docs/build-with-claude/tool-use
- Anthropic, тарифы API: https://www.anthropic.com/pricing
- Google, документация по function calling: https://ai.google.dev/gemini-api/docs/function-calling
- Google, тарифы Gemini API: https://ai.google.dev/pricing
