VFIO и IOMMU для LLM: безопасный GPU passthrough в KVM

Полный passthrough: где проходит граница метода

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

Это принципиально иной сценарий, чем MIG или MPS для multi-tenant GPU. MIG режет поддерживаемый ускоритель на аппаратные экземпляры, MPS совместно планирует CUDA-контексты, а passthrough передаёт весь PCI-функционал гостю. Если две команды должны одновременно загружать один GPU, этот runbook решает не ту задачу.

Зато у метода есть сильная эксплуатационная граница: хост не загружает модель и не обслуживает CUDA workload. Команда закрепляет версии guest OS, драйвера и inference runtime внутри VM, меняет сетевой слой отдельно от физического сервера и точно знает владельца устройства. Проверяли ли вы, кто владеет картой во время инцидента? Ответ должен подтверждаться командами, а не названием VM.

• Выбирайте passthrough, если важны отдельное ядро гостя, независимый userspace и один владелец GPU.
• Не выбирайте, если обязательны live migration, прозрачный sharing или быстрый autoscaling на одном устройстве.
• Не путайте изоляцию DMA с полной безопасностью сервиса: сеть, секреты, образы и API требуют собственных контролей.

IOMMU group — минимальная единица доверия

VFIO строит безопасную передачу устройства вокруг IOMMU: она ограничивает DMA теми областями памяти, которые назначены владельцу. Но единицей владения является не обязательно один адрес PCI. Документация ядра определяет IOMMU group как минимальный набор устройств, который можно изолировать от остальных. Многофункциональный GPU, его audio-функция или мост без ACS могут оказаться в одной группе.

Отсюда первый жёсткий stop condition: нельзя передавать только графическую функцию и оставлять соседнюю функцию группы активному драйверу хоста. Группа не станет viable, а попытка «починить» её принудительным ACS override меняет модель доверия. В production лучше переставить карту в другой слот, выбрать подходящую серверную плату или передать весь безопасный набор.

Сначала снимите evidence bundle: адреса, vendor/device ID, kernel driver, NUMA node и состав группы. Не начинайте с изменения initramfs. На сервере с двумя одинаковыми GPU ошибка в одном символе BDF способна отключить карту, которая обслуживает живой endpoint.

GPU=0000:65:00.0
lspci -nnk -s "$GPU"
readlink -f "/sys/bus/pci/devices/$GPU/iommu_group"
for dev in /sys/bus/pci/devices/$GPU/iommu_group/devices/*; do
  bdf=$(basename "$dev")
  lspci -nnk -s "$bdf"
done
cat "/sys/bus/pci/devices/$GPU/numa_node"

Gate проходит, когда группа существует, её состав ожидаем, и ни один соседний device не нужен хосту для диска, сети или управления. Отрицательная проверка не менее важна: выберите соседний GPU и убедитесь, что он находится в другой группе. Официальное описание модели и перехода к IOMMUFD находится в документации Linux VFIO.

Подготовка хоста: evidence до первого detach

До остановки любого процесса зафиксируйте baseline. Нужны версия ядра, параметры загрузки, драйвер GPU, активные клиенты и состояние IOMMU. Сам факт появления каталога /sys/kernel/iommu_groups полезен, но не заменяет проверку журнала загрузки и конкретной группы.

Для Intel обычно включают VT-d, для AMD — AMD-Vi/IOMMU в firmware и kernel command line согласно дистрибутиву. Не копируйте параметры из случайного руководства: названия и дефолты меняются, а часть серверных платформ включает remapping автоматически. Здесь намеренно нет универсальной строки для GRUB; её надо сверить с документацией вашей ОС и платы.

uname -r
cat /proc/cmdline
journalctl -k -b | grep -Ei 'DMAR|IOMMU|AMD-Vi'
lspci -Dnnk | grep -A3 -Ei 'VGA|3D|Audio'
nvidia-smi
fuser -v /dev/nvidia* 2>/dev/null || true

Если на GPU работают exporter, persistence daemon или контейнер, graceful stop принадлежит владельцу этого сервиса. Принудительный unbind при живом CUDA-контексте превращает понятную подготовку в reset-инцидент. Зафиксируйте owner, окно работ и команду возврата ещё до detach.

Практический пример: monitoring показывает нулевую загрузку, но exporter держит device node. Метрика говорит «idle», а kernel driver всё ещё имеет клиента. Поэтому инфраструктурный gate проходит только после проверки процессов, driver binding и группы вместе.

Сохраните baseline в тикет работ: BDF, UUID, driver version, список функций и состояние модели. После rollback эти же данные станут эталоном. Без симметричного снимка до и после команда легко пропустит исчезнувшую функцию или изменившийся NUMA affinity.

Bind и libvirt: передача должна быть управляемой

В стабильной конфигурации libvirt может сам отсоединить PCI device от хоста перед запуском и вернуть после остановки домена. Для этого у hostdev задают managed='yes' и полный domain/bus/slot/function. Это лучше набора ручных echo в sysfs: lifecycle становится частью декларации VM, а не памятью дежурного.

Если GPU многофункциональный, добавьте все необходимые функции отдельными hostdev и проверьте их совместное владение. Для современных карт также важны UEFI guest и достаточное пространство BAR. NVIDIA предупреждает, что большие BAR могут потребовать настроек VM, а некоторые обходные параметры QEMU имеют experimental-статус; применяйте их только для подтверждённого кейса.

После изменения XML проверьте фактическое состояние, а не только сохранённый файл. virsh dumpxml показывает effective configuration домена, lspci -nnk — текущий driver хоста. Спецификация libvirt Domain XML описывает managed hostdev: устройство detach перед стартом и reattach после выхода гостя.

Stop condition прост: если перед запуском весь набор группы не готов к vfio или после старта хотя бы одна функция осталась у хостового драйвера, трафик к VM не подаётся. Расширять привилегии или включать unsafe no-IOMMU ради зелёного старта нельзя: это убирает саму границу DMA.

Отдельно задокументируйте, кто может менять XML и запускать домен. Доступ к libvirt для passthrough фактически даёт управление физическим устройством. Это не обычная настройка приложения, поэтому privilege boundary должна быть узкой и журналируемой.

Старт VM: сначала PCI и reset, потом CUDA

Первый запуск делайте без production-трафика и без автоматического старта LLM. Сначала гостевая ОС должна увидеть правильные PCI ID, а хост — перестать владеть устройством. Так вы отделяете сбой assignment от проблем драйвера и приложения.

virsh start llm-vfio-01
virsh domstate llm-vfio-01
virsh dumpxml llm-vfio-01 | sed -n '//p'
lspci -nnk -s 0000:65:00.0
# В госте:
lspci -nnk | grep -A3 -Ei 'VGA|3D|NVIDIA'

Если домен не стартует, сохраните ошибку libvirt, kernel log и состав группы до перезапуска. Типичные причины лежат в четырёх слоях: часть IOMMU group занята, BAR не помещается в адресное пространство гостя, device reset не поддержан в текущем lifecycle или адрес в XML неверен. Менять одновременно firmware, XML и driver version — плохой эксперимент: после такого вы не узнаете, что помогло.

Успешный старт тоже нужно попытаться опровергнуть. На хосте nvidia-smi не должна показывать переданную карту; в госте BDF и device ID должны соответствовать baseline. Если один accelerator одновременно «виден» обоим драйверам как рабочий, gate провален.

Зафиксируйте продолжительность старта, но не объявляйте её benchmark. Первый boot может включать инициализацию driver, а повторный — иной reset path. Важнее стабильность последовательности start → stop → start и отсутствие новых AER, IOMMU fault или Xid в журналах.

Application gate: CUDA видит карту, LLM отвечает

Рабочий PCI passthrough ещё не означает готовность inference. Внутри гостя проверьте driver, UUID, ECC-состояние там, где оно поддерживается, температуру и отсутствие Xid. Затем запускайте выбранный runtime с закреплённой моделью и конфигурацией. Не обновляйте гостевой драйвер «до последнего» во время миграции: совместимость CUDA runtime, kernel module и образа должна быть частью version lock.

nvidia-smi -L
nvidia-smi --query-gpu=uuid,name,driver_version,memory.total --format=csv
journalctl -k -b | grep -Ei 'NVRM|Xid' || true
curl --fail --silent http://127.0.0.1:8000/v1/models
curl --fail --silent -H 'Content-Type: application/json'   -d '{"model":"","prompt":"health probe","max_tokens":8}'   http://127.0.0.1:8000/v1/completions

Application gate содержит два разных доказательства. Первое: CUDA действительно использует переданный GPU, а не CPU fallback. Второе: сервис проходит реальный короткий запрос с закреплённым model ID. Latency одиночного запроса не является benchmark; она лишь подтверждает путь выполнения.

Контрфактическая проверка помогает не принять совпадение за причину. Остановите inference-процесс, убедитесь, что endpoint становится недоступен, а GPU memory освобождается; затем запустите снова и повторите тот же probe. Так проверяется связь между readiness и реальным workload.

Проверьте и отрицательную границу: хостовый runtime не должен найти переданный UUID, а соседняя VM не должна получить устройство. Для выбора аппаратной базы сверяйте объём VRAM, питание и охлаждение с руководством по конфигурации GPU-сервера; passthrough не исправляет недостаток памяти модели.

Отрицательные проверки и наблюдаемость границы

Изоляцию нельзя доказать только положительным nvidia-smi в госте. Нужен отрицательный контроль: переданный UUID отсутствует в рабочих инструментах хоста, соседняя VM не получает этот PCI device, а сетевые политики не открывают management API шире запланированного.

На хосте наблюдайте libvirt lifecycle, IOMMU faults, AER и reset-события. В госте — Xid, VRAM, температуру, throttling и application metrics: queue depth, error rate, время до первого токена и readiness. Эти слои нельзя сливать в один «GPU healthy». Например, карта может быть полностью видна CUDA, но модель не загружаться из-за storage timeout.

Разделите alerts по owner. Platform team отвечает за IOMMU group, vfio binding, VM lifecycle и физический reset. Команда inference — за модель, runtime, VRAM budget и API. Security — за образ гостя, сеть, секреты и доступ к libvirt. Во время инцидента такая таблица экономит больше времени, чем ещё один общий dashboard.

Добавьте correlation key: имя домена, BDF, GPU UUID и deploy revision. Тогда событие libvirt можно связать с Xid в госте и ошибкой endpoint. Без общей идентичности дежурные видят три независимых алерта и теряют причинный порядок.

Материал о безопасности данных и AI-моделей на GPU-серверах дополняет аппаратную границу контролями данных. Passthrough уменьшает совместное владение устройством, но не шифрует веса и не аутентифицирует API.

Troubleshooting по слоям: не лечите LLM через PCI

Диагностика идёт в том же порядке, что rollout. Если GPU остаётся у хоста, не трогайте CUDA в госте. Если PCI device виден, но nvidia-smi падает, не меняйте model path. Если CUDA здорова, а endpoint не готов, инфраструктурный gate уже пройден и поиск смещается в приложение.

Слой 1 — host ownership. Проверьте активные процессы, driver binding и все функции группы. Слой 2 — assignment. Сопоставьте effective XML и guest PCI inventory. Слой 3 — driver/reset. Ищите Xid, BAR и ошибки инициализации. Слой 4 — runtime. Проверяйте pinned model, доступ к хранилищу и VRAM budget.

Типичная ловушка — перезапустить хост и решить, что проблема исправлена. Reboot очищает состояние устройства, но скрывает дефект lifecycle. После восстановления повторите цикл start → stop → start без reboot. Если второй запуск ломается, у вас reset/rebind issue, а не случайный сбой приложения.

Другая ловушка — одновременно обновить driver в госте и изменить machine type. Получив зелёный результат, вы не сможете объяснить причину. Меняйте одну переменную, сохраняйте evidence и повторяйте тот же отрицательный контроль.

NVIDIA описывает поддерживаемые способы настройки KVM passthrough и замечания по large BAR в актуальном руководстве GPU Pass-Through. Сверяйте support matrix конкретного GPU и гипервизора перед rollout.

Rollback: вернуть GPU и доказать повторяемость

Rollback начинается не с virsh destroy, а со снятия трафика и остановки приложения. Дайте inference-сервису завершить активные запросы, зафиксируйте состояние GPU, остановите домен штатно и дождитесь libvirt lifecycle event. Только затем проверяйте возврат устройства хосту.

virsh shutdown llm-vfio-01
virsh domstate llm-vfio-01
lspci -nnk -s 0000:65:00.0
journalctl -k --since '-10 min' | grep -Ei 'vfio|IOMMU|AER|NVRM|Xid'
nvidia-smi -L

Положительный rollback gate: ожидаемый host driver снова владеет всеми нужными функциями, журнал не содержит новых IOMMU/AER/Xid ошибок, и хостовый probe проходит. Но этого мало. Запустите VM повторно и пройдите те же PCI, CUDA и LLM gates в том же порядке. Повторяемость важнее первого удачного запуска.

Если reattach не проходит, не пытайтесь вручную привязать половину группы, пока домен или QEMU ещё держит file descriptor. Сохраните virsh domstate, список процессов QEMU, driver links в sysfs и kernel log. Stop condition: GPU не возвращается без reboot после двух штатных циклов. Такой узел нельзя считать готовым к автоматическому обслуживанию.

Опишите аварийный вариант: перенести трафик на другой inference endpoint, оставить проблемный GPU вне пула и расследовать reset отдельно. Цель rollback — восстановить сервис и сохранить доказательства, а не любой ценой вернуть карту в работу.

Production-чеклист и следующий шаг

Готовый passthrough — это не XML, который однажды загрузился. Это повторяемый lifecycle с evidence до detach, отрицательной проверкой границы, application probe и симметричным rollback. Перед эксплуатацией закрепите BDF и UUID в inventory, владельцев gates, окно обслуживания и известный путь возврата на хост.

• IOMMU включена и подтверждена журналом; unsafe no-IOMMU запрещён.
• Состав группы проверен, соседние критичные устройства не затронуты.
• libvirt managed hostdev содержит все необходимые функции.
• Host ownership и guest ownership взаимно исключаются.
• CUDA gate отделён от LLM readiness и storage/network checks.
• Start → stop → start проходит без reboot.
• Alerts разделены между platform, inference и security owners.

Если вы выбираете площадку, начинайте не с тюнинга QEMU, а с совместимости платы, слотов, IOMMU topology, GPU и охлаждения. Для готового сервиса полезно сверить lifecycle с runbook по NVIDIA NIM и health-check. На выделенном GPU-сервере KingServers можно заранее обсудить топологию и требования VM до переноса модели.

Следующий безопасный шаг — прогнать runbook на тестовом домене, сохранить evidence bundle и намеренно сломать один gate: занять функцию группы, указать неверный BDF или остановить endpoint. Если команда локализует сбой по слою и возвращает GPU без reboot, инфраструктура действительно готова к production, а не просто красиво стартовала один раз.

Не переносите в production непроверенный experimental workaround для BAR или ACS. Зафиксируйте версию kernel, QEMU, libvirt и guest driver, затем повторите тест после каждого обновления. Такой version lock не отменяет обновления, но делает изменение наблюдаемым и обратимым.