Windows Virtual Desktop #35 AMD GPU を試す 前編

この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です。

今回は Windows Virtual Desktop でGPU 仮想化をテストします。　WVD でのGPU 仮想化については過去にも2回( #13 , #14 )ほど記事にしています。　その時はNVIDIA のGPU を搭載する仮想マシンを利用していました。　今回はAMD Radeon Instinct MI25を搭載するNVv4-series を試してみます。　

1. NV4-series の特長

Azure Virtual Machine ではGPU 搭載タイプとして以下の通り提供されています。 (2020/7/5 現在）

これだけラインナップがあるとどれを選べばよいのか？という話になりますが、用途で絞れば単純です。　VDI（Windows Virtual Desktop） での利用という観点ではNV シリーズの4つが対象です。　NCv3 のVolte を積んだVirtual Machine でVDIを実現することも勿論可能です。ただ、最低スペックで6vCPU 、112GB メモリとVDIで使うにはCPUとメモリの比率がよくありません。　マルチセッションで使うにもメモリが多すぎます。　

ということで Windows Virtual Desktop での利用という観点かつNVIDIA のGPUを搭載する他シリーズとの比較の観点でNVv4 の特長を説明します。　

1.1. GPU 観点

比較対象の NV / NV Promo / NVv3 はすべて NVIDIA のTesla M60 を搭載しています。　M60は Maxwell 世代で発売は2015年となります。　Maxwell のあとはPascal 、Volteと続いていますので一言でいえば古いアーキテクチャです。

AMD Radeon Instinct MI25 の発売は2018年です。　M60よりは新しいです。　GPUの進化は非常に速いためCPU以上に新しいものほど性能差も大きくなります。

共通で評価できるVDIでのベンチマークの公表結果があればよいのですが現状見つかりません。　複数種類のベンチマークツールを実際に実行してみるしかないようです。

また話をややこしくするのはGPU仮想化で行われる物理GPUカードのリソース共有の動作仕様です。　NVIDIAの場合、メモリは明確に分割し仮想マシンに割り当てられますが、GPUの計算リソースは空いていればその分使用出来る、混んでいると複数VMで分け合って使用するというものでした。　つまり、M60とAMD MI25 の性能を単純に比較しても意味はなく、何分割で利用するかを決め、VMを多重実行させる環境を整えてベンチマークを実施しないと正しい比較は出来ないということです。

あと考慮するべきはアプリケーションの対応です。　Officeやブラウザ利用がメインの通常OA用途のVDIではなくCAD やGISなどGPU を前提とした業務アプリケーションの利用です。　アプリケーションベンダーの対応はNVIDIAが多いようです。

そして大事なことは性能とコストパフォーマンスの両立です。　古くても新しくても求めている性能要件を満たせば問題ありません。その性能が見合ったコストである必要があります。　クラウドなのでM60がハードウェア的に終息を迎えるころには新しいものが提供されるでしょうし。　

参考として、AMD 社が提供しているdatasheet にNVIDIA Tesla P100-16 との性能比較情報があったので紹介します。　FP16 & FP32 ということで浮動小数点演算ではPascal アーキテクチャを上回るとのこと。　　上でも書いた通り、MI25もM60も何分割で利用するか、また、浮動小数点演算以外の要素もあるのでこの結果だけでは何とも言えないかなと。　

現状をまとめると、GPU 単体のカタログ性能はAMD MI25 > NVIDIA M60、ただしVDIでどうなるかは正しくベンチマークが必要。　M60はGPU仮想化の実績も多く、CAD系アプリの対応も多いため、実使用での性能を満たしているのであれば選択肢として問題なし、という感じです。

1.2. CPU 観点

次はCPUの観点です。　VDI を快適に使うために必要となるリソースで最も重要なものはCPU リソースだと考えています。　SSD が一般化するまではストレージの遅さがボトルネックになることもありましたが今は何と言ってもCPUです。 ストレージが高速になった分CPUリソースもより必要になっています。

シリーズごとに搭載されているCPUを表にします。

着目するべきはアーキテクチャとBase 周波数です。　例えばNVIDIA を搭載するNV / NV Promo / NVv3 のCPU アーキテクチャはHaswell とBroadwell と大分古い世代です。　Broadwell はまだしもHaswell はもう5年以上前に発売開始されたアーキテクチャです。　世代が違うと同じクロック周波数でも性能差は出てきます。　

そして今回テストするAMD EPYC 7V12 (Rome) ですが2019年に発表、発売されている最新のCPUです。　

Datasheet を見ていると1 Socket で64core を搭載しています。　PCサーバ向けのCPUなわけですが、64core を手ごろな価格で実現できるわけです。　2000年代、16CPUや32CPUのUNIXサーバで1CPUが何百万円、このサーバのインターコネクトはクロスバーのため凄いんです、とか言っていたのが虚しくなる技術の進歩ですよね。　当時数千万円、数億円した性能が1時間で500円もしないで利用できるようになったわけです。

CPUもGPU同様にベンチマークなどで性能を比較するわけですが、SPEC のサイト を見ても丁度良い情報が見つからず。AMD EYPC 7742 は Base 273 の結果が出ていることは発見（サーバがAzureのサーバではないためあくまで参考値）しましたがHaswell は見つかりません。 　こちらも実際にベンチマークを実行してみるしかなさそうです。　GPU性能も含めて別途やってみます。

カタログスペックだけからのコメントになりますがAMD EPYCはクロックの低さが気になります。 2.25GHz となるとシングルスレッドしか対応しないアプリケーションや処理の実行には時間がかかりそうです。　特に最近の物理PCは3.7GHzや4GHzオーバが当たり前になっています。　WVDにしたらアプリの起動やXXXの処理が長くなったとか言われかねません。　これはAMDだけではなく古いHaswellやBroadwellのNVIDIA搭載の仮想マシンも同じです。　クロックは2.6GHzなのでAMDと大差ありません。　アーキテクチャの古さを考えるとシングルスレッドでは差が無い可能性もあります（要ベンチマーク）。　あとTurbo boost 時は確かに3.5GHz とかになりますがそもそもTurbo Boost に入るには物理サーバ全体でリソースが枯渇してこないと入らないのであまり期待しない方がよかったり。

1.3. コスト観点

最後にコストパフォーマンスを比較します。　NV Promo は検証利用など用途限定のため除外します。

まず、高い安いの話をする前に、WVDでSingle-session で利用するのに丁度よい仮想マシンがそもそもありません。　NVIDIA搭載はもっとも安価なNV6ないしNV12sでも6vCPU / 56 GBメモリまたは 12 vCPU / 112 GBメモリです。　Multi-Session で考えないとアンバランスな CPU / メモリ構成です。　　なお、この価格表を見てわかる通り、NV6とNV12sは同等コストというかNVv3の方が安価です。 NVv3 はCPUアーキテクチャも新しくかつコア数は2倍です。　マイクロソフトとしても古いHaswell アーキテクチャの NV6はなくしたいのだと思われます。

そんな中AMD搭載のNV4as v4 が4vCPU、14GBメモリと開発者やHeavy User 向けとして使えそうです。　また、このマシンをMulti-Session で使っていくのもよい感じです。　CPUリソースはGPUにオフロードされることもありますが10ユーザで使うのに丁度よい感じです。　その時のコストも1ユーザ当たり3,000円/月を下回ります（3年・RI)です。

CPUとメモリの比率が異なるため単純比較は出来ないのですが AMD を搭載するNVv4 は最も安いもので58.464円/時間です。　NVIDIA 搭載マシンは176.96円/時間です。　NVIDIA搭載マシンはCPUとメモリのバランスが良くないこともあり、デスクトップ用途でGPU仮想化する場合はコスト面ではAMD が第1選択肢となると思いました。

2. NV4-series の展開

GPU搭載の仮想マシンといってもWVDでの展開の仕方は通常の仮想マシンと変わるところはありません。

Marketplace から”host pool”を検索します。

“Create”をクリックします。

“Basics” のパラメータを設定し、

Virtual Machines でGPU仮想マシンを搭載するVirtual Machine を選択するだけです。

この後の手順も通常の仮想マシンの時と同じですので割愛してしまいます。

前編はここまでです。　後編では展開後に必要となるドライバのインストール、アプリケーションレベルでのGPUのオフロードの効果についてとなります。