GPU コンテナ仮想化の新機能のリリースとフルシナリオの実践

この共有では、まずBaidu Smart Cloud GPU Container Virtualization 2.0のアップグレード変更点を紹介し、次に新バージョンでの技術的な実装方法を紹介して具体的な機能を実演し、最後にさまざまなビジネスシナリオでの実践と探求を紹介します。

1. デュアルエンジン GPU コンテナ仮想化 2.0

昨年、当社は業界初のデュアルエンジン GPU コンテナ仮想化アーキテクチャをリリースしました。これは、「ユーザーモード」エンジンと「カーネルモード」エンジンの両方を使用して、分離、パフォーマンス、効率性などのさまざまなユーザーのニーズを満たします。

分離エンジンの上にはリソース プーリング レイヤーがあり、主にリモート呼び出しに基づいてリソースの分離とプーリングを実装します。

リソース プーリング層の上には、K8s 統合リソース スケジューリング層があります。スケジューリング メカニズムに加えて、共有ハイブリッド配信、プリエンプティブ ハイブリッド配信、タイムシェアリング ハイブリッド配信、潮汐ハイブリッド配信など、さまざまなビジネス シナリオに応じてさまざまなハイブリッド配信方法を抽象化します。

上記の技術力により、モデル開発、モデルトレーニング、オンライン推論など、さまざまな AI ビジネスの実現をサポートし、GPU リソースの利用率を大幅に向上させ、使用する GPU の数を削減します。

これらの内容についてのより詳細かつ包括的な説明は、昨年のシェアで紹介されました。本文原稿へのリンクは記事の最後にあります。

写真

バージョン 1.0 は、AI シナリオのビジネス ニーズを非常によく満たしており、工場の内外で広く使用されています。

当社の技術的目標は、すべてのリソースを最大限に活用し、すべてのビジネス シナリオをカバーし、全体的なビジネス パフォーマンスを向上させることです。

そのため、バージョン 1.0 は十分に完璧ではなく、GPU の完全な機能を発揮していません。GPU 上のすべてのリソースがコンテナー仮想化環境で完全に有効化されておらず、より多くのシナリオで GPU コンテナー仮想化機能を使用できないため、今年は引き続きバージョン 2.0 をリリースしました。

写真

これは、デュアルエンジン GPU コンテナ仮想化 2.0 のアーキテクチャ図です。

バージョン2.0では、GPUのビデオメモリとAIコンピューティングパワーの分離に加えて、GPUのレンダリングコンピューティングパワーとコーデックの分離も実現されています。

これらの新しい機能に基づいて、混合レンダリングと混合エンコード/デコードをリソース スケジューリング レベルで提供できるようになり、AI コンピューティング パワー、レンダリング コンピューティング パワー、コーデックなどのすべての GPU リソースの統一されたスケジューリングが実現します。

同時に、バージョン 2.0 では、複数のスケジューラを通じて、お客様の既存のビジネスを当社のアーキテクチャにスムーズに統合することをサポートします。これは、顧客のビジネスが最新の GPU コンテナ仮想化機能を迅速に使用するために非常に重要です。

これらの新しい機能のサポートにより、ARM プラットフォーム上の自動運転シミュレーションやクラウド ゲームなど、より多くのビジネス シナリオで、このプラットフォームを通じてリソースの使用率を向上させ、必要な GPU 使用量を大幅に削減できます。

さらに、基盤となるライブラリが更新されるたびに 2 つのコンテナ仮想化エンジンを継続的に反復し、ユーザーが業界の最新テクノロジーを利用できるようにします。ユーザー状態は最新バージョンの nvidia ドライバーと cuda 12.1 をサポートし、カーネル状態は最新バージョンの nvidia ドライバー 525/530/535 をサポートします。

写真

2. 新しい機能と技術の分析

次に、レンダリングの計算能力とコーデックの分離に関する技術的なソリューションについて詳しく紹介します。

まず、AIコンピューティングパワーとレンダリングコンピューティングパワーの違いを分析してみましょう。

NVIDIA GPU は、AI コンピューティングだけでなく、グラフィックス レンダリング コンピューティングも実行できます。 AI ワークロードは Cuda を介して GPU にアクセスし、レンダリング ワークロードは OpenGL/Vulkan を介して GPU にアクセスします。どちらのタイプの計算でも同じコンピューティング リソースが使用されます。

では、AI コンピューティングの分離の実現に基づいて、レンダリング負荷は AI コンピューティングの分離された環境で正常に実行できるのでしょうか?

レンダリング負荷を正常に分離できる場合、どのタイプの GPU コンテナ仮想化エンジンが適切なソリューションでしょうか?

写真

次に、AIコンピューティングアーキテクチャを詳しく分析してみましょう。

上から下に向かって見ていくと、最上層は AI APP であり、cuda-x、cuda ランタイムなど、基盤となる Cuda シリーズ ライブラリに依存しており、上位層の AI APP に使いやすい高レベル API を提供しています。次は、cuda ドライバー、NVML などを含むアプリケーション層ドライバー ライブラリです。これらは、デバイス ファイルを介してカーネル状態ドライバーと通信し、最終的に GPU を使用する目的を達成します。

アーキテクチャ図の灰色の矢印はGPUを使用したAIプログラムの制御フロー、赤色の矢印はGPUを使用したAIプログラムのデータフローです。

では、AI コンピューティング アーキテクチャとレンダリング アーキテクチャの違いは何でしょうか?読み続けましょう。

写真

レンダリング コンピューティング アーキテクチャを上から下に向かって見てみると、最上層はゲーム エンジンなどの UI/3D APP です。その基盤となるライブラリは、AI コンピューティング アーキテクチャよりも複雑です。基礎となるライブラリを呼び出すには、転送層 GLX を介して X11 サーバーを呼び出す方法と、EGL を直接呼び出す方法の 2 つの主な方法があります。

最終的には、AI コンピューティングの Cuda ライブラリに相当する、基盤となるグラフィック ライブラリを OpenGL または Vulkan と呼ぶことになります。

さらに下には、libnvidia-glcore/libnvidia-eglcore/libdrm などを含むアプリケーション層ドライバー ライブラリがあります。これらは、デバイス ファイルを介してカーネル状態ドライバーとも通信し、最終的に GPU を使用する目的を達成します。

アーキテクチャ図の灰色の矢印は GPU を使用したレンダリング プログラムの制御フローであり、赤色の矢印は GPU を使用したレンダリング プログラムのデータ フローです。

写真

上記の分析と比較を通じて、AI コンピューティング パワー アーキテクチャとレンダリング コンピューティング パワー アーキテクチャの上位ソフトウェアは異なりますが、制御フローは一貫しており、通信には同じデバイス ファイルとカーネル モジュールを使用していることがわかります。

前の質問に戻りますが、レンダリング ワークロードは AI コンピューティング用の分離された環境で正常に実行できますか?この分析結果に基づいて、レンダリング アプリケーションは AI コンピューティング パワーの分離された環境で実行できると予測されます。

しかし、実際に検証してみると、結論は否定的である。

逆分析の結果、2 つのソリューションの制御コマンド ワードにいくつかの違いがあることが判明し、分離実装ではこれらの違いを区別する必要がありました。多くの実験を経て、ついにカーネルレベルでレンダリング計算能力の分離を実現しました。

なぜこのソリューションをユーザー モードで実装することを選択しなかったのでしょうか?

ユーザー モードの実装では、多くの上位レベルのライブラリ関数をインターセプトする必要があるため、実装が困難です。同時に、ソフトウェアはユーザーに対して透過的ではありません。したがって、ユーザー モードを通じてレンダリング コンピューティング パワーの分離を実装することは、適切なエンジニアリング ソリューションではありません。

写真

次に、AIコンピューティングパワーとレンダリングコンピューティングパワーの分離効果を紹介します。デモのハードウェア環境は、NVIDIA V100 16G です。

この GPU で単一の AI ワークロード (pytorch resnet50 トレーニング) をバッチ サイズ 32 で実行すると、100% の計算能力が割り当てられ、スループットは約 340 になります。GPUtest の Furmask テストを使用して単一のレンダリング ロードを実行し、100% の計算能力と 550 FPS を割り当てます。混合負荷テストでは、1 つの AI 負荷と 1 つのレンダリング負荷にそれぞれ 50% の計算能力が割り当てられました。 AI負荷のスループットは170、レンダリングのFPSは260〜270でした。

単一の GPU 上で AI 負荷とレンダリング負荷の両方が分離され、約半分の計算能力が得られ、期待どおりのパフォーマンスが実現されていることがわかります。

写真

バージョン 2.0 で追加されたもう 1 つの新機能は、コーデック分離です。

ユーザー モードとカーネル モードの両方でエンコードおよびデコードのインスタンスを実装しました。

ユーザー モード コーデック インスタンスでは、コーデックは生の混合形式で使用されます。コーデックの計算能力の分離はサポートされておらず、各インスタンスはすべてのコーデックの計算能力を使用できます。

カーネル状態コーデック インスタンスでは、コーデックの分離を実装しました。この例では、エンコーダーの重みが AI コンピューティング パワーとレンダリング コンピューティング パワーの重みと共有され、統一されたコンピューティング パワーの割り当てが実現されます。

では、カーネル モードとユーザー モードの実装の違いは何でしょうか?ユーザー状態はインスタンス内のコーデックの計算能力をフルに活用し、カーネル状態はコーデックの計算能力の割り当てを実装します。たとえば、カーネル状態に計算能力の 20% を割り当てると、カーネル状態のエンコードおよびデコード インスタンスでエンコード機能とデコード機能の 20% を使用できます。

このようにして、統一されたコンピューティングパワーの割り当てと GPU リソースの有効化が完了し、リソースを最大限に活用できるようになりました。

写真

3. フルシナリオ練習

次に、これまでの技術を組み合わせて、さまざまなシナリオの実践を共有します。

まず、テクノロジとシナリオの観点から、ユーザー モード エンジンとカーネル モード エンジンの違いを見てみましょう。

技術的な機能の比較に関しては、ビジネス レイヤーでは通常、分離パフォーマンス、レイテンシ、リソース割り当ての粒度、マルチユーザー サポート機能などの観点から技術的な考慮を行い、アプリケーションに適した GPU コンテナー仮想化エンジンを一致させます。

これらの特性の分析に基づいて、さまざまなアプリケーション シナリオに適用可能な技術ソリューションをリストしました。

たとえば、オンライン推論ではレイテンシに対する要件が非常に高いため、通常はユーザー モード ソリューションが推奨されます。オフライン推論の場合、両方のオプションが利用可能です。レンダリング シミュレーション シナリオでは、ユーザー モードではレンダリング分離がサポートされていないため、カーネル モード ソリューションのみを使用できます。

写真

これは、データ処理、モデル開発、オンライン サービスを含む、典型的なインターネット推奨ビジネスです。データ処理やモデル開発はオンラインサービスを支えるオフライン業務であり、どの業務でも大量の GPU が利用されます。

GPU コンテナ仮想化ソリューションが使用される前は、各ビジネス インスタンスで GPU を使用していました。大量の監視データを通じて、オンライン推論サービスの全体的な GPU 使用率は 20% と高くないことがわかりました。これは業界ではよくある問題です。

オンライン サービスには高いレイテンシ要件があるため、このシナリオではユーザー モード ソリューションを展開することを選択します。同じビジネス SLA を確保しながら、全体的な GPU リソース使用率が大幅に向上し、35% に達します。

ユーザー ステートによってサポートされるプリエンプティブ ハイブリッドおよびタイム シェアリング ハイブリッドと組み合わせることで、データ処理やモデル開発などのオフライン タスクを、オフラインでオンライン推論サービスと混在させることができます。オンライン ビジネスが低調なときは、オフライン ビジネスがビジネス処理のためにより多くの GPU アイドル リソースを取得し、全体的な GPU 使用量を節約します。

このシナリオは工場の内外で広く使用されており、多くのコストを節約しています。 GPU リソースが比較的不足している時代には、これは優れた技術的選択です。

写真

多くの顧客は、カスタマイズされたキューイング アルゴリズムやその他の機能を含む、独自のカスタマイズされたタスク スケジューラをプラットフォーム上にすでに持っています。サードパーティベンダーの GPU コンテナ仮想化プラットフォームを導入する場合は、対応するタスク スケジューラを使用する必要があります。

カスタマイズされたタスク スケジューラと Baidu Smart Cloud のタスク スケジューラを顧客のビジネスに共存させるにはどうすればよいでしょうか? 1 つの方法は、複数の K8s クラスターを使用することですが、管理が複雑になります。もう 1 つの方法は、Baidu Smart Cloud によって開発されたマルチ スケジューラ サポート ソリューションを使用し、同じ K8s スケジューリング クラスターで複数のスケジューラを使用することです。

このソリューションでは、GPU リソースを 2 つのプールに分割し、ラベルを通じて 2 つの GPU プールのリソースを識別します。タスクの説明には異なるタグが使用され、K8s は対応するタスク スケジューラにタスクを割り当てるため、異なるタスク スケジューラが共存できるようになります。

顧客がタスク スケジューラのオープン ソース バージョンを、大幅な変更を加えずに使用している場合、このソリューションを使用して、ビジネスのスムーズな移行を実現し、最終的にすべてのビジネスを Baidu Smart Cloud タスク スケジューラに移行できます。

写真

開発者は、デバッグ、検証、オペレータ開発などに小規模モデルを使用します。これらのモデルのパラメータスケールは、通常 15 億以内です。通常は A100 または A800 GPU を使用して実行され、2 ～ 4 人のユーザーをサポートします。

ただし、開発プロセス中は GPU がアイドル状態になる頻度が高くなり、全体的な GPU 使用率が低下します。

同時に、各開発者は独自のトレーニング データとモデル データを保存するために大量のストレージ リソースを必要とし、それらを大容量のリモート ファイル システムを介して保存する必要があります。

リモート ファイル システムをクライアント コンテナーにマウントするには、異なるボリュームをマウントするために異なるパラメーターを使用する必要があります。これは、各ユーザーのユーザー ID を通じてユーザーを識別することによって実現されます。

ただし、ユーザー モード仮想化では、異なるユーザー ID を持つユーザーはサポートされません。つまり、マルチユーザーの分離はサポートされず、このシナリオでは使用できません。カーネルモード仮想化により、マルチユーザーの分離を実現し、異なるユーザーが同時に異なるリソースをマウントして使用できるようになります。

カーネルモード仮想化は、アクティブなコンテナ負荷に対してのみ重みに基づいて計算能力を割り当てることができるバースト スケジューリング戦略をサポートします。たとえば、GPU は 2 人のユーザーによって使用されるように仮想化され、計算能力の 50% が均等に共有されます。実際に GPU を使用するユーザーが 1 人だけの場合、スケジューリング ポリシーによってすべての計算能力がこのユーザーに割り当てられます。 2 人のユーザーが使用する場合、各ユーザーは計算能力の 50% を使用します。

これにより、コンピューティング能力を共有できるようになるだけでなく、全体的な GPU 使用率とビジネス パフォーマンスも向上します。

写真

自動運転シミュレーション シナリオには 3 つのモジュールが含まれ、そのうちレンダリング シミュレーション エンコーディング モジュールと知覚推論モジュールは GPU を使用し、AI コンピューティング、グラフィックス レンダリング、コーデックなどのすべてのリソース タイプをカバーします。

GPU コンテナ仮想化ソリューションが使用される前は、レンダリング シミュレーションとエンコード シミュレーションでは、GPU を使用してゲーム エンジンに似た環境を実行し、車両や道路状況をリアルタイムでレンダリングしていました。 1 ～ 2 秒ごとに画像がキャプチャされ、エンコードされ、認識および推論モジュールに出力されました。認識および推論モジュールは別の GPU を使用して画像認識や分類推論などの AI モデルを実行し、車線、歩行者、障害物などを識別して、そのデータを規制および制御モジュールに提供します。調整および制御モジュールは、認識データに基づいて車両の次の状態を計画および制御し、シミュレーション モジュールに制御コマンドを送信して次の操作を実行します。

現時点では、ビジネスの GPU 使用率は比較的低く、50% を超えていません。

カーネルモード仮想化テクノロジーを使用して、シミュレーションと推論のタスクを同じ GPU 上で同時に実行し、各タスクに計算能力の 50% を割り当てることで、1 つの GPU 上で 2 つの異なる負荷を同時に実行できるようになります。同時に、GPU のビデオメモリでデータが転送されるため、データ転送効率が向上し、ビジネス パフォーマンスが向上します。

これにより、シミュレーション環境での GPU 使用率が従来に比べて 100% 向上します。

写真

クラウド ゲームでは通常、同じ GPU 上で複数のコンテナーが実行され、各コンテナーで完全な Android インスタンスが実行されます。このインスタンスには Android ランタイム環境が含まれており、Honor of Kings、Game for Peace、Genshin Impact などの Android ゲームがその上で実行されます。

クラウド ゲームには実際の画面はなく、シミュレートされた仮想画面のみがあるため、各インスタンスは GPU レンダリング リソースを使用して、ゲームのグラフィカル インターフェイスを仮想画面にレンダリングします。これらの画像は、仮想画面のスクリーンショットとエンコードを通じて H.264 ビデオ ストリームとして出力され、ストリーミング メディア プロトコルを通じてユーザーのモバイル クライアントで再生されます。

GPU コンテナ仮想化ソリューションが使用される前は、複数のクラウド ゲーム インスタンスが、裸の混合競合方式で GPU レンダリング リソースを共有していました。サービス保証とリソース分離機能がなかったため、SLA を通じてゲーム体験を管理できなかったと言えます。

モバイル クラウド ゲームは ARM プラットフォーム上で実行されるため、クラウド ネイティブ AI プラットフォーム全体を ARM 上で実行できるようにするために、多くの新しいテクノロジ開発を行ってきました。

カーネル モード ソリューションを使用して、各 Android インスタンスを管理し、レンダリング メモリを分離し、メモリ割り当ての QoS を確保します。

では、このシナリオでは、カーネル モードの仮想化を使用してレンダリング能力とコーデックを分離してみませんか?クラウド ゲームではリアルタイム要件が高いため、カーネル モードの仮想化ではレイテンシ要件を満たすことができず、レンダリング分離はリアルタイム要件が低いシナリオに適しています。したがって、このシナリオでは、メモリ割り当ての QoS を確保するために、カーネル仮想化のメモリ分離機能のみが使用されます。

写真

本日私が皆さんにお伝えしたいのは以上です。