アルゴリズム実装からMiniFlow実装まで、機械学習のためのインフラプラットフォームを構築

ビッグデータ、クラウドコンピューティング、ディープラーニングと比較すると、インフラストラクチャはあまり人気がありません。多くのプログラマーは、仕事を始めるとMySQL、Django、Spring、Hadoopを使用してビジネスロジックを開発しますが、インフラストラクチャプロジェクトの開発に実際に参加したことはありません。機械学習の分野でも同じことが言えます。オープンソースの Caffe、TensorFlow、AWS、Google CloudML の助けを借りて、多くのビジネス アプリケーションを実現できます。ただし、フレームワークやプラットフォームは業界の発展とともに人気が出たり衰退したりする一方で、高可用性、高性能、柔軟で使いやすいインフラストラクチャの追求はほぼ永遠です。

Google の Wang Yonggang 氏は、「AI エンジニアがアーキテクチャについて少し知っておく必要がある理由」の中で、研究機関はアルゴリズムだけを理解することはできないと述べています。アルゴリズムの実装は問題解決を意味するものではなく、問題解決は現場での問題解決を意味するものではありません。アーキテクチャの知識は、エンジニアがチームで効率的にコラボレーションするための共通言語です。 Google は、強力なインフラストラクチャ機能を利用して、AI 研究を業界に先んじています。業界の発展により、ディープラーニングや自動機械学習も可能になりました。今後、基盤となるアーキテクチャと設計に注目する人が増えるでしょう。

したがって、今日のトピックでは、次の側面を含む機械学習の基本的なアーキテクチャを紹介します。

1. インフラストラクチャの階層化設計。
2. 機械学習のための数値計算。
3. TensorFlow の再実装。
4. 分散型機械学習プラットフォームの設計。

***パート: インフラストラクチャの階層化設計

AWS 上で TensorFlow アプリケーションを作成する場合、アプリケーション抽象化のレイヤーは何層になるでしょうか。まず、物理サーバーやネットワーク帯域幅について話す必要はありません。TCP/IP などのプロトコルの抽象化により、AWS 仮想マシン上で直接操作する場合とローカルで操作する場合に違いはありません。第二に、オペレーティング システムとプログラミング言語の抽象化により、基盤となる物理メモリ アドレスやディスクの読み取りと書き込みのシステム コールを意識する必要がなくなり、Python 仕様に従ってコードを記述するだけで済みます。次に、TensorFlow コンピューティング ライブラリを使用しました。実際には、トップレベルの Python API を呼び出すだけで済みます。最下層は、言語間研究のために Protobuf と swig を介してシリアル化され、gRPC または RDMA を介して通信します。最上層は、行列演算のために Eigen または CUDA ライブラリを呼び出します。

したがって、ソフトウェア間の分離と抽象化を実現するために、システム アーキテクチャでは階層化アーキテクチャが採用されることが多く、階層化によって基礎となる実装の詳細が保護され、最下層の各層は上位レベルのアプリケーションの基本アーキテクチャと同等になります。

では、階層化された世界で私たちはどうやって生き残ればいいのでしょうか?

誰かがオペレーティング システムとプログラミング言語を実装したのだから、基礎となる実装の詳細に注意を払う必要があるのか​​、と考える人もいるかもしれません。この質問に対する標準的な答えはありません。人によって感じ方は異なります。以下に 2 つの例を挙げてみましょう。

記事「1%のケースのために99%のケースのパフォーマンスを犠牲にする：カタツムリのようなPythonのディープコピー」では、Python標準ライブラリのcopy.deep_copy()の実装を紹介しています。1%のケースとは、ディープコピー中にオブジェクト自体を参照するオブジェクトが存在する可能性があることを指し、コピー中にコピーされたオブジェクトの情報をすべて記録する必要があります。99%のシナリオでは、オブジェクトが直接自分自身に適用されません。100%のケースに対応するために、このライブラリは6倍以上のパフォーマンスを失います。 Python ソース コードを深く理解した後、ディープ コピー アルゴリズムを実装してビジネス ロジックを最適化することで、上記のパフォーマンスの問題を解決できます。

もう 1 つの例は、Alibaba の Yang Jun 氏が Strata Data Conference で共有した「Pluto: 分散型異種ディープラーニング フレームワーク」です。このフレームワークでは、TensorFlow に基づく control_dependencies を導入して、GPU メモリ内のホット データとコールド データの配置を実現し、ユーザーが気付かないうちにメモリの使用量を大幅に削減しました。ソースコードに詳しい人なら、TensorFlow の動的計算グラフ、つまり tensorflow/fold プロジェクトも control_dependencies に基づいて実装されていることに気付いたかもしれません。宣言型の機械学習フレームワークで動的計算グラフを実装するのは簡単ではありません。これら 2 つの実装はいずれも TensorFlow の公式ドキュメントには存在しません。ソース コードを十分に深く理解することによってのみ、機能とパフォーマンスの大きな進歩がもたらされます。したがって、企業で TensorFlow フレームワークのインフラストラクチャ保守を担当している場合は、TensorFlow の Python API 抽象化レイヤーを突破することが非常に重要です。

機械学習を適用する際、私たちは無意識のうちに多くのインフラストラクチャの抽象化を使用しています。その中で最も重要なのは、機械学習アルゴリズム自体の実装です。次に、抽象化を打破し、基礎となる実装原則をより深く理解します。

パート II: 機械学習のための数値計算

機械学習は本質的には数値計算の連続であるため、TensorFlow はディープラーニングライブラリではなく、数値計算ライブラリとして位置付けられています。シャノンエントロピー、ベイジアン、バックプロパゲーションなどの概念を聞いても、心配する必要はありません。これらはすべて数学であり、コンピュータプログラミングを通じて実装できます。

機械学習に触れたことのある人なら誰でも、LR を知っています。これは通常、ロジスティック回帰または線形回帰を指します。前者は分類アルゴリズムに属し、後者は回帰アルゴリズムに属します。どちらの LR にも、トレーニング ラウンド数 (エポック数)、学習率 (学習率)、オプティマイザー (オプティマイザー) など、調整可能なハイパーパラメータがいくつかあります。このアルゴリズムを実装すると、その原理と調整手法を理解するのに役立ちます。

以下は単純な線形回帰の Python 実装です。モデルは単純に y = w * x + b です。

この例から、機械学習アルゴリズムの実装は Scikit-learn や TensorFlow などのライブラリに依存しないことがわかります。本質的にはすべて数値演算であり、異なる言語で実装するとパフォーマンスに違いが生じます。注意深い友人は、なぜここでのwの勾配が-2 * x * (y – x * x –b)であるのに、bの勾配が-2 * (y – w * x – b)であるのか、計算後に損失が減少し、精度が向上することをどのように保証するのか疑問に思うかもしれません。これは数学的に保証されています。損失関数（平均二乗誤差）をy – w * x – bの二乗として定義します。つまり、予測値がyに近いほど、損失は小さくなります。目標は、wとbの任意の値での損失関数の最小値を見つけることになります。したがって、wとbの偏微分を取った後、上記の2つの式が得られます。

興味があれば、線形回帰における MSE の偏微分の数式証明を見てみることをお勧めします。

ロジスティック回帰は線形回帰に似ています。分類問題なので、w * x + b の予測結果を正規化する必要があります。一般的にはシグモイド法が使われます。Python では、1.0 / (1 + numpy.exp(-x)) で実現できます。予測値が異なるため、損失関数の定義が異なり、偏微分によって得られる数値計算式も異なります。ご興味があれば、私の式の導出もご覧ください。

最終的に得られる偏微分は非常に単純であり、どのプログラミング言語でも簡単に実装できることがわかります。しかし、私たち自身の実装は、必ずしも最も効率的ではないかもしれません。Scikit-learn や MXNet などのオープンソース ライブラリに実装されているアルゴリズムを使用するだけでは不十分です。

このアルゴリズムを理解することは、実際にはエンジニアリングでこのアルゴリズムを使用するための非常に重要な基礎となります。たとえば、実際のビジネス シナリオでは、サンプルの特徴は数百億、さらには数千億の次元を持つ場合があります。 前述のアルゴリズムにより、LR モデルのサイズはサンプルの特徴の次元と同じであることがわかります。 つまり、数百億の次元を受け入れるモデルには、数百億のパラメーターがあります。 標準の倍精度浮動小数点数を使用してモデル パラメーターを保存する場合、モデル パラメーターの数百億の次元は少なくとも 40G を超える必要があり、数千億の次元の特徴を 1 台のマシンにロードすることはできません。

そのため、Scikit-learnはネイティブインターフェースを通じて高性能LRアルゴリズムを実装していますが、単一のマシン上でしかトレーニング要件を満たすことができません。MXNetはSpareTensorをネイティブにサポートしていないため、超高次元スパースデータに対するトレーニング効率は非常に低いです。TensorFlow自体はSpareTensorとモデル並列処理をサポートしており、数百億次元の特徴を持つモデルトレーニングをサポートできますが、LRに最適化されておらず、効率はあまり高くありません。このシナリオでは、Fourth Paradigm は、パラメータ サーバーをベースとしたモデル並列処理とデータ並列処理をサポートする超高次元、高性能の機械学習ライブラリを実装しました。これに基づく大規模 LR、GBDT などのアルゴリズムのトレーニング効率は、エンジニアリングのニーズを満たすことができます。

機械学習には、決定木、SVM、ニューラル ネットワーク、ナイーブ ベイズなど、数学的理論的基礎さえあればエンジニアリングに簡単に実装できる興味深いアルゴリズムが数多くあります。スペースの制約により、ここでは詳細には触れません。先ほど紹介したのは、実は機械学習における命令型プログラミングインターフェースです。偏微分方程式の式をあらかじめ導出しておき、他のプログラミングスクリプトと同様にコードの順番通りに実行していきます。ご存知の通り、TensorFlow は計算グラフを記述することで実行プロセスを遅延させ、最適化する宣言型プログラミングインターフェースを提供しています。次に、この側面について紹介します。

パート III: TensorFlow の再実装

まず、疑問に思うことがあるかもしれません。TensorFlow を再実装する必要があるのでしょうか? TensorFlow の柔軟なプログラミング インターフェイス、Eigen と CUDA に基づく高性能コンピューティング、分散型および Hadoop HDFS 統合のサポートは、個人や企業でさえ完全に追いついて実装するのは困難です。命令型プログラミング インターフェイスが必要な場合でも、MXNet を使用できます。新しい TensorFlow フレームワークに対する強い需要はありません。

実際、TensorFlow を学習する過程で、TensorFlow のようなプロジェクトを実装することで、そのソースコードとインターフェースの独創的な設計に驚いただけでなく、宣言型プログラミング、DAG 実装、自動偏微分、バックプロパゲーションなどの概念に対する理解も深まりました。ベンチマークテストでも、純粋な Python で実装されたプロジェクトは、線形回帰モデルのトレーニングにおいて TensorFlow よりも 22 倍高速であることがわかりました。もちろん、これは特定のシナリオでのストレステストの結果です。主な理由は、TensorFlow では Python と C++ の間で言語間の切り替えオーバーヘッドがあるためです。

このプロジェクトは、連鎖律、自動微分化を実装し、命令型プログラミングと宣言型プログラミングをサポートし、TensorFlow Python API と互換性のある数値計算ライブラリである MiniFlow です。ご興味がございましたら、こちらのアドレスから開発に参加できます。以下は 2 つの API の比較表です。

TensorFlow と MXNet (または NNVM) のソースコードに詳しい方は、どちらも Op、Graph、Placeholer、Variable などの抽象的な概念があり、モデルの計算フロー グラフを DAG 形式で記述しているため、同様の機能インターフェイスを実装する必要があることをご存知かもしれません。

以前の LR コードとは異なり、グラフベースのモデルでは、ユーザーが損失関数をカスタマイズできます。つまり、ユーザーは従来の平均二乗誤差を使用したり、損失関数として任意の数式をカスタマイズしたりできます。これには、損失関数に基づく微分計算方法を事前に実装するのではなく、フレームワーク自体が自動微分機能を実装できることが必要です。

次に、ユーザーが定義できる最小操作、つまり Op では、プラットフォームが ConstantOp、AddOp、MultipleOp などの基本演算子を実装する必要があり、ユーザーがカスタム演算子を実装すると、フレームワーク自体のトレーニング プロセスに影響を与えることなく、自動微分化プロセスに追加できます。 TensorFlow の Python ソースコードを参照して、Op の基本クラスを以下のように定義します。すべての Ops は、モデルのトレーニング中に自動微分化を容易にするために forward() と grad() を実装する必要があり、Python 演算子をオーバーロードすると、開発者にさらに便利な使用インターフェースを提供できます。

そして定数（ConstantOp）と変数（VariableOp）については、それぞれの順方向演算はそれぞれの値を求めるもので、微分を取る場合は定数の微分は0、偏微分を取る場合は変数の微分は1、その他の変数も0となります。具体的なコードは以下のようになります。

実際、より重要なのは、加算 (AddOp)、減算 (MinusOp)、乗算 (MultipleOp)、除算 (DivideOp)、平方 (PowerOp) などの演算子の順方向および逆方向の演算ロジックを実装する必要があることです。そうすれば、連鎖律に従って、複雑な数式の導出をこれらの基本演算子の導出に簡略化できます。

たとえば、加算と減算の場合、2 つの数値の加算の導関数は、導関数の加算に等しいことがわかっています。したがって、この数学的原理に基づいて、AddOp を簡単に実装できます。MinusOp の実装も同様であるため、ここでは繰り返しません。

掛け算と割り算は比較的複雑です。明らかに、2 つの数値の掛け算の導関数は、導関数の掛け算と同じではありません。たとえば、最初に x の導関数と x の 2 乗をとってからそれらを掛け算すると、2x になります。最初にそれらを掛け算してから導関数をとると、x の 2 乗の 3 倍になります。そのため、乗算規則を使用する必要があります。基本的な式は、コード実装は次のとおりです。

除算と平方の導出も同様です。数学的に証明されているので、基本的な順方向と逆方向の操作をコーディングするだけで済みます。スペースの制限により、ここでは MiniFlow のソースコード実装を詳しく紹介しません。ご興味があれば、上記の Github リンクから完全なソースコード実装を見つけることができます。以下は、同じ API インターフェースを使用して実装されたモデルのパフォーマンス テスト結果です。MiniFlow は、小さなバッチ データ処理と Python/C++ オペレーティング環境の頻繁な切り替えが必要なシナリオで、より優れたパフォーマンスを発揮します。

先ほど、機械学習アルゴリズムとディープラーニング ライブラリの実装を紹介しました。誰もがインフラストラクチャのこの部分を書き換えたり最適化したりする能力を持っているわけではありません。多くの場合、私たちはこれらのアルゴリズムの単なるユーザーです。しかし、別の観点から見ると、機械学習のトレーニングと予測のために、可用性の高いコンピューティング プラットフォームを維持する必要があります。以下では、この側面から分散機械学習プラットフォームを構築する方法を紹介します。

パートIV: 分散機械学習プラットフォームの設計

ビッグデータとクラウドコンピューティングの発展により、可用性の高い分散型機械学習プラットフォームの実装が基本的な要件となっています。 Caffe、TensorFlow、または当社が独自に開発した高性能機械学習ライブラリのいずれであっても、数値計算、アルゴリズムの実装、およびモデルのトレーニングの問題を解決するだけです。タスクの分離、スケジュール、およびフェイルオーバーはすべて、上位レベルのプラットフォームの実装を必要とします。

では、機械学習のプロセス全体をカバーするインフラストラクチャ プラットフォームの設計には、どのような機能を含めるべきでしょうか?

まず、リソースの分離を実現する必要があります。基盤となるコンピューティング リソースを共有するクラスターでは、ユーザーが送信したトレーニング タスクが他のタスクの影響を受けないようにし、CPU、メモリ、GPU などのリソースの分離を可能な限り確保する必要があります。 Hadoop または Spark クラスターを使用する場合、CPU とメモリの分離を確保するために、cgroup がデフォルトでタスク プロセスにマウントされます。Docker などのコンテナー テクノロジが成熟するにつれて、Kubernetes や Mesos などのプロジェクトを使用して、ユーザーが実装したモデル トレーニング タスクを開始および管理することもできます。

次に、リソースのスケジュール設定と共有を実現します。一般的なコンピューティングにおける GPU の普及に伴い、GPU スケジューリングをサポートするオーケストレーション ツールがますます増えています。しかし、一部の企業では依然として専用の GPU を使用しているため、リソースを動的にスケジュールして共有することができず、コンピューティング リソースの重大な浪費につながることが避けられません。機械学習プラットフォームを設計する際には、モデルのトレーニング、モデルの保存、モデルのサービング機能を同時にサポートするなど、共通のクラスター共有シナリオを可能な限り考慮する必要があります。代表的な例としては、Google Borg システムがあります。

次に、プラットフォームには柔軟な互換性が必要です。現在、機械学習ビジネスは急速に発展しており、さまざまなシナリオに対応する機械学習フレームワークがますます増えています。柔軟なプラットフォームアーキテクチャは、ほぼすべての主流のアプリケーションフレームワークと互換性があり、ビジネス開発によるインフラストラクチャの頻繁な変更を回避できます。現在、Docker は非常に適したコンテナ フォーマット仕様です。Dockerfile を記述することで、フレームワークの動作環境とシステム依存関係を記述できます。これに基づいて、TensorFlow、MXNet、Theano、CNTK、Torch、Caffe、Keras、Scikit-learn、XGBoost、PaddlePaddle、Gym、Neon、Chainer、PyTorch、Deeplearning4j、Lasagne、Dsstne、H2O、GraphLab、MiniFlow などのフレームワークをプラットフォームに統合できます。

***、機械学習のシナリオでは API サービスを実装する必要があります。機械学習の3つの主要プロセスであるモデル開発、モデルトレーニング、モデルサービスに対して、トレーニングタスクの送信、開発環境の作成、モデルサービスの開始、オフライン予測タスクの送信などのAPIを定義し、使い慣れたプログラミング言語でWebサービスインターフェースを実装できます。 Google のようなクラウド ディープラーニング プラットフォームを実装するには、次の 3 つの手順を参考にしてください。

もちろん、データ導入、データ処理、特徴量エンジニアリング、モデル評価機能まで網羅した機械学習プラットフォームを実現するには、HDFS、Spark、Hiveなどのビッグデータ処理ツールの統合や、AzkabanやOozieと同様のワークフロー管理ツールの実装も必要であり、使いやすさや敷居の低さといった面でさらなる取り組みが必要です。

要約する

***まとめると、機械学習の基本的なアーキテクチャには、機械学習アルゴリズム、機械学習ライブラリ、機械学習プラットフォームなどの複数レベルのコンテンツが含まれます。ビジネスニーズに応じて、詳細な研究と二次開発の特定の領域を選択できます。車輪を使用することと、ニーズに応じて車輪を変換することは同様に重要です。

機械学習と人工知能が大流行している今日、私は皆さんも基礎となるインフラに注目してほしいと思っています。アルゴリズム研究者はプロジェクトの設計と実装についてより深く理解でき、R＆Dエンジニアはアルゴリズムの原理と最適化についてより深く理解でき、機械学習は適切なインフラプラットフォーム上でより効果的に機能し、実際のシナリオに真に適用できるようになります。