Повний гайд: налаштування Kubernetes для AI/ML з NVIDIA GPU Operator

У production-кластері з 8× NVIDIA A100 (середня вартість оренди ~$40,000 на місяць) ми зіткнулися з утилізацією GPU лише 40% через відсутність MIG і неправильного шедулінгу. Після впровадження NVIDIA GPU Operator та gang scheduling утилізація піднялася до 92%, а час простою впав на 55%. Це дозволило заощадити до $15,000 на місяць — економія 37.5% від вартості кластера. Наша команда має 5+ років досвіду налаштування GPU-кластерів для AI/ML та реалізувала понад 20 проектів. Без грамотного налаштування GPU-шедулінгу ви ризикуєте втратити до 60% ресурсів — це прямі збитки. Наш досвід показує: правильна конфігурація Kubernetes для AI/ML навантажень гарантує утилізацію GPU вище 90% та скорочення витрат на GPU-інфраструктуру на 30–50% порівняно з неоптимізованим кластером. Замовте аудит кластера — виявимо вузькі місця та запропонуємо оптимізацію.

Автоматичне управління GPU за допомогою NVIDIA GPU Operator

Оператор автоматично розгортає драйвери NVIDIA, container toolkit і device plugin — все через Custom Resources. Виключається ручне налаштування на кожному вузлі. Результат — готовий кластер з GPU-підтримкою за один Helm-реліз, у 3 рази швидше за ручну конфігурацію. NVIDIA GPU Operator documentation підтверджує це.

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator --create-namespace \ --set driver.enabled=true --set driver.version="545.23.06" \ --set toolkit.enabled=true --set devicePlugin.enabled=true \ --set dcgmExporter.enabled=true --set gfd.enabled=true kubectl get pods -n gpu-operator kubectl get nodes -o custom-columns='NAME:.metadata.name,GPU:.status.capacity.nvidia\.com/gpu' 

Важливість правильного GPU-шедулінгу

Типові проблеми: job не може стартувати через нестачу цілих GPU, хоча є вільні частки MIG; або одна задача блокує весь вузол. Рішення — комбінація MIG, gang scheduling і пріоритетів.

Стандартний планувальник Kubernetes не підтримує gang scheduling, що викликає deadlock при розподіленому навчанні. Volcano та Kueue вирішують цю проблему: Volcano — зрілий, з fair sharing; Kueue — нативний API. Для великих кластерів Volcano забезпечує утилізацію 85–95% проти 60–75% у стандартного — це в 1.3 рази вище.

Як уникнути deadlock при розподіленому навчанні?

Gang scheduling з Volcano гарантує одночасний старт всіх подів розподіленої задачі:

apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: distributed-training spec: minAvailable: 4 schedulerName: volcano tasks: - replicas: 1 name: master template: spec: containers: - name: master image: nvcr.io/nvidia/pytorch:23.09-py3 resources: limits: nvidia.com/gpu: 8 - replicas: 3 name: worker template: spec: containers: - name: worker image: nvcr.io/nvidia/pytorch:23.09-py3 resources: limits: nvidia.com/gpu: 8 

Як підвищити щільність розміщення задач на GPU?

MIG (Multi-Instance GPU) для A100/H100 дробить GPU до 7 екземплярів. Використання MIG підвищує щільність розміщення задач у 3 рази порівняно з цілими GPU і скорочує витрати. Запит у pod spec:

resources: limits: nvidia.com/mig-1g.10gb: 1 

Налаштування пріоритетів для ML задач

Для production-інференсу встановіть PriorityClass з високим пріоритетом (1000), для batch-навчання — низький (100) з PreemptLowerPriority. Критичні сервіси завжди отримують GPU першими, навчання виконується за залишковим принципом.

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

• Документація всіх налаштувань та архітектури кластера.
• Доступ до дашборду Grafana з метриками GPU та сповіщеннями.
• Навчання команди роботі з оператором та шедулером.
• Підтримка за SLA після впровадження (наприклад, 8/5).

Компоненти налаштування кластера

• Розгортання NVIDIA GPU Operator з драйверами та DCGM Exporter.
• PriorityClass для пріоритезації інференсу.
• Node labels для групування GPU-типів (A100, V100, A10G).
• Gang scheduling (Volcano або Kueue).
• Cluster Autoscaler для динамічного масштабування GPU-вузлів.
• Дашборд Grafana з метриками утилізації, температури, NVLink.
• Документація та навчання команди (опціонально).

Наш підхід: етапи

1. Аудит інфраструктури — вимірюємо latency p99, утилізацію, виявляємо вузькі місця.
2. Проектування — вибираємо шедулер, визначаємо профілі ресурсів та MIG-конфігурації.
3. Реалізація — Helm-релізи, налаштування моніторингу, тести на синтетичних навантаженнях.
4. Тестування — перевіряємо FLOPS, витіснення низькопріоритетних job, коректність Gang scheduling.
5. Деплой і підтримка — передаємо документацію, активуємо моніторинг, надаємо SLA.

Типові помилки при налаштуванні GPU-кластера

• Відсутність node labels — поди не знають, який тип GPU на вузлі. Рішення: kubectl label node gpu-node-1 nvidia.com/gpu.product=A100-SXM4-80GB.
• Неконфігурований Cluster Autoscaler — при пікових навантаженнях кластер не зростає. Вкажіть min/max GPU-вузлів.
• Немає моніторингу — падіння продуктивності залишається непоміченим. DCGM Exporter + Grafana дають повну картину.

Порівняння підходів до GPU-шедулінгу

Грамотне налаштування GPU-шедулінгу в Kubernetes — ключ до ефективної експлуатації AI/ML навантажень. Ми гарантуємо утилізацію GPU вище 85% і стабільну роботу навіть при пікових навантаженнях. Зв'яжіться з нами для аудиту вашого кластера — оцінимо поточну утилізацію та запропонуємо оптимізацію. Отримайте консультацію та детальний план впровадження.