Деплой больших языковых моделей (LLM) — это всегда боль при пиковых нагрузках. В классических веб-сервисах при высоких RPS можно включить балансировщик или вернуть HTTP 429 Too Many Requests. Но в генеративном AI отбрасывать запросы слишком дорого: пользователь уже вложил время, написал промпт и ждёт ответ.

Масштабирование GPU-кластера занимает минуты, которых часто нет. Вместо отбрасывания запросов мы применили подход под названием «Динамическая лень» (Dynamic Degradation). Он позволяет сохранять доступность сервиса при 100% утилизации GPU, заставляя модель отвечать короче. Для этого мы создали open-source шлюз LazyGate.

Архитектура LazyGate

LazyGate — это легковесный ASGI-прокси на FastAPI и httpx, размещённый перед vLLM-сервером. Его основная задача — отслеживать нагрузку на GPU, опрашивая драйверы NVIDIA (или эмулятор в dev-режиме).

Мы выделили три состояния кластера:

• Normal Load (<75%): обычный режим. Модель генерирует полноценные ответы с max_tokens = 100%.
• Tired Load (75–90%): нагрузка растёт, растёт и очередь continuous batching. Шлюз добавляет в промпт инструкцию: «Отвечай кратко», а max_tokens снижается до 70%.
• Extremely Lazy (>90%): аварийный режим. Инжектируется жёсткий системный промпт: «Provide extremely short answers only. No explanations. Code only if asked.» и лимит токенов падает до 30%.

Zero-Blocking поллинг NVML

Чтение метрик GPU через pynvml на каждый HTTP-запрос блокировало бы event loop. Чтобы этого избежать, опрос драйверов вынесен в фоновую asyncio-задачу.

Теперь для каждого запроса получение нагрузки — это просто чтение из памяти: monitor.current_load.

Сохранение стриминга и TTFT

Одна из ключевых фич vLLM — стриминг токенов (stream=True). Если бы шлюз буферизовал ответ, это убило бы Time-to-First-Token (TTFT).

Поэтому мы используем StreamingResponse и передаём токены потоково, не нарушая задержки.

Автономные тесты: AI тестирует свою «лень»

Мы не хотели вручную обновлять Pytest-тесты при каждом изменении профилей нагрузки в config.yaml. Поэтому создали tester_agent.py — внутреннего агента на базе ИИ.

Он читает YAML-конфиг, анализирует тесты через AST и проверяет, покрыты ли все сценарии (Normal, Tired, Lazy). Если находит пробел — автоматически дописывает недостающий тест в test_main.py и перезапускает CI/CD.

Заключение

Динамическая модификация поведения модели через промпт — более гибкая альтернатива жёсткому rate limiting. Вместо отказа в обслуживании мы снижаем сложность генерации, сохраняя доступность.

В планах — заменить прямой опрос NVML на отслеживание Token Velocity, чтобы точнее оценивать пропускную способность очередей vLLM.

Проект открыт и доступен на GitHub под лицензией для академического и некоммерческого использования.

Введение: Почему обычный Rate Limiting не работает для LLM?

Деплой больших языковых моделей (LLM) — это всегда боль, когда дело доходит до пиковых нагрузок. В классических web-сервисах при высоких RPS мы просто включаем балансировщик, а если всё горит — жестко режем запросыHTTP 429 Too Many Requests.

Но в мире генеративного AI отбрасывать запросы клиентов очень дорого: пользователь уже подождал, пока загрузится чат, написал длинный промпт, нажал Enter и… получил ошибку. А масштабирование GPU-кластера занимает минуты, которых у нас нет.

В этой статье мы покажем, как подход“Динамической лени”(Dynamic Degradation) позволяет сохранить доступность сервиса при 100% утилизации GPU, не отбрасывая запросы, а заставляя саму модель быть более “краткой”. Для этого мы написали свой open-source шлюзLazyGate.

Архитектура LazyGate

Идея проста: мы ставим перед нашим vLLM сервером легковесный ASGI-прокси на базеFastAPI+httpx. Этот прокси-шлюз выполняет одну ключевую задачу — постоянно опрашивает драйверы NVIDIA (или эмулятор в режиме разработки), получая метрику нагрузки наGPU.

Мы определили три состояния кластера:

1. Normal Load (<75%): Обычный режим. Модель может писать стихи, долго рассуждать и вдаваться в детали (max_tokens: 100%).
2. Tired Load (75-90%): Система начинает испытывать сложности (очередь continuous batching растет). Прокси “на лету” подкидывает в массивmessagesсистемный промпт:“Отвечай кратко”, аmax_tokensурезается до 70%.
3. Extremely Lazy (>90%): Аварийный режим. Чтобы максимально быстро очистить очередь KV-кэша, шлюз инжектит жесткий промпт:“Provide extremely short answers only. No explanations. Code only if asked.”и режет токены до 30%.

Zero-Blocking поллинг NVML

Читать нагрузку видеокарты при каждом HTTP запросе через интерфейс Pythonpynvml— верная смерть для Event Loop’а. Поэтому мы вынесли это в фоновуюasyncioзадачу.

Таким образом, для каждого входящего роута получение метрики — это просточтение из памяти:monitor.current_load.

Проблема со стримингом и SSE

vLLM используется в основном со стримингом токенов (stream=True). Если бы наш прокси буферизировал ответ, мы бы убили главную фичу —Time-to-First-Token (TTFT).

Именно поэтому мы используем потоковую передачу данных черезStreamingResponse:

AI как тестировщик своей же “Лени” (Автономные тесты)

Мы не хотели вручную переписывать Pytest-тесты каждый раз, когда добавляем новый профиль нагрузки вconfig.yaml. Так как в разработке мы применяем AI-инструменты, мы написали скриптtester_agent.py.

Это “внутренний Агент”, который сам читает конфиг YAML со списком порогов, идет в файл с Pytest-тестами через Abstract Syntax Trees (AST) и ищет, покрыт ли каждый сценарий (Normal, Tired, Lazy). Если он находит “дыру”, скриптавтоматически дописывает коднового теста в файлtest_main.pyи запускает конвейер заново!

Заключение

Использование промптинга для динамической модификации сложности вычислений (LLM Routing) — намного более гибкий подход, чем жесткий Rate-limiting.

В ближайших планах — добавить в шлюз отслеживание Token Velocity () вместо прямого пинга NVML, чтобы понимать реальную пропускную способность очередей vLLM.

Код проекта полностью открыт под лицензией для академического и некоммерческого использования нанашем GitHub. Присоединяйтесь!