Решения

MIG‑партиционирование на A100/H100: экономика и практика

Задача страницы. Инженерный гид по MIG (Multi‑Instance GPU) на A100/H100: когда это выгодно, как считать экономику, как упаковывать нагрузки, какие профили выбирать, как настраивать Kubernetes/контейнеры, что и как мониторить. Разберём типовые пайплайны, профили производительности, конфиги (nvidia‑smi/K8s), метрики/алерты, траблшутинг и чек‑лист запуска.

TL;DR

  • Когда MIG «заходит»: много малых/средних моделей с низкой латентностью (ASR/TTS, эмбеддинги, RecSys‑ранкеры, онлайновое CV), где один «цельный» GPU простаивает, а изоляция и QoS важнее пикового throughput. См. https://cloudcompute.ru/solutions/throughput-vs-latency/
  • Когда — нет: обучение крупных моделей, распределёнка (FSDP/DP/TP), большие LLM/SD — нужен «цельный» профиль или мульти‑GPU. См. https://cloudcompute.ru/solutions/multi-gpu/
  • Экономика: Cost_per_query ≈ (c_mig × t_infer) / (U); c_mig = c_gpu × share × α, где share — доля HBM/SM, α — коэффициент оверхеда/фрагментации.
  • Профили: используйте мелкие для latency‑критичных однотипных микросервисов; крупные — для моделей «с запасом» (VRAM/активации).
  • Мониторинг: следите за p95 latency, gpu_util, HBM_peak, copy_engines, MIG instance utilization, packing_efficiency. См. https://cloudcompute.ru/solutions/monitoring-logging/
  • Практика: планируйте чанки ≤ 120 с и быстрые чекпоинты под прерываемые пулы, MIG хорошо сочетается с Interruptible‑паттернами. См. https://cloudcompute.ru/solutions/interruptible-patterns/

Сценарии (когда это нужно)

  • Онлайновый инференс (ASR/TTS/VC/эмбеддинги/ранкеры): десятки микро‑сервисов, строгий SLA p95, предсказуемая изоляция.
  • Мультитенантный хостинг моделей: разные команды/клиенты, гарантии VRAM/SM/копировщиков, «шумный сосед» не ломает SLA.
  • Batch‑запросы малого размера: массовая генерация эмбеддингов/скора по мелким батчам, где важен конвейер и стоимость.
  • Dev/QA/канарейки: несколько независимых окружений/веток на одном физическом GPU.

Не стоит применять MIG для: крупного обучения, FSDP/ZeRO, интенсивного NVLink‑обмена, больших диффузионных/LLM моделей. Для таких кейсов — «цельные» профили и/или мульти‑GPU (см. https://cloudcompute.ru/solutions/multi-gpu/).

Архитектуры/пайплайны

1) Мультитенантный инференс на MIG

				
					Ingress (LB/WS/SSE)
  └─ Router (per-tenant/model/SLA)
       └─ K8s Node (A100/H100 in MIG mode)
            ├─ MIG 1: ASR microservice
            ├─ MIG 2: TTS microservice
            ├─ MIG 3: Embeddings
            └─ MIG N: Ranker/Other
                 └─ DCGM Exporter (per-MIG metrics) → Prometheus/Grafana

Особенности: per‑tenant квоты, отдельные deployment’ы под каждый профиль, аннотации на Pod для выбора типа MIG‑инстанса.

2) Пул «мелких» MIG для RAG/RecSys

				
					Client → Featurizer/Tokenizer → Embeddings (MIG) → ANN/Retrieval → Ranker (MIG) → Response

Особенности: быстрые копировщики, pinned/zero‑copy, минимальные батчи (микробатчинг ≤ 4). См. https://cloudcompute.ru/solutions/recsys/, https://cloudcompute.ru/solutions/rapids/

3) Гибридный кластер (MIG + цельные GPU)

				
					Queue → Scheduler
  ├─ On‑Demand pool (целые GPU) — тяжёлые задачи/обучение
  └─ MIG pool (дробные GPU) — онлайн‑инференс/микросервисы

Дешёвые прерываемые узлы под бэкофисы — см. https://cloudcompute.ru/solutions/interruptible-patterns/

Профили MIG и ориентиры

MIG‑профили зависят от модели GPU. Инженерные ориентиры (на 80 ГБ класс, условные названия профилей) и типовые назначения ниже. Реальные цифры зависят от модели/ядра/HBM/копировщиков и вашего стека.

Профиль (пример)Память (ориентир)Для чего подходитКомментарии
1g (≈10 ГБ)~10 ГБTTS/ASR компакт, эмбеддинги, лёгкий CV, kNN‑скорингМинимальная задержка, 1–2 копировщика; беречь HBM‑пики.
2g (≈20 ГБ)~20 ГБASR/TTS среднего размера, RecSys‑ранкеры, векторные БДХороший компромисс latency/ёмкость.
3g/4g (≈40 ГБ)~40 ГБWhisper‑класс/средние diffusion‑инференсы, мультисервисыБольше SM/кэша → стабильный p95.
7g (≈80 ГБ)~80 ГБПочти «цельный» профильДля крупных моделей/батчей, без разбиения.

На 40 ГБ классе масштаб аналогичен, но шаг памяти ~5 ГБ на «1g». Для точной упаковки ориентируйтесь на пик VRAM конкретной модели с запасом 20–30%.

Оценка ёмкости на MIG (инференс, низкая латентность)

Профиль MIGКласс задачКонкурентных сервисов/узлов*Примечания
1gэмбеддинги/TTS компакт6–7 инстансов на 80 ГБ GPU1 модель = 1 MIG; экономия за счёт плотности.
2gASR/RecSys средние3–4Баланс SLA/стоимости.
3g/4gASR HQ/видео‑CV1–2Стабильный p95, запас по VRAM/копировщикам.

* При U≈0.6–0.75 и микробатчах ≤ 4; итог зависит от IO/сетей/модели. См. https://cloudcompute.ru/solutions/throughput-vs-latency/

Конфиги и скелеты

Включение и конфигурация MIG (на узле)

				
					# 1) Перевод GPU в MIG-режим (перезагрузка GPU-инстанса)
sudo nvidia-smi -i 0 -mig 1

# 2) Создание профилей (пример: 7×1g на 80 ГБ классе)
sudo nvidia-smi mig -i 0 -cgi 1g.10gb -C -n 7

# 3) Альтернатива: смешанная раскладка (2×2g, 3×1g)
sudo nvidia-smi mig -i 0 -cgi 2g.20gb,2g.20gb,1g.10gb,1g.10gb,1g.10gb -C

# 4) Проверка и UUID MIG-устройств
nvidia-smi -L
nvidia-smi -i 0 -mig -lmc   # список MIG-инстансов/UUID

Нужны права администратора. Зафиксируйте «матрицу» профилей в CM/Ansible и в kube‑scheduler.

Kubernetes: запрос MIG‑профиля в Pod

				
					apiVersion: v1
kind: Pod
metadata:
  name: asr-mig-1g
spec:
  restartPolicy: Always
  containers:
    - name: asr
      image: cloudcompute/asr-serving:latest
      resources:
        limits:
          nvidia.com/mig-1g.10gb: 1     # запрашиваем именно MIG 1g.10gb
      env:
        - { name: PRECISION, value: "fp16" }
        - { name: MAX_CONCURRENCY, value: "2" }
      volumeMounts:
        - { name: models, mountPath: /models }
  volumes:
    - name: models
      hostPath: { path: /nvme/models }

Для других профилей используйте соответствующий resourceName (например, nvidia.com/mig-2g.20gb). Планировщик выберет узел с подходящим свободным MIG‑инстансом.

Docker Compose: привязка к конкретному MIG‑UUID

				
					version: "3.9"
services:
  tts:
    image: cloudcompute/tts-serving:latest
    environment:
      NVIDIA_VISIBLE_DEVICES: "MIG-f8bd1f7e-...-uuid"  # UUID MIG-инстанса
      PRECISION: "fp16"
    deploy:
      resources:
        reservations:
          devices: [{ capabilities: ["gpu"] }]
    volumes:
      - /nvme/models:/models
    ports: ["8080:8080"]

DCGM/мониторинг на MIG (Prometheus‑лейблы)

  • Экспортируйте per‑MIG метрики: dcgm_gpu_instance_sm_util, dcgm_gpu_instance_mem_used, dcgm_gpu_instance_enc_util (копировщики), dcgm_processes с UUID MIG.
  • Снимайте latency‑метрики сервиса в разрезе Pod/Deployment (p50/p95), и packing_efficiency на узле:
     packing_efficiency = (Σ alloc_mem_MIG) / total_HBM и Σ alloc_SM / total_SM.

Подробнее по наблюдаемости:
 https://cloudcompute.ru/solutions/monitoring-logging/ • https://cloudcompute.ru/solutions/llm-inference/observability/

Наблюдаемость/метрики/алерты

Perf/Latency (на сервис):

  • latency_seconds{pod=…,profile=1g} (p50/p95/p99), qps, queue_wait_ms, timeout_rate.
  • gpu_instance_sm_util, gpu_instance_mem_used_bytes, gpu_copy_util.
  • nvme_{read,write}_mb_s, model_cache_hit.

Packing/Экономика (на узел):

  • packing_efficiency_hbm, packing_efficiency_sm, mig_free_slots{type=1g|2g|…}.
  • fragmentation_waste_bytes — «застрявшая» память/слоты.

Reliability:

  • oom_total{type=vram}, throttle_total, evicted_pods_total (по профилю MIG).
  • instance_restarts_total, readiness_fail_total.

Алерты (примеры):

  • latency_p95 > SLA — уменьшить concurrency/батч, расширить профиль (1g→2g), оптимизировать препроцессы.
  • packing_efficiency_hbm < 0.7 — переразложить MIG‑матрицу (больше мелких/крупных профилей), вынести «слона» на целый GPU.
  • fragmentation_waste_bytes ↑ — перегенерировать MIG на узле (rolling), изменить приёмную сетку профилей.
  • gpu_copy_util ~100% при умеренном SM — упираетесь в копировщики/PCIe; увеличить MAX_CONCURRENCY, оптимизировать I/O/пиннинг, укрупнить профиль.

Экономика и формулы

Обозначения: c_gpu — цена/час «цельного» GPU, c_mig — эквивалентная цена MIG‑инстанса, U — целевая загрузка, t_infer — среднее время запроса, φ — коэффициент фрагментации/оверхода (≥ 1), share_mem, share_sm — доли HBM/SM, β — поправка на небаланс (копировщики/кэш).

  • Стоимость MIG‑инстанса (оценка):
     c_mig ≈ c_gpu × max(share_mem, share_sm) × φ × β.
  • Стоимость 1 000 запросов:
     Cost_per_1000 ≈ (c_mig × 1000 × t_infer) / (3600 × U).
  • Эффективность упаковки узла:
     packing_efficiency ≈ (Σ c_mig_effective) / c_gpu (должна быть ≤ 1; ближе к 1 — лучше).
  • Брейк‑ивен MIG vs цельный GPU:
     Пусть SLA_penalty — «штраф» за деградацию latency при MPS/без MIG. MIG выгоден, если:
     Savings ≈ c_gpu — Σ c_mig_effective — SLA_penalty > 0.
  • Планирование по VRAM‑пикам:
     Для сервиса i требуемый профиль — min profile с HBM_profile ≥ 1.3 × HBM_peak_i (30% запас). Уголок безопасности критичен: миграции/переинициализация могут кратковременно расширять пиковое потребление.

Подробно про расчёты и компромисс throughput↔latency:
 https://cloudcompute.ru/solutions/cost-planner/ • https://cloudcompute.ru/solutions/throughput-vs-latency/

Паттерны эксплуатации

  • Сетка профилей на узле: «нырки» 1g/2g + 3g (или 4g) — закрывают 80% типовых сервисов. Не держите только 1g: возрастёт оверхед на «слонов».
  • Rolling‑пересборка MIG: при смене матрицы — по одному узлу, дренаж Pod’ов, recreate MIG, возврат в пул.
  • Пулы: разделяйте On‑Demand (SLA) и Interruptible (фон/канарейки), см. https://cloudcompute.ru/solutions/interruptible-patterns/
  • Кэш на NVMe: модели/веса/артефакты на локальном NVMe; прогрев перед включением трафика.
  • Тюнинг: FP16/BF16, pin‑memory, zero‑copy, микробатч ≤ 4, фьюзинг препроцессинга. См. https://cloudcompute.ru/solutions/performance-tuning/

Безопасность/изоляция

  • MIG даёт жёсткую изоляцию по SM/HBM/L2/копировщикам (в пределах GPU), снижая «noisy neighbor».
  • Но общие шины (PCIe/NVLink/NVSwitch) и файловые ресурсы остаются общими → rate‑limit I/O.
  • Секреты/токены — только через секрет‑хранилища; логируйте без PII; шифрование «в канале/на диске». См. https://cloudcompute.ru/solutions/security/

Траблшутинг

Симптом

Возможная причина

Решение

CUDA OOM на 1g

VRAM‑пик > профиль

Расширить до 2g/3g, уменьшить батч/активации, FP16/BF16, выгрузка ненужных тензоров

p95 «скачет»

«Шумный» сосед по копировщикам/IO

Переразложить профили, ограничить I/O, вынести «болтливый» сервис в больший профиль

Низкая утилизация SM

Мелкие ядра/узкий поток

Увеличить concurrency, фьюзить операции, микробатч 2–4, закрепить потоки

Высокий fragmentation_waste

Неподходящая матрица MIG

Пересобрать раскладку (больше 2g/3g), анти‑фрагментационный планировщик

Pod «не видит» GPU

Неверный resourceName/плагин

Проверить nvidia.com/mig-*.**gb, версии device‑plugin/драйверов, пересоздать Pod

Падает throughput

Упор в PCIe/copy engines

Пиннинг памяти, уменьшить число копий, сливать препроцессы на GPU

Нельзя собрать NCCL‑коллектив

Ограничения MIG

Для распределёнки используйте цельные GPU; MIG держите для независимых сервисов

Частые рестарты

Прерываемые узлы/сигналы

Включить fast‑чекпоинты/автосейвы, поднять terminationGrace, см. https://cloudcompute.ru/solutions/interruptible-patterns/

Как запустить в cloudcompute.ru

  1. Перейдите в Шаблоны запусков: https://cloudcompute.ru/solutions/templates/ — выберите MIG‑узел (A100/H100) или готовый шаблон сервиса (ASR/TTS/Embeddings/Ranker).
  2. Выберите матрицу профилей (напр., 2×2g + 3×1g) и профиль GPU 80 ГБ или 40 ГБ.
  3. Настройте DaemonSet с DCGM‑экспортёром и включите панели мониторинга p95/gpu/HBM/packing. См. https://cloudcompute.ru/solutions/monitoring-logging/
  4. В деплойментах запросите нужные resourceName MIG и задайте лимиты по CPU/памяти/IO.
  5. Для продакшна: разведите пулы On‑Demand/Interruptible, настройте rolling‑пересборку MIG, канарейки, алерты на latency_p95, packing_efficiency, fragmentation_waste.

Чек‑лист перед продом

  • Определены классы сервисов и их HBM‑пики (+30% запас).
  • Выбрана матрица MIG (1g/2g/3g/4g/7g) с учётом «слонов» и мелких сервисов.
  • Настроен планировщик: resourceName для каждого профиля, anti‑affinity/квоум узлов.
  • Прогреты модели/кэши на NVMe; проверены p95 latency и gpu_copy_util.
  • Включён DCGM per‑MIG; дашборды: latency/QPS/gpu/HBM/packing/fragmentation.
  • Политики безопасности/секретов и ретеншн — внедрены. См. https://cloudcompute.ru/solutions/security/
  • Готов сценарий rolling MIG reconfigure (дренаж узлов, recreate профилей).
  • Нагрузочный прогон ≥ 30 мин на целевой матрице с реальным трафиком.

Навигация