Amazon Elastic Inference で PyTorch モデル向け Amazon EC2 の推論コストを削減する

Amazon Elastic Inference を使用して、Amazon SageMaker と Amazon EC2 の両方で PyTorch モデルの推論を加速し、推論コストを削減できるようになりました。

PyTorch は、動的なコンピューティンググラフを使用する一般的なディープラーニングフレームワークです。これにより、命令的で慣用的な Python コードを使用してディープラーニングモデルを簡単に開発できます。推論は、トレーニングされたモデルを使用して予測を行うプロセスです。PyTorch などのフレームワークを使用するディープラーニングアプリケーションの場合、推論は計算コストの最大 90% を占めます。ディープラーニングモデルはさまざまな量の GPU、CPU、およびメモリリソースを必要とするため、推論に適切なインスタンスを選択することは困難です。通常、スタンドアロン GPU インスタンスでこれらのリソースの 1 つを最適化すると、他のリソースが十分に活用されなくなります。したがって、未使用のリソースに対して料金を支払うことになる可能性があります。

Elastic Inference は、Amazon SageMaker インスタンスタイプや EC2 インスタンスタイプ、または Amazon ECS タスクに適切な量の GPU による推論アクセラレーションをアタッチできるようにすることで、この問題を解決します。アプリケーションの全体的なコンピューティングとメモリのニーズに最適な AWS の CPU インスタンスを選択し、アプリケーションのレイテンシー要件を満たすために適切な量の GPU による推論アクセラレーションを個別にアタッチできます。これにより、リソースをより効率的に使用し、推論コストを削減できます。PyTorch が、Elastic Inference でサポートされるディープラーニングフレームワークとして TensorFlow と Apache MXNet に加わります。この記事の執筆時点でリリースされているバージョンは 1.3.1 です。

この記事では、Amazon EC2 インスタンスと Elastic Inference を使用して、PyTorch モデルのコストを削減し、レイテンシーを改善する方法を示します。代わりに Amazon SageMaker を使用してコストを削減する方法については、Amazon Elastic Inference を使用して Amazon SageMaker で PyTorch モデルの機械翻訳推論コストを削減するを参照してください。

TorchScript: 研究と生産のギャップを埋める

次に、PyTorch コードからシリアル化および最適化可能なモデルを作成する方法である TorchScript について説明します。PyTorch で Elastic Inference を使用するには、モデルを TorchScript に変換する必要があります。

PyTorch の動的コンピューティンググラフを使用することで、モデル開発プロセスが大幅に簡素化されます。ただし、このパラダイムは、本番モデルのデプロイに固有の課題を突き付けます。本番環境では、モデルの静的なグラフ表現が有益です。これにより、Python のない環境でモデルを使用できるだけでなく、パフォーマンスの向上とメモリの最適化も可能になります。

TorchScript は、モデルをコンパイルして Python フリーのグラフベースの表現にエクスポートする機能を提供することにより、このギャップを埋めます。PyTorch モデルを TorchScript に変換することにより、あらゆる本番環境でモデルを実行できます。TorchScript は、ジャストインタイムのグラフレベルの最適化も行い、標準的な PyTorch よりもパフォーマンスを向上させます。

Elastic Inference を PyTorch で使用するには、モデルを TorchScript 形式に変換し、Elastic Inference 用の推論 API を使用する必要があります。この記事では、モデルを TorchScript にコンパイルし、Elastic Inference 対応の PyTorch を使用してエンドツーエンドの推論レイテンシーをベンチマークする方法を例示します。記事の後半では、さまざまなインスタンスとアクセラレータの組み合わせのパフォーマンスとコストメトリクスをスタンドアロンの CPU および GPU インスタンスと比較します。

TorchScript を使用したモデルのコンパイルとシリアル化

tracing または scripting を使用して、PyTorch モデルを TorchScript にコンパイルできます。どちらもコンピューティンググラフを作成しますが、作成方法が異なります。

通常、モデルのスクリプトは、すべてのモデルロジックを保持するため、TorchScript にコンパイルする好ましい方法です。ただし、この記事の執筆時点では、PyTorch 1.3.1 を使用したスクリプト可能なモデルのセットは、トレース可能なモデルのセットよりも小さくなっています。モデルはトレースできるけれどもスクリプト化できないか、まったくトレース不可能である可能性があります。モデルコードを修正して TorchScript との互換性を確保する必要があることもあります。

Elastic Inference が現在 PyTorch 1.3.1 の制御フロー操作を処理する方法のため、多くの条件分岐を含むスクリプトモデルにとって推論のレイテンシーが最適化されていない可能性があります。モデルが Elastic Inference でどのようなパフォーマンスを発揮するかを確認するには、トレースとスクリプトの両方を試してください。1.3.1 のリリースでは、トレースモデルの方がスクリプトバージョンよりもパフォーマンスが高い可能性があります。

詳細については、PyTorch ウェブサイトの「TorchScript のご紹介」のチュートリアルをご覧ください。

スクリプト

スクリプトはソースコードの直接分析を実行して、コンピューティンググラフを構築し、制御フローを保持します。次のコード例では、スクリプトを使用してモデルをコンパイルする方法を示しています。ResNet-18 には TorchVision の事前トレーニング済みの重みを使用します。結果のスクリプトモデルをファイルに保存してから、Elastic Inference 対応の PyTorch を使用して torch.jit.load で読み込むことができます。次のコードを参照してください。

import torchvision, torch

# Call eval() to set model to inference mode
model = torchvision.models.resnet18(pretrained=True).eval()
scripted_model = torch.jit.script(model)

トレース

トレースでは、サンプル入力を使用して、その入力でモデルを実行したときの操作のパフォーマンスを記録します。つまり、単一の入力でコードをトレースしてグラフをコンパイルしているため、制御フローが消去される可能性があります。たとえば、モデル定義には、特定のサイズ x の画像をパディングするコードが含まれる場合があります 異なるサイズ y のイメージでモデルをトレースする場合、トレースされるモデルに供給されるサイズ x の入力は将来パディングされません。これは、特定の入力でトレース中にすべてのコードパスが実行されたわけではないために発生します。

次の例は、ランダム化されたテンソル入力でトレースすることでモデルをコンパイルする方法を示しています。また、ResNet-18 向けに TorchVision の事前トレーニング済みの重みを使用します。Elastic Inference でトレースされたモデルを使用するには、デバイス順序の 2 番目のパラメータで torch.jit.optimized_execution コンテキストブロックを使用する必要があります。この変更された関数定義は 2 つのパラメータを受け入れ、Elastic Inference 対応の PyTorch フレームワークを介してのみ使用できます。

標準の PyTorch フレームワークを使用してモデルをトレースする場合、torch.jit.optimized_execution ブロックを省略します。それでも結果のトレースされたモデルをファイルに保存し、Elastic Inference 対応の PyTorch を使用して torch.jit.load で読み込むことができます。次のコードを参照してください。

# ImageNet pre-trained models take inputs of this size.
x = torch.rand(1,3,224,224)
# Call eval() to set model to inference mode
model = torchvision.models.resnet18(pretrained=True).eval()

# Required when using Elastic Inference
with torch.jit.optimized_execution(True, {‘target_device’: ‘eia:0’}):
    traced_model = torch.jit.trace(model, x)

コンパイル済みモデルの保存と読み込み

トレースとスクリプトの出力は ScriptModule です。これは、標準 PyTorch の nn.Module における TorchScript の類似物です。TorchScript モジュールのシリアル化と逆シリアル化は、それぞれ torch.jit.save() と torch.jit.load() を呼び出すのと同じくらい簡単です。これは、torch.save() と torch.load() を使用して標準 PyTorch モデルを保存およびロードする JIT の類似物です。次のコードを参照してください。

torch.jit.save(traced_model, 'resnet18_traced.pt')
torch.jit.save(scripted_model, 'resnet18_scripted.pt')

traced_model = torch.jit.load('resnet18_traced.pt')
scripted_model = torch.jit.load('resnet18_scripted.pt')

保存された標準の PyTorch モデルとは異なり、保存された TorchScript モデルは特定のクラスおよびコードディレクトリにバインドされていません。最初にモデルクラスをインスタンス化せずに、保存された TorchScript モデルを直接読み込むことができます。これにより、Python のない環境で TorchScript モデルを使用できます。

Elastic Inference 対応の PyTorch を使用したエンドツーエンドの推論ベンチマーク

この記事では、Amazon EC2 の OpenAI 生成事前トレーニング (GPT) モデルの Elastic Inference 対応 PyTorch 推論レイテンシーをベンチマークするプロセスについて説明します。GPT は、複数の言語タスクで最先端の結果を達成した、教師無しトランスフォーマーのモデルです。

前提条件

チュートリアルを完了するには、最初に次の前提条件を満たす必要があります。

• ポート 22 および 443 へのすべての受信トラフィックを許可し、すべての送信トラフィックを許可する VPC セキュリティグループを設定します。詳細については、Elastic Inference のセキュリティグループの設定を参照してください。
• Elastic Inference VPC サービスを使用して VPC エンドポイントを作成します。詳細については、AWS PrivateLink エンドポイントサービスの設定を参照してください。
  • エンドポイントを作成する VPC をメモします。後で同じ VPC を使用してインスタンスを作成します。
  • Elastic Inference を使用するすべてのアベイラビリティーゾーンを選択します。
• Elastic Inference を使用する権限を持つ IAM ロールを作成します。詳細については、Elastic Inference ポリシー使用したインスタンスロールの設定を参照してください。
• m5.large CPU インスタンスを起動し、1 つの eia2.xlarge アクセラレータを接続します。
  • Linux または Ubuntu Deep Learning AMI (DLAMI) v27 を使用します。
  • 以前に設定した VPC とセキュリティグループを使用します。

この記事では、DLAMI から組み込みの Conda 環境を使用します。ただし、Elastic Inference でサポートされている他のすべてのフレームワークと同様に、Elastic Inference 対応の PyTorch を他の方法で使用することができます。Docker コンテナオプションは、AWS DL コンテナを通じて利用できます。DLAMI を使用していない場合は、Amazon S3 バケットから Elastic Inference PyTorch ピップホイールを使用して環境を構築することもできます。

チュートリアル

次の手順を実行します。

1. 作成したインスタンスにログインします。
2. 組み込みの EI ツールを使用して、接続されているすべての Elastic Inference アクセラレータデバイスの序数を取得します。次のコマンドをご参照ください。

   /opt/amazon/ei/ei_tools/bin/ei describe-accelerators --json

   EI ツールの詳細については、Elastic Inference アクセラレータのモニタリングを参照してください。

   次のコードのような出力が表示されるはずです。

   {
     "ei_client_version": "1.6.2",
     "time": "Fri Mar 6 03:09:38 2019",
     "attached_accelerators": 1,
     "devices": [
       {
         "ordinal": 0,
         "type": "eia2.xlarge",
         "id": "eia-56e1f73d4ab54b9e9389b0e535c905ec",
         "status": "healthy"
       }
     ]
   }

   クライアントインスタンスに複数のアクセラレータを接続している場合、このコマンドは序数 0 から始まる複数のデバイスを返します。推論を実行するには、目的の Elastic Inference アクセラレータのデバイス序数を使用します。

3. 次のコマンドを使用して、Elastic Inference 対応の PyTorch Conda 環境をアクティブ化します。

   source activate amazonei_pytorch_p36

4. 次のコマンドを使用して、トランスフォーマーライブラリ (OpenAI-GPT 事前トレーニング済みの重みをフェッチするために使用) をインストールします。

   pip install transformers==2.3.0

5. 次の内容で、openai_gpt_ei_benchark.py というスクリプトを作成します。このスクリプトは、一般的な教師なしの事前トレーニング済み言語モデルである GPT 事前トレーニング済みの重みを使用します。スクリプトはモデルを読み込み、トークン化されたテキストでトレースして TorchScript に変換し、コンパイルされたモデルをディスクに保存します。次に、モデルを読み込み、1,000 回の推論を実行して、レイテンシーの分布を報告します。次のコードを参照してください。

   import numpy as np
   import os
   import time
   import torch
   
   # トランスフォーマーパッケージをピップインストールしてください
   def nlp_input(tokenizer):
     tokenizer = torch.hub.load('huggingface/pytorch-transformers', 'tokenizer', tokenizer)
     sample_text = 'PyTorch is a Deep Learning Framework'
     indexed_tokens = tokenizer.encode(sample_text)
     return torch.tensor([indexed_tokens])
   
   token = nlp_input('openai-gpt')
   
   if not os.path.exists('openai_gpt_traced.pt'):
     # eval() は推論モードを切り替えます
     model = torch.hub.load('huggingface/pytorch-transformers', 'model', 'openai-gpt').eval()
   
     print('Compiling model ...')
     # トレースによってモデルを TorchScript にコンパイルします
     # ここでは、最初のアクセラレータを使用するため、序数 0 を使用します。
     with torch.jit.optimized_execution(True, {'target_device': 'eia:0'}):
       # 任意の入力でトレースできます
       model = torch.jit.trace(model, token)
   
     # モデルをシリアル化します
     torch.jit.save(model, 'openai_gpt_traced.pt')
   
   print('Loading model ...')
   model = torch.jit.load('openai_gpt_traced.pt')
   
   # 推論を 1,000 回実行します。必ず autograd を無効にし、EI 実行コンテキストを使用してください
   latencies = []
   for i in range(1000):
     with torch.no_grad():
       with torch.jit.optimized_execution(True, {'target_device': 'eia:0'}):
         start = time.time()
         _ = model(token)
         end = time.time()
         latencies.append((end - start) * 1000)
   
   # サービスのセットアップによってオーバーヘッドが発生したため、最初の推論が長くなります。
   # 最初の推論を破棄して、他のすべての推論レイテンシーを調べます
   latencies = np.array(latencies[1:])
   print('Mean latency (ms): {:.4f}'.format(np.mean(latencies)))
   print('P50 latency (ms): {:.4f}'.format(np.percentile(latencies, 50)))
   print('P90 latency (ms): {:.4f}'.format(np.percentile(latencies, 90)))
   print('P95 latency (ms): {:.4f}'.format(np.percentile(latencies, 95)))
   

   モデルを保存して読み込む必要はありません。モデルをコンパイルして、直接、推論を実行できます。モデルを保存することにより、将来の推論ジョブにかかる時間を節約できます。

   torch.jit.optimized_execution コードブロックを使用することを忘れないでください。これは Elastic Inference 対応の PyTorch 固有の推論 API であり、接続されたアクセラレータで推論をトリガーするために使用する必要があります。この実行コンテキストを正しく使用できない場合、推論はクライアントインスタンスで完全に実行されるため、アクセラレータを利用できません。

   Elastic Inference 対応の PyTorch フレームワークはこの文脈で 2 つのパラメータを受け入れますが、標準の PyTorch フレームワークは 1 つのパラメータのみを受け入れます。2 番目のパラメータは、アクセラレータデバイスの序数を指定します。target_device には、ID ではなくデバイスの序数を設定する必要があります。序数には 0 から始まる番号が付けられます。

6. 最初に接続されたアクセラレータを使用するようにデバイスの序数を設定します。次のスクリプトを参照してください。

   python openai_gpt_ei_benchmark.py

   以下のような出力を確認できるはずです:

   Amazon Elastic Inference クライアントライブラリバージョン: 1.6.2 の使用
   利用可能な伸縮自在推論アクセラレータの数: 1
   Elastic Inference アクセラレータ ID: eia-56e1f73d4ab54b9e9389b0e535c905ec
   Elastic Inference アクセラレータのタイプ: eia2.xlarge
   Elastic Inference アクセラレータの序数: 0
   
   平均レイテンシー (ミリ秒): 10.2795
   P50 レイテンシー (ミリ秒): 9.76729
   P90 レイテンシー (ミリ秒): 10.7727
   P95 レイテンシー (ミリ秒): 13.0613

適切なインスタンスを選択する

新しい推論ワークロードをデプロイするとき、多くのインスタンスタイプから選択できます。その際は以下の重要なパラメータを考慮に入れてください。

• メモリ – アプリケーションに十分な CPU とアクセラレータメモリを提供するクライアントインスタンスとアクセラレータの組み合わせを選択する必要があります。ランタイムメモリ要件の下限を入力テンソルサイズとモデルサイズの合計値に設定できます。ただし、実行時のメモリ使用量は通常、どのモデルでもこの下限を大幅に上回り、フレームワークにも左右されます。このガイドラインは、CPU インスタンスと Elastic Inference アクセラレータを選択する際の大まかなガイダンスとしてのみご使用ください。
• レイテンシー要件 – 十分なメモリを備えたクライアントインスタンスとアクセラレータのセットを作成したら、アプリケーションのレイテンシー要件を満たす選択肢にさらに絞り込むことができます。この記事では、パフォーマンスを評価するための重要な指標として、推論ごとのレイテンシーを考慮しています。単位時間あたりに処理される画像または単語の推論スループットは、一般的に使用される別のメトリクスです。
• コスト – メモリ要件とレイテンシー要件の両方を満たす一連のハードウェアの組み合わせができたら、推論ごとに最低料金を実現する組み合わせを選択することで、コスト効率を最適化できます。このメトリクスは、(料金 / 秒 * 推論の呼び出しごとの平均レイテンシー) として計算できます。数値をより具体的にするために、この記事では 100,000 推論あたりのコストを示しています。ワークロードのコスト効率を比較し、ハードウェアの組み合わせごとに計算することで、最適なハードウェアを選択できます。この記事では、米国西部 (オレゴン) リージョンの 1 時間あたりの料金を使用しています。

これで、このプロセスを適用して、GPT を実行するための最適なインスタンスを選択する準備ができました。まず、アプリケーションのメモリと CPU の要件を評価し、それらの要件を満たすクライアントインスタンスとアクセラレータのサブセットの候補リストを作成します。

次に、レイテンシーパフォーマンスを調べます。OpenAI GPT の torch.hub 事前トレーニング済みの重みを使用して、同じ入力に対して各インスタンスで 1,000 回の推論を実行しました。入力を作成するために、6 個の単語で作られた文章をトークン化して、サイズ (1,7) の入力トークンを作成しました。この入力を使用してモデルで 1,000 回の推論を実行し、実行ごとのレイテンシーを収集し、平均レイテンシーと 90 パーセンタイルレイテンシー (P90 レイテンシー) を報告しました。この記事では、P90 レイテンシーが 15 ミリ秒未満である必要があります。つまり、すべての推論呼び出しの 90% のレイテンシーは、15 ミリ秒未満である必要があります。

Elastic Inference アクセラレータを 4 種類の CPU クライアントインスタンスにアタッチし、それぞれに対して前述のパフォーマンステストを実行しました。次のテーブルは、1 時間あたりの料金、推論呼び出しごとの P90 レイテンシー、推論呼び出しごとの平均レイテンシー、および 100,000 推論あたりのコストを示しています。すべての組み合わせは、レイテンシーしきい値を満たしています。平均推論レイテンシーを使用して、100,000 回の推論あたりのコストを計算しているのでご注意ください。

さまざまなクライアントインスタンスがレイテンシーに与える影響を調べることができます。同じアクセラレータタイプに対して、より強力なクライアントインスタンスを使用しても、レイテンシーは大幅に改善されません。ただし、モデルがアクセラレータで実行されるため、より大きなアクセラレータをアタッチするとレイテンシーが低下し、より大きなアクセラレータには GPU コンピューティングやメモリなどのリソースが多くなります。アプリケーションに十分な CPU メモリを提供する最も安価なクライアントインスタンスタイプを選択する必要があります。m5.large または c5.large は、多くのユースケースには十分ですが、すべてのユースケースで十分というわけではありません。

上記の表から、Amazon Elastic Inference のすべてのオプションがレイテンシー基準を満たしています。m5.large と c5.large の両方で eia2.medium を使用すると、推論呼び出しごとに同じコストが発生します。この記事では、eia2.medium と c5.large を選択しました。P90 レイテンシーが eia2.medium と m5.large よりも低いためです。また、eia2.medium と c5.large よりもレイテンシーが低く、eia2.large と m5.large とほぼ同じレイテンシーであるため、eia2.large と c5.large を選びました。ただし、m5.large は基本的に同じ料金で 2 倍の CPU メモリを提供するのでご留意ください。

さまざまな推論用 EC2 インスタンスの比較

この記事では、スタンドアロン CPU および GPU ホストインスタンスのレイテンシーおよびコストパフォーマンスデータも収集し、前述の Elastic Inference ベンチマークと比較しました。スタンドアロンの CPU インスタンスは、c5.xlarge、c5.4xlarge、m5.xlarge、および m5.4xlarge でした。スタンドアロン GPU インスタンスは、p3.2xlarge、g4dn.xlarge、g4dn.2xlarge、および g4dn.4xlarge でした。

次の集計表は、Elastic Inference 対応オプションと、スタンドアロンインスタンスのオプションを示しています。

Elastic Inference がスタンドアロン CPU および GPU インスタンスで提供する価値命題をよりよく理解するために、各インスタンスタイプのレイテンシーとコスト効率データを並べて視覚化できます。次の棒グラフは 100,000 推論あたりのコストをプロットし、折れ線グラフはミリ秒単位で P90 推論レイテンシーをプロットしています。濃い灰色のバーは Elastic Inference アクセラレータを備えたインスタンス、緑色のバーはスタンドアロン GPU インスタンス、青色のバーはスタンドアロン CPU インスタンスです。

レイテンシーの分析

予想どおり、GPU インスタンスと比較した場合、CPU インスタンスのパフォーマンスは低下しています。g4dn.xl インスタンスは、CPU インスタンスよりも 3 倍以上高速です。スタンドアロン CPU インスタンスはどれも、15 ミリ秒の P90 レイテンシーしきい値を満たしていません。

ただし、これらの CPU インスタンスは、Elastic Inference をアタッチすると、GPU アクセラレーションの恩恵を受けるため、はるかに優れたパフォーマンスを発揮します。eia2.medium を使用した c5.large インスタンスは 1.7 倍以上高速で、スタンドアロン CPU インスタンスより最大 5.6 倍高速です。けれども、スタンドアロン GPU インスタンスは、Elastic Inference がアタッチされた CPU インスタンスよりも優れています。g4dn.xl は、c5.large および eia2.large のオプションの約 1.7 倍の速度です。g4dn.xl、g4dn.2xl、および g4dn.4xl インスタンスのレイテンシーはほぼ等しく、違いはほとんどありません。3 つの g4dn インスタンスにはすべて同じ GPU がありますが、より大きな g4dn インスタンスには、より多くの vCPU とメモリリソースがあります。この GPT モデルでは、vCPU とメモリリソースを増やしても推論レイテンシーは改善されません。

コスト分析

コストに関しては、c5.large および eia2.medium のオプションが際立っています。c5.large および eia2.medium のオプションは 1 時間あたりの料金が最低ではありませんが、100,000 推論あたりのコストが最低です。料金の詳細情報については、Amazon Elastic Inference の料金および Amazon EC2 の料金をご参照ください。

1 時間あたりのコストが低いインスタンスは、推論あたりのコストが必ずしも低いとは限らないと結論付けることができます。これは、推論ごとのレイテンシーが高くなる可能性があるためです。同様に、推論あたりのレイテンシーを低くするインスタンスは、推論あたりのコストが低くはならない場合があります。m5.xlarge および c5.xlarge CPU インスタンスは 1 時間あたりの料金は最低ですが、すべての Elastic Inference およびスタンドアロン GPU オプションよりも推論あたりのコストが高くなります。より大きな m5.4xlarge および c5.4xlarge インスタンスは、レイテンシーが高く、1 時間あたりのコストが高いため、すべての Elastic Inference オプションよりも推論あたりのコストが高くなります。GPU インスタンスは、CUDA 演算子が活用する高度な計算並列化により、全体的に最高のレイテンシーを実現します。けれども、推論あたりのコストが最も低いのは Elastic Inference です。

Elastic Inference では、両方の長所を活かせます。GPU が提供する並列化と推論の高速化のほとんどを実現し、さらに CPU と GPU の両方のスタンドアロンインスタンスよりも優れた費用対効果を実現します。さらに、ホストインスタンスと推論アクセラレーションハードウェアを疎結合化する柔軟性も備えているため、アプリケーションが必要とする vCPU、メモリ、およびその他すべてのリソースに対してハードウェアを柔軟に最適化できます。

上記のテストは、c5.large および eia2.medium のオプションが、OpenAI の GPT モデルを実行するためのレイテンシー基準とランタイムメモリ使用要件を満たした、最も低コストのオプションであることを示しています。

まとめ

Elastic Inference は、Amazon EC2 の PyTorch 推論ワークロード向けの低コストで柔軟なソリューションです。Elastic Inference アクセラレータを CPU クライアントインスタンスにアタッチすることで、GPU のような推論アクセラレーションを得て、スタンドアロンの GPU および CPU インスタンスよりも良いコスト効率を実現することができます。詳細については、Amazon Elastic Inference とはを参照してください。

著者について

David Fan は AWS AI のソフトウェアエンジニアです。彼は、コンピュータビジョンとディープラーニングの最先端の研究を推進し、AI 研究の大規模な本番環境における使用を妨げるコンピューティングおよびドメイン知識の障壁を下げることに情熱を傾けています。余暇には、Kaggle のコンペティションに参加し、arXiv の最新の論文を読んで過ごしています。

Srinivas Hanabe は、AWS AI で Elastic Inference 担当の主席プロダクトマネージャです。現在の職に就く前は、Amazon VPC の PM リーダーでした。Srinivas は、長距離を走ること、さまざまなトピックについて本を読むこと、家族と過ごすことが大好きで、キャリアの指導者でもあります。