次の方法で共有

Azure Databricks でのディープ ラーニングの推奨事項

  • [アーティクル]

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

Databricks Mosaic AI では、TensorFlow、PyTorch、Keras などの最も一般的なディープ ラーニング ライブラリを含む、Databricks Runtime for Machine Learning を備えた事前構築されたディープ ラーニング インフラストラクチャが提供されます。 また、ドライバーやサポート ライブラリを含む、組み込みの事前に構成された GPU サポートも提供します。

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

リソースと環境の管理

Azure Databricks を使用すると、ディープ ラーニング環境をカスタマイズすると共に、ユーザー間で環境の一貫性を維持することができます。

開発環境のカスタマイズ

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

クラスター ポリシーの使用

クラスター ポリシーを作成して、データ科学者を適切な選択肢に導くことができます。たとえば、開発には単一ノード クラスターを使用し、大規模なジョブには自動スケーリング クラスターを使用します。

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

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

  • Databricks では、すべてのクラウドで A100 GPU がサポートされます。 サポートされている GPU の種類の完全な一覧については、「サポートされているインスタンスの種類」を参照してください。
  • 通常、A100 GPU の利用は制限されています。 リソースの割り当てについてクラウド プロバイダーに問い合わせるか、事前に容量の予約を検討してください。

GPU のスケジューリング

分散ディープ ラーニングのトレーニングと推論のために GPU を最大化するには、GPU スケジューリングを最適化します。 GPU のスケジューリングを参照してください。

データの読み込みに関するベスト プラクティス

クラウド データ ストレージは、通常、入出力に関して最適化されていません。これは、大規模なデータセットを必要とするディープ ラーニング モデルにとって、課題になることがあります。 Databricks Runtime ML には、ディープ ラーニング アプリケーションのデータ スループットを最適化するための Delta Lake および Mosaic Streaming が含まれています。

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

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

ディープ ラーニング モデルをトレーニングするための推奨事項

Databricks では、すべてのモデル トレーニングで Databricks Runtime for Machine Learning、MLflow Tracking、Autologging を使用することをお勧めします。

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

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

単一ノード クラスターは、迅速に反復的な開発を行う場合に、小規模から中規模のサイズのデータに対するトレーニング モデルとして適しています。 データセットが相当に大きく、1 台のコンピューターではトレーニングの速度が低下する場合は、マルチ GPU や分散コンピューティングに移行することを検討してください。

TensorBoard とクラスター メトリックを使用してトレーニング プロセスを監視する

Databricks Runtime ML には TensorBoard がプレインストールされています。 これは、ノートブック内または別のタブで使用できます。詳細については、「TensorBoard」を参照してください。

クラスター メトリックは、すべての Databricks ランタイムで使用できます。 ネットワーク、プロセッサ、メモリの使用状況を調査して、ボトルネックを確認できます。 詳細については、「クラスター メトリック」を参照してください。

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

Databricks でのディープ ラーニングのパフォーマンス最適化手法を使用することをお勧めします。

早期停止

早期停止によって、検証セットに対して計算されたメトリックの値を監視し、メトリックが改善されないときにはトレーニングを停止します。 これは、多数のエポックが完了してから推定するよりもよい方法です。 各ディープ ラーニング ライブラリには、早期停止のためのネイティブ API が用意されています。たとえば、TensorFlow/Keras と PyTorch Lightning の EarlyStopping コールバック API を参照してください。 ノートブックの例については、「TensorFlow Keras サンプル ノートブック」をご覧ください。

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

バッチ サイズのチューニングは、GPU 使用率を最適化するために役立ちます。 バッチ サイズが小さすぎると、計算で GPU の能力を十分に使用できません。 クラスター メトリックを使用して、GPU メトリックを表示できます。

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

転移学習

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

分散トレーニングに移行する

Databricks Runtime ML には、単一ノードから分散型トレーニングへの移行を容易にする TorchDistributor、DeepSpeed および Ray が含まれています。

TorchDistributor

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

Optuna

Optuna は、機械学習のためのアダプティブ ハイパーパラメーター チューニングを提供します。

推論の推奨事項

このセクションでは、Azure Databricks での推論のためのモデルの使用に関する一般的なヒントについて説明します。

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

  • Mlflow を使用して、モデルのデプロイとサービス提供を簡略化します。 MLflow では、カスタムの前処理と後処理のロジックを含む、任意のディープ ラーニング モデルをログに記録できます。 Unity Catalog 内のモデルまたはワークスペース モデル レジストリに登録されているモデルは、バッチ、ストリーミング、またはオンラインの推論のためにデプロイできます。

オンライン サービス提供

短い待機時間でのサービス提供のための最適なオプションは、REST API の背後にあるオンライン サービス提供です。 Databricks では、オンライン推論のためにモデル提供を利用できます。 Model Serving では、AI モデルのデプロイ、管理、クエリのための統合インターフェイスが提供され、次のものの提供がサポートされています。

  • カスタム モデル。 これらは、MLflow 形式でパッケージ化された Python モデルです。 たとえば、scikit-learn、XGBoost、PyTorch、Hugging Face トランスフォーマー モデルなどがあります。
  • Foundation Model API で利用できる最先端のオープン モデル。 これらのモデルは、最適化された推論をサポートするキュレーションされた基盤モデル アーキテクチャです。 たとえば、Llama-2-70B-chat、BGE-Large、Mistral-7B などの基本モデルは、トークン単位の支払い価格ですぐに使用できます。 パフォーマンスの保証と微調整されたモデル バリアントを必要とするワークロードでは、プロビジョニングされたスループットを使用してそれをデプロイできます。
  • 外部モデル。 これらは、Databricks の外部でホストされているモデルです。 たとえば、OpenAI の GPT-4 や Anthropic の Claude などの生成 AI モデルです。 これらのモデルを提供するエンドポイントは一元的に管理でき、顧客はレート制限とアクセスの制御を確立できます。

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

オンライン推論のためのその他の一般的なマネージド サービスは、次のとおりです。

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

バッチとストリーミングのスコアリングでは、高スループットで低コストのスコアリングがサポートされています。待機時間は短く、数分程度です。 詳細については、モデル推論に MLflow を使用することに関する記事をご覧ください。

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