翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
独自の推論コンテナを適応させる
ビルド済みの Docker イメージを使用する SageMaker Amazon SageMaker にリストされているどのイメージもユースケースに使用できない場合は、独自の Docker コンテナを構築し、 SageMaker その内部でトレーニングや推論に使用できます。と互換性を持たせるには SageMaker、コンテナに以下の特性が必要です。
-
コンテナのポートにはウェブサーバーのリストが必要です
8080
。 -
コンテナは、
POST
/invocations
/ping
およびリアルタイムエンドポイントへのリクエストを受け入れる必要があります。これらのエンドポイントに送信するリクエストは 60 秒以内に返され、最大サイズは 6 MB でなければなりません。
トレーニングや推論用に独自の Docker コンテナを構築する方法の詳細と例については SageMaker、「独自のアルゴリズムコンテナの構築
以下のガイドでは、Amazon SageMaker Studio Classic JupyterLab
SageMaker でスペースを使用して推論コンテナをホスティングと連携させる方法を示しています。この例では、NGINXGunicornPythonウェブサーバーをウェブサーバーゲートウェイインターフェイスとして、Flaskまたウェブアプリケーションフレームワークとして使用しています。前述の要件を満たしていれば、さまざまなアプリケーションを使用してコンテナを調整できます。独自の推論コードを使用する方法の詳細については、を参照してくださいホスティングサービスでの独自の推論コードの使用。
推論コンテナを適合させてください。
以下の手順に従って、 SageMaker 独自の推論コンテナをホスティングと連携するように調整してください。以下の手順で示す例では、Python
および以下用の SpacY
-
A Dockerfile を使用してモデルを含むコンテナを作成します。NER
-
NERモデルを提供する推論スクリプト。
この例をユースケースに合わせる場合は、Dockerfileモデルのデプロイと提供に必要なおよび推論スクリプトを使用する必要があります。
-
Amazon JupyterLab SageMaker スタジオクラシックでスペースを作成 (オプション)。
どのノートブックでもスクリプトを実行して、 SageMaker 推論コンテナをホスティングに適応させることができます。この例は、Amazon SageMaker Studio Classic JupyterLab 内のスペースを使用して、JupyterLab SageMakerディストリビューションイメージが付属するアプリケーションを起動する方法を示しています。詳細については、「SageMaker JupyterLab」を参照してください。
-
Dockerファイルと推論スクリプトをアップロードします。
-
ホームディレクトリに新しいフォルダーを作成します。を使用している場合はJupyterLab、左上隅にある「新規フォルダ」アイコンを選択し、を格納するフォルダ名を入力します。Dockerfileこの例では、フォルダーはという名前です。
docker_test_folder
-
Dockerfileテキストファイルを新しいフォルダーにアップロードします。以下は、SpacY
から事前にトレーニングされた Named Entity Recognition (NER) モデル、サンプルを実行するのに必要なアプリケーション、Docker環境変数を含むコンテナーを作成する例ですDockerfile 。 FROM python:3.8 RUN apt-get -y update && apt-get install -y --no-install-recommends \ wget \ python3 \ nginx \ ca-certificates \ && rm -rf /var/lib/apt/lists/* RUN wget https://bootstrap.pypa.io/get-pip.py && python3 get-pip.py && \ pip install flask gevent gunicorn && \ rm -rf /root/.cache #pre-trained model package installation RUN pip install spacy RUN python -m spacy download en # Set environment variables ENV PYTHONUNBUFFERED=TRUE ENV PYTHONDONTWRITEBYTECODE=TRUE ENV PATH="/opt/program:${PATH}" COPY NER /opt/program WORKDIR /opt/program
前のコード例では、
PYTHONUNBUFFERED
Python環境変数は標準出力ストリームをバッファリングしないため、ユーザーへのログの配信が速くなります。PYTHONDONTWRITEBYTECODE
環境変数は、Python.pyc
このユースケースでは不要なコンパイル済みバイトコードファイルを書き込まないようにします。PATH
環境変数は、コンテナが呼び出されたときに、train
serve
およびプログラムの場所を特定するために使用されます。 -
新しいフォルダー内に、モデルを提供するスクリプトを格納する新しいディレクトリを作成します。この例では
NER
、というディレクトリを使用します。このディレクトリには、この例を実行するのに必要な以下のスクリプトが含まれています。-
predictor.py
— Python モデルを読み込んで推論を実行するロジックを含むスクリプト。 -
nginx.conf
— Web サーバーを構成するスクリプト。 -
serve
— 推論サーバーを起動するスクリプト。 -
wsgi.py
— モデルを提供するヘルパースクリプト。
重要
.ipynb
推論スクリプトを末尾ががのノートブックにコピーして名前を変更すると、スクリプトにエンドポイントがデプロイされないようにするフォーマット文字が含まれている可能性があります。代わりに、テキストファイルを作成して名前を変更してください。 -
-
スクリプトをアップロードして、モデルを推論できるようにしてください。以下は、
predictor.py
Flask/ping
/invocations
とエンドポイントを提供するために使用するというスクリプトの例です。from flask import Flask import flask import spacy import os import json import logging #Load in model nlp = spacy.load('en_core_web_sm') #If you plan to use a your own model artifacts, #your model artifacts should be stored in /opt/ml/model/ # The flask app for serving predictions app = Flask(__name__) @app.route('/ping', methods=['GET']) def ping(): # Check if the classifier was loaded correctly health = nlp is not None status = 200 if health else 404 return flask.Response(response= '\n', status=status, mimetype='application/json') @app.route('/invocations', methods=['POST']) def transformation(): #Process input input_json = flask.request.get_json() resp = input_json['input'] #NER doc = nlp(resp) entities = [(X.text, X.label_) for X in doc.ents] # Transform predictions to JSON result = { 'output': entities } resultjson = json.dumps(result) return flask.Response(response=resultjson, status=200, mimetype='application/json')
/ping
前のスクリプト例のエンドポイントは、200
モデルが正しくロードされたかどうか、404
モデルが正しくロードされていないかどうかを示すステータスコードを返します。/invocations
エンドポイントはJSON、でフォーマットされたリクエストを処理し、入力フィールドを抽出し、NERモデルを使用してエンティティを識別して変数エンティティに格納します。Flaskアプリケーションはこれらのエンティティを含むレスポンスを返します。これらの必須ヘルスリクエストの詳細については、を参照してくださいコンテナがヘルスチェック (Ping) リクエストに応答する方法。 -
推論サーバーを起動するスクリプトをアップロードします。以下のスクリプト例では、
serve
Gunicornをアプリケーションサーバーとして、および Web Nginx サーバーとしてを呼び出します。#!/usr/bin/env python # This file implements the scoring service shell. You don't necessarily need to modify it for various # algorithms. It starts nginx and gunicorn with the correct configurations and then simply waits until # gunicorn exits. # # The flask server is specified to be the app object in wsgi.py # # We set the following parameters: # # Parameter Environment Variable Default Value # --------- -------------------- ------------- # number of workers MODEL_SERVER_WORKERS the number of CPU cores # timeout MODEL_SERVER_TIMEOUT 60 seconds import multiprocessing import os import signal import subprocess import sys cpu_count = multiprocessing.cpu_count() model_server_timeout = os.environ.get('MODEL_SERVER_TIMEOUT', 60) model_server_workers = int(os.environ.get('MODEL_SERVER_WORKERS', cpu_count)) def sigterm_handler(nginx_pid, gunicorn_pid): try: os.kill(nginx_pid, signal.SIGQUIT) except OSError: pass try: os.kill(gunicorn_pid, signal.SIGTERM) except OSError: pass sys.exit(0) def start_server(): print('Starting the inference server with {} workers.'.format(model_server_workers)) # link the log streams to stdout/err so they will be logged to the container logs subprocess.check_call(['ln', '-sf', '/dev/stdout', '/var/log/nginx/access.log']) subprocess.check_call(['ln', '-sf', '/dev/stderr', '/var/log/nginx/error.log']) nginx = subprocess.Popen(['nginx', '-c', '/opt/program/nginx.conf']) gunicorn = subprocess.Popen(['gunicorn', '--timeout', str(model_server_timeout), '-k', 'sync', '-b', 'unix:/tmp/gunicorn.sock', '-w', str(model_server_workers), 'wsgi:app']) signal.signal(signal.SIGTERM, lambda a, b: sigterm_handler(nginx.pid, gunicorn.pid)) # Exit the inference server upon exit of either subprocess pids = set([nginx.pid, gunicorn.pid]) while True: pid, _ = os.wait() if pid in pids: break sigterm_handler(nginx.pid, gunicorn.pid) print('Inference server exiting') # The main routine to invoke the start function. if __name__ == '__main__': start_server()
前述のスクリプト例では
sigterm_handler
、NginxGunicornシグナルを受信するととサブプロセスをシャットダウンするシグナルハンドラー関数を定義しています。SIGTERM
start_server
関数はシグナルハンドラーを起動し、NginxGunicornおよびサブプロセスを開始および監視し、ログストリームをキャプチャします。 -
Web サーバーを設定するスクリプトをアップロードします。以下のスクリプト例は
nginx.conf
、Gunicornをアプリケーションサーバーとして使用して、Nginx推論用のモデルを提供するウェブサーバーを構成します。worker_processes 1; daemon off; # Prevent forking pid /tmp/nginx.pid; error_log /var/log/nginx/error.log; events { # defaults } http { include /etc/nginx/mime.types; default_type application/octet-stream; access_log /var/log/nginx/access.log combined; upstream gunicorn { server unix:/tmp/gunicorn.sock; } server { listen 8080 deferred; client_max_body_size 5m; keepalive_timeout 5; proxy_read_timeout 1200s; location ~ ^/(ping|invocations) { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://gunicorn; } location / { return 404 "{}"; } } }
前述のスクリプト例では、Nginxフォアグラウンドで実行するように設定し、をキャプチャする場所を設定し
error_log
、upstream
Gunicornサーバーのソケットソケットとして定義しています。サーバーは、ポートでリッスンするようにサーバーブロックを設定し8080
、クライアントのリクエスト本文のサイズとタイムアウト値に制限を設定します。サーバーブロックは、/ping
/invocations
またはパスを含むリクエストをに転送しGunicornserver http://gunicorn
、404
他のパスにはエラーを返します。 -
モデルの提供に必要な他のスクリプトをアップロードします。この例では、
wsgi.py
Gunicornアプリケーションを見つけるのに役立つ以下のサンプルスクリプトが必要です。import predictor as myapp # This is just a simple wrapper for gunicorn to find your app. # If you want to change the algorithm file, simply change "predictor" above to the # new file. app = myapp.app
このフォルダから
docker_test_folder
、Dockerfileディレクトリ構造にはとというフォルダが含まれているはずですNER。NERwsgi.py
フォルダには次のようなファイルnginx.conf
、predictor.py
、serve
、が含まれているはずです。 -
-
独自のコンテナを構築してください。
docker_test_folder
Dockerフォルダーからコンテナーをビルドします。以下のコマンド例は、Dockerで設定されているコンテナをビルドしますDockerfile。! docker build -t byo-container-test .
前のコマンドは、
byo-container-test
現在の作業ディレクトリにという名前のコンテナを構築します。Dockerビルドパラメーターについて詳しくは、「ビルド引数」を参照してください。 注記
Dockerが見つからないという次のエラー・メッセージが表示された場合はDockerfile、Dockerfileの名前が正しいことと、ディレクトリに保存されていることを確認してください。
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/ec2-user/SageMaker/docker_test_folder/Dockerfile: no such file or directory
Docker現在のディレクトリ内で、Dockerfile拡張子なしで特別に呼び出されたファイルを探します。別の名前を付けた場合は、-f フラグを使用してファイル名を手動で渡すことができます。たとえば、Dockerfile as という名前を付けた場合はDockerfile-text.txt、Docker
-f
次のようにフラグの後にファイルを指定してコンテナを構築します。! docker build -t byo-container-test -f Dockerfile-text.txt .
-
Amazon Elastic Container Registry (Amazon ECR) Docker にイメージをプッシュする
Dockerノートブックセル内のイメージを ECR にプッシュします。以下のコード例は、コンテナーをローカルでビルドし、ログインして ECR にプッシュする方法を示しています。
%%sh # Name of algo -> ECR algorithm_name=sm-pretrained-spacy #make serve executable chmod +x NER/serve account=$(aws sts get-caller-identity --query Account --output text) # Region, defaults to us-west-2 region=$(aws configure get region) region=${region:-us-east-1} fullname="${account}.dkr.ecr.${region}.amazonaws.com/${algorithm_name}:latest" # If the repository doesn't exist in ECR, create it. aws ecr describe-repositories --repository-names "${algorithm_name}" > /dev/null 2>&1 if [ $? -ne 0 ] then aws ecr create-repository --repository-name "${algorithm_name}" > /dev/nullfi # Get the login command from ECR and execute it directly aws ecr get-login-password --region ${region}|docker login --username AWS --password-stdin ${fullname} # Build the docker image locally with the image name and then push it to ECR # with the full name. docker build -t ${algorithm_name} . docker tag ${algorithm_name} ${fullname} docker push ${fullname}
前の例では、サンプルの Docker コンテナを ECR にプッシュするのに必要な以下のステップを実行する方法を示しています。
-
アルゴリズム名をとして定義します。
sm-pretrained-spacy
-
serve
NERフォルダー内のファイルを実行可能にします。 -
を設定します AWS リージョン。
-
ECR がまだ存在しない場合は作成します。
-
ECR にログインします。
-
Dockerコンテナをローカルでビルドします。
-
Dockerイメージを ECR にプッシュします。
-
-
クライアントをセットアップします。 SageMaker
SageMaker ホスティングサービスを推論に使用したい場合は、モデルを作成し
、エンドポイント設定を作成し、エンドポイントを作成する必要があります 。エンドポイントから推論を取得するには、 SageMaker boto3 Runtime クライアントを使用してエンドポイントを呼び出します。次のコードは、SageMaker boto3 クライアントを使用してクライアントと SageMaker Runtime SageMaker クライアントの両方を設定する方法を示しています。 import boto3 from sagemaker import get_execution_role sm_client = boto3.client(service_name='sagemaker') runtime_sm_client = boto3.client(service_name='sagemaker-runtime') account_id = boto3.client('sts').get_caller_identity()['Account'] region = boto3.Session().region_name #used to store model artifacts which SageMaker will extract to /opt/ml/model in the container, #in this example case we will not be making use of S3 to store the model artifacts #s3_bucket = '<S3Bucket>' role = get_execution_role()
前のコード例では、Amazon S3 バケットは使用されていませんが、モデルアーティファクトの保存方法を示すコメントとして挿入されています。
前のコード例を実行した後でアクセス権限エラーが発生した場合は、IAM ロールにアクセス権限を追加する必要がある場合があります。IAM ロールの詳細については、「Amazon SageMaker ロールマネージャー」を参照してください。現在のロールにアクセス権限を追加する方法の詳細については、「」を参照してくださいAWS Amazon 管理ポリシー SageMaker。
-
モデルを作成します。
SageMaker 推論にホスティングサービスを使用する場合は、 SageMakerでモデルを作成する必要があります。以下のコード例は、spaCyNER内部でモデルを作成する方法を示しています。 SageMaker
from time import gmtime, strftime model_name = 'spacy-nermodel-' + strftime("%Y-%m-%d-%H-%M-%S", gmtime()) # MODEL S3 URL containing model atrifacts as either model.tar.gz or extracted artifacts. # Here we are not #model_url = 's3://{}/spacy/'.format(s3_bucket) container = '{}.dkr.ecr.{}.amazonaws.com/sm-pretrained-spacy:latest'.format(account_id, region) instance_type = 'ml.c5d.18xlarge' print('Model name: ' + model_name) #print('Model data Url: ' + model_url) print('Container image: ' + container) container = { 'Image': container } create_model_response = sm_client.create_model( ModelName = model_name, ExecutionRoleArn = role, Containers = [container]) print("Model Arn: " + create_model_response['ModelArn'])
前のコード例は、ステップ 5 のコメントにある Amazon S3
model_url
s3_bucket
バケットを使用する場合を使用してを定義する方法を示し、コンテナイメージの ECR URI を定義しています。前のコード例では、ml.c5d.18xlarge
をインスタンスタイプとして定義しています。別のインスタンスタイプを選択することもできます。使用可能なインスタンスタイプの詳細については、Amazon EC2 インスタンスタイプを参照してください。 前のコード例では、
Image
キーはコンテナイメージの URI を指しています。create_model_response
この定義では、を使用してモデルを作成し、モデル名、ロール、およびコンテナ情報を含むリストを返します。create_model method
前のスクリプトの出力例は次のとおりです。
Model name: spacy-nermodel-YYYY-MM-DD-HH-MM-SS Model data Url: s3://spacy-sagemaker-us-east-1-bucket/spacy/ Container image: 123456789012.dkr.ecr.us-east-2.amazonaws.com/sm-pretrained-spacy:latest Model Arn: arn:aws:sagemaker:us-east-2:123456789012:model/spacy-nermodel-YYYY-MM-DD-HH-MM-SS
-
-
エンドポイントの設定と作成
SageMaker ホスティングを推論に使用するには、エンドポイントを設定して作成する必要もあります。 SageMaker このエンドポイントを推論に使用します。以下の設定例は、以前に定義したインスタンスタイプとモデル名を使用してエンドポイントを生成して設定する方法を示しています。
endpoint_config_name = 'spacy-ner-config' + strftime("%Y-%m-%d-%H-%M-%S", gmtime()) print('Endpoint config name: ' + endpoint_config_name) create_endpoint_config_response = sm_client.create_endpoint_config( EndpointConfigName = endpoint_config_name, ProductionVariants=[{ 'InstanceType': instance_type, 'InitialInstanceCount': 1, 'InitialVariantWeight': 1, 'ModelName': model_name, 'VariantName': 'AllTraffic'}]) print("Endpoint config Arn: " + create_endpoint_config_response['EndpointConfigArn'])
前の設定例では、
create_endpoint_config_response
model_name
endpoint_config_name
をタイムスタンプ付きで作成された一意のエンドポイント設定名に関連付けます。前のスクリプトの出力例は次のとおりです。
Endpoint config name: spacy-ner-configYYYY-MM-DD-HH-MM-SS Endpoint config Arn: arn:aws:sagemaker:us-east-2:123456789012:endpoint-config/spacy-ner-config-MM-DD-HH-MM-SS
エンドポイントエラーの詳細については、「エンドポイントを作成または更新したときに Amazon SageMaker エンドポイントが失敗状態になるのはなぜですか?
」を参照してください。 -
エンドポイントを作成し、エンドポイントが稼働するまで待ちます。
次のコード例では、前の設定例の構成を使用してエンドポイントを作成し、モデルをデプロイします。
%%time import time endpoint_name = 'spacy-ner-endpoint' + strftime("%Y-%m-%d-%H-%M-%S", gmtime()) print('Endpoint name: ' + endpoint_name) create_endpoint_response = sm_client.create_endpoint( EndpointName=endpoint_name, EndpointConfigName=endpoint_config_name) print('Endpoint Arn: ' + create_endpoint_response['EndpointArn']) resp = sm_client.describe_endpoint(EndpointName=endpoint_name) status = resp['EndpointStatus'] print("Endpoint Status: " + status) print('Waiting for {} endpoint to be in service...'.format(endpoint_name)) waiter = sm_client.get_waiter('endpoint_in_service') waiter.wait(EndpointName=endpoint_name)
前のコード例では、
create_endpoint
メソッドは前のコード例で作成した生成されたエンドポイント名でエンドポイントを作成し、エンドポイントの Amazon リソースネームを出力します。describe_endpoint
このメソッドは、エンドポイントとそのステータスに関する情報を返します。 SageMaker ウェイターはエンドポイントが稼働するまで待ちます。
-
-
エンドポイントをテストします。
エンドポイントが稼働したら、エンドポイントに呼び出しリクエストを送信します
。以下のコード例は、エンドポイントにテストリクエストを送信する方法を示しています。 import json content_type = "application/json" request_body = {"input": "This is a test with NER in America with \ Amazon and Microsoft in Seattle, writing random stuff."} #Serialize data for endpoint #data = json.loads(json.dumps(request_body)) payload = json.dumps(request_body) #Endpoint invocation response = runtime_sm_client.invoke_endpoint( EndpointName=endpoint_name, ContentType=content_type, Body=payload) #Parse results result = json.loads(response['Body'].read().decode())['output'] result
前のコード例では、メソッドはを JSON
json.dumps
request_body
形式の文字列にシリアル化し、変数ペイロードに保存しています。次に、 SageMaker ランタイムクライアントは invoke endpointメソッドを使用してペイロードをエンドポイントに送信します。結果には、出力フィールドを抽出した後のエンドポイントからの応答が含まれます。 前述のコード例では、次の出力が返されるはずです。
[['NER', 'ORG'], ['America', 'GPE'], ['Amazon', 'ORG'], ['Microsoft', 'ORG'], ['Seattle', 'GPE']]
-
エンドポイントを削除します。
呼び出しが完了したら、リソースを節約するためにエンドポイントを削除します。以下のコード例は、エンドポイントを削除する方法を示しています。
sm_client.delete_endpoint(EndpointName=endpoint_name) sm_client.delete_endpoint_config(EndpointConfigName=endpoint_config_name) sm_client.delete_model(ModelName=model_name)
この例のコードを含む完全なノートブックについては、「BYOC-Single-Model
」を参照してください。
コンテナ・デプロイメントのトラブルシューティング
エンドポイントがデプロイされなかった場合は、次のように Amazon CloudWatch イベントログを確認してください。
-
https://console.aws.amazon.com/sagemaker/
SageMaker コンソールのナビゲーションペインから [推論] を選択します。 -
[推論] で、[エンドポイント] を選択します。
-
「Name」でエンドポイントを探し、エンドポイントの名前をクリックします。この例では、
spacy-ner-configYYYY-MM-DD-HH-MM-SS
名前は命名規則に従います。 -
「エンドポイントの概要」で、「モデルコンテナログ」の下のリンクを選択します。
-
[ログストリーム] ボックスで最新のログストリームを選択します。
以下のリストを使用して、エンドポイントのデプロイをトラブルシューティングしてください。さらにSupport が必要な場合は、Amazon AWSAWS のサポートまたは開発者フォーラムにお問い合わせください
トピック
-
名前エラー
-
クォータが不十分
-
アップストリームタイムアウトエラー
名前エラー
ログにこのような状態になったらNameError: name 'null' is not defined
、スクリプトがノートブックで作成され、Dockerfile
末尾がなどの別のファイル名に変更されていないことを確認してください。.ipnyb
ノートブックを作成するときに、文字をフォーマットするとエンドポイントがデプロイされない場合があります。このエラーが発生し、スクリプトを変更して修正した場合、変更を有効にするためにカーネルを再起動する必要がある場合があります。
クォータが不足しています。
ResourceLimitExceeded
エラーが発生した場合は、以下のようにクォータの追加をリクエストする必要があります。
AWS サービスクォータの引き上げをリクエストする
-
画面上のエラーメッセージからインスタンス名、現在のクォータ、必要なクォータを取得します。たとえば、次のサンプルエラーでは、
-
インスタンス名はです
ml.c5d.18xlarge
。 -
current utilization
次の番号からの現在のクォータはです1 instances
。 -
request delta
以下の数字から追加で必要なクォータはです。1 instances
サンプルエラーは次のとおりです。
ResourceLimitExceeded: An error occurred (ResourceLimitExceeded) when calling the CreateEndpoint operation: The account-level service limit 'ml.c5d.18xlarge for endpoint usage' is 1 Instances, with current utilization of 1 Instances and a request delta of 1 Instances. Please use AWS Service Quotas to request an increase for this quota. If AWS Service Quotas is not available, contact AWS support to request an increase for this quota.
-
-
AWS Management Console にサインインして、Service Quotas
コンソールを開きます。 -
ナビゲーションペインの [クォータの管理] に「Amazon」と入力します。 SageMaker
-
[クォータを表示] を選択します。
-
サービスクォータの下の検索バーに、ステップ 1 のインスタンスの名前を入力します。たとえば、ステップ 1 のエラーメッセージに含まれる情報を使用して、を入力します。
ml.c5d.18xlarge
-
インスタンス名の横に表示され、末尾が「エンドポイントの使用状況」で終わるクォータ名を選択します。たとえば、ステップ 1 のエラーメッセージに含まれる情報を使用して、エンドポイントの使用状況を選択します
ml.g5.12xlarge
。 -
[アカウントレベルで [増加をリクエスト] を選択します。
-
[クォータ値を増やす] で、ステップ 1 のエラーメッセージに記載されている情報から必要なクォータを入力します。
current utilization
との合計を入力します。request delta
前のエラー例では、current utilization
1 Instances
はで、request delta
はです1 Instances
。この例では、2
必要なクォータを満たすためにクォータをリクエストします。 -
[リクエスト] を選択します。
-
ナビゲーションペインから [クォータ要求履歴] を選択します。
-
[ステータス] が [保留中] から [承認済み] に変わったら、ジョブを再実行します。変更を確認するには、ブラウザーの更新が必要な場合があります。
クォータの増額のリクエストについて詳しくは、「クォータの増額をリクエストする」を参照してください。
アップストリームのタイムアウトエラー
upstream timed out (110: Connection timed
out)
エラーが発生した場合は、次のことを試してください。
-
コンテナのレイテンシーを減らすか、コンテナのタイムアウト制限を増やしてください。 SageMaker コンテナが 60 秒以内にリクエストに応答することを要求します。
-
ウェブサーバーがモデルからの応答を待つ時間を増やしてください。
タイムアウトエラーの詳細については、「Amazon SageMaker の推論エラー「アップストリームからレスポンスヘッダーを読み込んでいるときに、アップストリームがタイムアウトしました (110: 接続がタイムアウトしました)」の解決方法をご覧ください