HuggingFaceとAmazonSageMakerの非同期推論エンドポイントで価値の高い研究を改善する

AWS の顧客の多くは、調査、分析、ビジネス インテリジェンスをサービスとして提供しています。 この種の調査とビジネス インテリジェンスにより、最終顧客は市場や競合他社に先んじて成長の機会を特定し、問題に積極的に対処できるようになります。 たとえば、当社の金融サービス部門の顧客の中には、傾向を理解し、ポートフォリオ戦略を特定するために、株式、ヘッジファンド、投資管理会社の調査を行っている人もいます。 健康産業では、健康研究の大部分が情報に基づいて行われるようになりました。 多くの研究では、当初は診断、治療、またはその他の研究プロジェクトのために収集されたデータの分析が必要ですが、現在は新しい研究目的に使用されています。 これらの形式の健康研究は、新たな感染者を避けるための効果的な一次予防、早期発見のための二次予防、より適切な疾病管理のための予防につながりました。 研究成果は生活の質を向上させるだけでなく、医療費の削減にも役立ちます。

顧客は公的および私的なソースからの情報を消化する傾向があります。 次に、確立されたまたはカスタムの自然言語処理 (NLP) モデルを適用して傾向を要約および特定し、この情報に基づいて洞察を生成します。 この種の調査タスクに使用される NLP モデルは大規模なモデルを扱い、通常、コーパスのサイズと、現時点ではコストが最適化されていない専用のエンドポイントを考慮して要約する長い記事が含まれます。 これらのアプリケーションは、XNUMX 日のさまざまな時間帯に大量の受信トラフィックを受信します。

私たちは、ゼロまでスケールダウンし、必要に応じて推論機能を強化できる機能から、お客様が大きな恩恵を受けると信じています。 これにより、調査コストが最適化されますが、推論の品質には妥協しません。 この記事では、顔をハグする方法と、 アマゾンセージメーカー 非同期推論はこれを実現するのに役立ちます。

TensorFlow、PyTorch、Apache MXNet などの複数の深層学習フレームワークを使用してテキスト要約モデルを構築できます。 これらのモデルには通常、さまざまなサイズの複数のテキスト ドキュメントからなる大きな入力ペイロードがあります。 高度な深層学習モデルでは、モデル推論の前に計算集約型の前処理が必要です。 処理時間は数分に及ぶ場合があり、HTTP API 経由でペイロードを渡してリアルタイム推論を実行するオプションが削除されます。 代わりに、次のようなオブジェクト ストアからの入力ペイロードを非同期的に処理する必要があります。 Amazon シンプル ストレージ サービス (Amazon S3) 自動キューイングと事前定義された同時実行しきい値を備えています。 システムはステータス通知を受信し、タスクが完了したときにリソースをクリーンアップすることで不必要なコストを削減できる必要があります。

SageMaker は、ML 専用に構築された幅広い機能セットを統合することで、データ サイエンティストや開発者が高品質の機械学習 (ML) モデルを迅速に準備、構築、トレーニング、デプロイできるように支援します。 SageMaker は、XGBoost 用の最先端のオープンソース モデル提供コンテナを提供します (コンテナ, SDK）、Scikit-Learn（コンテナ, SDK）、PyTorch（コンテナ, SDK）、TensorFlow（コンテナ, SDK)、および Apache MXNet (コンテナ, SDK).

1. リアルタイム推論 エンドポイントは、ミリ秒から秒程度の低遅延要件で処理する必要があるワークロードに適しています。
2. バッチ変換 大量のデータバッチに対するオフライン予測に最適です。
3. AmazonSageMakerサーバーレス推論 (プレビュー モードであり、この記事の執筆時点では運用ワークロードには推奨されていません) は、ML モデルのデプロイとスケーリングを容易にする専用の推論オプションです。 サーバーレス推論は、トラフィックの急増の間にアイドル期間があり、コールド スタートを許容できるワークロードに最適です。
4. 非同期推論 エンドポイントは受信リクエストをキューに入れます。 これらは、リクエスト サイズが大きく (最大 1 GB)、推論処理時間が数分程度 (最大 15 分) であるワークロードに最適です。 非同期推論を使用すると、処理するリクエストがないときにインスタンス数をゼロに自動スケールすることでコストを節約できます。

ソリューションの概要

この投稿では、 ペガサスモデル これは、テキストの要約を行うために事前にトレーニングされています。 ハグ顔 〜へ SageMakerホスティングサービス。 簡単にするために、Hugging Face のモデルをそのまま使用します。 ただし、次のことができます。 カスタム データセットに基づいてモデルを微調整する。 で入手可能な他のモデルを試すこともできます フェイスモデルハブを抱き締める。 また、このモデルをホストする非同期推論エンドポイントもプロビジョニングされており、そこから予測を取得できます。

非同期推論エンドポイントの推論ハンドラーは、入力ペイロードとしてアーティクルを予期します。 記事の要約テキストが出力となります。 出力は傾向を分析するためにデータベースに保存されるか、さらなる分析のために下流に供給されます。 この下流分析により、研究に役立つデータの洞察が得られます。

非同期推論エンドポイントを使用して、ユーザー定義の同時実行性と完了通知をどのように実現できるかを示します。 エンドポイントの背後にあるインスタンスの自動スケーリングを、トラフィックが収まるとゼロにスケールダウンし、リクエスト キューがいっぱいになるとスケールアップするように構成します。

私達はまた使用します アマゾンクラウドウォッチ キューのサイズ、合計処理時間、処理された呼び出しを監視するメトリクス。

次の図は、非同期推論エンドポイントを使用して推論を実行する際に必要な手順を示しています。

1. 私たちの事前トレーニング済み PEGASUS ML モデルは、まずスケーリング エンドポイントでホストされます。
2. ユーザーは、要約する記事を入力 S3 バケットにアップロードします。
3. 非同期推論エンドポイントは、API を使用して呼び出されます。
4. 推論が完了すると、結果は出力 S3 バケットに保存されます。
5. An Amazon シンプル通知サービス (Amazon SNS) 通知がユーザーに送信され、完了した成功または失敗が通知されます。

非同期推論エンドポイントを作成する

リアルタイムのホスト型エンドポイントと同様の非同期推論エンドポイントを作成します。 この手順には、SageMaker モデルの作成、その後のエンドポイントの構成、およびエンドポイントのデプロイが含まれます。 XNUMX 種類のエンドポイントの違いは、非同期推論エンドポイント構成に AsyncInferenceConfig セクション。 ここでは、エンドポイント呼び出しの結果の S3 出力パスを指定し、オプションで成功と失敗の通知用の SNS トピックを含めます。 また、お客様が決定したインスタンスごとの同時呼び出しの最大数も指定します。 次のコードを参照してください。

AsyncInferenceConfig={ "OutputConfig": { "S3OutputPath": f"s3://{bucket}/{bucket_prefix}/output", # Optionally specify Amazon SNS topics for notifications "NotificationConfig": { "SuccessTopic": success_topic, "ErrorTopic": error_topic, } }, "ClientConfig": { "MaxConcurrentInvocationsPerInstance": 2 #increase this value up to throughput peak for ideal performance } }

非同期推論用のエンドポイント構成を作成する API の詳細については、を参照してください。 非同期推論エンドポイントを作成する.

非同期推論エンドポイントを呼び出す

次のスクリーンショットは、入力ペイロードとして使用する短い記事を示しています。

次のコードは記事を input.json Amazon S3 にファイルを送信します。

sm_session.upload_data( input_location, bucket=sm_session.default_bucket(), key_prefix=prefix, extra_args={"ContentType": "text/plain"})

Amazon S3 URI を入力ペイロード ファイルに使用して、エンドポイントを呼び出します。 応答オブジェクトには、完了後に結果を取得するための Amazon S3 内の出力場所が含まれています。

response = sm_runtime.invoke_endpoint_async(EndpointName=endpoint_name, InputLocation=input_1_s3_location)
output_location = response['OutputLocation']

次のスクリーンショットは、要約後のサンプル出力を示しています。

非同期推論エンドポイントを呼び出す API の詳細については、「」を参照してください。 非同期推論エンドポイントの呼び出し.

ユーザー定義の同時実行性を使用して呼び出しリクエストをキューに入れる

非同期推論エンドポイントは、呼び出しリクエストを自動的にキューに入れます。 これは、さまざまな監視メトリックを備えた完全に管理されたキューであり、追加の構成は必要ありません。 それは、 MaxConcurrentInvocationsPerInstance 前のエンドポイント設定のパラメータを使用して、前のリクエストが完了した後にキューからの新しいリクエストを処理します。 MaxConcurrentInvocationsPerInstance SageMaker クライアントによってモデルコンテナに送信される同時リクエストの最大数です。 値が指定されていない場合、SageMaker は最適な値を選択します。

非同期推論エンドポイント内の自動スケーリングインスタンス

最小容量が XNUMX、最大容量が XNUMX つのインスタンスで自動スケーリング ポリシーを設定します。 リアルタイムのホスト型エンドポイントとは異なり、非同期推論エンドポイントは、最小容量をゼロに設定することで、インスタンスをゼロにスケールダウンすることをサポートします。 私たちが使用するのは、 ApproximateBacklogSizePerInstance さらにスケールアウトするために、インスタンスあたり XNUMX つのターゲット キュー バックログを持つスケーリング ポリシー構成のメトリック。 クールダウン期間を設定します ScaleInCooldown 120秒まで ScaleOutCooldown 120秒まで。 の値 ApproximateBacklogSizePerInstance トラフィックとスケーリング速度に対する感度に基づいて選択されます。 スケールインが速いほど、発生するコストは少なくなりますが、新しいリクエストが届いたときに再度スケールアップしなければならない可能性が高くなります。スケールインが遅いほど、発生するコストは増加しますが、コストが発生する可能性は低くなります。スケールが不足しているときにリクエストが届きます。

client = boto3.client('application-autoscaling') # Common class representing Application Auto Scaling for SageMaker amongst other services resource_id='endpoint/' + endpoint_name + '/variant/' + 'variant1' # This is the format in which application autoscaling references the endpoint response = client.register_scalable_target(
ServiceNamespace='sagemaker', #
ResourceId=resource_id,
ScalableDimension='sagemaker:variant:DesiredInstanceCount',
MinCapacity=0,
MaxCapacity=5
) response = client.put_scaling_policy(
PolicyName='Invocations-ScalingPolicy',
ServiceNamespace='sagemaker', # The namespace of the AWS service that provides the resource.
ResourceId=resource_id, # Endpoint name
ScalableDimension='sagemaker:variant:DesiredInstanceCount', # SageMaker supports only Instance Count
PolicyType='TargetTrackingScaling', # 'StepScaling'|'TargetTrackingScaling'
TargetTrackingScalingPolicyConfiguration={ 'TargetValue': 5.0, # The target value for the metric. 'CustomizedMetricSpecification': { 'MetricName': 'ApproximateBacklogSizePerInstance', 'Namespace': 'AWS/SageMaker', 'Dimensions': [{'Name': 'EndpointName', 'Value': endpoint_name }], 'Statistic': 'Average',
}, 'ScaleInCooldown': 120, # ScaleInCooldown - The amount of time, in seconds, after a scale-in activity completes before another scale in activity can start. 'ScaleOutCooldown': 120 # ScaleOutCooldown - The amount of time, in seconds, after a scale-out activity completes before another scale out activity can start.
# 'DisableScaleIn': True|False - indicates whether scale in by the target tracking policy is disabled.
# If the value is true, scale-in is disabled and the target tracking policy won't remove capacity from the scalable resource.
}
)

非同期推論エンドポイントを自動スケールする API の詳細については、 非同期推論エンドポイントの自動スケール.

非同期推論エンドポイントからの通知を構成する

各エンドポイント呼び出し結果の成功通知とエラー通知用に XNUMX つの別個の SNS トピックを作成します。

sns_client = boto3.client('sns')
response = sns_client.create_topic(Name="Async-Demo-ErrorTopic2")
error_topic = response['TopicArn']
response = sns_client.create_topic(Name="Async-Demo-SuccessTopic2")
success_topic = response['TopicArn']

通知のその他のオプションには、S3 バケットの出力を定期的にチェックすることや、S3 バケット通知を使用してバケットを初期化することなどがあります。 AWSラムダ ファイルアップロード時の機能。 前述したように、SNS 通知はエンドポイント構成セクションに含まれています。

非同期推論エンドポイントからの通知を設定する方法の詳細については、「」を参照してください。 予測結果を確認する.

非同期推論エンドポイントを監視する

非同期推論に固有の組み込みの追加 CloudWatch メトリクスを使用して、非同期推論エンドポイントを監視します。 たとえば、各インスタンスのキューの長さを次のように監視します。 ApproximateBacklogSizePerInstance および合計キュー長 ApproximateBacklogSize.

メトリクスの完全なリストについては、以下を参照してください。 非同期推論エンドポイントのモニタリング.

エンドポイント構成を最適化して、最もコスト効率が高く、パフォーマンスの高いインスタンスを取得できます。 たとえば、Amazon Elastic Inference または AWS Inferentia でインスタンスを使用できます。 他のモデル サーバーとコンテナーのパラメーターを調整しながら、同時実行レベルをスループットのピークまで徐々に高めることもできます。

CloudWatch グラフ

前のセクションで説明した自動スケーリング ポリシーを有効にした非同期推論エンドポイントに、一定期間にわたって流入する 10,000 の推論リクエストのトラフィックをシミュレートしました。

次のスクリーンショットは、リクエストが流入し始める前のインスタンス メトリクスを示しています。インスタンスが実行されていないライブ エンドポイントから始めます。

次のグラフは、 BacklogSize & BacklogSizePerInstance 自動スケーリングが開始され、エンドポイントの負荷が自動スケーリング プロセスの一部としてプロビジョニングされた複数のインスタンスによって共有されると、メトリクスが変化します。

次のスクリーンショットに示すように、推論数がスケールアップするにつれてインスタンスの数も増加しました。

次のスクリーンショットは、スケールインによってエンドポイントが実行インスタンスゼロの初期状態にどのように戻されるかを示しています。

クリーンアップ

すべてのリクエストが完了したら、リアルタイムでホストされているエンドポイントを削除する場合と同様に、エンドポイントを削除できます。 非同期推論エンドポイントの最小容量をゼロに設定した場合、ゼロにスケールダウンした後はインスタンス料金は発生しないことに注意してください。

エンドポイントの自動スケーリングを有効にした場合は、エンドポイントを削除する前に、必ずエンドポイントをスケーラブルなターゲットとして登録解除してください。 これを行うには、次のコードを実行します。

response = client.deregister_scalable_target(ServiceNamespace='sagemaker',ResourceId='resource_id',ScalableDimension='sagemaker:variant:DesiredInstanceCount')

このデモで使用したインスタンスに対して料金が発生するため、使用後は必ずエンドポイントを削除してください。

sm_client.delete_endpoint(EndpointName=endpoint_name)

S3 オブジェクトと SNS トピックも削除する必要があります。 SNS 通知を使用してアクションを実行するために他の AWS リソースを作成した場合は、それらを削除することもできます。

まとめ

この投稿では、SageMaker の新しい非同期推論機能を使用して、要約タスクの一部である一般的な大規模な入力ペイロードを処理する方法を示しました。 推論には、Hugging Face のモデルを使用し、それを非同期推論エンドポイントにデプロイしました。 研究分析に伴うバースト トラフィック、高いモデル処理時間、大きなペイロードといった一般的な課題について説明しました。 内部キュー、事前定義された同時実行制限を管理し、応答通知を構成し、自動的にゼロにスケールダウンする非同期推論エンドポイントの固有の機能は、これらの課題に対処するのに役立ちました。 この例の完全なコードは、次の場所で入手できます。 GitHubの.

SageMaker 非同期推論を開始するには、以下を確認してください。 非同期推論.

著者について

ディネシュ・クマール・スブラマニ は、スコットランドのエジンバラを拠点とするUKIRSMBチームのシニアソリューションアーキテクトです。 彼は人工知能と機械学習を専門としています。 Dineshは、さまざまな業界のお客様と協力して、AWSサービスに関する問題の解決を支援することを楽しんでいます。 仕事以外では、家族と過ごしたり、チェスをしたり、ジャンルを超えて音楽を楽しんだりするのが大好きです。

ラグーラメシャ Amazon SageMaker サービスチームの ML ソリューションアーキテクトです。 彼は、顧客が ML 本番ワークロードを大規模に構築、デプロイし、SageMaker に移行できるよう支援することに重点を置いています。 彼は機械学習、AI、コンピューター ビジョンの分野を専門とし、テキサス大学ダラス校でコンピューター サイエンスの修士号を取得しています。 自由時間には、旅行や写真撮影を楽しんでいます。

• コインスマート。 ヨーロッパで最高のビットコインと暗号通貨取引所。
• Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 出入り自由。
• CryptoHawk。 アルトコインレーダー。 無料トライアル。
• 出典: https://aws.amazon.com/blogs/machine-learning/improve-high-value-research-with-hugging-face-and-amazon-sagemaker-asynchronous-inference-endpoints/