# MIG и time-slicing: как делить GPU без путаницы в гарантиях

Чем аппаратное разделение поддерживаемых GPU отличается от совместного выполнения по времени и какие ограничения проверить при размещении нескольких моделей.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/gpu-mig-vs-time-slicing/
Language: ru

Одна большая карта может быть интересна нескольким небольшим нагрузкам. Но «разделить GPU» можно разными способами, и участники должны одинаково понимать предоставляемый ресурс. Для владельца оборудования и финансирующего партнёра это влияет на технические ожидания, размещение и правила учёта.

## Различайте механизмы

[NVIDIA MIG](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/) описывает разделение поддерживаемых GPU на экземпляры с выделенными ресурсами. [Time-slicing в GPU Operator](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-sharing.html) относится к совместному использованию GPU с распределением выполнения по времени.

Time-slicing не следует описывать как аналог аппаратной изоляции памяти и отказов MIG. И MIG нельзя обещать на любой карте: поддержка устройства и допустимые конфигурации проверяются по документации.

Число логических долей в интерфейсе не означает появление такого же количества физических ускорителей. В инвентаризации сохраняйте исходную карту и выбранный способ предоставления.

## Начните с профилей задач

Запишите модель, нужную память, характер потока и допустимые задержки каждой нагрузки. Небольшие веса не гарантируют низкого потребления всего сервиса при длинном контексте или нескольких сессиях.

Для условного пилота выберите две модели с разными профилями. Сначала измерьте каждую отдельно, затем вместе в поддерживаемой схеме. Сохраните ограничение памяти и число активных запросов.

Если цель — изоляция определённого свойства, назовите её явно. Удобство размещения нескольких процессов и предсказуемая граница ресурса решают разные задачи.

## Измерьте соседнее влияние

Изменяйте нагрузку одного процесса, наблюдая задержки и ошибки другого. Проверьте короткий поток, длинные входы и пик параллельности. Одиночный ответ на пустой машине не показывает работу совместной схемы.

Наблюдайте системную RAM и CPU наряду с VRAM. Даже при разделении GPU процессы могут конкурировать за ресурсы хоста, накопителя и сети.

Отдельно согласуйте тест прекращения одной нагрузки и восстановления. Нельзя выводить поведение всей системы при отказе из названия технологии без конкретной проверки.

## Сохраните конфигурацию разделения

Укажите профили, драйверы, версии и способ обнаружения ресурса приложением. Изменение схемы может требовать обслуживания и влиять на доступность, поэтому его нельзя считать незаметной операцией для владельца.

Проверьте, что планировщик и отчётность различают физическое устройство и предоставленную долю. Иначе одно и то же оборудование может быть неправильно посчитано как несколько независимых машин.

Финансовую модель стройте на согласованной единице работы или доступности. Само увеличение числа записей о ресурсах не подтверждает рост полезной мощности или выручки.

В отчёте сохраните результат одиночного запуска рядом с совместным. Так станет видно, какой компромисс создаёт выбранное разделение для каждой задачи. Без контрольной точки неудобную задержку соседа легко ошибочно объявить постоянной характеристикой самой карты или конкретной модели.

## Практические выводы

Поддерживаемый способ совместной работы определим после оценки; универсальная программа разделения всех карт не заявлена.

Прочитайте [Kubernetes и ресурсы](/ru/journal/kubernetes-gpu-scheduling/), [RAM и VRAM](/ru/journal/ram-vs-vram/) и [учёт работы оборудования](/ru/journal/capacity-reporting/).