Коротко
Автор предлагает ставить финансовые ограничения перед каждым вызовом модели, чтобы ошибки в циклах агентов и повторы запросов не создавали неконтролируемые счета. Он описывает четыре меры: оценку стоимости, быстрый учёт расходов, middleware-проверки бюджета и аварийный выключатель.
Контекст
Автор — разработчик, который, по его словам, не раз создавал такой защитный слой для LLM-проектов. Он начинает с примера исследовательского агента, зациклившегося на неразбираемой ссылке: без лимита итераций и контроля повторов ошибка может незаметно наращивать расходы. Автор также предлагает собственный FastAPI-шаблон ShipSafe.
Главное
- Пример расчёта для модели класса GPT-4o: при тарифах $2.50 за 1 млн входных токенов и $10.00 за 1 млн выходных одна итерация с примерно 4 000 входных и 800 выходных токенов стоит около $0.018.
- Если агент выполняет итерацию каждые 2 секунды, один зависший запуск обходится примерно в $32.40 в час; за 64 часа — около $2 074.
- Расходы усугубляют три пробела: отсутствие лимита итераций, повторы без бюджета и учёт, который не позволяет вовремя заметить перерасход.
- Для каждого поддерживаемого имени модели предлагается хранить цены в версионируемой таблице; неизвестную модель нужно отклонять или оценивать по максимальному тарифу, но не считать бесплатной.
- Пример цен в таблице: gpt-4o — $2.50 за 1 млн входных и $10.00 за 1 млн выходных токенов; claude-sonnet-4 — $3.00 и $15.00 соответственно.
- Вместо суммирования всей таблицы событий при каждом запросе автор рекомендует заранее обновляемый ledger с дневными и месячными расходами для каждого API-ключа.
- Проверку бюджета следует централизовать в FastAPI dependency или middleware и выполнять до обращения к провайдеру; превышение лимита в жёстком режиме возвращает HTTP 402.
- Предусмотрены два режима: hard блокирует вызовы при превышении бюджета, warn записывает предупреждение, но разрешает вызов.
- Redis-флаг llm:kill_switch должен позволять остановить расходы глобально без нового деплоя; при этом лимиты рекомендуется задавать отдельно для каждого API-ключа.
- Как стартовые ориентиры автор предлагает дневной лимит в 3–5 раз выше наблюдаемого p99 дневных расходов ключа и месячный лимит примерно в 1.5 раза выше ожидаемого.
Как сделано
Сначала сервис оценивает стоимость вызова по модели, числу входных и выходных токенов и таблице тарифов. Если модель неизвестна, вызов отклоняется (UNKNOWN_MODEL_POLICY = "refuse") либо оценивается по максимальному известному тарифу — нулевая цена недопустима.
После завершения вызова учётная запись расходов обновляет предварительно агрегированный ledger. Middleware перед следующим вызовом проверяет Redis-ключ llm:kill_switch, затем читает дневной и месячный баланс API-ключа и сравнивает его с предполагаемой стоимостью. При превышении можно либо вернуть HTTP 402, либо в режиме warn разрешить запрос и записать предупреждение.
Новые лимиты предлагается основывать на ожидаемом использовании клиента, а затем калибровать по первой неделе трафика: наблюдать расходы в warn-режиме, установить дневной предел примерно в 4 раза выше фактического p99 и перейти к жёсткой блокировке. Пороговые оповещения стоит дедуплицировать, например отправлять одно сообщение в Slack на ключ в день при достижении 80% лимита.
Результаты
По оценке автора, создание слоя защиты занимает один рабочий день, а описанный сценарий без ограничений может стоить около $2 074 за один зависший запуск. В статье нет данных о внедрении системы в реальном сервисе или измеренной экономии; результат представлен как расчёт и проектная рекомендация.
Ограничения
Расчёт стоимости основан на примерных объёмах токенов, заданной частоте итераций и тарифах GPT-4o-класса; реальные расходы зависят от модели и трафика. Предварительная оценка стоимости и ledger требуют актуальных тарифов и корректного учёта; статья не разбирает точность оценок, гонки при параллельных запросах или детали обработки частичных ошибок. Утверждение, что реализация занимает «один день» и окупается, не подкреплено сравнительным исследованием. Не приведены результаты тестирования ShipSafe.
Что взять себе
- Ставьте проверку бюджета до вызова модели: постфактум-метрики не предотвратят уже возникший счёт.
- Ограничивайте число итераций и бюджет повторов отдельно — не рассчитывайте, что агент сам распознает зацикливание.
- Держите быстрый агрегированный учёт расходов и изолируйте лимиты по API-ключам, чтобы сбой одного клиента не затронул остальных.
- Начинайте настройку лимитов с режима предупреждений и реального трафика, затем включайте жёсткую блокировку; предусмотрите аварийный выключатель без деплоя.
Читать оригинал, если…
Откройте оригинал, если вам нужны фрагменты кода FastAPI, примеры таблицы тарифов и деталей реализации middleware, ledger или kill switch.