Что такое MIG (Multi-Instance GPU) и когда он полезен для LLM?

Краткий тезис

MIG (GPU|Multi-Instance GPU) — это аппаратная технология виртуализации, позволяющая разделить один физический GPU (например, NVIDIA A100 или H100) на несколько полностью изолированных логических инстансов. Каждый инстанс получает выделенные ресурсы: память, кэш, тензорные ядра. Для LLM MIG полезен в сценариях мульти-tenant serving маленьких моделей (менее 10 млрд параметров), где важна изоляция и предсказуемая производительность. При работе с одной большой моделью или batch-инференсом MIG снижает утилизацию и неэффективен.

1. Термин: MIG (Multi-Instance GPU)

MIG — это технология, реализованная на уровне аппаратуры и драйвера NVIDIA, которая позволяет разбить один физический GPU на несколько GPU-инстансов (instances). Каждый инстанс ведёт себя как отдельный GPU: имеет собственную выделенную память, кэш L2, контроллер памяти, тензорные ядра и планировщик. Инстансы полностью изолированы по производительности и безопасности (нет утечки данных между ними).

Ключевые особенности

• Аппаратная изоляция — в отличие от программной виртуализации (например, MPS), MIG гарантирует, что один инстанс не может повлиять на производительность другого.
• Гранулярность — на A100 80GB можно создать до 7 инстансов, на H100 — до 7 (в зависимости от профиля).
• Профили — предопределённые конфигурации (например, 1g.10gb, profile|2g.20gb, profile|3g.40gb), где число и размер инстансов фиксированы.

Термин «Инстанс» (GPU instance) — логический GPU с фиксированной долей ресурсов физического GPU.

2. Как работает MIG

MIG использует аппаратные механизмы разделения:

• Memory partitioning — каждый инстанс получает непрерывный блок видеопамяти (HBM2/HBM3), недоступный другим инстансам.
• Cache partitioning — кэш L2 делится на сегменты, закреплённые за инстансами.
• Compute partitioning — тензорные ядра и SM (Streaming Multiprocessors) распределяются между инстансами.
• Memory bandwidth partitioning — контроллеры памяти назначаются инстансам, обеспечивая изоляцию пропускной способности.

На уровне драйвера каждый инстанс представляется как отдельное устройство /dev/nvidiaX. CUDA-приложения видят только свой инстанс и не знают о существовании других.

Пример конфигурации на A100 80GB

Команда для просмотра MIG-конфигурации

nvidia-smi mig -lgi

3. Когда MIG полезен для LLM

MIG эффективен в следующих сценариях:

3.1 Мульти-tenant serving маленьких моделей (<10B параметров)

Если вы развёртываете несколько копий небольшой LLM (например, LLaMA-7B, Mistral-7B) для разных клиентов или задач, MIG позволяет запустить их на одном физическом GPU с полной изоляцией. Каждый tenant получает гарантированную производительность, не зависящую от нагрузки соседей.

3.2 Инференс с жёсткими требованиями к latency

Для сервисов, где важна предсказуемость времени ответа (например, real-time чат-боты), MIG исключает «шумных соседей» (noisy neighbor problem). Даже если один инстанс загружен на 100%, другие не страдают.

3.3 Тестирование и разработка

MIG позволяет эмулировать несколько GPU на одной карте для параллельного тестирования разных версий модели или конфигураций без покупки дополнительного оборудования.

3.4 Изоляция безопасности

В мульти-tenant окружениях (например, облачные платформы) MIG гарантирует, что данные одного пользователя не могут быть прочитаны другим.

4. Когда MIG не полезен для LLM

4.1 Одна большая модель (>10B параметров)

Если модель требует более 40-80 GB памяти (например, LLaMA-70B в FP16), MIG не имеет смысла — весь GPU нужен целиком. Разделение приведёт к нехватке памяти для одного инстанса.

4.2 Batch-инференс с высокой пропускной способностью

При обработке большого batch-запроса (например, пакетная генерация для датасета) один физический GPU с полными ресурсами даёт максимальную throughput. MIG снижает совокупную производительность из-за фиксированного разделения ресурсов.

4.3 Fine-tuning или обучение

Обучение LLM требует максимальной памяти и вычислительной мощности. MIG только ограничит доступные ресурсы, замедлив процесс.

5. Сравнение MIG с альтернативами

Ключевое отличие MIG от MPS MPS делит только вычислительные ресурсы (SM), но память остаётся общей — один процесс может вызвать OOM для всех. MIG же полностью изолирует память.

6. Практические соображения при использовании MIG для LLM

6.1 Настройка

MIG включается на уровне драйвера и требует перезагрузки GPU. Пример активации:

sudo nvidia-smi -mig 1

Затем создаются инстансы через nvidia-smi mig -cgi <profile>.

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

• Не все GPU поддерживают MIG (только A100, H100, и некоторые модели HGX).
• Количество инстансов фиксировано профилем — нельзя создать, например, 4 инстанса по 20 GB на A100 (только 3 по 20 GB).
• Для работы с MIG требуется CUDA 11.0+ и совместимые контейнеры (например, NVIDIA GPU Operator в Kubernetes).

6.3 Мониторинг

Используйте nvidia-smi с флагом mig или Prometheus-экспортеры для отслеживания загрузки каждого инстанса.

6.4 Пример serving маленькой модели на MIG

Допустим, у вас есть A100 80GB и нужно развернуть 3 копии LLaMA-7B (FP16, ~14 GB каждая). Выбираем профиль 2g.20gb (3 инстанса по 20 GB). Каждая копия запускается в отдельном контейнере с привязкой к своему инстансу через переменную окружения CUDA_VISIBLE_DEVICES=GPU-<uuid>.

7. Влияние MIG на производительность LLM

Эксперименты показывают:

• Для моделей размером 7B latency на инстанс практически не отличается от полноценного GPU при одинаковом batch size = 1.
• Throughput (запросов/сек) при batch size > 1 падает пропорционально доле ресурсов, так как тензорные ядра и память разделены.
• Для моделей 13B профиль 3g.40gb может быть недостаточен (модель 13B в FP16 занимает ~26 GB + overhead), поэтому лучше использовать 7g.80gb целиком.

Пет-проект для закрепления

Задача Развернуть две маленькие LLM (например, TinyLlama-1.1B и Qwen-1.5B) на одном A100 с использованием MIG и сравнить latency и throughput с запуском на полном GPU через MPS.

Инструменты

• NVIDIA A100 (или эмуляция в облаке)
• Docker с NVIDIA Container Toolkit
• Hugging Face Transformers
• Python + CUDA 11.8+
• nvidia-smi для мониторинга

Шаги:

1. Включить MIG на GPU: sudo nvidia-smi -mig 1 && sudo nvidia-smi mig -cgi 1g.10gb -C 7 (создать 7 инстансов по 10 GB).
2. Запустить два контейнера: первый с TinyLlama, второй с Qwen. Каждому назначить отдельный MIG-инстанс через --gpus '"device=GPU-<uuid>"'.
3. Написать скрипт для отправки 100 запросов к каждой модели, замерить среднее время ответа (latency) и количество запросов в секунду (throughput).
4. Отключить MIG, запустить обе модели на полном GPU через MPS (установив CUDA_MPS_PIPE_DIRECTORY).
5. Сравнить результаты: latency, throughput, стабильность (дисперсия).

Ожидаемый результат

• MIG покажет более стабильную latency (меньше выбросов) за счёт изоляции.
• Throughput на MIG будет ниже, чем на полном GPU с MPS, из-за фиксированного разделения ресурсов.
• При высокой нагрузке на одну модель в MPS другая модель может страдать (noisy neighbor), в MIG — нет.

Связь с другими вопросами

Навигация

• Предыдущий: 314
• Следующий: 316
• Индекс: 00. Индекс разборов