このブログ投稿は、IntelのJonathan Lee、Nelson Leung、Paul Min、およびTroySquillaciによって共同執筆されました。
In 第1部 この投稿では、インテル®3DATがどのようにコラボレーションしたかについて説明しました AWS 機械学習プロフェッショナル サービス (MLPS)スケーラブルなAISaaSアプリケーションを構築します。 3DATは、コンピュータービジョンとAIを使用して、標準ビデオから1,000を超える生体力学データポイントを認識、追跡、分析します。 これにより、顧客は、詳細なパフォーマンスデータとXNUMX次元の視覚化を備えた、Webやモバイルアプリケーションなどのリッチで強力な生体力学主導の製品を作成できます。
この投稿のパート2では、アーキテクチャの各段階について詳しく説明します。 3DATの設計要件を満たすために使用されるAWSサービスを調査します。 Amazon Kinesisデータストリーム および Amazon Elastic Kubernetesサービス (Amazon EKS)、このSoftware as a Service(SaaS)アプリケーションに必要なポーズ推定モデルをスケーラブルに展開するため。
アーキテクチャの概要
MLPSチームの主な目標は、2Dおよび3Dポーズ推定モデルのパイプラインを生産化し、機能的でスケーラブルなアプリケーションを作成することでした。 次の図は、ソリューションアーキテクチャを示しています。
完全なアーキテクチャは、XNUMXつの主要なコンポーネントに分類されます。
- ユーザーアプリケーションインターフェイスレイヤー
- データベース
- ワークフローオーケストレーション
- スケーラブルなポーズ推定推論の生成
- 運用監視
各コンポーネント、それらの相互作用、および設計選択の背後にある理論的根拠について詳しく見ていきましょう。
ユーザーアプリケーションインターフェイスレイヤー
次の図は、アプリケーションとそのリソースのユーザーアクセスと制御を提供するアプリケーションインターフェイスレイヤーを示しています。
これらのアクセスポイントは、さまざまな顧客のペルソナに基づいたさまざまなユースケースをサポートします。 たとえば、アプリケーションユーザーはCLIを介してジョブを送信できますが、開発者はPython SDKを使用してアプリケーションを構築し、ポーズ推定インテリジェンスをアプリケーションに埋め込むことができます。 CLIとSDKはモジュラーコンポーネントとして構築されています。どちらのレイヤーもAPIレイヤーのラッパーであり、 アマゾンAPIゲートウェイ API呼び出しを解決し、 関連するAWSLambda 各API呼び出しに関連付けられたバックエンドロジックを処理する関数。 これらのレイヤーは、このSaaSアプリケーションを効果的に使用できる幅広い顧客基盤を開くため、インテルOTGチームにとって重要なコンポーネントでした。
APIレイヤー
このソリューションには、このプラットフォームで動作するオブジェクトのタイプに対応するXNUMXつのAPIのコアセットがあります。 各APIには、実行可能なAPIアクションを定義するPythonファイルがあります。 新しいオブジェクトの作成には、オブジェクトIDが順番に自動的に割り当てられます。 これらのオブジェクトの属性は、 Amazon Auroraサーバーレス このIDを使用するデータベース。 したがって、APIアクションは、Auroraデータベースをクエリするためのバックエンドロジックを含む中央ファイルで定義されている関数に関連付けられます。 このバックエンドロジックはBoto3を使用します AmazonRDSDataServiceクライアント データベースクラスターにアクセスします。
唯一の例外は /job
API、 create_job
新しい処理ジョブを作成するためのビデオ送信を処理するメソッド。 このメソッドは、 AWSステップ関数 ジョブを実行するためのワークフローロジック。 渡すことによって job_id
、このメソッドはBoto3を使用します ステップ関数クライアント を呼び出す start_execution
指定されたメソッド stateMachineARN
(Amazonリソース名)。
XNUMXつのオブジェクトAPIには、次の表に要約されているメソッドと同様のアクセスパターンがあります。
メソッドタイプ | 関数名 | 説明 |
GET | list_[object_name]s |
データベースからこのタイプのすべてのオブジェクトを選択して表示します。 |
POST | create_[object] |
必要な入力を含む新しいオブジェクトレコードをデータベースに挿入します。 |
GET | get_[object] |
データベースからオブジェクトIDに基づいてオブジェクト属性を選択し、表示します。 |
PUT | update_[object] |
必要な入力で既存のオブジェクトレコードを更新します。 |
DELETE | delete_[object] |
オブジェクトIDに基づいて、データベースから既存のオブジェクトレコードを削除します。 |
XNUMXつのAPIの詳細は次のとおりです。
- /ユーザー –ユーザーは、このアプリケーションにジョブを送信することを許可された誰かのIDです。 ユーザーを作成するには、ユーザー名、ユーザーの電子メール、およびユーザーが属するグループIDが必要です。
- /ユーザー・グループ –ユーザーグループはユーザーの集まりです。 すべてのユーザーグループは、XNUMXつのプロジェクトとXNUMXつのパイプラインパラメーターセットにマップされます。 (インフラストラクチャリソースとパイプラインパラメータの観点から)異なる層を持つために、ユーザーはユーザーグループに分けられます。 各ユーザーは、XNUMXつのユーザーグループにのみ属することができます。 ユーザーグループを作成するには、プロジェクトID、パイプラインパラメータセットID、ユーザーグループ名、およびユーザーグループの説明が必要です。 ユーザーグループは、AWSアカウントで定義されたユーザーロールとは異なることに注意してください。 後者は、アクセスロール(管理者など)に基づいて異なるレベルのアクセスを提供するために使用されます。
- /事業 –プロジェクトは、さまざまなインフラストラクチャリソースのセットをグループ化するために使用されます。 プロジェクトは単一に関連付けられています
project_cluster_url
(Auroraクラスター)ユーザー、ジョブ、およびその他のメタデータを記録するために、project_queue_arn
(Kinesis Data Streams ARN)、およびフレームバッチでの推論の実行またはビデオでの後処理に使用されるコンピューティングランタイム環境(現在はCortexを介して制御されています)。 各ユーザーグループはXNUMXつのプロジェクトに関連付けられており、このメカニズムは、さまざまなユーザーグループのレイテンシと計算能力の観点からさまざまな層を有効にする方法です。 プロジェクトの作成には、プロジェクト名、プロジェクトクラスターURL、およびプロジェクトキューARNが必要です。 - / pipeline –パイプラインは、Cortexによって調整されたAmazon EKS推論生成クラスターでビデオ処理を実行する一連の処理コンテナーの単一の構成に関連付けられています(詳細については、ビデオ処理推論生成のセクションを参照してください)。 通常、これは、前処理とデコード、オブジェクト検出、ポーズ推定の2つのコンテナで構成されます。 たとえば、デコードとオブジェクト検出の手順は3Dパイプラインと3Dパイプラインで同じですが、HRNetまたは2DMPPEのいずれかを使用して最後のコンテナを交換すると、3D処理パイプラインとXNUMXD処理パイプラインのパラメータが設定されます。 新しい構成を作成して、処理に使用できるパイプラインを定義できます。入力として、そのパイプラインを定義するモデルエンドポイント呼び出しのシーケンスを詳細に示す新しいPythonファイルをCortexリポジトリに入力する必要があります(ビデオ処理の推論生成に関するセクションを参照してください)。 )。 パイプラインエンドポイントは、単一のフレームを処理するために呼び出されるCortexエンドポイントです。 パイプラインを作成するには、パイプライン名、パイプラインの説明、およびパイプラインエンドポイントが必要です。
- / pipeline_parameter_set –パイプラインパラメーターセットは、特定のパイプラインの複数のパラメーター(パイプライン構成ランタイム)の柔軟なJSONコレクションであり、複数のパイプライン構成ランタイムが必要な場合に将来のカスタマイズに柔軟性を提供するために追加されます。 ユーザーグループは特定のパイプラインパラメータセットに関連付けることができ、その目的は、ユーザーグループごとおよびパイプラインごとに異なるパラメータグループを持つことです。 これは、さまざまな顧客、特にISVがアプリケーションの使用を開始するときに、移植性をサポートするカスタマイズを組み込むためのIntelOTGにとって重要な前向きな追加でした。
- / pipeline_parameters –パイプラインパラメーターの単一のコレクションは、パイプラインパラメーターセットのインスタンス化です。 これにより、パイプラインパラメータセットのパイプラインパラメータへの1:多くのマッピングになります。 このAPIには、パイプラインパラメーターのセットに関連付けるパイプラインIDが必要です。これにより、パイプラインパラメーターをパイプラインに1:1でマッピングするためのパイプラインを作成できます。 このAPIに必要なその他の入力は、パイプラインパラメーターセットID、パイプラインパラメーター値、およびパイプラインパラメーター名です。
- /ビデオ –ビデオオブジェクトは、ジョブ中に送信される.zipパッケージを構成する個々のビデオを定義するために使用されます。 このファイルは、送信後に複数のビデオに分割されます。 ビデオはに関連しています
job_id
.zipパッケージが送信されるジョブの場合、および Amazon シンプル ストレージ サービス (Amazon S3)生の分離されたビデオの場所と各ビデオの後処理結果のパス。 ビデオオブジェクトには、ビデオの進行状況のパーセンテージも含まれています。これは、そのビデオの個々のフレームバッチの処理中に一貫して更新され、完了または未完了のビデオステータスフラグも含まれます。 ビデオの作成には、ジョブID、ビデオパス、ビデオ結果パス、ビデオ進行率、およびビデオステータスが必要です。 - / frame_batch -
frame_batch
オブジェクトは、単一のビデオをサンプリングすることによって作成されたフレームのミニバッチです。 ビデオを通常のサイズのフレームバッチに分離すると、遅延を調整するための手段が提供され、並列化とスループットが向上します。 これは、推論のためにKinesisDataStreamsを介して実行される詳細なユニットです。 フレームバッチを作成するには、ビデオID、フレームバッチ開始番号、フレームバッチ終了番号、フレームバッチ入力パス、フレームバッチ結果パス、およびフレームバッチステータスが必要です。 - /仕事 –このインタラクションAPIは、処理ジョブを開始するためのファイル送信に使用されます。 このAPIは、ビデオ処理バックエンドのステップ関数ワークフロー調整およびAmazon EKSクラスターと対話するための直接パスであるため、他のオブジェクトAPIとは異なる機能を備えています。 このAPIには、ユーザーID、プロジェクトID、パイプラインID、パイプラインパラメーターセットID、ジョブパラメーター、およびジョブステータスが必要です。 ジョブパラメータでは、入力ファイルパスが指定されます。これは、処理されるビデオの.zipパッケージが配置されているAmazonS3内の場所です。 ファイルのアップロードは、
upload_handler
メソッド。ユーザーがファイルを配置するための事前に署名されたS3URLを生成します。 WORKFLOW_STATEMACHINE_ARNは、に渡される環境変数です。create_job
入力ファイルパスを含むビデオ.zipパッケージを送信してジョブを開始する場所を指定するAPI。
次の表は、APIの機能をまとめたものです。
メソッドタイプ | 演算 | 説明 |
GET | list_jobs |
データベースからすべてのジョブを選択して表示します。 |
POST | create_ job |
ユーザーID、プロジェクトID、パイプラインID、パイプラインパラメーターセットID、ジョブ結果パス、ジョブパラメーター、およびジョブステータスを含む新しいジョブレコードを挿入します。 |
GET | get_ job |
データベースからジョブIDに基づいてジョブ属性を選択して表示します。 |
GET | upload_handler |
.zipファイルをアップロードする場所として事前署名されたS3URLを生成します。 S3バケット名が必要で、アプリケーション/zipファイルタイプが必要です。 |
PythonSDKレイヤー
チームはAPIに基づいて、開発者がAPIメソッドに簡単にアクセスできるようにするラッパーとしてPythonSDKクライアントライブラリを作成しました。 彼らはオープンソースを使用しました 詩、Pythonのパッケージ化と依存関係の管理を処理します。 彼らは作成しました client.py
Pythonを使用して各APIをラップする関数を含むファイル requests
APIリクエストと例外を処理するライブラリ。
開発者がIntel3DATSDKを起動するには、Poetryパッケージをインストールしてビルドする必要があります。 次に、次の単純なPythonインポートを追加できます。 intel_3dat_sdk
任意のPythonコードに。
クライアントを使用するには、APIエンドポイントを指定して、クライアントのインスタンスを作成できます。
次に、クライアントを使用して、次のような個々のメソッドを呼び出すことができます。 create_pipeline
メソッド(次のコードを参照)。パイプライン名やパイプラインの説明などの適切な引数を取ります。
CLIレイヤー
同様に、チームはAPIに基づいて構築し、Pythonコードを記述せずに簡単なインターフェイスでAPIメソッドにアクセスしたいユーザー向けのコマンドラインインターフェイスを作成しました。 彼らはオープンソースのPythonパッケージを使用しました クリック (コマンドラインインターフェイス作成キット)。 このフレームワークの利点は、コマンドの任意のネスト、ヘルプページの自動生成、および実行時のサブコマンドの遅延読み込みのサポートです。 同じように client.py
SDKの場合と同様に、各SDKクライアントメソッドはClickを使用してラップされ、必要なメソッド引数はコマンドラインフラグに変換されました。 フラグ入力は、SDKコマンドを呼び出すときに使用されます。
CLIを起動するには、 CLI configure
指図。 エンドポイントURLの入力を求められます。
これで、CLIを使用して、APIメソッドに関連するさまざまなコマンドを呼び出すことができます。次に例を示します。
データベース
このアプリケーションはデータベースとして、Aurora Serverlessを使用して、データベースエンジンとしてMYSQLを使用する各APIに関連付けられたメタデータを格納します。 Auroraサーバーレスデータベースサービスの選択は、可能な場合はサーバーレスAWSサービスを利用することでインフラストラクチャのオーバーヘッドを最小限に抑えるという設計原則に準拠しています。 次の図は、このアーキテクチャを示しています。
サーバーレスエンジンモード このアプリケーションは新規顧客にスケールアップし、ワークロードはまだ不確実であるため、断続的な使用パターンを満たしています。 データベースエンドポイントを起動する場合、特定のDBインスタンスサイズは必要ありません。クラスター容量の最小範囲と最大範囲のみが必要です。 Aurora Serverlessは、ルーターフリートの適切なプロビジョニングを処理し、リソース間でワークロードを分散します。 Aurora Serverlessは、最低1日から最大35日間のバックアップ保持を自動的に実行します。 チームは、デフォルトを最大値の35に設定することにより、安全性を最適化しました。
さらに、チームは データAPI 永続的な接続を必要としないAuroraサーバーレスクラスターへのアクセスを処理し、代わりに安全なHTTPエンドポイントとAWSSDKとの統合を提供します。 この機能は AWSシークレットマネージャー データベースのクレデンシャルを保存して、クレデンシャルを明示的に渡す必要がないようにします。 CREATE TABLEスクリプトは、XNUMXつのAPIに対応するXNUMXつのテーブルのそれぞれの.sqlファイルに書き込まれました。 このデータベースにはシステム内のすべてのメタデータとオブジェクトの状態が含まれているため、APIメソッドは適切なSQLコマンドを使用して実行されました(たとえば、 select * from Job
list_jobs
API)およびに渡されます execute_statement
DataAPIのAmazonRDSクライアントからのメソッド。
ワークフローオーケストレーション
次の図に示すように、アプリケーションの機能バックボーンは、ワークフローを調整するためのステップ関数を使用して処理されました。
ステートマシンは、XNUMXつのLambda関数のシーケンスで構成されていました。これは、ジョブが送信されたときに開始されます。 create_job
からのメソッド job
API。 ジョブの作成には、ユーザーID、プロジェクトID、パイプラインID、パイプラインパラメーターセットID、ジョブ結果パス、ジョブパラメーター、およびジョブステータスが必要です。 最初に、を使用してビデオファイルの.zipパッケージをアップロードできます。 upload_handler
事前に署名されたS3URLを生成するためのジョブAPIからのメソッド。 ジョブの送信中に、ファイルの場所を指定するために、入力ファイルのパスがジョブパラメータを介して渡されます。 これにより、ワークフローステートマシンの実行が開始され、次のXNUMXつの主要なステップがトリガーされます。
- イニシャライザラムダ関数
- 送信者ラムダ関数
- 完了チェックラムダ関数
- コレクターラムダ関数
イニシャライザラムダ関数
イニシャライザーの主な機能は、.zipパッケージを個々のビデオファイルに分割し、サブミッター用に準備することです。 まず、.zipファイルがダウンロードされ、次にビデオファイルを含む個々のファイルが解凍されて抽出されます。 ビデオは、できれば.mp4形式で、S3バケットにアップロードされます。 を使用して create_video
メソッド video
API、ビデオオブジェクトは、入力としてビデオパスを使用して作成されます。 これにより、各ビデオのデータがAuroraデータベースに挿入されます。 JSONファイルなどの他のファイルタイプはメタデータと見なされ、同様にアップロードされますが、ビデオオブジェクトは作成されません。 抽出されたファイルとビデオファイルの名前のリストが次のステップに渡されます。
送信者ラムダ関数
サブミッター関数は、イニシャライザーによって抽出されたビデオファイルを取得し、ビデオフレームのミニバッチを画像として作成します。 現在制作中のほとんどのコンピュータビジョンモデルは画像でトレーニングされているため、ビデオが処理される場合でも、モデルの推論の前に最初に画像フレームに分離されます。 最先端のポーズ推定モデルを使用するこの現在のソリューションも例外ではありません。サブミッターからのフレームバッチがKinesisDataStreamsに渡され、推論生成ステップが開始されます。
まず、ビデオファイルがLambda関数によってダウンロードされます。 フレームレートとフレーム数は、 FileVideoStream
モジュールを imutils.video
処理ライブラリ。 フレームは、このパイプラインの主要な調整可能なパラメーターの3つである、指定されたミニバッチサイズに従って抽出およびグループ化されます。 Python Pickleライブラリを使用して、データがシリアル化され、AmazonSXNUMXにアップロードされます。 続いて、フレームバッチオブジェクトが作成され、Auroraデータベースにメタデータエントリが作成されます。 このLambda関数は、に依存するDockerfileを使用して構築されました opencv-python
, numpy
, imutils
ライブラリ。
完了チェックラムダ関数
完了チェック機能は、引き続きAuroraデータベースにクエリを実行して、この現在のジョブの.zipパッケージ内の各ビデオについて、COMPLETEDステータスにあるフレームバッチの数を確認します。 すべてのビデオのすべてのフレームバッチが完了すると、このチェックプロセスが完了します。
コレクターラムダ関数
コレクター関数は、コンシューマーステージ中に各フレームで実行された推論の出力を取得し、フレームバッチ全体およびビデオ全体でそれらを結合します。 結合されたマージされたデータは、S3バケットにアップロードされます。 次に、この関数は、特定のMLパイプラインに対してCortex後処理APIを呼び出して後処理計算を実行し、ビデオごとに集計された結果を出力バケットに追加します。 これらのメトリックの多くは、速度、加速度、関節角度などのフレーム全体で計算されるため、この計算は集約されたデータに対して実行する必要があります。 主な出力には、本文のキーポイントデータ(CSV形式に集約)、BMA計算(加速度など)、および画像ファイルの各フレームに追加されたキーポイントの視覚的なオーバーレイが含まれます。
スケーラブルなポーズ推定推論の生成
ML推論のスケーリングを強化する処理エンジンは、この段階で発生します。 これにはXNUMXつの主要な部分が含まれ、それぞれにレイテンシのトレードオフに合わせて調整できる独自の同時実行レバーがあります(次の図を参照)。
このアーキテクチャにより、遅延の増加をテストする実験が可能になり、アプリケーションにアクセスするエンドユーザーセグメントのさまざまな組み合わせによってワークロードが変化する可能性がある将来の柔軟性が得られます。
Kinesisデータストリーム
チームは、ストリーミングデータの処理に通常使用されるため、Kinesis Data Streamsを選択しました。この場合、スケーラビリティと並列化を提供するために同様の方法でフレームバッチを処理できるため、最適です。 Submitter Lambda関数では、KinesisBoto3クライアントが使用されます。 put_record
フレームバッチID、フレームバッチ開始フレーム、フレームバッチ終了フレーム、画像形状、フレームレート、ビデオIDなどの単一フレームバッチに関連付けられたメタデータを渡すメソッド。
さまざまなジョブキューとKinesisデータストリームの設定を定義して、さまざまなユーザーグループの優先度レベルに結びつくスループットのレベルを設定しました。 さまざまなレベルの処理能力へのアクセスは、を使用して新しいプロジェクトを作成するときにプロジェクトキューARNを渡すことによってリンクされます。 project
API。 すべてのユーザーグループは、ユーザーグループの作成中に特定のプロジェクトにリンクされます。 XNUMXつのデフォルトのストリーム構成が AWSサーバーレスアプリケーションモデル (AWS SAM)インフラストラクチャテンプレート:
- スタンダード –
JobStreamShardCount
- 優先 –
PriorityJobStreamShardCount
- 優先度が高い –
HighPriorityJobStreamShardCount
次の表に要約するように、チームはいくつかの異なるレバーを使用して、各ストリームの処理能力を区別したり、システムのレイテンシーを調整したりしました。
レバー | 説明 | デフォルト値 |
シャード | シャードはKinesisデータストリームにネイティブです。 これは、取り込みのスループットの基本単位です。 デフォルトは1MB/秒で、これは1,000秒あたりXNUMXデータレコードに相当します。 | 2 |
KinesisBatchSize |
KinesisDataStreamsがコンシューマーLambda関数を呼び出す前にXNUMXつのバッチで取得するレコードの最大数。 | 1 |
KinesisParallelizationFactor |
各シャードから同時に処理するバッチの数。 | 1 |
強化されたファンアウト | ファンアウトを強化したデータコンシューマーは、コンシューマー間でスループットを共有するのではなく、コンシューマーごとに専用の取り込みスループット(デフォルトの1MB /秒など)を使用します。 | オフ |
コンシューマーラムダ関数
Kinesis Data Streamsの観点から見ると、データコンシューマーは、データがストリームで生成されるときにデータストリームシャードからデータを取得するAWSサービスです。 このアプリケーションは、メッセージがデータストリームキューから渡されるときに呼び出されるConsumerLambda関数を使用します。 各コンシューマー関数は、次の手順を実行して3つのフレームバッチを処理します。 最初に、モデル推論パイプラインをホストするエンドポイントであるCortexプロセッサAPIが同期的に呼び出されます(詳細については、Cortexを使用したAmazon EKSに関する次のセクションを参照してください)。 結果はAmazonSXNUMXに保存され、処理されたフレームバッチのステータスを次のように変更することでデータベースが更新されます。 Complete
。 エラー処理は、再試行回数を504に設定して、Cortexクラスターからの5エラーを処理するための再試行ループでCortexAPI呼び出しを管理するために組み込まれています。
ML推論のためのCortexを使用したAmazonEKS
チームは、ML推論のコンピューティングエンジンとして、AWSのマネージドKubernetesサービスであるAmazonEKSを使用しました。 Amazon EKSを使用してMLエンドポイントをホストするように設計が選択され、AWSで完全に管理されているクラスターのオプションを使用してアップストリームKubernetesを柔軟に実行できるようになりました。 AWSファーゲート、またはオンプレミスハードウェア経由 Amazon EKS どこでも。 これは、Intel OTGが必要とする重要な機能であり、たとえば、このアプリケーションを専用のオンプレミスハードウェアに接続するオプションを提供していました。
推論パイプラインを構築するための構成要素である2つのMLモデルは、カスタムYoloモデル(オブジェクト検出用)、カスタムHRNetモデル(3Dポーズ推定用)、および3DMPPEモデル(XNUMXDポーズ推定用)でした(前を参照)詳細については、MLセクションを参照してください)。 彼らはオープンソースを使用しました 皮質 ML推論パイプラインエンドポイントのデプロイと管理、およびAmazonEKSクラスターの起動とデプロイを処理するライブラリ。 これらの各モデルはDockerコンテナにパッケージ化されました。モデルファイルはAmazonS3に保存され、モデルイメージはに保存されました。 Amazon エラスティック コンテナ レジストリ (Amazon ECR)-CortexRealtimeAPIとしてデプロイされます。 CPUとGPUで実行されるモデルコンテナのバージョンは、コンピューティングハードウェアのタイプに柔軟性を提供するために作成されました。 将来、追加のモデルまたはモデルパイプラインを追加する必要がある場合は、追加のCortexRealtimeAPIを作成するだけで済みます。
次に、CortexRealtimeモデルAPIをCortexRealtimeパイプラインAPIにまとめて、推論パイプラインを構築しました。 単一のリアルタイムパイプラインAPIは、一連のリアルタイムモデルAPIの呼び出しで構成されていました。 コンシューマーラムダ関数は pipeline
ブラックボックスとしてのAPI。単一のAPI呼び出しを使用して、画像の最終的な推論出力を取得します。 2つのパイプラインが作成されました。3DパイプラインとXNUMXDパイプラインです。
2Dパイプラインは、デコード前処理ステップ、アスリートの位置を特定してバウンディングボックスを生成するためのカスタムYoloモデルを使用したオブジェクト検出、そして最後にポーズ推定用の2Dキーポイントを作成するためのカスタムHRNetモデルを組み合わせたものです。
3Dパイプラインは、デコード前処理ステップ、カスタムYoloモデルを使用したオブジェクト検出を組み合わせてアスリートを特定し、バウンディングボックスを生成し、最後に3DMPPEモデルを組み合わせてポーズ推定用の3Dキーポイントを作成します。
フレームのバッチで推論を生成した後、各パイプラインには、XNUMXつの主要な出力を生成する個別の後処理RealtimeCortexエンドポイントも含まれます。
- 集約された本文のキーポイントデータを単一のCSVファイルに
- BMA計算(加速度など)
- 画像ファイルの各フレームに追加されたキーポイントの視覚的なオーバーレイ
Collector Lambda関数は、特定のビデオに関連付けられた適切なメタデータ(ポーズ推定推論出力のフレームIDやS3位置など)をエンドポイントに送信して、これらの後処理出力を生成します。
CortexはAmazonEKSと統合するように設計されており、クラスター構成ファイルと、Kubernetesクラスターを起動するための簡単なコマンドのみが必要です。
パフォーマンス調整のもう5つの手段は、計算クラスターのインスタンス構成でした。 M4インスタンスとG5dnインスタンスのさまざまな組み合わせで4つの層が作成され、クラスター名、リージョン、インスタンスの構成と組み合わせなどの仕様を持つ.yamlファイルとしてコード化されました。 MXNUMXインスタンスは低コストのCPUベースであり、GXNUMXdnは高コストのGPUベースであり、コストとパフォーマンスのトレードオフを提供します。
運用監視
運用ログ標準を維持するために、すべてのLambda関数には、ログを記録および取り込むためのコードが含まれています。 Amazon Kinesis データ ファイアホース。 たとえば、Submitter Lambda関数から処理されたすべてのフレームバッチは、タイムスタンプ、アクションの名前、Lambda関数の応答JSONとともにログに記録され、AmazonS3に保存されます。 次の図は、アーキテクチャのこのステップを示しています。
展開
デプロイは、AWSでサーバーレスアプリケーションを構築するためのオープンソースフレームワークであるAWSSAMを使用して処理されます。 AWS SAMを使用すると、関数、API、データベース、イベントソースマッピングなどのインフラストラクチャデザインをコード化して、新しいAWS環境に簡単にデプロイできます。 デプロイ中に、AWSSAM構文は次のように変換されます AWS CloudFormation インフラストラクチャのプロビジョニングを処理します。
A template.yaml
ファイルには、インフラストラクチャの仕様と、前のセクションで詳しく説明したKinesisDataStreamsレイテンシーレバーなどの調整可能なパラメーターが含まれています。 A samconfig.toml
ファイルには、スタック名、Lambda関数コードなどのアプリケーションファイルが保存されるS3バケット名、コストを追跡するためのリソースタグなどのデプロイパラメーターが含まれます。 テンプレート全体をビルドしてデプロイするために必要なのは、簡単なコマンドを使用したdeploy.shシェルスクリプトだけです。
ユーザーのワークフロー
要約すると、インフラストラクチャが展開された後、次のワークフローに従って開始できます。
- クライアントライブラリを使用してインテル3DATクライアントを作成します。
- APIを使用して、3Dポーズ推定用など、必要な処理のタイプに対応するパイプラインの新しいインスタンスを作成します。
- プロジェクトの新しいインスタンスを作成し、クラスターARNとKinesisキューARNを渡します。
- パイプラインパラメータセットの新しいインスタンスを作成します。
- パイプラインパラメータセットにマップするパイプラインパラメータの新しいインスタンスを作成します。
- プロジェクトIDとパイプラインパラメータセットIDに関連付けられた新しいユーザーグループを作成します。
- ユーザーグループに関連付けられている新しいユーザーを作成します。
- ジョブAPIのアップロード機能によって生成された事前署名されたS3URLを使用して、ビデオの.zipファイルをAmazonS3にアップロードします。
- を提出する
create_job
ビデオファイルの場所を指定するジョブパラメータを使用したAPI呼び出し。 これにより、処理ジョブが開始されます。
まとめ
これでアプリケーションはライブになり、アスリートとコーチの両方でテストできるようになりました。 インテルOTGは、コンピュータービジョンを使用した革新的なポーズ推定テクノロジーを、開発者からアスリート、ソフトウェアベンダーパートナーまで、さまざまなユーザーが利用できるようにすることに興奮しています。
AWSチームは、Intel OTGのようなお客様が、ML Solutions Labでのアイデアと発見の段階から、AWS ML ProServeでの強化と展開の段階まで、MLの旅を加速するのを支援することに情熱を注いでいます。 MLがスポーツで解き放つことができるすべての進歩を想像するために、私たちは皆、この夏の2021年の東京オリンピックを注意深く見守っています。
今日から始めましょう! この投稿や他の多くのサービスで言及されているサービスでユースケースを探索してください AWSマネジメントコンソール.
著者について
ハンマン カリフォルニア州サンディエゴを拠点とするAWSの機械学習とAIのシニアマネージャーです。 彼はノースウェスタン大学で工学の博士号を取得しており、製造、金融サービス、およびエネルギーのクライアントに助言する経営コンサルタントとして数年の経験があります。 現在、彼はさまざまな業界の顧客と熱心に協力して、AWSで機械学習とAIソリューションを開発および実装しています。 彼はNBAをフォローし、暇なときにバスケットボールをすることを楽しんでいます。
イマンカミヤビ AWSProfessionalServicesのMLエンジニアです。 彼は、AWSの幅広い顧客と協力して、再現性と信頼性の高いMLパイプラインをセットアップする際のベストプラクティスを支持してきました。
ジョナサンリー インテルのオリンピックテクノロジーグループのスポーツパフォーマンステクノロジーのディレクターです。 彼は、UCLAの学部生として、またオックスフォード大学の大学院で、機械学習の健康への応用を学びました。 彼のキャリアは、健康と人間のパフォーマンスのためのアルゴリズムとセンサーの開発に焦点を当ててきました。 彼は現在、Intelの3D AthleteTrackingプロジェクトを率いています。
ネルソン・レオン はIntelのSportsPerformance CoEのプラットフォームアーキテクトであり、アスリートのパフォーマンスを向上させる最先端の製品のエンドツーエンドアーキテクチャを定義しています。 彼はまた、これらの機械学習ソリューションの実装、展開、製品化をさまざまなインテルパートナーに大規模に主導しています。
トロイ・スクイラシ インテルのDecSecOpsエンジニアであり、DevOpsのベストプラクティスを通じて顧客にプロフェッショナルなソフトウェアソリューションを提供しています。 彼は、AIソリューションをさまざまなドメインのスケーラブルなプラットフォームに統合することを楽しんでいます。
ポールミン アマゾンウェブサービス(AWS)のアソシエイトソリューションアーキテクトインターンであり、さまざまな業界の顧客がミッションを推進し、クラウドの採用を加速するのを支援しています。 以前はIntelで、ソフトウェアエンジニアリングインターンとして3D Athlete TrackingCloudSDKの開発を支援していました。 仕事以外では、ポールはゴルフを楽しんでいて、歌っているのが聞こえます。
- コインスマート。 ヨーロッパで最高のビットコインと暗号通貨取引所。
- Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 出入り自由。
- CryptoHawk。 アルトコインレーダー。 無料トライアル。
- ソース:https://aws.amazon.com/blogs/machine-learning/the-intel3d-athlete-tracking-3dat-scalable-architecture-deploys-pose-estimation-models-using-amazon-kinesis-data-streams-および-amazon-eks/
- "
- &
- 000
- 100
- 2021
- 3d
- 私たちについて
- 加速する
- アクセス
- アクセス可能な
- 従った
- 越えて
- Action
- 行動
- 添加
- NEW
- 管理人
- 養子縁組
- AI
- アルゴリズム
- すべて
- Amazon
- Amazon Webサービス
- 間に
- API
- API
- 申し込み
- 適切な
- 建築
- 引数
- 割り当てられた
- 仲間
- アスリート
- 属性
- オートマチック
- AWS
- バックアップ
- バスケットボール
- 利点
- BEST
- ベストプラクティス
- ブラック
- ブログ
- ボディ
- ボックス
- ビルド
- 建物
- コール
- 容量
- これ
- キャリア
- 例
- 中央の
- チャンピオン
- 変化する
- 選択肢
- クライアント
- クラウド
- コード
- コレクション
- コレクタ
- 組み合わせた
- コンポーネント
- 計算
- コンピュータ
- 接続
- コンサルタント
- consumer
- 消費者
- コンテナ
- コンテナ
- 含まれています
- 続ける
- コントロール
- 調整する
- 基本
- 対応する
- 作ります
- 作成した
- 作成します。
- 作成
- 創造
- Credentials
- 重大な
- 重大な
- 電流プローブ
- 現在
- カスタム
- 顧客
- Customers
- 最先端
- データ
- データベース
- データベースを追加しました
- 中
- 専用の
- より深い
- 提供します
- 展開します
- 展開
- 展開
- 配備する
- 設計
- 設計
- 詳細
- 詳細な
- 細部
- 検出
- 開発する
- Developer
- 開発者
- 開発
- 異なります
- 区別する
- 直接
- 取締役
- 発見
- ディスプレイ
- デッカー
- そうではありません
- ドメイン
- ダウン
- 間に
- 簡単に
- エンドポイント
- エネルギー
- エンジン
- エンジニア
- エンジニアリング
- 環境
- イベント
- 例
- 興奮した
- 既存の
- 期待する
- 体験
- 探る
- 特徴
- 最後に
- ファイナンシャル
- 金融業務
- 名
- フィット
- 艦隊
- 柔軟性
- フレキシブル
- 焦点を当て
- フォロー中
- 次
- 形式でアーカイブしたプロジェクトを保存します.
- 将来を見据えた
- FRAME
- フレームワーク
- function
- 機能的な
- 機能性
- 機能
- 未来
- 生成する
- 生成
- 世代
- 与え
- 目標
- 良い
- GPU
- 卒業生
- グループ
- グループの
- ハンドル
- ハンドリング
- Hardware
- 健康
- 聞いた
- 助けます
- 助け
- ことができます
- こちら
- より高い
- 認定条件
- HTTPS
- 人間
- アイデンティティ
- 画像
- 実装する
- 実装
- 重要
- include
- 含ま
- 含めて
- 個人
- 産業
- 産業を変えます
- インフラ
- 革新的な
- インサート
- install
- 統合された
- 統合
- インテル
- インテリジェンス
- 相互作用
- インタフェース
- IT
- ジョブ
- Jobs > Create New Job
- 旅
- キー
- ラボ
- 起動する
- 発射
- リード
- 学習
- レベル
- 図書館
- LINE
- リスト
- ローディング
- 場所
- 場所
- 機械
- 機械学習
- 製
- 維持する
- 主要な
- 作る
- man
- 管理します
- マネージド
- 管理
- 製造業
- 地図
- マッピング
- 言及した
- メソッド
- メトリック
- 最小
- ミッション
- ML
- モバイル
- モバイルアプリ
- モデル
- モジュラー
- 他には?
- 最も
- の試合に
- 名
- NBA
- 必要
- ニーズ
- 数
- オリンピック
- 開きます
- 操作する
- 最適化
- オプション
- 注文
- その他
- 自分の
- オックスフォード
- パッケージ
- 部
- 特定の
- 特に
- パートナー
- 通過
- 情熱的な
- パターン
- 割合
- パフォーマンス
- 実行
- 視点
- ピース
- プラットフォーム
- プラットフォーム
- 再生
- 詩
- ポイント
- 可能
- 電力
- 強力な
- 準備
- 前
- 主要な
- 原則
- 優先順位
- プロセス
- ラボレーション
- 処理
- プロセッサ
- 作り出す
- 生産
- 製品
- プロ
- プロジェクト
- 提供します
- は、大阪で
- 目的
- 範囲
- Raw
- リアルタイム
- 認識する
- 記録
- 記録
- に対する
- 信頼性のある
- リクエスト
- 必要とする
- の提出が必要です
- 要件
- 必要
- リソースを追加する。
- リソース
- 応答
- 結果
- ラン
- ランニング
- 安全性
- サン
- スケーラビリティ
- ド電源のデ
- 規模
- スケーリング
- SDDK
- 安全に
- セグメント
- サーバレス
- サービス
- サービス
- セッションに
- 設定
- 形状
- シェアリング
- シェル(Shell)
- 示す
- 同様の
- 同様に
- 簡単な拡張で
- サイズ
- So
- ソフトウェア
- サービスとしてのソフトウェア
- ソフトウェア工学
- 溶液
- ソリューション
- 一部
- 誰か
- 専門の
- 仕様
- スピード
- スポーツ
- スタック
- ステージ
- 標準
- 規格
- start
- 開始
- 開始
- 都道府県
- 最先端の
- Status:
- ストレージ利用料
- 店舗
- 流れ
- ストリーミング
- 提出された
- 続いて
- 夏
- サポート
- サポート
- 取得
- チーム
- テクノロジー
- テスト
- したがって、
- 介して
- TIE
- 時間
- 今日
- 一緒に
- 東京
- 追跡する
- 追跡
- 一般的に
- UCLA
- 大学
- オックスフォード大学
- アンロック
- アップデイト
- つかいます
- users
- 活用
- 値
- 多様
- さまざまな
- 垂直
- ビデオ
- 動画
- ビジョン
- ウェブ
- Webサービス
- 誰
- 無し
- 仕事
- 働いていました
- ワーキング
- 年