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

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

Databricks Mosaic AI は、TensorFlow、PyTorch、Keras などの最も一般的なディープラーニングライブラリを含む Databricks Runtime for Machine Learning を使用して、事前に構築されたディープラーニングインフラストラクチャを提供します。 また、ドライバーやサポートライブラリなど、組み込み可能な事前構成済みの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 の可用性は限られています。 リソースの割り当てについてはクラウド プロバイダーに問い合わせるか、事前に容量を予約することを検討してください。

GPU スケジューリング

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

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

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

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 ランタイムで使用できます。 ネットワーク、プロセッサ、およびメモリの使用状況を調べて、ボトルネックを検査できます。 詳細は、 クラスターメトリクス を参照してください。

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

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

早期停止

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

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

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

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

転移学習

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

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

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

TorchDistributor

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

オプツナ

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

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

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

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

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

オンラインサービング

低遅延の配信に最適なオプションは、REST API の背後でのオンライン配信です。 Databricks には、オンライン推論用の モデルサービング が用意されています。 モデルサービングは、AI モデルをデプロイ、管理、クエリするための統一されたインターフェイスを提供し、次のサービスをサポートします。

  • カスタムモデル。 これらは、MLflow 形式でパッケージ化された Python モデルです。 例としては、 Scikit-Learn、XGBoost、PyTorch、Hugging Face トランスフォーマー モデルなどがあります。

  • 基盤モデルAPIsが提供する最先端のオープンモデル。これらのモデルは、最適化された推論をサポートするキュレーションされた基盤モデル アーキテクチャです。 たとえば、Meta-Llama-3.1-70B-Instruct のような基本モデル、 GTE-Large と Mistral-7B は、 トークン単位の従量課金 price ですぐに使用できます。 パフォーマンスの保証と微調整されたモデル バリアントが必要なワークロードの場合は、 プロビジョニングされたスループットでデプロイできます。

  • 外部モデル。 これらは Databricks の外部でホストされるモデルです。 AIたとえば、OpenAI の GPT-4、Anthropic の Claude などの モデルを生成します。これらのモデルを提供するエンドポイントは集中管理でき、顧客はエンドポイントに対してレート制限とアクセス制御を確立できます。

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

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

バッチとストリーミングのスコアリングは、数分という短いレイテンシーで高スループットで低コストのスコアリングをサポートします。 詳細については、「 バッチ推論と予測のためのモデルのデプロイ」を参照してください。

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

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