vGPU vs MIG vs SR-IOV: что выбрать для AI-облака в 2026 году
Контекст AI-облака: что важно при делёжке GPU
В 2026 году облака с ускорителями уже давно обслуживают не один тип клиента, а сразу множество разных абонентов с совершенно разными потребностями. Одни арендаторы запускают инференс больших языковых моделей и требуют минимальной задержки ответа, другие обучают модели и готовы терпеть более длинные очереди ради максимальной загрузки железа, третьи используют виртуальные машины с графикой, аналитикой и средами разработки, где важна не только скорость, но и привычная модель эксплуатации.
Из-за этого делить GPU по остаточному принципу уже нельзя. Для инференса критичны не средние значения, а хвостовые метрики: задержка 95-го и 99-го процентилей, а также разброс задержки между соседними запросами. Именно эти показатели определяют, выполнит ли сервис обещанный уровень качества в часы пикового спроса.
Отсюда вытекает и следующая проблема: эффект "шумного соседа". Если несколько арендаторов делят один и тот же GPU без жёсткой аппаратной изоляции, тяжёлая нагрузка одного клиента способна ухудшить задержку у другого, даже если формально всем выделена своя доля ресурсов. В исследованиях по предсказуемому обслуживанию моделей именно конкуренция за общие аппаратные ресурсы, включая шину PCIe и память, называется одной из главных причин нестабильности.
Не менее важна и изоляция при сбоях. В облаке проблема не только в том, кто делит вычислительные блоки, но и в том, кто разделяет область отказа. Если сброс или зависание одного арендатора затрагивает весь физический GPU, то вместе с ним страдают и соседние клиенты, а значит оператор нарушает обязательства сразу перед несколькими заказчиками.
Наконец, сложнее становится учёт. Когда клиент арендует целый GPU, модель расчётов проста. Когда он арендует лишь часть ресурса, облаку нужно честно и прозрачно измерять использование памяти, вычислительных блоков и времени работы, а затем связать это с наблюдаемостью, квотами и выставлением счетов. На практике именно здесь многие красивые схемы разделения ресурсов начинают буксовать.
Критерии выбора: короткий чек-лист
Прежде чем выбирать конкретную технологию, полезно держать перед глазами список критериев. Именно они определяют, окажется ли решение удобным в эксплуатации конкретно для вас или превратится в источник постоянных компромиссов. Давайте выделим 10 основных критериев:
- Изоляция при сбоях: ограничивается ли сброс конкретным экземпляром или задевает всех соседей.
- Безопасность при многоарендности: есть ли аппаратная изоляция памяти и вычислительных блоков.
- Качество обслуживания: насколько предсказуема задержка 95-го и 99-го процентилей.
- Совместимость с вашим стеком: поддерживаются ли нужные гипервизоры, Kubernetes, OpenStack, драйверы и версии операционных систем.
- Наблюдаемость и учёт: можно ли видеть метрики по каждому арендатору, а не только по всему устройству.
- Простота эксплуатации: насколько сложно обновлять драйверы, менять конфигурацию и обслуживать узлы.
- Ограничения профилей: можно ли гибко делить GPU или доступны только фиксированные размеры экземпляров.
- Плотность размещения: сколько клиентов реально удаётся посадить на один ускоритель без разрушения SLO.
- Стоимость владения: есть ли отдельная плата за лицензии и насколько она влияет на экономику услуги.
- Экосистема и зрелость: насколько хорошо технология интегрирована в существующие инструменты управления и мониторинга.
Эти критерии нужны затем, чтобы не обсуждать vGPU, MIG и SR-IOV в отрыве от продакшна и упростить выбор нужного решения конкретно для вас. Теперь давайте разберём термины, а уже потом приступим к сравнению конкретных решений.
База терминов: разделение, планирование и прямой проброс
Разделение GPU между клиентами имеет три очень разные модели реализации.
Разделение по времени означает, что GPU остаётся единым устройством, а арендаторы получают доступ к нему по очереди. В каждый момент времени ускоритель работает то на одного клиента, то на другого. Такой подход удобен там, где важна плотность размещения, но именно он чаще всего даёт нестабильность задержки под нагрузкой.
Аппаратное разделение означает, что физический GPU режется на несколько независимых экземпляров. Каждый экземпляр получает собственную долю вычислительных блоков, памяти и других аппаратных ресурсов. Это даёт более предсказуемое поведение, но ценой жёстких профилей и менее гибкой переупаковки ресурсов.
Прямой проброс или аппаратная виртуализация через SR-IOV означает, что виртуальная машина получает доступ к виртуальной аппаратной функции GPU почти как к отдельному устройству. Здесь минимальны накладные расходы и сильна изоляция, но резко возрастают требования к совместимости платформы: BIOS, IOMMU, гипервизор, драйверы и сама модель ускорителя должны совпасть без ошибок.
Краеугольные недостатки в продакшне у этих трёх подходов тоже разные. У разделения по времени это нестабильность задержки. У аппаратного разделения – жёсткие профили и фрагментация ресурсов. У прямого проброса же сложность эксплуатации, потому что любая несовместимость между версиями превращается в проблему ещё до запуска нагрузки.
Где каждый подход встречается на практике
Для клиента облака различие выглядит просто. При разделении по времени он получает "долю GPU", но не всегда получает предсказуемое поведение. При аппаратном разделении он арендует уже не абстрактную долю, а фиксированный экземпляр с понятным профилем. При прямом пробросе он работает почти как с выделенным ускорителем внутри виртуальной машины.
Для эксплуатации картина сложнее. Разделение по времени легче запустить, но труднее обещать по нему жёсткий уровень качества. Аппаратное разделение лучше подходит для инференса с чувствительностью к задержке, но требует аккуратного управления профилями и остановок при перенастройке. Прямой проброс даёт сильную изоляцию, но заставляет особенно строго относиться к матрице совместимости и процессу обновлений.
Теперь можно перейти к конкретике. Начнём с vGPU, потому что именно его чаще всего воспринимают как стандартную виртуализацию GPU, хотя для AI-нагрузок у него есть важные ограничения.
NVIDIA vGPU: когда это лучший продукт для аренды GPU, а когда ловушка по стоимости владения
NVIDIA vGPU удобен тем, что встраивается в привычную виртуализацию и позволяет разместить на одном физическом GPU несколько виртуальных машин с фиксированными профилями памяти. Поэтому он особенно хорош в сценариях VDI, графических рабочих мест и смешанных корпоративных нагрузок, где ценится гибкость профилей и плотность размещения клиентов на одном сервере.
Архитектура системы Nvidia vGPU. Источник: .
Но как только речь заходит об инференсе моделей с жёсткими требованиями к задержке, сильные стороны vGPU начинают оборачиваться ограничениями. В классическом режиме vGPU использует разделение по времени: арендаторы делят одно и то же вычислительное устройство, а значит под пиковыми нагрузками один клиент может ухудшать задержку другого. Для SLO это опаснее, чем умеренная потеря пропускной способности, потому что страдает именно хвост распределения задержек.
Поэтому vGPU хорош не всегда, а только в определённых условиях. О подробном устройстве и концепции Nvidia vGPU мы рассказывали в отдельной статье.
Когда его стоит брать:
- если облако ориентировано на виртуальные рабочие столы и графические приложения;
- если главная цель - высокая плотность размещения и гибкая нарезка профилей;
- если задержка в миллисекундах не критична, а важнее совместимость с гипервизором и знакомая модель управления.
Когда с ним стоит быть осторожнее:
- если сервис живёт по жёстким целевым показателям задержки и чувствителен к "шумным соседям";
- если основная нагрузка – инференс, а не графика и не VDI;
- если стоимость лицензирования начинает заметно влиять на цену конечной услуги.
Именно здесь возникают издержки по стоимости владения. На бумаге vGPU повышает оптимизацию нагрузки на ускорители, но если добавить стоимость подписки NVIDIA AI Enterprise, требования к совместимым версиям гипервизоров и риск нарушения SLO из-за нестабильной задержки, выгода уже не выглядит такой однозначной.
Лицензирование и поддержка vGPU в 2026 году
Про vGPU важно помнить: в этом продукте маркетинговое описание почти бесполезно без проверки официальных матриц совместимости. Именно там скрывается ответ на вопрос, будет ли конкретная схема работать в реальной инфраструктуре.
Что необходимо проверять:
- поддерживаемую ветку драйверов и срок жизни конкретной серии GPU;
- совместимость именно с вашей версией VMware vSphere, Red Hat KVM, Citrix или другого гипервизора;
- ограничения профилей: сколько экземпляров можно создать, какие профили можно смешивать, сколько vGPU поддерживается на одну виртуальную машину;
- особые замечания и известные проблемы в release notes для выбранной ветки драйвера;
- модель лицензирования NVIDIA AI Enterprise и её влияние на экономику сервиса.
Опираться нужно не на обзоры и презентации, а на четыре класса документов: матрица поддерживаемых GPU, матрица поддерживаемых продуктов, release notes выбранной ветки и официальное руководство по лицензированию.
После vGPU логично перейти к MIG. У него уже другая философия: не делить время одного устройства между всеми, а физически разрезать само устройство на независимые экземпляры.
NVIDIA MIG: жёсткие экземпляры и предсказуемая задержка
MIG ценят там, где важнее всего предсказуемость. Технология позволяет делить один GPU на несколько аппаратно изолированных экземпляров с выделенными вычислительными блоками, памятью и частью внутренних ресурсов. Именно поэтому она особенно уместна для инференса, где нарушение задержки 99-го процентиля часто опаснее, чем умеренная потеря средней производительности.
Преимущество MIG в том, что он уменьшает влияние соседей друг на друга. Исследования и практические материалы NVIDIA и облачных провайдеров показывают, что аппаратное разделение помогает сокращать долю нарушений целевых показателей и удерживать задержку более ровной под многопользовательской нагрузкой.
Схема физического разделения вычислительных ресурсов GPU при использовании технологии Nvidia MIG. Источник: .
Однако и у MIG есть цена. Он не даёт "любую удобную долю" GPU, а работает только с заранее определёнными профилями. Это хорошо для предсказуемости, но неудобно для коммерческого облака, где спрос у клиентов редко совпадает с красивыми долями вроде 1g, 2g или 3g. Отсюда появляется фрагментация: часть ресурса остаётся невостребованной просто потому, что доступные профили не складываются в нужную форму.
Вторая проблема связана с перенастройкой. MIG хорош в стабильной конфигурации, но менее удобен там, где состав нагрузки быстро меняется. Изменение профиля обычно требует остановки процессов и переинициализации конфигурации, а в некоторых управляемых средах даже пересоздания пула узлов. Об этих нюансах мы уже рассказывали в материале посвященному NVIDIA MIG.
Именно поэтому MIG чаще всего выбирают тогда, когда оператор заранее знает характер нагрузки: например, поток типовых инференс-задач, где важны изоляция и повторяемость поведения. Если же облако живёт в режиме постоянного пересмотра профилей под разные заявки, то эксплуатационная цена жёстких экземпляров быстро становится заметной.
Официальная поддержка NVIDIA MIG в 2026 году
По официальной документации NVIDIA, MIG поддерживается на архитектуре Ampere и новее, в том числе на A30, A100 и H100, с различиями по версиям CUDA и драйверов. Поддержка более ранних поколений в используемых официальных таблицах не подтверждена.
В Kubernetes MIG поддерживается через официальный механизм для устройств GPU и через GPU Operator, который умеет управлять конфигурацией MIG на узлах. При этом сама модель работы остаётся строгой: профили нужно планировать заранее, а не рассчитывать, что их будет удобно менять "на лету" без влияния на сервис.
После MIG остаётся третий путь. Если vGPU делает ставку на виртуализацию, а MIG на аппаратные экземпляры внутри одного GPU, то SR-IOV идёт дальше и стремится дать виртуальной машине почти прямой доступ к устройству.
SR-IOV и AMD MxGPU: максимум изоляции, максимум требований к платформе
SR-IOV привлекателен тем, что сочетает сильную изоляцию с производительностью, близкой к прямому пробросу устройства. В этом режиме GPU предоставляет виртуальные функции PCIe, а виртуальные машины получают доступ к ним почти без тяжёлой промежуточной прослойки. Поэтому SR-IOV особенно интересен там, где оператор хочет предоставить арендаторам виртуальные машины с максимально предсказуемым поведением GPU.
Но это же делает его самым требовательным вариантом. Для SR-IOV мало просто купить подходящий ускоритель. Нужны поддержка в BIOS, корректная настройка IOMMU, совместимый гипервизор, согласованные драйверы на хосте и в гостевой системе, а также подтверждённая матрица совместимости от вендора. В отличие от более "мягких" схем, здесь ошибка в одном слое быстро ломает всю конструкцию.
Именно поэтому SR-IOV выглядит не как универсальный ответ для всех, а как путь для тех, кто готов к дисциплине в инфраструктуре. При правильной платформе это очень сильный вариант. При хаотичном процессе обновлений он быстро превращается в источник трудных для диагностики проблем.
Текущий статус SR-IOV и MxGPU для AMD Instinct в 2026 году
В экосистеме AMD роль SR-IOV выполняет MxGPU, а важным шагом последних лет стало открытие исходного кода драйвера GIM, который отвечает за виртуализацию ускорителей Instinct. Это усилило интерес к сценарию, где оператор получает не только аппаратную виртуализацию, но и более прозрачную программную основу без отдельной дорогой лицензии поверх железа.
Описание особенностей технологии AMD MxGPU. Источник: .
По актуальной документации AMD и связанным официальным материалам, поддержка виртуализации заявлена для ряда ускорителей Instinct и некоторых профессиональных моделей, включая MI210X, MI300X, MI325X, MI350X, MI355X и Radeon Pro V710. Базовый и лучше всего подтверждённый сценарий – KVM и QEMU на Linux.
Что важно иметь ввиду:
- Поддержка VMware согласно актуальным официальным материалам AMD сильно ограничена;
- Расширение полноценной виртуализации на широкий набор потребительских карт Radeon в этих источниках тоже не подтверждено;
- Каждый сценарий нужно дополнительно сверять с конкретной версией ROCm и операционной системы.
Именно поэтому AMD MxGPU в 2026 году выглядит как интересный и перспективный путь для облаков на KVM, особенно там, где важны открытость и контроль над стеком. Но по зрелости экосистемы и широте готовых интеграций этот путь всё ещё требует большего внимания со стороны команды эксплуатации. Его мы освещали в отдельном материале, посвящённом AMD MxGPU.
Теперь, когда три модели разобраны по отдельности, можно собрать их в одну практическую матрицу.
Сравнительная матрица и выбор под типовые сценарии
Матрица сравнения vGPU, MIG и SR-IOV
| Критерий | vGPU | MIG | SR-IOV |
|---|---|---|---|
| Изоляция памяти и вычислений | В основном программная, с общими вычислительными ресурсами по времени. | Аппаратная изоляция памяти, части вычислительных блоков и внутренних ресурсов. | Аппаратная изоляция через виртуальные функции PCIe и IOMMU. |
| Изоляция при сбоях | Сброс чаще затрагивает всех соседей на GPU. | Область последствий лучше ограничена экземпляром MIG. | Сильная изоляция на уровне виртуальной функции и платформы. |
| Задержка и качество обслуживания | Под высокой нагрузкой возможны пики и нестабильность из-за разделения по времени. | Более предсказуемая задержка, лучше подходит для чувствительного к задержке инференса. | Поведение близко к выделенному устройству при корректной настройке платформы. |
| Накладные расходы | Зависят от плотности размещения и профиля нагрузки, но есть цена виртуализации и планирования по времени. | Обычно невелики, так как разделение аппаратное. | Минимальны по сравнению с более тяжёлой виртуализацией. |
| Безопасность при многоарендности | Приемлемая, но без столь жёсткой аппаратной границы, как у MIG и SR-IOV. | Высокая, так как экземпляры разделены аппаратно. | Высокая при корректной конфигурации IOMMU и гипервизора. |
| Совместимость с виртуализацией | Сильная сторона решения, особенно для VMware и корпоративных сценариев. | Хорошо подходит контейнерным средам и сценариям на Kubernetes. | Сильно зависит от конкретного вендора и матрицы совместимости. |
| Управление и квоты | Удобно для профилей виртуальных машин, но требует лицензирования и строгой проверки версий. | Жёсткие профили, меньше гибкости, возможна фрагментация ресурсов. | Управление сложнее и сильнее завязано на платформу.instinct. |
| Наблюдаемость и учёт | Хорошо вписывается в привычную виртуализацию, но тонкий учёт всё равно требует дисциплины. | Метрики на уровне экземпляров лучше подходят для учёта долей GPU. | Возможности зависят от связки гипервизора и драйверов. |
| Ограничения | Стоимость лицензий, нестабильность задержки под AI-нагрузкой, зависимость от матрицы совместимости. | Жёсткие профили, фрагментация, перенастройка с остановкой сервиса. | Жёсткие требования к BIOS, IOMMU, гипервизору и версиям драйверов. |
| Стоимость владения | Может заметно расти из-за NVIDIA AI Enterprise. | Обычно проще по лицензированию, если достаточно возможностей MIG без vGPU-надстройки. | Может быть выгодным по лицензированию, но дорогим по инженерной сложности. |
В сухом остатке картина выглядит так.
vGPU хорош там, где важнее совместимость и плотность виртуальных машин.
MIG предпочтительнее там, где необходима предсказуемость задержки и изоляция внутри AI-облака.
А SR-IOV хорошо покажет себя там, где организация готова платить инженерной дисциплиной за почти прямой доступ к GPU и сильную аппаратную изоляцию.
Отметив то что важно для вас в чек-листе из начала статьи, и сопоставив ответы с матрицей. Вы запросто выявите для себя самый выгодный продукт.
Заключение
Единого универсального решения не существует. В каждой платформе вас караулят свои недостатки и преимущества. Выбор зависит лишь от необходимого вам набора качеств. У каждой платформы он свой: где-то предсказуемость и изоляция, где-то гибкость и плотность размещения, а где-то простота внедрения и экономика. Поэтому выбирать стоит ту, чьи качества точнее всего совпадают с вашими задачами, требованиями к задержке, модели эксплуатации и бюджету.
