Amazon Web Services ブログ
Amazon Elastic Inference を使ったモデルサービング
Amazon Elastic Inference (EI) は、Amazon EC2 および Amazon SageMaker インスタンスに低コストの GPU アクセラレーションをアタッチできるようにするサービスです。EI は深層学習推論の実行コストを最大 75% 削減します。Model Server for Apache MXNet (MMS) は、大規模な推論のための MXNet および ONNX ベースのモデルのデプロイメントを可能にします。このブログ記事では、Elastic Inference Accelerator (EIA) がアタッチされた汎用 EC2 インスタンスで実行される MMS の使用について掘り下げていきます。
Model Server for Apache MXNet (MMS) とは?
MMS はオープンソースのモデルサービングフレームワークで、大規模な推論のための深層学習モデルをサーブするタスクをシンプル化するように設計されています。MMS は、Apache MXNet を使用して深層学習モデルを訓練した後、本番環境で大規模な推論のために訓練済みモデルをデプロイすることを容易にします。以下のアーキテクチャ図は、標準的な MMS のスケーラブルアーキテクチャを示しています。
Amazon Elastic Inference とは?
深層学習アプリケーションでは、推論がアプリケーションのコンピューティングコストの約 90 パーセントを占めています。推論は GPU コンピューティングリソースを少ししか消費しないリアルタイムの単一入力で行われるため、高速化された GPU インスタンスのサイズは推論のために大きめ設定されます。GPU のコンピューティングキャパシティの使用率はピークロード時でも 100 パーセントではない場合があるため、無駄が多く、コストも高くなります。
EI は、適切な量の GPU による推論アクセラレーションを EC2 または Amazon SageMaker のインスタンスにアタッチして、最大 75 パーセント節約することを可能にします。EI を使用することによって、アプリケーションの全体的な CPU ニーズとメモリニーズに最適なインスタンスタイプを選択することができるようになり、その後、リソースを効率的に使用し、コストを削減するために必要な量の推論アクセラレーションを別途に設定できます。
EC2 での Amazon Elastic Inference のセットアップ
EI アクセラレーターがアタッチされた EC2 インスタンスの開始には、AWS アカウントをセットアップするための設定前ステップがいくつか必要になります。その後、Elastic Inference ドキュメントにある手順に従って、アクセラレーターがアタッチされたインスタンスを起動できます。今回はシンプルな Ubuntu Amazon Machine Image (AMI) を使用し、それをニーズに応じて設定します。
Elastic Inference を使った ResNet-152 モデルのサーブ
EI アクセラレーターがアタッチされた EC2 インスタンスを起動したら、MMS と EI 対応バージョンの MXNet をインストールします。
次に、すでに EI 用に設定された ResNet-152 のモデルアーカイブを使って MMS を開始します。EIA をサポートする独自のモデルアーカイブを構築するには、Custom Service および Model Serving with Elastic Inference ドキュメントを参照してください。ここでは、ワーカーの数を 1 に設定し、ワーカーの同時作成を使用するために、curl コマンドを使って MMS を設定します。
前述の curl コマンドで、min_worker=1 として MMS を設定したことに注目してください。これは、EI アクセラレーターに対する推論コールが順次的であることから複数のワーカーを使用してもメリットがあまりないため、EI 上の MMS にとって重要な設定です。これで推論リクエストに対するモデルの準備が整いました。子猫の画像を分類するために、以下のコマンドを実行します。
これによって、以下の予測結果が得られます。
ResNet-152 が MMS でホストされる Elastic Inference を使ってトラ猫を識別したことがわかります。
Elastic Inference を使ってサーブすることのコストとパフォーマンス面でのメリット
モデルサービングでは、スループット (1 秒あたりの推論数) とレイテンシー (各推論の時間) の観点からパフォーマンスが測定されます。CPU または GPU インスタンス については、単一のワーカーで最良のレイテンシーを達成できますが、より良いスループットは各 vCPU または GPU ごとにひとつのワーカーを使用することによって達成されます。今回は m5.large インスタンスから始めて、スループットとレイテンシーの両方が最適化された設定を評価し、毎秒 4.5 件のリクエストと、244 ミリ秒のレイテンシーを達成しました。100,000 リクエストに対するこの設定のコスト効率性は 0.59 USD です。これを p3.2xlarge でのスループット 41.42、レイテンシー 23 ミリ秒、および 2.05 UDS のコスト効率性と比較します。これは、本番ユースケースには高額すぎるかもしれません。それでは、Amazon Elastic Inference がどのように役立つかを見てみましょう。
EI アクセラレーターは、現在 eia1.medium、eia1.large、および eia1.xlarge の 3 サイズで利用でき、それぞれに 1~4 GB のメモリと、8~32 TFLOPS のコンピューティング能力があります。
このモデルのパフォーマンスを eia1.medium アクセラレーターで評価したところ、大きいインスタンスサイズがレイテンシーパフォーマンスを大幅に向上させないことがわかりました。次に、異なるサイズの EI アクセラレーターで m5.large をテストしました。eia1.large アクセラレーターを使った推論コールでは、レイテンシーが eia1.medium よりも低くなりましたが、コスト効率面では変わりありませんでした。eia1.medium は ResNet-152 モデルのユースケースにパフォーマンスとコストの良好なバランスを提供することから、今回はこれを使用します。
スループットのために最適化する場合、m5.large + eia1.medium のインスタンスは通常の p3.2xlarge よりも速度が 46 パーセント速く、コスト効率性は 84 パーセント良くなりました。また、c5.xlarge よりもコスト効率性が 30 パーセント良く、1.9 倍のスループットも実現しました。m5.large + eia1.medium は m5.large だけの場合よりも 4.2 倍のスループットを提供し、コスト効率性は 45 パーセント良くなりました。以下の図は、最大スループットのために最適化した場合の結果を示したものです。
レイテンシーのために最適化する場合、m5.large + eia1.medium のインスタンスは c5.xlarge インスタンスよりもコスト効率性が 43 パーセント良く、レイテンシーは 2.4 倍低くなりました。m5.large だけの場合と比較すると、eia1.medium を追加することによってコスト効率性が 44 パーセント向上し、レイテンシーも 4.4 倍向上します。p3.2xlarge インスタンスでは、m5.large + eia1.medium と比べてレイテンシーは 2.3 倍低くなりましたが、コストは 5.6 倍増しでした。以下の図は、最小レイテンシーのために最適化した場合の結果を示したものです。
結論
以上をまとめると、このブログ記事では Elastic Inference がレイテンシーとスループットのための最適化を行いながら、大規模な推論の実行に最高のコスト効率性を提供することを実証しました。
MMS について詳しく学び、貢献してください
Elastic Inference の使用は、MMS でモデルをホストする数多くの可能性のひとつに過ぎません。MMS について詳しく学ぶには、リポジトリの model zoo と documentation フォルダにある例とドキュメントから始めてください。
MMS の改善を継続していくにあたって、私たちは質問、リクエスト、および貢献を含めたコミュニティーの参加をお待ちしています。すでに MMS をお使いの場合は、リポジトリの GitHub issues から、ぜひフィードバックをお寄せください。それでは、awslabs/mxnet-model-server にアクセスして始めましょう!
付録
以下の表は、今回使用した特定の構成設定と、この記事に記載した未処理の結果を示しています。
表 1: ResNet-152 のパフォーマンスとコストの未処理結果
インスタンスタイプ | 最適化の対象 | ワーカーの数 * | OMP スレッドの数 ** | 1 時間あたりのコスト | コスト効率性 | レイテンシー (ミリ秒) | スループット (リクエスト数/秒) |
m5.large | スループット | 2 | 1 | 0.10 USD | 0.59 USD | 444 | 4.50 |
m5.large | レイテンシー | 1 | 1 | 0.10 USD | 0.65 USD | 244 | 4.08 |
m5.large + eia.medium | 両方 | 1 | 1 | 0.23 USD
|
0.33 USD | 52 | 19.08 |
c5.xlarge | スループット | 4 | 1 | 0.17 USD | 0.47 USD | 400 | 9.95 |
c5.xlarge | レイテンシー | 1 | 4 | 0.17 USD | 0.64 USD | 134 | 7.38 |
p3.2xlarge | 両方 | 1 | N/A | 3.06 USD | 2.05 USD | 23 | 41.42 |
* このモデルのワーカーの数 – これは MMS の management API で調整できます。
** ワーカーごとの OMP_NUM_THREADS – これは、ワーカーごとの OpenMP スレッドの数を示しています。
通常、MMS は vCPU の数 (CPU インスタンスの場合) または GPU の数 (GPU インスタンスの場合) に合わせてワーカーの数を自動的にスケールしますが、複数のワーカーを使用する EI は追加のスループットを提供せず、推論レイテンシーを大幅に低減することがわかりました。このため、EI で最高のパフォーマンスを得るために単一のワーカーを使用していますが、CPU または GPU のインスタンスについては、ワーカーの数をより大きな値に設定することによって、より良いスループットが達成されます。
環境変数 OMP_NUM_THREADS を設定することで CPU インスタンスでレイテンシーまたはスループットのための最適化を行うには、追加の構成設定が必要であることに留意してください。MMS は、スループットのための最適化を行うために、自動でこの変数をデフォルトの 1 に設定しますが、c5.xlarge にはこれを 4 に設定してレイテンシーのための最適化を行いました。ただし、結果は選択するインスタンス、または最適化戦略に応じて異なる場合があります。
著者について
Rakesh Vasudevan は、AWS 深層学習のソフトウェア開発エンジニアで、スケーラブルな深層学習システムの構築に情熱を傾けています。Rakesh はそのかたわらで、ゲーム、クリケット、そして家族と友人との時間を楽しんでいます。
Denis Davydenko は AWS 深層学習のエンジニアリングマネージャーです。Denis は、開発者と科学者がインテリジェントなアプリケーションを構築することを可能にする、深層学習ツールの構築に焦点を当てています。余暇には、ポーカー、ビデオゲーム、家族との時間を楽しんでいます。
Sam Skalicky は、高機能の異種コンピューティングシステムの構築を楽しむ AWS 深層学習のソフトウェアエンジニアです。Sam は熱烈なコーヒー愛好家ですが、ハイキングだけは何としてでも行きたくありません。