Databricks でのディープラーニングのベスト プラクティス

この記事には、Databricks でのディープラーニングのヒントと、次のようなディープラーニング ワークロードを最適化するように設計された組み込みツールとライブラリに関する情報が含まれています。

Databricks Machine Learning は、TensorFlow、PyTorch、Keras などの最も一般的なディープラーニング ライブラリを含む、機械学習用の Databricks Runtime を備えたビルド済みのディープラーニング インフラストラクチャを提供します。 また、組み込み、ドライバーやサポートライブラリを含む事前構成されたGPUサポートもあります。

Databricks Runtime ML には、クラスターの作成と管理、ライブラリと環境の管理、Databricks Git フォルダーを使用したコード管理、Databricks ジョブとAPIsを含む自動化サポート、モデル開発の追跡とモデルのための統合 MLflow など、Databricks ワークスペースのすべての機能も含まれています。導入とサービス。

リソースと環境管理

Databricks は、ディープラーニング環境をカスタマイズし、ユーザー間で環境の一貫性を維持するのに役立ちます。

開発環境 をカスタマイズする

Databricks Runtimeを使用すると、ノートブック、クラスター、およびジョブレベルで開発環境をカスタマイズできます。

クラスターポリシー を使用する

クラスターポリシーを作成して、データサイエンティストを正しい選択 (開発には単一ノード クラスターを使用し、大規模なジョブにはオートスケール クラスター を使用するなど) に導くことができます。

ディープラーニングワークロード 用のA100 GPUを検討する

A100 GPU は、大規模な言語モデルのトレーニングとチューニング、自然言語処理、オブジェクトの検出と分類、レコメンデーション エンジンなど、多くのディープラーニング タスクに効率的な選択肢です。

  • Databricks は、すべてのクラウドで A100 GPU をサポートしています。 サポートされている GPU タイプの完全なリストについては、「 サポートされているインスタンスタイプ」を参照してください。

  • 通常、A100 GPU の可用性は限られています。 リソースの割り当てについてはクラウド プロバイダーに問い合わせるか、事前に容量を予約することを検討してください。

データ の読み込みに関するおすすめの方法

クラウドデータストレージは通常、I / O用に最適化されていないため、大規模なデータセットを必要とするディープラーニングモデルでは課題となる可能性があります。 Databricks Runtime 機械学習には、ディープラーニングアプリケーションのデータスループットを最適化するための Delta Lake と Petastorm が含まれています。

Databricks では、データ ストレージに Delta Lake テーブルを使用することをお勧めします。 Delta Lake ETL を簡素化し、データに効率的にアクセスできるようにします。 特に画像の場合、Delta Lake はトレーニングと推論の両方のインジェストを最適化するのに役立ちます。 イメージ アプリケーションのリファレンス ソリューション では、Delta Lake を使用してイメージの ETL を最適化する例を示します。

Petastorm には、TensorFlow、Keras、または PyTorch で使用するためにParquetの形式でデータを準備できる APIs が用意されています。 SparkConverter API は、Spark DataFrame 統合を提供します。 Petastormは、分散処理のためのデータシャーディングも提供します。 詳細については、「 Petastorm を使用してデータを読み込む 」を参照してください。

ディープラーニング モデルの トレーニングに関するベスト プラクティス

Databricks では 、すべての モデルDatabricks Runtime トレーニングで機械学習と MLflow の追跡 と 自動ログに を使用することをお勧めします。

単一ノードクラスター から開始する

通常、単一ノード(ドライバーのみ) GPU クラスターは、ディープラーニング モデル開発において最も高速で最もコスト効率が高くなります。 ディープラーニング トレーニングでは、4 つの GPU を備えた 1 つのノードの方が、それぞれ 1 つの GPU を備えた 4 つのワーカー ノードよりも高速になる可能性があります。 これは、分散トレーニングではネットワーク通信のオーバーヘッドが発生するためです。

単一ノード クラスターは、高速で反復的な開発や、小規模から中規模のデータでモデルをトレーニングする場合に適したオプションです。 データセットが 1 台のコンピューターでトレーニングを遅くするのに十分な大きさである場合は、マルチ GPU や分散コンピュートに移行することを検討してください。

TensorBoard を使用してトレーニング プロセスを監視する

TensorBoard は Databricks ランタイム 機械学習にプレインストールされています。 ノートブック内または別のタブで使用できます。 詳細については、 TensorBoard を参照してください。

ディープラーニング のパフォーマンスを最適化

Databricks では、ディープラーニングのパフォーマンス最適化手法を使用できます。

早期停止

早期停止は、検証セットで計算されたメトリクスの値を監視し、メトリクスの改善が止まるとトレーニングを停止します。 これは、完了するエポックの数を推測するよりも優れたアプローチです。 各ディープラーニングライブラリは、早期停止用のネイティブAPIを提供します。たとえば、 TensorFlow/Keras と PyTorch Lightning の EarlyStopping コールバックAPIs を参照してください。ノートブックの例については、「 TensorFlow Keras サンプルノートブック」を参照してください。

バッチ サイズのチューニング

バッチ サイズのチューニングは、GPU 使用率の最適化に役立ちます。 バッチ サイズが小さすぎると、計算で GPU 機能を十分に使用できません。

学習率に合わせてバッチサイズを調整します。 経験則として、バッチサイズをn増やすと、学習率をsqrt(n)だけ上げます。 手動でチューニングする場合は、バッチ サイズを 2 倍または 0.5 倍に変更してみてください。 次に、手動で、または Hyperopt などの自動ツールを使用してさまざまなハイパーパラメーターをテストすることにより、パフォーマンスを最適化するためのチューニングを続行します。

転移学習

転移学習では、以前にトレーニングされたモデルから開始し、アプリケーションの必要に応じて変更します。 転移学習を使用すると、新しいモデルのトレーニングと調整に必要な時間を大幅に短縮できます。 詳細と例については、「 転移学習の特徴付け 」を参照してください。

分散トレーニング への移行

Databricks ランタイム 機械学習には、HorovodRunner、 spark-tensorflow-distributor、TorchDistributor、Hyperopt が含まれており、単一ノードから分散トレーニングへの移行を容易にします。

ホロヴォドランナー

Horovodは、ディープラーニングトレーニングをマルチGPUまたは分散計算に拡張するオープンソースプロジェクトです。 Databricks によって構築され、 Databricks Runtime機械学習に含まれているHorovodRunner は、Spark との互換性を提供する Horovod ラッパーです。 API を使用すると、最小限の変更で単一ノード コードをスケーリングできます。 HorovodRunner は TensorFlow、Keras、PyTorch で動作します。

spark-tensorflow-distributor

spark-tensorflow-distributor は、Spark クラスター上の TensorFlow を使用した分散トレーニング用の TensorFlow のオープンソース ネイティブ パッケージです。 ノートブックの例を参照してください。

トーチディストリビューター

TorchDistributor は PySpark のオープンソース モジュールであり、Spark クラスター上の PyTorch を使用した分散トレーニングを容易にし、PyTorch トレーニング ジョブを Spark ジョブとして起動できます。 「トーチディストリビューターを使用した分散トレーニング」を参照してください。

Hyperopt

Hyperopt は、機械学習のための適応型ハイパーパラメーター調整を提供します。 SparkTrials クラスを使用すると、クラスター全体で並行してディープラーニング モデルのパラメーターを繰り返し調整できます。

推論 のベストプラクティス

このセクションには、Databricks での推論にモデルを使用するための一般的なヒントが含まれています。

  • コストを最小限に抑えるには、CPU と推論に最適化された GPU (A2 マシン ファミリなど) の両方を検討してください。 最適な選択はモデルのサイズ、データディメンション、その他の変数によって異なるため、明確な推奨事項はありません。

  • MLflowを使用して、デプロイメントとモデルサービングを簡素化します。 MLflow は、カスタムの前処理および後処理ロジックを含む、あらゆるディープラーニング モデルをログに記録できます。 Unity Catalog内のモデル、またはWorkspace Model Registryに登録されたモデルは、バッチ、ストリーミング、またはオンライン推論用にデプロイできます。

オンラインサービス

低遅延の配信に最適なオプションは、REST API の背後でのオンライン配信です。 Databricks には、オンライン推論用の モデルサービング が用意されています。

MLflow は、オンライン推論のためにさまざまなマネージドサービスにデプロイするための APIs と、カスタム サービス ソリューション用の Docker コンテナーを作成するためのAPIs を提供します。

バッチとストリーミングの推論

バッチとストリーミングのスコアリングは、数分という短い待機時間で高スループット、低コストのスコアリングをサポートします。 詳細については、「 モデルの推論に MLflow を使用する」を参照してください。

  • 推論のためにデータに複数回アクセスすることが予想される場合は、推論ジョブを実行する前に、データを Delta Lake テーブルに ETL する前処理ジョブを作成することを検討してください。 このようにして、データの取り込みと準備のコストは、データの複数の読み取りに分散されます。 前処理を推論から分離することで、ジョブごとに異なるハードウェアを選択して、コストとパフォーマンスを最適化することもできます。 たとえば、ETL には CPU を使用し、推論には GPU を使用できます。

  • Spark Pandas UDF を使用して、クラスター全体でバッチとストリーミングの推論をスケーリングします。