Amazon SageMaker を使用して従来の ML と LLM を簡単にパッケージ化してデプロイする、パート 1: PySDK の改善 | アマゾン ウェブ サービス

アマゾンセージメーカー は、開発者やデータ サイエンティストが、あらゆる規模の機械学習 (ML) モデルを迅速かつ簡単に構築、トレーニング、デプロイできるようにするフルマネージド サービスです。 SageMaker を使用すると、サービスへの API 呼び出しを通じてモデルを実稼働環境に直接デプロイすることが簡単になります。 モデルはコンテナにパッケージ化されており、堅牢でスケーラブルな展開が可能です。 SageMaker Python SDK、AWS SDK、SageMaker コンソール、 Amazon SageMakerスタジオ ノートブックを使用して ML モデルを大規模にトレーニングおよびデプロイするプロセスを簡素化できますが、顧客は依然として、プレイグラウンド テスト用にモデルをデプロイし、運用環境のデプロイを最適化するためのより良い方法を探しています。

私たちは、SageMaker を使用してモデルをパッケージ化およびデプロイするプロセスを簡素化する XNUMX つの新しい方法を開始します。

この投稿では、新しい SageMaker Python SDK を紹介します。 ModelBuilder このエクスペリエンスは、データ サイエンティストなどの新しい SageMaker ユーザーの学習曲線を最小限に抑えることを目的としていると同時に、経験豊富な MLOps エンジニアが SageMaker ホスティング サービスを最大限に活用できるように支援します。 これは、SageMaker の全機能を活用するためのベスト プラクティスに関するガイダンスを提供することにより、初期セットアップと展開の複雑さを軽減します。 この新しい SageMaker 機能に関する詳細情報と GitHub の例を提供します。

もう 2 つの新しい機能は、SageMaker Studio の新しいインタラクティブなデプロイメント エクスペリエンスを使用することです。 これについてはパート XNUMX で説明します。

モデルを SageMaker エンドポイントにデプロイするには、モデルを SageMaker エンドポイントでホストできるようにするための一連の手順が必要です。 これには、モデル アーティファクトを正しい形式と構造で取得し、推論コードを作成し、モデル画像の URL などの重要な詳細を指定することが含まれます。 Amazon シンプル ストレージ サービス (Amazon S3) モデルアーティファクトの場所、シリアル化と逆シリアル化の手順、および必要な AWS IDおよびアクセス管理 (IAM) ロールを使用して、適切なアクセス許可を促進します。 これに続いて、エンドポイント構成では、推論タイプを決定し、インスタンス タイプ、数、モデル バリアント間のトラフィック分散などの各パラメーターを構成する必要があります。

SageMaker ホスティングを使用する際にお客様をさらに支援するために、新しい機能を導入しました。 ModelBuilder SageMaker Python SDK のクラス。これにより、モデルを SageMaker エンドポイントにデプロイするときに次のような重要な利点が得られます。

• フレームワーク間で導入エクスペリエンスを統合します – 新しいエクスペリエンスは、PyTorch、TensorFlow、XGBoost などのさまざまなフレームワークを使用して構築されたモデルをデプロイするための一貫したワークフローを提供します。 これにより、展開プロセスが簡素化されます。
• モデルのデプロイメントを自動化する – 適切なコンテナの選択、依存関係の取得、シリアル化/逆シリアル化の処理などのタスクが自動化され、展開に必要な手動の労力が軽減されます。
• ローカルから SageMaker でホストされるエンドポイントへのスムーズな移行を実現します。 – 最小限のコード変更で、モデルをローカル テストから SageMaker エンドポイントでのデプロイメントに簡単に移行できます。 ライブ ログにより、デバッグがシームレスになります。

全体として、SageMaker ModelBuilder 低レベルの詳細を処理することで SageMaker 推論のモデル パッケージ化プロセスを簡素化および合理化し、エンドポイントのテスト、検証、最適化のためのツールを提供します。 これにより、開発者の生産性が向上し、エラーが減少します。

次のセクションでは、この新機能の詳細を詳しく説明します。 また、次を使用してモデルを SageMaker ホスティングにデプロイする方法についても説明します。 ModelBuilder、プロセスが簡素化されます。 次に、従来の ML モデルと生成 AI ユースケースを強化する基盤モデルの両方をデプロイするためのさまざまなフレームワークの例をいくつか紹介します。

SageMaker ModelBuilder について知る

新しい ModelBuilder は、XGBoost や PyTorch などのフレームワークを使用して構築された ML モデルを取得し、それらを SageMaker にデプロイできるモデルに変換することに重点を置いた Python クラスです。 ModelBuilder 提供 build() モデルサーバーに従ってアーティファクトを生成する関数と、 deploy() ローカルまたは SageMaker エンドポイントにデプロイする機能。 この機能の導入により、モデルと SageMaker 環境の統合が簡素化され、パフォーマンスとスケーラビリティが最適化されます。 次の図は、その方法を示しています。 ModelBuilder 高いレベルで取り組んでいます。

ModelBuilder クラス

　 モデルビルダー クラスには、カスタマイズのためのさまざまなオプションが用意されています。 ただし、フレームワーク モデルをデプロイするために、モデル ビルダーはモデル、入力、出力、およびロールを期待するだけです。

class ModelBuilder( model, # model id or model object role_arn, # IAM role schema_builder, # defines the input and output mode, # select between local deployment and depoy to SageMaker Endpoints ...
)

スキーマビルダー

　 スキーマビルダー クラスを使用すると、エンドポイントの入力と出力を定義できます。 これにより、スキーマ ビルダーは、入力と出力をシリアル化および逆シリアル化するための対応するマーシャリング関数を生成できるようになります。 次のクラス ファイルは、カスタマイズのためのすべてのオプションを提供します。

class SchemaBuilder( sample_input: Any, sample_output: Any, input_translator: CustomPayloadTranslator = None, output_translator: CustomPayloadTranslator = None
)

ただし、ほとんどの場合、サンプルの入出力だけで機能します。 例えば：

input = "How is the demo going?"
output = "Comment la démo va-t-elle?"
schema = SchemaBuilder(input, output)

サンプルの入出力を提供することで、 SchemaBuilder 必要な変換を自動的に決定できるため、統合プロセスがより簡単になります。 より高度な使用例では、入力と出力の両方にカスタム変換関数を提供できる柔軟性があり、より複雑なデータ構造も効率的に処理できるようになります。 次のセクションでは、次のセクションを使用して、さまざまなフレームワークを使用してさまざまなモデルをデプロイすることで、これを実証します。 ModelBuilder.

ローカルモード体験

この例では、 ModelBuilder XGBoost モデルをローカルにデプロイします。 Mode を使用して、ローカル テストと SageMaker エンドポイントへのデプロイを切り替えることができます。 最初に XGBoost モデルを (ローカルまたは SageMaker で) トレーニングし、モデル アーティファクトを作業ディレクトリに保存します。

# Train the model
model = XGBClassifier()
model.fit(X_train, y_train)
model.save_model(model_dir + "/my_model.xgb")

次に、実際のモデル オブジェクトを渡して ModelBuilder オブジェクトを作成します。 SchemaBuilder これは、サンプル テストの入力オブジェクトと出力オブジェクト (モデルのトレーニングとテスト時に使用したのと同じ入力と出力) を使用して、必要なシリアル化を推測します。 使用することに注意してください Mode.LOCAL_CONTAINER ローカル展開を指定します。 その後、 ビルド サポートされているフレームワーク コンテナ イメージを自動的に識別し、依存関係をスキャンする機能。 次のコードを参照してください。

model_builder_local = ModelBuilder( model=model, schema_builder=SchemaBuilder(X_test, y_pred), role_arn=execution_role, mode=Mode.LOCAL_CONTAINER
)
xgb_local_builder = model_builder_local.build()

最後に、 deploy モデル オブジェクト内の関数。これにより、デバッグを容易にするためのライブ ログも提供されます。 モデルはローカルにデプロイされるため、インスタンスのタイプや数を指定する必要はありません。 これらのパラメータを指定した場合、それらは無視されます。 この関数は、テスト データを使用して予測を行うために使用できる予測子オブジェクトを返します。

# note: all the serialization and deserialization is handled by the model builder.
predictor_local = xgb_local_builder.deploy(
# instance_type='ml.c5.xlarge',
# initial_instance_count=1
) # Make prediction for test data. predictor_local.predict(X_test)

オプションで、次を使用してモデルの読み込みと前処理および後処理を制御することもできます。 InferenceSpec。 詳細については、この投稿の後半で説明します。 使用する LOCAL_CONTAINER これは、SageMaker エンドポイントにデプロイする前にスクリプトをローカルでテストするための優れた方法です。

Job Status ページの下部にある モデルビルダー-xgboost.ipynb を使用してローカルと SageMaker エンドポイントの両方にデプロイをテストする例 ModelBuilder.

従来のモデルを SageMaker エンドポイントにデプロイする

次の例では、使用方法を紹介します。 ModelBuilder 従来の ML モデルをデプロイします。

XGBoostモデル

前のセクションと同様に、XGBoost モデルを SageMaker エンドポイントにデプロイするには、 mode 作成時のパラメータ ModelBuilder オブジェクト：

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(sample_input=sample_input, sample_output=sample_output), role_arn=execution_role, mode=Mode.SAGEMAKER_ENDPOINT
)
xgb_builder = model_builder.build()
predictor = xgb_builder.deploy( instance_type='ml.c5.xlarge', initial_instance_count=1
)

SageMaker エンドポイントにデプロイする場合、呼び出し時にインスタンス タイプとインスタンス数を指定する必要があることに注意してください。 deploy 機能。

Job Status ページの下部にある モデルビルダー-xgboost.ipynb XGBoost モデルをデプロイする例。

トリトンモデル

あなたが使用することができます ModelBuilder PyTorch モデルを提供するには Triton推論サーバー。 そのためには、 model_server パラメータとして ModelServer.TRITON、モデルを渡し、 SchemaBuilder オブジェクトには、モデルからのサンプル入力と出力が必要です。 残りの部分は ModelBuilder が処理します。

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(sample_input=sample_input, sample_output=sample_output), role_arn=execution_role, model_server=ModelServer.TRITON, mode=Mode.SAGEMAKER_ENDPOINT
) triton_builder = model_builder.build() predictor = triton_builder.deploy( instance_type='ml.g4dn.xlarge', initial_instance_count=1
)

参照する モデルビルダー-triton.ipynb Triton を使用してモデルをデプロイします。

ハグフェイスモデル

この例では、Hugging Face によって提供される事前トレーニング済みのトランスフォーマー モデルを SageMaker にデプロイする方法を示します。 ハグフェイスを使いたい pipeline モデルをロードするため、カスタム推論仕様を作成します。 ModelBuilder:

# custom inference spec with hugging face pipeline
class MyInferenceSpec(InferenceSpec): def load(self, model_dir: str): return pipeline("translation_en_to_fr", model="t5-small") def invoke(self, input, model): return model(input) inf_spec = MyInferenceSpec()

また、推論ワークロードの入力と出力も定義します。 SchemaBuilder モデルの入力と出力に基づくオブジェクト:

schema = SchemaBuilder(value,output)

次に、 ModelBuilder オブジェクトを作成し、他の例で示したものと同じロジックに従ってモデルを SageMaker エンドポイントにデプロイします。

builder = ModelBuilder( inference_spec=inf_spec, mode=Mode.SAGEMAKER_ENDPOINT, # you can change it to Mode.LOCAL_CONTAINER for local testing schema_builder=schema, image_uri=image,
)
model = builder.build( role_arn=execution_role, sagemaker_session=sagemaker_session,
)
predictor = model.deploy( initial_instance_count=1, instance_type='ml.g5.2xlarge'
)

参照する モデルビルダー-ハギングフェイス.ipynb ハグフェイスパイプラインモデルをデプロイします。

基盤モデルを SageMaker エンドポイントにデプロイする

次の例では、使用方法を紹介します。 ModelBuilder 基礎モデルを展開します。 前述のモデルと同様に、必要なのはモデル ID だけです。

フェイスハブを抱き締める

基盤モデルをデプロイする場合は、 フェイスハブを抱き締める、必要なのは、事前トレーニングされたモデル ID を渡すことだけです。 たとえば、次のコード スニペットは、 メタラマ/ラマ-2-7b-hf 現地でモデルを作ります。 モードを次のように変更できます。 Mode.SAGEMAKER_ENDPOINT SageMaker エンドポイントにデプロイします。

model_builder = ModelBuilder( model="meta-llama/Llama-2-7b-hf", schema_builder=SchemaBuilder(sample_input, sample_output), model_path="/home/ec2-user/SageMaker/LoadTestResources/meta-llama2-7b", #local path where artifacts will be saved mode=Mode.LOCAL_CONTAINER, env_vars={ # Llama 2 is a gated model and requires a Hugging Face Hub token. "HUGGING_FACE_HUB_TOKEN": "<YourHuggingFaceToken>" }
)
model = model_builder.build()
local_predictor = model.deploy()

Hugging Face Hub 上のゲート付きモデルの場合、Hugging Face Hub 経由でアクセスをリクエストし、関連するキーを環境変数として渡して使用する必要があります。 HUGGING_FACE_HUB_TOKEN。 一部のハグフェイスモデルでは、リモートコードを信頼する必要がある場合があります。 次を使用して環境変数としても設定できます HF_TRUST_REMOTE_CODE。 デフォルトでは、 ModelBuilder ハグ顔テキスト生成推論を使用します (T.G.I.) コンテナを、Hugging Face モデルの基礎となるコンテナとして使用します。 AWS 大規模モデル推論を使用したい場合 (LMI) コンテナを設定できます。 model_server パラメータとして ModelServer.DJL_SERVING を設定するとき ModelBuilder オブジェクト。

のすっきりとした機能 ModelBuilder を使用するときにコンテナパラメータのローカルチューニングを実行する機能です。 LOCAL_CONTAINER モード。 この機能は、次のコマンドを実行するだけで使用できます。 tuned_model = model.tune().

参照する デモ-モデル-ビルダー-ハギングフェイス-llama2.ipynb ハグフェイスハブモデルを展開します。

SageMaker ジャンプスタート

Amazon SageMaker ジャンプスタート 事前トレーニングされた基礎モデルも多数提供しています。 Hugging Face Hub からモデルをデプロイするプロセスと同様に、モデル ID が必要です。 SageMaker JumpStart モデルを SageMaker エンドポイントにデプロイするのは、次のコードを実行するのと同じくらい簡単です。

model_builder = ModelBuilder( model="huggingface-llm-falcon-7b-bf16", schema_builder=SchemaBuilder(sample_input, sample_output), role_arn=execution_role
) sm_ep_model = model_builder.build() predictor = sm_ep_model.deploy()

利用可能なすべての SageMaker JumpStart モデル ID については、以下を参照してください。 事前トレーニング済みのモデル テーブルを使用した組み込みアルゴリズム。 参照する モデルビルダー-ジャンプスタート-falcon.ipynb SageMaker JumpStart モデルをデプロイします。

推論コンポーネント

ModelBulder SageMaker の新しい推論コンポーネント機能を使用してモデルをデプロイできるようになります。 推論コンポーネントの詳細については、を参照してください。 SageMaker の最新機能を使用してモデルの導入コストを平均 50% 削減。 推論コンポーネントをデプロイメントに使用するには、 ModelBuilder 指定することにより endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED セクションに deploy() 方法。 を使用することもできます。 tune() メソッドを使用してアクセラレータの最適な数を取得し、必要に応じて変更します。

resource_requirements = ResourceRequirements( requests={ "num_accelerators": 4, "memory": 1024, "copies": 1, }, limits={},
) goldfinch_predictor_2 = model_2.deploy( mode=Mode.SAGEMAKER_ENDPOINT, endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED, ... )

参照する モデルビルダー推論コンポーネント.ipynb モデルを推論コンポーネントとしてデプロイします。

ModelBuilder クラスをカスタマイズする

　 ModelBuilder クラスを使用すると、モデルの読み込みをカスタマイズできます。 InferenceSpec.

さらに、ペイロードと応答のシリアル化と逆シリアル化を制御し、次を使用して前処理と後処理をカスタマイズできます。 CustomPayloadTranslator。 さらに、SageMaker でモデルをデプロイするために事前に構築されたコンテナを拡張する必要がある場合は、次のように使用できます。 ModelBuilder モデルのパッケージ化プロセスを処理します。 次のセクションでは、これらの機能について詳しく説明します。

推論仕様

推論仕様 追加のカスタマイズ層を提供します。 これにより、モデルがどのようにロードされるか、および受信した推論リクエストをどのように処理するかを定義できます。 を通して InferenceSpecを使用すると、デフォルトの読み込みメカニズムをバイパスして、モデルのカスタム読み込みプロシージャを定義できます。 この柔軟性は、非標準モデルまたはカスタム推論パイプラインを操作する場合に特に有益です。 呼び出しメソッドはカスタマイズでき、モデルが受信リクエストを処理する方法 (前処理と後処理) を調整できるようになります。 このカスタマイズは、推論プロセスがモデルの特定のニーズに確実に適合するようにするために不可欠です。 次のコードを参照してください。

class InferenceSpec(abc.ABC): @abc.abstractmethod def load(self, model_dir: str): pass @abc.abstractmethod def invoke(self, input_object: object, model: object): pass

次のコードは、このクラスの使用例を示しています。

class MyInferenceSpec(InferenceSpec): def load(self, model_dir: str): return // model object def invoke(self, input, model): return model(input)

CustomPayloadTranslator

SageMaker エンドポイントを呼び出すと、データはさまざまな MIME タイプの HTTP ペイロードを通じて送信されます。 たとえば、推論のためにエンドポイントに送信された画像は、クライアント側でバイトに変換され、HTTP ペイロードを通じてエンドポイントに送信される必要があります。 エンドポイントがペイロードを受信すると、バイト文字列をモデルが予期するデータ型 (別名) に逆シリアル化する必要があります。 サーバー側の逆シリアル化）。 モデルが予測を完了した後、結果をバイトにシリアル化し、HTTP ペイロードを通じてユーザーまたはクライアントに送り返す必要があります。 クライアントが応答バイト データを受信すると、クライアント側で逆シリアル化を実行して、バイト データを JSON などの予期されるデータ形式に変換し直す必要があります。 最低でも、 次のデータを変換する必要があります (次の図に番号が付けられています):

1. 推論リクエストのシリアル化 (クライアントによって処理される)
2. 推論リクエストの逆シリアル化 (サーバーまたはアルゴリズムによって処理される)
3. ペイロードに対してモデルを呼び出す
4. 応答ペイロードを送り返す
5. 推論応答のシリアル化 (サーバーまたはアルゴリズムによって処理)
6. 推論応答の逆シリアル化 (クライアントによって処理される)

次の図は、呼び出しプロセス中のシリアル化と逆シリアル化のプロセスを示しています。

次のコード スニペットでは、次の例を示します。 CustomPayloadTranslator クライアント側とサーバー側でそれぞれシリアル化と逆シリアル化の両方を処理するために追加のカスタマイズが必要な場合:

from sagemaker.serve import CustomPayloadTranslator # request translator
class MyRequestTranslator(CustomPayloadTranslator): # This function converts the payload to bytes - happens on client side def serialize_payload_to_bytes(self, payload: object) -> bytes: # converts the input payload to bytes ... ... return //return object as bytes # This function converts the bytes to payload - happens on server side def deserialize_payload_from_stream(self, stream) -> object: # convert bytes to in-memory object ... ... return //return in-memory object # response translator class MyResponseTranslator(CustomPayloadTranslator): # This function converts the payload to bytes - happens on server side def serialize_payload_to_bytes(self, payload: object) -> bytes: # converts the response payload to bytes ... ... return //return object as bytes # This function converts the bytes to payload - happens on client side def deserialize_payload_from_stream(self, stream) -> object: # convert bytes to in-memory object ... ... return //return in-memory object

デモモデルビルダー-pytorch.ipynb ノートブックでは、次を使用して PyTorch モデルを SageMaker エンドポイントに簡単にデプロイする方法を示します。 ModelBuilder CustomPayloadTranslator と InferenceSpec とに提供されます。

導入のためのステージモデル

モデルを推論用にステージングするか、モデル レジストリにステージングする場合は、次を使用できます。 model.create() or model.register()。 有効なモデルがサービス上に作成され、後でデプロイできます。 次のコードを参照してください。

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(X_test, y_pred), role_arn=execution_role, )
deployable_model = model_builder.build() deployable_model.create() # deployable_model.register() for model registry

カスタムコンテナを使用する

SageMaker が提供する 事前に構築された Docker イメージ 組み込みアルゴリズムと、トレーニングと推論に使用されるサポートされている深層学習フレームワークについて。 事前に構築された SageMaker コンテナがすべての要件を満たしていない場合は、ニーズに合わせて既存のイメージを拡張できます。 事前に構築されたイメージを拡張することで、イメージを最初から作成しなくても、含まれている深層学習ライブラリと設定を使用できます。 事前に構築されたコンテナを拡張する方法の詳細については、SageMaker ドキュメントを参照してください。 ModelBuilder は、事前に構築された Docker コンテナーから拡張された独自のコンテナーを導入する場合のユースケースをサポートします。

この場合、独自のコンテナ イメージを使用するには、フィールドを設定する必要があります。 image_uri および model_server 定義するとき ModelBuilder:

model_builder = ModelBuilder( model=model, # Pass in the actual model object. its "predict" method will be invoked in the endpoint. schema_builder=SchemaBuilder(X_test, y_pred), # Pass in a "SchemaBuilder" which will use the sample test input and output objects to infer the serialization needed. role_arn=execution_role, image_uri=image_uri, # REQUIRED FOR BYOC: Passing in image hosted in personal ECR Repo model_server=ModelServer.TORCHSERVE, # REQUIRED FOR BYOC: Passing in model server of choice mode=Mode.SAGEMAKER_ENDPOINT, dependencies={"auto": True, "custom": ["protobuf==3.20.2"]}
)

ここで、 image_uri アカウントのに保存されているコンテナ イメージ ARN になります。 Amazon エラスティック コンテナ レジストリ (Amazon ECR) リポジトリ。 一例を次に示します。

# Pulled the xgboost:1.7-1 DLC and pushed to personal ECR repo
image_uri = "<your_account_id>.dkr.ecr.us-west-2.amazonaws.com/my-byoc:xgb"

時 image_uri が設定されている間、 ModelBuilder ビルド プロセスでは、イメージ URI が指定されているため、イメージの自動検出はスキップされます。 もし model_server ModelBuilder に設定されていない場合は、次のような検証エラー メッセージが表示されます。

ValueError: Model_server must be set when image_uri is set. Supported model servers: {<ModelServer.TRITON: 5>, <ModelServer.DJL_SERVING: 4>, <ModelServer.TORCHSERVE: 1>}

この投稿の公開時点では、 ModelBuilder 当社のコンテナを拡張した独自のコンテナの持ち込みをサポートします。 事前に構築された DLC コンテナ イメージ または、次のようなモデルサーバーで構築されたコンテナー ディープJavaライブラリ（DJL）, テキスト生成推論 (TGI), トーチサーブ, Triton 推論サーバー.

カスタム依存関係

実行時 ModelBuilder.build()、デフォルトでは、Python 環境を自動的にキャプチャします。 requirements.txt ファイルを作成し、同じ依存関係をコンテナーにインストールします。 ただし、ローカルの Python 環境がコンテナ内の環境と競合する場合があります。 ModelBuilder は、カスタム構成を ModelBuilder。 これは、TorchServe と Triton のみに適用されることに注意してください。 InferenceSpec。 たとえば、次のように ModelBuilder で Python ディクショナリである入力パラメータの依存関係を指定できます。

dependency_config = { "auto" = True, "requirements" = "/path/to/your/requirements.txt" "custom" = ["module>=1.2.3,<1.5", "boto3==1.16.*", "some_module@http://some/url"]
} ModelBuilder( # Other params dependencies=dependency_config,
).build()

次のフィールドを定義します。

• オート – 環境内の依存関係を自動キャプチャするかどうか。
• 必要条件 – 自分自身へのパスの文字列 requirements.txt ファイル。 (これはオプションです。)
• カスタム – 追加または変更するその他のカスタム依存関係のリスト。 (これはオプションです。)

同じモジュールを複数箇所で指定した場合、 custom が最も優先されます。 requirements, auto の優先度は最も低くなります。 たとえば、自動検出中に次のようになったとします。 ModelBuilder 検出 numpy==1.25、と requirements.txt を指定するファイルが提供されます numpy>=1.24,<1.26。 さらに、カスタムの依存関係があります。 custom = ["numpy==1.26.1"]。 この場合、 numpy==1.26.1 コンテナに依存関係をインストールするときに選択されます。

クリーンアップ

モデルのテストが完了したら、ベスト プラクティスとして、エンドポイントが不要になった場合はコストを節約するためにエンドポイントを削除します。 フォローすることができます クリーンアップ 各デモ ノートブックのセクションを削除するか、次のコードを使用して、デモによって作成されたモデルとエンドポイントを削除します。

predictor.delete_model()
predictor.delete_endpoint()

まとめ

新しい SageMaker ModelBuilder 機能により、ML モデルを SageMaker の実稼働環境にデプロイするプロセスが簡素化されます。 ModelBuilder は、多くの複雑な詳細を舞台裏で処理することにより、新規ユーザーの学習曲線を短縮し、経験豊富なユーザーの利用率を最大化します。 わずか数行のコードで、XGBoost、PyTorch、Triton、Hugging Face などの組み込みフレームワークを備えたモデルや、SageMaker JumpStart によって提供されるモデルを、SageMaker 上の堅牢でスケーラブルなエンドポイントにデプロイできます。

すべての SageMaker ユーザーが、以下を参照してこの新しい機能を試してみることをお勧めします。 モデルビルダー ドキュメントページ。 ModelBuilder は現在、すべての SageMaker ユーザーが追加料金なしで利用できます。 この簡素化されたワークフローを利用して、モデルをより迅速にデプロイします。 ModelBuilder がどのようにモデル開発ライフサイクルを加速するかについてお聞きすることを楽しみにしています。

Sirisha Upadhyayala 氏、Raymond Liu 氏、Gary Wang 氏、Dhawal Patel 氏、Deepak Garg 氏、Ram Vegiraju 氏に心より感謝いたします。

著者について

メラニー・リー博士号は、オーストラリアのシドニーに拠点を置く AWS のシニア AI/ML スペシャリスト TAM です。 彼女は、企業顧客が AWS 上の最先端の AI/ML ツールを使用してソリューションを構築できるよう支援し、ベストプラクティスを使用した ML ソリューションの設計と実装に関するガイダンスを提供します。 余暇には、自然を探索したり、家族や友人と時間を過ごすのが大好きです。

マーク・カープ Amazon SageMaker Service チームの ML アーキテクトです。 彼は、お客様が大規模な ML ワークロードを設計、デプロイ、管理できるよう支援することに重点を置いています。 余暇には、旅行や新しい場所の探索を楽しんでいます。

サム・エドワーズは、機械学習と Amazon SageMaker を専門とする AWS シドニーのクラウド エンジニア (AI/ML) です。 彼は、顧客が機械学習ワークフローに関連する問題を解決できるよう支援し、顧客向けの新しいソリューションを作成することに情熱を注いでいます。 仕事以外では、ラケット スポーツをすることと旅行を楽しんでいます。

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

シヴァ ラージ コティニ Amazon SageMaker 推論製品ポートフォリオのプリンシパルプロダクトマネージャーとして働いています。 彼は、推論のための SageMaker でのモデルのデプロイ、パフォーマンス チューニング、最適化に重点を置いています。

モハンガンディー AWS のシニア ソフトウェア エンジニアです。 彼は過去 10 年間 AWS に勤務しており、EMR、EFA、RDS などのさまざまな AWS サービスに取り組んできました。 現在、彼は SageMaker Inference Experience の改善に重点を置いています。 余暇には、ハイキングやマラソンを楽しんでいます。

• SEO を活用したコンテンツと PR 配信。 今日増幅されます。
• PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
• プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
• プラトンESG。 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
• プラトンヘルス。 バイオテクノロジーと臨床試験のインテリジェンス。 こちらからアクセスしてください。
• 情報源： https://aws.amazon.com/blogs/machine-learning/package-and-deploy-classical-ml-and-llms-easily-with-amazon-sagemaker-part-1-pysdk-improvements/