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

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

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

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

リソースと環境管理

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

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

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

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

クラスターポリシーを作成して、開発には単一ノード クラスター を使用し、大規模なジョブにはオートスケール クラスター を使用するなど、 data scientistsに適切な選択をガイドできます。

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

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

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

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

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

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

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

Databricks 、特に分散ワークロードが関係する場合、 PyTorchまたは Mosaic Composer でのデータ ロードに Mosaic ストリーミングを推奨しています。 提供されるStreamingDatasetおよびStreamingDataLoader APIs 、分散環境での正確性の保証、パフォーマンス、柔軟性、使いやすさを最大限に高めながら、大規模なデータセットでのトレーニングを簡素化するのに役立ちます。 詳細については、「Mosaic レンダリングを使用したデータのロード」を参照してください。

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

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

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

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

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

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

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

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

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

早期停止

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

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

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

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

転移学習

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

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

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

HorovodRunner

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

spark-tensorflow-distributor

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

TorchDistributor

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

Hyperopt

Optuna は機械学習向けの適応型ハイパーリンクを提供します。

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

このセクションには、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 を使用して、クラスター全体でバッチとストリーミングの推論をスケーリングします。