Масштабируем vLLM по KV-cache и очереди запросов, а не по CPU — 21 июля 2026 г. в 04:05:21.550
Масштабируем vLLM по KV-cache и очереди запросов, а не по CPU Стандартный HPA в Kubernetes бессмыслен для LLM-инференса. Метрики CPU и RAM не отражают реальное состояние GPU: модель может простаивать при 80% утилизации видеопамяти из-за фрагментации KV-cache, либо уходить в OOM при резком всплеске длинных промптов. В vLLM узкое место — это внутренний буфер запросов и occupancy PagedAttention-ядра. Чтобы кластер реагировал на реальный pressure инференса, нужно переключить HPA на метрики самого рантайма: vllm:num_requests_running, vllm:num_requests_waiting и vllm:gpu_cache_usage_perc. Архитектура решения строится вокруг Prometheus Adapter, который транслирует pull-метрики в custom metrics API для контроллера HPA. Контейнер с vLLM должен экспортировать метрики на порту 8000 (флаг --enable-metrics). Prometheus собирает их, а adapter преобразует в /apis/custom.metrics.k8s.io/v1beta1. HPA таргетит именно эти метрики по подам. Важный нюанс: масштабирование должно учитывать cold start penalty загрузки модели на GPU. Резкое увеличение реплик при коротких спайках приведёт к OOM из-за параллельного инициализирования weight cache. Поэтому целевое значение ставим не на 100%, а на 75–80% occupancy, давая буфер для peak-load и garbage collection видеопамяти. Настройка требует трёх компонентов: ServiceMonitor для сбора метрик, CustomMetricRules в prometheus-adapter, и YAML HPA с правильной логикой стабилизации (behavior.scaleDown.stabilizationWindowSeconds минимум 300). Для отладки полезно включить --disable-frontend-multiprocessing и мониторить очередь через vllm:num_requests_swapped. Если swap активен — инференс деградирует, HPA должен уже масштабироваться до этого момента. Ниже конфиги для production-ready деплоя с учётом специфики GPU-кластеров. #AI #LLM #DevOps #OpenSource