Amazon Web Services ブログ
現代自動車、Amazon SageMakerを用いて自動運転のための機械学習モデルの学習時間を短縮
韓国のソウルに本社を置く現代自動車は、世界最大級の自動車メーカーです。彼らは、自動運転車の開発競争に多くの人的・物的資源を投資しています。
自動運転によく使われるアルゴリズムの一つにセマンティックセグメンテーションがあります。これは、画像のすべてのピクセルにオブジェクトクラスをアノテーションするタスクです。これらのクラスは、道路、人、車、建物、植生、空などです。通常の開発サイクルでは、現代自動車のチームは定期的に精度をテストし、特定の状況下で予測性能が不十分な場合は追加の画像を収集して補正します。しかし、新しいデータをすべて準備するには、モデルの学習に十分な時間を確保しつつ、予定された納期に間に合わせることができないことが多いからです。現代自動車は、Amazon ML Solutions Lab とともに、スケーラブルな AWS クラウドとデータ並列化のための新しい SageMaker ライブラリを含む、Amazon SageMaker を活用して学習を大幅に高速化することで、この問題を解決しました。
SageMaker は、分散コンピュートインフラの管理や学習ジョブの監視・デバッグといった「重労働」を軽減することで、お客様の課題を解決するフルマネージド ML プラットフォームです。このユースケースでは、SageMaker Data Parallel ライブラリと Amazon SageMaker Debugger を使用して、現代自動車の技術的課題を解決し、コスト効率よくビジネス目標を達成しています。
SageMaker では、データ並列化とモデル並列化のための分散学習ライブラリを提供しています。今回ケースでは、学習するモデルは1つの GPU のメモリに収まっていますが、学習データ量が多いため、1つのGPUでは1エポックの学習に時間がかかりすぎてしまいます。これは、データ並列分散学習により、学習ジョブの全体的な時間を短縮できる典型的な学習例です。SageMaker のデータ並列は、学習データを複数の GPU インスタンスに分散させ、割り当てられたデータセットを使用して各 GPU 上で同じモデルを学習することでこれを実現します。SageMaker Data Parallel ライブラリは、高速な AWS のネットワークインフラを利用して設計されており、GPU の数が増えれば増えるほど、ほぼ比例したスケーラビリティが得られます。
学習用のアーキテクチャでは、SageMaker を使用し、オプションとしてデータストレージ に Amazon FSx for Lustre を使用しています。恒久的なデータストレージとして Amazon Simple Storage Service (Amazon S3)を使用しています。PyTorch Data Parallel ベースの学習用コードを、わずか数行変更することで SageMaker のデータ並列ライブラリに変換し、8つの GPU インスタンス、または合計 64 の GPU で最大 93 ％のスケーリング効率を達成しました。以下の図は、分散学習のために導入された AWS のアーキテクチャを示しています。
単一の GPU を使用してモデルを学習する 場合とは異なり、複数の GPU や分散 GPU を使用してト レーニングを行うと、単一の GPU では観測されなかっ た根本的なパフォーマンスの問題が明らかになるこ とがあります。そのため、高価な GPU リソースを十分に活用して望ましいモデル性能を実現するためには、評価指標とともにリソースの使用状況を監視することが重要です。
SageMaker Debugger とそのプロファイリング機能により、深層学習の科学者やエンジニアは、学習ジョブの実行中に、システム関連やモデル関連のパフォーマンス問題を監視、追跡、分析することができます。デバッグ出力を有効にするには、学習用スクリプトのコードを変更する必要はありません。Amazon SageMaker Studio では、リアルタイムのモニタリングとビジュアライゼーションが提供されており、API コールを介して収集されたデバッグおよびプロファイリングデータにアクセスし、可視化や分析を行うことができます。Debugger のフレームワークレベルのプロファイリング機能がもたらすオーバーヘッドを最小限に抑えるために、学習ジョブの実行中にプロファイラのオン/オフやプロファイリング設定の変更を行うこともできます。
SageMaker Distributed Data Parallel ライブラリを用いた分散学習
SageMaker のデータ並列化ライブラリを使用するには、SageMaker の DistributedDataParallel クラスを使用してモデルをラップし、初期化を実行するわずかなコード変更が必要です。以下のコード例では、PyTorch の学習用スクリプトにこれを行う方法を示しています。API 上の開発者体験は、PyTorchの DistributedDataParallel と同様です。
# Importing SageMaker distributed training library
from smdistributed.dataparallel.torch.parallel.distributed
import DistributedDataParallel as DDP
import smdistributed.dataparallel.torch.distributed as dist
# Initializing distributed training process group
dist.init_process_group()
# Setting the local rank as the local GPU ID
local_rank = dist.get_local_rank()
# Wrapping the model for distributed training
model = DDP(Net())
torch.cuda.set_device(local_rank)
model.cuda(local_rank)PyTorch や TensorFlow の分散学習の経験者であれば、”分散学習用のクラスタを設定し、クラスタ内の各インスタンスで学習処理を開始するにはどうすればよいか？”というような質問をすることがあるかもしれません。SageMaker で行うことは、インスタンス数とインスタンスタイプを指定し、使用する分散学習戦略を SageMaker に知らせるだけです。SageMaker のマネージドな機能により、この設定は PyTorch と TensorFlow の両方に適用されます。以下のサンプルコードをご覧ください。
estimator = PyTorch(instance_count=4,
instance_type='ml.p3.16xlarge',
distribution={
'smdistributed':{
'dataparallel':{
'enabled': True
}
}
})
学習用スクリプトを更新したところで、S3 バケットにあるデータセットへのアクセス方法を決めなければなりません。最も一般的な方法は、学習ジョブの開始時に SageMaker に S3 バケットからデータセットを接続されたストレージまたは内蔵の NVMe SSD ストレージにコピーさせる方法です。このストレージは学習ジョブ間で永続的ではありません。この方法は SageMaker ファイルモードと呼ばれます。
このような状況で学習の速度が低下しないようにするためには、以下のような対応が考えられます。
- データセットのサイズを小さくする。
- SageMaker のパイプモードを使用して、データをコピーせずにストリームする。
- Amazon S3 からデータをコピーするのではなく、FSx for Lustre を使用する。
我々は実験を繰り返すために FSx for Lustre を選択しました。S3 バケットに格納されているデータを用いて FSx for Lustre ファイルシステムを作成し、各学習ジョブのインスタンスに取り付けました。FSx for Lustre ファイルシステムは、SageMaker の学習ジョブ間で永続するため（学習用インスタンスに接続されたストレージとは異なります）、初期化の遅延なしに複数の実験を実行することができます。
コード変換が完了し、学習用コードが問題なく実行されていることを確認した後、ファイルモードに切り替え、内部の NVMe SSD ストレージを使用して最適な I/O パフォーマンスを得られるようにします。これも SageMaker の estimator の設定を変更することで簡単に行うことができます。繰り返しになりますが、学習用スクリプトへのコード変更は必要ありません。以下のコードをご覧ください。
# Using Amazon FSx for Lustre
train_fs = FileSystemInput(file_system_id='file system id',
file_system_type='FSxLustre',
directory_path='/fsx/',
file_system_access_mode='ro')
estimator.fit(inputs={'train': train_fs})
# Using S3
estimator.fit(inputs={'train': 's3://your-bucket-name/prefix/'})
学習のパフォーマンス分析とチューニング
Debugger を使用するために学習用コードを変更する必要はありません。Debugger は、学習ジョブの実行中に、estimator の定義時に設定するか、スタジオまたは Debugger API を通じて有効または無効にすることができます。学習ジョブのパフォーマンスの全体像を把握するために、SageMakerの estimator を使用して、CPU 使用率、GPU 使用率、GPU メモリ使用率、I/O 待ち時間を 500 ミリ秒間隔で Debugger のシステムプロファイリングを有効にしました。これは、ProfilerConfig を定義し、それを estimator に設定することで行います。
profiler_config = ProfilerConfig(
system_monitor_interval_millis=500)
estimator = PyTorch(
...
profiler_config=profiler_config)SageMaker Studio Debugger の可視化機能を使ってシステムのリソース使用率を監視し、異常なパターンを見つけました。シングル GPU での学習よりもマルチ GPU での学習の方が、各ステップにかかる時間が長くなっています。複数 GPU を使用した学習では、CPU は常に 100 ％の性能を発揮していましたが、GPU は十分に活用されていませんでした。このパターンは、学習の進行中に、Studio の CPU と GPU の使用率のヒートマップを見てすぐにわかりました。また、Debugger のフレームワークプロファイリング機能を利用することで、Python レベルおよびディープラーニングフレームワークレベルのプロファイリング結果を得ることができ、根本的な原因を分析することができました
Amazon ML Solutions Lab と現代自動車は、Debugger のデータと学習用コードを深く掘り下げ、カスタムデータローダに根本的な原因があることを突き止めました。この問題は、シングル GPU の学習では、パフォーマンスのオーバーヘッドを引き起こすことはありませんでした。CPU の枯渇問題が解決されたことで、システムのリソース使用率は通常に戻り、学習のパフォーマンスも向上しました。この取り組みにより、同じ量の GPU リソースを使用しても、マルチ GPU での学習の速度が 2 倍に向上しました。
次の図は、CPU と GPU の使用率のグラフとヒートマップです。左が改善前の学習で、右が改善を行った後のを学習です。
まとめ
この記事では、SageMaker のデータ並列化ライブラリを使用して学習を高速化した方法について詳しく説明しました。また、学習中のボトルネックを特定し、学習におけるパフォーマンスを最適化するための実戦的なテクニックも紹介しました。その結果、わずか 5 倍のインスタンス数で 10 倍の学習速度を実現しました。
現代自動車のシニア・リサーチ・エンジニアである Jinwook Choi 氏は、「我々はコンピュータビジョンモデルを使ってシーンセグメンテーションを行っていますが、これはシーンを理解する上で重要です。Amazon SageMaker のデータ並列化ライブラリと Amazon ML Solutions Lab の協力により、もともと 57 分かかっていた学習が、5 台の ml.p3.16xlarge インスタンス上で最適化された学習用コードを使用して、6 分で行うことができました。学習時間が10分の1に短縮されたことで、開発サイクル中のデータ準備により多くの時間を費やすことができるようになりました。」と述べています。
SageMakerの関連機能については、以下をご確認ください。
Amazon ML Solutions Lab について
Amazon ML Solutions Lab は、あなたのチームと機械学習の専門家をペアにして、あなたの組織で最も価値の高い機械学習の活用先を特定して実装するのを支援します。製品やプロセスにおける機械学習の使用を加速するための支援をご希望の場合は、Amazon ML Solutions Lab にご連絡下さい。
翻訳は SA 上総が担当しました。原文はこちらをご覧ください。