Amazon MLS-C01: トレーニング、分散トレーニングとハイパーパラメータ最適化 — 学習ガイド

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

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

トレーニングジョブ、コンテナ、そして最小限のコード変更でのクラウドトレーニングへの移行

トレーニングワークロードを SageMaker に移行する際の主要な設計目標は、モデルコードの書き換えを避けつつ、コンテナランタイムが期待される SageMaker の環境変数とチャネルパスを公開するようにすることです。SageMaker スクリプトモードを、フレームワーク固有の Estimator (PyTorch, TensorFlow, XGBoost) と共に使用することで、同じトレーニングスクリプトを最小限の変更でローカルとクラウドの両方で実行できます。具体的には、SM_CHANNEL_TRAIN からデータを読み込み、SM_MODEL_DIR にモデルを書き込み、SM_NUM_GPUS/SM_HOSTS/SM_CURRENT_HOST を尊重するようにします。カスタム環境の場合、公式の AWS Deep Learning Containers (または SageMaker training toolkit) を拡張した Docker イメージをビルドし、Amazon ECR にプッシュします。コンテナのエントリポイントが SageMaker のトレーニングコントラクトを遵守していることを確認してください。コンピューティングプロファイルに基づいてインスタンスタイプを選択します。CPU バウンドなジョブには ml.c5/m5 ファミリー、GPU トレーニングには ml.p3、ml.p4d、g4dn、または g5 インスタンスを使用します。インスタンスサイズは、メモリと GPU 対 CPU 比によって選択します。よくある落とし穴には、ローカルファイルパスのハードコーディング、単一ホストの想定 (分散ジョブで問題になる)、そして I/O パフォーマンスに影響を与えるトレーニング入力モード (Pipe 対 File) の未宣言などがあります。再現性とコスト予測可能性のため、マネージドスポットトレーニングは、堅牢なチェックポイント機能を追加し、スポットの中断を許容するために max_wait > max_run と設定した後にのみ有効にしてください。

分散トレーニングのパターン、データ入力モード、ストレージの選択

分散深層学習では、モデル並列、データ並列、および I/O アーキテクチャのバランスを取る必要があります。マルチ GPU の単一ホストおよびマルチホストトレーニングには、フレームワークのネイティブプリミティブ (torch.distributed や TensorFlow の MultiWorkerMirroredStrategy) を使用するか、SageMaker の smdistributed ライブラリを活用します。データ並列スケーリングには smdistributed.dataparallel を、非常に大規模な Transformer モデルには smdistributed.modelparallel または DeepSpeed を使用します。大規模データセットの標準的なストレージとして S3 を使用しますが、多数の小さな S3 GET は避けてください。ファイルをより少数のアーカイブに統合するか、RecordIO/TFRecord のシャード化されたファイルを使用するか、POSIX ファイルシステムをアタッチします。大規模データセットの場合、ローカルディスクの使用量と起動時間を削減するために、S3 から直接トレーニングデータをストリーミングする Pipe モードを選択します。トレーニングにランダムアクセスが必要な場合や、EBS ボリューム上に完全なデータセットが必要な場合は File モードを使用します。複数のインスタンスにまたがる高スループットと POSIX セマンティクスが必要な場合は、Amazon FSx for Lustre または Amazon EFS をマウントします。FSx は高性能な並列読み取りに適しています。よくある間違いには、ホスト間でデータをシャーディングしないこと (重複の原因となる)、インスタンスあたりの S3 スループットを過大評価すること、並列性を高める際にバッチサイズと学習率のスケーリングルールを無視することなどがあります。

スポットトレーニング、チェックポイント、コスト最適化戦略

マネージドスポットトレーニングは、トレーニングの設計が中断を許容できる場合、コストを劇的に削減できます。SageMaker Estimator (use_spot_instances=True) を介してマネージドスポットを設定し、さらにチェックポイント機能も構成します。永続的な checkpoint_s3_uri とローカルの checkpoint_dir を提供し、再作業時間を抑制できる頻度でチェックポイントを保存します。ジョブがスポットウィンドウ内で中断されたインスタンスを再試行できるように、max_wait を max_run より大幅に大きく設定します。フレームワークでは、アトミックなチェックポイント書き込みと、最新の S3 チェックポイントを検査し、オプティマイザとスケジューラの状態を復元してからトレーニングを続行する堅牢な再開ロジックを実装します。チェックポイントの頻度は、書き込みのオーバーヘッドと無駄になる可能性のあるコンピューティングとのバランスを取る必要があります。エポックが長い、またはモデルが非常に大きい場合は、勾配累積のスナップショットやステップベースの保存を使用してエポックの途中でチェックポイントを作成します。コストの落とし穴には、チェックポイントを S3 に永続化し忘れること (中断時に完全な再起動を引き起こす)、エフェメラルなインスタンスストレージに依存すること、max_wait を max_run と等しく設定して再試行を妨げることなどがあります。スポットトレーニングを混合精度 (AMP) と組み合わせてコンピューティングコストをさらに削減し、より小さなチェックポイントペイロード (重み + オプティマイザのみを保存) と組み合わせて S3 の書き込みコストと再開レイテンシを削減します。

ハイパーパラメータの最適化、チューニング戦略、および実践的な決定基準

効果的なHPOは、探索戦略、リソース割り当て、早期停止を組み合わせたものです。SageMakerのHyperparameterTunerは、ランダム検索とベイズ検索をサポートしており、ContinuousParameter、IntegerParameter、CategoricalParameterの範囲を設定できます。広大な探索空間に対しては、まずランダム検索で幅広く探索し、その後ベイズ最適化を実行して有望な領域を深掘りします。HyperbandやSageMakerの組み込み早期停止などの早期停止手法を使用して予算を節約し、ウォームスタートチューニングを使用して関連する実験間で結果を再利用します。目的メトリクスは慎重に選択します（不均衡タスクには検証AUC、クラス不均衡な不正検出にはF1、在庫切れシナリオにはカスタムのコスト加重メトリクスなど）。よくある落とし穴には、広すぎる範囲を設定して多くのジョブが失敗すること、実質的に連続的なハイパーパラメータにカテゴリカルエンコーディングを使用すること、リソースを意識したHPOをスケーリングしないこと（短い、小規模インスタンスのプローブジョブで大まかな領域を見つけ、その後フルサイズのGPUインスタンスで長時間の実行を行う）などがあります。分散トレーニングでは、アルゴリズムのハイパーパラメータ（学習率、バッチサイズ）とシステムレベルの調整項目（勾配累積ステップ、データシャード数）の両方をチューニングします。SageMaker Debuggerで計測し、CloudWatchメトリクスを使用してノイズの多い測定値を検出します。分散が大きい場合は、設定ごとの繰り返し回数を増やすか、中央値ベースの選択を使用します。

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

シナリオ: FinRetailerは、SKUごとに数千の30日間需要予測をSageMakerで実行しています。S3には長年にわたる日次CSVが保存されており、バッチスコアリングジョブでの許容可能な推論レイテンシーを維持しつつ、テール需要品目に対する高い精度が求められます。

課題: 在庫切れが過剰在庫よりもコストがかかるという不均衡な重要性を持ち、長い履歴を持つ数千の時系列を予測し、希少な高需要イベントに対する精度を維持しながらコンピューティングコストを最小限に抑えること。

推奨アプローチ:

SageMakerの組み込みDeepAR、またはScript Mode Estimatorにパッケージ化されたカスタムPyTorch時間モデル（Transformerベース）を使用します。トレーニングデータはシャーディングされたRecordIO/TFRecordファイルとして保存し、高スループットのマルチインスタンストレーニングのためにFSx for Lustreと共にFileモードを使用します。
小規模インスタンスの分散トレーニング（smddpまたはHorovod）から開始して、モデルアーキテクチャとハイパーパラメータをチューニングします。HyperparameterTunerをベイズ検索と早期停止と共に使用し、予測不足をより重く罰する加重分位損失を目的として定義します。
checkpoint_s3_uriと頻繁なステップベースのチェックポイントを設定して、マネージドスポットトレーニングを有効にします。中断を許容し、最新のS3チェックポイントから再開するために、max_wait > max_runと設定します。
本番推論では、コンピューティング最適化インスタンス上でマルチモデルエンドポイントまたは非同期バッチ変換ジョブを使用してバッチスコアリングを行います。後処理のビジネスルールと、在庫切れコストを考慮したキャリブレーション済みのしきい値を適用します。

論理的根拠: DeepAR/Transformerアーキテクチャを使用することで、多くの時系列を効率的に処理できます。シャーディングされたバイナリ形式とFSxは、分散トレーニングのI/Oボトルネックを削減します。調整された目的を持つベイズHPOは、運用コストメトリクスに焦点を当てた探索を行い、チェックポイント付きのスポットトレーニングは、進捗を犠牲にすることなくコストを削減します。

← 時系列と予測 · すべてのドメイン · デプロイ、推論とサービング（MLの実装と運用） →

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