Единица учёта выбрана неверно
Большинство дашбордов затрат для LLM-систем строятся вокруг одного вопроса: сколько стоил этот вызов? На этот вопрос можно ответить, он точен и почти бесполезен для агентов. Запуск агента — это не вызов. Это траектория: план, последовательность вызовов инструментов, один или несколько проходов рефлексии, повторные попытки после некорректных аргументов и финальный синтез. Вызов — это атом; траектория — это молекула. Оценивать атом, а бюджетировать молекулу — так команды и получают месячный счёт, который никто не может объяснить по логам.
Это эссе выступает за контроль затрат на уровне траектории: ограничения на токены, астрономическое время и вызовы инструментов на уровне запуска, применяемые вне модели, с многоуровневой деградацией и эскалацией, определёнными до начала запуска. Механизм не блестящий. Но именно он отличает агентную систему, которой можно управлять, от той, которую можно только демонстрировать.
Почему ценообразование по вызовам вводит в заблуждение
Один вызов имеет ограниченную стоимость. Траектория — нет, потому что количество вызовов зависит от задачи, решений самой модели и ответов среды. Доминируют три фактора, и ни один из них не отображается в учёте по вызовам.
Повторные попытки. Вызов инструмента, который не проходит валидацию схемы, истекает по таймауту или возвращает неоднозначную ошибку, повторяется. Каждая повторная попытка заново отправляет контекст. Контекст, который монотонно растёт по траектории, означает, что n-я повторная попытка стоит дороже первой, а не столько же. Стоимость попытки растёт, даже если число попыток стабильно.
Веер вызовов инструментов. Шаг планирования может решить запросить один источник или двенадцать. Модель не знает вашей юнит-экономики, поэтому у неё нет причин предпочитать одно. Веер — это место, где хорошо ведущий себя медианный случай и патологический хвостовой случай расходятся на порядок, и расхождение структурное, а не случайное.
Проходы рефлексии. Циклы самокритики, верификации и перепланирования — это механизм качества с наибольшим рычагом в большинстве агентных архитектур и механизм затрат с наибольшей дисперсией. Проход рефлексии, который ничего не находит для исправления, всё равно стоит полного прохода по контексту. Проход рефлексии, который что-то находит, стоит этого плюс исправление плюс повторная верификация.
Следствие — распределение затрат с тяжёлым хвостом. Медианный запуск дёшев, а средний — нет. Команды, которые бюджетируют от медианы, систематически удивляются; команды, которые бюджетируют от среднего, закладывают слишком много и всё равно удивляются хвосту. Хвост — это не шум. Это конкретный класс задач, которые агент обрабатывает циклами, и он будет повторяться.
Есть и внешнее измерение: по мере распространения агентных фреймворков и паттернов оркестрации поверхность затрат развёрнутой системы меняется быстрее, чем любая статическая оценка по вызовам может отследить. Полезная дисциплина — рассматривать траекторию, а не вызов, как то, что оценивается, мониторится и ограничивается.
Примитивы бюджета
Бюджет запуска — это набор ограничений, привязанных к идентификатору траектории и применяемых оркестратором, а не моделью. Применение вне модели важно: модель, которую просят уложиться в бюджет, даёт мягкое обещание, а мягкие обещания — именно то, что отказывает в хвосте. Оркестратор умеет считать, а бюджеты требуют именно счёта.
Ограничения
Три ограничения покрывают большинство режимов отказа:
- Ограничение по токенам. Суммарные входные и выходные токены по всей траектории, а не по вызову. Считается на границе оркестратора, так что повторные попытки и проходы рефлексии включаются по построению.
- Ограничение по астрономическому времени. Дедлайн для траектории. Это ловит циклы, которые дёшевы на шаг, но неограниченны по числу шагов, и это единственное ограничение, которое выдерживает инцидент с задержкой на стороне провайдера.
- Ограничение по вызовам инструментов. Потолок на число внешних вызовов, опционально по каждому инструменту. Это прямой контроль веера и самое простое для рассуждений.
Практическая реализация ведёт журнал на запуск, в который каждый шаг пишет до того, как шаг отправлен:
class RunLedger:
def __init__(self, limits):
self.limits = limits
self.tokens = 0
self.tools = 0
self.started = now()
def admit(self, est_tokens, tool_name=None):
if self.tokens + est_tokens > self.limits.tokens:
raise BudgetExceeded("tokens")
if tool_name and self.tools + 1 > self.limits.tools:
raise BudgetExceeded("tools")
if now() - self.started > self.limits.wall_clock:
raise BudgetExceeded("wall_clock")
self.tokens += est_tokens
if tool_name:
self.tools += 1
Оценка, передаваемая в admit, намеренно консервативна: это прогнозируемая стоимость шага плюс резерв на одну повторную попытку. Резерв — это то, что делает ограничение значимым, а
Жёсткая остановка на ограничении корректна, но груба. Лучший дизайн определяет лестницу деградированных режимов, по которой оркестратор спускается по мере приближения запуска к своим пределам:
- Сократить набор инструментов. Убрать опциональные или высоколатентные инструменты, оставить те, без которых задача не может быть выполнена.
- Убрать проходы рефлексии. Пропустить самокритику и верификацию, принять более низкое качество ответа и зафиксировать, что запуск был деградирован.
- Отказать закрыто. Вернуть структурированный отказ с приложенной частичной траекторией, а не неограниченную попытку добиться успеха.
Лестница определяется заранее, потому что момент исчерпания — худшее возможное время для проектирования запасного варианта. Деградированный запуск, который возвращает пригодный частичный ответ и чёткий флаг, операционно гораздо лучше, чем запуск, который либо молча превышает бюджет, либо завершается ничем.
Атрибуция
Бюджеты диагностичны только если расход атрибутирован. Помечайте каждый запуск классом задачи, идентификатором тенанта или пользователя, где это уместно, и точкой входа, которая его породила. Затем агрегируйте расход по тегу, а не по модели. Полезный вид — распределение по классу задачи: медиана, хвост и отношение между ними. Класс задачи, чей хвост на порядок выше медианы, имеет патологию циклов, и тег говорит вам, где искать.
Операционные последствия
Аномалии затрат — это патологии циклов. Когда класс задачи внезапно дорожает, инстинкт — винить неэффективность промпта. Обычно промпт не менялся, а цикл изменился: инструмент начал возвращать ошибки, вызывающие повторные попытки, планировщик начал шире разворачивать веер, проход рефлексии перестал сходиться. Исследование аномалии должно начинаться с формы траектории, а не с текста промпта. Распределение числа шагов и вызовов инструментов на запуск выявит патологию быстрее, чем любой дифф промпта.
Бюджеты делают оценку сравнимой. Без ограничения затрат на уровне запуска сравнение бенчмарков между двумя агентными дизайнами не является сравнением. Более дорогой дизайн может выиграть по доле успеха просто потому, что пробует дольше. С фиксированными одинаковыми ограничениями более дешёвая траектория при равном успехе — это реальный результат, а более дорогая траектория при равном успехе — это регрессия. Это честный компромисс всего подхода: жёсткие бюджеты иногда отсекут запуск, который бы succeeded, если бы ему дали больше места. Эта цена платится осознанно, в обмен на систему, чьё поведение в худшем случае известно до развёртывания, а не обнаруживается в счёте. Команды, которые не могут принять никакого усечения, должны установить ограничения высоко и использовать деградацию вместо отказа, но они всё равно должны их установить.
Дедлайны — часть контракта. Ограничение по астрономическому времени — это не только контроль затрат; это гарантия задержки для всего, что ждёт агента. Запуски, которые его превышают, должны отказать закрыто с частичным результатом, потому что вызывающий, который уже сдался, не получает выгоды от позднего успеха.
Что строить в первую очередь
Минимально жизнеспособная версия мала. Поставьте журнал на оркестратор, считайте токены, вызовы инструментов и прошедшее время на траекторию, применяйте три ограничения и помечайте каждый запуск классом задачи. Добавьте один деградированный режим, прежде чем добавлять второй. Инструментируйте распределение, а не среднее. Вид по вызовам может остаться как вспомогательное средство для отладки, но он не должен быть тем, к чему привязан бюджет. Привяжите бюджет к запуску, и запуск станет чем-то, чем можно управлять.