Amazon SageMaker インスタンス優先リスト、手動GPU再試行を置き換えるも容量計画までは代替せず
AmazonはAmazon SageMakerのインスタンス優先リストを導入した。これにより、トレーニングリクエストでは単一の固定インスタンスタイプではなく、優先順位を付けた最大5つのコンピュートオプションを指定できる。SageMaker AIはこれらのオプションを優先順に確認し、容量が利用可能な最初の構成を起動する。
この変更は、根強く残る運用上の問題に対応するものだ。GPU搭載のSageMakerトレーニングジョブは、要求したハードウェアが利用できない場合、保留状態のままになることがある。チームはこれまで、容量を監視したり、ジョブを再送信したり、代替構成を試すスクリプトを維持したりして対応してきた。
AWSは今回、その再試行の判断をマネージドスケジューラへ移した。ただし、この機能がGPU容量を新たに生み出すわけでも、異なるアクセラレータでワークロードが正しく実行されることを保証するわけでもない。その価値は、チームがトレーニングコード、性能目標、コスト管理を真にハードウェア柔軟なものにできるかどうかにかかっている。
この違いは、インスタンスタイプをすべてのジョブにおける固定属性として扱う、よく知られたクラウドの慣行に再考を迫る。Google CloudはすでにDynamic Workload Schedulerを通じて柔軟なアクセラレータ要求をキューに入れている。Azure Machine Learningのユーザーも、リージョンおよびファミリー固有のコンピュートクォータを前提に計画を立てている。AWSは現在、宣言されたハードウェアの柔軟性を個々のSageMakerジョブの第一級要素にしようとしている。
Amazon SageMaker インスタンス優先リストでAWSが変更したこと
1つのSageMakerリクエストで、外部の再試行コントローラを必要とせず、複数の許容可能なコンピュート構成を表現できるようになった。
AWSは2026年9月15日、トレーニングジョブと処理ジョブの両方を対象にこの機能を発表した。同社のリージョン提供状況のお知らせによると、SageMaker AIが利用可能なすべてのAWS Regionで、SageMaker API、SDK、コマンドラインツール、コンソールを通じて利用できる。
優先リストには、優先順に2～5個のインスタンスタイプを含められる。SageMakerはリストを検証し、メモリ内で走査を実行して、利用可能な容量を持つ最初の構成を選択する。ジョブを実行するのは、リストに含まれる構成のうち1つだけだ。
いずれもすぐに利用できない場合、ジョブはイベント駆動型のキューに入る。SageMakerは、クライアントプロセスがサービスをポーリングしてリクエストを再送信するのではなく、容量の変化に応じて再試行する。待機時間の合計はMaxPendingTimeInSecondsで制限できる。
このタイムアウトは、各オプションに個別ではなく、優先リスト全体に適用される。AWSによれば、ml.p、ml.g、ml.trnなどのファミリーによるアクセラレーテッドコンピュートを、リスト内の少なくとも1つの構成が使用する場合にのみ有効となる。
この挙動が重要なのは、優先設定が単なる代替インスタンス名以上のものだからだ。チームは各オプションに異なるインスタンス数を割り当てられる。あるジョブでは、2台のml.g6.48xlargeノードを優先しつつ、第2の構成でも十分な総スループットが得られる場合には4台のml.g5.48xlargeノードを受け入れることができる。
AWSでは2つのカウントモデルが認められている。共有のResourceConfig.InstanceCountをすべての優先設定に適用するか、各優先設定で独自の数を定義できる。この2つの方式を混在させることは無効であると、APIリファレンスで説明されている。
この機能は、対応GPU容量を一定期間予約するSageMaker Flexible Training Plansにも接続する。トレーニングジョブでは、対応するプランで裏付けられた構成を先頭に置き、その後にオンデマンドの代替案を並べられる。予約済みのオプションをプロビジョニングできない場合、SageMakerは残りの優先設定を順に処理する。
この統合はトレーニングに限定される。処理ジョブにも同じ順序付きフォールバック機構が提供されるが、優先設定をFlexible Training Plansと関連付けることはできない。
それでも、処理のユースケースは重要だ。SageMaker Processingは、データ準備、特徴量エンジニアリング、評価、関連作業のためのマネージドインフラを実行する。こうしたジョブは、厳密に最適化された分散トレーニングジョブよりも、広い範囲のハードウェアを許容できる場合が多い。
AWSは、この変更を手動の再試行ループや容量監視スクリプトの代替策としてローンチ記事で紹介している。これが最も明確な直接的メリットだ。パイプラインは1つのジョブを送信し、SageMakerは宣言された境界内で容量探索を担う。
スケジューラが、同等と判断した任意のマシンを選ぶわけではない。顧客が指定した順序に従う。これにより、構成の有効性を決めるのは運用担当者であり、有効なオプションのうちどれを最初に開始できるかを決めるのはSageMakerである、という有用な責任分担が保たれる。
これは小さなAPI変更だが、運用面ではより大きな意味を持つ。インフラの柔軟性が、周辺のオーケストレーションコードに存在するのではなく、ジョブ定義とともに持ち運ばれるようになるからだ。
SageMakerのGPU容量がスケジューラの問題になった理由
希少なリソースは単なるGPUではなく、適切なリージョンで適切な瞬間に確保できる、適切なクラスタ構成である。
AIトレーニングチームはアクセラレータを交換可能な単位として語ることが多いが、クラウドの容量はインスタンスファミリー、サイズ、リージョン、可用性プール、クォータ、予約モデルに分割されている。顧客にはマシンをリクエストする権限があっても、そのマシンが即時割り当て可能とは限らない。
この断片化は、扱いにくい障害対応を生む。パイプラインが技術的に正しくても、選択した構成を開始できないために何時間も失われる可能性がある。その後、エンジニアは待つのか、ハードウェアを変更するのか、ノード数を調整するのか、ワークロードを移動するのかを判断しなければならない。
優先リスト以前、SageMakerトレーニングジョブは送信時に1つのインスタンスタイプを指定していた。代替案を受け入れるチームは、その柔軟性を別の場所で実装する必要があった。API障害を中心に再試行関数を構築するケースもあれば、複数のバリアントを送信し、1つが開始した後で他をキャンセルするケースもあった。
どちらのパターンも調整作業を増やす。複数のライブリクエストは可観測性やキャンセルを複雑にし得る。順次再試行スクリプトには、状態管理、バックオフルール、タイムアウト処理、権限、重複実行を防ぐ保護が必要になる。
容量監視もまた、別の本番システムになる。チームはSDKの挙動が変わるたびにこれを保守し、その障害を可視化し、再起動したコントローラが同じ高価なジョブを2回起動しないことを保証しなければならない。
Amazon SageMakerのインスタンス優先リストは、このコントロールプレーンの一部を取り込む。ジョブリクエストが許容可能な結果の限定された集合を保持し、マネージドサービスが容量を見つけた時点で選択を行う。
このモデルは、多くの現実のワークロードの挙動を反映している。ファインチューニング、評価、前処理、モデル実験では、数学的に必須となる構成が1つしかないというより、優先される構成がある場合が多い。チームは速度を求めて新しいGPUを好みつつ、開始時刻の方が重要な場合には古いGPUを受け入れることができる。
同じ原則はノード数にも当てはまる。より高速な2ノードと、より低速な4ノードが、場合によっては同様の完了目標を満たせる。両者は本質的に同等ではないが、開発者は検証したうえで、どちらも許容可能と宣言できる。
AWSだけが、希少性をスケジューリングインターフェースに変えているわけではない。Google CloudのFlex-startモードは、必要なリソースがすべて利用可能になるまでアクセラレータ要求をキューに入れる。Googleはこれを、柔軟な開始時刻を許容できるトレーニングジョブ向けに位置付けている。
仕組みは異なる。Googleのモデルは、要求されたアクセラレータ割り当てと期間の充足を重視する。AWSでは、1つのSageMakerジョブが順序付けられたタイプと台数のセットを移行できる。いずれのアプローチも、顧客に容量を繰り返し探るのではなく、柔軟性を表現するよう求めるものだ。
Azure Machine Learningは、制約の別の側面を明らかにしている。同サービスのコンピュートクォータはリージョンとVMファミリーごとに管理され、ワークスペース利用とサブスクリプション利用には別々の制限がある。GPUファミリーでは、サブスクリプションによっては専用コアクォータが初期状態で設定されていない場合がある。
これらのシステムは、アクセラレータの可用性をカタログページだけに還元できない理由を示している。掲載されているインスタンスがサポート対象であっても、特定のアカウント、場所、ジョブ規模、時間帯では利用できない可能性がある。
AWSの顧客にとって、直近の影響はカスタムプロビジョニングロジックを維持しているチームに及ぶ。再試行サービスがSageMakerのインスタンスタイプを順に切り替えるだけのものであれば、その中核機能は現在ではプラットフォームと重複する。
この機能は、モデルごとにインスタンスタイプを1つだけ承認する硬直的な社内標準にも圧力をかける。そうした標準はベンチマークとガバナンスを単純化してきたが、容量不足のたびにブロッカーとなる。チームには今、各ワークロードに対して複数の構成を認定する理由がある。
これはオーケストレーションをなくすものではない。パイプラインには依然として依存関係、アーティファクト追跡、障害ポリシー、実行後の検証が必要だ。この変更は、許容可能な構成のうちどれを開始できるかという繰り返しの判断をSageMaker自体に移すことで、オーケストレーションの役割を絞り込む。
柔軟性が再試行ロジックを置き換えても、容量制約は置き換えない
この仕組みは利用可能なインフラを探すプロセスを改善するが、存在しないインフラを供給することはできない。
ジョブが到着すると、SageMakerはその構成と優先リストを、サポート対象リソースおよび制限に照らして検証する。続いてスケジューラが、宣言された順序でオプションを一度確認する。最初に利用可能なオプションが選ばれ、プロビジョニングが開始される。
すべてのオプションが利用できない場合、イベント駆動型キューは関連する容量変化を待つ。これは顧客による継続的なポーリングより効率的だが、それでもキューである。タイムアウトが切れるまで、ジョブは保留状態のままになる可能性がある。
この境界は、この機能がジョブの開始を早めるというAWSの主張を評価する際に重要になる。比較対象は、利用不能な1つの構成に固定されたジョブ、またはより低速な顧客管理の再試行システムだ。AWSは、リージョン、インスタンスファミリー、クラスタ規模をまたぐ開始時間の中央値の改善を示す独立ベンチマークを公表していない。
また、リストは複数のエントリから部分的な容量を組み合わせるものでもない。ある優先設定が8ノードを要求する場合、SageMakerはその選択された構成をプロビジョニング可能である必要がある。システムは利用可能な断片から異種クラスタを組み立てるのではなく、完全な優先設定を1つ選ぶ。
これは、インスタンス優先設定とSageMakerの異種クラスタを区別する。異種クラスタは、1つのトレーニングジョブ内で複数のインスタンスグループを意図的に実行する。優先リストは相互排他的な代替案を表し、そのうち1つだけがジョブのコンピュート環境となる。
この違いは実行の一貫性を守る。分散トレーニングフレームワークは通常、ジョブ開始後に既知のトポロジーを期待する。あらかじめ定義された1つの構成を選ぶ方が、ハードウェアアーキテクチャ、ネットワーク特性、メモリプロファイルを動的に混在させるよりも簡単だ。
Training Planとの統合は、さらに別の判断レイヤーを加える。ある優先設定は対応する予約済みプランを指し、後続のエントリではオンデマンド容量を使用できる。運用担当者が予約済みのオプションを先頭に置いた場合、AWSはその予約済みオプションを最初に評価する。
このシーケンスにより、組織は前払い済みキャパシティを優先しつつ、それをジョブの唯一の実行経路にせずに済みます。ただし、フォールバックは経済的な結果を変え得ます。オンデマンドの代替手段は実効コストが異なる場合があり、ノード数が多いほどその差は増幅される可能性があります。
この機能は、Managed Spot Trainingの代替でもないようです。Managed Spot Training は、中断可能なEC2 Spotキャパシティを利用することで、別のトレードオフに対応します。AWSによると、このアプローチはコンピューティングコストを削減できる一方で、中断により完了までの時間が延び、チェックポイントの取得が必要になる場合があります。
インスタンスの優先設定は主に、許容できる構成群から初期キャパシティを選ぶことに対応します。Spotトレーニングは、ワークロードがコンピューティングを確保した後の購入モデルと中断リスクに対応します。チームはこれらの次元をそれぞれ評価する必要があります。
したがって最適なのは、再起動には弱いもののハードウェアの柔軟性があるジョブです。たとえば、複数世代のGPUで実行可能な夜間評価パイプラインを考えてみましょう。朝のレポート期限に間に合わないことは重要ですが、必ずしも最高速のアクセラレータを使う必要はありません。
チームは複数の構成を認定し、完了時間と予想コストの望ましいバランスに従って並べ、最大保留時間を設定できます。SageMakerはその検証済みの範囲内で選択します。
大規模な事前学習実行では、より難しいケースとなります。通信パターン、メモリ要件、チェックポイントの挙動、トポロジーが、特定のアクセラレータとインターコネクトに合わせて調整されている場合があります。名目上はサポートされるフォールバックでも、ジョブが遅くなったり、コストが増えたり、不安定になったりする可能性があります。
新しいスケジューラは、そのフォールバックが科学的または経済的に妥当であり続けるかを判断できません。その判断はワークロードの所有者に委ねられます。
したがって、Amazon SageMakerのインスタンス優先リストは宣言的なものであり、広義の適応型ではありません。SageMakerはキャパシティシグナルに応答しますが、モデルのベンチマーク、分散設定の書き換え、期限に応じたリストの最適化は行いません。
それでも、これは重要です。マネージドサービスは、反復的で明確に範囲が定められた責任を各顧客から引き受け、一度だけ実装することで価値を生みます。顧客が正直な互換性の境界を提示する限り、キャパシティフォールバックはこのパターンに適合します。
互換性とコストは引き続き運用担当者の責任
最も重要なリスクは、SageMakerが誤った優先設定を選ぶことではなく、チームが安全でない優先設定を許容可能だと宣言することです。
AWSは、SageMakerが異なるタイプ間の互換性を検証しないと明示的に警告しています。このサービスは、コンテナがすべてのGPUアーキテクチャをサポートしているか、ドライバーが一致しているか、分散構成にElastic Fabric Adapterネットワークが必要かを判定しません。
したがって、ジョブはリクエスト検証に合格しても、プロビジョニング後に失敗する可能性があります。この結果は起動時間を消費し、自動フォールバックで期待される利点を弱めるおそれがあります。
フレームワークの挙動には特に注意が必要です。CUDA機能、集団通信ライブラリ、混合精度フォーマット、コンパイラ出力、デバイス固有カーネルは、アクセラレータ世代によって異なることがあります。H100ハードウェアでテストしたコンテナが、A100またはL40Sハードウェアでも同一に動作すると想定すべきではありません。
メモリも別の境界です。理論上の総スループットが似ていても、あるアクセラレータに収まるワークロードが別のアクセラレータではデバイスメモリを超える可能性があります。ノード数を増やしても、デバイス単位のメモリ制約が自動的に解決するわけではありません。
分散トポロジーもパフォーマンスに影響します。高帯域幅の2ノードを低速な4ノードに置き換えると、通信量、同期オーバーヘッド、障害への露出が変化します。同じGPU数や概算のコンピューティング見積もりは、同じ完了時間を保証しません。
AWSの例は、普遍的な等価性の式ではなく意図を示しています。ある例では、4台のml.g5.48xlargeインスタンスより前に、2台のml.g6.48xlargeインスタンスが挙げられています。その関係がモデル、バッチサイズ、ネットワークパターン、ソフトウェアスタックにおいて成り立つかは、顧客が判断する必要があります。
チームは、本番環境で使うのと同じコンテナイメージ、データパス、分散ランチャーで、リストに含めるすべての構成をベンチマークすべきです。結果として作成する承認記録には、実行時間、収束チェック、使用率、失敗率、出力検証を含める必要があります。
コストポリシーにも同じ規律が必要です。優先順位は優先度を表すものであり、予算上限ではありません。より多くのインスタンスを使うフォールバックは早く開始できても、優先オプションより総請求額が高くなる可能性があります。
逆に、古いハードウェアは実行時間が長くなり、インスタンス単位での見かけ上の節約を相殺する場合があります。重要なのは、起動遅延、実行時間、再試行、ストレージ、下流の期限への影響を含めた、ジョブ全体の結果です。
この発表は、可観測性の要件も生み出します。チームは、どの優先設定が選ばれたか、ジョブがどれだけ待機したか、代替案をどのような理由で並べたか、実際のパフォーマンスがベンチマークと一致したかを記録する必要があります。
こうした記録がなければ、自動選択は不透明になります。エンジニアは、実行間で基盤となるインスタンスファミリーが変わったことを知らないまま、実行時間やコストのばらつきが増えたと感じるかもしれません。
ガバナンスルールも更新が必要になる可能性があります。AWSは、SageMakerのインスタンスタイプを制約するアイデンティティポリシーをサポートしています。組織が承認する優先リストは、これらの統制、アカウントクォータ、リージョンでの可用性の範囲内に収める必要があります。
予約済みキャパシティも、別の誤解を招く可能性があります。Flexible Training Planの優先設定はより強いキャパシティコミットメントを提供できますが、フォールバックによって利用不可能な予約が予約済み供給に変わるわけではありません。ジョブを、別途許容されるオンデマンドの経路へ移すだけです。
処理ジョブには独自のレビューが必要です。一部の変換ではCPUフォールバックが合理的な場合もありますが、完了時間を大幅に変える可能性もあります。APIが許可しているというだけで、CPUオプションをリストに含めるべきではありません。
公開済みの現場データがないことが、現時点で最大の不確実性です。AWSはスケジューリングフローと構成ルールを説明していますが、顧客は異なる不足状況での開始時間改善について、まだ広範な証拠を持っていません。
有用な測定では、この機能を各チームの既存ベースラインと比較する必要があります。これには、送信から実行までの時間、フォールバックを利用したジョブの割合、タイムアウト率、総コンピューティング消費量、構成変更による運用インシデントが含まれます。
これらの測定により、SageMakerのGPUキャパシティ柔軟性が真の手作業を取り除くのか、それとも変動性を見えにくい層へ移すだけなのかが明らかになります。
この機能が実運用で機能するかを示す3つのシグナル
導入は、構成に2つ目のインスタンスタイプを追加したチーム数ではなく、ジョブの結果で評価すべきです。
最初のシグナルは、フォールバック頻度と開始時間を組み合わせたものです。チームは、SageMakerが第1優先以外をどの程度の頻度で選択するか、またそれによって送信から開始までのレイテンシーがどう変わるかを測定すべきです。
フォールバック率が高く、待機時間が短くなるなら、AWSの中心的な主張を支持します。それは、優先タイプが制約されている場合でも、より広いプール全体にはキャパシティが存在することを示します。
待機時間が短縮されないままフォールバック率だけが高い場合、この主張は弱まります。リストされた代替案が同じリージョンのボトルネックを共有している、要求されたクラスターが大きすぎる、あるいはイベント駆動型キューがそのワークロードの充足を実質的に改善していない可能性があります。
2つ目のシグナルは、選択された構成間のパフォーマンスとコストのばらつきです。すべてのフォールバックを、実行時間、使用率、完了ステータス、総リソース消費量に結び付ける必要があります。
結果が安定していれば、インフラストラクチャを優先設定の集合として扱うという考え方が強化されます。大きな乖離があれば、各構成が技術的にはコンテナを実行できたとしても、代替案が真に等価ではなかったことを示します。
これは、繰り返し実行されるパイプラインで特に重要です。チームは緊急の実験で一度だけ遅い実行を許容するかもしれませんが、日次の本番スケジュールにおける継続的な予測不能性は受け入れないでしょう。
3つ目のシグナルは、AWSがこの機能と周辺テレメトリーをどのように拡張するかです。顧客は、より豊富な選択イベント、保留状態に関するより明確な説明、コストを考慮した並べ替えツール、パイプライン制御とのより広い統合に注目すべきです。
より細かなポリシーのサポートも重要になります。運用担当者は将来的に、期限、支出上限、フォールバックスループットがテスト済みの範囲内に収まることといった制約を求めるかもしれません。現行の順序付きリストでは、これらの判断を手作業で符号化しています。
競合他社の対応は補足的な文脈を提供しますが、決定的な証拠は顧客の運用から得られます。Googleはすでに、Dynamic Workload Schedulerを通じてアクセラレータ不足をスケジューリング問題として扱っています。Azureは、マネージドジョブを実行できるかどうかを左右するクォータの境界を公開しています。
AWSの特徴的な動きは、複数の許容可能な構成をSageMakerのトレーニングまたは処理リクエストの中に直接組み込むことです。顧客が許容できないばらつきなしに開始時間を短縮できれば、このモデルはマネージドMLプラットフォームにとって無視しにくいものになるでしょう。
短期的な検証は簡単です。ハードウェアの柔軟性があるワークロードを1つ選び、候補となるすべての構成をベンチマークし、自動フォールバックを有効にする前に最大保留時間を定義します。その後、少なくとも数回の実行を従来の再試行プロセスと比較します。
選択されたインスタンスタイプ、キュー滞在時間、実行時間、完了ステータス、総リソース使用量を記録してください。起動に成功したことだけを結果のすべてと見なしてはいけません。
Amazon SageMakerのインスタンス優先リストは、キャパシティ処理の手作業を減らしますが、準備を求めます。代替案を検証するチームは、脆弱なインフラストラクチャコードを取り除けます。推測に基づくフォールバックを入力するチームは、互換性のなさを発見する作業を自動化するだけかもしれません。
有用な問いは、5つの選択肢が1つより優れているかどうかではありません。組織が真に許容できる5つの結果を定義し、意図的に順位付けし、SageMakerがその中から選んだときに何が起きるかを測定できるかどうかです。
