「Amazon SageMakerを使用してクラシカルなMLとLLMsを簡単にパッケージ化し、デプロイする方法 – パート1：PySDKの改善」

『Amazon SageMakerを活用してクラシカルなMLとLLMsを簡単にパッケージ化し、デプロイする方法 - パート1：PySDKの進化』

Amazon SageMaker（Amazonセージメーカー）は、開発者やデータサイエンティストが機械学習（ML）モデルを迅速かつ容易に構築、トレーニング、展開できるようにするフルマネージドサービスです。SageMakerを使用すると、モデルをAPI呼び出しを介して直接本番環境にデプロイすることが簡単になります。モデルは、堅牢でスケーラブルな展開のためにコンテナにパッケージ化されます。SageMaker Python SDKやAWS SDK、SageMakerコンソール、Amazon SageMaker Studioノートブックなど、さまざまなエントリポイントを提供しており、スケールでのMLモデルのトレーニングと展開のプロセスを簡略化していますが、お客様はまだモデルをプレイグラウンドでテストしたり、本番展開を最適化するためのより良い方法を探しています。

私たちは、SageMakerを使用してモデルのパッケージ化と展開のプロセスを簡略化する2つの新しい方法を発表します。

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

もう一つの新しい発表は、SageMaker Studioの新しいインタラクティブな展開エクスペリエンスの利用です。Part 2で詳しく説明します。

SageMakerエンドポイントへのモデルの展開には、モデルをSageMakerエンドポイントにホストするための一連のステップが必要です。これには、モデルアーティファクトの正しい形式と構造への変換、推論コードの作成、モデルイメージURL、Amazon Simple Storage Service（Amazon S3）におけるモデルアーティファクトの場所、シリアライズとデシリアライズのステップ、適切なアクセス許可を実現するための必要なAWS Identity and Access Management（IAM）の役割など、重要な詳細の指定が必要です。これに続いて、エンドポイントの構成では、推論タイプの決定やインスタンスタイプ、カウント、モデルのバリアント間でのトラフィック分散などのパラメータの設定が必要です。

SageMakerホスティングを使用する際に、お客様をさらにサポートするために、SageMaker Python SDKで新しいModelBuilderクラスを導入しました。このクラスは、次のような利点をもたらします。

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

総合的に、SageMaker ModelBuilderは、低レベルの詳細を処理し、エンドポイントのテスト、検証、最適化のためのツールを提供することで、SageMaker推論のためのモデルパッケージングプロセスを簡素化し、開発者の生産性を向上させ、エラーを減らします。

次のセクションでは、この新機能の詳細について詳しく説明します。また、ModelBuilderを使用してSageMakerホスティングにモデルを展開する方法と、トラディショナルなMLモデルとジェネレーティブAIユースケースの基盤となるモデルの両方を展開するための異なるフレームワークのいくつかの例を紹介します。

SageMaker ModelBuilderの詳細

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

ModelBuilderクラス

ModelBuilderクラスは、カスタマイズオプションを提供します。ただし、フレームワークモデルを展開するには、モデルビルダーはモデル、入力、出力、およびロールの指定を期待しています：

class ModelBuilder(    model, # モデルIDまたはモデルオブジェクト    role_arn, # IAMロール    schema_builder, # 入力と出力を定義する    mode, # ローカル展開とSageMakerエンドポイントへの展開の選択    ...)

SchemaBuilder

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

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

ただし、ほとんどの場合、サンプルの入力と出力だけで十分です。例：

input = "デモの進行状況はどうですか？"output = "Comment la démo va-t-elle?"schema = SchemaBuilder(input, output)

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

ローカルモードの体験

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

# モデルをトレーニングmodel = XGBClassifier()model.fit(X_train, y_train)model.save_model(model_dir + "/my_model.xgb")

次に、実際のモデルオブジェクトを渡し、サンプルのテスト入力および出力オブジェクト（モデルのトレーニングおよびテスト時に使用した入力と出力と同じもの）を使用するSchemaBuilderを介してModelBuilderオブジェクトを作成します。ローカル展開を指定するためにMode.LOCAL_CONTAINERを使用します。その後、build関数を呼び出して、サポートされているフレームワークのコンテナイメージを自動的に特定し、依存関係をスキャンします。以下のコードを参照してください：

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関数を呼び出すことができます。この関数は、デバッグを容易にするためにライブログを提供します。インスタンスタイプまたは数を指定する必要はありません。モデルはローカルに展開されます。これらのパラメータが指定されている場合は無視されます。この関数は、テストデータで予測を行うために使用できるプレディクターオブジェクトを返します：

# 注意：すべてのシリアライズおよびデシリアライズは、モデルビルダーによって処理されます。predictor_local = xgb_local_builder.deploy(# instance_type='ml.c5.xlarge',# initial_instance_count=1)# テストデータの予測を行う。predictor_local.predict(X_test)

オプションで、InferenceSpecを使用してモデルのローディング、前処理、後処理を制御することもできます。詳細はこの記事の後半で説明します。 LOCAL_CONTAINERを使用すると、SageMakerエンドポイントへの展開前にスクリプトをローカルでテストできます。

ModelBuilderを使用してローカルおよびSageMakerエンドポイントに展開するための詳細は、model-builder-xgboost.ipynbの例を参照してください。

SageMakerエンドポイントに伝統的なモデルを展開する

以下の例では、ModelBuilderを使用して伝統的なMLモデルを展開する方法を紹介します。

XGBoostモデル

前述のセクションと同様に、ModelBuilderオブジェクトを作成する際に、modeパラメータを変更することでXGBoostモデルをSageMakerエンドポイントに展開することができます。

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関数を呼び出す際にインスタンスタイプとインスタンスカウントを指定する必要があります。

XGBoostモデルを展開するためのmodel-builder-xgboost.ipynbの例を参照してください。

Tritonモデル

Triton Inference Server上でPyTorchモデルを使用するためには、ModelBuilderを使用することができます。そのためには、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を使用してモデルを展開するためのmodel-builder-triton.ipynbを参照してください。

Hugging Faceモデル

この例では、Hugging Faceが提供する事前学習済みトランスフォーマーモデルをSageMakerに展開する方法を示します。Hugging Faceのpipelineを使用してモデルをロードするために、ModelBuilderに対してカスタムの推論スペックを作成します：

# Hugging Faceパイプラインを使用したカスタムの推論スペック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()

また、モデルの推論の入力と出力を定義するために、modelの入力と出力に基づいてSchemaBuilderオブジェクトを定義します：

schema = SchemaBuilder(value,output)

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

builder = ModelBuilder(    inference_spec=inf_spec,    mode=Mode.SAGEMAKER_ENDPOINT,  # ローカルテストの場合はMode.LOCAL_CONTAINERに変更できます    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')

Hugging Faceパイプラインモデルを展開するためのmodel-builder-huggingface.ipynbを参照してください。

SageMakerエンドポイントに基礎モデルを展開する

以下の例では、ModelBuilderを使用してファウンデーションモデルを展開する方法を紹介しています。上記で述べたモデルと同様に、必要なのはモデルIDだけです。

Hugging Face Hub

Hugging Face Hubからファウンデーションモデルを展開する場合、事前学習済みモデルIDを渡すだけです。たとえば、以下のコードスニペットはmeta-llama/Llama-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", #ローカルパス（アーティファクトが保存される場所）    mode=Mode.LOCAL_CONTAINER,    env_vars={        # Llama 2はゲートモデルであり、Hugging Face Hubトークンが必要です。        "HUGGING_FACE_HUB_TOKEN": "<YourHuggingFaceToken>"     })model = model_builder.build()local_predictor = model.deploy()

Hugging Face Hubのゲートモデルでは、Hugging Face Hub経由でアクセスをリクエストし、対応するキーを環境変数HUGGING_FACE_HUB_TOKENとして渡す必要があります。一部のHugging Faceモデルには、リモートコードを信頼する必要がある場合があります。これは環境変数HF_TRUST_REMOTE_CODEを使用して設定できます。デフォルトでは、ModelBuilderはHugging Faceモデルの基になるコンテナとしてHugging Faceテキスト生成推論（TGI）コンテナを使用します。AWS Large Model Inference（LMI）コンテナを使用したい場合は、ModelBuilderオブジェクトを設定する際にmodel_serverパラメータをModelServer.DJL_SERVINGに設定できます。

ModelBuilderの便利な機能の1つは、LOCAL_CONTAINERモードでコンテナパラメータのローカルチューニングを実行できることです。この機能は、tuned_model = model.tune()を実行するだけで使用できます。

Hugging Face Hubモデルを展開するには、demo-model-builder-huggingface-llama2.ipynbを参照してください。

SageMaker JumpStart

Amazon SageMaker JumpStartもいくつかの事前学習済みファウンデーションモデルを提供しています。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については、Built-in Algorithms with pre-trained Model Tableを参照してください。SageMaker JumpStartモデルを展開するには、model-builder-jumpstart-falcon.ipynbを参照してください。

推論コンポーネント

ModelBuilderは、SageMakerの新しい推論コンポーネント機能を使用してモデルを展開することができます。推論コンポーネントの詳細については、Reduce Model Deployment Costs By 50% on Average Using SageMaker’s Latest Featuresを参照してください。 ModelBuilderで推論コンポーネントをデプロイするには、deploy()メソッドでendpoint_type=EndpointType.INFERENCE_COMPONENT_BASEDを指定します。必要に応じて、最適なアクセラレータの数を取得し、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,    ...   )

モデルを推論コンポーネントとして展開するための詳細は、model-builder-inference-component.ipynbを参照してください。

ModelBuilderクラスのカスタマイズ

ModelBuilderクラスを使用すると、InferenceSpecを使用してモデルのローディングをカスタマイズすることができます。

さらに、CustomPayloadTranslatorを使用して、ペイロードおよびレスポンスのシリアル化およびデシリアル化を制御し、前処理および後処理をカスタマイズすることもできます。また、SageMakerでのモデル展開のためにプリビルトコンテナを拡張する必要がある場合、ModelBuilderを使用してモデルのパッケージングプロセスを処理することができます。次のセクションでは、これらの機能の詳細を提供します。

InferenceSpec

InferenceSpecは、追加のカスタマイズレイヤーを提供します。モデルのロード方法と着信推論リクエストの処理方法を定義することができます。 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ペイロードを介してエンドポイントに送信する必要があります。エンドポイントがペイロードを受け取ると、バイト文字列をモデルが期待するデータ型に逆シリアル化する必要があります（サーバーサイドのデシリアル化とも呼ばれます）。モデルの予測が終了した後、結果はユーザーまたはクライアントに戻すために、バイトにシリアル化する必要があります。クライアントがレスポンスバイトデータを受信すると、クライアント側でデシリアル化を行い、JSONなどの予想データ形式に変換する必要があります。最小限でも、次のようなデータの変換が必要です（以下の図の番号で示されています）：

推論リクエストのシリアル化（クライアントが処理する）
推論リクエストのデシリアル化（サーバーまたはアルゴリズムが処理する）
ペイロードに対するモデルの呼び出し
レスポンスペイロードの送信
推論レスポンスのシリアル化（サーバーまたはアルゴリズムが処理する）
推論レスポンスのデシリアル化（クライアントが処理する）

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

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

from sagemaker.serve import CustomPayloadTranslator# リクエストトランスレーターclass MyRequestTranslator(CustomPayloadTranslator):    # この関数はペイロードをバイトにシリアル化する - クライアント側で実行    def serialize_payload_to_bytes(self, payload: object) -> bytes:        # 入力ペイロードをバイトに変換する        ... ...        return  //バイトとしてオブジェクトを返す            # この関数はバイトをペイロードにデシリアル化する - サーバ側で実行    def deserialize_payload_from_stream(self, stream) -> object:        # バイトをインメモリオブジェクトに変換する        ... ...        return //インメモリオブジェクトを返す        # レスポンストランスレーターclass MyResponseTranslator(CustomPayloadTranslator):    # この関数はペイロードをバイトにシリアル化する - サーバ側で実行    def serialize_payload_to_bytes(self, payload: object) -> bytes:        # レスポンスペイロードをバイトに変換する        ... ...        return //バイトとしてオブジェクトを返す        # この関数はバイトをペイロードにデシリアル化する - クライアント側で実行    def deserialize_payload_from_stream(self, stream) -> object:        # バイトをインメモリオブジェクトに変換する        ... ...        return //インメモリオブジェクトを返す

demo-model-builder-pytorch.ipynbノートブックでは、ModelBuilderとCustomPayloadTranslatorおよびInferenceSpecクラスを使用して、PyTorchモデルをSageMakerエンドポイントに簡単にデプロイする方法を示しています。

デプロイのためのモデルのステージング

モデルを推論用またはモデルレジストリにステージングする場合は、model.create()または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コンテナから拡張されたカスタムコンテナを使用する場合のユースケースをサポートしています。

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

model_builder = ModelBuilder(    model=model,  # 実際のモデルオブジェクトを渡す。エンドポイントで「predict」メソッドが呼び出されます。    schema_builder=SchemaBuilder(X_test, y_pred), # 入力と出力のオブジェクトを使用してシリアル化に必要なサンプルテストを推測する「SchemaBuilder」を渡す。    role_arn=execution_role,     image_uri=image_uri, # BYOCの場合はREQUIRED：パーソナルECRリポジトリにホストされたイメージを渡す    model_server=ModelServer.TORCHSERVE, # BYOCの場合はREQUIRED：モデルサーバーを選択して渡す    mode=Mode.SAGEMAKER_ENDPOINT,    dependencies={"auto": True, "custom": ["protobuf==3.20.2"]})

ここでは、image_uriはアカウントのAmazon Elastic Container Registry（Amazon ECR）リポジトリに保存されているコンテナイメージARNです。以下に例を示します：

# xgboost:1.7-1 DLCを取得し、個人のECRリポジトリにプッシュしましたimage_uri = "<your_account_id>.dkr.ecr.us-west-2.amazonaws.com/my-byoc:xgb"

image_uriが設定されている場合、ModelBuilderのビルドプロセス中にイメージの自動検出がスキップされます。また、ModelBuilderでmodel_serverが設定されていない場合、次のようなバリデーションエラーメッセージが表示されます：

ValueError: image_uriが設定されている場合、model_serverも設定する必要があります。サポートされているモデルサーバー：{<ModelServer.TRITON: 5>、<ModelServer.DJL_SERVING: 4>、<ModelServer.TORCHSERVE: 1>}

この記事の公開時点では、ModelBuilderは、私たちの事前構築済みDLCコンテナイメージまたはDeep Java Library (DJL)、テキスト生成インファレンス（TGI）、TorchServe、Triton inference serverなどのモデルサーバーでビルドされたカスタムコンテナを利用することができます。

カスタム依存関係

ModelBuilder.build()を実行する際、デフォルトではPython環境をrequirements.txtファイルに自動的にキャプチャし、コンテナ内で同じ依存関係をインストールします。ただし、ローカルのPython環境がコンテナ内の環境と競合する場合があります。このような依存関係の競合を修正するために、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(    # その他のパラメータ    dependencies=dependency_config,).build()

以下のフィールドを定義しています：

auto – 環境内の依存関係を自動的にキャプチャするかどうか。
requirements – ユーザー独自のrequirements.txtファイルへのパスの文字列。（これはオプションです。）
custom – 追加または変更したい他のカスタム依存関係のリスト。（これはオプションです。）

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

後片付け

モデルのテストが終わったら、コストを節約するためにエンドポイントを削除することをおすすめします。デモノートブックの後片付けセクションに従うか、以下のコードを使用してデモで作成されたモデルとエンドポイントを削除できます：

predictor.delete_model()predictor.delete_endpoint()

まとめ

新しいSageMaker ModelBuilderの機能は、SageMaker上でのMLモデルのプロダクション展開プロセスを簡素化します。複雑なディテールを裏側で処理することにより、ModelBuilderは新しいユーザーの学習曲線を短縮し、経験豊富なユーザーにとっては最大限の利用を可能にします。わずか数行のコードで、XGBoost、PyTorch、Triton、Hugging Faceなどの組み込みフレームワークを含むモデル、さらにはSageMaker JumpStartに提供されるモデルを、SageMaker上の堅牢かつスケーラブルなエンドポイントに展開することができます。

全てのSageMakerユーザーに、この新しい機能を試していただくことをお勧めします。詳細な情報についてはModelBuilderのドキュメントページをご参照ください。ModelBuilderは追加料金なしで全てのSageMakerユーザーに利用可能です。この簡素化されたワークフローを活用して、モデルをより迅速に展開しましょう。ModelBuilderがモデル開発ライフサイクルをどのように加速するか、ご意見をお聞かせいただけることを楽しみにしています！

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

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!

Advanced (300)Amazon SageMakerAmazon SageMaker StudioArtificial Intelligence

Was this article helpful?

93 out of 132 found this helpful