こんにちは、ネットワールドの海野です。
以前、vGPU 18.0 の記事で「安定性を重視する場合は Long-Term Support Branch のリリースを待つのが無難です」と書きました。その Long-Term Support Branch にあたる 19.x ブランチは 2025 年 8 月に 19.0 がリリースされ、最新の 19.4 が 2026 年 1 月に公開されています。さらに最新メジャーリリースの 20.0 も登場しました。
この 20.0 ですが、先日参加してきた NVIDIA GTC 2026 の Ask the Experts というブースでも「そろそろリリースされるよ！」と紹介されていました。
さて、「結局どっちを入れればいいの？」という疑問をお持ちの方も多いんじゃないでしょうか。今回は 19.x と 20.0 の違いを NVIDIA の公式ドキュメントベースで解説していきます。なお、本記事では実機検証は行っておらず、ドキュメントの情報をもとにまとめています。また、バージョンやサポート状況は投稿日時点の情報ですので、その点はご注意ください。
まず、ブランチの使い分けを確認してみましょう
NVIDIA vGPU ソフトウェアには、大きく分けてふたつのリリースブランチがあります。
- 19.x (Long-Term Support Branch) : ドライバーシリーズ R580 です。19.0 から 19.4 までポイントリリースが出ており、セキュリティ修正と段階的な機能追加が含まれます。長期間安定したサポートを受けられるブランチです。
- 20.0 (最新メジャーリリース) : ドライバーシリーズ R595 です。新機能や新ハードウェアのサポートがいち早く反映されます。
ここで確認しておきたいことが、vGPU Manager 20.0 は 19.x のゲスト VM ドライバーと互換性があるという点です。つまり、Manager だけ先に 20.0 へ上げておいて、ゲストドライバーは 19.x のまま段階的に移行するといった、そんな運用が可能です。ただし、この組み合わせで有効になるのは両リリースで共通にサポートされる機能・ハードウェア・ソフトウェアのみです。20.0 Manager を入れたからといって、ゲストドライバーが 19.x のままでは 20.0 の新機能は使えない点にご注意ください。
一方で、18.x 以前のゲストドライバーは 20.0 Manager との組み合わせでサポートされません (19.x を除く)。現在 18.x 以前の環境を運用している場合、Manager と ゲストドライバーを同時に 20.0 へ上げるのであれば 19.x を経由する必要はありませんが、Manager だけ先に上げるような段階移行では 18.x ゲストドライバーとの混在が発生するため注意が必要です。
出典 : Virtual GPU Software Release Notes - Linux with KVM (20.0)、同 VMware vSphere (20.0)
19.x と 20.0 の主な違い
全体像を表で押さえてから、各ポイントを順に解説します。
| 項目 | 19.x (LTS) | 20.0 |
|---|---|---|
| ドライバーシリーズ | R580 | R595 |
| CUDA Toolkit | 13.0 | 13.2 |
| Blackwell 新 GPU | RTX PRO 6000 のみ | RTX PRO 6000 (液冷含む) + RTX PRO 4500 |
| レガシー GPU (M10, V100, Quadro RTX 6000/8000) | サポートあり (最後のブランチ) | サポート終了 |
| Fixed share スケジューラー (異種 vGPU 混在) | ― | 対応 |
| Wayland | ― | 限定対応 (対応 GPU・ゲスト OS に制限あり) |
| Verge.io VergeOS | ― | 対応 |
| MIG グラフィックス (vSphere 9u1) | 19.0 で導入 | vSphere 9u1 で拡張 |
| Windows 11 25H2 | 19.4 で追加 | 対応 |
| RHEL 10.1 ゲスト | 19.4 (KVM, console/CLI のみ) | vSphere 9u1 でも対応 |
対応 GPU の変更 : レガシー GPU のサポート終了に注意
20.0 で新たに追加された GPU
- NVIDIA RTX PRO 6000 Blackwell Server Edition (液冷モデル)
- NVIDIA RTX PRO 4500 Blackwell Server Edition
Blackwell 世代のデータセンター向け GPU がさらに拡充された形です。
20.0 でサポートが終了した GPU
以下の GPU は 19.x が最後のサポートブランチ です。20.0 では利用できません。
- Maxwell : Tesla M10
- Volta : Tesla V100 SXM2、V100 SXM2 32GB、V100 PCIe、V100 PCIe 32GB、V100S PCIe 32GB、V100 FHHL
- Turing : Quadro RTX 6000、Quadro RTX 6000 passive、Quadro RTX 8000、Quadro RTX 8000 passive
V100 や M10 は VDI 環境で一定数残っている GPU です。これらを使っている環境では、20.0 へ移行する前にハードウェアの更新計画が必要になります。ここは影響が大きいので要チェックです。
ちなみに、ここで削除された「Quadro RTX 6000」は Turing 世代の製品です。Ada Lovelace 世代の「RTX 6000 Ada Generation」とは別の GPU ですので、混同しないようにご注意ください。RTX 6000 Ada は 20.0 でも引き続きサポートされています。
20.0 で追加された新機能
Fixed share スケジューラー
Fixed share スケジューラー自体は以前から存在していましたが、20.0 では異なるフレームバッファサイズの Time-Sliced vGPU が混在する構成 (heterogeneous vGPU) でも固定シェアのスケジューリングが使えるようになりました。
たとえば VDI 環境で、パワーユーザー向けに大きなフレームバッファの vGPU プロファイルを割り当て、タスクワーカー向けに小さなプロファイルを割り当てるようなケース。こういった構成で GPU 時間の配分がより予測しやすくなります。
Wayland ディスプレイサーバープロトコルのサポート
20.0 で Wayland ディスプレイサーバープロトコルへの対応が追加されました。ただし全面対応ではなく、対応するゲスト OS は RHEL 10 系や Ubuntu 24.04 LTS など一部に限られ、GPU も Turing 世代を除く構成が対象です。解像度にも制限があるため、利用前にリリースノートのサポートマトリクスを確認してください。
そもそも Wayland とは何かというと、Linux のディスプレイサーバーの仕組みのひとつです。従来の Linux デスクトップは X Window System (X11) というプロトコルを使っていましたが、X11 は設計が古く、セキュリティモデルやパフォーマンス面で課題がありました。Wayland はこの X11 を置き換えることを目指して開発されたプロトコルで、ティアリング (画面のちらつき) の低減やセキュリティの改善といったメリットがあります。
RHEL や Ubuntu など主要な Linux ディストリビューションでは、すでにデフォルトのディスプレイサーバーが X11 から Wayland に切り替わりつつあります。vGPU でも Wayland に対応したことで、Linux VDI 環境を最新のディストリビューション構成で運用しやすくなったと言えます。
ただし、投稿日時点ではいくつか既知の制限があります。Ubuntu 24.04 でマルチ vGPU を割り当てた VM との組み合わせで非互換の問題が報告されているほか、GNOME Settings からの解像度変更が機能しないケースもあるようです。導入を検討する場合は、リリースノートの Known Issues を事前に確認しておくのがおすすめです。
出典 : Virtual GPU Software Release Notes - Linux with KVM (20.0) - Known Issues
MIG-Backed vGPU グラフィックスの拡張
VMware vSphere 9 Update 1 環境で、Blackwell GPU 上の MIG (Multi-Instance GPU) インスタンスにグラフィックス対応の vGPU を割り当てられるようになりました。さらに、MIG インスタンス内で Time-Sliced vGPU を構成する機能も追加されています。
MIG-Backed vGPU のグラフィックス対応自体は 19.0 で導入されていましたが、20.0 + vSphere 9u1 の組み合わせでより柔軟な構成が取れるようになった形です。
その他の追加・変更
- Verge.io VergeOS : 新たにサポートされたハイパーバイザーです (Linux with KVM カテゴリ)。日本国内ではまだ馴染みが薄いかもしれませんが、選択肢が増えること自体はいいのではないでしょうか。(私は初めて知りました。)
- CUDA Toolkit 13.2 : R595 ドライバーに対応する CUDA Toolkit です。19.x は CUDA 13.0 対応なので差は小さめですが、13.2 の新機能が必要な場合は 20.0 が必要になります。
- RHEL 10.1 / 10.0 ゲスト : VMware vSphere 9 Update 1 上での RHEL 10.1 および 10.0 ゲスト OS が新たにサポートされました。
- Strict Round Robin Policy の無効化が廃止 : 以前は無効化できましたが、20.0 ではこのオプションが削除されています。既存環境で無効化している場合は、アップグレード前にスケジューリング設定の確認をおすすめします。
19.x で段階的に追加された機能
19.x は Long-Term Support Branch として 19.0 から 19.4 まで計5回のリリースが行われています。いずれかを導入するなら、全ての累積改善とセキュリティ修正を含む 19.4 が推奨です。
各ポイントリリースで何が追加されたか、ざっとまとめておきます。
- 19.0 : MIG-backed vGPU でのグラフィックスサポート、B-series 3GB フレームバッファプロファイル (Ada Lovelace / Blackwell)、Windows 11 ゲスト VM での Virtualization Based Security (VBS) 対応
- 19.1 : B-series 3GB フレームバッファプロファイルが Ampere にも拡大、Ada Lovelace GPU での vGPU ハイバネーション (Microsoft Azure Local)
- 19.2 : VMware ESXi 8.0 のサポート要件が 8.0u3 P06 以降に変更。これ以前のパッチレベルでは動作しません。20.0 でも同様の要件です。
- 19.3 : Windows Enterprise マルチセッション対応 (Windows 11 / Microsoft Azure Local)
- 19.4 : RHEL 10.1 (KVM, console/CLI mode のみ。Wayland は非対応) のゲスト OS サポート追加、Windows 11 25H2 対応、セキュリティ更新
ESXi 8.0u3 P06 の要件は 19.2 で入ったものですが、20.0 でも引き継がれています。ESXi 環境の方はパッチレベルの確認を忘れずに。
補足: vCS (vCompute Server) はどこへ行ったのか？ NVIDIA AI Enterprise としての vGPU
vGPU の話をしていると「そういえば vCS ってどうなったの？」と気になる方もいるんじゃないでしょうか。せっかくなので現在の vGPU 製品体系を補足しておきます。
vGPU と NVAIE は何が同じで何が違うのか
まず押さえておきたいのは、標準 vGPU と NVIDIA AI Enterprise (NVAIE) は 同じ R580 系ドライバーブランチで足並みがそろっている という点です。NVAIE Infra 7.x は vGPU for Compute のコンポーネントとして 19.x 系を含んでおり、ドライバー系列は共通です。
| NVAIE Infra | GPU ドライバー | 対応する vGPU |
|---|---|---|
| Infra 7.0 | 580.65.06 | vGPU 19.0 |
| Infra 7.4 | 580.126.09 | vGPU 19.4 |
では何が違うのか。大きく分けて ライセンス体系、対応ハードウェア、利用可能な機能 の 3 点です。
ライセンス体系の違い
かつて NVIDIA vGPU にはグラフィックス/VDI 向けの vPC / vWS / vApps に加えて、コンピュートワークロード向けの vCS (vCompute Server) というライセンスがありました。C-series プロファイルを使って仮想マシン上で AI/ML などの GPU コンピュートワークロードを動かすためのものです。
現在、この vCS の役割は NVAIE に統合されています。C-series プロファイルは「vGPU for Compute」という名前で NVAIE ライセンスのもとに移っており、標準の vGPU ライセンス (vPC / vWS / vApps) では利用できません。
対応ハードウェアの違い
Hopper 世代の GPU (H100, H200, H800, H20) や HGX B200 は NVAIE 専用です。これらのデータセンター GPU は標準 vGPU のサポート対象には含まれていません。仮想化して使いたい場合は NVAIE ライセンスが必須です。
利用可能な機能の違い
| 観点 | 標準 vGPU (vPC / vWS / vApps) | NVAIE (vGPU for Compute) |
|---|---|---|
| vGPU プロファイル | Q / B / A-series | C-series |
| グラフィックス | 対応 (複数ディスプレイ、プロ向けグラフィックス) | シングルディスプレイヘッドのみ (RTX/Quadro 系 graphics acceleration は非対応) |
| CUDA | vWS の Q-series で利用可能 | AI モデルのトレーニング・推論・ファインチューニング向け |
| 付属ソフトウェア | vGPU ドライバー | vGPU ドライバー + NIM、NeMo、Run:ai、Container Toolkit、Kubernetes Operator 等の AI ソフトウェアスタック |
C-series はシングルディスプレイヘッドを持ちますが、RTX/Quadro 系の graphics acceleration は提供されないコンピュート専用のプロファイルです。VDI 用途には向きません。
一方で、標準 vGPU の vWS ライセンス (Q-series プロファイル) でも、対応する GPU であれば CUDA を利用できます。グラフィックスとコンピュートの両方が必要なケースでは、NVAIE ではなく vWS を選ぶという判断もあり得ます。
構築手順はどうなのか
vGPU としての構築手順 (ハイパーバイザーへの vGPU Manager のインストール、ゲスト VM へのドライバーインストール) は、標準 vGPU でも NVAIE でも NVIDIA のデプロイガイド上で同じ流れが記載されています。ドライバー系列も同じ R580 系なので、vGPU 部分の構築作業に大きな違いはないと考えてよさそうです。
違いが出るのはその先です。NVAIE の場合は vGPU ドライバーの構築に加えて、Container Toolkit や Kubernetes Operator、NIM といった AI ソフトウェアスタックのデプロイが追加で必要になります。また、ライセンスの種類が異なるため、ライセンスサーバーへの登録やゲスト VM でのライセンス設定は当然変わってきます。
製品体系の全体像
現在の vGPU 製品体系を一覧にするとこうなります。
| 用途 | ライセンス | vGPU プロファイル | グラフィックス | CUDA |
|---|---|---|---|---|
| ワークステーション | 標準 vGPU (vWS) | Q-series | 対応 | 対応 (対応 GPU のみ) |
| ビジネスデスクトップ | 標準 vGPU (vPC) | B-series | 対応 | ― |
| アプリケーション配信 | 標準 vGPU (vApps) | A-series | 対応 | ― |
| AI / ML コンピュート | NVIDIA AI Enterprise | C-series | ― | 対応 |
NVAIE は vGPU ドライバーだけでなく、NIM や NeMo、Run:ai といった AI ソフトウェアスタック全体を含む製品です。ライセンスの価値は「C-series が使える」だけにとどまらない点も覚えておくとよいかと思います。
出典 : NVIDIA AI Enterprise - vGPU for Compute、NVIDIA AI Enterprise Lifecycle、Virtual GPU Software User Guide (20.0)
結局どれを選ぶべきなんだ…？
ここまでの内容を踏まえて、選び方の目安をまとめます。
19.x を選ぶケース
- 環境内にレガシー GPU (V100, M10, Quadro RTX 6000/8000) が残っている
- 安定性を重視する本番 VDI 環境で、長期サポートの恩恵を受けたい
- 新機能よりも予測可能なアップデートサイクルを優先したい
20.0 を選ぶケース
- Blackwell 世代の新 GPU (RTX PRO 6000 液冷、RTX PRO 4500) を使う
- CUDA Toolkit 13.2 の新機能が必要な AI/ML ワークロードがある (19.x は 13.0 対応)
- Linux VDI で Wayland を利用したい
- VMware vSphere 9 Update 1 で MIG グラフィックスの拡張機能を活用したい
NVAIE が必要なケース
- AI/ML コンピュートワークロードで C-series プロファイルを使いたい
- Hopper (H100, H200) や HGX B200 を仮想化したい
なお、前述のとおり vGPU Manager 20.0 は 19.x ゲストドライバーとの互換性があります。Manager を先に 20.0 へ上げてからゲストドライバーを段階的に移行するという進め方も選択肢に入れてみてください (ただし混在中は両ブランチ共通の機能のみ有効です)。
おわりに
もう1年も前のことになりますが、 vGPU 18.0 の記事で「LTS を待ちましょう」と書きました。その答えが 19.x です。安定重視なら 19.4、Blackwell や最新機能が必要なら 20.0、AI/コンピュート目的なら NVAIE という使い分けになります。
今後も vGPU のアップデートがあれば取り上げていきます。あと実機検証ができたらそのレポートも取り上げようかと思っています。
ということで、今回はこのあたりで失礼します。ご覧いただきありがとうございました。
