今日から使うAI2026年11月1日

SOCIインデックス付きイメージでSageMakerジョブの起動が短くなる、コードがイメージを一気に読み切らなければ

AWSによると、SOCIインデックス付きのイメージはSageMakerジョブのイメージ取得を数分から数秒にします。コードがイメージを読み切る場合は別です。自分のジョブでの測り方。

中級5分で読めます参考ソース 1件

Amazon SageMaker AI（モデルの学習や実行のためのAWSのサービス）の学習ジョブは、あなたのコードを1行も実行しないうちに、コンテナイメージ（ジョブが動くライブラリや環境をまとめた、あらかじめ梱包されたソフトウェア）のダウンロードに数分を使うことがあります。AWSのブログによると、10 GBを超える深層学習用のイメージでは、このダウンロードがジョブのたびに数分加わり、その時間は料金として支払うことになります。AWSが今回紹介した対策は、SOCIインデックス（Seekable OCI。イメージを必要に応じて読み込む技術で、起動に必要なファイルだけを先に取り、残りはコードの実行中に裏で取得する）の作成です。このインデックスが効くのは、起動時にコードがイメージのほとんどを読まない場合だけで、それは同じジョブを2回走らせて確かめられます。

AWSの主張と、その測定条件

AWSによると、SOCIインデックスはメタデータ（イメージの中の各ファイルの位置を示す地図）で、元のイメージにひもづくアーティファクトとしてAmazon ECR（AWSのコンテナイメージの保管場所）に保存されます。そのため、イメージのダイジェスト（固有の識別子）と既存の署名はそのまま有効です。イメージにインデックスがない場合や、インデックスが読めない場合は、ジョブは通常の全量ダウンロードに戻り、そのまま動きます。

以下の数字はAWSが自社で測った結果で、圧縮後1.8〜35.4 GBのイメージについて、複数回の実行の中央値です。次の節の手順はAWSの案内からの引用で、この記事では再実行していません。

1.8 GBのイメージ：通常のダウンロードが48秒、オンデマンド読み込みが3〜11秒。
13.2 GBのイメージ：3分42秒に対して約6秒。
35.4 GBのイメージ：7分17秒に対して3〜11秒。
試験用の各学習ジョブ（ResNet-50による画像分類と、小さな言語モデルのファインチューニング）では、最初のエポック（学習データ全体を1周すること）が3〜16秒長くなりました。差し引きで、各ジョブは1〜6分早く終わったとAWSは報告しています。

AWSは、改善幅はイメージが大きいほど増え、約4 GB未満のイメージでは改善が比較的小さいとも述べています。AWS自身が挙げている点で、この記事の核心はここです。エントリーポイント（ジョブが最初に実行するコマンド）が、学習の開始前にイメージのほとんどを読む場合、たとえばスキャン、チェックサム（ファイルの完全性を確かめる符号）の計算、中身の先読みをする場合、最初のエポックは全量ダウンロードが取ってきたのとほぼ同じバイト数を待つことになり、差し引きの改善は小さくなります。

自分のジョブで試す

まず重要でないジョブで試してください。

入力：約4 GB以上のイメージを使い、繰り返し実行しているSageMakerのジョブ（AWSは、ハイパーパラメータ探索や短い実験で、イメージのダウンロードが占める割合が最も大きいと述べています）。イメージはAmazon ECRのプライベートリポジトリにある必要があります。AWSによると、他のレジストリにあるイメージや、TrainingRepositoryAccessModeをVpcにして社内のDockerレジストリ経由で取得するイメージは、オンデマンド読み込みの対象外です。

ジョブを今のまま実行し、2つの数字を記録します。イメージの取得からコンテナの準備完了までの時間と、ジョブ全体の時間です。これが比較の基準になります。
2つの道のどちらかを選びます。Deep Learning Container（PyTorch、TensorFlow、vLLM、SGLang向けにAWSが用意したイメージ）を使っているなら、イメージのタグ（イメージ名のコロンの後ろで、取得する版を示す部分）を、末尾が-sociの版に替えます。例：pytorch-training:2.9-gpu-py312-cu130-ubuntu22.04-sagemaker-v1-soci。自作のイメージなら、containerd（コンテナを動かすソフトウェア）、SOCI snapshotter（containerdの部品で、イメージをオンデマンドで読み込む）、nerdctl（containerd用のコマンドラインツール）が入ったLinuxマシンでインデックスを作ります。nerdctl pull、次にnerdctl image convert --sociで新しいタグに変換し、nerdctl pushです。イメージがDLCのベースイメージの上に作られている場合は、最終的なイメージにインデックスを作る必要があります。ベースイメージのインデックスは引き継がれないからです。
新しいタグに本当にインデックスがあるか確かめます。AWSが示しているのは次のコマンドで、期待される出力は、SOCIインデックスのartifactTypeを持つマニフェスト（イメージの構成要素を記したファイル）の一覧です。

aws ecr batch-get-image --repository-name "$REPOSITORY_NAME" \
  --image-ids imageTag="$SOCI_IMAGE_TAG" \
  --accepted-media-types "application/vnd.oci.image.index.v1+json" \
  --query 'images[0].imageManifest' --output text \
  | jq '.manifests[] | {mediaType, artifactType}'

ジョブのエントリーポイントとセットアップスクリプトを開き、Dockerコマンドを呼ぶ箇所、/var/run/docker.sockを読む箇所、cgroupのパスから識別子を取り出す箇所を探します。SOCIインデックス付きのイメージはcontainerdベースの実行環境で動くため、Dockerに頼っている箇所は壊れるおそれがある、とAWSは注意しています。実行の前に直してください。
イメージのタグだけを替えて、まったく同じジョブをもう一度実行し、同じ2つの数字と、最初のエポックの時間を記録します。

結果の読み方と、うまくいかないとき

コンテナの準備完了を待つ時間が数分から数秒に減り、ジョブ全体の時間が基準より短ければ完了です。最初のエポックが数秒遅くなっても構いません。最初のエポックがAWSの3〜16秒より大きく遅いなら、エントリーポイントがライブラリのディレクトリ全体を読んでいないか、イメージからデータを先読みしていないかを見てください。それはまさに、差し引きの利益が小さいとAWSが注意している場合です。元の取得方法に戻すか、先読みの手順をやめます。

ダウンロード時間が変わらなければ、次の順に確かめます。まず、イメージがAmazon ECRのプライベートリポジトリにない場合や、ジョブがTrainingRepositoryAccessModeをVpcにしている場合は、対象外なのでタグを替えても効果はありません。次に、イメージが約4 GB未満でないかを見ます。その場合、改善は小さいとAWSは述べています。最後に手順3に戻ります。タグがインデックスのないイメージを指している可能性があるからです。イメージにインデックスがない場合やインデックスが読めない場合、ジョブはいつもどおり全量をダウンロードするので、何も壊れませんが、得もありません。ジョブを送る前にローカルで試したいだけなら、元記事のリソースの節に、Finch（AWSのオープンソースのコンテナツール）でオンデマンド読み込みを試す手順の案内があります。

出典

AWS Machine Learning Blog「Announcing SOCI-indexed images for faster SageMaker AI jobs」 — 上記の数字、コマンド、注意点の出典。

Nguồn tham khảo

aws.amazon.com