サーバーレス コンピューティングによる機械学習の解決策は何でしょうか?

1. 機械学習とサーバーレス学習

1.1. 機械学習 (ML) はアプリケーション シナリオでどのような問題に遭遇しますか?

近年、機械学習（ML）は画像認識、テキスト・音声処理などの分野で広く利用され、人々の働き方や生活を変え、大きな利便性をもたらしています。しかし同時に、ML ユーザーは、ML の生産性と効率性を大きく妨げるいくつかの大きな課題にも直面しています。まず、ユーザーは通常、ワーカー サーバー/パラメータ サーバーの数、メモリ割り当て、CPU の数、物理トポロジなど、多くのシステム レベルのパラメータを手動で構成する必要があります。第二に、ユーザーは学習率、学習アルゴリズム、ニューラル ネットワーク構造など、多数の ML 関連のパラメータを指定する必要があります。これらのパラメータとシステム レベルのパラメータの間にはさまざまな相互作用があります。 3 番目に、ML ワークフローは通常、前処理、トレーニング、ハイパーパラメータ検索などの複数のステージで構成され、それぞれに ML ユーザーが考慮する必要がある異なる計算要件があります。

ML のこれらの特性により、実際のアプリケーションでは次の 2 つの問題が頻繁に発生します。

まず、ML ワークフロー内のさまざまなタスクの異質性により、トレーニング ワークフローの実行中にリソースの重大な不均衡が生じます。 ML ユーザーは、各ステージの異種リソース要件を個別に考慮する必要があり、多くの場合、リソースの過剰プロビジョニングにつながります。現在の ML フレームワークは通常、ML 関連のワークロードに必要な柔軟性を持たない粗粒度の VM クラスターに基づいています。 CPU使用率が20%まで低下することも珍しくありません[1]。実際には、開発者はワークフローのさまざまな段階でさまざまな ML パラメータを繰り返し試し、リソースの過剰プロビジョニングの問題をさらに悪化させます。

2 番目に、ML ユーザーは複雑な管理上の問題に対処する必要があります。各 ML ワークロードに対してこれらのリソースをプロビジョニング、構成、管理するという課題に直面しています。機械学習ワークロードに VM を活用するシステムでは、通常、ユーザーが一連の面倒なタスクを繰り返し実行する必要があります。その一部を表 1 に示します。この管理の複雑さにより、インタラクティブで反復的なユースケースが妨げられ、ユーザーの生産性とモデルの有効性が低下します。

実際には、過剰プロビジョニングと明示的なリソース管理の負担という 2 つの問題は密接に関連しています。ML ユーザーは、ワークフローのさまざまな段階に必要なリソースを正確に割り当てることの難しさや人件費に直面したときに、過剰プロビジョニングに頼ることがよくあります。

では、ML の実際の応用におけるこれらの問題の解決策は何でしょうか?この記事では、現在広く使用され、非常に優れた結果を達成している方法、サーバーレス コンピューティングについて説明します。

表 1. VM クラスターを使用する際に ML ユーザーが直面するタスクの課題。

1.2. サーバーレスコンピューティング

サーバーレス コンピューティングは、クラウド ネイティブ コンピューティング モデルの最終段階です。クラウド コンピューティングの開発は、インフラストラクチャー アズ ア サービス (IaaS)、プラットフォーム アズ ア サービス (PaaS)、ソフトウェア アズ ア サービス (SaaS) など、いくつかの段階を経て、徐々にサーバーレス コンピューティングの段階に入っています。前の段階で提供されたサービスと比較して、サーバーレス コンピューティングでは、次のサービスのうち 1 つまたは両方を提供できます。

1. サービスとしての関数 (FaaS)。開発者は、イベントまたは HTTP リクエストによってトリガーされる関数を使用して、アプリケーション コードを実行および管理します。開発者はこれらの小さなコード ユニットを FaaS にデプロイします。これにより、開発者がサーバーやその他の基盤となるインフラストラクチャを管理する必要がなくなり、オンデマンドで実行および拡張できます。

2. バックエンド・アズ・ア・サービス (BaaS)。アプリケーションのコア機能のサブセットを置き換えるサードパーティ API ベースのサービスを提供します。開発者にとって、これらの API は自動的にスケーリングされ、透過的に動作するサービスとして提供されるため、開発者にとってこのサービス アプローチもサーバーレスです。

技術的な実装の観点から見ると、サーバーレス コンピューティングは、ユーザーではなくクラウド インフラストラクチャに依存して、リソースの割り当てと管理の課題を自動的に解決します。このアプローチは、開発者によって送信され、クラウド インフラストラクチャによって実行がスケジュールされる、AWS Lambda のステートレス Lambda 関数などの、より制約のある計算単位に依存します。したがって、ユーザーは長期的なコンピューティング ユニット (VM など) を手動で構成、展開、管理する必要がありません。サーバーレス モデルの利点により、データ センター、クラウド プロバイダー、オープン ソース プラットフォーム全体で急速に導入が進んでいます。

サーバーレス コンピューティングによって提供されるサービスには、プログラム ロジックを実行するための時間制限のあるステートレス Function as a Service API や、プログラムの状態を管理するためのオブジェクト ストレージ システムなどがあります。サービス API を使用すると、ユーザーはコード関数 (操作とも呼ばれます) を実行し、各関数の結果を返すことができます。サーバーレス コンピューティングでは HTTPS ターミナルも提供されており、開発者は関数の結果を取得できます。開発者は、HTTPS ターミナルを通じてパラメータを入力することで、関連する関数のトリガー イベント (またはリンク) を生成できます。プログラムの状態とロジックを明確に分離できるアプリケーション設計者にとって、サーバーレス コンピューティング プラットフォームは、複雑なクラスターの展開を必要とせずに、大規模なコンピューティング能力に即座にアクセスできるようにします。

サーバーレス コンピューティング プラットフォームでは、クラウド サービス プロバイダーがオンデマンドで機能を実行し、クラスターの構成と管理のオーバーヘッドをエンド ユーザーから隠す機能を提供します。可用性の利点に加えて、このモデルは効率も向上します。クラウド プロバイダーは従来のクラスター コンピューティングよりも細かい粒度でリソースを再利用できるようになり、ユーザーはアイドル状態のリソースに対して料金を支払う必要がなくなります。ただし、リソースを効率的に管理するために、クラウド サービス プロバイダーは各リソースの使用に制限を課しています。

計算。サーバーレス コンピューティング プラットフォームで提供されるコンピューティング リソースは、通常、1 つの CPU コアと短いコンピューティング ウィンドウに制限されます。たとえば、AWS Lambda は、単一の AVX コアで 900 秒のコンピューティング時間を提供し、最大 3 GB のメモリと 512 MB のディスクストレージにアクセスできます。ユーザーは多数の関数を並行して実行することができ、これらの実行の総合的な計算パフォーマンスはほぼ直線的に増加します。関数実行における線形スケーラビリティは、個々のワーカー間で通信がない場合の並列コンピューティングにのみ役立ちます。実際のアプリケーションでは、個々のワーカーは瞬間的にしか存在しないため、起動時間がずれる可能性があり、そのため MPI などの従来のポイントツーポイント通信モデルはこの環境では機能しません。ストレージをワーカー間の間接的な通信チャネルとして使用することを検討できます。

ストレージ。クラウド サービス プロバイダーは、キー値ストアからリレーショナル データベースまで、さまざまなストレージ オプションを提供しています。一部のサービスは、事前にリソースをプロビジョニングする必要があるため、完全に弾力的ではありません。ただし、Amazon S3 や Google Cloud Storage などの分散オブジェクト ストレージ システムでは無制限のストレージが提供され、ユーザーは保存したデータの量に対してのみ料金を支払います。計算中に中間状態を分散オブジェクト ストアに保存し、他のノードの RAM からアクセスする場合と同じ帯域幅を確保することも検討できます。

コントロール プレーン。クラウド サービス プロバイダーは、ストレージ サービスに加えて、Amazon SQS や Google Task Queue などのパブリッシュ/サブスクライブ サービスも提供しています。これらのサービスは通常、高いデータ アクセス帯域幅をサポートしていませんが、少なくとも 1 回の配信などの一貫性保証を提供し、「コントロール プレーン」状態 (すべてのサーバーレス関数呼び出し間で共有されるタスク キュー) に使用できます。クラウド サービス プロバイダーは、サーバーレス関数の呼び出し全体でコントロール プレーンの状態を保存および操作するために使用できる DynamoDB などの一貫性のあるキー値ストアも提供しています。

サーバーレス コンピューティングに対する上記の制約により、実際のアプリケーションでは、サーバーレス コンピューティングは「完璧」ではなく、サーバーレス コンピューティングのアプリケーションも多くの問題に直面しています。 AWS Lambda を例にとると、サーバーレス コンピューティングを活用する際の主な課題は、Lambda 関数に関連するローカル リソースの制約 (メモリ、CPU、ストレージ、ネットワーク) が非常に小さいことです。これは、これらのきめ細かいコンピューティング ユニットによってスケーラビリティと柔軟性が実現されるため、サーバーレス コンピューティングの基礎となります。具体的には、サーバーレス コンピューティングは次の問題に直面します。

小さなローカルメモリとストレージ。計算リソースの制限により、これらのリソースを使用して設計されていない計算フレームワークは使用できません。たとえば、AWS Lambda やリソースが制限された構成の VM では、Tensorflow や Spark を実行することはできません。

帯域幅が低く、P2P 通信が不足しています。 Lambda 関数では、通常の VM と比較して利用可能な帯域幅が制限されます。最大の AWS Lambda は 60 MB/秒の帯域幅しか維持できないことがわかりました。これは、中規模の VM でも利用可能な 1 GB/秒を大幅に下回っています。さらに、サーバーレス コンピューティングでは、通信トポロジにさらなる制限が課せられます。 AWS Lambda などのサーバーレスコンピューティングユニットでは、ピアツーピア通信は許可されません。したがって、ツリー構造またはリング構造の AllReduce 通信など、データセンター ML の従来の一般的な通信戦略は、このような環境では効果的に実装できません。

起動時間が短く、予測できません。 Lambda 関数は有効期間が短く、起動時間も大きく異なります。たとえば、AWS Lambda はロード後に起動するまでに数分かかる場合があります。つまり、トレーニング中、Lambda は予期しないタイミングで開始され、トレーニングの途中で終了する可能性があります。これには、Lambda の ML ランタイムがワーカーの頻繁な出入りを許容できる必要があります。

高速な共有ストレージが不足しています。 Lambda 関数は相互に接続できないため、共有ストレージが必要です。 ML アルゴリズムには厳しいパフォーマンス要件があるため、この共有ストレージは低レイテンシ、高スループットで、ML ワークロードの通信タイプに合わせて最適化されている必要があります。しかし、これまで、クラウドにこれらすべての属性を提供できる高速なサーバーレス ストレージは存在しませんでした。

しかし、サーバーレスコンピューティングの実用化事例はすでに数多く存在します。その中でも代表的なパブリッククラウド サーバーレス プラットフォームは次のとおりです。

AWS ラムダ。 Amazon の AWS Lambda を使用すると、ほぼすべての種類のアプリケーションやバックエンド サービスのコードを、まったく管理せずに実行できます。コードをアップロードするだけで、Lambda が高可用性を維持しながらコードを実行および拡張するために必要なすべての処理を行います。開発者は、他の AWS サービスから自動的にトリガーされるコードや、任意の Web アプリケーションまたはモバイル アプリケーションから直接呼び出されるコードを設定することができます。 https://aws.amazon.com/cn/lambda/ をご覧ください。

Microsoft Azure 関数。 Microsoft の Azure は、複雑なオーケストレーションの問題を解決できるイベント駆動型のサーバーレス コンピューティング プラットフォームです。追加のセットアップなしでローカルでビルドおよびデバッグし、クラウドで大規模にデプロイおよび運用し、トリガーとバインディングを使用してサービスを統合します。 https://azure.microsoft.com/en-us/services/functions/ をご覧ください。

Google Cloud Functions。 Google の Cloud Functions は、イベント駆動型のコンピューティング サービスです。自動的にスケーリングし、イベントに応じてコードを実行し、コードの実行時にのみ料金が発生し、サーバー管理が不要という機能を備えています。ユースケースには、サーバーレス アプリケーション バックエンド、リアルタイム データ処理、仮想アシスタント、チャットボット、感情分析などのインテリジェント アプリケーションが含まれます。詳しくはこちら

Alibaba Cloud Function Compute。 Alibaba の Function Compute は、イベント駆動型の完全マネージド型サーバーレス コンピューティング サービスです。サーバーなどのインフラストラクチャを管理する必要はありません。コードを記述してアップロードするだけです。Function Compute がコンピューティング リソースを準備し、弾力性と信頼性のある方法でコードを実行します。 Function Compute は、すべてのお客様に、毎月 100 万回の関数呼び出しと 40 万個の関数インスタンス リソースの無料サーバーレス コンピューティング サポートを提供します。 https://www.aliyun.com/product/fc?spm=5176.10695662.1112509.1.3b6768bc2OOWFL です。

代表的なプライベート クラウド サーバーレス フレームワークには次のものがあります。

核分裂。 Fission は Kubernetes を使用して関数を構築します。これにより、プログラマーは任意のプログラミング言語で関数を記述し、それを任意のイベント トリガー (HTTP リクエストなど) にマップできるようになります。 https://fission.io/ をご覧ください。

関数。 Funktion は、Kubernetes を使用して関数を構築するオープンソースのコンテナネイティブ サーバー プラットフォームです。これにより、プログラマーは任意のプログラミング言語で関数を記述し、任意のクラウドまたはローカルのどこでも実行できるようになります。 https://github.com/funktionio/funktion.

キューブレス。これは、Kubernetes ネイティブのサーバーレス コンピューティング フレームワークです。 Kubernetes リソースを活用して、自動スケーリング、API ルーティング、監視、障害回復などの機能を提供します。 https://github.com/kubeless/kubeless.

Apache OpenWhisk。 OpenWhisk は Docker を使用して関数を構築します。これにより、プログラマーは Scala 言語で関数を記述でき、あらゆる規模のイベントに応じてコードを実行できます。フレームワークは、HTTP リクエストなどのトリガー イベントに応答し、JavaScript または Swift コードのスニペットを実行します。 https://openwhisk.apache.org/ をご覧ください。

鉄の機能。 Iron は Docker、Swarm、Kubernetes を使用して関数を構築し、プログラマーが Go 言語で関数を記述できるようにします。 https://github.com/iron-io/functions.

オープンラムダ。 OpenLambda は、Go で記述され、Linux コンテナをベースにした、Apache ライセンスのサーバーレス コンピューティング プロジェクトです。 OpenLambda の主な目標は、サーバーレス コンピューティングへの新しいアプローチを模索することです。 https://github.com/open-lambda/open-lambda.

オープンFaas。 OpenFaaS は、メトリクスに対する第一級のサポートを備えた、Docker を使用してサーバーレス関数を構築するためのフレームワークです。あらゆるプロセスを関数としてパッケージ化できるため、定型的なコーディングを繰り返すことなく、さまざまな Web イベントを使用できます。 https://www.oschina.net/p/openfaas?hmsr=aladdin1e1.

サーバーレス プラットフォームの代表的なパッケージ フレームワークは次のとおりです。

Zappa (Python、AWS)。 Zappa は、AWS Lambda + API Gateway 上での Python WSGI アプリケーションの公開を大幅に簡素化します。これは、サーバーなしで Python Web アプリケーションをデプロイして実行するのと同じです。これは、無制限のスケーラビリティ、ダウンタイムゼロ、メンテナンスゼロを意味します。 https://www.oschina.net/p/python-zappa.

Chalice (Python、AWS)。 Chalice を使用すると、開発者は Amazon API Gateway と AWS Lambda を使用してアプリケーションを迅速に作成およびデプロイできます。 https://www.oschina.net/p/chalice?hmsr=aladdin1e1.

Claudia.js (Node、AWS)。 Node.js プロジェクトを AWS Lambda および API Gateway に便利かつ迅速にデプロイします。エラーが発生しやすいすべてのデプロイメントおよび構成タスクを自動化し、JavaScript 開発者が期待するとおりにすべてをセットアップします。開発者は Lambda と API Gateway を簡単に使い始めることができ、AWS デプロイメントワークフローに対処する代わりに重要なビジネス問題の解決に集中できます。 https://github.com/claudiajs/claudia.

2. ML によるサーバーレス コンピューティングに関する最新の研究の紹介

前のセクションで学んだように、パブリック クラウドとプライベート クラウドのサーバーレス コンピューティング プラットフォームはすでに数多く存在し、サーバーレス プラットフォーム用のパッケージ フレームワークもいくつか存在します。日常のアプリケーション実践において、サーバーレスを試すことは比較的容易であると言えます。しかし、機械学習に関しては、これらのサーバーレス コンピューティング プラットフォームはすべて、ML アプリケーション シナリオでいくつかの問題を抱えています。

第 1 章の紹介からわかるように、サーバーレス コンピューティングは分散型データセンターに非常に適していますが、パフォーマンスが重要なアプリケーションの有効性に直接影響する、データの局所性や階層型通信を使用した最適化などの従来のパフォーマンス最適化手法をサーバーレス コンピューティングが遮断するため、多くのパフォーマンスが重要なアプリケーションにはあまり適していません。現在、サーバーレス プラットフォームは主に、IoT 自動化、フロントエンド Web サービス、ログ処理などの単純なイベント駆動型アプリケーションに使用されています。

最近、一部の研究者は、並列データ分析や分散ビデオエンコーディングなど、より幅広いシナリオにサーバーレスコンピューティングを適用しています。ただし、これらのワークロードは単純に並列化することしかできないか、または関数間で単純な通信パターンを使用するしかありません。複雑な通信パターンとワークロードをサーバーレス コンピューティングに効果的に適応させる方法は、未解決の研究課題のままです。この投稿では、ML 向けのサーバーレス コンピューティングに焦点を当てます。 ML は多数のパラメータと複雑な処理フローを伴い、典型的な「パフォーマンスクリティカルなアプリケーション」であることがわかっています。このセクションでは、「サーバーレス コンピューティングに ML をどのように導入するか」という問題に関する最新の研究の進捗状況を紹介します。

2.1 サーバーレス機械学習の事例 [2]

この記事は、バークレーの研究者が NIPS2018 で発表した記事です。特に、ML ワークロード環境におけるリソース管理の問題を分析し、サーバーレス インフラストラクチャを使用して ML ワークフロー リソース管理を自動化する研究の方向性を探ります。著者らは、サーバーレス インフラストラクチャと ML ワークフロー向けに特別に設計されたサーバーレス 機械学習フレームワークを提案しています。

この記事で説明するサーバーレスコンピューティングは、開発者によって送信され、クラウドインフラストラクチャによって自動的にスケジュールされる Amazon S3 のステートレス Lambda 関数に依存しています。したがって、開発者が長期間使用されるコンピューティング ユニット (VM など) を明示的に構成、展開、管理する必要がなくなります。一般的なサーバーレス コンピューティング プラットフォームとは異なり、サーバーレス 機械学習フレームワークでは、3 つの主要な目標を満たす必要があります。まず、 API はデータの前処理、トレーニング、ハイパーパラメータの最適化など、幅広い ML タスクをサポートする必要があります。既存の ML システムからの移行に伴う作業を簡素化するには、このような API を Python などの高級言語で開発する必要があります。 2 番目に、ステートレス ワーカー間の中間データとメッセージング用のストレージを提供するには、豊富なインターフェイスを備えた低レイテンシでスケーラブルなデータ ストアを提供する必要があります。 3 番目に、リソースが制限された Lambda で効率的に実行するには、ランタイムが軽量かつ高性能である必要があります。

これらの条件を満たすために、著者らは ML 専用のサーバーレス フレームワークを構築しました。

まず、このフレームワークは、ML ワークフローのすべての段階に、より広範な ML コミュニティにとって実用的で使いやすい API を提供します。 （1）APIはPythonパッケージに完全に含まれているため、ML開発者は簡単に呼び出すことができます。 （２）APIは、基礎となるシステムレベルのリソースを抽象化する高レベルインターフェースを提供します。 （3）Pythonパッケージは、開発者が作業の進行状況を視覚化できるユーザーインターフェースを提供します。

フレームワークは、クライアント バックエンドへのインターフェイスを提供する Python フロントエンドで構成されます。このバックエンドは、一時的なコンピューティング リソースの管理とタスクのスケジュール設定を担当します。このバックエンドでは、異なるサブモジュールが ML ワークフローの特定のステージごとにロジックをエンコードします (例: 前処理)。これらのサブモジュールは、Lambda 上でワーカーを開始し、計算の進行状況を追跡し、計算が完了したら結果を Python フロントエンドに返します。クライアント バックエンドは、サーバーレス Lambda で実行されるタスクの起動、終了、および再生成に関連するすべてのロジックをカプセル化する内部の低レベル スケジューラを使用します。スケジューラはすべてのタスクのステータスも追跡します。

3 番目に、フレームワークは、システムでサポートされているさまざまな計算間で共有されるすべての関数をカプセル化する軽量ランタイムを提供し、それによって新しいアルゴリズムの開発を簡素化します。ワーカー ランタイムは 2 つのインターフェースを提供します。まず、S3 に保存されているトレーニング データセット用のスマート イテレータを提供します。このイテレータは、ワーカーの計算と並行して、Lambda のローカルメモリにミニバッチをプリフェッチしてバッファリングし、S3 へのアクセスの高レイテンシ (> 10 ミリ秒) を軽減します。分散データストレージ用の API を提供します。

最後に、フレームワークは中間データとワーカー間の通信のための豊富なインターフェースを備えた共有ストレージを提供します。このインターフェースには、(1)一般的なメッセージング、中間データの保存、およびデータ削減のためのキーバリューストアと、(2)パラメータサーバーインターフェースの2種類のAPIがあります。必要な低レイテンシを実現するために、データ ストアはクラウド VM にデプロイされます。限られたネットワーク リソースを効果的に活用するために、データ圧縮、スパース データ構造、非同期通信などのデータ ストレージ インターフェイスが最適化されています。

機械学習ワークフローの実行を簡素化するという目標を達成するには、理想的なシステムはシンプルでありながら十分に汎用的な API を提供する必要があります。このAPIは、ユーザーが（1）データセットの読み込み、共通データ形式のサポート、（2）データの前処理、（3）モデルのトレーニング、（4）大規模なハイパーパラメータの調整などのMLタスクを単一の統合フレームワーク内で実行できるようにする必要があります。

著者らは、この API の機能を示す例を示しています。図 1 は、Criteo Kaggle コンペティションに基づいてモデルを開発するプロセスを示しています。このモデルは、ディスプレイ広告データセット内の広告をユーザーがクリックする確率を予測するために使用されます。ワークフローの最初のステップは、データセットをロードして Amazon S3 にアップロードすることです。たとえば、ユーザーは load_libsvm メソッドを呼び出して、LIBSVM 形式で保存されたデータセットをロードし、データを解析して、自動的にパーティションを作成し、Amazon S3 にアップロードすることができます。 2 番目に、データが Amazon S3 にロードされると、すぐに前処理できます。システムは、開発者が一般的に使用するいくつかの前処理方法を提供する必要があります。たとえば、ユーザーは、Amazon S3 内のデータセットへのパスを指定して normalize 関数を呼び出すことで、データセットを正規化できます。データがロードされると、ユーザーはさまざまなモデルをトレーニングし、システムのテスト損失を確認してモデルのパフォーマンスを確認できます。ユーザーが特定のモデルに対して妥当な損失を達成したら、ハイパーパラメータ検索を通じてそれを微調整できます。さらに、著者らは、各ステージの実行中にユーザーが複数回対話できるようにするシステムを構想しています。たとえば、ハイパーパラメータ検索タスクの実行中に、ユーザーは個々の実験ごとにテスト損失を監視できる必要があります。パフォーマンスが良好でない実験（テスト損失が発散しているなど）の場合、ユーザーは実験を終了できる必要があります。この機能は、Jupyter などのインタラクティブ環境のユーザー インターフェイスを通じて実装できます。

図 1. API の例。サーバーレス ML の API は、ML 開発ワークフローのさまざまな段階 ((a) 前処理、(b) トレーニング、(c) ハイパーパラメータの調整) をサポートする必要があります。

MLサーバーレスフレームワークの需要を評価するために、著者らはパフォーマンス比較のためにPyWren[3]とBosen[4]という2つのフレームワークを導入した。 PyWren は、サーバーレス アーキテクチャ向けに特別に設計された Map-Reduce フレームワークです。 PyWren は、数千のワーカーに拡張可能な map および Reduce プリミティブを提供します。 Bosen は、VM ベースの ML アルゴリズム専用の分散パラメータ フレームワークです。評価のために、著者らは PyWren に非同期 SGD トレーニング アルゴリズムを実装しました。 PyWren ベースライン実装に基づいて、著者は一連の最適化も実行しました。著者らは、Criteo Kaggle コンペティションの Criteo ディスプレイ広告データセットを実験に使用しました。著者らは、PyWren を 10 個の最大の AWS Lambda (3GB メモリ) で実行し、Bosen を単一の VM (m5.2xlarge1) の 8 コアで実行しました。

著者らは、時間の経過に伴うテスト損失を記録することで、これら 2 つのシステムのパフォーマンスを測定しました (図 2)。 PyWren の場合、著者は各最適化を実装した後にこの値を報告します。著者らは、次の最適化を累積的に実装しました: (1) 反復処理全体で Lambda を再利用、(2) 小規模バッチのプリフェッチに非同期 SGD を使用、(3) Amazon S3 の代わりに低レイテンシのストレージ (Redis) を使用、(4) 複数の get 操作でスパース データ転送を使用。これらの最適化により、600 秒後に Pyren によって達成された最終テスト損失が大幅に改善されることがわかります (0.61 から 0.57)。これらの改善にもかかわらず、PyWren は依然として Bosen よりも大幅に遅いです。さらにパフォーマンスを分析すると、PyWren には、データのシリアル化/デシリアル化や、インターフェースが ML ワークロードに適さないリモート ストレージ (Redis や S3 など) の使用など、オーバーヘッドがあることがわかりました。この結果は、サーバーレス コンピューティング フレームワークの設計の初期段階で、ML ワークロードのパフォーマンス要件を慎重に考慮する必要があることを示唆しています。

図 2. Criteo-Kaggle ロジスティック回帰タスクにおける PyWren と Bosen のパフォーマンス。 PyWren ベースラインは、Lambda の再利用、プリフェッチの追加、非同期計算への切り替え、S3 をより高性能な Redis ストレージ バックエンドに置き換え、単一の RPC で複数のキーの取得をサポートすることで、段階的に改善されてきました。

さらに、著者らは、本論文で提案したフレームワークのプロトタイプを構築した。これには、(1)パラメータサーバーインターフェースを備えた高性能データストレージ、(2)ミニバッチデータの循環バッファプリフェッチ、(3)ロジスティック回帰SGDトレーニングアルゴリズムが含まれる。この設計の利点を完全に検証するために、著者らは同じロジスティック回帰タスクで評価しました。著者らは、ワーカーあたりの平均 SGD 反復時間を測定しました (図 3 を参照)。この時間はワーカーのパフォーマンスの指標です。反復時間が短いほど、モデルの更新頻度が高くなり、収束が速くなります。著者らは今回、SGDアルゴリズムを4つの主なステップに分解しました。(1)データストアから最新のモデルを取得する、(2)リモートストレージ(S3など)からミニバッチを取得する、(3)SGD勾配を計算する、(4)勾配をデータストアに送信する、です。著者らは、サーバーレス コンピューティングに固有のオーバーヘッドにもかかわらず、提案されたフレームワークのプロトタイプは、Bösen などのシステムに匹敵する、反復あたりの短い時間 (500 μs) を達成したことを発見しました。このパフォーマンスは、(1) リモート ミニバッチの効率的なプリフェッチとバッファリング、(2) 可能な限りデータ ストアと通信するという 2 つのメカニズムから生まれます。まず、ミニバッチ プリフェッチ メカニズムは、計算と並行して実行することで、S3 からミニバッチをフェッチするのに必要な時間を効果的に隠します。実際には、中規模/大規模の Lambda の場合、ほとんどの場合、データはワーカーに必要なときまでメモリにキャッシュされるため、新しいミニバッチで計算を開始するために必要な時間はごくわずかです。これは、S3 からミニバッチを取得するのに 10 ミリ秒かかる場合でも当てはまります。第二に、著者らはデータ ストアとの通信が効率的であることを発見しました (たとえば、勾配を送信する時間はごくわずかです)。データ ストアと非同期に通信する機能により、フレームワークのパフォーマンスがさらに向上します。

図 3. 提案されたプロトタイプの SGD 反復あたりの時間。これは、(1) データ ストアへの勾配の送信、(2) 勾配の計算、(3) データ ストアからのモデルの取得、(4) S3 からのミニバッチの取得という 4 つの主なステップに分かれています。

2.2. Cirrus: エンドツーエンドのMLワークフローのためのサーバーレスフレームワーク [5]

この論文も、セクション 2.1 で紹介したバークレー研究チームの研究成果であり、セクション 2.1 で分析した NIPS'18 論文に含まれる作業を拡張および拡張したものです。サーバーレスインフラとMLワークフローに特化したサーバーレスMLフレームワークのプロトタイプをベースに、エンドツーエンドの管理を実装し、直接呼び出して使用できる分散MLトレーニングフレームワークCirrusにカプセル化されており（https://github.com/ucbrise/cirrus）、関連する作業内容はSoCC '19で公開されています。 Cirrus は、Amazon AWS Lambda などのサーバーレス クラウド インフラストラクチャでの ML トレーニング用に特別に設計されています。データセットの前処理、トレーニング、ハイパーパラメータの最適化など、ML ワークフローのさまざまなタスクをサポートするための高レベルのプリミティブを提供します。 Cirrus は、サーバーレス インターフェイスのシンプルさとサーバーレス インフラストラクチャ (具体的には AWS Lambda と S3) のスケーラビリティを組み合わせて、ユーザーの作業を最小限に抑えます。

Cirrus の設計原則は次のとおりです。

適応型のきめ細かいリソース割り当て。過剰プロビジョニングによるリソースの浪費を避けるために、Cirrus はワークフローの各ステージに予約されるきめ細かいリソースの量を柔軟に調整する必要があります。

ステートレスなサーバー側バックエンド。サーバーレス コンピューティング リソースの堅牢かつ効率的な管理を実現するために、Cirrus はステートレスなサーバー側バックエンドを設計しました。現在デプロイされている関数に関する情報と、ML ワークフロー タスクとコンピューティング ユニット間のマッピングは、クライアント側のバックエンドによって管理されます。したがって、すべてのクラウド リソースが利用できなくなった場合でも、ML トレーニング ワークフローは失敗せず、リソースが再び利用可能になったときに操作を再開できます。

エンドツーエンドのサーバーレス API 。モデルのトレーニングは、ML 研究者の唯一のタスクではありません。データセットの前処理、特徴エンジニアリング、およびパラメータの調整は、最終的に優れたモデルを生成するために同様に重要です。 Cirrus は、開発者が最小限の労力でこれらのタスクをエンドツーエンドかつ大規模に実行できるようにする完全な API を提供する必要があります。

高いスケーラビリティ。 ML タスクは計算負荷が非常に高く、効果的な並列化を行わないと完了までに長い時間がかかります。したがって、Cirrus は数千のワーカーと数百の実験を同時に実行できるはずです。

セクション 2.1 で説明した作業と同様に、Cirrus は 4 つのシステム モジュールを使用して上記の原則を実装します。まず、Cirrus は ML 開発者向けに Python フロントエンドを提供します。このフロントエンドには、a) ML トレーニングのすべての段階に豊富な API を提供する機能と、b) サーバーレス インフラストラクチャで大規模な計算を実行および管理する機能の 2 つの機能があります。次に、Cirrus はクライアント バックエンドを提供します。 3 番目に、低レイテンシのサーバーレス ストレージの欠点を克服するために、Cirrus は、ワーカーによって共有されるすべての中間データに対して低レイテンシの分散データ ストレージを提供します。 4 番目に、Cirrus はサーバーレス Lambda 上で実行されるワーカー ランタイムを提供します。ランタイムは、S3 内のトレーニング データセットと分散データ ストア内の中間データにアクセスするための効率的なインターフェイスを提供します。 Cirrus の完全な構造を図 4 に示します。

図 4. Cirrus システムのアーキテクチャ。システムは、(ステートフル) クライアント (左) と (ステートレス) サーバー (右) で構成されています。前処理とユーザー指向のトレーニングには、フロントエンド API が含まれます。クライアント バックエンドはクラウド関数を管理し、関数にタスクを割り当てます。サーバー側は、Lambda Worker と高性能データ ストレージ コンポーネントで構成されています。 Lambda ワーカーは、データ反復 API をクライアントのバックエンドにエクスポートし、多くの反復トレーニング アルゴリズムの効率的な実装を含んでいます。データ ストレージは、勾配、モデル、および中間の前処理結果を保存するために使用されます。

Cirrus の全体的な構造は、セクション 2.1 の構造と似ています。 Cirrus のフロントエンドとクライアント バックエンドは Python で実装されているため、Cirrus を既存の機械学習手法と簡単に統合できます。効率を向上させるために、分散データストレージとワーカーランタイムがC ++で実装されます。表2に、実装のさまざまなコンポーネントとそのサイズおよび実装言語を示します。ワーカーランタイムコードには、Iteratorインターフェイスとデータストレージクライアントの実装が含まれます。ワーカーランタイムとデータストアは、TCP接続を介して通信します。著者は、すべてのシステムコンポーネントで共有される線形代数ライブラリ、共通ユーティリティ、およびMLアルゴリズムを含む共有コンポーネントライブラリを実装しました。著者は、Apache 2オープンソースライセンス（https://github.com/ucbrise/cirrus）の下で公開されています。

表2。cirrusコンポーネント。

まず、CirrusはMLワークフローのすべての段階にPythonフロントエンドAPIを提供します。フロントエンドは非常に柔軟な薄いPython APIであり、デフォルトでは、API引数を介して内部構成パラメーター（最適化アルゴリズムなど）をオーバーライドする機能を提供しながら、開発者からのすべての詳細を抽象化します。また、FrontEndは、ユーザーがワークロードの進行状況を監視し、タスクを開始/停止するためにプロットで実行されているユーザーインターフェイスを提供します。 Cirrus Python APIは、3つのサブモジュールに分割されます。各サブモジュールは、ワークフローの各段階に関連するすべての機能とクラスをパッケージ化します。 （1）前処理プリプロセシングサブモジュールにより、ユーザーはS3に保存されているトレーニングデータセットを事前に処理できます。このサブモジュールにより、さまざまなタイプのデータセット変換が可能になります：MIN-MAXスケーリング、正規化、および特徴ハッシュ。 （2）トレーニング。 Cirrusのトレーニングサブモジュールは、確率的勾配降下を介してトレーニングできるMLモデルをサポートします。現在、Cirrusは、まばらなロジスティック回帰、潜在的なディリクレの割り当て、ソフトマックス、および共同フィルタリングをサポートしています。 （3）ハイパーパラメーターの最適化。ハイパーパラメーター最適化サブモジュールにより、ユーザーは特定のパラメーターセットでグリッド検索を実行できます。 Cirrusを使用すると、ユーザーはMLトレーニングパラメーター（学習率、正規化率、ミニバッチサイズなど）とシステムパラメーター（ラムダ関数サイズ、同時ワーカーの数、勾配フィルタリング）を変更できます。

第二に、Cirrus Pythonフロントエンドは、Cirrusクライアントのバックエンドへのインターフェイスを提供します。このバックエンドが達成できる機能とタスクは、セクション2.1で導入されたフレームワークとまったく同じです。クライアントバックエンドは、FrontendアルゴリズムからLambdaの管理を抽象化します。クライアントバックエンドは、現在アクティブなラムダのリストとAWSラムダAPIへの接続のリストを保持します（各接続はラムダの開始に使用されます）。トレーニング中にロードされたラムダは、生涯の終わりに自動的にリロードされます（15分ごとに1回）。 Lambda APIの特性により、単一のサーバーから何百ものラムダをすばやくロードすることは非常に困難です。この問題を解決するために、バックエンドは、新しいラムダタスクのリクエストに応答するために使用できるスレッドプールを維持します。

第三に、Cirrusは分散ストレージモジュールを提供します。 Cirrusのデータストレージは、すべての労働者が共有する中間データを保存するために使用されます。既存の製品では、ラムダが互いに通信することはできないため、ラムダは共有ストレージを必要とします。サーバーレスLambdaのストレージは、3つの条件を満たす必要があります。まず、MLトレーニング（反復SGD）に使用されるレイテンシに敏感なワークロードに対応できるように、低遅延（このペーパーでは300μsという低い）が必要です。第二に、サーバーレスインフラストラクチャのほぼ線形スケーラビリティを活用するために、数百人の労働者にスケーリングする必要があります。第三に、さまざまなMLユースケースをサポートするために豊富なインターフェイスが必要です。たとえば、データストアは、マルチゲット（§6.5）、通常のキー/値のPut/Get操作、およびパラメーターサーバーインターフェイスをサポートする必要があります。低遅延を達成するために、データストレージはクラウドVMに展開されます。 AWS S3の約10msの遅延と比較して、300μsという低いレイテンシーを達成します。この遅延は、トレーニングフェーズ中のモデルの更新を最大化するために重要です。著者は、スパース表現を使用して勾配とモデルを特徴付けて、ストレージとバッチ要求を使用したデータ交換のために最大100倍の圧縮比を達成します。高いスケーラビリティを実現するために、Cirrusには次のメカニズムが含まれています。（1）シャードストレージ、（2）高度にマルチスレッド、（3）データ圧縮、（4）勾配フィルター、（5）非同期通信。 Cirrusの分散データストレージは、MLワークフローに中間データを保存するためのすべてのユースケースをサポートするインターフェイスを提供します。このインターフェイスは、Key-Valueストレージインターフェイス（SET/GET）およびパラメーターサーバーインターフェイス（実際にdient/getモデルを送信）をサポートします。

最後に、Cirrusは、システムでサポートされている異なる計算間で共有されたすべての機能をカプセル化するランタイム（ランタイム）を提供します。図5に示すように、Cirrusのランタイムは、トレーニングデータ、パラメーターモデル、および中間結果にアクセスするためのML計算の一般的な抽象化と基本データ型を提供します。これらを使用して、Cirrusに新しいMLモデルを追加できます。新しいアルゴリズムの開発を簡素化するために、ランタイムは一連の線形代数ライブラリを提供します。 Cirrusの初期バージョンでは、勾配計算にはEigenなどの外部線形代数ライブラリを使用しています。固有の時間を短縮するために、データのシリアル化と降下処理を処理するために、著者は最終的に独自の線形代数ライブラリを開発しました。データアクセスのために、Runtimeは、労働者が低遅延アクセスでミニバッチを訓練できるようにするローカル円形バッファーでサポートされたミニバッチベースのイテレーターを提供します。さらに、分散データストアと通信するための効率的なAPIを提供します。

図5。CIRRUSランタイム。ミニバッチは、各ラムダを記憶して非同期にプリフェッチされ、局所的にキャッシュされます（使用するラムダのサイズに応じて）。勾配はパラメーターサーバーに非同期に送信され、モデルは各反復に対してパラメーターサーバーから同期的に取得されます。

著者は、さまざまな段階で作業するCirrusの詳細な方法を提供します。

（1）データの読み込みと前処理。 Cirrusは、トレーニングデータがS3などのグローバルストレージに保存されると想定しています。したがって、Cirrusを使用する最初のステップは、データセットをクラウドにアップロードすることです。ユーザーはデータセットのパスをシステムに渡し、システムはデータセットの解析とアップロードを担当します。このプロセスでは、Cirrusはデータセットを元の形式（CSVなど）からバイナリ形式に変換します。この圧縮により、トレーニングおよびハイパーパラメーターのチューニングフェーズ中に脱色する必要性がなくなり、Lambdaワーカープロセスの計算負荷を減らすことができます。第二に、Cirrusは同様のデータセットサイズのパーティションを生成し、それらをS3バケット（S3バケット）にアップロードします。

Cirrusは、モデルのパフォーマンスを改善するために変換を適用することもできます。たとえば、Cirrusによって実装された非同期SGD最適化方法の場合、データセットの機能を正規化するとトレーニング効果が向上する可能性があります。これらの変換では、Cirrusは大規模なマップを開始します。ジョブを減らします。入力パーティションごとに1人のワーカーです。マップフェーズ中、各ワーカーは、パーティションの統計（平均および標準偏差など）を計算します。削減段階では、これらのローカル統計が集計されてグローバル統計を計算します。最終マッピングフェーズでは、ワーカーは各パーティションサンプルを変換して、各列の最終統計を提供します。大規模なデータセットの場合、多数の労働者と列にわたって各列のマップと削減フェーズが統計を集約します。これにより、S3でサポートされているトランザクションスループットを超える1秒あたりの新しい書き込みおよび読み取り操作が生成されます。このため、著者はCirrusの低遅延分散データストアを使用して、マッピングされた中間結果を保存し、計算量を削減します。

（2）モデルトレーニング。 Cirrusは、モデルトレーニングに分散されたSGDアルゴリズムを使用しています。トレーニング中、ワーカーはラムダ関数を実行し、勾配ステップサイズを繰り返し計算します。各勾配計算には、ミニバッチと最新モデルの2つの入力が必要です。ミニバッチは、cirrusのランタイムのためにS3からイテレーターを介して取得されます。イテレーターは作業メモリでミニバッチをバッファリングするため、ミニバッチを取得するレイテンシは非常に低いです。データストレージAPI（get_sparse_model_x）を使用して、データストレージの最新モデルを同期させます。反復ごとに、各ワーカーは新しい勾配を計算します。この勾配は、モデルを更新するために非同期にデータストア（send_gradient_x）に送られます。

（3）ハイパーパラメーターの最適化。ハイパーパラメーターの最適化は、モデルパラメーターの検索方法であり、生成の最適精度を確保できます。典型的なアプローチは、多次元パラメータースペースでグリッド検索を実行することです。検索は、ブルートフォース検索または適応型検索です。一般的な慣行は、グリッド検索を完全に実行し、結果を後処理して最適な構成を見つけることです。これは費用のかかるリソースの無駄です。 Cirrusは、ハイパーパラメーター検索ダッシュボードを提供することにより、時間の経過とともにこの過度のプロビジョニングを解決します。 Cirrus HyperParameterダッシュボードは、モデルの時間にわたる損失の収束を監視するための統一されたインターフェイスを提供します。これにより、ユーザーは単一の損失曲線を選択し、対応するトレーニング実験を終了できます。したがって、Cirrusは次のとおりです。APIは、ハイパーパラメーターの検索を開始し、モデルの精度を監視するためのダッシュボード。

文献の研究[2]に基づいて、CirrusはMLユーザーに軽量のPython APIを提供します。著者はまた、このAPIの機能を示す例を示します。図6に示すように、このAPIは、図1に示す文献[2]のAPIとほぼ同じです。違いは、この記事がモジュール「Cirrus」としてcirrusをカプセル化し、Pythonに直接インポートできることです。

図6。CIRRUSAPIの例。 Cirrusは、ML開発ワークフローのさまざまな段階をサポートしています。

著者は、スパースロジスティック回帰タスクを使用して、VMベースのTensorflow [6]とBosen [4]専用のCirrusと2つのMLトレーニングフレームワークを比較します。 Tensorflowは、MLコンピューティングの一般的なデータフローエンジンです。 Bosenは、CMUが商業化のために開発した分散およびマルチスレッドパラメーターサーバーであり、大規模な分散クラスターと機械学習アルゴリズムの古い更新用に最適化されています。ロジスティック回帰は、特定のサンプルが2つのクラスの関心に属する可能性を計算する問題です。この実験では、著者はWebサイト広告がクリックされる可能性を計算し、時間関数を使用して学習収束を評価します。 Criteoを使用して広告データセットを表示します[7]。このデータセットには45mのサンプルが含まれており、11GBのサイズがあります。各サンプルには、13の数値機能と26のカテゴリ機能が含まれています。トレーニング前に、データセットが正規化され、分類機能はサイズ2^20のスパースベクトルにハッシュされます。 Bosenを評価するために、著者は1、2、および4 M5.2xlarge Amazon AWSインスタンス（それぞれ8 cpuと32GBのメモリを備えた）を使用しました。骨付き実験では、著者はデータセットをすべてのマシンに分割します。 Cirrusを評価するために、著者はAmazon AWS Lambdaをワーカーとして使用し、M5.largeインスタンス（2 CPU、8GBメモリ、10Gbpsネットワーク）をパラメーターサーバーとして使用し、AWS S3ストレージはデータと定期的なバックアップモデルのトレーニングに使用されます。著者は、両方のシステムの学習率の範囲を試した後に得られた最良の結果を報告しています。ボーセンの場合、学習率と労働者の数のみが変更されます。他のすべての構成パラメーターは、デフォルト値を保持します。

図7aは、一定期間にわたってさまざまな数のサーバー（ボーセン用）とAWSラムダ（cirrus用）によって実装されたロジックテスト損失を示しています。損失値は、50Kサンプルを含むデータセット上のトレーニングモデルを評価することにより得られます。著者らは、CirrusがBosenよりも大幅に速く収束したことを発見しました。ボーセンのパフォーマンスは影響を受けます。なぜなら、ワーカーが互いに競争してローカルのキャッシュを共有するため、勾配をパラメーターサーバーに送信する前に勾配を集約します。この設計は、最終的にボーセンの収束率が遅いことにつながります。図7Bでは、著者は同じデータセットと同じ前処理手順を使用して、CirrusをTensorflowと比較しました。同様に、CirrusはTensorflowよりも優れています。

図7Cの実験では、Netflixデータベース[8]を使用して、CirrusとSparkの共同フィルタリングタスクの完了を比較しています。図7Cから、CirrusはSparkよりも速く収束し、テスト損失が低くなります。さらに、著者は、SparkのALS実装は、データセット全体をメモリにロードする必要があるため、SparkのALS実装が高価なRDDオーバーヘッドの影響を受けることを観察しました。これにより、Sparkはモデルのトレーニングに直接関係していない仕事をする時間の94％以上を費やします。対照的に、CirrusはデータをS3からワーカーまで継続的にストリーミングし、すぐに計算を開始できます。

図7。ボセンは0.485の最適な損失を達成し、Cirrusは少なくとも5倍速い（200秒対1000秒）最適な損失を達成しました。最先端のMLトレーニングフレームワークと比較して、Cirrusは1つまたは2つのラムダ（300〜600秒）の生涯にわたってより速く収束し、損失が低くなります。 （b）Tensorflow Criteo_tftベンチマークとcirrusの収束と時間曲線。 Tensorflowは32のコアノードで実行され、Cirrus Runsは10 Lambdasで実行されます。 （c）Netflixデータセットを実行したときの時間の経過とともに、Spark（ALS）およびCirrusのRMSE曲線。 Sparkは、Netflixデータセットを実行するときに最初の4分間データを処理し、ALSの5回の反復（RMSE = 0.85）で収束した後に終了します。 Cirrusはより低いRMSE（0.833）に収束します。

図8の実験では、Cirrusのスケーラビリティを検証します。このシステムは、拡張の3つの次元を実現するように設計されています。S3でトレーニングデータを保存し、LambDAとの計算、分散パラメーターサーバーとメモリを共有してスケーラビリティを実現します。

ストレージのスケーラビリティ：Cirrusは、S3のトレーニングデータセットを中型オブジェクトに分割することにより、この問題を解決します。著者は10MBのオブジェクトを使用しています。これは、このサイズが適切なネットワーク利用を実現できることを発見し、最小サイズのLambdaにも十分に小さいことを発見したためです。大きなオブジェクトを使用することにより、1秒あたりのリクエスト数が減少します。したがって、各労働者がS3の30MB/sのトレーニングデータを消費すると、S3のスループットを1000輪労働者に直線的に拡張できます（図8A）。

計算のスケーラビリティ：図8Bから、モデルとパラメーターの同期なしで、Cirrusは、入力トレーニングデータと計算勾配を並行して送信することにより、線形計算スケーラビリティを実現できます。

パラメーターサーバーのスケーラビリティ：パラメーターサーバーレベルでは、主な課題は、各仮想マシンVMの限られたネットワーク帯域幅と、モデルを更新し、ワーカーがサーバーをリクエストするために必要な計算から生じます。 Cirrusは、1）モデルのシャーディング、2）スパースグラデーション/モデル、3）データ圧縮、および4）非同期通信によりこの問題を解決します。 Cirrusは、最大600人の労働者の線形スケーラビリティを達成します（図8c）。

図8。AWSストレージ（GB/秒）のスケーラビリティ、AWSサーバーレスコンピューティング（勾配/秒）、およびCirrusデータストレージ（サンプル/秒）。各労働者は、30MB/sのトレーニングデータを消費します。

最後に、著者は専用のMLシステムPywrenをCirrusと比較します。 Pywrenは、サーバーレスのラムダで実行されているマップレディースフレームワークです。マップを提供し、数千人の労働者に拡張できるプリミティブを削減します。 Pywrenのランタイムは、AWS Lambdaで実行されるように最適化されています。これは、この記事でCirrus実験に使用されるサーバーレスプラットフォームでもあります。著者は、実験でパイウェンを最適化し、各モデルの更新の平均時間を700回（14秒から0.02）増加させましたが、秒あたりのモデルの更新はci骨よりもはるかに低く（図9b）、収束は繊毛よりも著しく遅くなります（図9a）。

図9。10lambdasで実行したときのスパースロジスティック回帰ワークロードに対するpywrenおよびcirrusのパフォーマンス。 Cirrusは、モデルトレーニングの繰り返しでのラムダの再利用、Cirrusの高速データストレージによる効率的なモデル共有の組み合わせにより、モデルの更新が2桁増加します。トレーニングデータのプリフェッチは、S3の高アクセス待ち時間の問題を解決し、更新速度を10回/秒増加させます。

2.3サーバーレスアーキテクチャを使用した機械学習[9]

この記事の著者は、サーバーレスアーキテクチャであるサイレンに完全に基づいた新しい分散機械学習フレームワークを紹介します。サイレンは、オンプレミスのクライアントとAmazon Lambdaなどのサーバーレスクラウドプラットフォームで構成されています。サイレンの完全な構造フレームワークを図10に示します。

図10。サイレン構造

まず、ユーザー定義のMLモデルと依存するライブラリを含むサーバーレスクラウドプラットフォームにコードパッケージを展開します。次に、Stateless Functionグループは、SGDに基づいた最初のエポックトレーニングを実行するために、初期リソーススキーム（つまり、関数の数とメモリサイズの数）に従ってロードされます。最初のエポックの終わりに、ジョブの関数状態と統計が収集され、DRLエージェントが次のエポックのリソーススケジューリング決定を行うために行動を起こします。 Sirenは、トレーニングジョブのエポックでリソーススケジューリングの決定を適応的に調整します。異なるエポックでは、さまざまなメモリ構成を持つさまざまな数の関数を開始できます。

SirenはSGDアルゴリズムを使用し、ミニバッチを使用し、複数のLambda関数で実行します。各ラムダ関数の関数は、従来のパラメーターサーバーアーキテクチャのワーカーに似ています。サイレンとパラメーターサーバーアーキテクチャの主な違いの1つは、モデルパラメーターの更新を処理するためのサイレンにパラメーターサーバーがないことです。代わりに、データとモデルの両方が共通のデータストア（Amazon S3など）に保存され、すべての機能にアクセス可能です。各関数は、パブリックストレージから現在のモデルを読み取り、ミニバッチトレーニングデータに基づいて勾配を計算し、新しく計算された勾配でパブリックストレージのモデルを直接更新します。したがって、アーキテクチャ全体はサーバーレスです。サイレンでは、著者はハイブリッド同期平行（HSP）計算モデルを提案しています。図11に示すように、各エポック内で、すべての関数はモデルを非同期的に更新できますが、各エポックの最後に同期障壁を適用して、次のエポックのリソーススケジューリングを完了します。

エポックはtであり、kth miniバッチはξ_t、kであり、更新モデルは次のとおりです。

エポックT-1の終わりにあるモデルωは、ω_t、0と同じです。 HSPは、ロードされた関数が均一であり、各エポックの同期コストが低くなるため、サーバーレスアーキテクチャで効率的です。サーバーレスクラウドプラットフォームでは、呼び出しおよび終了関数も軽量です。

図11。サーバーレスクラウドでのハイブリッド同期平行（HSP）処理。

著者は、Pythonコードを使用してサイレンを実装し、AWSラムダのMLモデルトレーニングをサポートし、MXNET APIを完全にサポートします。機械学習開発者は、既存のコードをリファクタリングすることなく、従来のMXNETプロジェクトをサイレンで実行できます。図10に示すように、（1）MXNET機械学習ライブラリのコードパッケージをカプセル化します。さらに、AWS Lambdaは、ステートレス機能の軽量と携帯性を確保するための一連の制約の対象となります。

AWSラムダのプログラミングランタイムはネイティブMLトレーニングアルゴリズムをサポートしていないため、著者はコードパッケージにMXNET MLライブラリの一部を導入しました。 AWS Lambdaでは、コードパッケージサイズは250 MBに制限されているため、既製のMLライブラリ（MXNET、TensorFlowなど）をAWS Lambdaに直接ロードすることは不可能です。 MXNETコードパッケージのサイズを削減するために、著者はMXNETソースコードをコンパイルオプションの異なる組み合わせで再コンパイルし、サーバーレスクラウドで不必要なコンピレーションオプションを排除しました。たとえば、use_cuda、use_cudnn、use_openmpなどのオプションは無効です。

AWS Lambdaでは、単一の関数のコンピューティング能力も限られています。各ラムダ関数は、300秒以内に実行する必要があり、最大メモリサイズは3GBです。ただし、AWS LambdaはAWSアカウントごとに最大3000の関数の同時実行をサポートするため、MLトレーニングワークロードを多数のLambda機能と並行することにより、Sirenは高度な並列性を達成します。

著者は、サイレンでの動的なリソース展開を完了するために、ディープ補強学習（DRL）テクノロジーを提案しています。 Rehnection Learning（RL）は、エージェントが動的環境と対話し、アクションを実行するための報酬を獲得することにより、動的環境で実行する方法をエージェントが学ぶ経験駆動型アプローチです。 DRLは、Deep Neural Network（DNN）を使用してRLの問題を解決します。エージェントは、状態と呼ばれる自動環境に対するさまざまな騒々しい信号を観察し、これらの状態をDNNに戻し、アクションを生成します。エージェントは環境で行動を起こし、報酬を受け取ります。報酬は、より良い決定を下すためにDNNのパラメーターを更新するために使用されます。 DRLは、総報酬を最大化するという究極の目標を設定して、意思決定を改善するために閉ループで動作します。

著者は、Bの合計報酬予算でMサンプルを使用してデータセットでMLワークロードをトレーニングすることを検討します。特定の損失値lに達するか、報酬予算bの合計が使用された場合、トレーニングは終了します。任意のエポックtでは、スケジューラは、並列（n_tで示される）と呼び出される関数の数と各関数m_tのメモリサイズについて判断します。図11に示すように、f_tとします。関数Iが稼働している寿命に到達した場合、それの代わりに新しい関数が呼び出され、それはまだf_t、iで表されることに注意する必要があります。各関数F_T、Iでは、新しいミニバッチデータの集約勾配が繰り返し計算され、モデルパラメーターはHSPモードのSGDに従って更新されます。

エポックTでは、関数f_tが完全なサイクル（p^f）_tを取ると仮定します。私はミニバッチデータを取得します。エポックTの機能の完全な実行時間Iは次のとおりです。

HSPのエポックTの全体の期間はP_T = MAX_I（P_T、I）です。エポックTの終わりに、MLタスクの損失値がL_Tに更新されます。

サーバーレスクラウドは、関数の実行時間と関数メモリサイズに基づいてユーザーを充電します。 Cが1GBのメモリを使用して、関数を1秒間実行する単価を表します。エポックtの総コストは次のとおりです。

MLタスクの総報酬コストは次のとおりです。

ここで、Tはエポックの総数を表します。この記事で説明されているタスクの目標は、ジョブの完了時間を最小化することです。つまり、特定の報酬予算Bの制約の下で次の最適化問題を解決することです。

各エポックTの開始時に、DRLエージェントは、図12に示すように、リソース構成計画（N_T、M_T）、つまりDRLタスクのアクションアクションを決定します。アクションの有効性（N_T、M_T）を測定する方法は、各エポックtの終わりにデジタル報酬量子化計算を実行することです。計算は、このエポックP_Tの期間と、タスクの終了時に予算が過剰に引き起こされているかどうかに基づいています。

図12。DNNポリシーで表されるDRL。

状態：この記事に記載されている問題では、エポックTの状態は次のように表現されています。

ここで、L_Tはエポックtの損失値、（p^f）_t、（p^c）_t、および（p^u）_tを表します。 U_Tおよびω_Tはそれぞれ平均メモリとCPUの使用率を表し、B_Tは残りの予算です。

アクション：この記事で説明する問題では、アクションはA_T =（N_T、M_T）として表されます。 N_Tは、アクティブ化された関数の数を表し、M_Tは各関数のメモリサイズを表します。 DRLエージェントはポリシーに従って操作を選択し、ポリシーは、指定された現在の状態の動作空間全体の確率分布π（a | s）として定義されます。著者は、ポリシーグラデーション法を使用して、パラメーターθの関数を介して戦略π（a | s）を近似します。したがって、戦略πはπ（a | s、θ）として記述できます。ここで、θは学習するパラメーターです。戦略πを、実際の値空間のガウス確率密度として定義します。

アクションA_Tは、条件付き確率π（A_T | S_T-1、θ）に基づいて決定されます。次に、大きな離散アクション空間で確率質量関数を学習する問題は、2次元連続空間でパラメーター（μ（s、θ）、σ（s、θ）を見つける問題になります。

報酬：この記事で説明した問題では、各エポックの最後の報酬は、R_T =-βP_Tとして定義されます。ここで、βは正規化係数です。エポックtが長くなればなるほど、エージェントが受ける報酬は少なくなります。最後のエポックtの報酬は次のとおりです。

言い換えれば、ジョブが正常に停止した場合、つまり、収束しきい値lが予算Bを超えることなく満たされる場合、正のCの報酬がエージェントに割り当てられます。それ以外の場合、ジョブが失敗した場合、つまり、予算Bを使い果たす前に収束していません。報酬にはネガティブCが割り当てられます。 DRLでは、エージェントは累積割引報酬を学びます。

その中で、γ∈（0、1]は将来の割引報酬係数です。DRLトレーニングプロセス全体で、上記の式の目的関数がエージェントをガイドして最適な推定値を見つけます。

著者は、DRLエージェントによって制御されるミニバッチSGDアルゴリズムを実行するサーバーレスクラウド環境をシミュレートします。著者は、Openai Gymを使用して、シミュレートされた環境（https://gym.openai.com（https://gym.openai.com/））を実装しています。これは、強化学習アルゴリズムを評価するためのオープンソースインターフェイスです。実験の目的は、従来のグリッド検索ベースライン法で見つかった最適な（静的）戦略と比較して、スケジューリングにSirenを使用することの利点を検証することです。著者は、AWSラムダでサイレンを使用し、EC2クラスターでMXNETを使用する完了時間とコストを比較します。特定の実験では、3種類のEC2インスタンスがテストクラスターを構築するために選択されました：M4.large（2 VCPU、8GBメモリ）、M4.xlarge（4 VCPU、16GBメモリ）、およびM4.2XLARGE（8 VCPU、32GBメモリ）。

図13は、サイレンとグリッド検索の最適な関数の数の比較実験を示しています。図13（a）は、グリッド検索とサイレンによって達成されたトレーニング時間を比較しています。グリッド検索と比較して、サイレンは300ドルの予算でトレーニング時間を最大36％短縮します。図13（b）に示すように、グリッド検索には、異なる予算の下での異なる数の機能の合計報酬がリストされています。サイレンは、経験に基づいて機能の数を動的に調整できます。図13（c）は、各エポックに割り当てられた関数の数を示しています。最初のいくつかのエポックでは、サイレンは多数の機能を開始して、最後のいくつかのエポックで迅速に減少します。 SirenのDRLエージェントは、シミュレートされたサーバーレスクラウドとの反復的な相互作用を通じてオンラインでトレーニングします。図13（d）の学習曲線は、エージェントが異なる数の関数を調査することにより、総報酬を最大化することを学ぶことを示しています。エージェントのトレーニングは、約200回の反復後に完了します。

図13。サイレンとグリッド検索の最適な関数の数の比較。

図14。MXNETによるMNISTデータセットのトレーニングレネットとEC2。

図14のサイレンとEC2のMXNETの実験の比較。図14（a）は、12のEC2クラスターを使用してサイレンを使用してレネットをトレーニングするための完了時間と対応するコストを示しています。 EC2クラスターの不均一性により、EC2のコストはトレーニング完了時間と非線形です。たとえば、M4.xlarge×6クラスターとM4.2xlarge×6クラスターの完全なトレーニングをほぼ同時にトレーニングしますが、後者は前者の2倍のコストが発生します。対照的に、サイレンは完了時間を短縮し、より多くの投資を行います。図14（b）は、サイレンが各トレーニングエポックの関数とそれらの記憶を動的に調整することを示しています。関数の数が減少すると、各関数はより大きなトレーニングデータパーティションを受信し、データパーティションを処理するために大きなメモリが必要です。 SirenのDRLエージェントは、AWS Lambdaとのオンラインインタラクションを通じて訓練されています。図14（c）の学習曲線から、約150回の反復後、DRLエージェントのトレーニングが完了したことがわかります。

さらに、著者は、m4.2xlargeインスタンスのクラスターでレネット、CNNモデル、線形分類モデルを訓練し、対応するコストを決定します。次に、同じモデルが同じコストでM4.2xlarge×8クラスターでサイレンでトレーニングされます。図15の実験データは、Sirenがこれらのモデルをそれぞれ40％、39.4％、および44.3％で使用していることを示しています。

図15。異なるモデルの同じコスト予算でのサイレンとEC2の比較。

2.4サーバーレス代数[10]

この記事の著者は、サーバーレスプログラミングモデルに基づいたNumpywren：線形代数システムとLambDapack：高度に平行線形代数アルゴリズムのサーバーレス実行のために設計されたドメイン固有の言語を構築します。関連作業はSOCC'20に掲載されています。

サーバーレスコンピューティング（たとえば、AWS Lambda、Google Cloud Functions、Azure Functions）は、クラウドプロバイダーがリソース割り当てを動的に管理しながらサーバーを管理するプログラミングモデルです。通常、サーバーレスプラットフォームコンピューティングは、時間制限のないステートレスFAAS APIと、プログラムの状態を管理するオブジェクトストレージシステムを公開します。プログラムの状態とロジックを明確に分離できるアプリケーションデザイナーの場合、サーバーレスプラットフォームは、複雑なクラスターの展開のオーバーヘッドなしで、大規模なコンピューティングパワーへの即時アクセスを提供します。

この記事で研究されているコンテンツは、密な線形代数で既存のサーバー中心のデータセンターから非常に恩恵を受けています。既存の分散線形代数フレームワークは、局所性、ネットワークトポロジ、および単一のサーバー内のリソースの緊密な統合を活用することにより、高性能コンピューティングを実行できます。在这样的背景下作者提出这样一个问题：这些线性代数算法能否成功地移植到一个分散数据中心中？也就是说，我们能否在无服务器编程模型中实现与基于MPI 的分布式线性代数框架相当的性能？

本文作者构建了NumPyWren，一个在无服务器架构上完成线性代数任务的系统。NumPyWren 执行使用LAmbdaPACK 编写的程序，LAmbdaPACK 是作者构建的一个高级DSL，可以简洁地表示任意基于分片的线性代数算法。NumPyWren 通过无状态函数执行来执行大规模密集线性代数程序。通过对中间语言LAmbdaPACK 的分析，作者最终证明了分散式无服务器计算模型（Disaggregated serverless computing model）可以用于具有复杂通信程序的计算密集型程序。

NumPyWren 解决的是类似Cholesky 分解的线性代数问题。考虑求解线性方程Ax=b 的问题，其中a 是对称正定矩阵。我们可以先把a 分解成两个三角形矩阵a=LL^T，然后解两个相对简单的Ly=b 和L^T x=y 得到解x。从这个过程中可以看出，分解是该求解问题中计算代价最高的步骤。 Communication-Avoiding Cholesky 是一个很好的计算Cholesky 分解的算法。该算法将矩阵分成若干块，并得出一个计算顺序使总数据传输量最小。具体的なアルゴリズムは次のとおりです。

如图16，在outer loop(j)的每一步中，算法首先计算单个块Ajj 的Cholesky 分解(图16(a))。这个结果用来更新由Aij 下面的列块组成的"面板（panel）"（图16（b））。最后，第j 列右边的所有区块都会根据各自的位置，通过索引更新面板（图16(c)）。通过向下移动对角线重复这一过程（图16（d））。

图16. 并行Cholesky 分解的前4 个时间步骤：0）对角块Cholesky 分解，1）并行列更新，2）并行子矩阵更新，3）（后续）对角块Cholesky 分解。

作者针对Algorithm 1 提出了两点问题。首先，作者认为Algorithm 1 在执行过程中展现出了动态并行性。外循环（Outer loop）由三个不同的步骤组成，具有不同的并行度，从O(1)、O(K)到O(K2)，其中K 是每个步骤的封闭子矩阵大小。其次，该算法在这三个步骤之间存在细粒度的依赖关系，无论是在一个迭代内还是在多个迭代之间。由此，作者提出了本文所考虑的工作，即：实现适应可用的并行化，作者通过将程序分解为可并行运行的细粒度执行单元来实现这一点。为了在无状态环境中实现这一点，作者建议以分散的方式执行依赖性分析。将描述程序控制流的全局依赖图分发给每个worker。然后，每个worker 根据其在全局任务图中的当前位置，对其下游依赖关系进行本地推理。

首先，我们介绍本文提出的LAmbdaPACK：一种用于实现并行线性代数算法的特定语言。LAmbdaPACK 是生成和使用矩阵块（Tiled matrices）的命令式程序。这些程序可以对标量值执行基本的算术和逻辑运算。它们不能直接读取或写入矩阵值；相反，所有实质性的计算都是通过调用矩阵块上的本机内核来执行的。矩阵块由索引引用，LAmbdaPACK 程序的主要作用是对内核调用排序，并计算每个调用的分块索引。LAmbdaPACK 包括简单的for 循环和if 语句，但是没有递归，只有从LAmbdaPACK 到内核的一级函数调用。每个矩阵块索引只能写入一次，这是许多函数式语言的共同设计原则。LAmbdaPACK 中的原语功能强大，包括Tall Skinny QR（TSQR）、LU、Cholesky 和奇异值分解等等。LAmbdaPACK 的示例性描述如图17 所示。

图17. LAmbdaPACK 语言的示例性描述。

关于LAmbdaPACK 的算法分析主要包括两个阶段。由于原始未压缩的DAG 非常大，其节点数可能会随着Cholesky 或QR 等算法的输入大小呈立方级增长，因此，第一阶段的任务是分析程序并提取任务的压缩DAG。DAG 中的每个任务对应一个数组写入，我们还需提取执行此任务所需的内核计算和数组读取。由于每个数组读取都有一个唯一的上游写入任务，因此此过程是可跟踪处理的。第二个阶段发生在runtime，在执行任务之后，能够动态发现下游任务。使用当前循环变量绑定的信息来查询下游任务的压缩DAG。图18 和图19 分别给出了LAmbdaPACK 的DAG 和程序示例。

图18.LAmbdaPACK DAG 示例。

图19. LAmbdaPACK 程序示例。

LAmbdaPACK 中没有并行原语，而是LAmbdaPACK runtime 通过静态分析程序来推断底层依赖关系图。为了并行执行程序，作者从程序产生的依赖结构构造了一个内核调用的DAG。作者借用并扩展了循环优化技术（loop optimization），将LAmbdaPACK 程序转换为隐式有向无环图（Implicit DAG）。将程序DAG 中的每个节点N 表示为一个元组（line_number, loop_indices）。利用这个信息，可以执行程序迭代空间中的任何语句。

接下来，作者解决推导DAG 中特定节点的下游依赖关系问题。作者提出在runtime 处理依赖性分析：每当一个存储位置被写入时，确定从同一存储位置读取的N（所有行，所有循环索引）中的表达式。每当一个存储位置被写入时，我们确定从同一存储位置读取N（所有行，所有循环索引）中的表达式。作者将约束建模为一个方程组。假设单个线性代数算法中的行数必然很小，而程序迭代空间通常非常大。当数组仅由循环变量的仿射函数索引时，即形式为ai+b 的函数，其中i 是循环变量，a 和b 是编译时已知的常数，则可以使用循环优化来有效地查找特定节点的依赖关系。

如图19 中的程序示例，如果在runtime 一个worker 正在执行程序的第7 行，i=0、j=1 和k=1，以查找下游依赖项，则分析器将扫描这7 行中的每一行，并计算是否存在一组有效的循环索引，以便在程序中的该点读取S[1,1,1]。如果是这样，那么元组（line_number, loop_indices）定义了该任务的下游依赖项，并确定为当前任务的子任务。为了便于访问和开发，作者将LAmbdaPACK 嵌入Python 中。由于大多数LAmbdaPACK 调用优化的BLAS 和LAPACK 内核，因此使用高级解释语言的性能损失很小。LAmbdaPACK 详细流程见Algorithm2。

然后，我们介绍本文提出的NumPyWren 框架。NumPyWren 框架包括五个独立可扩展的主要组件：runtime 状态存储、任务队列、轻量级全局任务调度器、无服务器计算runtime 和分布式对象存储。图20 展示了NumPyWren 框架组件。

图20. NumPyWren 执行框架的体系结构，具体为6x6cholesky 分解期间的runtime 状态。

任务排队（Task Queue）：客户端进程将需要执行的第一个任务排队到任务队列中。任务队列是一个发布- 订阅样式的队列，它包含DAG 中的所有节点，这些节点的输入依赖关系都已满足并准备好执行。

执行器配置（Executor Provisioning）：任务队列的长度由配置者（Provisioner）监控，provisioner 管理计算资源以匹配执行期间的动态并行性。在第一个任务排队后，provisioner 启动一个执行器（executor），并根据任务队列大小维护活动executor 的数量。由于provisioner 的角色只是轻量级的，所以它也可以作为“无服务器” 云函数定期执行。

任务执行（Task Execution）：执行器管理NumPyWren 任务的执行和调度。一旦执行器准备就绪，它就轮询任务队列以获取可用的任务，并执行任务中的编码指令。大多数任务涉及从对象存储读取输入和将输出写入对象存储，以及执行BLAS/LAPACK 函数等。假定对象存储是一个分布式持久存储系统，它支持单个密钥的先读后写一致性。使用一个带有单一静态赋值语言的持久对象存储，有助于设计容错协议。当执行器接近无服务器系统的runtime 限制时（AWS Lambda 为900），执行器自动终止。如果有必要的话，provisioner 将负责雇佣新worker。容错协议能够实现即使工作进程超过runtime 限制或是在执行过程中被云提供商杀死，程序仍能在有效状态下运行。

Runtime 状态更新（Runtime state update）：一旦任务执行完成并且输出被持久化，执行器就会更新runtime 状态存储中的任务状态。runtime 状态存储跟踪整个执行的控制状态，并且需要支持每个任务的快速更新。如果已完成的任务具有“ready” 子任务，则执行器会将该子任务添加到任务队列中。状态存储的原子性保证了每个子任务都能够被调度。这个使用执行器执行调度的过程实现了高效、分散、细粒度的任务调度。由于计算和存储的分离，NumPyWren 中的容错非常容易实现。因为对对象存储的所有写入都是持久的，所以在任务完成后都不需要重新计算。

任务租用（Task Lease）：在NumPyWren 中，所有挂起的和可执行的任务都存储在一个任务队列中。保持一个不变量，即任务只有在完成后才能从队列中删除（例如，runtime 状态存储已更新，输出持久化到对象存储）。当一个worker 获取一条任务，这个worker 就获得了该任务的租约（lease）。在租用期间，该任务被标记为不可见，以防止其他workers 获取这条任务。

故障检测和恢复（Failure Detection and Recovery）：在正常操作期间，worker 将使用后台线程续订任务租约，直到任务完成。如果任务完成，worker 将从队列中删除该任务。如果worker 失败，它将无法再续订租约，并且该任务将对任何可用的worker 可见。因此，故障检测在租约到期时发生，恢复时间由租约长度决定。

垃圾收集（Garbage collection）：由于NumPyWren 将所有中间状态存储到一个持久对象存储区，因此在不再需要时清除状态是非常必要的。但是，由于在对象存储中存储字节的成本极低，与处理TB 级中间状态问题的计算成本相比，在程序结束时进行垃圾收集就足够了。使用与程序相关联的唯一id 标记对象存储中单个程序执行的所有分配。在程序执行终止后，NumPyWren 通过启动一组并行的无服务器任务来异步清理对象存储，以清理与给定程序id 关联的所有对象。

自动缩放（Autoscaling）：与传统的无服务器计算模型（每个新任务分配一个新容器）不同，NumPyWren 中的任务调度和worker 管理是解耦的。这种解耦允许自动扩展计算资源，以实现更好的性价比权衡。在NumPyWren 中，作者采用了一个简单的自动缩放启发式算法，能够在保持较低作业完成时间的同时获得很好的利用率。

作者对4 种线性代数算法：矩阵乘（Matrix Multiply，GEMM）、QR 分解（QR Decomposition，QR）、奇异值分解（SingularValue Decomposition，SVD）、Cholesky 分解（Cholesky Decomposition，Cholesky）进行了实验评价。对于这四种算法，作者将它们与最先进的MPI 实现进行比较。其中Cholesky，GEMM 和SVDwe 使用ScaLAPACK 实现，ScaLAPACK 是一个工业级Fortran 库，专为高性能、分布式密集线性代数而设计。对于QR 分解，则使用了communication-avoiding QR 分解算法的优化实现。NumPyWren 实现大约有6000 行Python 代码，作者将其构建在Amazon web 服务（AWS）平台上。对于runtime 状态存储，使用的是Redis--- 一个由ElasticCache 提供的键值存储。尽管ElasticCache 是一种配置的（而不是“无服务器”）服务，但作者发现使用一个实例就足以满足所有工作负载。此外，作者还发现，可以用托管供应商提供的键值存储（如DynamoDB）来替换Redis，但性能略有下降。作者将Amazon 的简单队列服务（Simple queue Service，SQS）用于任务队列，Lambda 或EC2，使用Amazon S3 作为远程对象存储。

作者对实验进行了一些特殊的设备选择、环境选择或参数选择。首先，由于不能很容易地控制并发Lambda 执行的数量或AWS 提供的硬件类型，出于实验控制的原因，作者通过模仿EC2 上的无服务器runtime 来进行大部分评估以便与其他系统进行比较。其次，本文的Lambda 模拟基于PyWren 框架中的“独立模式”。PyWren 使用一个单独的SQS 队列来模拟Lambda 作业队列，并使用有时间限制的进程来模拟短函数调用。在控制底层硬件（AVX、NIC 等）时，使用SQS 会导致不确定性。然后，目前Lambda 的定价是EC2 现货价格的10 倍，这使得本文的大规模实验无法在Lambda 上进行。作者通过实验对比发现，在EC2 上运行模拟的无服务器环境与在AWS Lambda 上运行的性能差别最小。最后，模拟环境中的实验还允许修改某些在真实无服务器环境中用户无法控制的系统参数，如函数超时等。

表3 中给出针对四种密集线性代数方法NumPyWren 与MPI 的端到端性能比较。作者对比了在完全相同的硬件条件下（8 个r4.16xlarge 实例中的256 个物理核），处理大小为256k（262144）的方阵时MPI 和NumPyWren 的性能。我们可以看到无服务器环境施加的限制导致的性能损失在1.4x 到1.6x 之间（按wall-clock time 计算）。

表3. 在具有512 个虚拟核的集群上，在N=256K 的方阵上运行时，不同算法的MPI 与NumPyWren 执行时间的比较。

在表4 中，作者比较了NumPyWren 和MPI 使用的总核秒数（core-seconds）。对于MPI，core seconds 是指核的总数乘以wall-clock runtime。对于NumPyWren，作者只计算“活动核（Active cores）”，因为空闲核是可以被其他任务利用的。作者通过在无服务器核启动和冷却计算过程中每个核的总计算时间中添加一个启动延时γ来计算总核秒数。具体的，作者选择γ=20s 以对系统进行保守的评估。对于QR 和Cholesky 这些具有可变并行性的算法，虽然wall-clock time 相当，但作者发现NumPyWren 使用的核秒数减少了1.15 倍。对于SVD，实验中显示出超过3 倍的资源节省效果，不过，产生这种差异一部分是由于使用的SVD 算法不同。然而对于具有固定数量的并行性的算法（如GEMM），NumPyWren 中过多的通信会导致更高的资源消耗。

表4. 在一个256K 大小的方阵上运行算法的MPI 与NumPyWren 总CPU 时间（以核秒为单位）比较。

三、文章小结

本文重点关注了基于无服务器计算的机器学习的最新研究进展。随着云计算的不断发展，开发人员对于按需执行或扩展的需求越来越强烈，越来越希望不去应对服务器或其它底层基础设施，而是集中精力关注于自身应用的开发和调优。无服务器计算的FaaS 和BaaS 服务必将迎来更多的关注。但是，正如我们开篇提到的，机器学习的算法或模型中包含大量的参数、复杂的处理流程，是典型的“性能关键型应用”。针对机器学习这种要求复杂通信模式和工作负载的应用如何基于无服务器计算去工作仍然是一个有待研究的问题。

本文关注了三个研究小组的四篇研究论文。其中前两篇文章提出了一种无服务器基础设施和ML 工作流的无服务器ML 框架原型，并将其封装为一个实现端到端管理的分布式ML 训练框架Cirrus，可以直接调用使用。第三篇文章提出了一个基于无服务器架构的分布式机器学习新框架，以及一种深度强化学习技术，用于实现SIREN 中的动态资源供应。作者还提出了一种能够在无服务器架构中高效工作的HSP 计算模式。最后一篇文章重点关注的是无服务器计算的模密集线性代数程序应用，作者提出了一个在无服务器架构上完成线性代数任务的系统NumPyWren，通过对中间语言LAmbdaPACK 的分析，作者最终证明了该分散式无服务器计算模型NumPyWren 可以用于具有复杂通信程序的计算密集型程序。

在几篇文章中，作者都通过实验证明了几种框架在执行机器学习任务时性能远优于经典的基于粗粒度的VM 集群的ML 框架。尽管无服务器的机器学习具有敏捷、快速、可伸缩性等优点，但是它对机器学习的集成还处于初级阶段，它自身也面临着工具不全面、不成熟或者配置方式不统一等问题。随着越来越多的研究人员关注，越来越多的应用开发提出成本节约和效率提高的需要，无服务器计算将迎来更快更好的发展。