SageMaker AIがSOCIインデックス付きイメージに対応、学習コンテナを遅延読み込みしイメージ取得中のGPUアイドルを最大90%削減とAWS

Published 2026-10-29 · AI Daily — AI-assisted deep research, methodology & disclosure

AWSは2026年10月29日、Amazon SageMaker AIの学習ジョブと処理ジョブがSOCI（Seekable OCI）インデックス付きのコンテナイメージに対応したと発表した。AWSによれば、学習コンテナが数秒で起動し、イメージ取得中のGPUアイドル時間を最大90%減らせて、学習性能への影響は、最初のエポックの一度きりのコストを除けばない。90%はAWS自身のベンチマークで得た「最大」の値であり、すべてのジョブへの保証ではない。

問題はジョブが動き出す前にある。SageMaker AIはまずコンテナイメージ全体をインスタンスにダウンロードし、展開して全レイヤーを書き込む。深層学習のイメージは10 GBを超えることが多く、この工程が毎回のジョブに数分を足し、その時間にも課金される。数百ジョブに及ぶハイパーパラメータ探索、短い実験、短い処理ジョブでは、ダウンロードが実行時間の大半を占めうるため影響が大きい。

SOCIはオープンソースの遅延読み込み技術だ。SOCIインデックスはイメージ内の全ファイルを対応づけるメタデータで、OCI準拠の成果物としてAmazon ECRに保存され、元のイメージに関連づけられるため、イメージのダイジェストと既存の署名は有効なままである。ジョブのイメージにインデックスがあると、SageMaker AIはコンテナの起動に必要なファイルだけを取得し、残りはコードの実行中にバックグラウンドで流し込む。サービスはインデックスの有無を自動で確認し、あれば遅延読み込み、なければ従来どおりのダウンロードを行い、インデックスが読めない場合や遅延読み込みに失敗した場合は標準のダウンロードに戻ってジョブを続ける。つまりインデックスを足してもジョブが動かなくなることはない。

導入の方法は2つある。1つはAWSがインデックス済みのDeep Learning Containerを使い、イメージタグを-sociの付いた版に変えること。AWSの発表ブログはPyTorch Training、TensorFlow Training、vLLM、SGLangを挙げ、一部のフレームワークにはarm64版もある。もう1つは自分のイメージにインデックスを足す方法で、containerd、SOCI snapshotter、FinchまたはnerdctlのあるLinuxホストが必要だが、イメージの作り直しは要らない。ジョブ定義、エントリポイント、データチャネルは変えなくてよい。条件が2つある。Deep Learning ContainerをFROMにして作ったイメージは、基礎イメージのインデックスが引き継がれないため最終イメージ用に別途インデックスが必要なこと、そしてイメージがプライベートなECRリポジトリにあることだ。機能はSageMaker AIが使えるすべてのリージョンで、API、CLI、SDK、コンソールから使える。

発表ブログにはAWS自身の測定が載っている。テストは圧縮後1.8〜35.4 GBの8イメージを使い、ml.g4dnからml.p5までのインスタンスで、米国西部（オレゴン）と米国東部（バージニア北部）で実施し、数値は繰り返し実行の中央値である。1.8 GBのイメージは48秒から3〜11秒に、13.2 GBは3分42秒から約6秒に、35.4 GBは7分17秒から3〜11秒になった。同じ13.2 GBのイメージを13種のインスタンスで試すと、標準のダウンロードは3分16秒〜4分20秒、遅延読み込みは6〜8秒だった。ブログ自身の概説は倍率の書き方が揃っておらず、約10倍、8倍、8〜46倍と出てくるが、表では約8倍から約38倍なので、秒数のほうを根拠にしたい。

学習そのものには一度だけのコストがある。AWSはImagenette（9,469枚）でのResNet-50と、51,760例でのQwen2.5-0.5Bの全パラメータ微調整を比べた。2エポック目以降は1エポックの時間が同じで、最初のエポックは初めて触るファイルを取りに行くため3〜16秒長くなり、ジョブ全体では約1〜6分早く終わった。エントリポイントが学習の前にイメージの大半を読む場合、たとえばスキャン、チェックサム、プリロードでは、利得は小さくなる。AWSのテストでは、torch.compileとJITビルドのCUDA拡張で最初のエポックが7〜15秒伸び、6 GBのモデルをイメージに焼き込み、読み込み時に重みを流し込む構成では2〜3.5分増えたが、それでもジョブは2〜2.5分早く終わった。

これらはAWSが2種類のワークロードで測った値である。最初のエポックのコストはイメージと起動時に触るファイルで変わるので、自分のジョブで測るのがよい。

Sources

FAQ

SOCIインデックス付きイメージは何を変え、「最大90%」は何を指しますか？

ジョブはイメージ全体のダウンロードを待たず、コンテナの起動に必要なファイルだけを取得し、残りはバックグラウンドで流し込む。90%はAWSのベンチマークでイメージ取得中のGPUアイドル時間が減る「最大」の値で、全ジョブへの約束ではなく、学習性能は最初のエポックの一度きりのコストを除いて変わらない。

どのような手順で導入しますか？

第1にイメージをプライベートなECRリポジトリに置く。第2に-sociタグのインデックス済みDeep Learning Containerに切り替えるか、containerd、SOCI snapshotter、Finchまたはnerdctlを入れたLinuxホストで自分のイメージにインデックスを作る。第3にジョブでそのイメージを参照する。ジョブ定義は変えない。

どんなコストと限界がありますか？

AWSのテストでは最初のエポックが3〜16秒長くなったが、ジョブ全体では約1〜6分早く終わった。エントリポイントが学習前にイメージの大半を読むと利得は小さくなり、DLCを土台に作ったイメージには別にインデックスが要る。2種類のワークロードの測定なので、自分のジョブで測ってほしい。