Компания подключает нейросеть к одной задаче. Через месяц ключей уже пять, к API ходят три сервиса и половина разработчиков, а счёт вырос втрое. Кто именно потратил — никто не знает.
Это не редкий случай, а обычный ход событий. Разберём, почему так выходит и что ставить, чтобы не выяснять это по факту.
Почему счёт растёт незаметно
Отдельный запрос стоит копейки. Одно обращение к недорогой модели — доли цента. Ни у кого не возникает мысли, что за этим надо следить. Проблема появляется на объёме, и появляется сразу вся.
Ключ расходится по команде. Один ключ, выданный «чтобы попробовать», кочует в скрипты, в чужие ноутбуки и в тестовые окружения. Через месяц никто не скажет, кто им пользуется.
Цикл не спрашивает разрешения. Ошибка в коде, отправляющая запрос в цикле, — обычное дело. Разница только в том, остановит ли её что-нибудь до конца месяца.
Длина ответа не ограничена. Если не задан предел, модель отвечает столько, сколько сочтёт нужным. Платите вы за каждый исходящий токен, а они дороже входящих в разы.
Счёт приходит потом. Когда расход виден одной суммой в конце месяца, понять, что именно её сделало, уже нельзя.
Три уровня, на которых ставят лимиты
Смысл в том, чтобы ограничение стояло там, где происходит трата, а не только сверху.
Уровень компании
Общий месячный предел. Это последняя линия: он не даст выйти за рамки, даже если всё остальное настроено неудачно.
Ставится по принципу «сколько мы готовы потратить в худшем месяце», а не «сколько тратим обычно». Лимит, равный обычному расходу, будет срабатывать на каждом всплеске и мешать работе.
Уровень ключа
Отдельный предел на каждый API-ключ. Это тот уровень, который чаще всего пропускают, а он самый полезный.
Смысл прост: боевой сервис и эксперименты не должны делить один кошелёк. Ключ для тестов с небольшим лимитом — это гарантия, что неудачный эксперимент остановится сам, а не съест бюджет, из которого работает продакшен.
Отсюда же правило: на каждое применение — свой ключ. Не ради порядка, а чтобы можно было отозвать один, не останавливая остальные.
Уровень сотрудника
Личный предел на человека. Нужен там, где к моделям ходят люди, а не только сервисы: через чат, через помощника в редакторе, через собственные скрипты.
Без него один увлёкшийся эксперимент неотличим от обычной работы, пока не придёт счёт.
Мягкое предупреждение и жёсткая блокировка
Это разные вещи, и путать их дорого.
Мягкий лимит предупреждает: при достижении порога приходит уведомление, но запросы продолжают идти. Подходит там, где остановка хуже перерасхода — например, для боевого сервиса, от которого зависят клиенты.
Жёсткий лимит отклоняет запросы при исчерпании. Подходит для экспериментов, тестовых контуров и личных ключей — везде, где остановка безопаснее счёта.
Разумная связка: порог уведомления процентов на восемьдесят плюс жёсткий предел сверху. Тогда вы узнаёте о приближении заранее, а не в момент, когда всё встало.
Отдельно стоит подумать, кому уходит уведомление. Письмо разработчику, который в отпуске, — это отсутствие уведомления.
Что смотреть, кроме общей суммы
Общая сумма не отвечает ни на один полезный вопрос. Полезны разрезы.
- По моделям. Часто выясняется, что основную часть счёта делает одна дорогая модель на задаче, где хватило бы дешёвой.
- По дням. Ровный график — норма. Ступенька — это чей-то новый сервис или чья-то ошибка, и лучше увидеть её на второй день, а не тридцатый.
- По ключам. Отвечает на вопрос «кто тратит», ради которого всё и затевалось.
- Доля ошибок. Растущая доля неудачных запросов означает, что что-то сломано, а вы продолжаете это оплачивать.
- Прогноз до конца месяца. Простая экстраполяция, но она превращает «мы потратили 40» в «к концу месяца выйдет 120» — а это уже повод действовать.
Три вещи, которые стоит сделать сегодня
- Задать `max_tokens` во всех запросах. Самая дешёвая мера с самым быстрым эффектом.
- Развести ключи по применениям и поставить лимит хотя бы на экспериментальный.
- Включить уведомление о пороге. Даже без жёсткой блокировки это превращает неожиданность в предупреждение.
Как это устроено у нас
Управление расходами — не приложение к доступу, а то, ради чего платформа и делалась.
- Лимиты на трёх уровнях: компания, отдельный ключ, отдельный сотрудник.
- Мягкий и жёсткий режим: порог уведомления настраивается, жёсткая блокировка включается отдельно и по умолчанию выключена — включать её молча значило бы сломать работу тем, кто этого не просил.
- Расход по каждому запросу: модель, токены, стоимость, время. Не одна сумма в конце месяца.
- Разрезы по моделям, дням и ключам, доля ошибок, прогноз на месяц вперёд.
- Рекомендации по экономии: где вы, вероятно, переплачиваете и что попробовать вместо. Формулируем осторожно — обещать сохранение качества при смене модели нельзя.
- Ограничение списка моделей: можно разрешить команде только часть каталога, и тогда дорогую модель не выберут даже по ошибке.
- Баланс предоплатный — уйти в минус невозможно в принципе.
Что до цен и того, из чего вообще складывается счёт, — разбирали отдельно.
Частые вопросы
Лимит останавливает работу целиком? Только жёсткий и только по достижении предела. Мягкий шлёт уведомление и не мешает.
Считается ли расход в реальном времени? Да. Жёсткий лимит смотрит и на прошлые дни, и на сегодняшние траты — иначе оставалась бы дыра размером в сутки.
Можно ли ограничить конкретного сотрудника? Да, личный предел ставится на человека отдельно от общего.
Что происходит при ошибочном запросе? Деньги не списываются. При обрыве ответа платите только за полученную часть.