Одна GPU на несколько VM: vGPU, MIG или passthrough

Короткий ответ

Отдать одну GPU нескольким VM можно тремя способами, и путать их дорого. Полный проброс PCI (VFIO passthrough) отдаёт карту одной машине целиком и больше никому. NVIDIA vGPU режет карту на профили средствами хостового драйвера: это отдельный лицензируемый продукт, а не флажок в настройках гипервизора. MIG (Multi-Instance GPU) делит сам кристалл на изолированные экземпляры, и умеют это далеко не все карты. Есть и четвёртый путь, для инференса обычно самый разумный: не делить карту вообще, отдать её одной VM и разводить пользователей уже внутри, силами vLLM или Ollama.

Если у вас одна L40S и четыре виртуалки, которые все хотят ускоритель, правильный ответ зависит от того, что в этих виртуалках крутится. Дальше разберём, чем механизмы отличаются физически, как проверить по документации NVIDIA возможности именно вашей карты, что требуется для vGPU кроме драйвера, и как всё это выглядит на Proxmox VE 9.2.

Одна GPU на несколько VM: чем три механизма отличаются физически

Проброс PCI работает на уровне IOMMU (input/output memory management unit, блок трансляции адресов для устройств). Хост отвязывает карту от своего драйвера, привязывает к vfio-pci и отдаёт её адресное пространство гостю. Гость видит настоящую L40S и ставит обычный драйвер NVIDIA. Хост картой больше не распоряжается: она занята, пока живёт VM. Производительность равна bare metal, лицензировать нечего, гибкости ноль.

vGPU работает на уровне хостового драйвера. На хост ставится пакет vGPU Manager, и он создаёт виртуальные устройства с фиксированным кадровым буфером. Машине достаётся профиль вида L40S-8Q: 8 ГБ видеопамяти и доля машинного времени SM (streaming multiprocessor, вычислительный блок GPU). Память делится жёстко и не переподписывается. Вычислительные блоки делятся по времени, поэтому изоляции по производительности нет: соседняя VM, запустившая длинное ядро, задержит вашу.

MIG режет сам кристалл. Карта разбивается на GPU instances, и у каждого свои SM, своя доля кэша L2 и свои контроллеры памяти. Это не разделение по времени, а физическая перегородка: сосед не может отобрать у вас пропускную способность памяти. Поэтому MIG предсказуем там, где time slicing плавает. Плата за предсказуемость: резать можно только по фиксированной сетке профилей, и карта обязана такое уметь.

Что умеет именно ваша карта: три документа NVIDIA

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

Первый документ: "NVIDIA Virtual GPU Software Supported GPUs" на docs.nvidia.com/vgpu/gpus-supported-by-vgpu.html. Он отвечает ровно на один вопрос: поддерживает ли карта vGPU хоть в каком-нибудь релизе. В таблице есть Tesla M10 и M60, Pascal P100, P40, P4, P6, Volta V100, Turing T4 и Quadro RTX 6000/8000, Ampere A2, A10, A16, A40, Ada L2, L4, L20, L40, L40S, а также карты RTX PRO Blackwell. Старая Tesla, которая всё ещё стоит в стойке, скорее всего в списке есть. GeForce в списке нет, и это не придирка лицензии, а отсутствие поддержки в коде драйвера.

Второй документ: "NVIDIA Multi-Instance GPU User Guide", раздел Supported GPUs. Правило там сформулировано коротко: MIG поддерживается начиная с поколения Ampere, на картах с compute capability не ниже 8.0. Поимённо перечислены A100 (SXM4 и PCIe), A30, H100 (SXM5, PCIe и в составе GH200), H20, H200, и дальше Blackwell: B200, GB200, RTX PRO 6000/5000/4500. L40 и L40S в этом списке отсутствуют. Для владельца L40S это главный вывод всей статьи про MIG: аппаратного деления на вашей карте не будет, потому что архитектура Ada его не реализует. Ни одна версия драйвера этого не добавит.

Третий документ: "Virtual GPU Software User Guide", раздел Virtual GPU Types Reference, где для каждой карты перечислены доступные профили. Для L40S там описаны Q-серия (рабочие станции), B-серия (виртуальные десктопы) и A-серия (виртуальные приложения). Счётные C-профили вынесены в отдельный комплект документации, NVIDIA AI Enterprise. На сентябрь 2026 актуальная ветка vGPU это 20.x.

Собирая вместе: A100 и H100 можно резать и по MIG, и по времени, а MIG-backed профили в документации AI Enterprise выглядят как A100-2-10C или A100-3-20C, то есть профиль привязан к конкретному GPU instance. L40S режется только по времени. Tesla V100 и T4 тоже только по времени, MIG на них не существует.

Сколько vGPU помещается в одну L40S

Профили нарезаются по кадровому буферу, и число одновременных vGPU получается делением 48 ГБ карты на размер профиля. Ниже Q-серия для L40S по таблице NVIDIA, с объёмами, переведёнными из мегабайт в гигабайты, в режиме равных профилей.

[
  {
    "label": "L40S-48Q",
    "fb_gb": 48,
    "max_per_gpu": 1
  },
  {
    "label": "L40S-24Q",
    "fb_gb": 24,
    "max_per_gpu": 2
  },
  {
    "label": "L40S-16Q",
    "fb_gb": 16,
    "max_per_gpu": 3
  },
  {
    "label": "L40S-12Q",
    "fb_gb": 12,
    "max_per_gpu": 4
  },
  {
    "label": "L40S-8Q",
    "fb_gb": 8,
    "max_per_gpu": 6
  },
  {
    "label": "L40S-6Q",
    "fb_gb": 6,
    "max_per_gpu": 8
  },
  {
    "label": "L40S-4Q",
    "fb_gb": 4,
    "max_per_gpu": 12
  },
  {
    "label": "L40S-3Q",
    "fb_gb": 3,
    "max_per_gpu": 16
  },
  {
    "label": "L40S-2Q",
    "fb_gb": 2,
    "max_per_gpu": 24
  },
  {
    "label": "L40S-1Q",
    "fb_gb": 1,
    "max_per_gpu": 32
  }
]

Всего в Q-серии для этой карты 10 профилей. Старший, L40S-48Q, забирает все 48 ГБ и существует в единственном экземпляре: это фактически тот же проброс, только через лицензируемый драйвер. Младший даёт 32 машин по 1 ГБ, что нормально для VDI и бессмысленно для любой модели.

Два правила важнее самих чисел. Первое: сумма профилей не может превысить физическую память карты, память не переподписывается, так что 48 ГБ это потолок, а не ориентир. Второе: в обычном режиме все vGPU на одной карте должны быть одного размера. Смешанные размеры (mixed-size) поддерживаются отдельно и с более низкими лимитами: в таблице NVIDIA у L40S-1Q в этом режиме уже не 32 машины, а 16.

Что требуется для vGPU кроме драйвера

Здесь инструкции обычно обрываются на "поставьте .run и готово", и это неправда.

vGPU это лицензируемый продукт. Нужны две вещи: хостовый пакет vGPU Manager и клиентская лицензия, которую гостевой драйвер получает по сети. Оба компонента раздаются через NVIDIA Licensing Portal по действующему entitlement, то есть по оплаченной подписке или пробному доступу. Свободной загрузки vGPU Manager не существует, и это не тот драйвер, который лежит в открытом разделе сайта NVIDIA.

Редакция лицензии зависит от нагрузки. Q-профили лицензируются как NVIDIA RTX Virtual Workstation, A-профили как Virtual Applications. Счётные C-профили идут под NVIDIA AI Enterprise, и правило в её документации сформулировано как одна лицензия на каждый vGPU, назначенный виртуальной машине. В выводе nvidia-smi внутри такой VM продукт называется NVIDIA Virtual Compute Server.

Выдаёт лицензии NVIDIA License System, и вариантов два. CLS (Cloud License Service) держит NVIDIA у себя: гостю нужен исходящий доступ к облаку NVIDIA по портам 443 и 80. DLS (Delegated License Service) это виртуальный сервер у вас в сети; в полностью отключённом от интернета варианте файлы лицензий вы скачиваете с портала руками и загружаете в DLS. Подробности в "NVIDIA License System User Guide" (DU-10195-001, ревизия v3.6.1 от июня 2026). Для закрытого контура выбор очевиден: DLS.

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

Valid GRID license not found. GPU features, and performance will be fully degraded.

В руководстве NVIDIA по диагностике лицензирования рядом перечислены сообщения Failed to acquire a license from local trusted store и Insufficient count for the requested feature. Первое чаще всего означает проблему связи с сервисом, второе означает, что лицензии просто кончились. Отдельная частая причина отказа: разъехалось время на госте, и запрос лицензии отклоняется. NTP внутри VM для vGPU обязателен, а если часы в ваших машинах уже ведут себя странно, сначала разберитесь, почему уплывают часы на виртуалке и как их синхронизировать, и только потом грешите на лицензию.

Если entitlement на vGPU получить негде

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

Практический вывод один: если entitlement недоступен, вычеркните vGPU на этапе проектирования, а не обнаруживайте это на этапе установки. Остаются проброс и мультиплексирование внутри одной VM. Оба ничего не стоят, и оба описаны ниже.

Есть и организационный нюанс. В списке гипервизоров, которые NVIDIA перечисляет как поддерживаемые, есть XenServer, Linux with KVM, Red Hat Enterprise Linux with KVM, Ubuntu, VMware vSphere ESXi, Nutanix AHV, Microsoft Windows Server и Azure Local. Proxmox VE там не назван. Сам Proxmox установку vGPU документирует и обращения в поддержку по ней принимает, но только при наличии действующего entitlement NVIDIA и активной подписки Proxmox. Если вы выбираете платформу с нуля, это стоит учесть заранее, наравне с остальными доводами в пользу своего гипервизора против готового VPS.

Как это выглядит на Proxmox VE 9.2

Версии на сентябрь 2026: Proxmox VE 9.2 (май 2026), Debian 13 Trixie в основе, ядро Linux 7.0, QEMU 11.0. Команды ниже взяты из официальной вики Proxmox, страница "NVIDIA vGPU on Proxmox VE". Выполняются на хосте, от root.

В прошивке сервера включите VT-d или AMD-v, SR-IOV, Above 4G decoding и ARI. Для Ampere и более новых карт это не опционально: vGPU на них реализован через виртуальные функции SR-IOV, и без ARI они не появятся.

apt install pve-nvidia-vgpu-helper
pve-nvidia-vgpu-helper setup

Хелпер делает подготовительную работу, включая занесение nouveau в чёрный список. Если nouveau уже был загружен, нужна перезагрузка. Дальше ставится хостовый драйвер, полученный с портала лицензий. Имя файла зависит от вашей ветки; в примере вики это NVIDIA-Linux-x86_64-525.105.14-vgpu-kvm.run, у вас будет своя версия.

chmod +x NVIDIA-Linux-x86_64-<версия>-vgpu-kvm.run
./NVIDIA-Linux-x86_64-<версия>-vgpu-kvm.run --dkms

На вопрос про регистрацию в DKMS отвечайте утвердительно, иначе модуль перестанет собираться после первого же обновления ядра. При включённом Secure Boot вики советует ставить с --skip-module-load и подписывать модули через DKMS отдельно. Если на этом шаге вы уже ловили Key was rejected by service, лечение описано в разборе отказа подписи модуля NVIDIA при Secure Boot.

После перезагрузки включаем виртуальные функции, причём постоянно. Вручную запущенный sriov-manage переживает только до перезагрузки, юнит systemd переживает её.

systemctl enable --now pve-nvidia-sriov@ALL.service
lspci -d 10de:

В выводе lspci рядом с физической картой должны появиться виртуальные функции. Дальше смотрим, какие профили доступны, и вешаем один на машину.

pvesh get /nodes/<node>/hardware/pci/<mapping>/mdev
qm set <vmid> -hostpci0 01:00.4,mdev=nvidia-660

Номер nvidia-660 это идентификатор профиля из предыдущей команды, у вашей карты он будет другим. Внутри гостя ставится гостевой драйвер строго той же ветки vGPU, что и хостовый: смешивать версии нельзя. Рассогласование даёт знакомую ошибку, разобранную в заметке про NVML Driver/library version mismatch. А если модуль вообще не поднимается после обновления ядра Proxmox, смотрите разбор того, почему сборка DKMS падает на новом ядре.

Для сравнения, MIG на A100 или H100 настраивается совсем другими командами и не требует vGPU вообще, если экземпляры нужны хосту или контейнерам, а не отдельным VM.

sudo nvidia-smi -i 0 -mig 1
nvidia-smi mig -lgip
nvidia-smi mig -cgi 9,9,9 -C

Смена режима MIG требует полной перезагрузки. И важное: включить режим мало. Пока не созданы GPU instances и compute instances внутри них, ни одна задача CUDA на карте не запустится.

Для LLM делить карту обычно не нужно

Теперь главное решение. Соблазн понятен: 48 ГБ, четыре команды, дадим каждой по 12 ГБ. Для языковых моделей это почти всегда проигрыш, и причина арифметическая.

Веса модели лежат в памяти каждой VM отдельно. Разрезав карту на четыре профиля по 12 ГБ, вы получаете четыре независимые копии весов и четыре независимых кэша KV. Модель на 70 миллиардов параметров даже в 4-битной квантовке в 12 ГБ не помещается, так что разрез просто закрывает вам доступ к моделям, которые карта тянула целиком. Дальше хуже: SM всё равно делятся по времени, а переключение контекста между четырьмя VM стоит такта, которых у вас и так не в избытке.

Правильная конструкция другая. Одна VM владеет картой целиком, через проброс или через профиль L40S-48Q, внутри работает vLLM или Ollama, и уже сервер инференса разводит пользователей. Веса лежат в памяти один раз. Continuous batching складывает запросы разных пользователей в один проход по весам, и при этом растёт не только загрузка SM, но и суммарная пропускная способность. Изоляция при этом переезжает на уровень выше: отдельные API-ключи, квоты, разные очереди. Сколько одновременных сессий вытянет конкретная карта, считается отдельно, и это разобрано в материале про число одновременных пользователей на своём LLM-сервере. Крутилки Ollama, которыми это настраивается на практике, описаны в разборе OLLAMA_NUM_PARALLEL и OLLAMA_MAX_QUEUE.

Есть ровно одно исключение: MIG на A100 или H100, когда вам нужна жёсткая гарантия задержки для нескольких независимых мелких моделей. Аппаратная перегородка даёт ту предсказуемость, которой батчинг не даёт. Но это про SLA, а не про пропускную способность: суммарный throughput у разрезанной карты будет ниже, чем у целой.

Когда деление действительно окупается

Деление начинает оправдывать сложность там, где нагрузки разнородные. Классический набор в одной стойке: машина с медиасервером, которой нужен кодировщик NVENC и полтора гигабайта памяти, машина разработчика с CUDA для сборки и отладки, и пара VDI-сессий для инженеров с CAD. Ни одна из них не выберет карту целиком, и ни одной не нужны все 48 ГБ. Вот здесь L40S-8Q на каждую это честный выигрыш.

Перед тем как закладывать такую схему, проверьте по таблице профилей в Virtual GPU Types Reference, какие возможности несёт выбранный профиль: число подключённых дисплеев и доступность кодировщиков от профиля зависят. Если медиасервер и есть основная причина затеи, сначала посмотрите, как устроено аппаратное транскодирование Jellyfin на NVIDIA: возможно, ему достаточно самого мелкого профиля, и всё остальное останется свободным.

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

Как выбрать за пять минут

Если карта не поддерживает vGPU по первому документу NVIDIA, выбор закончен: только проброс. Если entitlement недоступен, выбор тоже закончен: проброс или одна VM с сервером инференса. Если основная нагрузка это LLM, берите одну VM и батчинг, а карту не режьте. Если нагрузки разнородные и лицензия есть, берите vGPU. Если нужна гарантированная задержка для нескольких независимых задач и карта это A100, A30, H100, H200 или Blackwell, берите MIG.

Отдельный вариант, который стоит посчитать до закупки: не держать карту у себя. Аренда снимает и вопрос лицензии, и вопрос перегородок, и обзор вариантов есть в обзоре VPS с выделенной GPU. Экономику сравнения со своим железом считают в разборе стоимости сборки своего AI-сервера, а границу, за которой аренда проигрывает оплате токенов, в материале про точку безубыточности GPU-сервера против API.

FAQ

Поддерживает ли L40S технологию MIG?

Нет. В разделе Supported GPUs документа "NVIDIA Multi-Instance GPU User Guide" перечислены A100, A30, H100, H20, H200 и карты Blackwell, включая RTX PRO 6000/5000/4500. Архитектура Ada, к которой относятся L4, L40 и L40S, в списке отсутствует, и обновление драйвера этого не изменит. Делить L40S между VM можно только через vGPU с разделением по времени.

Можно ли использовать NVIDIA vGPU бесплатно?

Нет. vGPU Manager для хоста и клиентская лицензия для гостя раздаются через NVIDIA Licensing Portal по действующему entitlement, и в открытом доступе хостового драйвера нет. Без лицензии гостевой драйвер сначала стартует, а затем деградирует, оставляя в логе строку Valid GRID license not found. GPU features, and performance will be fully degraded. Редакция зависит от профиля: Q-профили покрываются RTX Virtual Workstation, счётные C-профили покрываются NVIDIA AI Enterprise.

Что выбрать для нескольких пользователей одной языковой модели?

Одну VM, которая владеет всей картой, и сервер инференса внутри неё. При разрезании карты каждая VM грузит свою копию весов и свой кэш KV, так что полезной памяти становится меньше в разы. Continuous batching в vLLM складывает запросы разных пользователей в один проход по весам и загружает SM плотнее, чем переключение контекста между виртуальными машинами. Разграничение пользователей делается ключами и квотами на уровне API, а не перегородками в железе.

Работает ли vGPU на Proxmox VE?

Технически да, и Proxmox документирует процедуру на странице "NVIDIA vGPU on Proxmox VE": пакет pve-nvidia-vgpu-helper, установка хостового драйвера с --dkms, юнит pve-nvidia-sriov@ALL.service для виртуальных функций и назначение профиля через qm set. При этом Proxmox VE не входит в список гипервизоров, которые NVIDIA перечисляет как поддерживаемые, а поддержка со стороны Proxmox требует и действующего entitlement NVIDIA, и активной подписки Proxmox.

Нужен ли SR-IOV для vGPU и почему он слетает после перезагрузки?

На картах архитектуры Ampere и новее vGPU реализован через виртуальные функции SR-IOV, поэтому в прошивке должны быть включены VT-d или IOMMU, SR-IOV и ARI. Включение виртуальных функций скриптом sriov-manage не сохраняется между перезагрузками по своей природе, и именно поэтому Proxmox предлагает юнит pve-nvidia-sriov@ALL.service. Включайте его через systemctl enable --now, иначе после планового обновления ядра профили просто исчезнут, а машины не стартуют.