vGPU, MIG или SR-IOV: как поделить GPU в AI-облаке в 2026 году

Когда один ускоритель обслуживает сразу нескольких клиентов, вопрос «как его поделить» превращается в вопрос о деньгах, SLA и репутации оператора. В 2026 году есть три основных подхода: NVIDIA vGPU, NVIDIA MIG и SR-IOV (в экосистеме AMD он называется MxGPU). У каждого свои сильные стороны и свои ловушки, и ниже мы разбираем, где какой подход работает лучше всего.

Что важно при делёжке GPU в облаке

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

Хвостовые метрики вместо средних

Для инференса важны не средние значения, а задержка 95-го и 99-го процентилей и разброс времени ответа между соседними запросами. Именно они показывают, выдержит ли сервис обещанный уровень качества в часы пикового спроса.

Шумный сосед

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

Область отказа

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

Учёт ресурсов

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

Десять критериев выбора

Прежде чем сравнивать технологии, зафиксируйте, что для вас важно. Вот список из десяти критериев:

Изоляция при сбоях — ограничивается ли сброс одним экземпляром или задевает всех соседей.
Безопасность при многоарендности — есть ли аппаратная изоляция памяти и вычислительных блоков.
Качество обслуживания — насколько предсказуема задержка 95-го и 99-го процентилей.
Совместимость со стеком — поддерживаются ли нужные гипервизоры, Kubernetes, OpenStack, драйверы и версии ОС.
Наблюдаемость и учёт — доступны ли метрики по каждому арендатору, а не только по устройству целиком.
Простота эксплуатации — насколько сложно обновлять драйверы, менять конфигурацию и обслуживать узлы.
Ограничения профилей — можно ли делить GPU гибко или доступны только фиксированные размеры.
Плотность размещения — сколько клиентов реально помещается на один ускоритель без нарушения SLO.
Стоимость владения — есть ли отдельные лицензии и как они влияют на экономику услуги.
Экосистема и зрелость — насколько технология встроена в инструменты управления и мониторинга.

Эти критерии нужны, чтобы обсуждать vGPU, MIG и SR-IOV не в отрыве от продакшна, а применительно к вашим условиям.

Базовые понятия: три модели разделения

Прежде чем переходить к продуктам, стоит развести три принципиально разные модели.

Разделение по времени. GPU остаётся единым устройством, а арендаторы получают к нему доступ по очереди. Плотность размещения высокая, но именно эта модель чаще всего даёт нестабильную задержку под нагрузкой.
Аппаратное разделение. Физический GPU режется на независимые экземпляры, каждый со своей долей вычислительных блоков, памяти и других ресурсов. Поведение предсказуемее, но профили жёсткие, а переупаковка ресурсов негибкая.
Прямой проброс и аппаратная виртуализация через SR-IOV. Виртуальная машина получает виртуальную функцию GPU почти как отдельное устройство. Накладные расходы минимальны, изоляция сильная, но резко растут требования к платформе: BIOS, IOMMU, гипервизор, драйверы и сама модель ускорителя должны совпасть без ошибок.

Главный недостаток в продакшне у каждой модели свой. У разделения по времени это нестабильность задержки, у аппаратного разделения — жёсткие профили и фрагментация, у SR-IOV — сложность эксплуатации: любое расхождение версий всплывает ещё до запуска нагрузки.

Для клиента разница выглядит так. При разделении по времени он получает «долю GPU», но не всегда предсказуемое поведение. При аппаратном разделении арендует фиксированный экземпляр с понятным профилем. При прямом пробросе работает почти как с выделенным ускорителем внутри ВМ. Для эксплуатации картина сложнее: разделение по времени проще запустить, но трудно обещать по нему жёсткое качество; аппаратное разделение лучше для инференса, чувствительного к задержке, но требует аккуратной работы с профилями и остановок при перенастройке; SR-IOV даёт сильную изоляцию, но требует строгого отношения к матрице совместимости и процессу обновлений.

NVIDIA vGPU: удобная виртуализация и риск для стоимости владения

NVIDIA vGPU встраивается в привычную виртуализацию и позволяет разместить на одном физическом GPU несколько виртуальных машин с фиксированными профилями памяти. Он особенно силён в VDI, графических рабочих местах и смешанных корпоративных нагрузках, где ценятся гибкость профилей и плотность клиентов на сервере.

Для инференса с жёсткими требованиями к задержке те же свойства становятся ограничениями. В классическом режиме vGPU использует разделение по времени, и под пиковой нагрузкой один клиент способен ухудшить задержку другого. Для SLO это опаснее умеренной потери пропускной способности, потому что страдает именно хвост распределения.

Когда vGPU уместен:

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

Когда стоит быть осторожнее:

сервис живёт по жёстким целевым показателям задержки и чувствителен к «шумным соседям»;
основная нагрузка — инференс, а не графика и не VDI;
лицензии заметно влияют на цену конечной услуги.

Здесь и скрывается ловушка. На бумаге vGPU улучшает использование ускорителей, но если прибавить подписку NVIDIA AI Enterprise, требования к совместимым версиям гипервизоров и риск нарушить SLO из-за плавающей задержки, выгода перестаёт быть очевидной.

Лицензирование и поддержка в 2026 году

Про vGPU важно помнить: маркетинговое описание почти бесполезно без проверки официальных матриц совместимости. Проверяйте:

поддерживаемую ветку драйверов и срок жизни конкретной серии GPU;
совместимость с вашей версией VMware vSphere, Red Hat KVM, Citrix или другого гипервизора;
ограничения профилей: сколько экземпляров можно создать, какие профили допустимо смешивать, сколько vGPU поддерживается на одной ВМ;
известные проблемы и особые замечания в release notes выбранной ветки драйвера;
модель лицензирования NVIDIA AI Enterprise и её влияние на экономику сервиса.

Опираться стоит не на обзоры и презентации, а на четыре класса документов: матрицу поддерживаемых GPU, матрицу поддерживаемых продуктов, release notes выбранной ветки и официальное руководство по лицензированию.

NVIDIA MIG: жёсткие экземпляры и предсказуемая задержка

У MIG другая философия: вместо того чтобы делить время одного устройства, он физически режет GPU на несколько аппаратно изолированных экземпляров с выделенными вычислительными блоками, памятью и частью внутренних ресурсов. Поэтому технологию ценят там, где нужна предсказуемость, прежде всего в инференсе, где нарушение задержки 99-го процентиля часто хуже умеренного падения средней производительности.

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

У этой предсказуемости есть цена.

Только заранее определённые профили. MIG не выдаёт «любую удобную долю». Для коммерческого облака это неудобно: спрос клиентов редко ложится на красивые доли вроде 1g, 2g или 3g. Возникает фрагментация, когда часть ресурса простаивает просто потому, что доступные профили не складываются в нужную форму.
Перенастройка. Смена профиля обычно требует остановки процессов и переинициализации конфигурации, а в некоторых управляемых средах даже пересоздания пула узлов.

Поэтому MIG чаще выбирают, когда оператор заранее знает характер нагрузки: например, поток типовых инференс-задач, где нужны изоляция и повторяемость. Если же профили приходится постоянно пересматривать под разные заявки, эксплуатационная цена жёстких экземпляров быстро становится заметной.

Официальная поддержка MIG в 2026 году

По документации NVIDIA, MIG поддерживается на архитектуре Ampere и новее, в том числе на A30, A100 и H100, с различиями по версиям CUDA и драйверов. Поддержка более ранних поколений в официальных таблицах не подтверждена.

В Kubernetes MIG работает через официальный механизм для GPU-устройств и через GPU Operator, который умеет управлять конфигурацией MIG на узлах. Модель при этом остаётся строгой: профили планируются заранее, и рассчитывать на удобную смену «на лету» без влияния на сервис не стоит.

SR-IOV и AMD MxGPU: максимум изоляции и максимум требований

SR-IOV сочетает сильную изоляцию с производительностью, близкой к прямому пробросу. GPU предоставляет виртуальные функции PCIe, а виртуальные машины работают с ними почти без тяжёлой промежуточной прослойки. Это привлекательно, если арендаторам нужны ВМ с максимально предсказуемым поведением GPU.

Но именно поэтому вариант самый требовательный. Мало купить подходящий ускоритель: нужны поддержка в BIOS, корректно настроенный IOMMU, совместимый гипервизор, согласованные драйверы на хосте и в госте и подтверждённая вендором матрица совместимости. В отличие от более «мягких» схем, ошибка в одном слое быстро ломает всю конструкцию. SR-IOV — не универсальный ответ, а путь для тех, кто готов к дисциплине в инфраструктуре: при правильной платформе вариант очень сильный, при хаотичных обновлениях он превращается в источник трудно диагностируемых проблем.

Статус MxGPU для AMD Instinct в 2026 году

В экосистеме AMD роль SR-IOV играет MxGPU. Важным шагом последних лет стало открытие исходного кода драйвера GIM, отвечающего за виртуализацию ускорителей Instinct. Это усилило интерес к сценарию, где оператор получает аппаратную виртуализацию и более прозрачную программную основу без отдельной дорогой лицензии поверх железа.

По актуальной документации AMD и связанным официальным материалам, виртуализация заявлена для ряда ускорителей Instinct и некоторых профессиональных моделей: MI210X, MI300X, MI325X, MI350X, MI355X и Radeon Pro V710. Базовый и лучше всего подтверждённый сценарий — KVM и QEMU на Linux.

Что учесть:

поддержка VMware, согласно официальным материалам AMD, сильно ограничена;
распространение полноценной виртуализации на широкий набор потребительских карт Radeon в этих источниках не подтверждено;
каждый сценарий нужно сверять с конкретной версией ROCm и операционной системы.

В итоге AMD MxGPU в 2026 году — интересный и перспективный путь для облаков на KVM, особенно когда важны открытость и контроль над стеком. Но по зрелости экосистемы и широте готовых интеграций он пока требует больше внимания от команды эксплуатации.

Сводная матрица

Критерий	vGPU	MIG	SR-IOV
Изоляция памяти и вычислений	В основном программная, общие вычислительные ресурсы делятся по времени	Аппаратная изоляция памяти, части вычислительных блоков и внутренних ресурсов	Аппаратная изоляция через виртуальные функции PCIe и IOMMU
Изоляция при сбоях	Сброс чаще затрагивает всех соседей на GPU	Последствия лучше ограничены экземпляром MIG	Сильная изоляция на уровне виртуальной функции и платформы
Задержка и QoS	Под высокой нагрузкой возможны пики и нестабильность из-за разделения по времени	Более предсказуемая задержка, лучше для инференса, чувствительного к задержке	Близко к выделенному устройству при корректной настройке платформы
Накладные расходы	Зависят от плотности и профиля нагрузки; есть цена виртуализации и планирования по времени	Обычно невелики, разделение аппаратное	Минимальны по сравнению с более тяжёлой виртуализацией
Безопасность при многоарендности	Приемлемая, но граница не так жёстка, как у MIG и SR-IOV	Высокая, экземпляры разделены аппаратно	Высокая при корректной конфигурации IOMMU и гипервизора
Совместимость с виртуализацией	Сильная сторона, особенно для VMware и корпоративных сценариев	Хорошо подходит контейнерным средам и Kubernetes	Сильно зависит от вендора и матрицы совместимости
Управление и квоты	Удобно для профилей ВМ, но нужны лицензии и строгая проверка версий	Жёсткие профили, меньше гибкости, возможна фрагментация	Сложнее и сильнее завязано на платформу
Наблюдаемость и учёт	Хорошо вписывается в привычную виртуализацию, но тонкий учёт требует дисциплины	Метрики на уровне экземпляров лучше подходят для учёта долей GPU	Зависит от связки гипервизора и драйверов
Ограничения	Стоимость лицензий, нестабильная задержка под AI-нагрузкой, зависимость от матрицы совместимости	Жёсткие профили, фрагментация, перенастройка с остановкой сервиса	Жёсткие требования к BIOS, IOMMU, гипервизору и версиям драйверов
Стоимость владения	Может заметно расти из-за NVIDIA AI Enterprise	Обычно проще по лицензированию, если хватает возможностей MIG без надстройки vGPU	Может быть выгодным по лицензированию, но дорогим по инженерной сложности

Как выбирать

Если свести всё к трём тезисам:

vGPU — когда важнее совместимость и плотность виртуальных машин (VDI, графика, смешанные корпоративные нагрузки).
MIG — когда нужна предсказуемая задержка и изоляция внутри AI-облака, особенно для потока типовых инференс-задач.
SR-IOV — когда организация готова платить инженерной дисциплиной за почти прямой доступ к GPU и сильную аппаратную изоляцию.

Отметьте в чек-листе из начала статьи то, что критично для вас, сопоставьте с матрицей, и самый подходящий вариант станет очевиден.

Что это значит при подборе железа

Выбор технологии делёжки напрямую диктует выбор платформы. Для MIG нужны ускорители на архитектуре Ampere и новее (A30, A100, H100), для SR-IOV на стороне AMD — Instinct вроде MI210X, MI300X, MI325X, MI350X, MI355X или Radeon Pro V710 в связке с KVM, а для vGPU придётся закладывать бюджет на лицензии и проверять матрицу гипервизора. Прежде чем покупать узлы, сверьте GPU, BIOS, гипервизор и версии драйверов. Готовые решения можно посмотреть в разделах серверы и AI-серверы, а помощь с конфигурацией под вашу схему делёжки GPU вы получите через контакты «СервакМастер».

Заключение

Универсального решения не существует: у каждой платформы свои преимущества и недостатки. Где-то на первом месте предсказуемость и изоляция, где-то гибкость и плотность, где-то простота внедрения и экономика. Выбирайте ту, чьи качества точнее всего совпадают с вашими задачами, требованиями к задержке, моделью эксплуатации и бюджетом.