GPU Passthrough（GPU Passthrough）
仮想マシンに物理GPUを直接割り当てて、ネイティブに近いパフォーマンスを実現する技術。
GPU Passthroughの基礎知識と動作原理
GPU Passthrough（GPUパススルー）とは、ホストOS上で動作している仮想マシン（VM）に対して、物理的なGPU（グラフィックス処理装置）を直接的に割り当てる技術のことです。通常、仮想環境におけるハードウェアへのアクセスは、ハイパーバイザー（Hypervisor）が提供する「エミュレーション」や「仮想デバイス」を通じて行われます。しかし、この方法ではCPUがGPUの動作を模倣するため、極めて大きなオーバーヘッドが発生し、3DレンダリングやAI計算のような高負荷処理は不可能です。
GPUパススルーでは、PCIパススルー（PCI Passthrough）という技術を利用し、ハイパーバイザーが介在せずにVMが直接PCI Expressバス上のGPUを制御できるようにします。これにより、仮想マシン内でネイティブ環境（物理マシンに直接OSをインストールした状態）とほぼ同等のパフォーマンス、具体的には95%〜99%程度の性能を引き出すことが可能になります。
この技術を実現するための核心となるのが「IOMMU（Input-Output Memory Management Unit）」です。Intelでは「VT-d」、AMDでは「AMD-Vi」として実装されており、デバイスのメモリ空間を仮想マシンに安全に隔離して割り当てる役割を担います。例えば、NVIDIA GeForce RTX 4090のような高性能GPUをパススルーさせる場合、ホストOS側でそのGPUを「使用しない」設定にし、VFIO（Virtual Function I/O）ドライバーを用いてVMに権利を譲渡するプロセスが必要となります。
必要なハードウェア要件と推奨構成
GPUパススルーはソフトウェアの設定以上に、ハードウェアの選定が成功の鍵を握ります。特に「IOMMUグループ」の分離が重要であり、マザーボードの設計によって、GPUと一緒にオーディオコントローラーやUSBコントローラーが同一グループにまとめられている場合、それらすべてをまとめてVMに渡さなければならないという制約が生じます。
推奨されるCPUとマザーボード
パススルーを行うには、多くのPCIeレーンと強力なマルチコア性能を持つCPUが推奨されます。
- CPU: AMD Ryzen 9 7950XやIntel Core i9-14900Kのようなハイエンドモデル。これらは多くのPCIeレーンを提供し、VMに割り当てるコア数を十分に確保できます。
- マザーボード: IOMMUの分離精度が高いX670EやZ790チップセット搭載モデル。BIOS/UEFI設定で「VT-d」や「IOMMU」を有効にする必要があります。
GPUの構成例
パススルーを運用する場合、基本的には「ホスト用GPU」と「ゲスト（VM）用GPU」の2枚差し構成が一般的です。ホストOSに画面出力が必要なため、内蔵グラフィックス（iGPU）をホストに使い、物理GPUをゲストに割り当てる構成が最も効率的です。
以下に、パススルー環境を構築する際の代表的なハードウェアスペック例を挙げます。
- GPU (ゲスト用): NVIDIA GeForce RTX 4090（VRAM 24GB GDDR6X / TDP 450W / TSMC 4nmプロセス）
- GPU (サブ/ホスト用): AMD Radeon RX 7900 XTX（VRAM 24GB / 256-bitメモリバス）
- CPU: 16コア/32スレッド以上のモデル（例: 3.2GHz以上のベースクロックを持つ製品）
- メモリ: 128GB DDR5-6000（VMに64GB以上を割り当てるため）
- ストレージ: NVMe Gen5 SSD（PCIe 5.0対応で、VMのディスクI/Oボトルネックを解消）
実装におけるメリットとデメリット（トレードオフ）
GPUパススルーは非常に強力な技術ですが、導入には相応のリスクと手間が伴います。
メリット
- ネイティブに近い性能: 仮想環境でありながら、RTX 4090などの真の性能を享受でき、4K解像度でのゲーミングや、大規模言語モデル（LLM）の推論・学習が可能です。
- 環境の完全な分離: Windows VMにGPUをパススルーさせれば、Linuxホスト上で動作させながら、Windows専用のソフトウェア（Adobe Premiere Proや特定のゲームなど）を完全に隔離された環境で実行できます。
- スナップショット機能: 仮想マシンのため、ドライバー更新でシステムが不安定になっても、瞬時に以前の状態にロールバックできます。
デメリットと注意点
- 構築の難易度: Linuxカーネルのパラメータ設定、VFIOドライバのバインド、XMLファイルの編集など、高度な専門知識が必要です。
- ハードウェアの占有: パススルー中のGPUはホストOSからは一切見えなくなります。つまり、1枚のGPUをホストとゲストで同時に使うことはできません（後述のvGPUを除く）。
- リソースの固定割り当て: VMに割り当てたメモリ（例：32GB）やCPUコアは、VMが動作している間、ホスト側で利用できなくなります。
- セットアップ時間: 安定した環境を構築するまでに、数時間から数日の試行錯誤が必要な場合があります。
2025年〜2026年に向けた最新トレンドと次世代技術
2025年、そして2026年に向けて、GPUパススルーの領域は「単一デバイスの占有」から「リソースの動的共有」へとシフトしています。
SR-IOV（Single Root I/O Virtualization）の普及
これまで、1枚の物理GPUを複数のVMで分割して利用するには、NVIDIAのvGPU（仮想GPU）ライセンスなどの高価なエンタープライズ向けソリューションが必要でした。しかし、次世代のハードウェアではSR-IOVのサポートが一般消費者向けにも浸透し始めています。これにより、1枚のGPUを仮想的に複数の「仮想関数（VF）」に分割し、複数のVMに同時にパススルーすることが可能になります。
AIワークロードへの最適化
2025年以降のトレンドとして、ローカルLLM（Llama 3やMistralなど）の実行環境をVMで構築する需要が急増しています。NVIDIA RTX A6000のような大容量VRAM（48GB）を搭載したワークステーション向けGPUをパススルーさせ、ホストは軽量な管理OS（Proxmox VEなど）にし、ゲストでAI開発環境を構築する構成が標準的になりつつあります。
次世代ハイパーバイザーの進化
Proxmox VEやKVMベースの仮想化環境では、GPUパススルーの設定がGUIレベルで簡略化されており、2026年までには複雑なコマンドライン操作なしに、数クリックでパススルーが完了するユーザー体験が実現すると予想されます。
仮想化方式の比較：エミュレーション vs パススルー vs vGPU
ユーザーがどの手法を選択すべきかは、目的（ゲーム、AI、開発）によって異なります。以下の表に、それぞれの特性をまとめました。
| 比較項目 | GPUエミュレーション | GPUパススルー (Direct) | vGPU (SR-IOV / 分割) |
|---|---|---|---|
| パフォーマンス | 極めて低い (CPU処理) | 極めて高い (ネイティブ同等) | 高い (分割比率に依存) |
| 導入難易度 | 低い (標準機能) | 高い (設定が複雑) | 中〜高 (ドライバ依存) |
| ハードウェア占有 | なし (共有) | あり (1 VMが独占) | なし (複数 VMで共有) |
| 主な用途 | 簡易的な画面表示 | ゲーミング, AI学習, 3D CAD | サーバー集約, VDI |
| 必要要件 | 特になし | IOMMU, 物理GPU | SR-IOV対応GPU/ドライバ |
| 安定性 | 非常に安定 | 設定次第で不安定 | 安定しているがライセンス制が多い |
具体的な構築ステップとトラブルシューティング
GPUパススルーを成功させるための一般的なワークフローを解説します。ここでは、多くの自作ユーザーが利用するProxmox VE（KVMベース）を例に想定します。
構築の基本フロー
- BIOS設定:
Intel VT-dまたはAMD-Viを有効にし、CSM（Compatibility Support Module）を無効にしてUEFIモードで起動させます。 - ホスト側でGPUを隔離: カーネルパラメータに
intel_iommu=onやamd_iommu=onを追加し、vfio-pciドライバーを用いて、起動時にホストOSがGPUを掴まないように設定します。 - VMの作成: マシンタイプを
q35に設定し、BIOSをOVMF (UEFI)に変更します。 - PCIデバイスの追加: 管理画面から対象のGPU（例:
0000:01:00.0）を選択し、「All Functions」および「ROM-Bar」にチェックを入れて追加します。 - ゲストOSでのドライバインストール: Windows VMなどのゲストOSを起動し、最新のNVIDIA/AMDドライバをインストールします。
よくあるトラブルと解決策
- Error 43 (NVIDIA): 以前はNVIDIAが仮想環境での動作を制限し、デバイスマネージャーに「エラー43」を表示させていました。現在は最新のドライバで解消されていますが、古い環境ではVMの構成ファイル（.conf）に
cpu: host,hidden=1などの記述を追加して、ハイパーバイザーの存在を隠す必要があります。 - 画面が映らない（ブラックスクリーン）: 多くのGPUは、物理的なモニターが接続されていないと出力を停止します。これを回避するには、HDMIダミープラグ（数百円で購入可能）をGPUに刺すか、仮想的なディスプレイエミュレーションを有効にする必要があります。
- IOMMUグループの汚染: GPUが他のデバイス（USBコントローラー等）と同じグループに入っている場合、
ACS Override Patchというカーネルパッチを適用することで、強制的にグループを分離させることが可能です。
FAQ
Q1: GPUパススルーをすると、ホストOSの画面は使えなくなりますか？ A: はい、パススルーしたGPUをホストが利用することはできなくなります。そのため、CPUに内蔵グラフィックスがある場合はそれをホスト用とし、外部GPUをゲスト用に割り当てる構成を強く推奨します。もしGPUが1枚しかない場合は、ホストOSをヘッドレス（画面なし）で運用し、SSHやWeb GUIで管理することになります。
Q2: ノートPCでもGPUパススルーは可能ですか？ A: 理論上は可能ですが、非常に困難です。ノートPCの多くは「Muxless」構成（内蔵GPUを経由して外部GPUが出力される構造）となっており、PCIパススルーに必要なハードウェア的な分離ができていないことが多いためです。Muxスイッチ搭載モデルであれば可能性はありますが、デスクトップPCに比べて成功率は大幅に低くなります。
Q3: パススルーしたGPUでゲームをすると、遅延（ラグ）は発生しますか？ A: 物理的なモニターをパススルーしたGPUに直接接続している場合、遅延はほぼゼロであり、ネイティブ環境と区別がつきません。一方で、ParsecやMoonlightなどのリモートデスクトップソフト経由で画面を表示させる場合は、ネットワーク速度に応じたわずかな遅延が発生しますが、それでも十分にプレイ可能なレベルです。