Як ми розгортаємо LLM на Kubernetes з GPU: практичний досвід

Ми інтегруємо Kubernetes з GPU-вузлами для десятків проєктів — це знижує time-to-production у 2-3 рази порівняно з bare metal. Проблема ручного управління LLM: простій GPU при збоях, складне масштабування, хаос оновлень. Наш підхід дає автоскейлінг, rolling updates, health checks та ізоляцію ресурсів. Працюємо з 2018 року, виконали 50+ ML-проєктів.

Нещодавно ми деплоїли LLaMA-3-8B для чат-бота з вимогами latency p99 < 200 мс. Використовували vLLM з PagedAttention на двох A100. Після оптимізації досягли 45 req/s та 120 мс p99. Подробиці нижче.

Чому Kubernetes з GPU критичний для LLM?

LLM споживають до 320 ГБ пам'яті на модель. Відмова одного пода не повинна ламати сервіс. Kubernetes забезпечує resource isolation та автоматичне відновлення. За нашим досвідом, кластер з GPU-вузлами окупається за 2-3 місяці за рахунок скорочення простоїв. NVIDIA GPU Operator автоматизує драйвери, а Device Plugin керує віртуалізацією. Наприклад, економія на оренді GPU може сягати $400 на місяць для двох A100.

Підготовка кластера: NVIDIA Device Plugin та GPU Operator

NVIDIA Device Plugin — обов'язковий компонент. Встановлення через Helm:

helm repo add nvdp https://nvidia.github.io/k8s-device-plugin helm repo update helm upgrade -i nvdp nvdp/nvidia-device-plugin \ --namespace nvidia-device-plugin --create-namespace \ --set gfd.enabled=true \ --set devicePlugin.config.sharing.timeSlicing.resources[0].name=nvidia.com/gpu \ --set devicePlugin.config.sharing.timeSlicing.resources[0].replicas=4 

Time-slicing дає до 4 віртуальних GPU на один фізичний — це економить до 40% витрат при малому навантаженні. Для production використовуйте виділені GPU з MIG (Multi-Instance GPU) — ізоляція вища, latency стабільніша.

Як vLLM порівнюється з конкурентами?

vLLM у 2 рази швидший за LMDeploy на A100 з LLaMA-3-8B при тому ж hardware. Причина — PagedAttention та оптимізація KV-cache. Згідно з документацією vLLM, PagedAttention покращує ефективність пам'яті у 2–4 рази. Порівняємо ключові метрики:

Приклад деплою LLaMA-3-8B з streaming та моніторингом:

apiVersion: apps/v1 kind: Deployment metadata: name: vllm-llama3-8b namespace: ai-serving spec: replicas: 2 selector: matchLabels: app: vllm-llama3-8b template: metadata: labels: app: vllm-llama3-8b annotations: prometheus.io/scrape: "true" prometheus.io/port: "8080" spec: nodeSelector: nvidia.com/gpu.product: "A100-SXM4-80GB" tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule containers: - name: vllm image: vllm/vllm-openai:v0.5.0 command: - python3 - -m - vllm.entrypoints.openai.api_server args: - --model=/models/llama-3-8b-instruct - --tensor-parallel-size=1 - --max-model-len=8192 - --max-num-seqs=256 - --gpu-memory-utilization=0.90 - --port=8000 ports: - containerPort: 8000 name: http resources: limits: nvidia.com/gpu: "1" memory: "32Gi" cpu: "8" requests: nvidia.com/gpu: "1" memory: "24Gi" cpu: "4" readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 60 periodSeconds: 10 failureThreshold: 10 livenessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 120 periodSeconds: 30 volumes: - name: model-storage persistentVolumeClaim: claimName: model-storage-pvc 

Як скейлити LLM під навантаженням?

Стандартний HPA по CPU марний. Використовуємо кастомні метрики — розмір черги vLLM (vllm_queue_size). Приклад HPA з scaling policies:

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: vllm-hpa namespace: ai-serving spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: vllm-llama3-8b minReplicas: 1 maxReplicas: 8 metrics: - type: Pods pods: metric: name: vllm_queue_size target: type: AverageValue averageValue: "10" behavior: scaleUp: stabilizationWindowSeconds: 60 policies: - type: Pods value: 1 periodSeconds: 120 scaleDown: stabilizationWindowSeconds: 300 

Така конфігурація дає економію GPU-годин до 30% при низькому навантаженні.

Що робити, якщо модель не влізає в один GPU?

Для моделей 70B+ використовуємо tensor parallelism. Приклад affinity для розміщення на одній ноді:

resources: limits: nvidia.com/gpu: "4" memory: "320Gi" cpu: "32" affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: kubernetes.io/hostname 

Порівняння режимів розділення GPU:

Покрокова інструкція з деплою

1. Встановіть NVIDIA Device Plugin через Helm, як описано вище.
2. Створіть PVC для зберігання моделі з достатнім розміром (мінімум 50 ГБ для 7B моделі).
3. Розгорніть vLLM через наведений маніфест, вказавши вірну модель та ресурси.
4. Налаштуйте сервіс та Ingress для доступу до API (наприклад, через Istio або Nginx).
5. Налаштуйте HPA з кастомними метриками, зібравши їх за допомогою Prometheus та адаптера.
6. Перевірте скейлінг, запустивши навантажувальне тестування (наприклад, за допомогою locust).

Що входить у роботу

• Аудит поточної інфраструктури та рекомендації щодо GPU-вузлів.
• Встановлення та налаштування NVIDIA Device Plugin / GPU Operator.
• Деплой vLLM з підтримкою streaming та моніторингом (Prometheus + metrics).
• Налаштування HPA на основі кастомних метрик.
• Документація та навчання команди (2 дні).
• Гарантія стабільної роботи — 24/7 підтримка перший місяць.

Терміни впровадження

1-2 тижні — базовий деплой однієї моделі. Від 1 місяця — multi-model кластер з CI/CD, disaster recovery та cost optimization.

Отримайте консультацію

Зверніться до наших сертифікованих інженерів — допоможемо розгорнути LLM-інфраструктуру, яка витримає продакшен-навантаження. Досвід — 50+ проєктів з ML-інфраструктури. Зв'яжіться з нами для попередньої оцінки. Замовте аудит GPU-інфраструктури — ми підберемо оптимальну конфігурацію під ваші завдання.