Лимиты бюджета для LLM-фич без ручного контроля

Почему счет растет незаметно

Счет за LLM редко вырастает из-за одной большой ошибки. Обычно его раздувают мелкие решения, которые долго выглядят безобидно. Команда следит за качеством ответов, а расход спокойно растет в фоне и становится заметен только в конце месяца.

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

Вторая причина - длинные чаты. Пользователь пишет все больше сообщений, а приложение при каждом новом запросе отправляет всю историю заново. Один диалог, который выглядит вполне обычным, за день может набрать сотни тысяч токенов. Особенно часто это происходит в поддержке, где человек переспрашивает одно и то же разными словами, а система снова оплачивает весь контекст.

Есть и менее заметный источник расходов внутри команды: тесты, отладка и внутренние демо. Разработчики проверяют промпты, аналитики прогоняют сценарии, менеджеры показывают прототипы коллегам. По отдельности это мелочь. Вместе такие вызовы легко съедают ощутимую часть месячного бюджета, если для тестовой среды нет отдельных правил.

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

Именно поэтому лимиты бюджета для LLM-фич лучше ставить до перерасхода, а не после него. Когда ошибка в маршруте, длинная сессия или бесконтрольные тесты уже попали в отчет, времени на спокойную настройку обычно не остается.

Где ставить лимиты

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

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

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

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

На практике обычно хватает такой схемы:

• на пользователя - дневной или месячный лимит;
• на сессию - потолок по токенам или сумме;
• на функцию - отдельный лимит по деньгам, токенам и числу вызовов.

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

Если запросы идут через единый шлюз, например AI Router, такие ограничения удобно хранить рядом с API-ключами, маршрутами и аудит-логами. Тогда расходы видны по слоям, а не одной строкой в счете.

Что считать расходом

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

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

Обычно в расход попадает не только сам вызов модели. Деньги уходят и на поиск, и на внешние API, и на повторные запросы после ошибок или таймаутов. Во многих командах проблема не в основном промпте, а в цепочке вокруг него: сначала поиск, потом извлечение данных, затем модерация и еще один вызов модели для финального ответа.

Удобно делить бюджет на три корзины: запрос, генерация и инструменты. Запрос - это все, что вы отправили в модель. Генерация - все, что модель вернула. Инструменты - любые дополнительные шаги вокруг ответа, даже если пользователь их не видит.

Цена должна фиксироваться в момент вызова. Если трафик маршрутизируется через разные модели и провайдеров, прошлый запрос нельзя пересчитывать по новой ставке. Иначе отчет перестает совпадать с реальным счетом.

После этого полезно регулярно сверять внутренний расчет с инвойсом провайдера. Не в конце месяца, а по ходу работы. Если внутренняя метрика показывает 9 000 тенге, а счет приходит на 11 800, значит вы не учли ретраи, инструменты или разницу между ценой входа и выхода.

Когда команда считает деньги, а не только токены, контроль расходов LLM становится заметно точнее. Тогда лимиты на пользователя, сессию и функцию работают по реальной стоимости, а не по грубой оценке.

Как внедрить лимиты по шагам

Лимиты бюджета для LLM-фич лучше вводить как обычную часть продукта. Если ждать большого счета и действовать в спешке, получится набор случайных ограничений, который мешает пользователям, но плохо спасает бюджет.

Начните с короткого реестра всех мест, где модель делает платный вызов. Обычно это не только чат, но и автосводка, проверка анкеты, поиск по базе знаний, скрытая классификация в фоне и повторные запросы после ошибок. Чаще всего команды забывают именно про фоновые вызовы.

Дальше работает простая последовательность:

1. Для каждой функции запишите цель, частоту запуска и цену одного типового запроса. Достаточно грубой оценки.
2. Назначьте месячный потолок отдельно для каждой функции. Чат поддержки и генерация отчета редко заслуживают одинаковый бюджет.
3. Разделите этот потолок на два слоя: лимит на пользователя и лимит на сессию.
4. Поставьте мягкий порог и жесткую отсечку. На мягком пороге система сокращает контекст, переходит на более дешевую модель или отключает дорогой режим. На жесткой отсечке она останавливает вызов и показывает понятное сообщение.
5. До запуска проверьте отказ вручную. Пользователь должен видеть ясный ответ, а команда - лог и метрику, а не молчаливую ошибку.

Небольшой пример: если функция "умный чат" получила 300 000 тенге в месяц, пользователю можно дать 3 000 тенге, а одной сессии - 150 тенге. Когда сессия доходит до 120 тенге, чат отвечает короче и не тянет лишний контекст. После 150 тенге он предлагает продолжить позже или перевести запрос оператору.

Хорошая настройка отвечает на один важный вопрос заранее: что система делает в ту минуту, когда бюджет закончился. Если этот сценарий понятен, расход не выходит из-под контроля.

Лимит на пользователя

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

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

Бесплатный и платный трафик тоже стоит считать отдельно. У бесплатного плана лимит можно обрезать жестко, например по деньгам в день. Для платного тарифа разумнее поставить мягкий потолок и предупредить заранее, а не обрывать диалог посреди работы.

Если одна и та же функция может работать через несколько моделей, порог лучше привязать к классу модели. На дешевой модели пользователь получает больше запросов, на дорогой - меньше. Такой подход быстро снижает расход и почти не требует ручного контроля.

Не склеивайте устройства одного человека вслепую. Если считать только по device_id, лимит легко обойти. Но если без проверки объединить мобильное приложение, веб-кабинет и рабочий планшет, вы получите ложные блокировки. Надежнее опираться на account_id, а устройства использовать как дополнительный сигнал.

Когда лимит сработал, пишите прямо. Сообщение вроде "Бесплатный лимит на AI-ответы закончился. Попробуйте снова завтра или выберите короткий режим" работает лучше, чем сухая ошибка 429. Пользователь понимает, что случилось, и не думает, что сервис сломался.

Лимит на сессию

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

Обычно сначала задают потолок на общий объем токенов в рамках одной сессии. Например, чат может работать до 20-40 тысяч токенов суммарно, включая вход и выход. Когда сессия подходит к порогу, интерфейс предупреждает пользователя и предлагает начать новый диалог. Это заметно лучше, чем молча продолжать дорогую переписку.

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

Нужен и таймаут простоя. Если человек ушел на встречу и вернулся через два часа, старая сессия уже редко полезна целиком. Проще завершить ее через 15-30 минут бездействия и начать заново. Так вы не тащите в новый запрос лишний контекст.

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

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

Лимит на функцию

Один общий потолок на весь продукт почти всегда создает перекос. Чат съедает бюджет, а короткое саммари или проверка поля в форме внезапно начинают получать отказы. Поэтому лимит лучше задавать для каждой функции отдельно.

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

Расход полезно делить и по этапам. Поиск по документам и ответ модели - это не одна операция, а две. Поиск может тратить деньги на эмбеддинги, rerank или отдельный сервис. Ответ модели добавляет свою часть. Если считать все вместе, трудно понять, где именно ушли деньги и что урезать первым.

Для функций обычно хватает нескольких простых правил. Саммари получает небольшой дневной лимит и короткий таймаут. Основной чат - отдельный бюджет и более мягкий порог отказа. Поиск по базе знаний считается отдельно от генерации ответа. Фоновые и пакетные задачи идут через очередь со своим лимитом. Экспериментальные фичи получают бюджет заметно ниже, чем основной сценарий.

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

Лимиты удобно хранить рядом с конфигом маршрутизации модели. Тогда команда видит полную картину в одном месте: какая функция вызывает какую модель, с каким fallback и с каким денежным потолком.

Пример: чат поддержки в мобильном банке

Клиент открывает чат в приложении и пишет: "Какая комиссия за перевод и какой лимит у моей карты?" Для банка это частый и на вид дешевый сценарий. Но расход быстро растет, если бот несколько раз ходит в поиск, собирает длинное резюме и отвечает слишком многословно.

Нормальный путь запроса короткий. Система ищет тарифы и лимиты по нужному продукту, делает сжатое резюме для модели и отдает один понятный ответ без лишних уточнений. Если данных хватает, на этом сессия заканчивается за 1-2 хода.

В таком чате обычно ставят три ограничения. Для пользователя действует дневной потолок в тенге. Например, после 250 тенге бот продолжает только простые FAQ-ответы или предлагает написать оператору. Для сессии задают предел на число ходов и длину ответа - скажем, не больше 6 сообщений туда-обратно и не длиннее 700-900 знаков на ответ. Отдельный бюджет получает и перевод на оператора, потому что он часто дороже обычного ответа: нужно собрать контекст, сделать краткую сводку для сотрудника и сохранить логи.

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

Частые ошибки

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

Первая ошибка - один общий потолок на весь продукт. На старте это кажется удобным, но потом ломает картину. Несколько активных пользователей или одна тяжелая функция быстро съедают весь запас, и дальше блокируются уже все сценарии.

Вторая ошибка - смотреть только на токены. Токены сами по себе мало что говорят о расходе. Один и тот же запрос на двух моделях может стоить совсем по-разному. Команде нужен учет в деньгах, иначе перерасход видно слишком поздно.

Третья ошибка - оставлять дорогую модель по умолчанию для всех задач. Короткая классификация, черновик письма и ответ в чате поддержки не требуют одного и того же уровня качества. Когда любая задача уходит в дорогую модель, счет растет тихо, без явного сигнала.

Четвертая ошибка - не считать системные промпты и повторный контекст. Многие команды смотрят только на текст пользователя. Но в цену входят и инструкции, и история диалога, и правила безопасности, и прошлые сообщения. Иногда именно этот невидимый объем делает сессию дорогой.

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

Хороший лимит не мешает работе. Он сдерживает расход так, чтобы пользователь все равно мог закончить задачу.

Короткий чек-лист перед запуском

Перед релизом проверьте не только качество ответов, но и место, где система остановит лишний расход. Если не задать границы заранее, даже полезная AI-функция быстро начинает тратить больше, чем вы ожидали.

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

Есть простой тест перед запуском: откройте логи и попробуйте за две минуты ответить на три вопроса. Кто потратил больше нормы? Какая функция дала пик расходов? Какая модель была вызвана в этот момент? Если на любой из этих вопросов нельзя ответить сразу, система еще не готова к боевой нагрузке.

Что сделать дальше

Не пытайтесь сразу ставить лимиты на все AI-сценарии. Начните с одной функции, где расход уже заметен. Часто это чат поддержки, длинная суммаризация документов или генерация ответов для операторов.

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

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

Если у команды уже есть единый шлюз для LLM, полезно свести в одном месте логи запросов, маскирование PII, rate limits, маршрутизацию моделей и денежные лимиты. Для таких задач AI Router выглядит практичным вариантом: он позволяет держать расходы, маршруты и аудит рядом, не меняя привычные SDK и код.

Когда эти данные собраны вместе, перекосы видны намного быстрее. Становится понятно, кто съедает бюджет, какая функция уходит в перерасход и где дешевле сменить модель, чем просто ужать лимит. Тогда бюджет перестает быть ручной проблемой и становится обычной частью эксплуатации.