Что такое MIG (Multi-Instance GPU) и как настроить для разных LLM?

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

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

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

MIG — это аппаратная функция, доступная на GPU архитектуры Ampere (A100) и Hopper (H100). Она создаёт на одном физическом GPU несколько GPU-инстансов (GI), каждый из которых ведёт себя как отдельный, меньший GPU. Ключевое отличие от программной виртуализации (например, vGPU) в том, что MIG обеспечивает аппаратную изоляцию: один инстанс не может повлиять на производительность другого, даже при максимальной нагрузке.

Зачем это нужно

• Изоляция рабочих нагрузок Запуск нескольких LLM (или других задач) на одном GPU без риска "шумных соседей".
• Оптимизация стоимости Вместо покупки нескольких маленьких GPU можно использовать один большой, разделив его на части.
• Соответствие SLA Каждый инстанс получает гарантированную долю ресурсов, что критично для production-систем.

2. Архитектура MIG: как это работает

Физический GPU A100/H100 состоит из множества SM (Streaming Multiprocessors), VRAM (видеопамять) и кэша L2. MIG делит эти ресурсы на GPU-инстансы (GI) и Compute Instances (CI).

• GPU Instance (GI): Изолированный набор ресурсов, включая часть VRAM, кэша L2 и определённое количество SM. Каждый GI имеет собственный Fabric Manager и отдельные очереди команд.
• Compute Instance (CI): Дополнительное подразделение внутри GI. Один GI может содержать несколько CI, которые делят между собой SM, но имеют изолированные очереди команд. Это позволяет ещё более тонко настраивать параллелизм.

Пример разделения A100 (80GB):

Термин "profile|Профиль MIG" — это предопределённая конфигурация, которая определяет, сколько SM, памяти и кэша получит инстанс. Например, profile|2g.20gb означает 2 SM-среза (28 SM) и 20 ГБ VRAM.

3. Настройка MIG: пошаговое руководство

Настройка MIG выполняется через утилиту nvidia-smi и требует перезагрузки драйвера. Процесс состоит из нескольких этапов.

3.1 Проверка поддержки MIG

Убедитесь, что GPU поддерживает MIG (A100, H100 или более новые) и установлен драйвер версии 470+.

nvidia-smi -q | grep "MIG Capable"
# Ожидаемый вывод: MIG Capable: Yes

3.2 Включение режима MIG

MIG отключён по умолчанию. Включите его для конкретного GPU (например, GPU 0):

sudo nvidia-smi -i 0 -mig 1

После этого GPU перестаёт быть видимым как единое устройство. Вместо него появятся виртуальные инстансы.

3.3 Создание профилей MIG

Создайте один или несколько инстансов с нужными профилями. Например, создадим три инстанса по 20 ГБ (профиль 2g.20gb):

# Создать три инстанса 2g.20gb
sudo nvidia-smi mig -i 0 -cgi 19,19,19

Здесь 19 — это ID конфигурации GPU Instance (CGI) для профиля 2g.20gb. Список всех CGI можно получить командой nvidia-smi mig -i 0 -lgip.

3.4 Проверка созданных инстансов

nvidia-smi mig -i 0 -lgi
# Вывод покажет список GPU Instance ID (GI ID) и их профили.

Теперь каждый инстанс будет виден в системе как отдельное устройство /dev/nvidia-mig-<ID>.

3.5 Запуск LLM на конкретном инстансе

Чтобы запустить модель на определённом инстансе, используйте переменную окружения CUDA_VISIBLE_DEVICES с указанием MIG device ID (например, MIG-<UUID>). UUID можно получить через nvidia-smi -L.

# Пример запуска модели через Hugging Face Transformers
CUDA_VISIBLE_DEVICES=MIG-<UUID> python run_inference.py --model_name "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

Важно MIG-инстансы не поддерживают MPS (Multi-Process Service) и NCCL для распределённого обучения. Они предназначены в первую очередь для инференса.

4. Применение MIG для разных LLM

4.1 Маленькие модели (<10B параметров)

Модели вроде TinyLlama (1.1B), Phi-2 (2.7B), Mistral 7B или Llama 2 7B в 4-битной квантизации могут уместиться в 10–20 ГБ. MIG позволяет запустить несколько таких моделей на одном A100, каждая со своим инстансом.

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

• 3 инстанса по 20 ГБ (профиль 2g.20gb).
• На каждом инстансе запускаем Mistral 7B в 4-битном формате (занимает ~4–5 ГБ).
• Оставшаяся память используется для кэша KV и батча.

4.2 Средние модели (10B–30B)

Для моделей вроде Llama 2 13B или CodeLlama 13B в 8-битном формате потребуется 30–40 ГБ. Подойдёт профиль 3g.40gb или 4g.40gb. На одном A100 можно разместить 1–2 таких инстанса.

4.3 Большие модели (>30B)

Модели вроде Llama 2 70B или Mixtral 8x7B требуют полного GPU (80 ГБ). MIG в этом случае не используется, так как профиль 7g.80gb — это, по сути, весь GPU без разделения.

5. Ограничения и недостатки MIG

Несмотря на преимущества, MIG имеет существенные ограничения:

Альтернативы MIG

• vGPU (виртуальный GPU): Программная виртуализация, менее строгая изоляция, но более гибкая.
• GPU Pooling (например, Run:ai, Volcano): Оркестрация контейнеров с GPU на уровне Kubernetes, без аппаратного разделения.
• Обычный мультипроцессный инференс Запуск нескольких моделей на одном GPU через MPS (Multi-Process Service) — менее изолировано, но проще.

6. MIG в контексте RAG и Agentic Systems

В архитектуре Agentic RAG часто требуется запускать несколько моделей одновременно:

• LLM для генерации ответа (основная модель).
• LLM для реранжирования (ранжировщик).
• LLM для оценки/валидации (например, Self-RAG).
• Embedding-модель (для векторизации запросов).

MIG позволяет изолировать эти компоненты на одном GPU, гарантируя, что нагрузка на ранжировщик не повлияет на latency основной модели. Например, на A100 80GB можно выделить:

• Инстанс 3g.40gb для основной LLM (например, Llama 2 13B).
• Инстанс 2g.20gb для ранжировщика (например, BGE-Reranker).
• Инстанс 1g.10gb для embedding-модели (например, E5-large).

7. Сравнение MIG с другими подходами к разделению GPU

8. Практические рекомендации

• Используйте MIG, когда: Нужно запустить несколько маленьких LLM (до 7B) с гарантиями производительности, и вы готовы пожертвовать гибкостью ради изоляции.
• Не используйте MIG, когда: У вас одна большая модель, вы работаете с большими батчами, или вам нужно распределённое обучение.
• Мониторинг: Отслеживайте использование каждого инстанса через nvidia-smi mig -i 0 -lgi и nvidia-smi dmon -i 0 -m 1.
• Автоматизация Используйте инструменты вроде NVIDIA MIG Manager или Kubernetes Device Plugin for MIG для автоматического создания и удаления инстансов.

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

Задача Развернуть два разных LLM (TinyLlama 1.1B и Phi-2 2.7B) на одном A100 80GB с использованием MIG, каждый на отдельном инстансе, и сравнить latency при параллельных запросах.

Инструменты

• NVIDIA A100 (или эмуляция на H100)
• Docker
• Hugging Face Transformers
• nvidia-smi для управления MIG
• Python (для отправки запросов)

Шаги:

1. Включите MIG на GPU 0: sudo nvidia-smi -i 0 -mig 1.
2. Создайте два инстанса: один профиль 1g.10gb (для TinyLlama), второй 2g.20gb (для Phi-2).
3. Запустите два Docker-контейнера, каждый с доступом к своему MIG-инстансу через CUDA_VISIBLE_DEVICES.
4. В каждом контейнере загрузите соответствующую модель и запустите простой REST API (например, на FastAPI).
5. Напишите скрипт, который отправляет параллельные запросы к обоим API и замеряет latency.
6. Сравните результаты с запуском обеих моделей на одном GPU без MIG (через MPS).

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

• При использовании MIG latency каждого запроса будет стабильным, независимо от нагрузки на соседний инстанс.
• Без MIG latency может сильно варьироваться из-за конкуренции за ресурсы.

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

Навигация

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