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

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

Длина промпта почти ничего не говорит о цене ответа

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

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

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

Фильтр по словам здесь не сработает

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

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

Отдельного внимания требуют необычные Unicode-последовательности и так называемые glitch-токены. Некоторые редкие последовательности кодируются моделью нестандартно и могут потребовать непропорционально много обработки. Их следует включать в набор нагрузочных проверок, не ограничиваясь длинными текстами и копированием символов.

Устойчивое упрощение сохраняет смысл ответа

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

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

Это поведение полезно проектировать на уровне продукта. Интерфейс должен уметь показать, что результат ограничен, предложить сузить период, количество объектов или глубину анализа. Для агентного сценария полезна остановка с кратким отчётом: что уже сделано, какой лимит достигнут и какое следующее действие потребует нового подтверждения пользователя.

Модель не заменяет инфраструктурные ограничения

В эксперименте обе модели были ограничены генерацией в 512 токенов. YandexGPT Lite 5 в 115 ответах остановилась ровно на этом значении. Это важное наблюдение: интеллектуальное упрощение помогает, однако часть опасных сценариев всё ещё выполняется до технического лимита.

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

Нужен и мониторинг. Логи должны позволять увидеть рост токенов на запрос, задержку, число повторных попыток, расходы по модели, цепочки tool calls и заполнение очереди. Полезны пороги, после которых сервис переводит запрос в компактный режим, требует подтверждения или останавливает работу. Метрика «запрос завершился» здесь недостаточна: успешное завершение может оказаться слишком дорогим для всей системы.

Нагрузочный тест должен имитировать смысловую сложность

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

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

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