Baidu のディープラーニング プラットフォーム PaddlePaddle フレームワークの分析

PaddlePaddleは、Baiduが2016年8月末に一般公開したディープラーニングプラットフォームです。短期間で急速に世界的な開発ホットスポットとなり、Github Pull Requests数の成長率が最も高いオープンソースのディープラーニングプラットフォームとなりました。

PaddlePaddle は反復速度が非常に速く、コミュニティからも広く注目を集めています。最初にオープンソース化されたとき、PaddlePaddle の設計コンセプトはレイヤー設計に基づいていました。その後、「v2」と「Fluid」という 2 つのイテレーションがリリースされました。v2 では、レイヤーをより細かい粒度の演算子に「分割」する演算子の概念が追加され、より複雑なネットワーク トポロジ「グラフ」がサポートされました。Fluid は PyTorch に似ていますが、Python の制御フロー (if-else、for など) に依存せず、独自のインタープリターとコンパイラーも提供しているため、Python の実行速度に制限されません。

本日は、PaddlePaddleFluid の紹介から始まり、クラスタをより使いやすくするためにブラウザサイドでトレーニングできるように提供されている PaddlePaddleCloud についてお話します。また、PaddlePaddleEDL の部分であるクラスタトレーニングの原理、構成、実験結果についても重点的にお話します。 ***、非常に強力なトレーニング ログ解析および視覚化ツールである PaddlePaddleVisualDL について説明します。

パドルパドルフルイド

PaddlePaddleFluid は、高級言語と同様の制御フロー構造 (while、if、if-else、for など) を提供します。コンパイル最適化テクノロジを使用してコンピューティング パフォーマンスを確保するだけでなく、ユーザーの開発効率も向上します。

PaddlePaddleFluid の設計コンセプトは非常に高度であり、レイヤー構造とオペレータ構造モデルは使用されなくなりました。つまり、「モデル」という概念はなくなり、「グラフ」（演算子のグラフ）や「レイヤーのシーケンス」（レイヤーのシーケンス）もなくなります。 「プログラム」という概念だけがある。同時に、プログラムはグラフをエクスポートすることができ、ONNX ファイル形式のモデルをプログラムからエクスポートすることができます。

ディープラーニング インフラストラクチャは最も急速に進化するテクノロジーの 1 つであり、わずか 4 年で 3 世代のテクノロジーが発明されました。下の表からわかるように、ディープラーニング技術のアーキテクチャ設計の方向性は、モデルを徐々に排除することです。

Python 言語の強力なエコシステムに基づいて、PyTorch と Eager Execution の制御フローはすべて Python で記述されていますが、Python の実行速度が遅く、高速化が難しいというボトルネックがあります。 PyTorch や Eager Execution プログラムの実行速度が Python の実行速度によって制限されるという問題を解決するために、Fluid は PyTorch や Eager Execution よりもさらに革新的な技術的アイデアを持っています。 Fluid の設計では、実行時に記述された Python プログラムを protobuf メッセージとして出力し、その後、Python インタープリターではなく Fluid インタープリターを呼び出してこの protobuf メッセージを解釈して実行します。 Fluid インタープリターはグラフの実行を大幅に高速化します。同時に、コンパイルと実行の面では、protobuf メッセージを C++ プログラムに変換するトランスパイラを作成し、nvcc、icc、gcc を使用してバイナリ コードにコンパイルすることで、サーバーと携帯電話で直接実行できます。

パドルパドルクラウド

PaddlePaddle には、ブラウザーで JupyterNotebook プログラミングを使用して AI アプリケーションを開発するための Web ベースの IDE があります。その後、プログラムをクラウド (Kubernetes クラスター) に送信してデバッグまたは実行できます。プログラムの出力はブラウザーにリアルタイムで表示されます。これにより、ユーザーはパソコンやクラスターなどの複数のプログラミング環境を切り替える必要がなくなり、複数の環境のバージョンや構成の一貫性を保つことができるため、作業効率が大幅に向上します。

パドルパドルEDL

PaddlePaddle EDL は、Google KubeFlow に匹敵します。 PaddlePaddle EDLはKubernetesと連携することで、柔軟なジョブスケジューリングを実現します。これは、柔軟なジョブスケジューリングをサポートする世界初のオープンソースAIクラウドソリューションです。

現在、多くのディープラーニングアプリケーションは、数台のマシンからなる小規模なクラスターで解決できますが、データ量の増加と、Web 規模のアプリケーション (広告、検索、推奨など) やセンサーを通じて大量のデータを収集する無人車両などの AI アプリケーションシナリオの継続的な拡大に伴い、大規模なディープラーニングコンピューティング機能が必要になります。

ここでの主な目的は、ディープラーニングが直面する 2 つの大きな課題を解決することです。 1つは、大量の計算能力が必要になることです。研究室や企業では、SLURM、MPI、または SGE によって管理される GPU クラスターを構築することがよくあります。これらのクラスターは、送信されたジョブを実行するか (アイドル状態よりも少ないリソースが必要であると想定)、予測できない期間ジョブを一時停止します。しかし、このアプローチには欠点があります。利用可能なノードが 99 個あり、タスクに 100 個のジョブの送信が必要な場合、ジョブは待機する必要があり、実行できません。

PaddlePaddle EDL の柔軟なスケジューリングとは、トレーニング ジョブがアイドル状態のときにより多くのリソースを使用し、ビジー状態のときにより少ないリソースを使用することを意味しますが、リソースの変更によってジョブが失敗することはありません。これは、KubeFlow に対する利点の 1 つです。同時に、EDL は他のジョブ (Nginx、MySQL など) も柔軟にスケジュールするため、クラスターの全体的な使用率が大幅に向上します。 ^[2]これにより、パブリッククラウドやプライベートクラウドに導入する際にマシンの数を簡単に数倍節約でき、企業は年間数百万ドル、数千万ドルものコンピューティングコストを節約できます。

もう 1 つの課題は、産業ユーザーは、ログ コレクターなどの完全なデータ パイプラインのサブセット ステージとしてディープラーニング ジョブを実行する傾向があることです。この一般的なクラスターでは、優先度ベースの柔軟なスケジューリングが必要です。たとえば、ネットワーク オーバーヘッドが高い期間中はディープラーニング タスクの実行数が少なくなり、ネットワーク トラフィックが少ない場合はディープラーニング タスクが優先されます。これには、全体的な状況を理解し、さまざまなタスクに関連するプロセスの数を調整する必要があります。

パドルパドルEDLテスト実験

上記の両方の課題に直面しても、PaddlePaddle ジョブはプロセス数の変動に簡単に対処できます。 Fluid EDL のテスト ケースを 2 つ示します。

1. Kubernetes クラスターは PaddlePaddle ジョブのみを実行します。
2. クラスターは PaddlePaddle と Nginx ジョブを実行します。

最初のテストでは、10 秒間隔で 20 個の PaddlePaddle ジョブを開始しました。各ジョブには 60 個のトレーナーと 10 個のパラメータ サーバー プロセスがあり、数時間続きます。実験は 20 回繰り返しました。10 回は Fluid EDL をオフにし、10 回は Fluid EDL をオンにしました。下の図では、実線は最初の 10 回の実験に対応し、残りは破線です。図の上部では、EDL がない場合、未処理ジョブの数が単調に増加していることがわかります。ただし、EDL がオンの場合、リソースはすべてのジョブ間で均等に分散されます。 Fluid EDL は、他の新しいタスクのためのスペースを確保するために既存のプロセスの一部を終了し、後でタスクの実行を開始します。どちらの場合も、クラスターは均等に使用されています (図の下部を参照)。

2 番目のテストでは、各実験で 6 つの PaddlePaddle ジョブよりも高い優先度で 400 個の Nginx Pod を実行しました。最初は、各 PaddlePaddle ジョブには 15 個のトレーナーと 10 個のパラメーター サーバーがあります。残りが 100 個になるまで、90 秒ごとに 100 個の Nginx Pod を強制終了し、その後、90 秒ごとに Nginx ワーカーの数を 100 ずつ増やしていきます。下の図の上半分はこのプロセスを示しています。図の中央は、Fluid EDL が Nginx Pod を減らすことで一部の PaddlePaddle プロセスを自動的に開始し、その後 Nginx Pod を増やすことで PaddlePaddle プロセスを強制終了することを示しています。その結果、図に示すように、クラスターの使用率は約 90% に維持されます。 Fluid EDL がオフになっている場合、PaddlePaddle プロセスは自動的に追加されず、使用率は Nginx Pod の数に応じて変動します。

PaddlePaddleEDLの設計と実装

ディープラーニング サービスと他のクラウド サービス間でコンピューティング リソースを共有し、各タスクの優先順位を動的に調整およびスケーリングして、クラスターの CPU/GPU を最大限に活用するプロセスはどのように実現されるのでしょうか。

EDLとHPA

Horizo​​ntal Pod Autoscaling (HPA) は、Kubernetes が提供する柔軟なスケジューリング メカニズムです。その設計の出発点は、単一のコンピューティング タスクで各 Pod にコンピューティング リソースを公平に割り当てることにより、単一のタスクに対して分散システム リソースを最適に利用することです。ただし、トレーニング タスクは多様 (音声、画像など) で、異なる時間に展開され、リソース要件も異なります。そのため、この柔軟なスケジューリング メカニズムによって、各トレーニング タスクに必要なシステム リソースを全体的に把握し、必要に応じて割り当てることができることを期待しています。しかし、HPA コントローラーはまだ実装されていません。

同時に、HPA の弾性スケジューリングは、同じタイプのコンピューティング タスク (同種コンピューティング タスク) を実行する Pod を対象としています。しかし、ディープラーニング システムのコンピューティング ノードとパラメーター サーバーは、異なるタイプのポッドに存在することがよくあります。

上記の固有の要件では、Kubernetes を使用する場合に特定の弾性スケジューリング ソリューションが必要であり、HPA を直接使用することはできません。したがって、より良い解決策は PaddlePaddle EDL です。

PaddlePaddleEDLの具体的な設計と実装

1. Kubernetesがカスタマイズされた弾性スケジューリングメカニズムをサポートできるようにする

Kubernetes 自体はカスタマイズされたリソース管理メカニズムをサポートしています。ユーザーは、カスタマイズされたリソース宣言ファイルとコントローラー ファイルを送信することで、特定の Pod の柔軟なスケジュールを実装できます。次の図を例に挙げます。この training_job.yaml は、コントローラーが pserver を自動的に監視し、その数が min-instance と max-instance の間になるようにします。

Kubernetes クラスターでは、このカスタマイズされたリソースは、kubectl create -f training_job.yaml コマンドを通じて取得できます。次に、このリソースをスケジュールするには、カスタマイズされたトレーニング ジョブ コントローラーが必要です。

カスタマイズされたトレーニング ジョブ コントローラーはポッド内で実行され、クラスター リソースを統合的に認識します。Kubernetes API を通じてクラスター リソースを監視およびスケジュールします。次の図は、トレーニング ジョブ コントローラー構成ファイルの例です。

Kubernetes クラスターでは、このカスタム リソース管理 Pod は、kubectl create -f training_job_controller.yaml コマンドを通じて起動できます。

2. 制御プログラムの実装

現在、Kubernetes で上記のカスタマイズされたリソースを実装する方法は 2 つあります。 1 つは Kubernetes バージョン 1.7 で導入されたカスタム リソース定義 (CRD) であり、もう 1 つはサードパーティ リソース (TRP) です。 PaddlePaddle プロジェクトは現在 Kubernetes バージョン 1.6 を使用しており、TRP モデルを実装しており、将来的には CRD モデルを統合する予定です。

現在、PaddlePaddle は、実行されているトレーニング ジョブ コントローラーが 1 つだけであると想定しています。現在のトレーニング ジョブ コントローラーは、次のロジックに従ってリソースを管理します。

3. 弾性スケジューリングアルゴリズム

PaddlePaddle は、カスタマイズされたリソースの設定ファイル (training_job.yaml) に基づいて、ジョブが柔軟なスケジュールを必要とするかどうかを判断します。判断基準は、trainer と pserver の min-instance =/ max-instance です。

クラスター内のGPUのスケジュール

コントローラーは、クラスター内の GPU の合計数と現在アイドル状態の GPU の数を認識し、アイドル状態の GPU をすべて現在のトレーニング タスクに割り当てようとします。 PaddlePaddle は、GPU を必要とするトレーニング タスクの「達成スコア」を定義します。スコアの範囲は [0, 1] です。 PaddlePaddle は、満足度スコアが最も高いトレーニング タスクに GPU リソースを優先的に割り当てます。同点の場合は、GPU 要件、CPU 要件、メモリ要件が優先されます。特定のトレーニング タスクの GPU 最小インスタンスが満たされていない場合 (cur-instance=min-instance でない限り)、PaddlePaddle は満足度が最も高いトレーニング タスクから GPU リソースを取得し、そのタスクに割り当てます。最高度スコアのトレーニング タスク (cur-instance=min-instance) の場合、クラスター全体で新しいトレーニング タスクが実行されなくなり、新しいタスクは待機する必要があります。

クラスターにおける CPU スケジューリング

CPU リソースの割り当ては GPU の場合と同じです。コントローラーは、クラスター内の CPU とメモリの数、およびそれらの負荷状況を認識しており、トレーニング タスクの CPU 要件も認識しています。同様に、CPU リソースは満足度スコアに基づいてオンデマンドで割り当てられます。

パドルパドルフォールトトレランスメカニズム

ここでは、PaddlePaddle のフォールト トレランス メカニズムについて説明します。分散トレーニング タスクでは、マスター プロセスまたはすべてのパラメーター サービス プロセスが終了すると、トレーニング タスク全体が停止され、一定期間後に Kubernetes によって再起動されます。特定のトレーニング プロセスが終了していない場合は、トレーニング タスク全体が続行されます。

PaddlePaddle は etcd を使用してトレーニング プロセスのステータスを記録します。 etcd は信頼性の高い分散型キーバリューストレージです。トレーニングプロセスは定期的に自身のステータスを etcd に書き込み、この情報は必要に応じてトレーニングプロセスを復元するために使用されます。具体的なプロセスは以下のとおりです。

マスター プロセスが Kubernetes によって開始されると、次の処理が実行されます。

1. 複数のマスターインスタンスを回避するために、etcdから一意のマスターロックを取得します。
2. etcd にタスク キューがあるかどうかを確認します。存在しない場合は新しいタスクキューを作成します。そうでない場合はこのタスクキューの情報を取得します。
3. etcdのキー/master/addrに自分のIPアドレスを書き込み、自分自身と通信するための後続のトレーニングプロセスを容易にします。
4. ポートを開いて、トレーニング プロセスのタスク要件をリッスンします。トレーニング プロセスからタスク要求を受信した場合は、タスク キューからタスクを取得して割り当て、タスク キューを更新します。

マスター プロセスが何らかの理由で停止した場合、Kubernetes はそれを再起動します。このプロセスは、再起動から etcd 情報の取得、トレーニング プロセス タスクの取得まで、通常数分かかります。

トレーニングプロセス

Kubernetes によってトレーニング プロセスが開始されると、次の処理が実行されます。

1. etcd でパラメータ サービス プレフィックス /ps/ をチェックして、現在のパラメータ サービス プロセスの数を取得し、その数が構成ファイルの要件に達するまで待機します。
2. etcdの/master/addrキーからマスタープロセスのアドレスを取得します。
3. マスターにタスクリクエストを送信し、タスクに応じてトレーニングプログラムを開始します。

トレーニング プロセスが終了すると、Kubernetes はそれを再起動し、新しいプロセスは新しいトレーニング ジョブが開始するまで上記の作業を繰り返します。

パラメータサービスプロセス

Kubernetes によってパラメータ サービス プロセスが開始されると、次の処理が実行されます。

1. etcd/ps_desiredからトレーニングタスクに必要なパラメータサービスプロセスの数を読み取ります。
2. 必要なプロセス数よりも小さく、etcd /ps/<index> (/ps/0、/ps/1、...) に存在しない ID を見つけ、それを独自の ID として使用して etcd にこのエントリを作成します。 （下図参照）

3 番目のパラメータ サーバーが参加する場合:

3. パラメータサービスプロセスは、対応するetcdパスから既存のトレーニング結果パラメータを見つけ、それを読み込みます。

4. パラメータ サービス プロセスは、トレーニング プロセスからの要求の受信を開始します。

PaddlePaddle の視覚化 - PaddlePaddleVisualDL

PaddlePaddleVisualDL は、PaddlePaddle に付属する強力な視覚化ツールであり、Web アプリケーション スイートでもあります。 PaddlePaddleVisualDL は現在、SCALARS、IMAGES、GRAPHS、HISTOGRAMS の 4 種類の視覚化をサポートしています。これら 4 つの視覚化の主な機能は次のとおりです。

● スケーラブル: トレーニング中の精度、損失値、重み/バイアスの変化を表示します。

● 画像: トレーニングプロセス中に記録された画像を表示します。

● グラフ: モデルのデータフロー グラフと、各デバイスでのトレーニングで消費されたメモリと時間を表示します。

● ヒストグラム: トレーニング中に記録されたデータのヒストグラムを表示します。

PaddlePaddleVisualDL は、ポート 8080 をリッスンするローカル サーバーを実行します。ブラウザがリクエストを行うと、トレーニング中に記録されたデータが分析され、トレーニングプロセスの画像が描画されます。さらに、VisualDL は ONNX と互換性があります。Python SDK と組み合わせることで、VisualDL は PaddlePaddle、pytorch、mxnet、Caffe2 など、ほとんどの主流の DNN プラットフォームと互換性を持つようになります。 Tensorboard は現在、Tensorflow、Pytorch、MXNet などでのみ利用可能です。

PaddlePaddleVisualDL の視覚化インターフェースを下図に示します。

VisualDLの使用

VisualDL の使い方は非常に簡単で、次の 3 つの手順だけが必要です。

VisualDLの機能

VisualDL の主な機能は次のとおりです。

全体的なトレーニングの傾向を観察するのに便利なスカラー点線チャート表示をサポートします。

データサンプルの品質と中間トレーニング結果を表示するための画像をサポートします

パラメータの分布と変化の傾向を表示するためのヒストグラムをサポート

ディープニューラルネットワークのモデル構造を表示するためのグラフをサポート

要約する

PaddlePaddle に新しい機能が継続的に追加されることにより、科学研究と応用において大多数のユーザーに多大な助けをもたらすと信じています。ここでは、まずPaddlePaddleFluidについて説明し、次にクラスタをより簡単に利用できるようにブラウザ側でトレーニングできるように提供されているPaddlePaddleCloudについて説明します。また、PaddlePaddleEDLの部分であるクラスタトレーニングの原理、構成、実験結果にも焦点を当てます。 ***、非常に強力なトレーニング ログ解析および視覚化ツールである PaddlePaddleVisualDL について説明します。