GPU Scheduling в Kubernetes: Multi-Instance GPU и виртуализация

🎯 Введение и мотивация

Проблема: В 2023 году компании тратят до 68% бюджета на GPU впустую из-за неоптимального распределения ресурсов (исследование Gartner). Представьте дорогой сервер с GPU A100 стоимостью $15,000, где одна модель машинного обучения использует лишь 15% вычислительной мощности, а остальные ресурсы простаивают.

Пробуждение: В эпоху ChatGPT и Stable Diffusion спрос на GPU в Kubernetes-кластерах вырос на 400% за последний год (данные CNCF). Но традиционное выделение целых GPU на под приводит к:

• Чудовищной неэффективности (1 под = 1 GPU)
• Очередям задач и задержкам запуска моделей
• Невозможности запуска lightweight inference-сервисов
• Росту затрат на инфраструктуру на 200-300%

Решение: Современные технологии виртуализации GPU — NVIDIA Multi-Instance GPU (MIG) и vGPU — превращают физические ускорители в управляемые ресурсы Kubernetes. В этом руководстве вы освоите:

1. Архитектурные различия MIG и vGPU
2. Пошаговое развертывание с GPU Operator
3. Реальные кейсы из MLOps-практики
4. Оптимизацию распределения ресурсов

Roadmap: Мы начнем с фундамента GPU-виртуализации, погрузимся в технические детали Kubernetes Device Plugins, протестируем решения на практических примерах и разберем архитектурные решения для разных сценариев.

📋 Что вам понадобится

Предварительные знания

• Базовое понимание архитектуры Kubernetes (ноды, пода, kube-scheduler)
• Опыт работы с kubectl и Helm
• Общее представление о GPU-вычислениях (CUDA, драйверы)

Инструментарий

1. Кластер Kubernetes v1.20+ (минимум 1 нода с GPU)
   • Поддерживаемые GPU: NVIDIA A100/A30 (для MIG) или любые vGPU-совместимые (T4, V100)
2. NVIDIA GPU Operator v22.09+
3. Инструменты мониторинга: DCGM Exporter, Prometheus, Grafana
4. Тестовые workload: Реестр образов с CUDA-тестами

Практические задания

1. Настройка MIG-профилей через GPU Operator
2. Развертывание vGPU с oversubscription 4:1
3. Бенчмарк-тест изоляции ресурсов
4. Анализ метрик потребления GPU

[🎓 Для новичков]: Не пугайтесь термина MIG — представьте мощный грузовик (физический GPU), который можно разделить на несколько маленьких фургонов (MIG-инстансы) для разных задач. [🚀 Для экспертов]: Используйте DCGM для мониторинга contention в vGPU — ключевой метрики при oversubscription. При высоком значении увеличьте vgpu-memory-limit.

🏗️ Фундаментальные основы

Ментальная модель «Офисное здание»: Представьте физический GPU как 40-этажное здание (аппаратные ресурсы).

• Традиционный GPU: Аренда всего здания одной компании
• MIG: Разделение на 7 независимых блоков с отдельными входами (1A, 2B и т.д.)
• vGPU: Виртуальные этажи, которые могут «перекрываться» между арендаторами

Ключевые концепции

1. MIG (Multi-Instance GPU):

   • Физическое разделение GPU Ampere (A100/A30) на до 7 экземпляров
   • Гарантированные ресурсы: вычисления, память, bandwidth
   • Требует аппаратной поддержки

2. vGPU (Virtual GPU):

   • Программная виртуализация через гипервизор
   • Поддержка широкого спектра GPU
   • Возможность oversubscription (перераспределение ресурсов)

3. Device Plugins:

   flowchart LR
    A[Kubelet] --> B[Device Manager]
    B --> C[NVIDIA Device Plugin]
    C --> D[GPU Resources]
    C --> E[MIG Devices]
    C --> F[vGPU Profiles]

[🎓 Для новичков]: Oversubscription — как продажа одних и тех же билетов на рейс нескольким пассажирам в расчете, что не все придут. Рискованно, но повышает эффективность. [🚀 Для экспертов]: Избегайте смешения MIG и vGPU на одной ноде. Конфликт драйверов снижает производительность на 15-20%.

🔬 Глубокий технический анализ

Архитектура MIG в Kubernetes

graph TD
    A[Physical GPU] -->|Partitioned| B[MIG Device 1]
    A -->|Partitioned| C[MIG Device 2]
    A -->|Partitioned| D[...]
    B --> E[K8s Device Plugin]
    C --> E
    D --> E
    E -->|Exposed| F[Pod GPU Request]

Каждый MIG-инстанс получает:

• Выделенные SMs (Streaming Multiprocessors)
• Изолированную память L2 и DRAM
• Независимые асинхронные движки

Интерактивный эксперимент: Что если запросить 5GiB памяти для MIG-инстанса 1g.5gb? 👉 Ответ: Такой профиль не существует! Стандартные профили: 1g.5gb, 2g.10gb, 3g.20gb, 4g.20gb, 7g.40gb.

vGPU Реализация

sequenceDiagram
    participant Pod as Pod
    participant Kubelet
    participant Plugin as vGPU Device Plugin
    participant Driver as NVIDIA vGPU Driver

    Pod->>Kubelet: Запрос vGPU: nvidia.com/vgpu: 1
    Kubelet->>Plugin: Allocate(gpu_request)
    Plugin->>Driver: Создать vGPU
    Driver-->>Plugin: vGPU Handle
    Plugin-->>Kubelet: Device ID
    Kubelet-->>Pod: Монтирует устройство

Ключевые параметры:

• vgpu-memory-limit: Лимит памяти на инстанс
• vgpu-oversubscription: Коэффициент перераспределения (2, 4, 8)

Производительность и ограничения

💻 Пошаговое практическое руководство

1. Подготовка кластера

# Проверяем доступность GPU
kubectl get nodes -o json | jq '.items[].status.allocatable | {"gpu": ."nvidia.com/gpu"}'
# Ожидаемый вывод: {"gpu": "8"}

2. Установка GPU Operator

helm install --wait gpu-operator \
  -n gpu-operator --create-namespace \
  nvidia/gpu-operator \
  --set migManager.enabled=true

3. Конфигурация MIG

Объяснение: Создаем ConfigMap для профилей MIG

# mig-parts.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: default-mig-parted-config
  namespace: gpu-operator
data:
  config.yaml: |
    version: v1
    mig-configs:
      all-disabled:
        - devices: all
          mig-enabled: false
      all-1g.5gb:  # Профиль для 7 инстансов
        - devices: all
          mig-enabled: true
          mig-devices:
            "1g.5gb": 7

Применяем:

kubectl apply -f mig-parts.yaml

Анализ: GPU будет разделен на 7 экземпляров по 5GB памяти каждый. Проверяем:

kubectl describe node | grep nvidia.com/mig-1g.5gb
# Должно показать 7 доступных устройств

4. Развертывание workload с MIG

# mig-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: cuda-vector-add
spec:
  containers:
  - name: vector-add
    image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda11.6.0
    resources:
      limits:
        nvidia.com/mig-1g.5gb: 1

5. Настройка vGPU с oversubscription

# vgpu-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: vgpu-config
  namespace: gpu-operator
data:
  any: |
    version: v1
    vgpu:
      defaults:
        oversubscription: 4
        memory: 4096

Важно: Oversubscription 4:1 позволяет запускать 4 пода на одном физическом GPU.

📊 Исчерпывающее сравнение решений

Матрица выбора:

• Производственные ML: MIG
• Графика/VDI: vGPU
• Тестовые среды/CI: Time-Slicing

🏆 Реальные кейсы и истории успеха

Кейс 1: Медицинский стартап (компьютерное зрение)

• Проблема: 12 моделей inference с пиковым спросом в разное время
• Решение: A100 с MIG (7 инстансов 1g.5gb)
• Результат:
  • Задержка обработки снижена с 210ms до 47ms
  • Затраты на GPU снижены на 60%
  • Плотность задач увеличена в 6.8 раз

Кейс 2: Автопром (рендеринг CAD)

• Проблема: Пиковые нагрузки 300+ сессий VDI
• Решение: NVIDIA T4 с vGPU (oversubscription 4:1)
• Результат:
  • Снижение TCO на 45%
  • Единый пул GPU для инженеров и DS
  • Поддержка Windows/Linux workload

Кейс 3: FinTech (анализ в реальном времени)

• Ошибка: Использование Time-Slicing для LSTM-моделей
• Проблема: Сбои при пиковых нагрузках из-за contention
• Решение: Переход на MIG с профилем 2g.10gb
• Урок: Time-Slicing непригоден для чувствительных к задержкам задач

🛠️ Мастер-класс по лучшим практикам

1. Принципы проектирования:

   • «Один профиль на ноду»: Не смешивайте MIG-профили на одном GPU
   • «Золотая середина oversubscription»: Начинайте с 4:1 для vGPU

2. Антипаттерны:

   • Разделение GPU между namespace без ResourceQuotas
   • Игнорирование метрик DCGM_FI_DEV_VGPU_IPC_CONTENTION
   • Использование nvidia-docker вместе с GPU Operator

3. Чеклист развертывания:

4. [ ] Проверка совместимости GPU

5. [ ] Установка GPU Operator последней версии

6. [ ] Настройка MIG через ConfigMap

7. [ ] Определение ResourceQuotas для namespace

8. [ ] Настройка мониторинга (DCGM, Prometheus)

9. [ ] Тест изоляции: запуск stress-тестов параллельно

10. Оптимизация производительности:

    • Для MIG: используйте nvidia-smi mig -i 0 -cgi 1g.5gb для точного профилирования
    • Для vGPU: мониторьте contention rate в Grafana

🚀 Дорожная карта изучения и развития

Для новичка (0-6 мес):

1. Освойте базовое выделение GPU в Kubernetes
2. Разверните GPU Operator с Time-Slicing
3. Изучите мониторинг через DCGM Exporter

Для продвинутых (6+ мес):

1. Внедрите MIG для production workload
2. Постройте систему автоматического масштабирования GPU
3. Оптимизируйте oversubscription под специфичные задачи

Проекты для портфолио:

• MLOps-платформа с динамическим выделением GPU
• Система квотирования GPU ресурсов
• Бенчмарк-инструмент для сравнения MIG/vGPU

Сообщества:

• NVIDIA Developer Forums
• Kubernetes GPU Special Interest Group (SIG)

🔮 Будущее и emerging trends

1. Краткосрочные тренды (2024):

   • Нативная поддержка MIG в KubeScheduler
   • Упрощение vGPU для облачных провайдеров
   • Стандартизация GPU метрик в OpenTelemetry

2. Долгосрочные тренды (2025+):

   • Интеграция с распределенным обучением (Multi-Node MIG)
   • Адаптивное перераспределение GPU в реальном времени
   • Квантово-инспирированные алгоритмы планирования

Как готовиться:

• Изучайте архитектуры Hopper и Blackwell GPU
• Экспериментируйте с Kubernetes Device Plugins SDK
• Мониторьте проекты KubeVirt и ContainerD

❓ Подробные ответы на частые вопросы

Q1: Можно ли использовать MIG на старых GPU (P100, V100)? 👉 Нет, MIG требует аппаратной поддержки, доступной только в Ampere (A100/A30) и новее. Для V100 используйте vGPU или Time-Slicing.

Q2: Как контролировать oversubscription в production? 👉 Установите лимиты через vgpu-memory-limit и мониторьте contention. При значениях >15% уменьшите коэффициент oversubscription.

Q3: Какие риски безопасности у vGPU? 👉 vGPU использует общие драйверы, что может привести к уязвимостям изоляции. Решение: регулярное обновление драйверов и использование Trusted Computing.

Q4: Какой минимальный размер MIG инстанса? 👉 Минимальный профиль — 1g.5gb (1/7 GPU A100). Для задач <5GB памяти используйте Time-Slicing.

Q5: Поддерживается ли MIG в облачных провайдерах? 👉 Да, но с ограничениями. AWS (p4d.24xlarge), GCP (a2-megagpu-16g), Azure (ND A100 v4). Всегда проверяйте документацию.

Q6: Как отлаживать проблемы с выделением GPU? 👉 Используйте:

kubectl describe node | grep -i gpu
nvidia-smi -q
kubectl logs -n gpu-operator <device-plugin-pod>

Q7: Можно ли динамически менять MIG-профили? 👉 Да, через GPU Operator с перезагрузкой модуля ядра (требует recycle ноды). Онлайн-изменение планируется в CUDA 12.4.

Q8: Какие альтернативы NVIDIA GPU Operator? 👉 Open-source решения: KubeGPU, GPU-Manager (Tencent). Но они не поддерживают MIG/vGPU полноценно.

🎯 Заключение и план действий

Ключевые концепции:

• Вспомним ментальную модель «Офисного здания»: MIG — это физическое разделение этажей, vGPU — виртуальные перегородки
• Без виртуализации до 70% ресурсов GPU пропадают впустую
• GPU Operator — стандарт де-факто для управления GPU в Kubernetes

Твой план «Первые 3 шага»:

1. 🚀 Сейчас: Установите GPU Operator в тестовый кластер:

   helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
   helm install gpu-operator nvidia/gpu-operator

2. 🔍 Завтра: Протестируйте MIG на A100 или vGPU на T4 с oversubscription
3. 📈 На неделе: Настройте мониторинг DCGM и определите точки неэффективности

Долгосрочная стратегия:

• Автоматизируйте выбор GPU-стратегии на основе типа workload
• Внедрите квотирование для multi-tenant сред
• Оптимизируйте TCO через комбинацию MIG + vGPU

Пора действовать! Откройте терминал, запустите GPU Operator, и превратите ваши кластеры в эффективные GPU-фабрики. Ваши модели машинного обучения ждут освободившихся ресурсов!

Дополнительные ресурсы:

• Официальная документация NVIDIA GPU Operator
• Глубокое погружение в MIG архитектуру
• Репозиторий практических примеров