Пиковая нагрузка на LLM-функции: как не уронить продукт

Что происходит с продуктом в час пик

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

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

Чаще всего в пике проседают такие места:

• входной API и rate limits по ключу
• хранилище истории, кэш и векторный поиск
• сервисы модерации, PII-маскирования и аудита
• таймауты на фронтенде, в мобильном приложении и бэкенде

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

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

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

Самое неприятное в том, что такая деградация долго выглядит терпимой. Система еще отвечает, но уже теряет деньги и доверие.

Какие сигналы показывают перегрузку заранее

Пик редко начинается с явных ошибок. Сначала растет задержка у самых медленных запросов, потом копятся повторы и таймауты, и только после этого продукт начинает "падать" в глазах пользователей. Если смотреть только на 5xx, вы увидите проблему слишком поздно.

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

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

Раньше ошибок обычно срабатывают такие сигналы:

• p95 и p99 времени ответа растут, хотя среднее еще выглядит нормально
• время ожидания в очереди растет быстрее, чем сама генерация
• доля ретраев и переключений на другого провайдера идет вверх
• time to first token ползет вверх, даже если полный ответ еще укладывается в норму
• пользователи чаще отменяют запрос или закрывают экран до ответа

Пороги лучше задавать не "вообще", а от своей обычной нагрузки. Простой рабочий вариант такой: желтый уровень - p95 выше базовой нормы в 1,5 раза пять минут подряд; оранжевый - ожидание в очереди съедает больше 10-15% вашего SLA; красный - таймауты, 429 или 5xx держатся выше 1-2% несколько минут подряд.

Если у чата обычный p95 равен 3 секундам, реагировать стоит уже на 4,5 секунды, а не ждать 8-10. Для интерактивных функций время до первого токена часто важнее полного времени ответа. Длинный ответ люди терпят лучше, чем пустой экран.

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

Когда включать очередь, а когда сразу резать трафик

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

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

В очередь обычно можно отправлять длинные summary документов, генерацию отчетов и писем, пакетную обработку карточек или обращений, внутренние AI-инструменты для сотрудников и фоновые задачи, где ответ не нужен на экране сразу.

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

Лимит длины очереди лучше считать не в количестве запросов, а во времени ожидания. Если сервис реально обрабатывает 40 запросов в секунду, а ждать дольше 8 секунд уже больно для UX, очередь не должна расти выше примерно 320 задач для этого класса. Иначе вы просто копите долг, который пользователь все равно почувствует.

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

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

Как снижать качество аккуратно, а не хаотично

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

Что упрощать первым

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

Если ассистент обычно пишет 700-900 токенов, в пике часто хватает 300-500. Для чата, поддержки и внутренних помощников это дает заметный эффект: очередь движется быстрее, а смысл ответа почти не страдает.

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

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

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

Как задать уровни без сюрпризов

Команде нужен простой режимный план. Обычно хватает 3-4 уровней:

• уровень 0 - полный ответ, поиск, файлы, длинный контекст
• уровень 1 - более короткие ответы, без лишнего форматирования и длинных примеров
• уровень 2 - без поиска и работы с файлами, с урезанным контекстом
• уровень 3 - только базовые сценарии с жестким лимитом на вывод

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

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

Когда переводить запросы на упрощенные модели

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

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

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

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

Если у вас один OpenAI-совместимый endpoint, как у AI Router, такие правила проще держать в одном месте. Команда может маршрутизировать запросы по классу задачи и не переписывать код под каждого провайдера. Это особенно удобно, когда пик длится 20-30 минут и нагрузку нужно снять быстро.

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

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

Пошаговый план на случай резкого роста запросов

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

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

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

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

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

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

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

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

Пример: один продукт, четыре типа нагрузки

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

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

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

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

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

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

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

Ошибки, из-за которых пик превращается в аварию

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

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

Если у вас OpenAI-совместимый шлюз вроде AI Router, смысл не в одном endpoint сам по себе. Смысл в том, чтобы заранее развести классы запросов: что идет в сильную модель, что можно отдать более дешевой, а что можно отложить.

Вторая ошибка - очередь без жесткого потолка. На бумаге она спасает систему. На деле часто только маскирует аварию: сервис формально жив, но люди ждут 40-60 секунд и уходят. Лучше отклонить часть нагрузки сразу, чем держать бесконечную очередь и сжечь весь запас по времени.

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

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

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

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

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

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

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

Полезно заранее прогнать короткий сценарий. Например, в 18:05 растет очередь, в 18:07 p95 выходит за порог, в 18:08 система отключает длинные генерации, переводит простые запросы на легкую модель и для части экранов отдает ответы по шаблону. Пользователь получает результат за 2-3 секунды, а не ждет 25 секунд и не видит ошибку.

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

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

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

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

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

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

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

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

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

Если команде нужна одна OpenAI-совместимая точка доступа, такой слой можно собрать поверх собственного шлюза или использовать готовый вариант вроде AI Router на airouter.kz. Он позволяет держать маршрутизацию, rate limits и аудит в одном месте, а для команд в Казахстане и Центральной Азии еще упрощает работу с локальным хранением данных и B2B-инвойсингом в тенге.

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