Amazon SageMaker での TensorFlow 1.x アクセラレーション トレーニングのベスト プラクティス

現在、多くのお客様が TensorFlow を使用して、広告のクリック率や e コマースのパーソナライズ推奨事項の深層学習モデルをトレーニングしています。 クライアントの行動が変化するにつれて、毎日大量の新しいデータが蓄積される可能性があります。 モデルの反復はデータ サイエンティストの日常業務の XNUMX つですが、大規模なデータセットのトレーニングに時間がかかりすぎるという問題に直面しています。

アマゾンセージメーカー TensorFlow や PyTorch などの独自のアルゴリズムとフレームワークをネイティブにサポートすることで、データ サイエンティストがインフラストラクチャではなくモデルに集中できるようにする、フル マネージドの機械学習 (ML) プラットフォームです。 SageMaker は、特定のワークフローに合わせて調整する柔軟な分散トレーニング オプションを提供します。 多くのデータ サイエンティストは加速トレーニング プロセスの経験が不足している可能性があるため、この投稿では、高速ディープ ラーニング モデル トレーニングに重要な要因と、SageMaker での TensorFlow 1.x の加速トレーニングのベスト プラクティスを紹介します。 のサンプルコードもあります DeepFM 上の SageMaker での分散トレーニング GitHubレポ.

SageMaker で TensorFlow スクリプトを実行するときに、CPU/GPU 使用率を最大化するために考慮すべき要素は多数あります。たとえば、インフラストラクチャ、アクセラレータの種類、分散トレーニング方法、データ読み込み方法、混合精度トレーニングなどです。

次の分野のベスト プラクティスについて説明します。

• 単一のインスタンスでトレーニングを加速する
• 複数のインスタンスでトレーニングを加速する
• データパイプライン
• 自動混合精度トレーニング

単一のインスタンスでトレーニングを加速する

TensorFlow スクリプトを XNUMX つのインスタンスで実行する場合、次のようなコンピューターに最適化されたシリーズを選択できます。 アマゾン エラスティック コンピューティング クラウド (Amazon EC2) C5 シリーズ、または p3.8xlarge、p3.16xlarge、p3dn.24xlarge、p4d.24xlarge などの単一インスタンスに複数の GPU を備えた高速コンピューティング シリーズ。

このセクションでは、XNUMX つのインスタンスで複数の CPU を使用するための戦略と、XNUMX つのインスタンスで複数の GPU を使用した分散トレーニングについて説明します。

XNUMX つのインスタンスに複数の CPU

このセクションでは、CPU デバイス、タワー方式、TensorFlow MirroredStrategy、および Horovod でオペレーターの並列処理を手動で設定する方法について説明します。

CPU デバイスでのオペレーターの並列処理の手動設定

TensorFlow は、トレーニング プロセスで演算計算を並列化するために適切な数のスレッドを自動的に選択します。 ただし、 intra_op スレッドプールと inter_op TensorFlow によって提供される並列処理設定を使用し、MKL-DNN の環境変数を使用して OS スレッドのバインドを設定します。 次のコードを参照してください。

# Set parallelism of intra_op and inter_op
num_cpus = int(os.environ['SM_NUM_CPUS'])
config = tf.ConfigProto(allow_soft_placement=True, device_count={'CPU': num_cpus}, intra_op_parallelism_threads=num_cpus, inter_op_parallelism_threads=num_cpus)
run_config = tf.estimator.RunConfig().replace(session_config = config)

# Use Intel MKL-DNN Setting to accelerate training speed
os.environ["KMP_AFFINITY"]= "verbose,disabled"
os.environ['OMP_NUM_THREADS'] = str(num_cpus)
os.environ['KMP_SETTINGS'] = '1'

環境変数 KMP_AFFINITY MKL-DNN の granularity=fine,compact,1,0 デフォルトで。 TensorFlow のイントラとインターの両方を現在のインスタンスの vCPU の最大数に設定した後、CPU 使用の上限はトレーニング インスタンスの物理コアの数とほぼ同じになります。

設定した場合 os.environ["KMP_AFFINITY"]= "verbose,disabled"OS スレッドがハードウェア ハイパー スレッドにバインドされていないため、CPU 使用率が物理コアの数を超える可能性があります。

TensorFlow の内部並列処理、TensorFlow の相互並列処理、および MKL-DNN スレッドの数の設定に関して、これら XNUMX つのパラメーターの組み合わせが異なると、トレーニング速度が異なります。 したがって、それぞれのケースをテストして、最適な組み合わせを見つける必要があります。 一般的な状況は、XNUMX つのパラメーターを設定することです (intra_op_parallelism_threads & inter_op_parallelism_threads TensorFlowの場合、 os.environ['OMP_NUM_THREADS'] MKL-DNN の場合) を vCPU (物理コア) の数または vCPU の総数の半分にします。

タワー方式

GPU を介してモデルをレプリケートするために、各 GPU はフォワード パスの独自のインスタンスを取得します。 フォワード パスのインスタンスは、 タワー. タワー方式は、ほとんどの場合、GPU デバイスに使用されます。 トレーニング速度を他の方法と比較するために、ここでも CPU デバイスにタワー方式を使用します。

CPU デバイスを手動で設定しない場合、TensorFlow は勾配の平均化にタワー方式を使用しないため、そのような場合にバッチ サイズをスケーリングする必要はありません。

1. CPU デバイスを手動で設定します。

device_list = []
if manual_CPU_device_set:
		cpu_prefix=’/cpu:’
		for I in range(1, num_cpus):
			devices_list.append(cpu_prefix + str(i))

2. 　 replicate_model_fn ラップします model_fn:

DeepFM = tf.estimator.Estimator(model_fn=tf.contrib.estimator.replicate_model_fn(model_fn, devices=device_list), model_dir=FLAGS.model_dir, params=model_params, config=config)

3. 　 TowerOptimizer ラップします optimizer:

optimizer = tf.contrib.estimator.TowerOptimizer(optimizer)

4. あなたを包む model_fn:

with tf.variable_scope(‘deepfm_model’, reuse=tf.AUTO_REUSE)

5. バッチ サイズを (NUM_CPU – 1) にスケーリングします。

タワー モードを有効にした場合の CPU 使用率の違いを見てみましょう。 次の図は、次の構成での ml.c5.18xlarge インスタンスの CPU 使用率を示しています。

Tower なし + LibSVM データ + パイプ モード + MKL-DNN バインディングの無効化 + TensorFlow イントラ/インター オペレーション並列処理をインスタンスの vCPU の最大数に設定

次の図は、次の構成での ml.c5.18xlarge インスタンスの CPU 使用率を示しています。

CPU デバイスが設定された Tower + LibSVM データ + パイプモード + MKL-DNN 無効化バインディング + TensorFlow イントラ/インター op 並列処理をインスタンスの vCPU の最大数に設定

タワー方式の方がCPU使用率が高く、物理コア数を超えています。

TensorFlow Mirrored戦略

TensorFlow MirroredStrategy は、XNUMX 台のマシンで複数のレプリカにまたがる同期トレーニングを意味します。 この戦略は通常、複数の GPU を備えた XNUMX 台のマシンでのトレーニングに使用されます。 トレーニング速度を別の方法と比較するために、CPU デバイスに MirroredStrategy を使用します。

TensorFlow MirroredStrategy を使用する場合、CPU デバイスを設定しないと、TensorFlow は XNUMX つの CPU を単一のワーカーとして使用するだけで、リソースが無駄になります。 CPU デバイスを手動で設定することをお勧めします。 /CPU:0ので、 /CPU:0 ここでは、デバイスはレプリカとして使用されません。 次のコードを参照してください。

device_list = []
if manual_CPU_device_set:
		cpu_prefix=’/cpu:’
		for I in range(1, num_cpus):
			devices_list.append(cpu_prefix + str(i))
mirrored_strategy = tf.distribute.MirroredStrategy(devices=devices_list)
	else:
mirrored_strategy = tf.distribute.MirroredStrategy()

# Set strategy to config:
config = tf.estimator.RunConfig(train_distribute=mirrored_strategy,
eval_distribute=mirrored_strategy,
session_config = config)

MirroredStrategy を使用する場合は、バッチ サイズをスケーリングする必要があります。 たとえば、バッチ サイズを GPU デバイスの数の倍数にスケーリングします。

CPUデバイスを設定した場合のサブ戦略については、CPUデバイスを設定しない場合 cross_device_ops のパラメータ tf.distribute.MirroredStrategy()、TensorFlow は ReductionToOneDevice デフォルトではサブ戦略。 ただし、設定すると HierarchicalCopyAllReduce サブ戦略として、TensorFlow は削減作業を行うだけです /CPU:0. TensorFlow データセット API を使用して戦略を配布する場合、関数内の特徴とラベルの代わりにデータセット オブジェクトを返す必要があります。 input_fn.

通常、TensorFlow MirroredStrategy は CPU トレーニングのタワー メソッドよりも遅いため、マルチ CPU の単一ホストで MirroredStrategy を使用することはお勧めしません。

ホロヴォード

ホロヴォード TensorFlow、Keras、PyTorch、および Apache MXNet 用の分散型ディープ ラーニング トレーニング フレームワークです。 Horovod の目標は、分散型ディープ ラーニングを高速で使いやすいものにすることです。

というパラメータがあります distribution これは、Horovod 分散トレーニングを記述するために使用できます。 SageMaker はインフラストラクチャをプロビジョニングし、MPI でスクリプトを実行します。 次のコードを参照してください。

hvd_processes_per_host = 4
distribution = {'mpi': { 
'enabled': True, 
'processes_per_host': hvd_processes_per_host,
'custom_mpi_options': '-verbose --NCCL_DEBUG=INFO -x OMPI_MCA_btl_vader_single_copy_mechanism=none' 
} 
}

ml.p3.8xlarge などの GPU インスタンスを選択する場合、すべてのワーカーに対して各 GPU を固定する必要があります。

config = tf.ConfigProto()
config.gpu_options.visible_device_list = str(hvd.local_rank())

モデルの収束を高速化するには、Horovod の公式ドキュメントに従って、学習率をワーカー数でスケーリングします。 ただし、実際のプロジェクトでは、ワーカーの数ではなく、学習率をある程度スケーリングする必要があります。これにより、モデルのパフォーマンスが低下します。 たとえば、元の学習率が 0.001 の場合、ワーカーの数が 0.0015 つ以上であっても、学習率を XNUMX にスケーリングします。

通常、プライマリ (Horovod ランク 0) のみがチェックポイントとモデル、および評価操作を保存します。 Horovod を使用する場合、バッチ サイズをスケーリングする必要はありません。 SageMaker オファー パイプモード データをストリーミングする Amazon シンプル ストレージ サービス (Amazon S3) をトレーニング インスタンスに追加します。 パイプ モードを有効にする場合は、エラーを回避するために、同じホスト上の異なるワーカーが異なるチャネルを使用する必要があることに注意してください。 これは、最初のワーカー プロセスが FIFO/チャネル データを読み取り、同じインスタンスの他のワーカー プロセスが同じ FIFO/チャネルからデータを読み取ることができないためにハングし、Horovod が適切に動作しないためです。 この問題を回避するには、インスタンスごとのワーカー数に応じてチャネルを設定します。 少なくとも、同じホスト上の異なるワーカーが異なるチャネルを使用していることを確認してください。 同じチャネルを別のホストのワーカーが使用できます。

Horovod を使用すると、次のエラーが発生する場合があります。

“One or more tensors were submitted to be reduced, gathered or broadcasted by subset of ranks and are waiting for remainder of ranks for more than 60 seconds. This may indicate that different ranks are trying to submit different tensors or that only subset of ranks is submitting tensors, which will cause deadlock.”

この問題の原因として考えられるのは、特定のランク (ランク 0 など) の動作が他のランクよりも遅いか、他のランクよりも多くのジョブを実行し、これにより他のランクが長時間待機することです。 ランク 0 は他のランクよりも多くの作業を行う必要がある場合がありますが、ランク 0 は長時間にわたって多くの作業を行うべきではないことに注意してください。 たとえば、検証セットでのモデル評価とトレーニング中のチェックポイントの保存について、これらの操作に時間がかかり、エラーが発生する可能性があることが避けられない場合、0 つの回避策は、すべてのワーカーがランク XNUMX と同じ作業を行うようにすることです (チェックポイント保存、評価など)。

データ シャーディングは、分散トレーニングを使用する際に考慮すべき最も重要なことの XNUMX つです。 TensorFlow を使用できます dataset.shard() あなたのスクリプトで。 SageMaker は、データセット シャード機能も提供します。 入力チャンネル 設定することにより distribution=S3shardbykey データセット チャネルで。 次のコードを参照してください。

dataset = PipeModeDataset(channel, record_format='TFRecord')

number_host = len(FLAGS.hosts)

if FLAGS.enable_data_multi_path : # If there are multi channels mapping with different S3 path
    if FLAGS.enable_s3_shard == False :
        if number_host > 1:
            index = hvd.rank() // FLAGS.worker_per_host
            dataset = dataset.shard(number_host, index)
else :
    if FLAGS.enable_s3_shard :
        dataset = dataset.shard(FLAGS.worker_per_host, hvd.local_rank())
    else :
        dataset = dataset.shard(hvd.size(), hvd.rank())

次の図は、Horovod (ml.c5.18xlarge、Horovod + LibSVM + default intra op および inter op 設定) を使用した場合の結果を示しており、tower 方式と比較できます。

XNUMX つのインスタンスで複数の GPU を使用した分散トレーニング

データ サイエンティストは 3.8 つのインスタンスのみを管理し、GPU 間の高速相互リンクを利用する必要があるため、3.16 つのインスタンスで複数の GPU を使用して分散トレーニングを開始するのが普通です。 SageMaker トレーニング ジョブは、ml.p3xlarge、ml.p24xlarge、ml.p4dn.24xlarge、ml.pXNUMXd.XNUMXxlarge など、XNUMX つのインスタンスに複数の GPU を持つ複数のインスタンス タイプをサポートします。 この方法は、単一インスタンス内の複数の CPU と同じですが、スクリプトにいくつかの変更があります。

タワー方式

ここでのタワー法は、マルチ CPU トレーニングとほぼ同じです。 使用中の GPU の数に応じてバッチ サイズをスケーリングする必要があります。

TensorFlow Mirrored戦略

のデフォルトのサブ戦略 MirroredStrategy is NcclAllReduce. 使用中の GPU の数に応じてバッチ サイズをスケーリングする必要があります。 次のコードを参照してください。

mirrored_strategy = tf.distribute.MirroredStrategy()
config = tf.estimator.RunConfig(train_distribute=mirrored_strategy,
				eval_distribute=mirrored_strategy)

複数のインスタンスでトレーニングを加速する

スケールアウトは、トレーニング速度を改善するためのオプションです。 分散トレーニングに関して、これをデフォルトのオプションとして選択するデータ サイエンティストが増えています。 このセクションでは、複数のホストを使用した分散トレーニングの戦略について説明します。

複数のインスタンスを持つ複数の CPU

分散トレーニングを有効にするときに、複数のインスタンスで複数の CPU を使用する主な方法は XNUMX つあります。

• • CPUデバイスにオペレータの並列性を手動で設定しないパラメータサーバー
  • CPUデバイスにオペレータの並列性を手動で設定するパラメータサーバー
  • タワー付きパラメーターサーバー (CPU デバイスを手動で設定し、設定する allow_soft_placement=True in tf.ConfigProto)
  • ホロヴォード

でパラメーターサーバーを使用する場合 tf.estimator API、チェックポイントのパスは、Amazon S3 などの共有可能なパスまたはローカル パスである必要があります。 Amazon エラスティック ファイル サービス (Amazon EFS) コンテナへのマッピング。 パラメータ サーバの場合 tf.keras、チェックポイント パスをローカル パスに設定できます。 Horovod の場合、チェックポイント パスをトレーニング インスタンスのローカル パスに設定できます。

パラメータサーバーと tf.estimator Amazon S3 へのチェックポイント パスを持つ API では、モデルが非常に大きい場合、S3 へのチェックポイントの保存時にプライマリがスタックするというエラーが発生する可能性があります。 SageMaker 組み込みコンテナ TensorFlow 1.15 または TensorFlow 1.15.2 を使用するか、共有のチェックポイント パスとして Amazon EFS を使用できます。

複数のホストにパラメーター サーバーを使用する場合、各パラメーター サーバー プロセスのパラメーターの負荷が不均衡になる可能性があり (特に、比較的大きな埋め込みテーブル変数がある場合)、エラーが発生する可能性があります。 各パラメータ サーバーはチェックポイント ファイルのシャードに対応するため、Amazon S3 の各シャードのチェックポイントのファイル サイズをチェックして、パラメータ サーバーのパラメータがバランスが取れているかどうかを判断できます。 このような問題を回避するには、パーティショナー機能を使用して、各パラメーター サーバーのパラメーターを均等に分散させます。

with tf.variable_scope('deepfm_model', reuse=tf.AUTO_REUSE, partitioner = tf.fixed_size_partitioner(num_shards=len(FLAGS.hosts))):

複数のインスタンスを持つ単一の GPU

SageMaker トレーニング ジョブは、ml.p3.xlarge、ml.g4dn、ml.g5 シリーズなど、GPU が XNUMX つしかないインスタンスをサポートします。 このシナリオで使用される主な方法は XNUMX つあります。パラメーター サーバーと Horovod です。

SageMaker の組み込みパラメータ サーバー分散トレーニング方法は、各トレーニング インスタンスに対してパラメータ サーバー プロセスとワーカー プロセスを開始することです (各パラメータ サーバーはモデル パラメータの一部のみを担当します)。 GPU トレーニング。 SageMaker 組み込みパラメーター サーバー分散トレーニングは、非同期勾配更新メソッドです。 トレーニングの収束に対する非同期更新の影響を軽減するには、学習率を下げることをお勧めします。 インスタンス上のすべての GPU を使用する場合は、パラメーター サーバーとタワー方式を組み合わせて使用​​する必要があります。

Horovod の場合は、設定するだけです processes_per_host=1 SageMaker Python Estimator API の分布パラメーターで。

複数のインスタンスを持つ複数の GPU

パラメーター サーバーとタワー方式の場合、コードの変更は複数の GPU を持つ単一インスタンスのタワー方式と基本的に同じであり、GPU デバイスを手動で設定する必要はありません。

Horovod の場合、分散パラメーターの processes_per_host を各トレーニング インスタンスの GPU の数に設定します。 パイプ モードを使用する場合、インスタンスあたりのワーカー数はチャネル数と一致する必要があります。

データパイプライン

これまで説明してきたインフラストラクチャに加えて、考慮すべき重要な点がもう XNUMX つあります。データ パイプラインです。 データ パイプラインとは、データをニューラル ネットワークにフィードする前にデータを読み込んで変換する方法を指します。 CPU はデータの準備に使用され、GPU は CPU からのデータの計算に使用されます。 GPU は高価なリソースであるため、GPU のアイドル時間が長くなると非効率的になります。 トレーニング ジョブの優れたデータ パイプラインにより、GPU と CPU の使用率が向上する可能性があります。

TensorFlow データ入力パイプラインを最適化しようとしているときは、で使用される API の順序を考慮してください。 TensorFlow データセット、トレーニング データのサイズ (多数の小さなファイルまたはいくつかの大きなファイル)、バッチ サイズなど。

トレーニング中の GPU と CPU 間の相互作用を見てみましょう。 次の図は、パイプラインがある場合とない場合の相互作用を比較しています。

パイプラインを改善すると、GPU のアイドル時間が短縮される可能性があります。 次のヒントを考慮してください。

• 特徴とラベルの抽出に単純な関数ロジックを使用する
• サンプルをメモリにプリフェッチする
• 不要なディスク I/O とネットワーク I/O を減らす
• 処理された特徴とラベルをメモリにキャッシュする
• CPU と GPU 間のレプリケーション回数を減らす
• さまざまなワーカーにトレーニング データセットのさまざまな部分を処理させる
• TensorFlow データセット API を呼び出す回数を減らす

TensorFlow はデータセット形式に関連する変換 API を提供しており、TensorFlow での変換 API の順序はトレーニング速度に大きく影響します。 TensorFlow データセット API を呼び出す最適な順序をテストする必要があります。 以下にいくつかの基本原則を示します。

• ベクトル化されたマップを使用します。 これは、最初に TensorFlow データセット バッチ API を呼び出し、次にデータセット マップ API を呼び出すことを意味します。 次のように、map 関数で提供されるカスタム解析関数 decode_tfrecord サンプル コードでは、データのミニ バッチを解析します。 反対に、最初にマップしてからバッチはスカラー マップであり、カスタム パーサー関数は XNUMX つのサンプルのみを処理します。
• TensorFlow データセット キャッシュ API を使用して、特徴とラベルをキャッシュします。 TensorFlow データセット キャッシュ API を TensorFlow データセット リピート API の前に置きます。そうしないと、RAM 使用率がエポックごとに直線的に増加します。 データセットが RAM と同じくらい大きい場合は、TensorFlow データセット キャッシュ API を使用しないでください。 TensorFlow データセット キャッシュ API とシャッフル API を使用する必要がある場合は、TensorFlow データセット オブジェクトの作成 -> キャッシュ API -> シャッフル API -> バッチ API -> マップ API -> リピート API -> プリフェッチ API の順序で使用することを検討してください。
• tfrecord LibSVM 形式以上のデータセット形式。
• ファイル モードまたはパイプ モードは、データセットの形式とファイルの量によって異なります。 の tfrecorddataset API設定可能 num_parallel_reads 複数のファイルを並行して読み込んで設定する buffer_size データの読み取りを最適化しますが、 pipemodedataset APIにはそのような設定はありません。 パイプ モードは、XNUMX つのファイルが大きく、ファイルの総数が少ない場合に適しています。 SageMaker 処理ジョブを使用して、ラベルに従って複数のファイルをより大きなファイルに結合する、サンプリング方法を使用してデータセットをよりバランスの取れたものにする、バランスのとれたデータセットをシャッフルするなどの前処理作業を行うことをお勧めします。

次のコード サンプルを参照してください。

def decode_tfrecord(batch_examples):
        # The feature definition here should BE consistent with LibSVM TO TFRecord process.
        features = tf.parse_example(batch_examples,
                                           features={
                                               "label": tf.FixedLenFeature([], tf.float32),
                                               "ids": tf.FixedLenFeature(dtype=tf.int64, shape=[FLAGS.field_size]),
                                               "values": tf.FixedLenFeature(dtype=tf.float32, shape=[FLAGS.field_size]) 
                                           })
        
        batch_label = features["label"]
        batch_ids = features["ids"]
        batch_values = features["values"]
        
        return {"feat_ids": batch_ids, "feat_vals": batch_values}, batch_label


    def decode_libsvm(line):
        columns = tf.string_split([line], ' ')
        labels = tf.string_to_number(columns.values[0], out_type=tf.float32)
        splits = tf.string_split(columns.values[1:], ':')
        id_vals = tf.reshape(splits.values,splits.dense_shape)
        feat_ids, feat_vals = tf.split(id_vals,num_or_size_splits=2,axis=1)
        feat_ids = tf.string_to_number(feat_ids, out_type=tf.int32)
        feat_vals = tf.string_to_number(feat_vals, out_type=tf.float32)
        return {"feat_ids": feat_ids, "feat_vals": feat_vals}, labels

if FLAGS.pipe_mode == 0:
        dataset = tf.data.TFRecordDataset(filenames)
    else :
        # Enter Pipe mode
        dataset = PipeModeDataset(channel, record_format='TFRecord')
        
    if FLAGS.enable_s3_shard == False:
        host_rank = FLAGS.hosts.index(FLAGS.current_host)
        number_host = len(FLAGS.hosts)
        dataset = dataset.shard(number_host, host_rank)
    
    dataset = dataset.batch(batch_size, drop_remainder=True) # Batch size to use
    dataset = dataset.map(decode_tfrecord,
                          num_parallel_calls=tf.data.experimental.AUTOTUNE) 

    if num_epochs > 1:
        dataset = dataset.repeat(num_epochs)
    dataset = dataset.prefetch(buffer_size=tf.data.experimental.AUTOTUNE)

CPU インスタンスでのトレーニングの場合、並列処理の設定 intra op, inter op、MKL-DNN の環境変数は良い出発点です。

自動混合精度トレーニング

最後に説明するのは、自動混合精度トレーニングです。これにより、速度が向上し、モデルのパフォーマンスが向上します。 この記事の執筆時点では、Nvidia V100 GPU (P3 インスタンス) と A100 (P4dn インスタンス) が Tensor コアをサポートしています。 これらのタイプのインスタンスを使用する場合、TensorFlow で混合精度トレーニングを有効にすることができます。 バージョン 1.14 以降、TensorFlow は自動混合精度トレーニングをサポートしています。 次のステートメントを使用して、元のオプティマイザをラップできます。

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

モデルが小さく、GPU の使用率が低い場合、自動混合精度トレーニングの利点はありません。 モデルが大きい場合、自動混合精度トレーニングはトレーニング速度を加速できます。

まとめ

SageMaker で深層学習モデルのトレーニングを開始するときは、トレーニング速度を向上させるために次のヒントを考慮してください。

• 最初に、マルチ CPU、単一インスタンスの方法、または単一 GPU、単一インスタンスの方法を試してください。 CPU/GPU 使用率が非常に高い場合 (たとえば 90% 以上)、次のステップに進みます。
• 単一ホストでより多くの CPU を試すか、単一ホストでより多くの GPU を試してください。 使用率が CPU または GPU の最大使用率に近い場合は、次のステップに進みます。
• 複数のホストで複数の CPU または複数の GPU を試してください。
• パラメーター サーバーまたは Horovod を使用する場合は、コードを変更する必要があります。 コードの変更は、TensorFlow セッション ベースの API と同じではありません。 tf.estimator API、および tf.keras API。 パラメータ サーバーまたは Horovod は、さまざまなトレーニング ケースやタスクでさまざまなトレーニング速度を示す場合があるため、最適な方法を決定する時間と予算がある場合は、両方の方法を試してください。

次のアドバイスを覚えておいてください。

• スケーリングの前に使用率を確認し、データ パイプラインを最適化し、タイムラインで CPU と GPU をオーバーラップさせます。
• 最初にスケールアップしてから、スケールアウトします。
• すべての方法を試しても GPU 使用率を上げられない場合は、CPU を試してください。 多くの場合 (特にクリック率ランキング モデルの場合)、CPU インスタンス トレーニングの合計トレーニング時間が GPU インスタンス トレーニングよりも短く、費用対効果が高くなります。

コードサンプルも GitHubレポ、SageMaker での DeepFM 分散トレーニングの XNUMX つのサンプルを示します。 XNUMX つは CPU インスタンス上の TensorFlow パラメータ サーバーで、もう XNUMX つは GPU インスタンス上の Horovod です。

著者について

リャン・ユフイ シニア機械学習ソリューション アーキテクトです。 彼は機械学習の促進と応用に注力しており、多くの顧客の機械学習プロジェクトに深く関わっています。 彼は、深層学習の分散トレーニング、レコメンデーション システム、計算広告で豊富な経験を持っています。

王石帥 シニア機械学習ソリューション アーキテクトです。 彼は AWS のお客様と協力して、大規模な機械学習の導入を支援しています。 彼は映画を見たり、世界中を旅したりするのが好きです。