Best practices for deep learning on Databricks | Databricks on AWS [2022/2/7時点]の翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
Databricks Machine Learningは、Databricks機械学習ランタイムと事前構築済みのディープラーニングインフラストラクチャを提供します。Databricks機械学習ランタイムには、TensorFlow、PyTorch、Kerasのような著名なディープラーニングと、Petastorm、Hyperopt、Horovodのようなサポート用ライブラリが含まれています。ドライバーやサポート用ライブラリを含む、ビルトインかつ事前設定済みのGPUサポートも提供します。
Databricks機械学習ランタイムは、クラスター作成・管理、ライブラリ、環境管理、Databricks Reposによるコード管理、Databricksジョブ、APIを含む自動化のサポート、モデル開発をトラッキングし、モデルをデプロイ、サービングするための統合されたMLflowのようなDatabricksワークスペースの全ての機能を含んでいます。
Databricksを用いることで、モデルをトレーニングするためのロジックを作成するために必要なライブラリを活用することができます。事前設定済みのDatabricksランタイムを用いることで、一般的な機械学習ステップ、ディープラーニングのステップを容易にスケールさせることが可能となります。本書では、Databircksにおけるディープラーニングのティップスと、以下のようなディープラーニングのワークロードを最適化するために設計されたビルトインツールとライブラリを説明します。
- データをロードするためのDeltaとPetastorm
- トレーニングを並列化するためのHorovodとHyperopt
- 推論で用いるPandas UDF
リソースと環境の管理
Databricksは、ユーザーに対して一貫性のある環境を維持する、ディープラーニング環境をカスタマイズするという両方のケースで役立ちます。
開発環境のカスタマイズ
Databricksランタイムを用いることで、ノートブック、クラスター、ジョブのレベルで開発環境をカスタマイズすることができます。
- 他のクラスターユーザーに影響を与えることなしに、特定のライブラリのセット、バージョンを使用するためにノートブックスコープPythonライブラリやノートブックスコープRライブラリを使用します。
- チームやプロジェクトでバージョンの標準化を行うためにクラスターレベルでライブラリをインストールします。
- 一貫性を保ち、環境を変更せずに、タスクを繰り返し実行することを保証できるようにDatabricksジョブをセットアップします。
クラスターポリシーの活用
開発時にはSingle Nodeクラスター、大規模なジョブにはオートスケーリングのクラスターを用いるなど、データサイエンティストが適切な選択をできるようにガイドするためにクラスターポリシーを作成することができます。
データロードにおけるベストプラクティス
クラウドデータストレージは通常I/Oに最適化されておらず、大規模なデータセットを必要とするディープラーニングモデルにおける課題となる場合があります。Databricks機械学習ランタイムには、ディープラーニングアプリケーションにおけるデータのスループットを最適化するためのDelta LakeとPetastormが含まれています。
Delta Lakeテーブルをデータストレージに用いることをお勧めします。Delta LakeはETLをシンプルなものにし、効率的にデータにアクセスできるようになります。特に、画像に対してはトレーニング、推論の両方におけるデータ取り込みの最適化の役立ちます。画像アプリケーションに対するリファレンスソリューションは、Delta Lakeを用いた画像に対するETLの最適化のサンプルを提供しています。
PetastormはTensorFlow、Keras、PyTorchで使用されるParquetフォーマットでデータを準備するためのAPIを提供します。SparkConverter APIはSparkデータフレームとのインテグレーションを提供します。また、Petastormは分散処理向けのデータシャーディングを提供します。詳細はLoad data using Petastormをご覧ください。
ディープラーニングモデルのトレーニングにおけるベストプラクティス
全てのモデルトレーニングにおいて、機械学習ランタイムとMLflowトラッキング、オートロギングを使用することをお勧めします。
シングルノードクラスターから始める
(ドライバーのみの)Single NodeのGPUクラスターが、ディープラーニングのモデル開発において最も高速かつコスト効率性が高いものになります。4GPU1ノードは、多くのケースで、1GPUの4ノードでディープラーニングをトレーニングするよりも早くなります。これは、分散トレーニングにおいてネットワークコミュニケーションのオーバーヘッドが含まれるためです。
シングルノードクラスターは、小規模から中規模のデータに対するモデルのトレーニング、高速かつイテレーティブな開発においては優れた選択肢となります。シングルマシンではトレーニングが遅くなるような大規模データセットである場合には、マルチGPU、分散処理への移行を検討します。
トレーニングプロセスをモニタリングするためにTensorBoardとGangliaを活用する
TensorBoardは、すでにDatabricks機械学習ランタイムにインストールされています。ノートブック内あるいは別のタブで利用することができます。詳細はTensorBoardを参照ください。
Gangliaは全てのDatabricksランタイムで利用できます。ボトルネックを調査するために、ネットワーク、プロセッサ、メモリー使用料を検証するために活用することができます。詳細はGangliaのメトリクスをご覧ください。
ディープラーニングにおけるパフォーマンスを最適化する
Databricksにおけるディープラーニングパフォーマンス最適化技術を活用できますし、活用すべきです。
アーリーストッピング
アーリーストッピングは、検証用セットにおけるメトリクスの値をモニタリングし、メトリクスに改善が認められない場合には、トレーニングを停止します。これは、完了すべきエポック数を推定するよりも優れたアプローチです。それぞれのディープラーニングライブラリは、アーリーストッピングに対するネイティブAPIを提供しています。例えば、TensorFlow/KerasやPyTorch LightningのEarlyStoppingコールバックAPIをご覧ください。サンプルノートブックについては、DatabricksでTensorFlow Kerasを使ってみる をご覧ください。
バッチサイズのチューニング
バッチサイズのチューニングは、GPU利用率の最適化に役立ちます。バッチサイズが小さすぎると、計算処理が完全にGPUの能力を使い切ることができません。GPUメトリクスを参照するためにGangliaのメトリクスを使用することができます。
バッチサイズは学習率と組み合わせて調整します。定石として、バッチサイズをnに増やした場合には学習率はsqrt(n)だけ増加させるというものがあります。手動でチューニングする際には、バッチサイズを2倍あるいは0.5倍するようにしてください。パフォーマーンスを最適化するためにチューニングを続ける際には、手動あるいは、Hyperoptのような自動化ツールを用いてさまざまなハイパーパラメーターをテストしていきます。
転送学習
転送学習を用いることで、事前にトレーニングされたモデルからスタートして、アプリケーションで必要な修正を行うことができます。転送学習はトレーニングと新規モデルのチューニングに要する時間を劇的に削減することができます。詳細とサンプルについては、Featurization for transfer learningをご覧ください。
分散トレーニングに移行する
Databricks機械学習ランタイムには、シングルノードから分散トレーニングへの移行を支援するHorovodRunner、spark-tensorflow-distributor、Hyperoptが含まれています。
HorovodRunner
Horovodは、ディープラーニングのトレーニングをマルチGPUあるいは分散処理にスケールさせるためのオープンソースプロジェクトです。Databricksによって開発され、Databricks機械学習ランタイムに含まれているHorovodRunnerは、Sparkとの互換性を提供するHorovodのラッパーです。このAPIによって、最低限の変更でシングルノード向けのコードをスケールさせることができます。HorovodRunnerはTensorFlow、Keras、PyTorchと連携できます。
spark-tensorflow-distributor
spark-tensorflow-distributorは、SparkクラスターにおけるTensorFlowの分散トレーニングのためのオープンソースのネイティブパッケージであり、TensorFlowに含まれています。
Hyperopt
Hyperoptは機械学習における適合ハイパーパラメーターチューニングを提供します。SparkTrialsクラスを用いることで、クラスターで並列にディープラーニングモデルのパラメーターをイテレーティブにチューニングすることができます。
推論におけるベストプレクティス
このセクションでは、Databricksによる推論でモデルを使う際の一般的なティップスを説明します。
- コストを最小化するためには、Amazon EC2のG4、G5インスタンスのように推論に最適化されたGPUとCPUの両方を検討します。しかし、最適な選択肢はモデルのサイズ、データの次元数や他の変数に依存するため、明確な推奨内容はありません。
- モデルのデプロイメントとサービングをシンプルにするためにMLflowを使います。MLflowはカスタムの前処理、後処理ロジックを含みいかなるディープラーニングモデルを記録することができます。MLflowのモデルレジストリに登録されたモデルを、バッチ向け、ストリーミング向け、あるいはオンライン推論向けにデプロイすることができます。
バッチ及びストリーミングによる推論
バッチとストリーミングのスコアリングは、数分のレーテンシーによる、高いスループット、低コストのスコアリングをサポートします。詳細に関してはOffline (batch) predictionsをご覧ください。
- 推論で複数回データにアクセスすることが予期されるのであれば、推論ジョブを実行する前にDelta LakeテーブルにデータをETLする前処理ジョブを作成することを遠投してください。このようにすることで、データの取り込み、準備のコストを複数のデータ読み取り処理に分散させることができます。推論から前処理を分離することで、コストとパフォーマンスを最適化するために、ジョブごとに異なるハードウェアを選択できるようになります。例えば、ETLにはCPU、推論にはGPUを使うことができます。
- クラスターにまたがるバッチ、ストリーミング推論をスケールさせるためにSpark Pandas UDFを使用します。
- Databricksでモデルを記録すると、MLflowは自動で[モデルをpandas UDFとして適用するための推論コードを提供します。
- 特に大規模なディープラーニングモデルに対しては、さらに推論パイプランを最適化することができます。画像アプリケーションに対するリファレンスソリューションのサンプルを参照ください。
オンラインサービング
低レーテンシーのサービングに対する最適な選択肢は、REST APIによるオンラインサービングとなります。Databrikcsはオンライン推論のためのモデルサービングを提供します。
MLflowはオンラインサービングのためのさまざまなマネージドサービスにデプロイするためのAPI、カスタムサービングソリューション向けのDockerコンテナを作成するためのAPIを提供します。
SageMakerのサービングを使用することもできます。サンプルノートブックとMLflowのドキュメントをご覧ください。