Лимиты по бизнес-сценарию вместо API-ключа: где и зачем

Почему один лимит мешает работе

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

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

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

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

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

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

Почему у сценариев разные правила

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

Чат продаж сильнее всего зависит от скорости. Когда ответ идет дольше 2-3 секунд, человек часто закрывает окно или просто перестает писать. Для такого трафика обычно выбирают быстрые модели, короткий таймаут и жесткий предел на длину ответа. Лучше дать короткий, но живой ответ, чем потерять лид из-за паузы.

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

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

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

Что стоит ограничивать

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

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

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

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

Третий слой - деньги. Лучше считать расходы не только по API-ключу, а по команде, продукту или типу задачи. Тогда видно, кто именно тратит бюджет. Поддержка может жить в одном диапазоне расходов, внутренний R&D - в другом. Это особенно полезно, если вы маршрутизируете запросы на разные модели и цена ответа меняется в разы.

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

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

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

Как задать правила

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

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

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

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

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

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

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

Как это выглядит в обычный день

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

Чат продаж живет по минутам. Если ответ идет 8-10 секунд вместо 2-3, человек часто закрывает окно или уходит без заявки. У операторов допуск шире: они могут подождать немного дольше, если получают полный и аккуратный ответ по обращению. Ночная обработка архива вообще не требует мгновенной реакции. Ей важнее пройти весь объем без сбоев и не съесть дневной бюджет.

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

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

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

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

Какие метрики смотреть после запуска

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

Первая метрика - доля запросов, которые упираются в лимит. Смотрите ее отдельно по каждому сценарию. Если чат продаж получает отказы даже в 2-3% случаев в часы пик, это уже бьет по выручке. Для фоновых задач тот же процент может быть терпимым, если очередь потом догоняет план.

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

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

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

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

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

Где обычно ошибаются

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

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

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

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

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

Проверка перед релизом

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

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

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

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

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

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

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

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

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

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

Если вам нужен единый API-слой в РФ, этот подход удобно строить через RU LLM. Платформа дает один совместимый с OpenAI эндпоинт, а маршрутизацию, биллинг и аудит-трейлы можно держать внутри РФ, не меняя SDK, код и промпты.

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