AmazonSageMakerトレーニングジョブに最適なデータソースを選択してください

アマゾンセージメーカー は、機械学習 (ML) モデルの構築、トレーニング、デプロイを容易にするマネージド サービスです。 データ サイエンティストは、SageMaker トレーニング ジョブを使用して、ML モデルを簡単にトレーニングします。 コンピューティング リソースの管理について心配する必要はなく、実際のトレーニング時間に対してのみ料金を支払います。 データの取り込みはあらゆるトレーニング パイプラインに不可欠な部分であり、SageMaker トレーニング ジョブは、幅広いトレーニング ワークロードに適合するさまざまなデータ ストレージと入力モードをサポートしています。

この投稿は、SageMaker ML トレーニングのユースケースに最適なデータ ソースを選択するのに役立ちます。 SageMaker トレーニング ジョブがネイティブにサポートするデータ ソース オプションを紹介します。 データ ソースと入力モードごとに、その使いやすさ、パフォーマンス特性、コスト、制限事項について概説します。 すぐに開始できるように、主要なワークロードの特性に基づいて従うことができるサンプルの意思決定フローを図に示します。 最後に、現実的なトレーニング シナリオに対していくつかのベンチマークを実行し、全体的なトレーニングのコストとパフォーマンスに対する実際的な影響を示します。

ネイティブ SageMaker データ ソースと入力モード

パフォーマンスの高い方法でトレーニング データを簡単かつ柔軟に読み取ることは、ML トレーニングで繰り返し発生する一般的な懸念事項です。 SageMaker は、データ ソースと呼ばれる効率的で高スループットのデータ取り込みメカニズムとそれぞれの入力モードを選択することにより、データの取り込みを簡素化します。 これにより、実際のデータ ソースからトレーニング コードを分離し、ファイル システムを自動的にマウントし、高パフォーマンスで読み取り、GPU とインスタンス間のデータ シャーディングを簡単にオンにしてデータの並列処理を可能にし、各エポックの開始時にデータを自動シャッフルすることができます。

SageMaker トレーニング取り込みメカニズムは、次の XNUMX つの AWS マネージド ストレージ サービスとネイティブに統合されています。

• Amazon シンプル ストレージ サービス (Amazon S3) は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクト ストレージ サービスです。
• 光沢のためのAmazonFSx は、人気のある Lustre ファイル システムの拡張性とパフォーマンスを備えたフルマネージドの共有ストレージです。 通常、既存の S3 バケットにリンクされます。
• AmazonElasticファイルシステム (Amazon EFS) は、複数の価格帯を持つ汎用、スケーラブル、可用性の高い共有ファイル システムです。 Amazon EFS はサーバーレスであり、ファイルを追加および削除すると自動的に拡大および縮小します。

SageMaker トレーニングを使用すると、トレーニング スクリプトは、Amazon S3、FSx for Lustre、または Amazon EFS に保存されているデータセットに、あたかもローカル ファイル システム上で利用できるかのように (POSIX 準拠のファイル システム インターフェイス経由で) アクセスできます。

データ ソースとして Amazon S3 を使用すると、ファイル モード、FastFile モード、およびパイプ モードのいずれかを選択できます。

• ファイルモード – SageMaker は、Amazon S3 から ML インスタンスストレージにデータセットをコピーします。 Amazon Elastic Blockストア (Amazon EBS) ボリュームまたは NVMe SSD ボリューム (トレーニング スクリプトを開始する前)。
• 高速ファイルモード – SageMaker は、Amazon S3 に存在するデータセットをトレーニング インスタンス上の POSIX ファイル システムとして公開します。 データセット ファイルは、トレーニング スクリプトがデータセット ファイルを読み取るときに、オンデマンドで Amazon S3 からストリーミングされます。
• パイプモード – SageMaker は、Amazon S3 にあるデータセットを Unix パイプとして ML トレーニング インスタンスにストリーミングします。これは、トレーニング スクリプトがパイプからデータを読み取るときにオンデマンドで Amazon S3 からストリーミングします。

FSx for Lustre または Amazon EFS をデータソースとして使用すると、SageMaker はトレーニング スクリプトを開始する前にファイル システムをマウントします。

トレーニング入力チャンネル

SageMaker トレーニング ジョブを起動するときは、最大 20 個の管理対象ジョブを指定できます。 トレーニング入力チャンネル。 チャネルは、アルゴリズム コードがファイル システム パスから読み取るために利用できるデータをどこでどのように取得するかをトレーニング ジョブに指示するための抽象化単位と考えることができます (たとえば、 /opt/ml/input/data/input-channel-name) ML インスタンス上。 選択したトレーニング チャネルは、トレーニング ジョブの再現性やモデル ガバナンス目的などのユースケースで完全なモデル リネージ追跡を可能にするために、トレーニング ジョブ メタデータの一部としてキャプチャされます。

Amazon S3 をデータソースとして使用するには、 トレーニングインプット 次のように指定します。

• 入力モード (File、FastFile、または Pipe モード)
• 販売 & シャッフリング の監視
• An S3DataType データセットを構成する Amazon S3 内のオブジェクトを指定する XNUMX つの方法の XNUMX つとして使用します。
  • S3Prefix (S3 プレフィックスの下にあるすべてのオブジェクト)
  • マニフェストファイル (S3 オブジェクトのリスト)
  • 拡張されたマニフェスト ファイル (S3 オブジェクトとそれぞれのラベルのリスト)

あるいは、FSx for Lustre または Amazon EFS の場合は、 ファイルシステム入力.

次の図は、それぞれが異なるデータ ソースと入力モードの組み合わせで構成された XNUMX つのトレーニング ジョブを示しています。

データソースと入力モード

次のセクションでは、Amazon S3 (ファイル モード、FastFile モード、および Pipe モード)、FSx for Lustre、および SageMaker 取り込みメカニズムとしての Amazon EFS の違いを詳しく説明します。

Amazon S3 ファイルモード

ファイル モードはデフォルトの入力モード (明示的に指定しなかった場合) であり、より簡単に使用できます。 この入力オプションを使用すると、SageMaker は、モデルのトレーニングを開始する前に、ユーザーに代わって Amazon S3 から ML トレーニング インスタンス ストレージ (インスタンス タイプに応じて Amazon EBS またはローカル NVMe) にデータセットをダウンロードします。これにより、トレーニング スクリプトは、トレーニング スクリプトからデータセットを読み取ることができます。ローカルファイルシステム。 この場合、インスタンスには、データセット全体に適合するのに十分なストレージ容量が必要です。

S3 プレフィックス、マニフェスト ファイル、または拡張マニフェスト ファイルのいずれかを指定して、ファイル モードのデータセットを構成します。

すべてのデータセット ファイルが共通の S3 プレフィックス内にある場合は、S3 プレフィックスを使用する必要があります (サブフォルダーは問題ありません)。

マニフェスト ファイルには、データセットを構成するファイルがリストされます。 通常、マニフェストは、データ前処理ジョブがマニフェスト ファイルを生成する場合、またはデータセット ファイルが複数の S3 プレフィックスにまたがる場合に使用します。 拡張マニフェストは JSON 行ファイルで、各行には Amazon S3 内のファイルへの参照などの属性のリストと、追加の属性 (主にラベル) が含まれます。 その使用例はマニフェストの使用例と似ています。

ファイルモードは互換性があります SageMaker ローカル モード (SageMaker トレーニング コンテナを数秒で対話的に開始します)。 分散トレーニングの場合、次のコマンドを使用して複数のインスタンスにわたってデータセットをシャーディングできます。 ShardedByS3Key オプションを選択します。

ファイル モードのダウンロード速度は、データセット サイズ、平均ファイル サイズ、ファイル数によって異なります。 たとえば、データセットが大きくなるほど (またはデータセットに含まれるファイルが多くなればなるほど)、ダウンロード段階は長くなり、その間、インスタンスのコンピューティング リソースは実質的にアイドル状態のままになります。 スポット インスタンスを使用してトレーニングする場合、スポットの中断後にジョブが再開されるたびにデータセットがダウンロードされます。 通常、データのダウンロードは、大きなファイルの場合、約 200 MB/秒で行われます (たとえば、5 分/50 GB)。 この起動時のオーバーヘッドが許容できるかどうかは、主にトレーニング ジョブの全体的な期間によって決まります。これは、トレーニング フェーズが長いほどダウンロード フェーズが比例して短くなることを意味するためです。

Amazon S3 FastFile モード

FastFile モードは、トレーニング インスタンスのローカル ディスク上でファイルが利用可能であるかのように、POSIX 準拠のファイル システム インターフェイスを介して S3 オブジェクトを公開し、トレーニング スクリプトによってデータが消費されるときにオンデマンドでコンテンツをストリーミングします。 つまり、データセットをトレーニング インスタンスのストレージ スペースに収める必要がなくなり、トレーニングを開始する前にデータセットがトレーニング インスタンスにダウンロードされるのを待つ必要がなくなりました。

これを容易にするために、SageMaker はトレーニング スクリプトを実行する前に、指定された S3 プレフィックスの下に保存されているすべてのオブジェクト メタデータをリストします。 このメタデータは、読み取り専用のファイルを作成するために使用されます。 FUSE (ユーザー空間のファイル システム) これはトレーニング スクリプトで利用できます。 /opt/ml/data/training-channel-name。 S3 オブジェクトのリスト表示は、サイズに関係なく、5,500 秒あたり 3 個のオブジェクトの速度で実行されます。 これは、ファイル モードの場合と同様に、事前にファイルをダウンロードするよりもはるかに高速です。 トレーニング スクリプトの実行中、ファイルがローカルで利用可能であるかのようにファイルを一覧表示したり、読み取ったりできます。 各読み取り操作は FUSE サービスに委任され、実際のファイルのコンテンツを呼び出し元に配信するために Amazon SXNUMX への GET リクエストをプロキシします。 ローカル ファイル システムと同様に、FastFile はファイルをバイトとして扱うため、ファイル形式に依存しません。 FastFile モードは、複数のワーカーを使用して大きなファイルを順次読み取る場合、XNUMX GB/秒を超えるスループットに達する可能性があります。 FastFile を使用して小さなファイルを読み取ったり、ランダムなバイト範囲を取得したりできますが、そのようなアクセス パターンではスループットが低下することが予想されます。 多くの小さなファイルを大きなファイル コンテナーにシリアル化し、それらを順番に読み取ることで、読み取りアクセス パターンを最適化できます。

FastFile は現在 S3 プレフィックスのみをサポートしており (マニフェストおよび拡張マニフェストはサポートされていません)、FastFile モードは SageMaker ローカル モードと互換性があります。

Amazon S3 パイプモード

パイプ モードはもう XNUMX つのストリーミング モードであり、その大部分は、より新しくて使いやすい FastFile モードに置き換えられます。

パイプ モードでは、データは高い同時実行性とスループットで Amazon S3 からプリフェッチされ、Unix の名前付き FIFO パイプにストリーミングされます。 各パイプは単一のプロセスによってのみ読み取られます。 TensorFlow に対する SageMaker 固有の便利な拡張機能 Pipe モードをネイティブ TensorFlow データ ローダーに統合します ストリーミング テキスト、TFRecords、または RecordIO ファイル形式の場合。 パイプ モードは、データのマネージド シャーディングとシャッフルもサポートします。

光沢のためのFSx

FSx for Lustre は、低遅延のファイル取得により、数百 GB/秒のスループットと数百万の IOPS まで拡張できます。

トレーニング ジョブを開始するとき、SageMaker は FSx for Lustre ファイル システムをトレーニング インスタンス ファイル システムにマウントし、トレーニング スクリプトを開始します。 マウント自体は比較的高速な操作であり、FSx for Lustre に保存されているデータセットのサイズに依存しません。

多くの場合、FSx for Lustre ファイル システムを作成し、 S3 バケットとプレフィックスにリンクします。 ソースとして S3 バケットにリンクされている場合、ファイルは、トレーニング スクリプトがファイルを読み取るときにファイル システムに遅延ロードされます。 これは、最初のトレーニング実行の最初のエポックの直後に、データセット全体が Amazon S3 から FSx for Lustre ストレージにコピーされることを意味します (トレーニング例ではエポックが単一の完全なスイープとして定義されており、割り当てられた FSx が光沢ストレージは十分な大きさです）。 これにより、後続のエポックおよび同じデータセットを使用したトレーニング ジョブに対して低遅延のファイル アクセスが可能になります。

また、ワイルドカード*を使用すると、任意の文字にマッチし、XNUMXつのコマンドで複数のファイルを削除することができます。 ファイルをファイルシステムにプリロードする これにより、遅延読み込みによるコールド スタートが軽減されます。 同じ FSx for Lustre ファイル システムによってサービスされる複数のトレーニング ジョブを並行して実行することもできます。 FSx for Lustre にアクセスするには、トレーニング ジョブが VPC に接続する必要があります (「 VPCConfig 設定)、DevOps のセットアップと関与が必要です。 データ転送コストを回避するために、ファイル システムは単一のアベイラビリティ ゾーンを使用するため、トレーニング ジョブを実行するときにこのアベイラビリティ ゾーン ID を指定する必要があります。 Amazon S3 を長期データ ストレージとして使用しているため、高スループットを実現するコスト効率の高い短期ストレージの選択肢として、Scratch 2 ストレージを使用して FSx for Lustre をデプロイし、200 MB/秒のベースラインを提供することをお勧めします。プロビジョニングされたストレージの 1300 TB あたり最大 XNUMX MB/秒のバースト。

FSx for Lustre ファイル システムが常に実行されていると、ファイル システムが作成されるのを待たずに新しいトレーニング ジョブを開始でき、最初のエポック中のコールド スタートを心配する必要はありません (ファイルはまだキャッシュされている可能性があるため) FSx for Lustre ファイル システム)。 このシナリオの欠点は、ファイル システムの実行維持に関連する追加コストがかかることです。 あるいは、各トレーニング ジョブの前後にファイル システムを作成および削除することもできます (おそらく、スクリプトによる自動化が役立つでしょう)。ただし、FSx for Lustre ファイル システムの初期化には時間がかかります。これは、保持するファイルの数に比例します。たとえば、Amazon S2 から約 3 万個のオブジェクトのインデックスを作成するには、約 XNUMX 時間かかります)。

アマゾンEFS

ML トレーニング以外のユースケースにより、トレーニング データがすでに Amazon EFS に存在する場合は、Amazon EFS を使用することをお勧めします。 Amazon EFS をデータソースとして使用するには、トレーニング前にデータが Amazon EFS に存在している必要があります。 SageMaker は、指定された Amazon EFS ファイル システムをトレーニング インスタンスにマウントし、トレーニング スクリプトを開始します。 Amazon EFS ファイル システムを構成するときは、レイテンシーに最適化されたデフォルトの汎用パフォーマンス モード (小さなファイルに適しています) と、より高いレベルの総スループットに拡張できる最大 I/O パフォーマンス モードのどちらかを選択する必要があります。 XNUMX 秒あたりの操作数 (多数の I/O ワーカーを使用するトレーニング ジョブに適しています)。 詳細については、を参照してください。 適切なパフォーマンス モードの使用.

さらに、バースト スループットとプロビジョニング スループットの 1 つの従量制スループット オプションから選択できます。 150 TB ファイル システムのバースト スループットは 300 MB/秒のベースラインを提供しますが、12 日 3072 時間の期間では XNUMX MB/秒までバーストすることができます。 より高いベースライン スループットが必要な場合、またはバースト クレジットが何度も不足していることに気付いた場合は、ファイル システムのサイズを増やすか、プロビジョニングされたスループットに切り替えることができます。 プロビジョニングされたスループットでは、最大 XNUMX MB/秒の読み取りまで、必要なベースライン スループットに対して料金を支払います。

トレーニング ジョブは VPC に接続する必要があります (「 VPCConfig 設定) Amazon EFS にアクセスします。

最適なデータソースの選択

トレーニング ジョブに最適なデータ ソースは、データセット サイズ、ファイル形式、平均ファイル サイズ、トレーニング期間、シーケンシャルまたはランダム データ ローダー読み取りパターン、モデルがトレーニング データを消費する速度などのワークロードの特性によって異なります。

次のフローチャートは、開始に役立ついくつかのガイドラインを示しています。

Amazon EFS を使用する場合

データセットが主に Amazon EFS に保存されている場合は、ストレージに Amazon EFS を使用する前処理または注釈アプリケーションが存在する可能性があります。 Amazon EFS ファイル システムを指すデータ チャネルで構成されたトレーニング ジョブを簡単に実行できます (詳細については、「 Amazon FSx for LusterおよびAmazon EFSファイルシステムを使用して、Amazon SageMakerでのトレーニングを高速化します）。 パフォーマンスが期待したほど良くない場合は、最適化オプションを確認してください。 Amazon EFS パフォーマンスガイド、または他の入力モードを検討してください。

小規模なデータセットにはファイル モードを使用する

データセットが Amazon S3 に保存されており、その全体のボリュームが比較的小さい (たとえば、50 ～ 100 GB 未満) 場合は、ファイル モードを使用してみてください。. 50 GB のデータセットをダウンロードするオーバーヘッドは、ファイルの総数によって異なります (たとえば、5 MB のシャードに分割した場合は約 100 分)。 この起動時のオーバーヘッドが許容できるかどうかは、主にトレーニング ジョブの全体的な期間によって決まります。これは、トレーニング フェーズが長いほどダウンロード フェーズが比例して短くなることを意味するためです。

多数の小さなファイルをまとめてシリアル化する

データセットのサイズは小さい (50 ～ 100 GB 未満) ものの、多数の小さなファイル (50 MB 未満) で構成されている場合、各ファイルを Amazon S3 からトレーニング インスタンスのボリューム。 このオーバーヘッドを軽減し、一般にデータ トラバーサルを高速化するには、次のようなファイル形式を使用して、小さなファイルのグループを少数の大きなファイル コンテナー (ファイルあたり 150 MB など) にシリアル化することを検討してください。 TFレコード TensorFlowの場合、 ウェブデータセット PyTorch の場合、または 記録IO MXNet用。 これらの形式では、データ ローダーがサンプルを順番に繰り返す必要があります。 各エポックの後に TFRecord ファイルのリストをランダムに並べ替えたり、ローカル シャッフル バッファからデータをランダムにサンプリングしたりすることで、データをシャッフルすることもできます (次を参照) TensorFlow の例).

FastFile モードを使用する場合

より大きなファイル (50 MB を超える) を含む大規模なデータセットの場合、最初のオプションは FastFile モードを試すことです。これは、ファイル システムの作成や VPC への接続が必要ないため、FSx for Lustre よりも簡単に使用できます。 FastFile モードは、大きなファイル コンテナー (150 MB を超える) に最適ですが、50 MB を超えるファイルにも適している可能性があります。 FastFile モードは POSIX インターフェイスを提供するため、ランダム読み取り (非連続バイト範囲の読み取り) をサポートします。 ただし、これは理想的な使用例ではなく、おそらくシーケンシャル読み取りよりもスループットが低下するでしょう。 ただし、比較的大規模で計算量の多い ML モデルがある場合、FastFile モードでもトレーニング パイプラインの有効帯域幅が飽和状態になり、I/O ボトルネックが発生しない可能性があります。 実験して確認する必要があります。 幸いなことに、ファイル モードから FastFile モードへの切り替え (またはその逆) は、ファイルを追加 (または削除) するのと同じくらい簡単です。 input_mode='FastFile' SageMaker Python SDK を使用して入力チャネルを定義する際に、パラメータを追加します。

sagemaker.inputs.TrainingInput(S3_INPUT_FOLDER, input_mode='FastFile') 

他のコードや構成を変更する必要はありません。

Lustre に FSx を使用する場合

データセットがファイル モードには大きすぎる場合、小さなファイルが多数ある場合 (簡単にシリアル化できない)、またはランダム読み取りアクセス パターンがある場合は、FSx for Lustre を検討することをお勧めします。 そのファイル システムは、数百 GB/秒のスループットと数百万の IOPS まで拡張できるため、小さなファイルが多数ある場合に最適です。 ただし、すでに説明したように、遅延読み込みによるコールド スタートの問題と、FSx for Lustre ファイル システムのセットアップと初期化のオーバーヘッドに注意してください。

コストに関する考慮事項

大部分の ML トレーニング ジョブ、特に GPU または専用の ML チップを利用するジョブでは、トレーニングのコストのほとんどは、ML トレーニング インスタンスの請求対象秒数です。 月あたりのストレージ GB、API リクエスト、プロビジョニングされたスループットは、使用するデータ ソースに直接関連する追加コストです。

XNUMX か月あたりのストレージ GB

動画、LiDAR センサー データ、AdTech のリアルタイム入札ログなど、大規模なデータセットの場合、1 か月あたりのストレージ GB が大きくなる可能性があります。 たとえば、XNUMX TB を Amazon S3 インテリジェント階層化の高頻度アクセス階層 月額 23 ドルかかります。 Amazon S3 上に FSx for Lustre ファイル システムを追加すると、追加コストが発生します。 たとえば、データ圧縮を無効にして SSD バックアップの Scratch 1.2 タイプの 2 TB ファイル システムを作成すると、月額 168 ドルの追加料金がかかります (140TB/月あたり XNUMX ドル)。

Amazon S3 と Amazon EFS では、使用した分だけお支払いいただきます。つまり、実際のデータセットのサイズに応じて料金が請求されます。 FSx for Lustre では、プロビジョニングされたファイル システムのサイズ (最小 1.2 TB) に応じて料金が発生します。 EBS ボリュームで ML インスタンスを実行する場合、Amazon EBS は ML インスタンスとは独立して課金されます。 これは通常、インスタンスの実行コストに比べてはるかに低いコストです。 たとえば、3.2 GB EBS ボリュームを持つ ml.p100xlarge インスタンスを 1 時間実行すると、インスタンスに $3.825、EBS ボリュームに $0.02 かかります。

API リクエストとプロビジョニングされたスループット コスト

トレーニング ジョブがデータセットを処理している間、Amazon S3 API リクエストをディスパッチしてファイルをリストし、取得します。 たとえば、0.4 万件の GET リクエストの価格は 3 ドルです (Intelligent-Tiering クラスの場合)。 トレーニングは単一のアベイラビリティーゾーンで行われるため、Amazon SXNUMX の内外の帯域幅に対するデータ転送コストは発生しないと考えられます。

S3 バケットにリンクされた FSx for Lustre を使用する場合、FSx For Lustre はリクエストを Amazon S3 にプロキシする (そして結果をキャッシュする) ため、ファイル システムにまだキャッシュされていないデータを読み取るための Amazon S3 API リクエストのコストが発生します。 ）。 FSx for Lustre 自体には直接リクエストのコストはかかりません。 FSx for Lustre ファイル システムを使用する場合は、ファイル システムをプロビジョニングしたのと同じアベイラビリティ ゾーンに接続してトレーニング ジョブを実行することで、アベイラビリティ ゾーン間のデータ転送のコストを回避します。プロビジョニングされたスループットを備えた Amazon EFS では、それ以上の追加コストを考慮する必要があります。 XNUMX か月あたりの GB。

パフォーマンスのケーススタディ

前述のトレーニング パフォーマンスに関する考慮事項を実証するために、コンピューター ビジョン ドメインの現実的な使用例に対して一連のベンチマークを実行しました。 このセクションのベンチマーク (および要点) はすべてのシナリオに適用できるわけではなく、DNN など、使用したさまざまな事前決定要素の影響を受けます。 次の 12 の組み合わせについてテストを実行しました。

• 入力モード – FSx for Lustre、ファイル モード、FastFile モード
• データセットのサイズ – 小さいデータセット (1 GB)、大きいデータセット (54 GB)
• ファイルサイズ – 小さいファイル (JPG、約 39 KB)、大きいファイル (TFRecord、約 110 MB)

このケーススタディでは、最も広く使用されている入力モードを選択したため、Amazon EFS と Pipe モードは省略しました。

ケーススタディのベンチマークは、ml.p3.2xlarge シングル GPU インスタンス上のエンドツーエンドの SageMaker TensorFlow トレーニング ジョブとして設計されました。 分類タスクのバックボーン モデルとして有名な ResNet-50 を選択し、より小さなトレーニング データセットとして Caltech-256 を選択しました (より大きなデータセット バージョンを作成するために 50 回複製しました)。 トレーニング例では XNUMX 回の完全なスイープとして定義される XNUMX エポックでトレーニングを実行しました。

次のグラフは、各ベンチマーク シナリオの SageMaker トレーニング ジョブの合計請求可能時間を示しています。 ジョブの合計時間自体は、ダウンロード、トレーニング、およびその他の段階 (コンテナーの起動や、トレーニング済みのモデル アーティファクトの Amazon S3 へのアップロードなど) で構成されます。 請求可能時間が短縮されると、トレーニング ジョブがより速く、より安価になります。

まずは話し合いましょう シナリオ A とシナリオ Cこれは、データセットが多数の小さなファイルで構成されている場合の入力モード間のパフォーマンスの違いをわかりやすく示しています。

シナリオA (ファイルが小さく、データセットが小さい) ことから、FSx for Lustre ファイル システムを使用したトレーニング ジョブの請求可能時間が最小であることがわかります。 ダウンロード フェーズが最も短く、トレーニング ステージはファイル モードと同じくらい高速ですが、FastFile よりも高速です。 FSx for Lustre は、この単一エポック テストの勝者です。 そうは言っても、複数のエポックがある同様のワークロードを考えてみましょう。ダウンロード段階によるファイル モードの相対的なオーバーヘッドは、エポックが追加されるにつれて減少します。 この場合、使いやすさからファイル モードを好みます。 さらに、FSx for Lustre ファイル システムの料金を支払ってプロビジョニングするよりも、ファイル モードを使用して追加の請求対象秒数を支払う方が良い選択であることがわかる場合があります。

シナリオC (ファイルが小さく、データセットが大きい) では、FSx for Lustre が最速のモードとして示されており、合計請求可能時間はわずか 5,000 秒です。 また、FSx for Lustre ファイル システムのマウントはファイル システム内のファイル数 (この場合は 1.5 万ファイル) に依存しないため、ダウンロード段階が最も短くなります。 FastFile のダウンロードのオーバーヘッドも小さいです。 ファイルのコンテンツはトレーニング段階で読み取られますが、指定された S3 バケット プレフィックスの下にあるファイルのメタデータのみを取得します。 ファイル モードは最も遅いモードで、トレーニングを開始する前にデータセット全体を事前にダウンロードするのに 10,000 秒かかります。 トレーニング段階を見ると、FSx for Lustre モードとファイル モードは同様の優れたパフォーマンスを示しています。 FastFile モードに関しては、小さいファイルを Amazon S3 から直接ストリーミングする場合、(プリフェッチ バッファーを備えた高度な並列データローダーを使用しているにもかかわらず) ファイル転送の合計時間に比べて、各ファイルの新しい GET リクエストをディスパッチするためのオーバーヘッドが大きくなります。 その結果、FastFile モードのスループットが全体的に低下し、トレーニング ジョブの I/O ボトルネックが生じます。 このシナリオでは、FSx for Lustre が明らかに勝者です。

シナリオ B と D データセットが少数の大きなファイルで構成されている場合の、入力モード間のパフォーマンスの違いを示しています。 より大きなファイルを使用して順次読み取ると、効果的なバッファリングが可能になり、I/O 操作の数が減るため、通常、I/O パフォーマンスが向上します。

シナリオB (ファイルが大きく、データセットが小さい) は、すべてのモードで同様のトレーニング ステージ時間を示しています (トレーニングが I/O バウンドではないことを証明しています)。 このシナリオでは、ダウンロード段階が短いため、ファイル モードよりも FastFile モードを好みます。また、前者の使いやすさのため、FSx for Lustre よりも FastFile モードを好みます。

シナリオD (より大きなファイル、より大きなデータセット) は、54 つのモードすべてで比較的類似した合計請求可能時間を示しています。 ファイル モードのダウンロード フェーズは、FSx for Lustre および FastFile のダウンロード フェーズよりも長くなります。 ファイルモードでは、トレーニングステージを開始する前に、Amazon S3 からトレーニングインスタンスにデータセット全体 (4 GB) をダウンロードします。 すべてのモードは十分な速度でデータをフェッチでき、GPU 依存であるため、24 つのモードはすべてトレーニング フェーズで同様の時間を費やします。 ml.p3.2d.3.8xlarge など、追加の CPU または GPU リソースを備えた ML インスタンスを使用すると、コンピューティング リソースを飽和させるために必要なデータ I/O スループットが増加します。 このような場合、FastFile と FSx for Lustre がスループットを正常に拡張できることが期待できます (ただし、FSx for Lustre のスループットはプロビジョニングされたファイル システムのサイズに依存します)。 ファイル モードがスループットを拡張できるかどうかは、インスタンスに接続されているディスク ボリュームのスループットによって異なります。 たとえば、Amazon EBS ベースのインスタンス (ml.p3.16xlarge、ml.p250xlarge、ml.p5xlarge など) は最大スループット 4MB/s に制限されますが、ローカル NVMe ベースのインスタンス (ml.p24xlarge、ml.pXNUMXxlarge、ml.pXNUMXxlarge など) は最大スループットが XNUMXMB/s に制限されます。 gXNUMX.* または ml.pXNUMXd.XNUMXxlarge) は、はるかに大きなスループットに対応できます。

要約すると、FastFile はファイル モードよりも高速で、FSx for Lustre と同じくらい高速でありながら、より簡単に使用でき、コストが低く、必要に応じてスループットを簡単にスケールアップできるため、このシナリオでは FastFile が勝者であると考えられます。

さらに、はるかに大きなデータセット (サイズが数 TB) がある場合、ファイル モードではトレーニングを開始する前にデータセットのダウンロードに何時間もかかりますが、FastFile ではトレーニングをより迅速に開始できます。

独自のデータ取り込みを導入する

SageMaker のネイティブ データ ソースは、考えられるすべてではありませんが、ほとんどの ML トレーニング シナリオに適合します。 他のデータ取り込みオプションを探す必要がある状況には、サードパーティのストレージ製品から直接データを読み取る場合 (Amazon S3 への簡単かつタイムリーなエクスポートが不可能であると仮定)、または同じトレーニングに対する強い要件がある場合が含まれます。 SageMaker と SageMaker の両方で変更せずに実行されるスクリプト アマゾン エラスティック コンピューティング クラウド （Amazon EC2）または Amazon Elastic Kubernetesサービス (アマゾンEKS)。 データ取り込みメカニズムをトレーニング スクリプトに実装することで、これらのケースに対処できます。 このメカニズムは、外部データ ソースからトレーニング インスタンスにデータセットを読み取る役割を果たします。 たとえば、 TFRecordDataset TensorFlow の tf.data ライブラリは Amazon S3 ストレージから直接読み取ることができます。

データ取り込みメカニズムで AWS のサービスを呼び出す必要がある場合は、 Amazon リレーショナル データベース サービス (Amazon RDS)、 AWS IDおよびアクセス管理 トレーニング ジョブの (IAM) 役割には、関連する IAM ポリシーが含まれます。 データ ソースが次の場所にある場合 アマゾン バーチャル プライベート クラウド (Amazon VPC)、同じ VPC に接続してトレーニング ジョブを実行する必要があります。

データセットの取り込みを自分で管理している場合、SageMaker リネージ追跡はトレーニング中に使用されたデータセットを自動的にログに記録できません。 したがって、関連するメタデータを取得するには、トレーニング ジョブ タグやハイパーパラメータなどの代替メカニズムを検討してください。

まとめ

適切な SageMaker トレーニング データ ソースの選択は、ML モデルのトレーニングの速度、使いやすさ、コストに大きな影響を与える可能性があります。 提供されているフローチャートを使用して、すぐに開始し、結果を観察し、必要に応じて追加の構成を試してください。 各データ ソースの長所、短所、制限と、それらがトレーニング ジョブの個々の要件にどの程度適合するかを念頭に置いてください。 さらに詳しい情報とサポートが必要な場合は、AWS の担当者にお問い合わせください。

著者について

ギリナチュム は、EMEAのAmazonMachineLearningチームの一員として働くシニアAI/MLスペシャリストソリューションアーキテクトです。 Giliは、ディープラーニングモデルのトレーニングの課題と、機械学習が世界をどのように変えているかについて情熱を注いでいます。 暇なときは、ギリは卓球を楽しんでいます。

アレクサンダーアルザノフ博士 ドイツのフランクフルトを拠点とするAI/MLスペシャリストソリューションアーキテクトです。 彼は、AWSのお客様がEMEA地域全体でMLソリューションを設計およびデプロイするのを支援しています。 AWSに参加する前、アレクサンダーは私たちの宇宙の重元素の起源を研究しており、大規模な科学計算でMLを使用した後、MLに情熱を注いでいました。

• コインスマート。 ヨーロッパで最高のビットコインと暗号通貨取引所。
• Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 出入り自由。
• CryptoHawk。 アルトコインレーダー。 無料トライアル。
• 出典: https://aws.amazon.com/blogs/machine-learning/choose-the-best-data-source-for-your-amazon-sagemaker-training-job/