GPU パススルー(VFIO)完全ガイド2026｜Proxmox・libvirt仮想マシンでゲーミング

対応マザーボードの選定基準

高級ゲーミングマザーボードやワークステーション向けマザーボードは、IOMMUグループの分割が洗練されており、GPUとUSBコントローラを分離しやすいため、初心者でも設定が成功しやすい傾向にあります。一方、エントリーチップセットでは、PCIeスロットの物理的な配置とチップセット内部のバス構造により、GPUがUSB 3.0コントローラと同一グループに属するケースが多々あります。この場合、USBパススルーを諦めるか、PCIeスイッチ（例：ASM1184チップ搭載カード）を使用してIOMMUグループを分割する必要があります。

これらの対策は、GPUパススルーの安定稼働にとって不可欠です。特にNVIDIAユーザーはCode 43対策を、AMDユーザーはリセットバグ対策を、それぞれのGPUモデルに応じて適切に適用する必要があります。

パフォーマンス最適化とLooking Glassによる運用

GPUパススルーで得た高性能を最大限に引き出すには、CPUとメモリの最適化、そして低遅延な入出力環境の構築が不可欠です。単にGPUを割り当てるだけでなく、システム全体の構成をゲーミング向けにチューニングすることで、ベアメタルとほぼ同等の体験が可能になります。

CPU PinningとHugepagesの活用

GPUの演算負荷が高いため、VMのCPUリソースを固定（CPU Pinning）し、ホストOSの他のプロセスと干渉させないことが重要です。

1. CPU Pinning: VMのXML定義で <vcpu> の cpuset 属性を使用し、特定の物理コアにVMのvCPUを固定します。例えば、AMD Ryzen 9 9950Xの場合、コア0-7をホスト用、コア8-15をVM用に割り当てるなどします。これにより、VMの処理が他のコアにスレッドを移動するオーバーヘッドがなくなり、フレームタイムの安定性が向上します。

2. Hugepages（巨大ページ）: メモリ管理ユニット（MMU）のオーバーヘッドを減らすため、4KBのページではなく2MBまたは1GBの巨大ページを使用します。Linuxホストで hugepages を有効化し、VMのXML定義で <memoryBacking> タグ内に <hugepages/> を追加します。これにより、GPUとVM間のメモリ転送効率が向上し、特に大容量テクスチャを扱うゲームで性能差が発現します。

Looking Glassによる低遅延画面共有

GPUパススルーの最大の課題は、VM内のGPU出力をホストOSのモニターに表示する方法です。従来のRDPやVNCは遅延が大きく、ゲーミングには適しません。ここで活躍するのが「Looking Glass」です。

Looking Glassは、VM内のGPUメモリを直接読み取り、ホストOSのOpenGL/Vulkanアプリケーションで描画する技術です。ネットワーク経由ではなく、共有メモリ（shm）を用いるため、遅延は1〜2ms程度に抑えられ、ベアメタルと見分けがつかないほどスムーズです。

設定手順は以下の通りです。

1. ホスト側のインストール: LinuxホストにLooking Glassのホスト側コンポーネントをインストールします。

   sudo apt install looking-glass-host
   

2. VM側のインストール: VM内のゲストOS（Windows/Linux）にLooking Glassのゲスト側クライアントをインストールします。

3. VM設定の変更: VMのXML定義で、共有メモリデバイス（/dev/shm/looking-glass）をVMにマウントします。

   <filesystem type='mount' accessmode='passthrough'>
     <source dir='/dev/shm/looking-glass'/>
     <target dir='looking-glass'/>
   </filesystem>
   

4. Looking Glassの起動: VM内でLooking Glassクライアントを起動し、ホストのLooking Glassホストに接続します。これで、VMのディスプレイ出力がホストモニターにリアルタイムで表示されます。

オーディオパススルーとUSBパススルー

音声と入力はゲーミング体験の重要な要素です。

• オーディオ: GPUのHDMIオーディオをVMに割り当てる場合、NVIDIA RTX 30/40シリーズやAMD RX 6000/7000シリーズのHDMIオーディオコントローラをPCIデバイスとして割り当てます。ただし、ホスト側のサウンドドライバー（PulseAudio/PipeWire）がGPUのオーディオデバイスを使用している場合、競合が発生します。解決策として、ホスト側のオーディオ出力を別のデバイス（例：Realtekオーディオコーデック）に固定し、GPUのHDMIオーディオをVM専用にします。また、USBオーディオインターフェース（例：Focusrite Scarlett 2i2）をUSBパススルーでVMに割り当てる方法もあります。

• USBパススルー: キーボードとマウスをUSBコントローラごとVMに割り当てます。ただし、前述のIOMMUグループの問題に注意が必要です。GPUと同じIOMMUグループにあるUSBコントローラをVMに割り当てると、ホストのキーボードやマウスが使えなくなります。解決策として、USBコントローラを個別に指定するのではなく、特定のUSBデバイス（キーボード、マウス）を直接割り当てる「USBデバイスパススルー」を使用します。これにより、他のUSBデバイス（例：Webカメラ、マイク）はホスト側に残しつつ、キーボードとマウスのみをVMに渡すことができます。

  <hostdev mode='subsystem' type='usb' managed='no'>
    <source>
      <vendor id='0x046d'/>
      <product id='0xc52b'/>
    </source>
  </hostdev>
  

  このように、ハードウェアの特性を理解し、適切な最適化を施すことで、GPUパススルーはベアメタルに迫るパフォーマンスと使いやすさを実現します。

GPUパススルー環境の比較表：構成要素と最適選択の基準

GPUパススルー環境を構築する際、単にGPUを購入するだけでなく、CPU、マザーボード、メモリ、電源といった周辺機器の互換性と性能バランスが全体の安定性とパフォーマンスを決定します。2026年時点で主流となっている構成は、Intel第14世代CoreシリーズやRyzen 9000シリーズといった最新世代のIOMMU対応CPUと、PCIe 5.0対応マザーボードの組み合わせです。本セクションでは、具体的な製品例を用いて、価格帯、スペック、用途、判断基準の4軸で主要な構成要素を比較します。これにより、予算と目的に応じた最適なコンポーネントの選択が可能になります。

主要GPUの価格・スペック・用途比較

GPUパススルーにおいて、ゲストOSとして動作する仮想マシンの用途（ゲーミング、3Dレンダリング、AI推論）によって、推奨されるGPUアーキテクチャと価格帯は大きく異なります。AMD Radeon RX 7000シリーズはOpenCLやVulkanのネイティブなサポートが厚く、VFIOとの親和性が高い一方で、NVIDIA GeForce RTX 40シリーズはCUDAエコシステムの利用者にとって不可欠です。以下の表は、代表的なGPUモデルを比較したものです。

CPUとマザーボードのIOMMU対応比較

GPUパススルーの要となるIOMMU（IO Memory Management Unit）の動作安定性は、CPUとマザーボードの組み合わせに依存します。Intel VT-dとAMD-Vi（AMD IOMMU）は、それぞれ異なる実装を持っており、特にIOMMUグループの分割状況がPCIデバイス割り当ての自由度を左右します。2026年現在、Intel Core i9/i7とRyzen 9/7のハイエンドモデルは、より大きなIOMMUグループを形成する傾向があり、複数GPUを搭載する場合に有利です。

メモリ構成とHugePages最適化比較

GPUパススルー環境では、ゲストOSのメモリ管理効率を向上させるため、Linuxホスト側でHugePages（巨大ページ）の利用が推奨されます。これにより、TLB（Translation Lookaside Buffer）のミスヒットが減り、メモリアクセスのオーバーヘッドが低下します。また、VMに割り当てるメモリ容量と、ホストOSが確保するHugePagesのサイズ（通常2MBまたは1GB）の設定が、パフォーマンスに直結します。以下の表は、メモリ容量と設定方法の比較です。

電源供給と冷却システムの比較

GPUパススルーでは、GPUがVM内でフル稼働するため、ベアメタル時と同様、あるいはそれ以上に安定した電源供給と冷却が必要です。特に、GPUのPCIeスロットからの給電（最大75W）に加えて、8ピンコネクタによる追加給電が必要となります。高消費電力なGPU（例：RTX 4090）を搭載する場合、電源ユニットの定格出力と、CPU/GPUの瞬時消費電力（Transient Spike）への耐性が重要です。

国内流通とサポート体制の比較

GPUパススルー環境の構築には、ハードウェアの入手可能性とアフターサポートも重要な要素です。特に、BIOSアップデートによるIOMMUグループの修正や、ドライバーの最新化が必要となる場面では、国内でのサポート体制が役立ちます。また、中古市場での価格変動も大きく、時期による購入戦略の違いを理解しておく必要があります。

これらの比較表を参照し、自身の使用環境（Proxmox VEかlibvirtか、メインGPUかサブGPUか、予算はどれくらいか）に合わせてコンポーネントを選択することが、失敗のないGPUパススルー環境構築の第一歩となります。特に、IOMMUグループの確認は購入前に必須であり、マザーボードのレビューやCPUベンチマーク情報で事前に確認しておきましょう。

よくある質問

Q1. GPUパススルーに必要な最低限のPCスペックは？

GPUパススルーを実行するには、IOMMU（Intel VT-dまたはAMD-Vi）に対応したCPUとマザーボード、そして2枚以上のGPUが必要です。ホスト用としてIntel Core i5-14600KやAMD Ryzen 7 7800X3DなどのiGPU付きCPU、ゲスト用にはNVIDIA GeForce RTX 4060やAMD Radeon RX 7800 XTといった専用GPU1枚があれば構築可能です。メモリは64GB以上を推奨し、ストレージはPCIe 4.0対応のNVMe SSD（例：Samsung 990 PRO）を使用することで、仮想マシン内のGPU通信のボトルネックを最小限に抑えられます。

Q2. Proxmox VEとUbuntu libvirt、どちらが初心者向けですか？

技術的な習得コストを抑えるならProxmox VE、柔軟なカスタマイズを求めるならUbuntu libvirtが適しています。Proxmox VEはWeb GUIでIOMMUグループ確認やVFIOバインド設定が直感的に行えるため、CLI操作に不慣れな方でも比較的容易に構築できます。一方、Ubuntu libvirtはvirshコマンドやXMLファイル編集が必要ですが、Debian系パッケージ管理との親和性が高く、特定のドライバアップデートやカスタムカーネルビルドが必要な上級者向けです。まずはProxmox VEで基本を学び、必要に応じてlibvirtへ移行するのが効率的です。

Q3. NVIDIA GPUのCode 43エラーを回避する方法は？

NVIDIAドライバーが仮想環境を検知してインストールを拒否するCode 43エラーは、GPUのベンダーIDやhypervisorフラグを隠蔽することで回避可能です。Proxmox VEでは、VM設定の「オプション」→「qemuサーバーのプロパティ」でhypervisorフラグを削除するか、vendor_idを空文字列に設定します。libvirt環境では、VMのXML定義に<vendor_id state='on' value='xxxxxxxxxxxx'/>を追加して偽造値を設定します。これにより、NVIDIAドライバーはホスト上の物理GPUとして認識し、正常に動作します。ただし、ドライバーアップデート後に再設定が必要な場合があるため注意が必要です。

Q4. GPUパススルーのパフォーマンス損失はどの程度ですか？

GPUパススルー（VFIO）におけるパフォーマンス損失は、適切に設定された環境では5%未満、一般的には95%以上のベアメタル比が達成可能です。PCIeバス経由の通信オーバーヘッドは微小であり、CPUコアのピン留め（Pinning）やHugePagesの有効化により、さらに1〜2%の改善が見込めます。主要なベンチマーク結果では、NVIDIA GeForce RTX 4090を使用した場合、3DMark Time Spyスコアがベアメタルとほぼ同等となり、ゲーム内のフレームレート変動も最小限に収まります。ただし、ホストOSのリソース競合を防ぐため、CPUとメモリの割り当てには十分な余裕を持たせることが重要です。

Q5. GPUが1枚しかない場合、パススルーは可能ですか？

物理的にGPUが1枚しかない場合でも、「Single GPUパススルー」技術を用いれば仮想マシンにGPUを割り当てることが可能です。これは、仮想マシン起動時にGPUをホストから切り離し、VMにアタッチし、VM終了時に再びホストに戻すという動的な切り替えを行います。KVMのvfio-pciドライバーとqemu-system-x86_64のコマンドラインオプション、またはlibvirtのXML設定で<hostdev mode='subsystem' type='pci' managed='yes'>を指定します。ただし、VMのシャットダウン処理が失敗するとホストがフリーズするリスクがあり、バックアップと慎重な運用が必須です。

Q6. AMD GPUとNVIDIA GPU、どちらが仮想化向けですか？

コストパフォーマンスと設定の容易さを重視するならAMD GPU、高品質なレンダリングやNVIDIA専用ソフトの安定性を求めるならNVIDIA GPUが適しています。AMD Radeon RXシリーズは、VFIO環境でのリセットバグ対策が比較的単純で、オープンソースのamdgpuドライバーがホスト側でも利用しやすいため、初期設定が楽です。一方、NVIDIA GPUはCode 43回避の一手間が必要ですが、CUDA利用やDLSSなどの独自機能を利用できる利点があります。2026年時点で両社ともIOMMUグループの分離性が向上しており、互いに大きな格差はなくなりましたが、NVIDIAの専門ドライバーの安定性は依然として優れています。

Q7. Looking Glassは必要ですか？

ホストOSの画面出力を低遅延でゲストVMに映し出す「Looking Glass」は、GPUが1枚しかない場合や、VM内の操作をホストのモニターで確認したい場合に極めて有用です。PCIeの共有メモリ（Shared Memory）を用いるため、ネットワーク経由のVNCやRDPよりもフレームレートが高く、遅延は1ms未満に抑えられます。例えば、[AMD [Radeon RX 7900 XT](/glossary/radeon-rx-7900-xtx)](/glossary/radeon-rx-7900-xt)XとIntel Core i9-14900Kの組み合わせでは、240Hzモニターでも滑らかな動作が可能です。ただし、VM側でvfio-pciバインドされたGPUが出力を担当している必要があるため、VMのシャットダウン時にGPUが正しくホストに戻らないと、Looking Glass側でも画面がフリーズします。

Q8. USBデバイス（キーボード・マウス）のパススルー設定は？

USBキーボードやマウスをVMに直接接続するには、USBコントローラーのパススルーまたはevdevドライバの使用が有効です。ハードウェアのPID/VIDを確認し、libvirtのXMLで<hostdev mode='subsystem' type='usb'>として指定するか、Proxmox VEのUIから「USBデバイス」を追加します。ただし、VM起動中にホスト側でUSBデバイスが占有されると競合するため、VM起動前にUSBコントローラーを物理的に切り替えるスイッチの導入や、VM終了時に確実にVM側からUSBを解放するスクリプトの設定が推奨されます。Bluetoothドングルは共有しにくいため、USB接続の有線デバイスを使用するのが確実です。

Q9. オーディオパススルーはどう設定すればよいですか？

GPUに内蔵されたHDMI/[DisplayPortオーディオをVMに渡すには、GPUのオーディオ機能（HDAコントローラー）を別々のPCIeデバイスとして認識させ、VMにアタッチする必要があります。NVIDIA RTXシリーズやAMD Radeon RXシリーズは、GPU本体とHDAオーディオが異なるIOMMUグループに属していることが多く、これらを個別にVMに割り当てます。音質面では、VM内のオーディオドライバーがホストのPulseAudioやPipeWireと連携する方式（例：Windows側で「PulseAudio for Windows」を使用）と、直接ASIOドライバー経由でホストのオーディオレイヤーにアクセスする方式があります。低遅延を求めるなら、後者のASIO連携設定が推奨されます。

Q10. 将来的にGPUパススルーは必要なくなりますか？

クラウドゲーミングやブラウザベースの3Dレンダリングの普及により、一部での需要は低下しますが、ローカル環境での完全な制御と低遅延を求める層には、GPUパススルーの需要は2026年以降も持続すると予想されます。特に、AI推論、3Dモデリング、専門的な動画編集など、GPUリソースを独占的に必要とするワークロードでは、仮想化オーバーヘッドのないVFIO環境が不可欠です。また、VMwareやHyper-Vなどの商用仮想化ソフトウェアでもGPUパッシブまたはパッシングのサポートが強化されており、企業環境での採用も増えています。技術的には、SR-IOVなどのより高度な仮想化技術との統合が進むことで、より効率的なリソース共有が可能になるでしょう。

まとめ

GPUパススルー（VFIO）は、ホストのGPUを仮想マシンに直接割り当てることで、ベアメタル環境と同等のネイティブに近いゲームパフォーマンスを実現する技術です。2026年現在、Intel VT-dおよびAMD-Viに対応した最新のCPUとマザーボードを使用すれば、設定は以前より格段に容易になっています。本ガイドで解説した手順を踏むことで、Proxmox VEやlibvirt環境においても高品質なゲーミングVMを構築可能です。

記事の主要なポイントを下記に整理します。

• 必須環境の確保: IOMMU対応CPU（Intel VT-d/AMD-Vi）と、ホスト用とゲスト用の2枚以上のGPU構成が基本です。IOMMUグループの確認は、エラー回避の第一歩となります。
• ドライバーの正しいバインド: vfio-pciドライバーを用いてGPUをホストから解放し、VFIOデバイスとして識別させる手順が不可欠です。これにより、仮想マシンへの独占的なアクセスが可能になります。
• NVIDIA Code 43対策: NVIDIA GPUで発生する「Code 43」エラーは、vendor_idの隠蔽とhypervisorフラグの調整により回避できます。最新のドライバーでは改善されていますが、設定確認は必要です。
• AMD GPUのリセットバグ対策: AMD GPUではリセットバグに注意し、適切なPCIリセット手順を設定することで、クラッシュやフリーズを防ぎます。
• パフォーマンス最適化: CPU Pinning、hugepagesの有効化、IOMMUグループの分割などを適切に行うことで、ベアメタル比95%以上のパフォーマンスを引き出せます。
• 周辺機器と画面出力: Looking Glassによるホスト画面の低遅延共有、USBデバイス（キーボード・マウス）のパススルー、オーディオの処理により、快適なゲーミング体験を提供できます。
• トラブルシューティングの重要性: 起動失敗やパフォーマンス低下の原因は、GRUBパラメータ、BIOS設定、ドライバーバージョンの整合性にあることが多いです。ログ確認と段階的なデバッグが成功への近道です。

GPUパススルーの構築は、初期設定に手間がかかりますが、一度確立すれば、仮想化の恩恵を受けながら最高のゲーム性能を享受できます。まずはIOMMUグループの確認から始め、小規模なテスト環境で手順を確立することをお勧めします。仮想化プラットフォームの設定ファイルやドキュメントを参照し、自身の環境に合わせて慎重に調整を進めてください。

TrueNAS ScaleやOpenMediaVaultをProxmox上の仮想マシン（VM）で運用する場合、単に仮想ディスク（.qcow2）を割り当てるだけでは不十分です。