Amazon MLA-C01: ML ワークロードのコスト最適化 — 学習ガイド

By Laurynas Brazys · 4 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

こちらの一部です： AWS Machine Learning Engineer Associate MLA-C01 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

コアコンセプト: コストの発生源と調整可能な要素

機械学習ワークロードのコストは、3つの基本的な要素から構成されます。すなわち、トレーニングと推論のためのコンピューティング、データセットとチェックポイントのためのストレージとデータ転送、そして十分に活用されていない、あるいは不適切にプロビジョニングされたインフラストラクチャによる運用オーバーヘッドです。大規模なモデルをトレーニングしたり、多くの実験を実行したりする場合、トレーニングはしばしば最大の単一コスト項目となります。モデルを大規模に提供したり、インタラクティブなアプリで低レイテンシーが要求されたりする場合、推論コストが大半を占めます。主要な最適化の手段は、インスタンスファミリーとサイズの選択、購入オプション (オンデマンド vs Spot vs Savings Plans)、モデルのライフサイクルパターン (バッチ vs リアルタイム vs サーバーレス)、そしてモデルコンパイル、キャッシング、インスタンス統合などのランタイム最適化です。

運用テクニックは、これらの手段を実践に移すものです。マネージドスポットトレーニングとチェックポイントを使用して、オンデマンドと比較してトレーニングのコンピューティングコストを最大70%削減します。ただし、チェックポイント (CreateTrainingJob パラメータの CheckpointConfig → S3Uri) と、CreateTrainingJob のフラグ EnableManagedSpotTraining を true に設定して、中断後にジョブを再開できるようにすることが必要です。実際のCPU/GPU/IO使用量 (GPUUtilization、HostCPUUtilization などの CloudWatch メトリクスや SageMaker Debugger のプロファイラートレース) をプロファイリングしてインスタンスをライトサイジングし、ワークロードの特性に合ったコンピューティングファミリー (CPU向けに ml.c5/ml.c6、GPU向けに ml.g5/ml.p4、メモリ集約型向けに ml.r5) に切り替えます。推論については、コストに比例したモデルを選択します。スパイクがありスループットの低いワークロードにはサーバーレス推論 (CreateEndpointConfig の本番稼働用バリアントで ServerlessConfig → MemorySizeInMB と MaxConcurrency を使用) を利用します。多くの小さなモデルのインスタンス要件を削減するために、マルチモデルエンドポイントやモデルコンパイル (SageMaker Neo) を使用します。そして、大規模またはレイテンシーに寛容なワークロードは、非同期推論またはバッチ変換 (AsyncInferenceConfig および Batch Transform) に移行します。

主要なサービスと設定

Amazon SageMaker は、コスト管理のための明確な調整項目を公開しています。トレーニングコストを削減するには、マネージドスポットトレーニングを使用します。CreateTrainingJob API で EnableManagedSpotTraining=true を設定し、CheckpointConfig.S3Uri を含め、Spot キャパシティの取得を可能にするために MaxWaitTimeInSeconds > MaxRuntimeInSeconds と設定します。SageMaker Python SDK では、estimator.use_spot_instances=True、estimator.max_wait、そして estimator.checkpoint_s3_uri にS3のチェックポイントロケーションを設定できます。連続するトレーニングジョブで再現性のある低レイテンシーを実現するには、実験の頻度が高い場合には SageMaker Processing を活用するか、永続的にプロビジョニングされたインフラ上でトレーニングコンテナを実行してコンテナをウォーム状態に保ちます。それ以外の場合は、より小さなコンテナイメージやビルド済みの SageMaker コンテナを使用するか、開発環境で永続的なトレーニングインスタンスを再利用することで、コンテナの起動時間を短縮します。

推論コストの管理のために、CreateEndpointConfig/UpdateEndpointConfig は複数の戦略をサポートしています。ProductionVariants で ServerlessConfig を使用すると、SageMaker がスケーリングを管理し、インスタンス時間全体ではなく呼び出しごとおよびメモリごとに課金されるようになります。ServerlessConfig には MemorySizeInMB と MaxConcurrency の値が必要です。安定的で高スループットのワークロードには、プロビジョニングされたインスタンスを使用し、エンドポイントに Application Auto Scaling のターゲット追跡ポリシーを適用して、過剰なプロビジョニングを回避します。マルチモデルエンドポイントは、単一のコンテナを共有し、S3 からオンデマンドでモデルアーティファクトをロードすることで、めったに使用されない多数のモデルをホストする際のコストを削減します。モデルのサイジングに関する推奨事項については、Inference Recommender で CreateInferenceRecommendationsJob を呼び出します。これにより、インスタンスタイプ、バッチサイズ、およびレイテンシー/スループットに関するガイダンスが得られます。

料金コミットメントは、SageMaker Savings Plans または AWS Compute Savings Plans で対応するのが最適です。AWS Billing コンソール経由で Savings Plan を購入し、1年または3年の期間で $/hour のコミットメントを行います。これにより、インスタンスファミリー全体でオンデマンドの SageMaker コンピューティング (トレーニングとホスティング) が割引されます。Savings Plans はオンデマンドの使用量に適用され、Spot には適用されないことに注意してください。したがって、戦略を組み合わせる必要があります。ベースラインとなる安定した使用量のために Savings Plans を購入し、突発的な、あるいは実験的なトレーニングには Spot を使用します。

設計パターンとトレードオフ

マネージドスポットとチェックポイントを組み合わせるパターンは、長時間または大規模な分散トレーニングを実行する際の定番です。最小限のコード変更で済みます。EnableManagedSpotTrainingを有効にし、CheckpointConfig.S3Uriを指定し、スポットスケジューリングを許容するために適切なMaxWaitTimeInSecondsを設定します。トレードオフは、スポットの中断が頻繁に発生した場合の再起動の複雑さと、ウォールクロックタイムがわずかに長くなることです。その代わりに、劇的なコスト削減というメリットが得られます。連続するジョブ間の起動レイテンシーが重要な反復的な実験では、ウォームな開発環境を維持します。NVMe/ローカルキャッシュにデータをプリロードした、より小規模なプロビジョニング済みml.m5またはml.c5インスタンスを使用するか、SageMaker ProcessingまたはStudioノートブックを使用して同じインスタンス上で多くの実験をローカル処理ジョブとして実行します。これによりベースラインコストは増加しますが、総サイクル時間は短縮されます。

推論では、トラフィックパターンに応じてサーバーレスエンドポイントとプロビジョニングされたエンドポイントのどちらかを選択します。サーバーレス推論 (ServerlessConfig) はキャパシティプランニングを不要にし、呼び出しごとおよびメモリ割り当てごとに支払うため、断続的で予測不可能なトラフィックに対して最も低コストです。トレードオフは、コールドスタートのレイテンシーとサイズ制限です。厳格な低レイテンシーSLAが求められる場合は、オートスケーリングを備えたプロビジョニング済みインスタンスを選択し、インスタンス数を削減するためにSageMaker Neoによるモデルの最適化を検討してください。多くのモデルをホストする必要があるものの、モデルごとのトラフィックが少ない場合は、マルチモデルエンドポイントがディスクとメモリの使用量を集約し、モデルあたりのコストを削減します。その代償として、ロードされていないモデルに対するコールドスタートのロード時間がわずかに長くなります。

ライトサイジングは、推測ではなく、まず観測に基づいて行うべきです。SageMaker DebuggerのプロファイリングとCloudWatchを使用してGPUUtilizationとDiskReadOpsを収集し、次にInference Recommenderジョブ (CreateInferenceRecommendationsJob) を実行してインスタンスクラス/タイプとパフォーマンスを検証します。モデルのレイテンシー要件が厳しい場合は、モデルの量子化、SageMaker Neoでのコンパイル、またはElastic Inferenceアクセラレーターを使用してCPUインスタンスにGPU推論機能の一部をアタッチすることを検討してください。Elastic Inferenceを使用すると、小さなアクセラレーターをCPUインスタンスにアタッチできるため、特定のモデルにおいて、完全なGPUインスタンスと比較してコストを削減できます。

一般的な落とし穴と判断基準

よくある間違いは、単一のコスト最適化戦略をすべてのワークロードに適用してしまうことです。Savings Plansは安定したベースライン使用率に対しては強力ですが、実験的なワークロードにはSpot、スパイク的な推論にはサーバーレスと組み合わせるべきです。Spotが無料だと考えないでください。チェックポインティングと中断耐性のあるトレーニングロジックが必要です。

undefined

、CreateTrainingJob.CheckpointConfig、EnableManagedSpotTrainingを設定し、開始の遅延をどの程度許容できるかを反映したMaxWaitTimeInSecondsを計算してください。もう一つの落とし穴は、テレメトリを無視することです。プロファイリング（SageMaker Debugger、CloudWatch、Inference Recommender）を行わないと、過剰プロビジョニングのリスクや、CPU、GPU、メモリの特性が要件と合わないインスタンスファミリーを選択してしまうリスクがあります。最後に、サーバーレス推論はコストを簡素化しますが、予測不能なコールドスタートを引き起こす可能性があります。ServerlessConfigを使用する際はエンドツーエンドのレイテンシを測定し、厳しいSLAがある場合はオートスケーリングを備えたプロビジョニング済みエンドポイントにフォールバックしてください。

実践的な問題：ユースケースシナリオ

企業：FinSight Analytics。課題：FinSight社は、S3に保存されたトランザクションログと顧客プロファイルで頻繁にトレーニングを行い、データを分離し、本番デプロイ前の手動承認によるモデルバージョンのガバナンスをサポートし、夜間の再トレーニングのコストを削減し、迅速な実験中のジョブごとの起動レイテンシを最小化し、スパイク的なトラフィックに対してコストを意識した低レイテンシのリアルタイムエンドポイントを提供する必要がある不正検知パイプラインを構築しなければなりません。

一元化された安全なデータとモデルレジストリ。 デフォルト暗号化と、SageMaker実行ロールにアクセスを制限するバケットポリシーを設定した、安全なS3バケットにデータを保存します。SageMaker Model Registryにモデルを登録します。SageMaker PipelinesのRegisterModelステップを使用して、ModelApprovalStatusがデフォルトで “PendingManualApproval” に設定されたモデルパッケージを作成します。モデルパッケージと手動承認ステップを出力するSageMaker Pipelineを作成することで、手動承認の人間によるワークフローを実装します。承認されたレビュー担当者が検証を終えたら、boto3 sagemaker.update_model_package(ModelPackageName=..., ModelApprovalStatus='Approved') を呼び出してデプロイを許可します。理由：Model Registryは一元的なバージョニングを提供し、ModelApprovalStatusはSageMaker APIと直接統合されているため、カスタムの運用作業を最小限に抑えられます。
コスト効率の良い夜間の再トレーニング。 EnableManagedSpotTraining=trueを指定してトレーニングジョブを作成することで、マネージドスポットトレーニングを使用します。オプティマイザの状態を永続化するためにCheckpointConfig.S3Uriを含め、Spotによる中断時にジョブが再開できるようにMaxRuntimeInSecondsとMaxWaitTimeInSecondsを適切に設定します。これを、平均的なオンデマンドのトレーニング/推論時間をカバーする規模のベースラインとなるSavings Planの購入と組み合わせることで、定常的なコストを削減します。そして、中断が許容できる実験にはSpotを使用します。理由：マネージドスポットは最小限のコード変更でコンピューティングコストを削減します。Savings Plansはベースラインのオンデマンド使用量に適用され、予測可能な費用を削減します。
実験における起動レイテンシの削減。 インタラクティブな実験サイクルでは、SageMaker Studioで永続的な開発インスタンスプロファイル（ml.c5やml.m5など）を維持するか、EBS/NVMeにデータセットをプリロードした小規模な専用Notebook Instanceを維持し、その環境を多くの迅速なトレーニング実行に再利用します。本番の夜間ジョブには、引き続きチェックポインティング付きのマネージドスポットを使用します。理由：永続的な環境はコンテナのコールドスタートを回避し、イテレーション速度を向上させると同時に、負荷の高い実行に対するコスト削減効果を維持します。
低レイテンシでコストを意識したリアルタイムサービング。 承認されたモデルをプロビジョニング済みエンドポイントにデプロイしてベースラインの低レイテンシを確保し、オフピーク時間帯にスケールダウンするためにエンドポイントにApplication Auto Scalingポリシーをアタッチします。予測不能なトラフィックのスパイクに対しては、低トラフィックのモデルにはサーバーレス推論オプションを配置するか、リアルタイム性が求められない重いバッチスコアリングタスクには非同期推論（AsyncInferenceConfigとS3 OutputConfigを使用）を利用します。デプロイ前にモデルにSageMaker Neoコンパイルを適用して、CPU/GPUフットプリントを削減します。理由：プロビジョニング済みとオートスケーリングの組み合わせは、安定した低レイテンシとコスト管理を実現します。サーバーレスまたは非同期エンドポイントは、スパイク的またはバッチ処理のワークロードをよりコスト効率よく処理し、Neoはインスタンス要件を削減します。

このアプローチは、トレーニングコスト削減のためのEnableManagedSpotTrainingとCheckpointConfig、手動承認のためのSageMaker Model RegistryとUpdateModelPackage、起動レイテンシ削減のための永続的な開発インスタンス、そして推論コストを最適化するためのプロビジョニング済み、サーバーレス、コンパイル済みモデルの組み合わせを統合したものです。

← 生成 AI と基盤モデル · すべてのドメイン · コンピュータービジョン、NLP、特化型 ML →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →