Контроль бюджета на доступ к моделям: три уровня

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

Уровень первый: лимит на ключ

Самая дешёвая защита из существующих. Лимит останавливает не только злоумышленника, но и собственную ошибку: цикл, ушедший в бесконечность вечером пятницы, обойдётся в сумму лимита, а не в весь баланс.

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

Уровень второй: лимит на проект

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

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

Уровень третий: уведомление о пороге

Лимит останавливает работу, а уведомление позволяет вмешаться заранее. Настройте оповещение на достижение примерно трёх четвертей бюджета и отдельно — на резкий скачок за сутки.

Второе важнее первого. Резкий рост числа запросов — первый признак и утечки ключа, и забытого процесса на стенде.

Как прогнозировать

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

Отдельно смотрите на средний объём одного запроса. Если он растёт при неизменном числе обращений, значит, в контекст что-то добавляется — разросшийся системный промпт, лишние документы, неограниченная история диалога.

Разбивка по сценариям

Общая цифра не позволяет ничего оптимизировать. Как только расход разложен по сценариям, обычно выясняется, что почти всё съедают один-два из них.

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

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

Что делать при перерасходе

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

1. Посмотреть, какой ключ и какой сценарий дал рост.
2. Проверить, не изменилось ли число запросов и средний размер обращения.
3. Если растёт размер — искать, что попало в контекст.
4. Если растёт число — искать процесс, который его генерирует.
5. При подозрении на утечку немедленно отозвать ключ.

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

Что не поможет

Попытка контролировать расход силой воли и напоминаниями в чате. Через две недели про них забывают.

Единый ключ на всех «чтобы не усложнять». Экономия пяти минут при настройке оборачивается невозможностью что-либо выяснить позже.

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

Кто смотрит на цифры

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

Разработчик отвечает за то, чтобы у каждого ключа был лимит и метка сценария. Это техническая настройка, её делают один раз.

Руководитель проекта раз в неделю смотрит на сводку: сколько израсходовано, какой сценарий лидирует, есть ли всплески. Пять минут.

Финансист сверяет месячную сумму с бюджетом и получает объяснение по отклонениям. Раз в месяц.

Ни один из троих не тратит заметного времени, но вместе они закрывают вопрос полностью.

Что делать с фоновыми задачами

Основной источник неожиданных цифр — не пользовательский трафик, а фоновая обработка: пересчёты, разметка, эксперименты. Она растёт незаметно, потому что её никто не видит в интерфейсе.

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

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

Что настроить один раз

• Отдельный ключ на каждое окружение и каждый проект.
• Лимит расхода на каждом ключе.
• Уведомление о приближении к порогу и о резком скачке.
• Метку сценария во всех вызовах.
• Еженедельный взгляд на сводку: пять минут, чтобы увидеть тренд.

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