大規模機械学習フレームワークの4つのレベル

[[208759]]

1. 背景

Google が GFS、MapReduce、BigTable に関する 3 つの有名な論文を発表して以来、インターネットは正式にビッグデータの時代に入りました。ビッグデータの最も注目すべき特徴は、それが巨大であることです。それはどこにでも存在します。この記事では、主に、大量のデータを機械学習で処​​理する過程で発生するアーキテクチャ上の問題を体系的に整理します。

GFS では、オンライン広告の露出やクリックデータなど、当然ながらポジティブサンプルとネガティブサンプルの特性を持つ膨大なデータサンプルを蓄積することができます。1～2 か月蓄積すると、数百億、数千億のトレーニングサンプルを簡単に取得できます。これほど大量のサンプルをどのように保存するのでしょうか。膨大なサンプルから有用なパターンを学習するには、どのようなモデルを使用すればよいのでしょうか。これらの疑問は、エンジニアリングの問題であるだけでなく、アルゴリズムに取り組むすべての学生が深く考える価値のある問題でもあります。

1.1 単純なモデルか複雑なモデルか

ディープラーニングの概念が提案される前は、アルゴリズムエンジニアが利用できるツールは多くありませんでした。LR、SVM、パーセプトロンなど、比較的固定されたモデルとアルゴリズムがいくつかあるだけでした。当時、実用的な問題を解決するために、アルゴリズムエンジニアは主に特徴エンジニアリングに取り組んでいました。しかし、特徴量エンジニアリング自体にはあまり体系的な指導理論がないので（少なくとも現時点では体系的に特徴量エンジニアリングを紹介する書籍はありません）、特徴量構築手法は奇妙に思えることが多く、それが有用かどうかは問題自体、データサンプル、モデル、そして運にも左右されます。

特徴エンジニアリングがアルゴリズム エンジニアの主な仕事である場合、新しい特徴を構築しようとする試みのほとんどは、実際の作業ではうまくいかないことがよくあります。私の知る限り、国内大手数社の長編映画製作における成功率は、一般的に後期段階で20％を超えません。つまり、新しい構造的特徴の 80% には、プラスの改善効果がないことが多いのです。この方法に名前を付けるなら、おそらく「シンプルなモデル + 複雑な特徴」になるでしょう。シンプルなモデルとは、LR や SVM などのアルゴリズム自体がサービスを提供せず、パラメータと表現力が基本的に線形関係を示すことを意味し、理解しやすいです。複雑な特徴とは、有用または無用である可能性があり、特徴エンジニアリングでさまざまなトリックを絶えず使用して試行錯誤することで構築される特徴を指します。これらの特徴を構築するためのさまざまなトリックが存在する可能性があり、たとえば、ウィンドウスライディング、離散化、正規化、平方根、平方、直積、多重直積などです。ちなみに、特徴エンジニアリング自体は特に体系的な理論と概要がないため、業界に不慣れな学生は、特徴を構築したい場合は、より多くの論文、特に自分と同じまたは類似のビジネスシナリオに関する論文を読む必要があります。著者のデータ分析と理解の方法と、対応する特徴構築のテクニックから学ぶことができます。時間の経過とともに、独自の知識体系が形成されることが期待されます。

ディープラーニングの概念が提唱されてから、ディープニューラルネットワークを通じて、ある程度の表現学習ができることがわかってきました。例えば、画像の分野では、CNNで画像の特徴を抽出し、それに基づいて分類するという手法が、これまでのアルゴリズムの限界を一気に打ち破り、大きな差でそれを打ち破りました。これは、すべてのアルゴリズム エンジニアに新しいアイデアをもたらします。ディープラーニング自体に特徴を抽出する機能があるため、人工的な特徴設計を自分で行う必要があるのでしょうか。

ディープラーニングはある程度、特徴エンジニアリングのプレッシャーを軽減しましたが、ここで2つの点を強調する必要があります。1. 軽減は完全な解決策を意味するものではありません。画像などの特定の分野を除いて、ディープラーニングはパーソナライズされた推奨などの分野でまだ絶対的な優位性を達成していません。その理由は、データ自体の固有の構造の問題であり、他の分野では画像+ CNNのような完璧なCPを見つけることができないためと考えられます。 2. ディープラーニングは特徴エンジニアリングを軽減しますが、複雑で説明できないモデルの問題ももたらします。アルゴリズム エンジニアは、結果を改善するために、ネットワーク構造の設計に多くの時間と労力を費やす必要があります。要約すると、ディープラーニングによって表現されるシンプルな機能 + 複雑なモデルは、実用的な問題を解決するもう 1 つの方法です。

どちらのモデルが優れているかはまだ分かりません。クリック率予測を例にとると、計算広告の分野では、大量の特徴量+LRが主流であることが多いです。VC次元理論によれば、LRの表現力は特徴量数に比例します。そのため、特徴量が多いと、LRに十分な記述能力を持たせることもできます。パーソナライズされたレコメンデーションの分野では、ディープラーニングが本格的に普及し始めたばかりです。現在、Google PlayではWDL構造[1]が採用されており、YouTubeではデュアルDNN構造[2]が採用されています。

モードに関係なく、モデルが十分に大きい場合、モデル パラメータを 1 台のマシンに保存できない場合があります。たとえば、数百億の特徴のLRに対応する重みwは数十GBであり、多数の単一マシンに保存するのは困難です。大規模なニューラルネットワークはさらに複雑です。単一のマシンに保存するのが難しいだけでなく、パラメータ間には強い論理的依存関係もあります。超大規模モデルをトレーニングするには、分散システムの技術を使用する必要があります。この記事では、主にこの点に関するいくつかのアイデアをまとめています。

1.2 データ並列処理とモデル並列処理

データ並列性とモデル並列性は、大規模な機械学習フレームワークを理解するための基本的な概念です。私はそれらの起源を詳しく調べたことはありませんが、最初にそれらを目にしたのは義理の弟 (Jeff Dean) のブログでした。ざっと目を通しただけで、理解できたと思いました。何年も経って、この問題を再び研究し始めたとき、私は年長者たちのアドバイスを思い出しました。「若者よ、あなたたちはまだ世間知らずだ。」もしもあなたが私と同じように、これまでこの概念を見逃していたのであれば、今日それを再確認させてください。

穆帥はかつて[3]でこれら2つの概念について非常に直感的で古典的な説明をしました。残念ながら、私がそれを引用しようとしたときに、何らかの理由でそれが削除されていたことがわかりました。ここで簡単にこの例えを紹介しましょう。2つの建物を建てたい場合、建設チームがあり、どのように運営しますか？最初の選択肢は、人々を2つのグループに分けて、1つの建物を別々に建て、改修が完了した後に装飾することです。2番目の方法は、1つのグループが最初の建物を建て、最初の建物が建てられるまで待ってから、もう1つのグループが最初の建物を装飾し、その後、最初のグループが2番目の建物を建て続け、改修が完了したら、装飾チームが2番目の建物を装飾するのを待つことです。一見すると、2 番目の方法は並列性が高くないように見えますが、最初のソリューションではすべてのエンジニアが「構築」と「装飾」の両方の機能を備えている必要がありますが、2 番目のソリューションでは各人がいずれかの機能を備えているだけで済みます。最初のソリューションはデータ並列処理に似ていますが、2 番目のソリューションはモデル並列処理の本質を明らかにします。

データ並列処理は比較的簡単に理解できます。サンプル数が多い場合、すべてのサンプルを使用してモデルをトレーニングするには、データを異なるマシンに分散し、各マシンでモデルパラメータを反復処理する方がよいでしょう。次の図を参照してください。

この図はTensorFlowの論文[4]から引用したものです。図では、ABCは3つの異なるマシンを表しており、それぞれが異なるサンプルを格納しています。モデルPは各マシンで対応する増分を計算し、パラメータが格納されているマシンでそれらを要約して更新します。これがデータ並列処理です。同期については今は無視してください。これは同期メカニズムに関連する概念であり、第 3 セクションで具体的に紹介されます。

データ並列化の概念は単純で、特定のモデルに依存しないため、データ並列化メカニズムはフレームワークの基本機能として使用でき、すべてのアルゴリズムに有効です。対照的に、モデル並列処理では、データ並列処理のようにモデルパラメータを直接シャーディングすることによってモデルパラメータ間の依存関係を破壊することはできません。これは、パラメータ間に依存関係があるためです (実際、データ並列パラメータの更新もすべてのパラメータに依存する可能性がありますが、違いは、前回の反復のパラメータの完全なセットに依存することが多いことです。モデル並列処理では、BP アルゴリズムに従って形成された DNN ネットワークの異なるレイヤーのパラメータ間の依存関係など、同じ反復内のパラメータ間に強い依存関係があることがよくあります)。したがって、モデル並列処理では、モデルのシャーディングだけでなく、パラメータ間の依存関係を制御するスケジューラも必要です。ただし、各モデルの依存関係は異なることが多いため、モデル並列スケジューラはモデルごとに異なり、完全に汎用的になることは困難です。この問題に関してはCMUのEric Xingが[5]で紹介しています。興味のある方は参照してください。

モデル並列性の問題定義は、私の義兄の論文[6]に記載されています。この論文は、TensorFlowの前身の要約でもあります。

モデル並列性の物理的な図を説明します。非常に大きなニューラル ネットワークを 1 台のマシンに格納できない場合は、ネットワークを複数のマシンに分割することができます。ただし、図の太い黒線で示すように、異なるパラメータ スライス間の依存関係を維持するには、異なるマシン間での同時制御が必要です。細い黒線で示すように、同じマシン内のパラメータ依存関係は、マシン内で制御できます。

黒い線の部分を効果的に制御するにはどうすればよいでしょうか？下の図に示すように

モデルを異なるマシンに分割した後、それらの間でパラメータとサンプルを転送します。ABC は、モデルのさまざまな部分のパラメータを表します。C が B に依存し、B が A に依存していると仮定すると、マシン 1 で A の反復を取得した後、A と必要なサンプル情報がマシン 2 に送信されます。マシン 2 は、A とサンプルに基づいて P2 を更新します。以下同様に続きます。マシン 2 が B を計算すると、マシン 1 は A の 2 番目の反復の計算を開始できます。 CPU パイプライン操作に慣れている学生には馴染みがあるはずです。はい、モデルの並列処理はデータ パイプラインを通じて実現されます。建物を建てる場合の 2 番目のソリューションについて考えると、モデルの並列性の本質が理解できます。

上図は制御モデルのパラメータに依存するスケジューラの概略図です。実際のフレームワークでは、同様の機能を実装するために DAG (有向非巡回グラフ) スケジューリング技術が一般的に使用されています。私はこれについて深く研究していないので、後で追加で説明します。

データ並列性とモデル並列性を理解することは、後でパラメータ サーバーを理解する上で非常に重要ですが、まずは並列コンピューティング フレームワークに関する背景情報を簡単に紹介します。

2. 並列アルゴリズムの進化

2.1 MapReduceルート

Googleは関数型プログラミングにヒントを得て、分散コンピューティング手法MapReduce[7]をリリースしました。これは、タスクを複数のMap+Reduceタスクに分割して複雑なコンピューティングタスクを完了するものです。概略図は次のとおりです。

MapReduce には主に 2 つの問題があります。1 つは、プリミティブのセマンティクスが低レベルすぎるため、プリミティブを直接使用して複雑なアルゴリズムを記述するには多くの開発が必要になることです。もう 1 つの問題は、データ転送にディスクに依存しているため、パフォーマンスがビジネス ニーズに追いつけないことです。

MapReduceの2つの問題を解決するために、Mateiは[8]で新しいデータ構造RDDを提案し、Sparkフレームワークを構築しました。 Spark フレームワークは、MR セマンティクスの上に DAG スケジューラをカプセル化し、アルゴリズムを使用するためのハードルを大幅に下げます。長い間、Spark は大規模機械学習の代表的存在と言っても過言ではありません。Mu Shuai のパラメータ サーバーが大規模機械学習の分野をさらに開拓するまで、Spark の欠点がいくつか露呈することはありませんでした。下記の通り

図からわかるように、Spark フレームワークはドライバーを中心に構成されています。タスクのスケジュール設定やパラメータの集約はすべてドライバー内にあり、ドライバーはスタンドアロン構造であるため、Spark のボトルネックは非常に明白であり、それがドライバーにあります。モデルが大きすぎて 1 台のマシンに収まらない場合、Spark は適切に実行できません。したがって、今日の観点から見ると、Spark は中規模の機械学習フレームワークとしか言えません。ネタバレ注意: 同社のオープンソース Angel は、ドライバーの基礎となるプロトコルを変更することで、Spark をより高いレベルに拡張します。この部分については後ほど詳しく紹介します。

MapReduce はフレームワークであるだけでなく、アイデアでもあります。Google の先駆的な取り組みにより、ビッグデータ分析の実現可能な方向性が見出され、それは今日でも意味を持ちます。ビジネス レイヤーから、基礎となるセマンティクスが配置されるフレームワークの下位レイヤーへと徐々に移行していきます。

2.2 MPIテクノロジー

Mu Shuaiは[9]でMPIの展望について簡単に紹介した。Sparkとは異なり、MPIはソケットに似たシステム通信APIであるが、メッセージブロードキャストなどの機能のみをサポートしている。私は MPI を深く研究していないので、ここではその長所と短所を簡単に紹介します。長所はシステムレベルのサポートと優れたパフォーマンスですが、短所もたくさんあります。まず、MR と同様に、プリミティブが低レベルすぎるため、MPI でアルゴリズムを記述するには、多くの場合、大量のコードが必要になります。一方、MPI ベースのクラスターでは、タスクが失敗するとクラスター全体を再起動する必要があることがよくありますが、MPI クラスターのタスク成功率は高くありません。アリは[10]で次の図を示した。

図からわかるように、MPI ジョブが失敗する確率は 50% 近くになります。 MPI にメリットが全くないわけではありません。Mu Shuai 氏が言うように、スーパーコンピューティング クラスターでは今でも使用されています。クラウド コンピューティングやコモディティ コンピュータに依存している産業部門では、コスト効率が十分に高くありません。もちろん、パラメータサーバーの枠組みの中で単一のワーカーグループにMPIを使用する場合は、試してみるのが良いかもしれません。Kunpengシステム[10]はこのように設計されています。

3. パラメータサーバーの進化

3.1 歴史的進化

穆帥[12]はパラメータサーバの歴史を3つの段階に分けている。第一世代のパラメータサーバの出現

ユ・ムシュアイの師であるスモラ[11]は次の図に示されています。

この研究では、memcached はキー値データを格納するためだけに導入され、異なる処理プロセスがそれを並列に処理します。 [13]も同様の考え方を持っています。第2世代のパラメータサーバーはアプリケーション固有のパラメータサーバーと呼ばれ、主に特定のアプリケーション向けに開発されています。その最も典型的な代表例はTensorFlowの前身である[6]でしょう。

第3世代パラメータサーバーは、汎用パラメータサーバーフレームワークとも呼ばれ、BaiduのCEOであるLi Mu氏によって正式に提案されました。以前の2世代とは異なり、第3世代パラメータサーバーは、汎用的な大規模機械学習フレームワークとして設計されています。特定のアプリケーションやアルゴリズムの制約を取り除き、一般的な大規模機械学習フレームワークを作成するには、まずフレームワークの機能を定義する必要があります。フレームワークと呼ばれるものは、多くの場合、一度実行したら二度とやりたくない、反復的で些細で面倒で退屈な多数のタスクを適切かつエレガントにカプセル化したものなので、フレームワークを使用する人はコアロジックだけに集中できます。第 3 世代のパラメータ サーバーはどのような機能をカプセル化する必要がありますか? Mu Shuai がこれらの点を要約しました。以下に転載します。

1. 効率的なネットワーク通信: モデルとサンプルの両方が非常に大きいため、大規模な機械学習システムには、ネットワーク通信とハイエンドのネットワーク機器の効率的なサポートが不可欠です。
2. 柔軟な一貫性モデル: さまざまな一貫性モデルは、実際にはモデルの収束速度とクラスターの計算能力の間のトレードオフです。この概念を理解するには、次のセクションで紹介するモデル パフォーマンスの評価を分析する必要があります。
3. 弾力性と拡張性：明らか
4. 災害とフォールト トレランス: 大規模なクラスターが連携してコンピューティング タスクを実行する場合、Straggler 障害やマシン障害が発生することはよくあるため、システム設計自体でこれらを考慮する必要があります。障害が発生していない場合でも、タスクの適時性要件の変化により、クラスターのマシン構成をいつでも変更する必要がある場合があります。これには、タスクに影響を与えずにマシンをホットスワップできるフレームワークも必要です。
5. 使いやすさ: これは主に、フレームワークを使用してアルゴリズムを調整するエンジニア向けです。当然、使いにくいフレームワークは役に立ちません。

第3世代パラメータサーバーの主な技術を正式に紹介する前に、大規模機械学習フレームワークの進化を別の観点から見てみましょう。

この図は、パラメータ サーバーが登場する前に、人々が多くの並行的な試みを行っていたものの、特定のアルゴリズムや特定の分野のみを対象としていたことを示しています。たとえば、YahooLDA は LDA アルゴリズムを対象としています。モデルパラメータの数が 10 億を超えると、パラメータ サーバーが市場を独占し、ライバルがいないことがわかります。

まず、第 3 世代パラメータ サーバーの基本的なアーキテクチャを見てみましょう。

上の図のリソースマネージャは、実際のシステムではこの部分が yarn や mesos などの既存のリソース管理システムを再利用することが多いため、今のところは脇に置いておけます。以下のトレーニング データには、間違いなく GFS などの分散ファイル システムのサポートが必要です。残りは、パラメータ サーバーのコア コンポーネントです。

この図には、サーバー グループと 3 つのワーカー グループが示されています。実際のアプリケーションは、多くの場合、1 つのサーバー グループと、オンデマンドで構成されたワーカー グループで構成され、サーバー マネージャーはサーバー グループ内の管理ノードであり、通常はロジックを持ちません。サーバー マネージャーは、サーバー ノードが参加または離脱するときに、ハッシュの一貫性を維持するためにいくつかの調整を行うだけです。

ワーカー グループ内のタスク スケジュールは、単純なタスク コーディネーターです。特定のタスクが実行されている場合、タスク スケジュールは各ワーカーに通知して対応するデータをロードし、サーバー ノードから更新するパラメーター スライスを取得し、ローカル データ サンプルを使用してパラメーター スライスに対応する変更を計算し、それをサーバー ノードに同期します。サーバー ノードが担当するパラメーター スライスに対応するすべてのワーカーの更新を受信した後、サーバー ノードはパラメーター スライスを更新します。

図に示すように、異なるワーカーが並列操作を実行する場合、ネットワークやマシン構成などの外部要因により、異なるワーカーの進行状況が異なる可能性があります。ワーカーの同期メカニズムをどのように制御するかは、比較的重要なトピックです。詳細については次のセクションを参照してください。

3.2 同期プロトコル

このセクションでは、読者がすでに確率的勾配最適化アルゴリズムに精通していることを前提としています。このアルゴリズムに精通していない場合は、Andrew Ng の定番コース「機械学習」の SGD 入門、または私がこれまで何度もお勧めしている書籍「最適化入門」を参照してください。

まず、単一マシンアルゴリズムの動作プロセスを見てみましょう。モデルのパラメータが 3 つのスライス k1、k2、k3 に分割されているとします。たとえば、ロジスティック回帰アルゴリズムの重みベクトルが 3 つのセグメントに分割されていると想定できます。また、トレーニング サンプル セットを 3 つのシャード s1、s2、s3 に分割します。単一のマシンで実行する場合、実行シーケンスは (k1、s1)、(k2、s1)、(k3、s1)、(k1、s2)、(k2、s2)、(k3、s2) であると想定します。 。 。理解できましたか? これは、最初に s1 のサンプルを使用してパラメーター スライス k1、k2、k3 を 1 回トレーニングし、次に s2 に切り替えることを意味します。これは典型的な単一マシン操作であり、このような実行シーケンス *** アルゴリズムは収束することがわかっています。

それでは並列化を始めましょう。k1、k2、k3 が 3 つのサーバー ノードに分散され、s1、s2、s3 が 3 つのワーカーに分散されていると仮定します。以前の計算順序を維持するとどうなるでしょうか。ワーカー 1 が計算しているとき、work2 と work3 は待機することしかできません。同様に、ワーカー 2 が計算しているとき、work1 と work3 は待機する必要があります。このような並列化ではパフォーマンスは向上しませんが、超大規模モデルのストレージ問題も簡単に解決できます。

パフォーマンス問題を解決するために、業界ではここで一貫性モデルの検討を始めました。最新バージョンは、前述のASPモデルです[11]。これはワーカー間の順序を完全に無視します。各ワーカーは独自のペースで実行され、反復を実行した後に更新してから続行します。これは、図に示すように、大規模機械学習におけるフリースタイルのはずです。

ASP の利点は、クラスターの計算能力を最大限に活用し、すべてのワーカー マシンを待機させる必要がないことですが、欠点も明らかです。LDA などのいくつかのモデルを除いて、ASP プロトコルにより、モデルが収束に失敗する可能性があります。つまり、SGD は完全に暴走し、勾配はどこに飛んでしまったのか分からない状態です。

ASPの後、別の比較的極端な同期プロトコルBSPが提案されました。Sparkはこの方法を採用しています。図をご覧ください。

各ワーカーは同じ反復で実行する必要があります。反復タスクのすべてのワーカーがそれを完了した場合にのみ、ワーカーとサーバー間の同期とシャード更新が実行されます。このアルゴリズムは、厳密な一貫性アルゴリズムと非常によく似ていますが、唯一の違いは、スタンドアロン バージョンのバッチ サイズが、BSP 中にすべてのワーカーの単一バッチ サイズを合計して取得された合計バッチ サイズに置き換えられることです。唯一の違いはバッチ サイズであるため、BSP モードと単一マシン シリアル モードはモデル収束の点では完全に同じであることは間違いありません。同時に、各ワーカーはサイクル内で並列計算を実行できるため、ある程度の並列機能を備えています。

このプロトコルをベースにした Spark が、長い間機械学習の分野で事実上の覇者となってきたのには理由があります。このプロトコルの欠点は、ワーカー グループ全体のパフォーマンスが、その中の最も遅いワーカーによって決まることです。このワーカーは一般に、ストラグラーと呼ばれます。 GFS の記事を読んだ学生は、落伍者の存在が非常に一般的な現象であることを知っているはずです。

ASPとBSPの妥協点はできるでしょうか？答えはもちろんイエスです。これが私が考える最高の同期プロトコルSSPです。SSPの考え方は実はとてもシンプルです。ASPでは異なるワーカー間の反復間隔を任意に大きくできるのに対し、BSPでは0しか許されないので、定数sを取ることはできるでしょうか？図に示すように

異なるワーカー間では反復間隔が許可されますが、間隔の数は指定された値 s (図では s=3) を超えることはできません。

SSPプロトコルの詳細な紹介については[14]を参照してください。CMUの偉大な人物であるEric XingがSSPの定義とその収束保証について詳細に紹介しています。理論的な導出により、定数 s が無限大に等しくない場合、アルゴリズムは数回の反復後に確実に収束することが証明されています。実際、エリックが理論的な証明を提案する前に、業界ではすでにこれを試していました :)

ちなみに、分散アルゴリズムのパフォーマンスは、一般的に統計的パフォーマンスとハードパフォーマンスに分けられます。前者は、異なる同期プロトコルによりアルゴリズムが収束するために必要な反復回数を指し、後者は、1 回の反復に対応する時間消費を指します。両者の関係は適合率\再現率の関係に似ているため、詳細には触れません。 SSPでは、s=0を指定することでBSPが得られます。 ASPはs=∞に設定することでも実現できます。

3.3 コアテクノロジー

このセクションでは、パラメータ サーバーのアーキテクチャと同期プロトコルに加えて、他のテクノロジについても簡単に紹介します。詳細については、Mu Shuai の博士論文と関連する公開論文をお読みください。

ホット スタンバイとコールド スタンバイのテクノロジ: サーバー ノードがクラッシュしてタスクが中断されるのを防ぐために、2 つのテクノロジを使用できます。1 つは、パラメータ シャードでホット スタンバイを実行することです。各シャードは 3 つの異なるサーバー ノードに保存され、マスター スレーブの形式で存続します。マスターに障害が発生した場合、スレーブから関連タスクを迅速に取得して再開できます。

ホットスタンバイに加えて、分散ファイルシステムにチェックポイントファイルを定期的に書き込んで、パラメータシャードとそのステータスをバックアップすることもできます。安全性をさらに確保します。

サーバーノード管理: 図に示すように、一貫性ハッシュ技術を使用して、サーバーノードの参加と退出の問題を解決できます。

サーバー ノードが参加または離脱する場合、サーバー マネージャーはパラメータの再シャーディングまたはマージを担当します。シャード内のパラメータを管理する場合、シャードごとに必要なロックは 1 つだけであることに注意してください。これにより、システムのパフォーマンスが大幅に向上し、パラメータ サーバーの実際の使用においても重要なポイントとなります。

4. 大規模機械学習の4つのレベル

さて、タイトルに戻りましょう。大規模機械学習の 4 つの領域とは何でしょうか?

この 4 つのレベルの区分は、著者の個人的な読書概要に基づくアイデアであり、業界標準ではありません。あくまでも参考用です。

領域1: パラメータは単一のマシン上で保存および更新できる

この状態は比較的単純ですが、パラメータ サーバーは、データの並列処理を通じてモデルのトレーニングを高速化するために使用できます。

領域2: パラメータは単一のマシンに保存できませんが、単一のマシンで更新できます。

この状況は、スパース ロジスティック回帰などのいくつかの単純なモデルに該当します。特徴の数が 100 億を超えると、LR 重みパラメータが 1 台のマシンに完全に保存されることはほとんどありません。この場合、パラメータ サーバー アーキテクチャを使用してモデル パラメータを分割する必要があります。しかし、SGDの更新式は

w'=w-αは計算上は1次元に分離できるが、1次元wi=f(w)xi

ここで、f(w) はすべてのパラメータ w の関数を表します。具体的な推論は比較的単純なので、スペースの制限によりここでは詳細には触れません。ここで説明したいのは、ワーカーが勾配を計算するときに、前回の反復のすべてのパラメータを使用する必要がある可能性があることです。パラメータを分割する理由は、すべてのパラメータを 1 台のマシンに保存できないためです。現在、1 人のワーカーがすべてのパラメータを使用して、特定のパラメータ シャードの勾配を計算する必要があります。これは矛盾ではありませんか? 可能ですか?

答えは可能です。単一サンプルの特徴は高いスパース性を持っているからです。たとえば、数百億の特徴を持つモデルの場合、単一のトレーニング サンプルには、特徴のごく一部の値しか含まれず、残りはすべて 0 になることがよくあります (特徴値が離散化されていると仮定)。したがって、f(w)を計算するときは、0ではない特徴に対応するwの部分のみを抽出すれば済みます。ある記事の統計によると、このレベルのシステムのスパース性は通常 0.1% 未満です (または 0.01% 未満、正確かどうかは覚えていませんが、おおよそこのくらいです)。このようなスパース性により、単一のマシンで何の支障もなく f(w) を計算できます。

現在、同社のオープンソースエンジェルとAILabが開発中のシステムはこのレベルにあります。ただし、ネイティブ Spark はまだこのレベルに達しておらず、小規模および中規模のサークルでのみ使用できます。エンジェルの改造エンジェルベースのスパークがこのレベルに到達しました。

レベル3: パラメータを単一のマシンに保存または更新することはできませんが、モデルの並列処理は必要ありません。

領域 3 は領域 2 に続きます。次に、特徴が数百億個あり、特徴が密集している場合、コンピューティング フレームワークはこのレベルに入る必要があります。この時点で、単一のワーカーの容量は限られており、サンプルを完全にロードしたり、f(w) を完全に計算したりすることは不可能です。どうすればいいでしょうか? 実はとても簡単です。線形代数を学んだ人なら誰でも、行列をブロックに分割できることを知っています。ベクトルは最も単純な行列であり、計算のために自然に分割することができます。スケジューラがオペレータのセグメンテーションをサポートする必要があるだけです。

レベル4: パラメータを単一のマシンに保存または更新することはできず、モデルの並列処理が必要です。

このレベルのコンピューティング フレームワークへの参入は、世界をリードするものとみなすことができます。非常に大規模なニューラル ネットワークを処理できます。これは最も一般的なアプリケーション シナリオでもあります。現時点では、モデルパラメータを単一のマシンに保存できないだけでなく、同じ反復内でのモデルパラメータ間の依存関係も強くなります。義理の兄弟の distbelief の紹介にあるモデルセグメンテーションを参照できます。

この時点で、まずモデルの同時制御を実行するためのコーディネーター コンポーネントを追加する必要があります。同時に、パラメータ サーバー フレームワークは名前空間のセグメンテーションをサポートする必要があり、コーディネーターは名前空間を通じて依存関係を表します。

一般的に、パラメータ間の依存関係はモデルに依存するため、一般的なコーディネータを抽象化することは困難です。代わりに、スクリプト パーサーを介してコンピューティング タスク全体の DAG グラフを何らかの形で生成し、DAG スケジューラを介して完了する必要があります。この問題の概要については、Eric Xing氏の共有[5]を参照してください。

テンソルフロー

現在、業界でよく知られているディープラーニングフレームワークには、Caffee、MXNet、Torch、Keras、Theanoなどがありますが、最も人気のあるのはGoogleがリリースしたTensorflowです。ここで少し分解して説明してみましょう。

上記の写真の多くは、TFペーパーから引用されています。TFフレームワークは、モデルの並列性とデータの並列性をサポートしています。その理由は、露出したAPIはニューラルネットワークの異なるレイヤー間のパラメーターの分割のみをサポートし、超大規模なスケールLRはニューラルユニットと見なすことができ、TFは単一のニューラルユニットパラメーターの複数のパラメーターサーバーノードへの分割をサポートしていないためです。

もちろん、Googleの強さにより、それが公開されていない理由は、クラウドコンピューティングサービスの使用など、他のビジネス目的に基づいている可能性があります。

要約すると、4番目のレベルを達成できれば、世界最高の大規模な機械学習フレームワークと言えると個人的に考えています。 Mu ShuaiのPPTから判断すると、彼は以前にこれを達成したことがあるので、Googleで問題はないはずです。 3番目のレベルは国内で最高であるはずであり、第2レベルは国内で最高のレベルであるはずです。

5。その他

5.1リソース管理

この記事がカバーしていないのは、リソース管理です

リソース消費も比較的大きく、メンテナンスには特別なリソース管理ツールが必要です。この点で、ヤーンとメソスはどちらもリーダーなので、ここで詳しく説明することはありません。

5.2機器

リソース管理ツールに加えて、大規模な機械学習クラスターを展開するには、ハードウェアも必要です。

理論的には、すべてのコモディティマシンを使用して、このタイプのクラスターを構築することができます。パフォーマンスを考慮して、メモリが高く、ギガビットが10個以上高いマシンを使用することをお勧めします。非常に高速なネットワークカードがなければ、パラメーターの渡しとサンプルの読み込みで再生するのは少し難しいでしょう。

6。結論

バックエンドからアルゴリズムに切り替えて以来、私は長い間論文を推論するアルゴリズムに没頭しており、自分自身を抽出することはできません。

私は徐々に台湾のエンジニアリング能力を見下し始め、エンジニアリングはアルゴリズムにほとんど役に立たないと感じました。私はこの分野で研究をする機会があり、私のエンジニアリングの経験が大規模な機械学習フレームワークを理解するのに非常に役立つことに突然気づきました。

1か月の研究では、私は毎日午前4時に目が覚めていました。私が手放すことができないという問題があるとき、私は非常に興奮した状態になります。幸いなことに、私はついにこの点ですべての重要な詳細を見つけました。これを覚えておいてください。 Carbonzhang 2017年8月26日の早朝！

謝辞

Wills、Janwang、Joey、Roberty、Suzi、その他のクラスメートに感謝し、TFでの彼の深い到達と研究に感謝します。私の限られたレベル、間違いは避けられません。彼らは将来的に。