推奨システムにおけるTensorFlowの分散トレーニング最適化の実践

著者 | Yifan、Jiaheng、Zhengshao など

Meituan の高度にカスタマイズされた TensorFlow バージョンは、ネイティブの TensorFlow 1.x アーキテクチャとインターフェースに基づいており、大規模なスパースパラメータのサポート、トレーニングモード、分散通信の最適化、パイプラインの最適化、演算子の最適化の融合など、複数の側面で高度に最適化されています。レコメンデーションシステムのシナリオでは、分散スケーラビリティが10倍以上向上し、ユニットコンピューティングパワーのパフォーマンスも大幅に向上し、Meituanの社内業務で広く使用されています。この記事では、関連する最適化と実践的な作業を紹介します。

1 背景

TensorFlow（以下、TF）は、Google がリリースしたオープンソースのディープラーニングフレームワークであり、Meituan のレコメンデーションシステムのシナリオで広く使用されています。ただし、TensorFlow の産業グレードのシナリオに対するサポートの公式バージョンは、現時点では特に完全ではありません。 Meituan は、大規模生産プロセス中に次のような課題に直面しました。

すべてのパラメータは変数として表現されるため、100 億を超えるスパースパラメータに大量のメモリが必要になり、リソースが無駄になります。
数百のワーカーの分散拡張のみをサポートしており、数千のワーカーに対するスケーラビリティは低いです。
大規模なスパースパラメータの動的な追加、削除、増分エクスポートをサポートしていないため、オンライン学習をサポートできません。
大規模クラスタで実行する場合、フレームワーク層が対応できないため、速度低下やダウンタイムが発生し、タスク動作異常を引き起こします。

上記の問題は TensorFlow の設計の問題ではなく、基礎となる実装に関するものです。多数の Meituan 企業の使用習慣とコミュニティの互換性を考慮して、大規模なスパースパラメータのサポート、トレーニングモード、分散通信の最適化、パイプラインの最適化、オペレータの最適化の融合など、ネイティブ TensorFlow 1.x アーキテクチャとインターフェイスを複数の側面から深くカスタマイズし、このシナリオの核心的な問題点を解決しました。まず、サポート機能の面では、新システムは現在、数千億のパラメータを持つモデルをサポートし、数千人のワーカーの分散トレーニングをほぼ線形に加速できます。1年分のサンプルデータのトレーニングを1日以内に完了でき、オンライン学習機能もサポートします。同時に、新システムのさまざまなアーキテクチャとインターフェースはよりユーザーフレンドリーになり、Meituan Takeout、Meituan Best Selection、Meituan Search、広告プラットフォーム、Dianping Feedsなど、Meituanの社内ビジネス部門で使用されています。この記事では、大規模な分散トレーニングの最適化の作業に焦点を当て、皆様のお役に立ち、刺激となることを願っています。

2 大規模なトレーニング最適化の課題

2.1 ビジネス反復がもたらす課題

Meituan のビジネスが発展するにつれて、以下に示すように、推奨システムモデルの規模と複雑さも急速に増大しています。

トレーニングデータ: トレーニングサンプルの数は数百億から数千億に増加し、ほぼ 10 倍に増加しました。
スパースパラメータ: 数は数百から数千に増加し、約 10 倍になりました。パラメータの総数は数億から数百億に増加し、10 倍から 20 倍になりました。
モデルの複雑さ: ますます複雑になり、モデルの単一ステップの計算時間は 10 倍以上増加しました。

トラフィック量の多いビジネスでは、トレーニング実験に数時間から数日かかることがあります。このシナリオでは、実験を 1 日以内に終わらせることが基本要件です。

2.2 システム負荷分析

2.2.1 問題分析ツールチェーン

TensorFlow は、数百万行のコードを含む非常に大規模なオープンソースプロジェクトです。ネイティブシステムの監視インジケーターは粗すぎて、グローバル監視をサポートしていません。複雑なパフォーマンスのボトルネックを見つけるのは困難です。 Meituanのオープンソース監視システムCAT[2]をベースに、TensorFlow用のきめ細かい監視リンクを構築しました（下図1参照）。これにより、パフォーマンスのボトルネックを正確に特定することができます。

図 1 TensorFlow PS アーキテクチャのフルリンクモニタリング同時に、パフォーマンス最適化プロセスには大量のパフォーマンステストと結果分析が含まれており、これも非常に労働集約的なタスクです。私たちは、複数のラウンドで自動的に実験を実行し、さまざまな監視指標を自動的に収集し、レポートを生成できる自動化された実験フレームワーク (下の図 2 を参照) を抽象化しました。

図2 自動化された実験フレームワーク

2.2.2 ビジネスの観点から見た負荷分析

推奨システムのシナリオでは、TensorFlow Parameter Server[3]（略してPS）の非同期トレーニングモードを使用して、ビジネスの分散トレーニング要件をサポートしました。このアーキテクチャでは、上記のビジネス変更によってどのような負荷の変化がもたらされるでしょうか?下の図3に示すように:

図 3 TensorFlow PS アーキテクチャの大規模トレーニング負荷分析の概要。主に通信圧力、PS 同時実行圧力、ワーカーコンピューティング圧力が含まれます。分散システムの場合、負荷の問題は通常、水平方向の拡張によって解決されます。問題は解決できそうに思えますが、実験結果から、PS を一定の数まで拡張すると、図 4 に示すように、1 ステップのトレーニング時間が長くなります。

図4 PSを延長することでトレーニングパフォーマンスを向上させる実験

この結果の主な理由は、ワーカーのシングルステップトレーニングは、すべての PS 通信と同期して完了する必要があることです。PS を追加するごとに N 個の追加通信リンクが必要になり、リンクの遅延が大幅に増加します (下の図 5 を参照)。トレーニングセッションでは、数百万または数千万ステップのトレーニングが必要になる場合があります。最終的に、リンク遅延は PS コンピューティングパワーの同時実行性を追加することによる利点を上回ります。

図 5 PS の増加によって生じるリンクオーバーヘッドこのシステムの場合、最適化の最大の難しさは、制限された PS インスタンスの下で分散コンピューティングを最適化する方法にあります。

3 最適化の実践

3.1 大規模スパースパラメータの紹介

レコメンデーションシステムモデルの場合、ほとんどのパラメータはスパースパラメータです。スパースパラメータの場合、非常に重要な操作は埋め込みです。この操作は通常、最も負荷が高く、その後の最適化の焦点となります。スパースパラメータを再定義し、その後の最適化はこれに基づいて行われるため、まずこの作業部分を紹介します。ネイティブ TensorFlow で埋め込みモジュールを構築するには、まずすべてのスパースパラメータを保持するのに十分な大きさの変数を作成し、次にこの変数に対して埋め込み学習を実行する必要があります。ただし、埋め込みトレーニングに変数を使用すると、多くの欠点があります。

変数のサイズは事前に設定する必要があります。変数の数が数百億または数千億になるシナリオでは、この設定により膨大なスペースが無駄になります。
トレーニング速度が遅く、スパースモデル向けにカスタマイズできません。

まず、スパースな特徴 ID をキーとして、埋め込みベクトルを値として、変数の代わりにハッシュテーブルを使用することで、存在または非存在の問題を解決しました。埋め込みに変数を使用するネイティブメソッドと比較すると、次の利点があります。

ハッシュテーブルのサイズはトレーニングプロセス中に自動的に拡大または縮小できるため、余分なストレージスペースを確保する必要がなくなります。同時に、ユーザーはアプリケーションのサイズを気にする必要がないため、使用コストが削減されます。
HashTable ソリューションには一連のカスタマイズされた最適化が実装されており、Variable と比較してトレーニング速度が大幅に向上しています。数千億規模のモデルをトレーニングでき、優れたスケーラビリティを備えています。
スパースパラメータの動的スケーリングのおかげで、これに基づいてオンライン学習をサポートします。
API はコミュニティバージョンと互換性があるように設計されており、使用方法はネイティブ変数とほぼ同じで、統合コストが非常に低くなっています。

簡略化された PS アーキテクチャベースの実装を以下の図 6 に示します。

図 6 大規模なスパースパラメータをサポートする HashTable ソリューションのコアプロセスは、おおよそ次の手順に分けられます。

スパースな特徴 ID (通常は事前に統合エンコード作業を完了します) は、埋め込みモジュールに入ります。TensorFlow によって構築された Send-Recv メカニズムの助けを借りて、これらのスパースな特徴 ID は PS エンドに引き出されます。PS エンドの Lookup などの演算子は、実際に基礎となるハッシュテーブルから埋め込みベクトルを照会して組み立てます。
上記の埋め込みベクトルは、後続のトレーニングのためにワーカーによって引き戻され、これらのパラメータの勾配はバックプロパゲーションによって計算されます。これらの勾配は、PS 側のオプティマイザーによってさらに引き戻されます。
PS 側のオプティマイザーは、まず Find 演算子を呼び出して、勾配に対応する元のスパースパラメーターベクトルと、対応するオプティマイザーパラメーターを HashTable から取得します。最後に、最適化アルゴリズムによって、埋め込みベクトルとオプティマイザーパラメーターの更新計算を完了し、Insert 演算子によってそれらを HashTable に挿入します。

3.2 分散負荷分散の最適化

最適化のこの部分は、分散コンピューティングの古典的な最適化の方向性です。 PS アーキテクチャは典型的な「バケットモデル」です。トレーニングステップを完了するには、ワーカーがすべての PS と対話する必要があるため、PS 間のバランスが非常に重要です。しかし、実際には、複数の PS の時間消費が不均一であることがわかりました。その理由としては、TensorFlow PS アーキテクチャの単純なグラフスライスロジック (ラウンドロビン) によって生じる負荷の不均衡と、異機種マシンによって生じる不均衡が挙げられます。推奨モデルの場合、主な最適化戦略は、すべてのスパースパラメータと大きな密なパラメータを各 PS に自動的に均等に分割することであり、これによりこれらの問題のほとんどを解決できます。実際には、トラブルシューティングが難しい問題も見つかりました。ネイティブ Adam オプティマイザーの実装により、PS 負荷の不均衡が発生するのです。以下、詳しく紹介します。 Adam オプティマイザーでは、そのパラメータ最適化プロセスでは、計算に参加するために 2 つの β が必要です。ネイティブ TensorFlow 実装では、これらの 2 つの β は、このオプティマイザーによって最適化される必要があるすべての Variabl (または HashTable) で共有され、最初の Variable (名前の辞書順) と同じ PS に配置されます。これにより問題が発生します。各オプティマイザーにはβとβが 1 つずつしかなく、それらは特定の PS にのみ配置されます。したがって、パラメータ最適化プロセス中、この PS は他の PS よりもはるかに高い要求を処理することになり、この PS がパフォーマンスのボトルネックになります。

図 7 Adam 最適化アルゴリズムただし、Adam 最適化アルゴリズムを観察すると、 βとβは定数であり、青で強調表示された部分は比較的独立した計算プロセスであり、各 PS によって独立して完了できることがわかります。この発見に基づいて、最適化方法は非常に直感的になりました。各 PS 上の Adam オプティマイザーの β パラメーターを冗長的に作成し、t 値と alpha 値をローカルで計算することで、不均一な負荷によって発生する PS ホットスポットの問題を排除します。この最適化によってもたらされる改善は普遍的かつ効果的です。Meituan 内の特定のビジネスモデルでは、β ホットスポットを削除すると 9% のパフォーマンス向上がもたらされます。さらに、β への全体的な依存性がなくなるため、この最適化により PS アーキテクチャのスケーラビリティが向上し、ワーカー数を増やすときに加速率が向上します。

3.3 通信の最適化

セクション 2.2 の分析から、システムの通信圧力も非常に高いことがわかります。主に RDMA に基づいて通信を最適化しました。まず、RDMAについて簡単に紹介します。ソケットTCP/IPプロトコルスタックに基づく従来の通信プロセスと比較して、RDMAにはゼロコピーとカーネルバイパスの利点があり、ネットワーク遅延が短縮されるだけでなく、CPU占有率も削減されます。RDMAは、ディープラーニングモデルの関連通信プロセスに適しています。 RDMA には主に、Infiniband、RoCE (V1、V2)、iWARP の 3 つのプロトコルが含まれます。 Meituan 内のディープラーニングシナリオでは、RDMA 通信プロトコルは RoCE V2 プロトコルを使用します。現在、ディープラーニングトレーニングの分野、特に高密度モデルトレーニングシナリオ（NLP、CV など）では、RDMA が大規模分散トレーニングの標準となっています。しかし、大規模なスパースモデルのトレーニングでは、オープンソースシステムではRDMAのサポートが非常に限られています。TensorFlow Verbs[4]通信モジュールは長い間更新されておらず、通信効果は理想的ではありません。これに基づいて多くの改善を行ってきました。最適化されたバージョンでは、1TBのClick Logs[5]パブリックデータセット、DLRM[6]モデル、100人以上のワーカーでトレーニングした場合、パフォーマンスが20%～40%向上しました。美団の複数のビジネスモデルでは、TensorFlow Seastar[7]によって変換された通信層の実装により、10％から60％の速度向上も達成されました。同時に、私たちは私たちの仕事を地域社会に還元しています。

3.3.1 メモリ登録の最適化

RDMA には、SEND/RECV、WRITE、READ の 3 つのデータ転送モードがあります。WRITE と READ は、データ送信者がリモートメモリを直接読み書きするのと似ており、受信側はそれを認識できません。WRITE と READ は、バッチデータ転送に適しています。 TensorFlow では、RDMA ベースのデータ転送方式では WRITE 単方向通信モードが使用されます。

図8 RDMA転送方式 RDMAでデータ転送を行う場合、ネットワークカードが直接この空間を操作できるように、事前にメモリ空間を開放し、ネットワークカードデバイスに登録しておく必要があります（メモリ登録処理、以下MRと略します）。新しいメモリを開いてデバイスに登録するプロセス全体に時間がかかります。下の図 9 は、さまざまなサイズのメモリをネットワークカードデバイスにバインドするのにかかる時間を示しています。登録されているメモリが増えると、MR のバインドにかかる時間が急激に長くなることがわかります。

図 9 MR プロセスのオーバーヘッド Tensorflow RDMA 実装のコミュニティバージョン。テンソルの作成では引き続き統合 BFC アロケータが使用され、作成されたすべてのテンソルが MR に登録されます。前述のように、MR 登録とバインディングにはパフォーマンスのオーバーヘッドがあり、高頻度および大空間の MR 登録は大幅なパフォーマンスの低下につながります。トレーニングプロセスにおけるテンソルについては、ノード間通信に関与するテンソルのみを MR に登録する必要があり、残りのテンソルは MR に登録する必要はありません。したがって、最適化の方法は比較的簡単です。通信テンソルを識別して管理し、ノード間で通信するテンソルに対してのみ MR を登録します。

3.3.2 RDMA静的アロケータ

RDMA 静的アロケータは、以前の MR 登録最適化の拡張です。メモリ登録を最適化し、送信されないテンソルの MR 登録を削除することで、MR 登録の数を削減しました。しかし、スパースシナリオの大規模なトレーニングでは、数百または数千のワーカーが並行してトレーニングすることが多く、次のような新たな問題が発生します。

PS アーキテクチャ内の PS とワーカーは、互いにクライアントサーバーです。PS 側を例にとると、ワーカーの数が数千に増加すると、ワーカー数の増加により PS 側の MR 登録頻度が非常に高くなり、メモリ割り当て登録にかかる時間が増加します。
同じ演算子の出力テンソルの形状はスパースシナリオの異なるステップ間で変化する可能性があるため、作成された MR の再利用性が低くなり、メモリの断片化が大きくなり、MR 登録のオーバーヘッドが繰り返されます。

上記の問題を解決するために、MR 静的アロケータ戦略を導入しました。

図10 MR静的アロケータ

ここでの中核となる設計アイデアは次のとおりです。

スパースシナリオでは、同じ演算子によって出力される Tensor の形状が変わる可能性がありますが、全体的な変化の範囲は制御可能です。監視と分析を通じて、複数のステップ間の Tensor のストレージ要件を満たす比較的安定したメモリサイズを見つけることができます。
上記の情報に基づいて、各テンソル（リクエスト）の元の MR アプリケーション戦略を変更しました。一度に大きなスペースを申請し、ネットワークカードに登録しました。その後、独自の割り当て戦略を通じてスペースを割り当てました。これにより、MR アプリケーションの頻度が大幅に削減されました。ほとんどの場合、トレーニングプロセス全体で必要な MR 登録アプリケーションは 1 つだけです。
送信されたテンソルのシェイプとデータを一緒にパッケージ化し、クライアントに書き込むためのシンプルな交換プロトコルを導入しました。クライアントはプロトコルに従ってテンソルのサイズを解析し、最終的にデータを読み取ります。これにより、ネイティブ実装でのテンソルの形状の変更によって発生する複数のネゴシエーションプロセスを回避できます。

図 11 MR 静的アロケータの構築プロセス。実装では、割り当て分析モジュールを導入しました。トレーニングの開始時に、履歴割り当てデータを分析して、実際に事前に開かれた MR サイズと各テンソルの予約済みスペースサイズを取得します。次に、トレーニングプロセスを一時停止し、MR の作成と通信の両端間の情報の同期を含むアロケータ構築プロセスを開始します。関連情報を使用して MR 情報マップを構築します。このマップのキーは、送信されたテンソルの一意のマーク (ParsedKey、グラフカットの計算時に決定) です。情報構造には、ローカルアドレスポインター、オフセットサイズ、ibv_send_wr 関連情報などが含まれます。その後、トレーニングを再開すると、その後の Tensor の送信は静的に開かれた MR を使用して送受信されるようになり、これにより、Shape の変更によって発生する複数のネゴシエーションプロセスも回避されます。

3.3.3 マルチリクエストバッファとCQ負荷分散

TensorFlow Community Edition の RDMA 通信プロセスには、上記の Tensor データの送受信プロセスだけでなく、伝送関連の制御メッセージの送受信プロセスも含まれます。制御メッセージの送受信プロセスでは、ibv_post_send および ibv_post_recv プリミティブも使用されます。ネイティブ制御フローの実装にはいくつかのボトルネックがあり、大規模なトレーニング中に制御フローのスループットが制限され、データの送受信の効率に影響します。具体的には以下の点に反映されています。

リクエストは同じ RequestBuffer メモリを通じて書き出されます。複数のクライアントリクエストはすべてこのバッファに依存しているため、制御フロー情報は実際にはシリアルに送信されます。相手側からの Ack 情報を受信した後にのみ、次のリクエストを書き出すことができるため、リクエスト送信スループットが制限されます。
クライアントは、要求の到着と関連するステータスの変更を取得するために、RDMA 完了キューをポーリングする必要があります。ネイティブ実装には完了キューが 1 つしかなく、ポーリングもシングルスレッドであるため、大規模な分散トレーニングでは応答の効率が制限されます。

上記の問題に対処するために、Multi RequestBuffer と CQ 負荷分散最適化を使用して、リクエスト送信段階とリクエスト応答段階に存在する可能性のあるスループットのボトルネックを排除しました。

3.3.4 送信駆動とランデブーバイパス

Tensorflow PS アーキテクチャに精通している人は、計算グラフ全体が Worker 側と PS 側に分割された後、Rendezvous メカニズムに基づく非同期データ交換モードが確立され、2 つの計算グラフが相互にデータを交換できるようになることを知っているでしょう。下の図12に示します。

図 12: TensoFlow グラフスライシングの Send-Recv ペア。上図のグラフスライシングロジックに基づくと、Recv 演算子は計算グラフのこちら側での Tensor の需要を表し、Tensor のプロデューサーは、それとペアになっている他のデバイス上の Send 演算子の後ろにあります。具体的な実装としては、Tensorflow は Recv 駆動型データ交換モードを実装しています。上図に示すように、DeviceA と DeviceB にある 2 つの計算グラフは非同期かつ同時に実行されます。DeviceB にある Recv が実行されると、DeviceA に対して RPC 要求が開始されます。要求を受け取った後、DeviceA は要求を Rendezvous にルーティングします。必要なデータが Send オペレータによって生成され登録されていることが判明した場合、その場でデータを取得して DeviceB に返します。この時点でデータが生成されていない場合、DeviceB からの Recv 要求は Rendezvous に登録され、DeviceA が後で生成するのを待機し、その後 Send オペレータによって送信されて登録された Recv を見つけ、コールバックをトリガーし、データを DeviceB に返します。ランデブーポイントメカニズムは、プロデューサーとコンシューマーのリズムが異なる場合にデータ交換の問題を巧みに解決することがわかります。ただし、Recv-Driven モデルでは、次の 2 つの潜在的な問題も発生します。

我々の観察によると、実際のビジネスモデルでは、Rendezvous では、Recv オペレータが Send オペレータを待つ割合は、Send オペレータが Recv オペレータを待つ割合と同等です。つまり、Send が Recv を待つデータについては、Send の準備ができた瞬間に相手に送信できます。しかし、メカニズムの実装の問題により、データを戻す前に Recv オペレータが来るのを待つ必要があり、通信プロセスに時間がかかります。
データ交換のホットスポットとして、Rendezvous には高い内部ロジックのオーバーヘッドがあります。

上記の問題に対処するために、Send-Driven モードと呼ばれる別のデータ交換モードを RDMA に実装しました。 Recv-Driven モードとは対照的に、名前が示すように、Send オペレータは Recv エンドにデータを直接書き込み、Recv エンドはデータを受信してローカル Rendezvous に登録し、Recv オペレータはローカル Rendezvous から直接データを取得します。具体的なプロセスを以下の図 13 に示します。

図 13 ネイティブ Recv-Driven と補助的な Send-Driven メカニズム図からわかるように、Recv-Driven モードと比較して、Send-Driven モードの通信プロセスは大幅に簡素化されています。また、準備ができたらすぐにデータを送信する機能により、一方の Rendezvous をスキップし、プロデューサーがコンシューマーよりも先行している場合、コンシューマー側のデータ取得速度を高速化できます。

3.4 レイテンシの最適化

最適化のこの部分は、分散コンピューティングの古典的な最適化の方向でもあります。プロセスチェーン全体の中で、合理化、統合、重複化できる領域を継続的に調査する必要があります。機械学習システムの場合、他のシステムと比較して、この部分の作業を実行するためにいくつかの近似アルゴリズムを使用できるため、大幅なパフォーマンスの向上が実現します。以下は、これら 2 つの側面で私たちが行った最適化の実践の一部です。

3.4.1 スパースドメインパラメータ集約

HashTable を有効にしてスパースパラメータを保存した後、サポートパラメータの一部も HashTable 実装に置き換える必要があります。このようにして、計算グラフ全体に複数の HashTable と多数の関連演算子が表示されます。実際には、PS 負荷と RPC QPS を削減するには、Lookup/Insert などの演算子の数をできるだけ減らす必要があることがわかりました。そのため、スパースモデルの一般的な使用法に関する適切な集約作業を実施しました。 Adam オプティマイザーを例にとると、最適化で運動量情報を保存するために 2 つのスロットを作成する必要があります。その形状は Embedding と同じです。ネイティブオプティマイザーでは、これら 2 つの変数は別々に作成され、逆勾配更新中に読み書きされます。同様に、HashTable ソリューションを使用する場合は、m パラメータと v パラメータをトレーニングするために、2 つの個別の HashTable を同時に作成する必要があります。次に、順方向と逆方向で、それぞれ埋め込み、m、v に対してルックアップと挿入を実行する必要があります。合計で 3 つのルックアップと 3 つの挿入が実行されます。ここでの最適化ポイントの 1 つは、埋め込み、m、v、および低頻度フィルタリングのカウンター (下の図 14 のカウントハッシュテーブルを参照) をハッシュテーブルの値としてまとめて集約し、スパースパラメーターに対する関連操作を集約的に実行できるようにすることです。これにより、スパースパラメーター操作の頻度が大幅に削減され、PS への負荷が軽減されます。

図 14 ハッシュテーブルに基づくパラメータ融合戦略この機能は普遍的な最適化です。集約機能を有効にすると、トレーニング速度が大幅に向上します。パフォーマンスの向上はモデルとワーカーの規模によって変化し、効果は常にプラスです。美団の実際のビジネスモデルでは、集約後のパフォーマンスは非集約方式と比較して約45％向上できます。

3.4.2 埋め込みパイプラインの最適化

工業生産において、組立ラインとは、作業効率と生産量を向上させるために、各生産ユニットが作業の特定の部分の処理のみに集中する生産方法を指します。コンピュータの分野では、パイプラインは複数のタスク間の重複実行のための並列化技術を表すものとしてよく知られています。たとえば、一般的な RISC プロセッサでは、ユーザーのプログラムは多数の命令で構成されており、命令の実行は、命令フェッチ、デコード、実行、メモリアクセス、書き戻し、その他のリンクに大まかに分けられます。これらのリンクは、命令キャッシュ、データキャッシュ、レジスタ、ALU などのさまざまなハードウェアユニットを利用します。各命令サイクルでは、これら 5 つのリンクのハードウェアユニットが並列に実行され、ハードウェア機能を最大限に活用して、プロセッサ全体の命令スループットパフォーマンスが向上します。プロセッサの命令パイプラインは複雑かつ体系的な基盤技術ですが、そのアイデアは次のような分散型ディープラーニングフレームワークでも広く使用されています。

分散トレーニングを単純にコンピューティングと通信の 2 つのプロセスに抽象化する場合、ほとんどの主流のディープラーニングフレームワークは、計算グラフ DAG を実行するときに通信とコンピューティングのオーバーラップをサポートします。
ディープモデルのトレーニングを単純に順方向と逆方向に分割すると、強い依存性があるため、1つのステップ内で効果的に並列化することはできません。BytePS[8]で導入された通信スケジューリングは、ステップ反復間の障壁を打ち破ります。前のラウンドの一部のパラメータが更新された後、次のラウンドの順方向計算を事前に開始できるため、全体的な観点から順方向と逆方向の重なりが強化されます。
CTRシナリオでのGPUトレーニング中に、パラメータはメインメモリに配置されているが計算はGPUに配置されているという問題を解決するために、Baidu AIBox[9]は異なるハードウェアデバイスを巧みにスケジュールし、CPU /メインメモリ/ネットワークカードを主に使用するパラメータ準備ステージと、GPU / NVLinkを主に使用するネットワーク計算ステージを構築します。2つのステージのオーバーラップにより、より高いトレーニングスループットが実現されます。

ディープラーニングフレームワークの設計では、シナリオを分析することで、さまざまな観点から並列ステージを発見し、全体的なトレーニングスループットを向上できることがわかりました。大規模なスパースモデルをトレーニングする場合、コアモデルプロセスは、最初にスパースパラメーターの埋め込みを実行し、次にサブネットワークの密な部分を実行するというものです。スパースパラメータの埋め込みは、主にネットワークリソースを消費するリモート PS 上で実行されますが、サブネットワークの密な部分は、主にコンピューティングリソースを消費するローカルワーカー上で実行されます。これら 2 つの部分はプロセス全体の時間の大部分を占め、Meituan の実際のビジネスモデルでは、消費される時間はそれぞれ 40% 以上と 50% 以上です。では、事前にスパースパラメータ埋め込みを実行して、通信と計算の重複を実現し、この部分の時間を隠すことはできるでしょうか?システム実装の観点からは確かに実現可能ですが、アルゴリズムの観点からは、そうすることでパラメータの古さの問題が発生し、モデルの精度に影響する可能性があります。しかし、実際の運用シナリオでは、大規模な非同期トレーニング自体が数十から数百ステップの遅延問題を引き起こします。私たちのテストによると、1 ステップまたは 2 ステップ前にスパースパラメータを取得しても、モデルの精度には影響がありませんでした。具体的な実装としては、計算グラフ全体を埋め込みグラフ (EG) とメイングラフ (MG) の 2 つのサブグラフに分割します。2 つのサブグラフは非同期かつ独立して実行され、分割プロセスの重複を実現します (分割プロセス全体をユーザーに対して透過的にすることができます)。 EG は主に、サンプルからの埋め込みキーの抽出、埋め込みベクトルのクエリとアセンブル、および埋め込みベクトルの更新をカバーします。 MG には主に、密部サブネットワーク計算、勾配計算、密パラメータ部更新などのリンクが含まれます。

図 15 埋め込みパイプラインモジュール間の相互作用関係 2 つのサブグラフ間の相互作用関係は次のとおりです。EG は埋め込みベクトルを MG に渡します (MG の観点からは、密な変数から値を読み取ります)。MG は埋め込みパラメータに対応する勾配を EG に渡します。上記の 2 つのプロセスは、どちらも TensorFlow 計算グラフとして表現されます。2 つのスレッドと 2 つのセッションを使用して 2 つの計算グラフを同時に実行し、2 つのステージが重複するようにすることで、より高いトレーニングスループットを実現します。

図 16: 埋め込みパイプラインアーキテクチャのフローチャート上の図は、埋め込みパイプラインのアーキテクチャフローチャートです。直感的に見ると、左側のサンプル配布モジュール、上部のセッション間データ交換モジュール、自動グラフ分割によって得られた埋め込みグラフとメイングラフに分かれています。青い円は新しく追加された演算子、オレンジ色の矢印はEGキープロセス、青い矢印はMGキープロセス、赤い矢印はサンプルデータキープロセスを表しています。

パイプラインデータセットと呼ばれる抽象的なレイヤーは、ユーザー透過形式で導入されています。さらに、パイプライン全体のデータを相互に互換性のあるものにするために、この部分はグローバルバッチIDの生成と登録も担当しています。パイプラインデータセットは、2つのイテレータをEG用、もう1つはmg用に公開します。パイプラインデータセットの下部は、Tensorflowの各層のネイティブデータセットを共有しています。
上部のExchangeManagerは、データ登録とデータ検索機能を公開する静的なクロスセッションデータ交換媒体です。このモジュールを抽象化する理由は、EGとMGが元々1つの計算グラフに属していたが、このようにして2つのグラフに分割されたため、セッションのデータ交換メカニズムを確立し、それらを正確に一致させる必要があります。グローバルバッチIDを内部的にキーとして使用し、サンプルデータを管理し、ベクトルの埋め込み、勾配の埋め込み、一意後のインデックス、およびその他のデータを管理し、このデータのライフサイクル管理を担当します。
中央の埋め込みグラフは、独立したスレッドで独立したTFセッションによって実行されます。これは、機能IDを抽出し、ハッシュテーブルメソッドに基づいてスパースパラメータークエリを実行します。 EGには、逆更新用のF演算子も含まれています。これは、ExchangeManagerから埋め込み勾配と対応する前方パラメーターを取得し、Gradient Updateパラメーターロジックを実行します。
以下のメイングラフは、密集したサブネットワークの実際の計算を担当します。さらに、普及可能な登録の逆の方法で、Eオペレーターを追加して、EGのFオペレーターによる消費のために埋め込み勾配を取引所に追加できるようにしました。

上記の設計により、制御可能なEG/mgの並行パイプライントレーニングモードを構築しました。一般的に、埋め込みパイプライントレーニングモデルの収入源は次のとおりです。

複数のビジネスモデルのプロファイリング分析により、EGとMGの時間比は約3：7または4：6であることがわかりました。
Tensorflowエンジンで複数のオプティマイザー（スパースおよび非スパース）を使用すると、逆の計算グラフを繰り返し構築する問題が発生し、この問題をある程度避けることができます。
実装プロセス中、ExchangeManagerは、埋め込みパラメーターと勾配の交換に責任を負うだけでなく、メタデータの再利用管理の責任を引き受けます。たとえば、一意などの演算子の結果が保存され、繰り返し計算がさらに減少します。

さらに、API設計の観点から、ユーザーへの埋め込みパイプライン関数を有効にするために、ユーザーへの透明性を達成しました。現在、Meituanのビジネストレーニングでは、埋め込みパイプライン関数は、CPU PSアーキテクチャの下で20％〜60％のパフォーマンス改善をもたらす可能性があります（ワーカーの同時尺度が大きいほど、パフォーマンスが向上します）。

3.5単一インスタンスPS並行性の最適化

セクション2.2の分析によると、単一インスタンスPSの並行性の最適化によって、分散タスクのスループットを改善できないことがわかります。主な最適化作業は次のとおりです。

3.5.1高性能ハッシュテーブル

PSアーキテクチャでは、大規模なスパースモデルトレーニングには、ハッシュテーブルの同時読み取りと執筆のための非常に高い要件があります。これは、数百人または数千人の労働者の埋め込み圧力を負担しなければならないため、TBB :: concurrent_hash_map [10]を包括的な実装として包括的に検討します。テスト後、TBBCONRENTHASHTABLEは、数億スケールでトレーニング速度でネイティブの変動ハッシュテーブルの3倍速いです。

3.5.2ハッシュテーブルバケットプール

大規模なスパースモデルトレーニングの場合、ハッシュテーブルの埋め込みは、プロファイリングを介して多数の同時操作に直面します。メモリプーリングのアイデアに基づいて、ハッシュテーブルのメモリ管理を最適化しました。ハッシュテーブルを初めて作成すると、それぞれのプールがそれぞれバックアップのために大きなメモリを作成します。キーと値が内部ハッシュテーブルデータ構造に挿入されるたびに、キーと値のメモリとリリースの割り当てがプールで管理されます。この方法により、大規模なスパーストレーニングで遭遇するまばらなメモリ割り当てオーバーヘッドが減少し、全体的なエンドツーエンドトレーニングパフォーマンスが約5％向上します。

図17ハッシュテーブルメモリ最適化

3.6ユニットコンピューティング電力スループットの最適化

セクション2.2の分析によると、労働者のコンピューティング圧力も非常に高く、スループットを維持する必要があります。ユーザーの場合、限られたコンピューティングリソースでパフォーマンスを向上させることができれば、ビジネス価値が向上します。 CATを使用して、いくつかの高周波演算子を数え、特別な最適化を実施しました。ここでは、共有のための一意のダイナミックパーティションオペレーターフュージョンケースを選択します。 Tensorflow PSアーキテクチャでは、埋め込みベクターを含む共有パラメーターがPSに保存され、通常はネットワークを介してワーカーと対話します。

スパースパラメーターの性質により、サンプルから抽出される埋め込みIDの繰り返しは70％〜90％になります。したがって、クエリする前に、通常、一意の操作が実行されます。
大規模なスパースシナリオでは、数千億のパラメーターを保存するために、ワークロードを共有するために複数のPSマシンを使用します。ワーカー側は、通常、セットルーティングルールに従ってクエリリクエストを分割する責任があります。

通常、これらの2つのプロセスは、Tensorflowで既存のオペレーターを使用して構築されますが、実際に使用すると、主な問題はあまり効率的ではありません。

一意の演算子はネイティブに実装されており、内部で使用するメモリ割り当て戦略は比較的非効率的です。入力パラメーターの2倍のサイズ（埋め込みID）はメモリの割り当てに使用されますが、入力パラメーターのサイズが大きく、繰り返し速度が高いため、作成されたハッシュテーブルは大きすぎて非常にまばらです。ほぼすべての挿入がMinor_Page_Faultを生成し、ハッシュテーブル性能が低下します。 Intel Vtuneを使用してこれを検証しました（図18を参照）。
一意で動的なパーティション演算子は、冗長なデータトラバーサルを持っています。

図18は、一意の演算子内で発生します。ハッシュテーブルが大きすぎると、ハッシュテーブルが小さすぎると容量の拡大につながる可能性があります。ヒューリスティックアルゴリズムに基づいたメモリアダプティブオペレーターの実装を採用します。さらに、埋め込みIDを中心にオペレーターのマージを実行し、論理実装を簡素化しました。上記の最適化により、ユニークな単一オペレーターは51％の加速を達成でき、実際のモデルのエンドツーエンドで約10％のパフォーマンス改善を達成でき、演算子の総数は4％削減されます。主要なオペレーターの最適化の全プロセスでは、Intel CompanyのLin Lifan、Zhang Xiangze、およびGao Mingが多くの技術サポートを提供しました。

4大規模なスパースアルゴリズムモデリング

大規模なスパース機能の過程で、非常に良い結果を得るには、特性とモデル構造からそれに応じてアルゴリズムレベルをアップグレードする必要があります。その中で、テイクアウト広告はビジネス特性から始まり、大規模なスパース機能を導入して、テイクアウトシナリオの機能システムのアップグレードを完了し、より高次元の特徴スペースとパラメータースペースを提供し、モデルのフィッティング能力を高めます。高次元のスパースシナリオの機能コーディングスキームは、機能コーディングプロセスの機能競合の問題を解決すると同時に、いくつかの冗長機能のハッシュ操作を削除し、特定の処理ロジックを削除し、時間帯の特徴計算を削減します。システムレベルでは、100億パラメーターと100億サンプルを備えた大規模なスパースモデルのトレーニングは、トレーニング反復の効率を大幅に低下させ、1日以内から1週間以内に1つの実験が増加します。上記のTensorflowフレームワークの最適化に加えて、Meituan Machine Learning Platform Training Engine Teamもビジネスモデルの特別な最適化を実施し、全体的なスループットが8〜10回最適化されました（より多くのコンピューティングリソースがさらに加速されると、さらに加速できます）。

5つの概要と見通し

Tensorflowは大規模な推奨システムで広く使用されていますが、大規模な分散トレーニング機能の欠如はビジネスの発展を妨げています。 Tensorflowネイティブアーキテクチャに基づいて、Meituanは大規模なスパース機能をサポートし、複数の角度から詳細な最適化を実施して、1000億パラメーターと1000億サンプルの効率的な分散トレーニングを実現し、Meituan内の大規模に使用されています。 Tensorflowコミュニティは、このような重要な能力の欠如にも共鳴しました。 Meituanのモデルトレーニングでは、システムシナリオは現在主にCPUで実行されていることを推奨していますが、ビジネスの開発により、一部のモデルはますます複雑になり、CPUで最適化する余地があることが困難です（最適化されたCPU使用率は90％を超えています）。近年、GPUコンピューティングパワーは、NVIDIA A100 GPUの新世代のコンピューティングパワー（TF32テンソルコア）、80gのビデオメモリ、およびカード間で600GB/sに達しました。このタイプの複雑なモデルのために、A100 GPUアーキテクチャに基づいて、次世代の分散トレーニングアーキテクチャを設計しました。