Налаштування автоскейлінгу GPU-інфраструктури для AI-навантажень

GPU-інстанції для AI — дорогий ресурс: година A100 коштує суттєво, а idle-простої «з'їдають» бюджет. Холодний старт нового пода займає 3–10 хвилин (завантаження моделі, ініціалізація CUDA), а стандартний CPU-автоскейлінг не враховує специфіку GPU. Без правильного автомасштабування ви платите за простої або втрачаєте запити під час піків. Ми вирішуємо це завдання: налаштовуємо масштабування, яке реально тримає SLA та знижує витрати на 30–40%.

Проблеми, які ми вирішуємо

Холодний старт: час запуску GPU-пода 3–10 хвилин. За цей час черга запитів переповнюється. Рішення: keepalive-поди (мінімум 1), pre-warming (запуск при 70% завантаження черги) та буферизація через request queue. Використання spot-інстанцій погіршує проблему — вони можуть бути перервані в будь-який момент, тому поєднуємо spot з on-demand для критичних сервісів.

GPU utilization vs queue depth: завантаження GPU під час обробки довгого запиту — 100%, але нові запити чекають. Покладатися на utilization — помилка. Правильна метрика — vllm_num_requests_waiting або queue_depth. Ми використовуємо комбінацію: scale-up за глибиною черги, scale-down за utilization.

Thrashing pods: часті злети та падіння через різкі піки. Налаштування стабілізаційних вікон запобігає цьому: scale-down через 10 хвилин, scale-up за 30 секунд.

Чому queue depth — головна метрика для LLM?

GPU utilization не відображає затримки черги. Коли модель обробляє довгий запит, GPU завантажений на 100%, але нові запити стоять. Queue depth показує реальну потребу в ресурсах. Саме вона має бути основним тригером для scale-up.

Як ми налаштовуємо автоскейлінг GPU

Kubernetes HPA з кастомними метриками

# Prometheus Adapter для кастомних метрик apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: vllm-autoscaler namespace: ai-serving spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: vllm-llama3 minReplicas: 1 maxReplicas: 8 metrics: # Основна метрика: черга запитів, що очікують - type: Pods pods: metric: name: vllm_pending_requests target: type: AverageValue averageValue: "5" # скейл при > 5 запитів у черзі на pod # Додаткова: GPU utilization (для scale-down) - type: Pods pods: metric: name: nvidia_gpu_duty_cycle target: type: AverageValue averageValue: "70" # scale-down при < 70% утилізації behavior: scaleUp: stabilizationWindowSeconds: 30 # швидкий scale-up policies: - type: Pods value: 2 periodSeconds: 60 # +2 пода щохвилини scaleDown: stabilizationWindowSeconds: 600 # повільний scale-down (10 хвилин) policies: - type: Pods value: 1 periodSeconds: 300 # -1 pod кожні 5 хвилин 

KEDA для event-driven autoscaling

KEDA гнучкіший за HPA: скейлінг по Prometheus, Kafka, RabbitMQ, SQS. Нижче приклад конфігурації.

apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: vllm-keda-scaler namespace: ai-serving spec: scaleTargetRef: name: vllm-llama3 minReplicaCount: 1 maxReplicaCount: 10 cooldownPeriod: 300 triggers: - type: prometheus metadata: serverAddress: http://prometheus.monitoring.svc.cluster.local:9090 metricName: vllm_queue_size query: sum(vllm_num_requests_waiting{namespace="ai-serving"}) threshold: "10" # 1 replica на кожні 10 запитів, що очікують - type: prometheus metadata: serverAddress: http://prometheus.monitoring.svc.cluster.local:9090 metricName: request_rate query: rate(http_requests_total{job="vllm"}[2m]) threshold: "20" # додатковий тригер по RPS 

Cloud-native autoscaling

Для хмарних GPU-інстанцій використовуємо Auto Scaling Groups з кастомними метриками:

import boto3 autoscaling = boto3.client('autoscaling', region_name='us-east-1') autoscaling.put_scaling_policy( AutoScalingGroupName='llm-gpu-asg', PolicyName='scale-on-queue-depth', PolicyType='TargetTrackingScaling', TargetTrackingConfiguration={ 'CustomizedMetricSpecification': { 'MetricName': 'LLMQueueDepth', 'Namespace': 'Custom/LLMMetrics', 'Statistic': 'Average', }, 'TargetValue': 5.0, 'ScaleInCooldown': 300, 'ScaleOutCooldown': 60, 'DisableScaleIn': False, } ) 

Публікація кастомних метрик з vLLM

Збираємо метрики безпосередньо з інференс-сервера:

from prometheus_client import Gauge, start_http_server import requests import time QUEUE_SIZE = Gauge('llm_queue_depth', 'Number of pending requests') GPU_MEMORY = Gauge('llm_gpu_memory_used_gb', 'GPU memory usage in GB', ['gpu_id']) def collect_metrics(): response = requests.get("http://localhost:8000/metrics").text for line in response.split('\n'): if 'vllm:num_requests_waiting' in line and not line.startswith('#'): queue_size = float(line.split()[-1]) QUEUE_SIZE.set(queue_size) import subprocess result = subprocess.run( ['nvidia-smi', '--query-gpu=memory.used', '--format=csv,noheader,nounits'], capture_output=True, text=True ) for i, mem_mb in enumerate(result.stdout.strip().split('\n')): GPU_MEMORY.labels(gpu_id=str(i)).set(float(mem_mb) / 1024) start_http_server(9091) while True: collect_metrics() time.sleep(15) 

Як pre-warming запобігає cold start?

Запобігаємо холодному старту прогнозуванням завантаження. Якщо queue depth перевищує 70% від максимальної, запускаємо додатковий pod заздалегідь. Код стратегії:

class PreWarmingStrategy: def __init__(self, warmup_threshold: float = 0.7, warmup_lead_time: int = 180): self.warmup_threshold = warmup_threshold self.warmup_lead_time = warmup_lead_time def should_scale_up(self, current_queue: int, max_queue: int, forecast: list) -> bool: if current_queue / max_queue >= self.warmup_threshold: return True future_queue = forecast[self.warmup_lead_time // 15] return future_queue / max_queue >= self.warmup_threshold 

Чому GPU-автоскейлінг складніший за CPU?

Основні відмінності: GPU-інстанції не можна «дробити» між сервісами, cold start значно довший (завантаження моделі ~5 ГБ), а метрики завантаження вводять в оману. На CPU ви опираєтеся на CPU utilization, на GPU — лише на глибину черги та швидкість надходження запитів. Крім того, вартість помилки вища: зайвий GPU-под — зайві витрати на місяць.

Як обрати метрику для скейлінгу?

Найкраще рішення — комбінація queue depth для scale-up та GPU utilization для scale-down.

Що входить у нашу роботу

Ми пропонуємо впровадження під ключ:

1. Аудит поточної інфраструктури — аналіз навантаження, визначення вузьких місць, підбір інстанцій.
2. Проектування схеми скейлінгу — вибір метрик, налаштування HPA/KEDA, оптимізація поведінки (stabilization windows, policies).
3. Реалізація — розгортання Prometheus-стека, інтеграція з vLLM/TGI, налаштування автоскейлінг-груп хмари.
4. Тестування — навантажувальне тестування з симуляцією піків, калібрування порогів.
5. Документація та навчання — runbook для чергових, опис метрик і алертів.
6. Пост-релізна підтримка — моніторинг у перші тижні, коригування політик за фактом.

Терміни та економія

Орієнтовні терміни:

• Базове налаштування (метрики + HPA) — від 5 днів.
• Розширена конфігурація (KEDA + pre-warming) — від 10 днів.
• Повний цикл з навантажувальним тестуванням — від 3 тижнів.

Вартість розраховується індивідуально, виходячи зі складності стеку та обсягу робіт. Наші клієнти економлять 30–40% щомісячних витрат на GPU після впровадження.

Замовте впровадження автоскейлінгу GPU і почніть економити вже через тиждень. Ми займаємося інфраструктурою для AI 5+ років, виконали 20+ проєктів. Гарантуємо стабільну роботу — в договорі прописуємо SLA на час реакції скейлінгу. Kubernetes HPA і KEDA — перевірені інструменти. Зв'яжіться з нами для консультації щодо вашого проєкту — ми проаналізуємо навантаження та запропонуємо оптимальну схему.