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

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

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

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

# Из нашего hardware.py
async def _monitor_loop(self):
    while True:
        # Чтение реальной нагрузки (либо синусоиды для mock режима)
        new_load = self._fetch_real_load()
        
        # EMA (Экспоненциальное скользящее среднее) чтобы побороть "дребезг" на порогах
        alpha = 0.3
        self._current_load = (new_load * alpha) + (self._current_load * (1 - alpha))
            
        await asyncio.sleep(self.update_interval)

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

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

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

# main.py
if is_stream:
    async def stream_generator():
        async with http_client.stream("POST", url, json=body, headers=proxy_headers) as response:
            async for chunk in response.aiter_bytes():
                yield chunk
                
    return StreamingResponse(stream_generator(), media_type="text/event-stream")

Мы не хотели вручную переписывать 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. Присоединяйтесь!