メインコンテンツまでスキップ

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

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

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

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

リソースと環境の管理​

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

開発環境のカスタマイズ​

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

Use クラスターポリシー​

クラスターポリシーを作成して、開発にシングルノードクラスターを使用し、大規模なジョブにオートスケールクラスターを使用するなど、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 for Machine Learning と MLflow の追跡 と 自動ログ 記録を使用することをお勧めします。

Single Node クラスターから始める​

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

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

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

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

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

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

早期停止​

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

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

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

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

転移学習​

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

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

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

TorchDistributor​

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

オプツナ​

Optuna は、機械学習のための適応型ハイパーパラメーターチューニングを提供します。

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

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

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

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

オンラインサービング​

低遅延サービスに最適なオプションは、REST API の背後でオンライン サービスを提供することです。 Databricks は、オンライン推論のための モデルサービング を提供します。 モデルサービングは、 AI モデルをデプロイ、制御、およびクエリするための統一インターフェイスを提供し、次のサービスをサポートします。

  • カスタムモデル。 これらは、MLflow 形式でパッケージ化された Python モデルです。 例としては、scikit-learn、XGBoost、PyTorch、Hugging Face トランスフォーマーモデルなどがあります。
  • 外部モデル。 これらは、Databricks の外部でホストされているモデルです。 たとえば、OpenAIのGPT-4、AnthropicのClaudeなどの生成AIモデルです。 これらのモデルを提供するエンドポイントは一元管理でき、顧客はそれらのレート制限とアクセス制御を確立できます。

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

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

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

  • 推論のためにデータに複数回アクセスすることが予想される場合は、推論ジョブを実行する前に、データを Delta Lake テーブルに ETL する前処理ジョブを作成することを検討してください。 これにより、データの取り込みと準備のコストは、データの複数の読み取りに分散されます。 前処理と推論を分離することで、ジョブごとに異なるハードウェアを選択して、コストとパフォーマンスを最適化することもできます。 たとえば、ETL には CPU を使用し、推論には GPU を使用できます。
  • Spark Pandas UDFs を使用して、クラスター全体でバッチ推論とストリーミング推論をスケーリングします。
    • Databricksからモデルをログに記録すると、MLflow はモデルをとして適用PandasUDF するための推論コードを自動的に提供します。
    • また、推論パイプラインをさらに最適化することもできます (特に大規模なディープラーニングモデルの場合)。 例については、 画像 ETL の参照ソリューション を参照してください。
に最終更新