AmazonSageMakerでNVIDIATritonInferenceServerを使用してモデルサービングのハイパースケールパフォーマンスを実現

機械学習（ML）アプリケーションは展開が複雑であり、多くの場合、単一の推論要求を処理するために複数のMLモデルが必要です。 一般的なリクエストは、前処理、データ変換、モデル選択ロジック、モデル集約、後処理などのステップで複数のモデルにまたがって流れる場合があります。 これにより、シリアル推論パイプライン、アンサンブル（スキャッターギャザー）、ビジネスロジックワークフローなどの一般的なデザインパターンが進化し、リクエストのワークフロー全体が有向非巡回グラフ（DAG）として実現されました。 ただし、ワークフローがより複雑になると、これらのアプリケーションの全体的な応答時間または遅延が増加し、全体的なユーザーエクスペリエンスに影響を与えます。 さらに、これらのコンポーネントが異なるインスタンスでホストされている場合、これらのインスタンス間の追加のネットワーク遅延により、全体的な遅延が増加します。 カスタマーサポートの仮想アシスタントの一般的なMLユースケースの例を考えてみましょう。 通常のリクエストでは、音声認識、自然言語処理（NLP）、ダイアログ状態の追跡、ダイアログポリシー、テキスト生成、そして最後にテキスト読み上げを含むいくつかの手順を実行する必要があります。 さらに、ユーザーインタラクションをよりパーソナライズするために、さまざまなバージョンのような最新のトランスフォーマーベースのNLPモデルを使用することもできます。 ベルト, バート, GPT。 その結果、これらのモデルアンサンブルの応答時間が長くなり、カスタマーエクスペリエンスが低下します。

全体的なスループットを損なうことなく応答時間を短縮するための一般的なパターンは、これらのモデルを、それに組み込まれた軽量のビジネスロジックとともに同じインスタンスでホストすることです。 これらのモデルは、実行中のプロセスを分離し、レイテンシーを低く抑えるために、同じインスタンス上の単一または複数のコンテナー内にさらにカプセル化できます。 さらに、全体的な遅延は、推論アプリケーションロジック、モデルの最適化、基盤となるインフラストラクチャ（コンピューティング、ストレージ、ネットワーキングを含む）、および推論要求を受け取る基盤となるWebサーバーにも依存します。 NVIDIATriton推論サーバー は、超低（XNUMX桁のミリ秒）の推論レイテンシでスループットとハードウェア使用率を最大化する機能を備えたオープンソースの推論サービスソフトウェアです。 MLフレームワーク（TensorFlow、PyTorch、ONNX、XGBoost、NVIDIA TensorRTを含む）とインフラストラクチャバックエンド（GPU、CPU、および AWSインフェレンティア。 さらに、TritonInferenceServerはと統合されています アマゾンセージメーカー、フルマネージドのエンドツーエンドMLサービスで、次のようなリアルタイムの推論オプションを提供します。 & マルチモデル ホスティング。 これらの推論オプションには、同じコンテナ内で複数のモデルをホストすることが含まれます。 単一のエンドポイント、およびホスティング 複数のコンテナを持つ複数のモデル 単一のエンドポイントの背後にあります。

2021年XNUMX月に発表しました SageMakerでのTritonInferenceServerの統合。 AWSはNVIDIAと緊密に連携して、両方の世界を最大限に活用し、AWSでのTritonを使用したモデルのデプロイを容易にしました。

この投稿では、SageMakerのTriton Inference Serverを使用して、GPUにトランスフォーマーモデルを大規模にデプロイするためのベストプラクティスについて説明します。 まず、SageMakerのレイテンシーに関する主要な概念の概要と、パフォーマンスチューニングガイドラインの概要から始めます。 次に、Tritonとその機能の概要、およびSageMakerにデプロイするためのサンプルコードを提供します。 最後に、を使用して負荷テストを実行します SageMaker推論レコメンダー HuggingFaceが提供する一般的なトランスモデルの負荷テストから得られた洞察と結論を要約します。

あなたはレビューすることができます ノート 以前は、モデルをデプロイし、次のコードを使用して独自に負荷テストを実行していました。 GitHubの.

SageMakerで提供されるモデルのパフォーマンスの調整と最適化

パフォーマンスの調整と最適化は、多くの場合、複数の反復を伴う経験的なプロセスです。 調整するパラメーターの数は組み合わせであり、構成パラメーター値のセットは互いに独立していません。 ペイロードのサイズ、タイプ、推論要求フローグラフのMLモデルの数、ストレージタイプ、コンピューティングインスタンスタイプ、ネットワークインフラストラクチャ、アプリケーションコード、推論サービングソフトウェアのランタイムと構成など、さまざまな要因が最適なパラメーターの調整に影響します。

MLモデルのデプロイにSageMakerを使用している場合は、最高の価格パフォーマンスを備えたコンピューティングインスタンスを選択する必要があります。これは複雑で反復的なプロセスであり、数週間の実験が必要になる場合があります。 まず、モデルのリソース要件と入力データのサイズに基づいて、70を超えるオプションから適切なMLインスタンスタイプを選択する必要があります。 次に、選択したインスタンスタイプのモデルを最適化する必要があります。 最後に、負荷テストを実行し、クラウド構成を調整して最適なパフォーマンスとコストを実現するために、インフラストラクチャをプロビジョニングおよび管理する必要があります。 これらすべてが、モデルの展開と市場投入までの時間を遅らせる可能性があります。 さらに、最適な展開構成を選択するには、遅延、スループット、およびコストの間のトレードオフを評価する必要があります。 SageMaker推論レコメンダー 適切なコンピューティングインスタンスタイプ、インスタンスカウント、コンテナパラメータ、および推論用のモデル最適化を自動的に選択して、スループットを最大化し、レイテンシを削減し、コストを最小化します。

SageMakerでのリアルタイムの推論とレイテンシ

SageMakerリアルタイム推論 リアルタイム、インタラクティブ、低レイテンシの要件がある推論ワークロードに最適です。 SageMaker推論エンドポイントの推論リクエストレイテンシーを監視するために最も一般的に使用されるXNUMXつのメトリックがあります

• コンテナのレイテンシ –要求を送信し、モデルのコンテナーから応答をフェッチし、コンテナーで推論を完了するのにかかる時間。 このメトリクスは、AmazonCloudWatchで 呼び出しメトリック SageMakerによって公開されました。
• モデルの待ち時間 –すべてのSageMakerコンテナにかかった合計時間 推論パイプライン。 このメトリクスは、AmazonCloudWatchで 呼び出しメトリック SageMakerによって公開されました。
• オーバーヘッドレイテンシ – SageMakerがリクエストを受信して​​からクライアントにレスポンスを返すまでの時間から、モデルのレイテンシーを差し引いて測定されます。 このメトリクスは、AmazonCloudWatchで 呼び出しメトリック SageMakerによって公開されました。
• エンドツーエンドのレイテンシ –クライアントが推論要求を送信してから応答を受信するまでに測定されます。 顧客はこれをAmazonCloudWatchのカスタムメトリクスとして公開できます。

次の図は、これらのコンポーネントを示しています。

コンテナのレイテンシはいくつかの要因に依存します。 以下は最も重要なもののXNUMXつです。

• 推論サーバーとの通信に使用される基礎となるプロトコル（HTTP（s）/ gRPC）
• 新しいTLS接続の作成に関連するオーバーヘッド
• 要求/応答ペイロードの逆シリアル化時間
• 基盤となる推論サーバーによって提供されるキューイングおよびバッチ処理機能を要求する
• 基盤となる推論サーバーによって提供されるリクエストスケジューリング機能
• 推論サーバーの基本的なランタイムパフォーマンス
• モデル予測関数を呼び出す前の前処理および後処理ライブラリのパフォーマンス
• 基盤となるMLフレームワークバックエンドのパフォーマンス
• モデル固有およびハードウェア固有の最適化

この投稿では、全体的なスループットとコストとともに、コンテナのレイテンシを最適化することに主に焦点を当てています。 具体的には、SageMakerコンテナ内で実行されているパフォーマンスチューニングTritonInferenceServerについて説明します。

ユースケースの概要

実稼働セットアップでのNLPモデルの展開とスケーリングは、非常に困難な場合があります。 NLPモデルはサイズが非常に大きく、数百万のモデルパラメータが含まれていることがよくあります。 実稼働グレードのNLPアプリケーションの厳しいパフォーマンスとスケーラビリティの要件を満たすには、最適なモデル構成が必要です。

この投稿では、Triton Inference Serverコンテナーに基づくSageMakerリアルタイムエンドポイントを使用してNLPユースケースのベンチマークを行い、MLユースケースのパフォーマンスチューニングの最適化を推奨します。 事前にトレーニングされた大型のトランスベースのHuggingFaceを使用します BERTラージケースなし モデル。約336億512万のモデルパラメータがあります。 二項分類モデルに使用される入力文は、500トークンの最大入力シーケンス長にパディングおよび切り捨てられます。 推論負荷テストは、30,000秒あたりXNUMX回の呼び出し（XNUMX分あたり最大XNUMX回の呼び出し）をシミュレートします。 ModelLatency 0.5秒（500ミリ秒）未満です。

次の表は、ベンチマーク構成をまとめたものです。

NVIDIATriton推論サーバー

Triton Inference Serverは、本番環境でのモデルのスケーラブルで迅速かつ簡単な展開を可能にするように特別に設計されています。 Tritonは、TensorFlow、TensorRT、PyTorch、XGBoost、ONNXなどのさまざまな主要なAIフレームワークをサポートしています。 PythonおよびC++カスタムバックエンドを使用すると、よりカスタマイズされたユースケースのために推論ワークロードを実装することもできます。

最も重要なことは、Tritonは、モデルをホストするための単純な構成ベースのセットアップを提供します。これにより、コーディングの労力をほとんどかけずに使用できるパフォーマンス最適化機能の豊富なセットが公開されます。

Tritonは、さまざまな最適化手法を使用してハードウェアの使用率を最大化することにより、推論のパフォーマンスを向上させます（同時モデルの実行と動的バッチ処理が最も頻繁に使用されます）。 動的バッチサイズと同時モデルインスタンスの数のさまざまな組み合わせから最適なモデル構成を見つけることは、Tritonを使用して低コストのサービス内でリアルタイムの推論を実現するための鍵です。

動的バッチ処理

サーバーが複数の独立した要求で呼び出されると、多くの実践者は推論を順番に実行する傾向があります。 セットアップは簡単ですが、通常、GPUの計算能力を利用することはベストプラクティスではありません。 これに対処するために、Tritonは組み込みの最適化を提供します 動的バッチ処理 サーバー側でこれらの独立した推論要求を組み合わせて、より大きなバッチを動的に形成し、スループットを向上させます。 次の図は、Tritonランタイムアーキテクチャを示しています。

前述のアーキテクチャでは、すべての要求は、推論を待機するために実際のモデルスケジューラキューに入る前に、最初に動的バッチャーに到達します。 を使用して、動的バッチ処理の優先バッチサイズを設定できます。 Preferred_batch_size モデル構成の設定。 （形成されたバッチサイズは、 最大バッチサイズ モデルがサポートします。）構成することもできます max_queue_delay_micro秒 レイテンシー要件に基づいて、他のリクエストがバッチに参加するのを待つためのバッチャーの最大遅延時間を指定します。

次のコードスニペットは、モデル構成ファイルを使用してこの機能を追加し、実際の推論に推奨されるバッチサイズ16で動的バッチ処理を設定する方法を示しています。 現在の設定では、16の優先バッチサイズが満たされるか、最初の要求が動的バッチャーに到達してから100マイクロ秒の遅延時間が経過すると、モデルインスタンスが即座に呼び出されます。

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

モデルを同時に実行する

追加のレイテンシオーバーヘッドなしでハードウェア使用率を最大化するためにTritonで提供されるもうXNUMXつの重要な最適化は 同時モデル実行、これにより、複数のモデルまたは同じモデルの複数のコピーを並行して実行できます。 この機能により、Tritonは複数の推論要求を同時に処理できるようになり、ハードウェアでアイドル状態の計算能力を利用することで推論スループットが向上します。

次の図は、数行のコード変更だけでさまざまなモデル展開ポリシーを簡単に構成する方法を示しています。 たとえば、構成A（左）は、XNUMXつのモデルインスタンスの同じ構成をブロードキャストできることを示しています。 bert-large-uncased 利用可能なすべてのGPUに。 対照的に、構成B（中央）は、他のGPUのポリシーを変更せずに、GPU0のみの異なる構成を示しています。 構成C（右）に示すように、単一のGPUに異なるモデルのインスタンスをデプロイすることもできます。

構成Cでは、計算インスタンスは、DistilGPT-2モデルのXNUMXつの同時要求と、 bert-large-uncased 並列モデル。 これらの最適化により、ハードウェアリソースをサービングプロセスにより有効に活用できるため、スループットが向上し、ワークロードのコスト効率が向上します。

TensorRT

NVIDIA TensorRT Tritonとシームレスに連携する高性能ディープラーニング推論用のSDKです。 すべての主要なディープラーニングフレームワークをサポートするTensorRTには、強力な最適化を介して大量のデータで推論を実行するための低レイテンシと高スループットを提供する推論オプティマイザーとランタイムが含まれています。

TensorRTはグラフを最適化して、不要なメモリを解放し、効率的に再利用することでメモリフットプリントを最小限に抑えます。 さらに、TensorRTコンパイルは、モデルグラフ内のスパース操作を融合して、より大きなカーネルを形成し、複数の小さなカーネル起動のオーバーヘッドを回避します。 カーネルの自動調整は、ターゲットGPUで最適なアルゴリズムを選択することにより、ハードウェアを完全に活用するのに役立ちます。 CUDAストリームを使用すると、モデルを並行して実行して、GPU使用率を最大化して最高のパフォーマンスを実現できます。 最後になりましたが、量子化手法では、Tensorコアの混合精度アクセラレーションを完全に使用して、モデルをFP32、TF32、FP16、およびINT8で実行し、最高の推論パフォーマンスを実現できます。

SageMakerホスティングのTriton

SageMakerホスティング サービスは、モデルのデプロイとサービスを容易にすることを目的としたSageMaker機能のセットです。 さまざまなユースケースに合わせて調整されたMLモデルを簡単に展開、自動スケーリング、監視、および最適化するためのさまざまなオプションを提供します。 これは、永続的でサーバーレスオプションで常に利用できるものから、一時的、長時間実行、またはバッチ推論のニーズまで、あらゆるタイプの使用パターンに合わせてデプロイメントを最適化できることを意味します。

SageMakerのホスティング傘下には、対応するサポートされているMLフレームワーク用の適切なモデルサーバーソフトウェアがあらかじめパッケージ化されたSageMaker推論ディープラーニングコンテナー（DLC）のセットもあります。 これにより、モデルサーバーのセットアップなしで高い推論パフォーマンスを実現できます。これは、モデル展開の最も複雑な技術的側面であり、一般に、データサイエンティストのスキルセットの一部ではありません。 Triton推論サーバーが 利用できます SageMakerディープラーニングコンテナ（DLC).

この幅広いオプション、モジュール性、さまざまなサービングフレームワークの使いやすさにより、SageMakerとTritonは強力にマッチしています。

テスト結果のベンチマークのためのSageMaker推論推奨

SageMakerInferenceRecommenderを使用して実験を実行します。 SageMaker Inference Recommendationerは、次の図に示すように、デフォルトとアドバンスのXNUMX種類のジョブを提供します。

デフォルトのジョブは、ベンチマークするモデルとサンプルペイロードのみを含むインスタンスタイプに関する推奨事項を提供します。 インスタンスの推奨事項に加えて、このサービスはパフォーマンスを向上させるランタイムパラメーターも提供します。 デフォルトのジョブの推奨事項は、インスタンス検索を絞り込むことを目的としています。 インスタンスファミリの場合もあれば、特定のインスタンスタイプの場合もあります。 次に、デフォルトのジョブの結果が高度なジョブに送られます。

高度なジョブは、パフォーマンスをさらに微調整するためのより多くのコントロールを提供します。 これらのコントロールは、実際の環境と本番環境の要件をシミュレートします。 これらの制御の中には、ベンチマークの要求パターンをステージングすることを目的としたトラフィックパターンがあります。 トラフィックパターンの複数のフェーズを使用して、ランプまたは定常トラフィックを設定できます。 たとえば、 初期ユーザー数 1の、 スポーン率 1の、および durationInSeconds 600を超えると、最初に10人の同時ユーザー、最後に1人の同時ユーザーで10分のランプトラフィックが発生する可能性があります。 さらに、コントロールでは、 最大呼び出し数 & モデル遅延しきい値 生産のしきい値を設定します。これにより、しきい値のXNUMXつを超えると、ベンチマークが停止します。

最後に、 推奨メトリック スループット、最大スループットでの遅延、および推論あたりのコストが含まれるため、それらを簡単に比較できます。

高度なジョブタイプのSageMakerInferenceRecommendationerを使用して実験を実行し、トラフィックパターンをさらに制御し、サービングコンテナーの構成を微調整します。

実験のセットアップ

SageMaker Inference Recommendationerのカスタム負荷テスト機能を使用して、ユースケースで概説されているNLPプロファイルのベンチマークを行います。 まず、NLPモデルとMLタスクに関連する次の前提条件を定義します。 SageMaker Inference Recommendationrは、この情報を使用して、推論Dockerイメージをからプルします Amazon エラスティック コンテナ レジストリ （Amazon ECR）モデルをSageMakerモデルレジストリに登録します。

SageMaker Inference Recommendationrのトラフィックパターン構成により、カスタム負荷テストのさまざまなフェーズを定義できます。 次のコードに示すように、負荷テストは25人の初期ユーザーから始まり、毎分1500人の新しいユーザーを生み出します。合計時間はXNUMX分（XNUMX秒）です。

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

XNUMXつの異なる状態で同じモデルの負荷テストを実験します。 PyTorchベースの実験では、標準の変更されていないPyTorchモデルを使用します。 TensorRTベースの実験では、事前にPyTorchモデルをTensorRTエンジンに変換します。

次の表に要約されているように、これらXNUMXつのモデルにパフォーマンス最適化機能のさまざまな組み合わせを適用します。

テスト結果と観察

同じg4dnファミリ内の4つのインスタンスタイプ（ml.g4dn.xlarge、ml.g2dn.4xlarge、ml.g12dn.4xlarge）の負荷テストを実施しました。 すべてのg4dnインスタンスタイプは、NVIDIA T2 TensorCoreGPUおよび第4世代IntelCascadeLakeプロセッサにアクセスできます。 インスタンスタイプの選択の背後にあるロジックは、使用可能なGPUが12つだけのインスタンスと、複数のGPUにアクセスできるインスタンス（ml.gXNUMXdn.XNUMXxlargeの場合はXNUMXつ）の両方を持つことでした。 さらに、使用可能なGPUがXNUMXつしかないインスタンスでvCPU容量を増やすと、コストパフォーマンス比が向上するかどうかをテストしたいと思いました。

まず、個々の最適化のスピードアップについて見ていきましょう。 次のグラフは、TensorRTの最適化により、ml.g50dn.xlargeインスタンスのPyTorchのネイティブのものと比較してモデルのレイテンシが4％削減されることを示しています。 このレイテンシの短縮は、ml.g4dn.12xlargeのマルチGPUインスタンスで30倍以上に増加します。 一方、XNUMX％のスループットの向上は両方のインスタンスで一貫しており、TensorRT最適化を適用した後の費用対効果が向上します。

動的バッチ処理を使用すると、ml.g2dn.xlarge、ml.g4dn.4xlarge、ml.g2dn.4xlargeのすべての実験インスタンスで同じハードウェアアーキテクチャを使用して、レイテンシを大幅に増加させることなく、スループットを12倍近く向上させることができます。

同様に、モデルの同時実行により、ml.g3dn.xlargeインスタンスでGPU使用率を最大化することで、スループットを約4〜4倍向上させ、ml.g2dn.4xlargeインスタンスとmlのマルチGPUインスタンスの両方で約2倍向上させることができます。 g4dn.12xlarge ..このスループットの向上は、レイテンシーのオーバーヘッドなしで実現します。

さらに良いことに、これらすべての最適化を統合して、ハードウェアリソースを最大限に活用することにより、最高のパフォーマンスを提供できます。 次の表とグラフは、実験で得られた結果をまとめたものです。

[1]上記の表の初期インスタンス数は、ワークロードのスループットと遅延の要件を維持するために自動スケーリングポリシーで使用する推奨インスタンス数です。

[2]上記の表のXNUMX時間あたりのコストは、インスタンスタイプの初期インスタンス数と価格に基づいて計算されています。

結果は主に、さまざまなパフォーマンス最適化機能に期待される影響を検証します。

• TensorRTのコンパイルは、すべてのインスタンスタイプで最も信頼できる影響を及ぼします。 インスタンスあたりの30分あたりのトランザクション数は35〜25％増加し、デフォルトのPyTorch BERTに対するTensorRTエンジンのパフォーマンスと比較した場合、一貫して約XNUMX％のコスト削減が実現しました（pt-base）。 TensorRTエンジンのパフォーマンスの向上は、他のテスト済みのパフォーマンスチューニング機能に組み込まれ、活用されています。
• 各GPU（インスタンスグループ）に80つのモデルをロードすると、測定されたすべてのメトリックがほぼ90倍になります。 50インスタンスあたりのXNUMX分あたりの呼び出し数は、約XNUMX〜XNUMX％増加し、XNUMXつのGPUを使用しているかのように、XNUMX％の範囲でコストを削減しました。 実際には、 アマゾンクラウドウォッチ （例として）g4dn.2xlargeでの実験のメトリックは、XNUMXつのモデルのインスタンスグループを構成すると、CPUとGPUの両方の使用率がXNUMX倍になることを確認します。

さらなるパフォーマンスとコスト最適化のヒント

この投稿で提示されたベンチマークは、推論のパフォーマンスを向上させるためにTritonで使用できる可能性のある機能と手法のほんの一部にすぎません。 これらは、バイナリペイロードをモデルサーバーに送信したり、より大きなバッチのペイロードを送信したりするなどのデータ前処理技術から、次のようなネイティブTriton機能にまで及びます。

• モデルのウォームアップ、これは、最初の推論要求が受信される前にモデルを完全に初期化することにより、初期の遅い推論要求を防ぎます。
• 応答キャッシュ、繰り返されるリクエストをキャッシュします。
• モデルアンサンブリング、これにより、XNUMXつ以上のモデルのパイプラインと、それらのモデル間の入力テンソルと出力テンソルの接続を作成できます。 これにより、各リクエストの処理フローに前処理と後処理のステップを追加したり、他のモデルとの推論を追加したりする可能性が広がります。

今後の投稿で、これらの手法と機能のテストとベンチマークを行う予定ですので、ご期待ください。

まとめ

この投稿では、TritonInferenceServerでPyTorchBERTモデルを提供するためのSageMakerリアルタイムエンドポイントのパフォーマンスを最大化するために使用できるいくつかのパラメーターについて説明しました。 SageMaker Inference Recommendationrを使用してベンチマークテストを実行し、これらのパラメーターを微調整しました。 これらのパラメーターは、本質的にTensorRTベースのモデル最適化に関連しており、最適化されていないバージョンと比較して、応答時間がほぼ50％向上します。 さらに、モデルを同時に実行し、Tritonの動的バッチ処理を使用すると、スループットがほぼ70％向上しました。 これらのパラメータを微調整することで、推論コストも全体的に削減されました。

正しい値を導き出す最良の方法は、実験を行うことです。 ただし、パフォーマンスの調整と最適化に関する経験的知識の構築を開始するには、さまざまなTriton関連パラメーターの組み合わせと、MLモデルおよびSageMakerMLインスタンス全体のパフォーマンスへの影響を観察できます。

SageMakerは、MLライフサイクルの各段階から未分化の重労働を取り除くためのツールを提供します。これにより、モデルのデプロイを完全に最適化するために必要な迅速な実験と調査が容易になります。

負荷テストと展開に使用されるノートブックは、 GitHubの。 Tritonの設定とSageMakerInferenceRecommendationrの設定を更新して、ユースケースに最適なものにし、費用対効果が高く、パフォーマンスが最も高い推論ワークロードを実現できます。

著者について

ヴィクラムエランゴ は、米国バージニア州に拠点を置くアマゾンウェブサービスのAI/MLスペシャリストソリューションアーキテクトです。 Vikramは、大規模な機械学習アプリケーションを構築および展開するための設計、ソートリーダーシップにより、金融および保険業界の顧客を支援します。 彼は現在、自然言語処理、責任あるAI、推論の最適化、企業全体でのMLのスケーリングに焦点を当てています。 余暇には、家族と一緒に旅行、ハイキング、料理、キャンプを楽しんでいます。

ジョアンモウラ アマゾンウェブサービスのAI/MLスペシャリストソリューションアーキテクトです。 彼は主にNLPのユースケースに焦点を当て、顧客がディープラーニングモデルのトレーニングと展開を最適化するのを支援しています。 彼はまた、ローコードMLソリューションとML専用ハードウェアの積極的な支持者でもあります。

モハンガンディー AWSのシニアソフトウェアエンジニアです。 彼は過去9年間AWSに勤務しており、前哨基地でEMR、EFA、RDSなどのさまざまなAWSサービスに携わってきました。 現在、彼はSageMakerInferenceExperienceの改善に注力しています。 余暇には、ハイキングやマラソンを楽しんでいます。

ダワル・パテル AWSのプリンシパル機械学習アーキテクトです。 彼は、分散コンピューティングや人工知能に関連する問題について、大企業から中規模の新興企業に至るまでの組織と協力してきました。 彼は、NLPおよびコンピュータービジョンドメインを含むディープラーニングに焦点を当てています。 彼は、顧客がSageMakerで高性能モデルの推論を実現するのを支援します。

サントッシュバヴァニ は、Amazon SageMaker ElasticInferenceチームのシニアテクニカルプロダクトマネージャーです。 彼は、SageMakerの顧客がモデルの推論とデプロイを加速するのを支援することに焦点を当てています。 余暇には、旅行、テニス、プーアル茶をたくさん飲むのが好きです。

ジャホン・リュウ NVIDIAのクラウドサービスプロバイダーチームのソリューションアーキテクトです。 彼は、クライアントがNVIDIAアクセラレーションコンピューティングを活用してトレーニングと推論の課題に対処する機械学習とAIソリューションを採用するのを支援しています。 余暇には、折り紙、DIYプロジェクト、バスケットボールを楽しんでいます。

• コインスマート。 ヨーロッパで最高のビットコインと暗号通貨取引所。
• Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 出入り自由。
• CryptoHawk。 アルトコインレーダー。 無料トライアル。
• 出典: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/