VFIOによるGPUパススルー本番設計｜AIワークロード直接割当とKVM仮想化共存検証

VFIOとGPUパススルーが注目される背景と2026年の現状

AIワークロードの推論・学習処理をベアメタルに近いパフォーマンスで実行しながら、同一ホスト上でKVM仮想マシンも動かしたい、という要件は2024年以降に急速に増えています。クラウド移行コストの見直しやオンプレミスGPUサーバーの有効活用が背景にあります。

この要件を満たす中心技術がVFIO（Virtual Function I/O）によるPCIデバイスパススルーです。VFIOはLinuxカーネルに組み込まれたデバイス分離フレームワークで、GPUを特定の仮想マシンやコンテナプロセスに直接割り当て、ハイパーバイザー経由のエミュレーションオーバーヘッドをほぼ排除できます。

2026年時点では、Linuxカーネル6.x系のVFIO実装が成熟し、NVIDIAのオープンカーネルモジュール（nvidia-open）がデフォルト推奨となっています。AMDはROCm 6.x系でVFIO経由パススルーのサポートを明示しており、ディストリビューションとドライバーの組み合わせの選択肢が広がっています。一方で、IOMMUグループ設計の誤りやACSオーバーライドの乱用など、本番環境で問題になりやすいポイントは変わっていません。

事前確認：IOMMU対応とIOMMUグループの把握

GPUパススルーの成否はIOMMUグループ設計にほぼ依存します。まずハードウェアとBIOS/UEFIの対応状況を確認します。

Intel環境では VT-d、AMD環境では AMD-Vi（AMD IOMMU）をUEFIで有効化します。その上でカーネルパラメータに intel_iommu=on iommu=pt（Intel）または amd_iommu=on iommu=pt（AMD）を追加します。iommu=pt はIOMMUをパススルー専用デバイス以外には介在させないモードで、パフォーマンスへの影響を最小化する現在の標準的な設定です。

パラメータ追加後にリブートし、IOMMUグループを確認します。以下のコマンドで各グループとデバイスの対応を一覧できます。

for d in /sys/kernel/iommu_groups/*/devices/*; do
  echo "Group $(basename $(dirname $(dirname $d))): $(lspci -nns ${d##*/})"
done

重要なのは、パススルーしたいGPUが他のデバイスと同一IOMMUグループに収まっていないかどうかです。GPUとそのオーディオコンポーネント（例：HDMI Audio）が同一グループに入ることは一般的ですが、無関係なNICやUSBコントローラーが同居している場合は、そのグループ内の全デバイスをVFIOに渡す必要があり、ホスト側で使えなくなります。

よくあるつまずきとして、エントリ向けマザーボードではPCIeスロット間でACSが有効化されておらず、複数のデバイスが同一グループに束ねられるケースがあります。ACSオーバーライドパッチで強制分離する手法も存在しますが、これはDMAリマッピングの安全保証を一部無効化するため、本番環境での採用は設計リスクとして明示しておく必要があります。

VFIO-PCIバインドの実装手順

IOMMUグループの確認が取れたら、対象GPUをVFIO-PCIドライバーにバインドします。手順は大きく3ステップです。

ステップ1：対象デバイスのベンダーIDとデバイスIDを取得する

lspci -nn | grep -i nvidia
# 例: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation ... [10de:2684]
# 例: 01:00.1 Audio device [0403]: NVIDIA Corporation ... [10de:22ba]

ステップ2：VFIO-PCIモジュールをロードし、デバイスIDを登録する

/etc/modprobe.d/vfio.conf を作成し、以下の内容を記述します。

options vfio-pci ids=10de:2684,10de:22ba
softdep nvidia pre: vfio-pci

softdep の指定により、NVIDIAドライバーよりも先にvfio-pciがロードされるよう順序を制御します。Ubuntu 22.04以降やRHEL 9系ではこの方式が安定しています。

ステップ3：initramfsを更新してリブートする

# Ubuntu/Debian系
update-initramfs -u

# RHEL/Fedora系
dracut --force

リブート後、lspci -nnk -d 10de:2684 で Kernel driver in use: vfio-pci と表示されればバインド成功です。

AIワークロード直接割当とKVM仮想マシンの共存設計

GPU搭載サーバーを共存環境で運用する場合、典型的には次のような構成が取られます。

• GPU-A（推論専用）：VFIO経由でKVM仮想マシン（AIコンテナホストVM）に直接割当
• GPU-B（学習用）：同じくVFIO経由で別の仮想マシンに割当、またはホストのDockerから直接利用
• ホストCPU/メモリ：管理VM・監視エージェント・KVMハイパーバイザー自体の運用に使用

QEMUでGPUをパススルーするコマンドの核心部分は以下のようになります。

qemu-system-x86_64 \
  -enable-kvm \
  -m 32G \
  -cpu host \
  -device vfio-pci,host=01:00.0,multifunction=on \
  -device vfio-pci,host=01:00.1 \
  ...

libvirtで管理する場合は、VMのXML定義に <hostdev mode='subsystem' type='pci' managed='yes'> ブロックを追加し、virsh nodedev-detach でホストからデタッチする方法が一般的です。managed=’yes’ を指定すると、VM起動・停止時のバインド切り替えをlibvirtが自動で行います。

2026年時点の注意点として、NVIDIA open カーネルモジュールはGeForce RTX 40番台以降で推奨されており、VFIO経由のパススルーVMでも追加の「バレメタルパッチ」なしで動作するケースが増えています。ただし、特定のGeForceモデルではドライバーがVMであることを検出し機能を制限する実装が依然残っているため、本番導入前にドライバーバージョンとモデル固有の制限を確認する必要があります。

AMDのRDNA 3/4系GPUはVFIOパススルーとの相性が良く、ROCm 6.x環境との組み合わせで推論ワークロードをVM内から直接実行できる事例が増えています。ホストOSにはROCmをインストールせず、VM内のみに閉じ込める設計はセキュリティ分離の観点からも有効です。

動作検証の手順とよくある確認ポイント

VM起動後、まずVMのゲストOS内で lspci を実行し、GPUが認識されているかを確認します。NVIDIA GPUであれば nvidia-smi でGPU情報が表示されれば基本的な動作は確認できます。

パフォーマンス検証では、推論フレームワーク（PyTorch、TensorRTなど）のベンチマークをVM内とベアメタルで比較します。一般的にはVFIOパススルー環境でのパフォーマンスはベアメタルの95〜99%程度に収まるとされていますが、これはワークロードの種類やメモリ帯域幅の要求によって変わります。想定例として、バッチ推論のようなGPU持続使用率が高いワークロードはベアメタルに近い数値が出る傾向があります（実測値ではなく傾向として捉えてください）。

ホスト側の監視では、IOMMUエラーやDMAエラーがカーネルログに出ていないかを定期確認します。

dmesg | grep -iE 'iommu|vfio|dmar' | grep -i error

エラーが出ている場合はIOMMUグループ設定の問題か、デバイスが正しく分離されていない可能性があります。

切り戻し手順と運用上の注意点

VFIO設定を元に戻したい場合、手順は以下の通りです。

• /etc/modprobe.d/vfio.conf の内容を削除またはコメントアウトする
• update-initramfs -u（または dracut --force）でinitramfsを再生成する
• リブートし、GPUが本来のドライバー（nvidia、amdgpu など）にバインドされていることを確認する

リブートなしでバインドを切り替えたい場合は echo "0000:01:00.0" > /sys/bus/pci/drivers/vfio-pci/unbind でアンバインドし、その後 echo "0000:01:00.0" > /sys/bus/pci/drivers/nvidia/bind で再バインドできますが、対象デバイスを使用中のプロセスが存在する場合は必ず停止してから実施します。

運用上の主な注意点をまとめます。

• GPUのホットプラグ非対応： VFIOバインド済みGPUはホスト側から参照できないため、ホスト上のGPU監視ツール（nvidia-smiなど）の対象から外れます。監視設計をVM内に移す必要があります。
• Secure Bootとの干渉： カスタムACSオーバーライドパッチを適用したカーネルはSecure Bootの署名検証に通らない場合があります。Secure Bootを無効化するか、MOK（Machine Owner Key）で署名する対応が必要です。
• KVMネストの非推奨： パススルーGPUを持つVMの中でさらにKVM仮想化を行うネスト構成は、デバイス制御の複雑さが増すため本番設計では避けるのが無難です。
• NVIDIAドライバーのバージョン固定： ホスト側のNVIDIAドライバーとゲスト側のバージョンを合わせる必要はなくなりましたが、QEMUとvfio-pciドライバーのバージョン組み合わせによっては既知のバグが存在するため、ディストリビューションのリリースノートを確認してから更新するのが安全です。

VFIOによるGPUパススルーは、適切なIOMMUグループ設計と正確なドライバーバインド順序を押さえることで、本番環境でも安定して運用できる技術です。2026年時点では関連ツールチェーンの成熟が進んでおり、以前ほどのパッチ当てや特殊設定なしに構成できるケースが増えています。一方で、ハードウェアの世代・BIOSの実装・ディストリビューションの組み合わせによる個体差は依然として大きいため、本番導入前に同一構成でのステージング検証を必ず行うことが重要です。