Истории про счёт в сотни долларов за ночь почти всегда об одном и том же: не человек много спрашивал, а программа много спрашивала. Агент попал в цикл, ретраи ушли по кругу, скрипт обработки списка отработал дважды. Человек в это время спал.
Отсюда принцип, вокруг которого построена статья: защищаться нужно не от своей активности, а от автоматической. Ваша скорость набора текста ограничена физиологией; скорость программы — нет.
Ниже — семь предохранителей. Они независимы: каждый закрывает свой класс аварий, и ни один не заменяет остальные.
#Что понадобится
- Доступ к кабинету провайдера с правом менять лимиты.
- Понимание, из чего складывается ваш обычный расход. Если этой картины нет, начните с материала про расчёт стоимости запросов к модели: защищать бюджет, не зная его нормы, невозможно.
#Предохранитель 1. Жёсткий потолок в кабинете провайдера
Первое, что нужно сделать сразу после выпуска ключа. У большинства провайдеров есть два разных параметра, и их путают:
- порог уведомления — вам напишут, но запросы продолжатся;
- жёсткий потолок — по достижении суммы запросы отклоняются.
Нужны оба. Уведомление без потолка защищает от неведения, но не от расхода. Ставьте потолок примерно вдвое выше вашей нормы: слишком низкий вы будете снимать вручную и однажды забудете вернуть.
#Предохранитель 2. Предоплатный баланс вместо постоплаты
Постоплата удобна и опасна: верхней границы у неё нет по определению. Предоплаченный баланс — это физический предел ущерба. Если провайдер даёт выбор, выбирайте предоплату и пополняйте на месяц, а не на год.
#Предохранитель 3. Отдельный ключ на каждое приложение
Один ключ на всё делает диагностику невозможной: вы видите рост расхода и не знаете, кто его создаёт. Отдельные ключи дают две вещи — понимание источника и возможность отключить одного потребителя, не ломая остальных. Если провайдер позволяет привязать к ключу собственный лимит трат, используйте это.
#Предохранитель 4. Ограничение длины ответа
Параметр максимальной длины генерации есть у всех провайдеров. Он ограничивает самую дорогую часть счёта — выходные токены. Значение выбирайте по реальной длине нужных вам ответов, а не «с запасом»: запас здесь оплачивается.
Отдельно про модели с рассуждением: их внутренние размышления тарифицируются как выход и могут превышать сам ответ. Включать такую модель по умолчанию для бытового чата — самый простой способ увеличить счёт без всякой пользы.
#Предохранитель 5. Ограничение подмешиваемого контекста
У ассистента с памятью основную часть входных токенов создаёт не вопрос, а найденные фрагменты памяти и история диалога. Два ограничения дают немедленный эффект:
- максимальное число фрагментов памяти, подмешиваемых к запросу;
- максимальное число последних сообщений диалога, отправляемых заново.
Проверка простая: задайте короткий вопрос и посмотрите в кабинете провайдера, сколько входных токенов ушло. Если на «привет» уходит десять тысяч, экономить нужно здесь, а не на модели.
#Предохранитель 6. Потолок шагов у агента
Самый частый источник катастрофического счёта. Агент, который сам решает, сколько раз обратиться к модели, в норме делает несколько вызовов, а в патологии — не останавливается. Механика зацикливания и способы его распознать разобраны в статье про то, что делать, если агент зациклился.
Три ограничения, которые обязаны стоять до запуска, а не после первого инцидента:
- максимальное число шагов на задачу — жёсткое число, а не «пока не решит»;
- общий таймаут задачи — время, после которого работа прерывается независимо от состояния;
- бюджет токенов на задачу — счётчик, который останавливает выполнение по достижении лимита.
Для многоагентных схем всё перечисленное умножается на число участников: разбор рисков — в обзоре многоагентных систем.
#Предохранитель 7. Разумные повторные попытки
Повтор после ошибки — стандартное поведение клиента, и именно оно превращает временный сбой в лавину. Три правила:
- растущая задержка между попытками вместо мгновенного повтора;
- ограниченное число попыток, после которого клиент сдаётся и сообщает об этом;
- никаких повторов при ошибке авторизации или неверного запроса — они детерминированы, повтор их не исправит.
Как отличить ошибку, которую имеет смысл повторить, от той, которую бессмысленно, разобрано в материале про ошибку 429 и лимиты запросов.
#Проверка результата
Предохранители считаются установленными, только когда проверены.
- Проверьте потолок расходов: в кабинете провайдера должно стоять конкретное число, а не пустое поле.
- Проверьте расход на один короткий вопрос в разделе использования. Это ваша базовая единица; всё остальное меряется относительно неё.
- Проверьте поведение агента на заведомо неразрешимой задаче. Дайте ему цель, которую он не может достичь, и убедитесь, что он останавливается по лимиту шагов, а не работает бесконечно. Это единственный способ узнать, что ограничение действительно включено.
- Посмотрите на дневной график расхода через неделю. Ровный график — норма. Всплеск, которому вы не можете назвать причину, — повод разбираться до того, как он повторится.
В Persona расход токенов и его денежная оценка сводятся на отдельной странице статистики — с оговоркой: она доступна владельцу инстанса, участнику эту страницу не показывают. Участник контролирует свой расход в кабинете своего провайдера, поскольку запросы идут его собственным ключом напрямую.
#Типовые сценарии перерасхода
| Сценарий | Как выглядит | Что останавливает |
|---|---|---|
| Зацикленный агент | ровный поток запросов часами | потолок шагов и таймаут |
| Лавина повторов | всплеск сразу после сбоя провайдера | растущая задержка, лимит попыток |
| Разросшийся контекст | плавный рост изо дня в день | лимит фрагментов памяти |
| Не та модель по умолчанию | счёт вырос скачком без роста активности | явный выбор модели под задачу |
| Пакетная обработка дважды | двойной расход за короткий период | защита от повторного запуска |
Первые два сценария опасны внезапностью, третий — незаметностью. Третий встречается чаще остальных вместе взятых: ассистент накапливает память, выборка растёт, счёт растёт вместе с ней, и заметно это становится через месяцы.
#Частые вопросы
#Можно ли поставить жёсткий лимит трат у любого провайдера?
Не у любого. У части сервисов есть только уведомление о достижении порога, а отклонять запросы они начинают лишь при исчерпании предоплаченного баланса. В таком случае предоплата и есть ваш жёсткий лимит — не переводите на баланс больше, чем готовы потерять за месяц.
#Почему счёт вырос, хотя я пользуюсь ассистентом так же, как раньше?
Скорее всего, вырос объём подмешиваемого контекста: памяти стало больше, поиск находит больше фрагментов, история диалога длиннее. Проверяется сравнением количества входных токенов на один запрос сейчас и месяц назад.
#Стоит ли переходить на бесплатный уровень ради экономии?
Как способ ограничить расход это работает: квота кончается, и списаний не происходит. Как способ работать — далеко не всегда: у бесплатных уровней свои ограничения, и ассистент замолкает в неудобный момент. Сравнение по критерию «хватит ли на день» — в разборе бесплатных API языковых моделей.
#Помогает ли кэширование входа?
У провайдеров, где оно есть, повторяющаяся начальная часть запроса тарифицируется дешевле. Для ассистента с постоянной системной инструкцией эффект заметен. Механизм есть не у всех и включается по-разному — читайте документацию конкретного провайдера.
#Что делать, если счёт уже пришёл?
Сначала остановить источник: отозвать ключ приложения, которое тратит. Потом найти причину по графику расхода и по логам — момент начала всплеска обычно указывает на неё однозначно. И только потом обсуждать с провайдером: часть сервисов идёт навстречу при явной технической аварии, но рассчитывать на это как на стратегию нельзя.
#Какой предохранитель поставить первым, если времени мало?
Жёсткий потолок в кабинете провайдера и лимит шагов у агента. Первый ограничивает ущерб, второй — устраняет самую вероятную причину. Всё остальное можно донастроить позже; общий контекст по провайдерам и их лимитам — в обзоре того, где взять ключ к языковой модели.