Основные выводы

Гипервизор с пробросом GPU превращает аппаратное обеспечение AMD в частное облако графических процессоров — развернутое локально, управляемое через API и подходящее для изолированных (air-gapped) сред.
Процессоры AMD Ryzen™ AI Max объединяют конфигурации с большим объемом унифицированной памяти и встроенной графикой Radeon™, что позволяет локально запускать модели, для которых традиционно требуется память GPU рабочего класса. Та же техника проброса применима и к дискретным видеокартам Radeon™ AI PRO.
Именно уровень гипервизора делает аппаратное обеспечение GPU практически полезным в больших масштабах. Шаблоны виртуальных машин, снимки состояния (снапшоты), клонирование и REST API позволяют создавать эфемерные сборщики CI, изолированные среды разработки, многопользовательские вычислительные системы и лаборатории искусственного интеллекта самообслуживания — не теряя контроля над своими данными или инфраструктурой.

Введение

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

Процессоры AMD Ryzen™ AI Max+ 395 (Strix Halo) объединяют процессорные ядра Zen 5, мощный графический процессор RDNA 3.5 Radeon и архитектуру с большой емкостью унифицированной памяти в компактном корпусе. Системы Strix Halo поддерживают до 128 ГБ унифицированной памяти LPDDR5X, что позволяет запускать модели с количеством параметров до 128 миллиардов при 4-битной квантизации. Новая платформа AMD Ryzen™ AI Max+ PRO 495 (Gorgon Halo) поднимает планку памяти до 192 ГБ и может поддерживать модели, превышающие 300 миллиардов параметров при 4-битной квантизации. Та же техника проброса GPU, описанная в этом руководстве, применима и к дискретным графическим процессорам Radeon AI PRO, которые обеспечивают выделенную видеопамять (VRAM) и пропускную способность PCIe для рабочих нагрузок, превышающих возможности одного гибридного процессора (APU).

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

Виртуализация меняет эту модель. Гипервизор может изолировать рабочие нагрузки в виртуальных машинах, в то время как VFIO передает физический GPU непосредственно в ВМ. Гостевая система (ВМ) получает прямой доступ к физическому устройству и запускает программный стек AMD ROCm™ на реальном оборудовании AMD. Гипервизор обеспечивает инфраструктурный уровень вокруг этого GPU:

клонирование виртуальной машины из проверенного шаблона
создание снапшота перед обновлением драйвера
подготовка изолированной среды для задания CI
уничтожение виртуальной машины по завершении задания
управление жизненным циклом через API

В этом руководстве демонстрируется такая архитектура с использованием Proxmox VE, платформы виртуализации на базе KVM/QEMU. В нем описан полный путь от настройки хоста до рабочей ВМ под управлением ROCm и PyTorch на проброшенном графическом процессоре AMD. Инструкции охватывают как встроенную графику Radeon на процессорах Ryzen AI Max, так и дискретные GPU Radeon, с пояснениями в тех местах, где эти два пути расходятся.

Проверенные конфигурации

Эта процедура была проверена от начала и до конца как для конфигурации со встроенным, так и с дискретным графическим процессором:

Конфигурация с iGPU

Конфигурация с dGPU

Хост

AMD Ryzen™ AI Max+ 395

AMD Ryzen™ Threadripper PRO 9965WX

GPU

Radeon™ 8060S (gfx1151, встроенный)

4x Radeon™ AI PRO R9700 (gfx1201, дискретный)

Память

64 ГБ LPDDR5X

128 ГБ DDR5

Гипервизор

Proxmox VE 9.1

Гостевая ОС

Ubuntu 24.04 HWE (7.0.0-34-generic)

ROCm

7.2

PyTorch

2.9.1+rocm7.2

Идентификаторы PCI-устройств и адреса шины будут различаться в зависимости от платформы и артикула (SKU).

Когда виртуализация имеет смысл (а когда — нет)

Используйте гипервизор, когда:

CI/CD требует чистого состояния для каждого задания. Клонируйте эталонный шаблон ВМ, запустите задание, уничтожьте клон. Никакого накопленного состояния, никаких нестабильных сборок из-за оставшихся артефактов. Это архитектура, лежащая в основе эфемерных систем CI, которые выделяют исполнители (runners) с GPU по требованию.
Несколько команд совместно используют оборудование. ВМ обеспечивают изоляцию, лимиты ресурсов и контроль доступа, не предоставляя каждому пользователю права root на хосте.
Вам нужен откат (rollback). Тестируете обновление ROCm, обновление ядра или новый драйвер? Сначала сделайте снапшот ВМ. Если обновление нарушает работу стека GPU, выполните откат за секунды, вместо того чтобы тратить часы на переустановку системы.
Вы управляете парком машин. Proxmox предоставляет веб-интерфейс, REST API и интерфейс командной строки (CLI) для операций с жизненным циклом ВМ на множестве хостов. В больших масштабах это значительно проще, чем подготовка "голого железа".

Используйте "голое железо", когда:

Вы являетесь единственным пользователем на одном компьютере, выполняющим интерактивные рабочие нагрузки
Максимальная производительность важнее воспроизводимости или изоляции
В системе только один GPU, и вам необходим доступ к GPU со стороны хоста

Обратите внимание, что проброс VFIO является монопольным: когда GPU назначен виртуальной машине, хост Proxmox не может одновременно использовать этот GPU для собственных рабочих нагрузок. Хост становится машиной плоскости управления, а ВМ владеет ускорителем.

Как насчет контейнеров?

Docker и Podman могут получать доступ к GPU AMD через --device=/dev/kfd --device=/dev/dri, и для многих рабочих нагрузок это более простой путь. Но контейнеры используют общее ядро хоста и драйвер GPU, а для CI и многопользовательских сценариев это создает реальные проблемы:

Отсутствие изоляции сбоев GPU. Если рабочая нагрузка зависает на GPU или вызывает сброс драйвера внутри контейнера, это приводит к сбою каждого другого контейнера, использующего этот GPU, и потенциально хоста. В случае с ВМ зависание GPU локализовано внутри гостевой системы. Завершите работу ВМ, VFIO освободит устройство, и хост останется невредимым.
Отсутствие изоляции памяти GPU. Графические процессоры AMD не имеют аппаратного разделения памяти. Все контейнеры борются за один и тот же пул VRAM. Один контейнер, выделяющий память слишком агрессивно, может вызвать ошибку OOM (Out of Memory) для рабочей нагрузки другого контейнера без предупреждения.
Состояние драйвера сохраняется между запусками. Модуль ядра amdgpu накапливает состояние — контексты микропрограмм, таблицы страниц, очереди команд. "Чистый" контейнер все равно наследует все, что драйвер накопил от предыдущих рабочих нагрузок. Для CI это означает, что результаты тестов могут зависеть от того, что выполнялось ранее. С VFIO гостевая система загружает собственный драйвер с нуля при каждой загрузке.
Вы не можете менять ядро или драйвер. Каждый контейнер использует модуль amdgpu и версию ROCm хоста. Если вам нужно протестировать разные версии ROCm или проверить обновление ядра, контейнеры не помогут.
Только Linux. Контейнеры — это конструкция ядра Linux. Если вам нужны рабочие нагрузки GPU в Windows или WSL2 — инференс DirectML, проверка драйверов Windows, тестирование ONNX Runtime — контейнеры не подходят.

Эти два подхода не являются взаимоисключающими. Распространенный паттерн — запуск контейнеров внутри ВМ с пробросом VFIO: ВМ обеспечивает аппаратную изоляцию и чистое состояние устройства, в то время как контейнеры внутри нее занимаются упаковкой приложений.

Что вам понадобится

Аппаратное обеспечение

Компонент

Требование

Процессор

Процессор AMD с поддержкой SVM и IOMMU

GPU

Дискретный GPU AMD (Radeon RX 7000+) или процессор AMD Ryzen AI со встроенной графикой Radeon

Память

Достаточный объем для выделения как хосту, так и гостевым системам

Программное обеспечение

Компонент

Версия

Гипервизор

Proxmox VE 8.x или 9.x

Гостевая ОС

Ubuntu 24.04 LTS (требуется ядро HWE)

ROCm

7.2

PyTorch

2.9.x с пакетами ROCm из repo.radeon.com

Установка Proxmox VE: Если Proxmox еще не установлена: скачайте ISO с proxmox.com/en/downloads, запишите его на USB-накопитель с помощью такого инструмента, как Rufus (Windows) или dd (Linux/macOS), и загрузитесь с него. Во время установки вам будет предложено выбрать файловую систему (ext4 или ZFS) и способ загрузки (GRUB или systemd-boot). Для большинства конфигураций с одним диском ext4 с GRUB — самый простой выбор. ZFS предлагает встроенные снимки и целостность данных, но использует больше памяти. Выберите загрузку UEFI, если ваша система ее поддерживает. После установки перейдите к веб-интерфейсу Proxmox по адресу https://<host-ip>:8006 и войдите в систему под учетной записью root с паролем, заданным во время установки.

О пробросе VFIO (VFIO Passthrough)

VFIO (Virtual Function I/O) связывает устройство PCIe исключительно с одной виртуальной машиной. Гостевая ОС загружает нативные драйверы и обращается к железу напрямую — гипервизор не участвует в обработке команд/данных GPU во время вычислительных операций. Современные GPU от AMD имеют как минимум две функции PCIe: контроллер дисплея/VGA и аудиоконтроллер HDMI/DP. Для конфигураций Radeon, рассматриваемых в этом руководстве, пробрасывайте функцию дисплея графического процессора и сопутствующую аудиофункцию вместе.

Часть 1: Конфигурация хоста

Шаг 1 -- Настройка BIOS/UEFI

Эти параметры обычно находятся в меню AMD CBS или Advanced CPU/PCI. Точное расположение зависит от производителя материнской платы.

Включите SVM (AMD Secure Virtual Machine / AMD-V)
Включите IOMMU (часто находится в меню AMD CBS, NBIO или Common Options)
Сохраните настройки и перезагрузите систему

Шаг 2 -- Включение IOMMU в ядре

В терминале Proxmox (доступен через вкладку Shell в веб-интерфейсе или по SSH) отредактируйте конфигурацию GRUB:

Для проброса дискретного GPU:

Для проброса встроенного GPU (iGPU) на Ryzen AI:

Параметры:

amd_iommu=on включает IOMMU от AMD
iommu=pt устанавливает режим pass-through (проброс), снижая нагрузку для устройств, которые не пробрасываются
video=efifb:off (только для iGPU) запрещает хосту использовать кадровый буфер (framebuffer) iGPU, что могло бы помешать VFIO связаться с ним
initcall_blacklist=sysfb_init (только для iGPU) предотвращает подключение простого кадрового буфера ядра к iGPU во время ранней загрузки
amdgpu.isp=0 (только для iGPU) отключает подсистему ISP на Strix Halo, которая может мешать корректной привязке VFIO

Примените изменения и перезагрузите систему:

Убедитесь, что IOMMU активна:

Вы должны увидеть вывод, подтверждающий, что IOMMU включена и назначены группы устройств.

Шаг 3 -- Загрузка модулей VFIO при старте

Добавьте модули ядра VFIO, чтобы они загружались на раннем этапе процесса загрузки:

В качестве альтернативы модули можно перечислить по одному в строке в /etc/modules. Оба подхода эквивалентны; для наглядности здесь показан шаблон файла в -modules-load.d.

Пересоберите initramfs:

Примечание: Эта команда пересобирает образы для каждого установленного ядра и может занять несколько минут с большим объемом вывода. Это нормально.

Шаг 4 -- Идентификация графического процессора

Выведите список устройств PCI от AMD и запишите адреса шины и пары идентификаторов vendor:device:

Пример дискретного GPU (Radeon™ AI PRO R9700):

Пример интегрированного GPU (Strix Halo):

Обратите внимание на разницу: дискретные GPU отображаются как VGA compatible controller [0300], в то время как iGPU Strix Halo отображается как Display controller [0380].

Запишите оба идентификатора vendor:device (например, 1002:744a,1002:ab30 или 1002:1586,1002:1640). Вы будете использовать их на следующем шаге.

Шаг 5 -- Добавление драйверов хоста GPU в черный список

Запретите хосту загружать драйверы GPU до того, как VFIO сможет привязаться к устройству:

Это гарантирует, что модуль ядра amdgpu не загрузится на хосте и не станет конкурировать с VFIO за устройство.

Шаг 6 -- Привязка GPU к VFIO

Создайте конфигурацию VFIO с идентификаторами vendor:device вашего GPU:

Замените VVVV и AAAA на идентификаторы, записанные на Шаге 4.

Пересоберите initramfs и перезагрузите систему:

Проверка привязки VFIO

После перезагрузки убедитесь, что vfio-pci управляет обеими функциями GPU:

Для каждой функции вы должны увидеть Kernel driver in use: vfio-pci. Появление строчки Kernel modules: amdgpu в качестве доступных, но не используемых (not in use), является нормальным:

Часть 2: Создание виртуальной машины

Шаг 7 -- Загрузка ISO-образа Ubuntu

ISO-образ Desktop предоставляет графический интерфейс для первоначальной проверки. ISO-образ Server подходит, если вы предпочитаете гостевые системы без графической оболочки (headless).

Шаг 8 -- Создание виртуальной машины

В веб-интерфейсе Proxmox (https://<host-ip>:8006) нажмите Create VM и укажите следующие настройки:

Настройка

Значение

Примечания

Машина (Machine)

q35

Требуется для проброса PCIe

BIOS

OVMF (UEFI)

Требуется для проброса PCIe

Тип CPU (CPU type)

host

Предоставляет гостевой системе все возможности процессора; требуется для ROCm

SCSI-контроллер

VirtIO SCSI single

Лучшая производительность для виртуальных дисков

Кэш диска (Disk cache)

Write back

Обычно оптимально; настраивается под конкретное хранилище

Discard/TRIM

Включено (Enabled)

Рекомендуется для дисков с динамическим выделением памяти (thin-provisioned)

Поток ввода-вывода (IO thread)

Включено (Enabled)

Снижает задержки при операциях с диском

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

Шаг 9 -- Подключение GPU

Выберите виртуальную машину и перейдите на вкладку Аппаратное обеспечение (Hardware)
Нажмите Добавить (Add), затем PCI Device, затем Raw Device
Выберите функцию дисплея GPU (ту, которая привязана к vfio-pci)
Все функции (All Functions): отмечено галочкой (автоматически подключает сопряженную аудиофункцию)
PCI-Express: отмечено галочкой
Основной GPU (Primary GPU): оставьте пустым во время установки (чтобы консоль noVNC оставалась доступной)
Убедитесь, что в списке оборудования появился параметр hostpci0 с pcie=1

Если список устройств пуст или отображает GPU как «используемый» (in use) драйвером amdgpu, вернитесь к Шагам 5–6. Обе функции должны отображать vfio-pci в качестве активного драйвера.

Шаг 10 -- Установка гостевой ОС

Запустите виртуальную машину и откройте вкладку Консоль (Console)
Установите Ubuntu, выбрав «Стереть диск и установить» (Erase disk and install) — это применимо только к виртуальному диску самой ВМ
После завершения установки перезагрузите систему по запросу

Проверка после установки внутри ВМ:

Часть 3: ROCm и PyTorch в гостевой системе

Когда GPU станет виден в гостевой системе, установите стек вычислений.

Шаг 11 -- Установка ROCm

Важно: Сначала установите ядро HWE. Метод установки --no-dkms, используемый ниже, опирается на встроенный в гостевое ядро драйвер amdgpu. Ядро Ubuntu 24.04 по умолчанию (6.8.0), а также облачное/минимальное ядро не включают модуль amdgpu. Ядро HWE (Hardware Enablement) поставляется с ядром 7.0.0+ со встроенным amdgpu. Без него ROCm установится, но использовать GPU будет нельзя.

Если вы устанавливали систему из ISO-образа Desktop, у вас, скорее всего, уже установлено ядро HWE. Для Server или облачных образов установите его явно:

После перезагрузки убедитесь, что активно ядро HWE:

Установите необходимые для сборки компоненты:

Примечание: dkms устанавливается здесь как зависимость, требуемая пакетом установщика ROCm, несмотря на то, что на следующем шаге используется флаг --no-dkms.

Установите стек ROCm 7.2:

Флаг --no-dkms предотвращает сборку и установку установщиком ROCm внешнего ядра AMDGPU через DKMS. Проброшенный графический процессор по-прежнему определяется гостевой системой как устройство PCI, а встроенный в ядро гостевой системы драйвер amdgpu (поставляемый с ядром HWE) управляет им. Компоненты пользовательского пространства ROCm затем взаимодействуют с GPU через интерфейсы, предоставляемые драйвером ядра (/dev/kfd, узлы рендеринга DRM и т.д.).

Добавьте своего пользователя в необходимые группы:

Важно (только для iGPU): После установки ROCm на конфигурацию с пробросом iGPU остановите виртуальную машину с хоста (qm stop <vmid>), а затем перезагрузите весь хост Proxmox. Перезагрузки только гостевой системы недостаточно — хост должен заново инициализировать привязку устройства VFIO, чтобы ROCm корректно обнаружил GPU при следующем запуске ВМ.

Без перезагрузки хоста вы столкнетесь с частичным сбоем: amdgpu загружается в гостевой системе, и появляется /dev/kfd, но /dev/dri отсутствует. В системном журнале ядра появится информация о сбое драйвера во время gmc_v11_0_sw_fini (деинициализация контроллера памяти). Решением является полная перезагрузка хоста.

Для конфигураций с дискретным GPU достаточно перезагрузить гостевую систему.

Проверка ROCm

После перезагрузки (перезагрузка хоста для iGPU, перезагрузка гостевой системы для dGPU) и запуска виртуальной машины:

Пример вывода для iGPU (сокращенно):

Пример вывода для dGPU (сокращенно):

Появление GPU в качестве агента с именем и целевым gfx-чипом подтверждает, что ROCm может взаимодействовать с проброшенным GPU.

Примечание: rocminfo может указывать коммерческое наименование, немного отличающееся от заявленного в системе артикула (SKU), в зависимости от версии прошивки и версии ROCm. Авторитетным идентификатором является целевой идентификатор gfx.

Шаг 12 — Установка PyTorch

AMD предоставляет протестированные пакеты ROCm на repo.radeon.com. Они рекомендуются вместо пакетов с сайта pytorch.org, которые часто меняются в ночных сборках и не проходят тщательную проверку со стороны AMD.

Создайте окружение Python и установите проверенные пакеты:

Проверьте матрицу совместимости ROCm для поиска последних версий пакетов, соответствующих вашим версиям Python и ROCm.

Проверка PyTorch

Ожидаемый результат: Available: True и имя устройства, соответствующее вашему GPU.

В PyTorch torch.cuda является универсальным API для доступа к GPU. На оборудовании AMD с ROCm запросы перенаправляются через HIP. Аппаратное обеспечение CUDA не требуется.

Примечания к производительности

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

В системе Strix Halo системная память физически разделяется между CPU и GPU, а не является выделенной видеопамятью (VRAM). Объем памяти, доступный для проброшенного GPU, зависит от выделенной в BIOS зоны UMA и конфигурации GTT. Для задач LLM, где емкость и пропускная способность памяти имеют критическое значение, настройка выделенной памяти UMA в BIOS и параметров GTT ядра (amdgpu.gttsize, ttm.pages_limit) может значительно увеличить объем памяти, доступный GPU.

Часть 4: От виртуальной машины к инфраструктуре

Одна виртуальная машина с проброшенным GPU — это полезно. Реальная ценность заключается в превращении одной рабочей ВМ в целый парк.

Клонирование шаблонов

После того как у вас появится полностью настроенная виртуальная машина (ОС, ROCm, PyTorch, зависимости), превратите ее в шаблон:

Клонируйте ее для создания идентичных окружений:

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

В системах с несколькими GPU (или нескольких хостах с одним GPU на каждом) назначьте разные GPU каждому клону, отредактировав его конфигурацию:

Управление на основе API

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

Это основа для эфемерных агентов CI на оборудовании AMD. Интерфейс командной строки qm предоставляет те же операции для написания скриптов:

Управление парком оборудования

Для стойки систем Strix Halo или смешанного парка хостов с APU и дискретными GPU Proxmox обеспечивает централизованное управление с помощью функций кластера. Каждый хост добавляет свои графические процессоры в общий пул. Оркестратор распределяет задачи по доступному оборудованию в зависимости от типа GPU, метки или емкости.

Практический пример: система DevLab Dispatch выполняет эфемерную CI для проектов с открытым исходным кодом на оборудовании AMD, используя ровно эту архитектуру — виртуальные машины Proxmox с проброшенными GPU, которые подготавливаются для каждой задачи и уничтожаются после ее завершения.

Устранение неполадок

Краткая справочная информация

Сноски

Конфигурация для тестирования: AMD Ryzen™ AI MAX+ 395 / Radeon 8060S (gfx1151), 128 ГБ LPDDR5X, Proxmox VE 9.x, гостевая ОС Ubuntu 24.04 HWE, ROCm 7.2, PyTorch 2.9.1. Проброс iGPU через VFIO с включенной IOMMU. Те же шаги настройки хоста применимы к дискретным GPU Radeon; идентификаторы устройств PCI и адреса шины будут различаться в зависимости от платформы.