Стоимость вызова инструментов: из чего складывается цена

Почему один вызов стоит дороже, чем кажется

Команды часто смотрят только на цену токенов. Из-за этого один вызов выглядит дешевым, хотя бизнес платит не за ответ модели, а за весь шаг целиком.

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

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

Полная цена одного шага обычно состоит из пяти частей:

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

Простой пример: оператор запрашивает статус заявки. На токены уходит совсем мало. Но если модель вернула JSON без обязательного поля, система отклоняет вызов, делает повторный запрос и снова ждет. Один такой сбой кажется мелочью. Если он происходит в 3-5% обращений каждый день, это уже постоянная утечка бюджета.

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

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

Как выбор модели меняет итоговую стоимость

Тариф на токены - только начало. Одна модель выглядит дешево в прайсе, но чаще ошибается в формате, тянет лишние токены и просит повторный вызов. Другая стоит дороже за 1 млн токенов, но закрывает задачу с первой попытки и в итоге обходится дешевле на одно завершенное действие.

Возьмем простой сценарий: ассистент должен вызвать функцию create_ticket и передать 5 обязательных полей. В запрос уходит не только фраза пользователя. Там есть системные инструкции, описание инструмента, схема полей, типы, enum и правила проверки. Даже короткий диалог легко превращается в 1200-1500 входных токенов. Если модель еще и многословно заполняет аргументы, к счету добавляется служебный JSON, который никто не читает, но за него все равно нужно платить.

На одинаковом сценарии дешевая модель может стоить в 3 раза меньше по токенам, но держать формат хуже. Допустим, на 1000 запросов она в 8% случаев ломает JSON или забывает обязательное поле. Еще в 4% случаев она вызывает инструмент зря, хотя хватило бы обычного ответа. Это уже 80 повторов LLM-вызова и 40 лишних обращений к внутренним системам.

Теперь сравним с более дорогой моделью. Пусть она стоит заметно выше за токен, но ошибается в формате только в 1,5% случаев, а ложные вызовы дает в 1% случаев. Разница быстро накапливается. Вы платите не только за текст модели, но и за каждую лишнюю проверку, задержку очереди и работу сервиса, который принял ненужный запрос.

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

На тесте смотрите не на цену токена саму по себе, а на четыре показателя:

• долю успешных вызовов с первой попытки;
• среднее число токенов на одно успешно завершенное действие;
• долю ложных вызовов;
• долю пропущенных вызовов.

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

Где схема ломает процесс

Даже недорогой вызов быстро дорожает, если модель не попала в схему с первого раза. На бумаге вы платите за один tool call. На деле платите за генерацию аргументов, проверку JSON, повторный запрос и время, пока процесс стоит.

Чаще всего все ломается на мелочах. Модель пишет phoneNumber вместо phone, кладет строку туда, где ждут число, или забывает обязательное поле. Ошибка выглядит пустяковой, но цепочка уже сломана. Система не может вызвать инструмент, приложение просит модель исправить ответ, а пользователь ждет еще один круг.

Самые частые сбои выглядят так:

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

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

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

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

Почему повторы быстро съедают бюджет

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

Повторы бывают трех типов. Первый - retry модели. Он случается, когда модель вернула битый JSON, выбрала не тот инструмент или не уложилась в формат. Тогда оркестратор просит ее повторить ответ, и вы платите еще раз.

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

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

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

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

Рабочее правило простое:

• задайте отдельный лимит попыток для модели, инструмента и всего пользовательского запроса;
• разрешайте повтор инструмента только для сетевых ошибок, а не для любого сбоя подряд;
• записывайте idempotency key для каждой бизнес-операции;
• храните статус каждого шага: started, succeeded, failed, timed_out, duplicate_skipped.

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

Как задержка превращается в деньги

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

Как считать цену ожидания

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

Дальше включается объем. При 20 000 заявок в месяц те же 8,3 тенге превращаются в 166 000 тенге. И это еще без повторных вызовов, ошибок схемы JSON и ручной проверки после сбоя.

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

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

Когда ждать синхронно, а когда уводить в фон

Синхронный ответ подходит там, где человек действительно смотрит на экран и ждет: чат, поиск, подсказка оператору, проверка формы. Здесь задержку нужно держать жестко. Если шаг не укладывается в лимит, лучше показать промежуточный статус и отправить тяжелую часть в фон.

Фоновая обработка лучше для длинных цепочек: сверка документов, обогащение CRM, сбор данных из нескольких систем, генерация отчета. Пользователь получает подтверждение сразу, а результат приходит позже. Во многих случаях это дешевле, чем держать человека в ожидании 30-40 секунд.

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

Как посчитать полную стоимость заранее

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

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

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

Формула обычно простая: сумма стоимости всех шагов, умноженная на среднее число попыток, плюс цена ожидания и цена ошибок, которые ушли в ручную обработку. Если шаг срабатывает не всегда, берите его вероятность. Например, CRM-проверка нужна в 70% случаев, значит в модели расчета для нее стоит коэффициент 0,7, а не 1.

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

Отдельно считайте задержку. Если оператор ждет ответ 12 секунд вместо 4, это не просто техническая метрика. На потоке в 1000 заявок команда теряет часы рабочего времени, а клиент чаще бросает процесс. Для банка, ритейла или SaaS это уже заметный расход.

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

Пример на одной заявке

Запрос на смену тарифа хорошо показывает, почему цена операции редко равна цене одного ответа модели. Клиент пишет в чате или в личном кабинете: "Переведите меня с базового тарифа на бизнес с первого числа". Снаружи это выглядит как одна простая команда, но внутри система проходит несколько шагов.

Сначала модель должна понять запрос, собрать поля для CRM и проверить, хватает ли данных. Нужны номер клиента, текущий тариф, новый тариф и дата смены. Если часть данных уже есть в профиле, модель формирует JSON и вызывает CRM. Если чего-то не хватает, она задает уточняющий вопрос. Это уже еще один ответ, еще токены и еще время.

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

Проблема часто начинается на схеме. CRM ждет, например, plan_code и дату в формате YYYY-MM-DD, а модель отдает "Бизнес" и "с первого числа следующего месяца". Валидатор отклоняет запрос. Система запускает повтор, просит модель исправить JSON, снова тратит токены и снова ждет. Если и второй ответ не проходит, заявку отправляют на ручную проверку.

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

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

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

Ошибки в расчете, которые встречаются чаще всего

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

Первая проблема проста: в расчет попадает только успешный ответ. Но деньги съедают и неудачные попытки. Таймаут, обрыв соединения, ответ модели в неверном формате, повторный запрос после 429 или 500 - все это тоже стоит денег и времени.

Если у вас есть повторные вызовы API, их нельзя прятать в строку "редкие сбои". Даже 3-5% повторов быстро меняют итог, если инструмент вызывается почти на каждом шаге процесса.

Вторая частая ошибка связана со схемой. Команда считает только удачные function calls и забывает, что ошибки JSON тоже оплачиваются. Модель сначала пробует заполнить поля, потом получает отказ валидатора, потом делает еще одну попытку. Иногда к этому добавляется уточняющий промпт, и один логический шаг превращается в три или четыре запроса.

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

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

Считать лучше не "цену одного идеального вызова", а цену одной завершенной задачи. Для этого обычно хватает четырех строк:

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

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

Проверка перед запуском

Перед релизом стоит пройти короткий список. Он занимает 10 минут, но часто экономит недели на разбор дублей, пустых ответов и скачков по счету.

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

Проверьте пять вещей:

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

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

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

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

Что делать дальше

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

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

Потом прогоните 20 живых сценариев с логами и таймингами. Лучше брать не тестовые примеры, а то, что уже похоже на реальную работу: заявка, проверка документа, поиск данных в CRM, статус заказа. Смотрите не только на успех. Фиксируйте, где ломается JSON, сколько раз система делает повторный вызов API и в каком месте процесс начинает тормозить.

Выбор модели тоже стоит пересмотреть на реальных данных. Дешевая модель на бумаге легко проигрывает, если она чаще ошибается в вызове функций. Если более дорогая модель с первой попытки отдает правильный tool call и корректный JSON, итоговый счет часто ниже. Это особенно заметно в процессах, где лишние 15-30 секунд тормозят заявку или ответ клиенту.

Если команде нужно сравнивать несколько моделей без переписывания интеграций, такой слой лучше продумать заранее. Для компаний в Казахстане и Центральной Азии здесь часто важны не только цена, но и хранение данных, аудит и единый способ подключения. Например, AI Router дает один OpenAI-совместимый эндпоинт, а команде достаточно поменять base_url на api.airouter.kz; при этом аудит-логи и хранение данных внутри Казахстана помогают точнее считать повторы, задержки и полную цену операции.

Хороший следующий шаг очень простой: считать не стоимость запроса, а стоимость успешно завершенной задачи. Именно она потом и попадает в бюджет.