Масштабирование LLM-кластеров по загрузке KV-кеша, а не по VRAM: DCGM Exporter + KEDA +... — 28 июля 2026 г. в 07:27:37.508
Масштабирование LLM-кластеров по загрузке KV-кеша, а не по VRAM: DCGM Exporter + KEDA + vLLM Стандартный Horizontal Pod Autoscaler в Kubernetes реагирует на утилизацию CPU и памяти. Для инференса больших языковых моделей этот подход работает с опасной задержкой: когда использование видеопамяти достигает 85–90%, буфер KV-кеша уже переполнен, генерация переходит в состояние вытеснения контекста, а P95 latency взлетает до неприемлемых значений. Корректное автомасштабирование кластера инференса должно базироваться на метриках уровня фреймворка, а не уровне железа. В этой архитектуре мы используем внутреннюю статистику vLLM, экспорт через DCGM и Prometheus, а также KEDA для реактивного масштабирования под пул воркеров. Основная проблема традиционного подхода — нелинейная зависимость между потреблением VRAM и способностью обработки новых запросов. Модели с длинным контекстом быстро фрагментируют память даже при среднем QPS. Когда система опирается на nvidia_gpu_memory_used_bytes, масштабирование запускается уже после начала деградации SLA. Переход на метрики vllm:num_requests_running и vllm:gpu_cache_usage_perc позволяет инициировать развёртывание новых реплик за 30–60 секунд до переполнения буфера. Это критически важно для burst-нагрузок, когда пиковый спрос длится всего несколько минут, но требует мгновенного распределения токенов по доступным чипам без блокировки main loop инференса. Архитектурно цепочка выстраивается так: vLLM поднимает Prometheus endpoint на порту 8000, экспортируя состояние KV-кеша, длину очереди и текущий токеновый throughput. Prometheus собирает метрики с интервалом 15 секунд, применяя histogram_quantile для расчёта P90 загрузки кеширования. KEDA выступает в роли adapter'а: он выполняет custom query к Prometheus API, парсит ответ и динамически изменяет .spec.replicas у HorizontalPodAutoscaler. Дополнительно DCGM Exporter мониторит уровень ECC-ошибок и тепловые throttling-события, отправляя алерты в Alertmanager для принудительного рестарта деградирующих нод до того, как они станут точкой отказа всего кластера. Важно учитывать накладные расходы на холодный старт. Загрузка весов модели в GPU-память занимает время, пропорциональное размеру checkpoint'а и скорости PCIe/NVMe. Поэтому threshold для масштабирования должен задаваться с опережением (lead time). Если gpu_cache_usage_perc пересекает 0.65, а средняя продолжительность загрузки модели — 45 секунд, KEDA уже инициирует создание новой реплики. Это предотвращает резкие скачки метрик и даёт время на пролив трафика через service mesh или load balancer с health-check задержками. Для тонкой настройки рекомендуется использовать recording rules в Prometheus, агрегирующие метрики по namespace и model-version, чтобы исключить кросс-инференсные шумовые данные из общих дашбордов. #AI #LLM #DevOps #OpenSource