Серверные инструменты — отдельный счет
Обновлено September 1, 2026 · впервые опубликовано September 1, 2026
Большинство моделей затрат на LLM опираются на один счетчик: входящие токены, исходящие токены, цена за миллион. Эта модель была верна, пока запрос только генерировал текст. Она перестала быть верной с появлением инструментов на стороне сервера.
Веб-поиск, веб-фетч и выполнение кода работают на инфраструктуре провайдера, и несколько из них, помимо токенов, которые производят, несут собственную плату за использование. Поэтому один ход агента может выставить счет дважды: за выполненные поиски и за токены, которые их результаты добавили в контекст.
Эффект накопления
Вторая плата — та, которую обычно упускают. Каждый результат инструмента добавляется в разговор, и каждый следующий ход отправляет весь разговор заново как входные данные. Десять поисков в начале долгого запуска агента — это не десять списаний, а десять списаний плюс результаты этих поисков, которые перечитываются на каждом следующем ходу.
Поэтому затраты агента выглядят нелинейными, хотя арифметика токенов говорит, что они должны быть линейными. Плата за использование — видимая часть. Рост контекста, который она вызывает, — большая часть, и попадает он в строку входных токенов без метки, что это работа инструментов.
Без атрибуции нет управления
Логируйте вызовы инструментов для каждого запроса рядом с объектом usage: какой инструмент, сколько раз он вызывался и сколько токенов добавил каждый результат. Именно последнее поле делает накопление видимым, и по умолчанию его никто не записывает.
Затем считайте стоимость за запуск агента, а не за вызов API. Запуск — то, что пользователь реально инициировал; вызов API — одна из двадцати вещей, которые сделал запуск. Любой бюджет или показатель экономики единицы, привязанный к вызову, а не к запуску, будет ошибаться в сторону, которая выглядит выгоднее реальности.
Три контроля, которые действительно работают
Ограничьте число вызовов инструментов за запуск. Жесткий лимит на поиски или загрузки на запрос пользователя ограничивает обе платы сразу. Большинство нагрузок, упиравшихся в лимит в десять, зацикливались, а не исследовали.
Сокращайте то, что попадает в контекст. Вся загруженная страница нужна редко. Суммаризация или обрезка результата до добавления снижает стоимость каждого последующего хода, а не только текущего.
Кешируйте стабильный префикс. Если системный промпт и определения инструментов не меняются в течение запуска, а обычно так и есть, кеширование промптов убирает самую крупную повторяющуюся статью расходов, которую создали инструменты.
Перед моделированием сверьте актуальный прайс-лист провайдера: какие инструменты берут плату за использование и по какой ставке — это различается от инструмента к инструменту и меняется со временем. Структурный вывод от этого не меняется: счетчик токенов больше не является всем счетом.
Связанное
По теме
Хотите применить это к своему стеку? Принесите счета провайдеров, логи шлюза и ключевые рабочие процессы — мы определим драйверы затрат и пути экономии. Заказать бесплатный аудит →