従来のコンピュートの代わりにAI ランタイムを使用する理由
AI ランタイムは、カスタムディープラーニングモデルのトレーニング、ファインチューニング、バッチ推論の実行を目的としたServerless GPU コンピュートです。これらのワークロードをDatabricks Runtime 機械学習でクラシック コンピュートでランしている場合は、TCOの削減、より柔軟な開発者エクスペリエンス、マルチノードスケールのためにAI ランタイムに移行することをお勧めします。以下のセクションでは、機械学習エンジニアとプラットフォームチームの両方を比較し、Genie Codeが移行にどのように役立つかを説明します。
AI ランタイムと従来のコンピュートの比較
次の表は、AI Runtimeとクラシック コンピュート上の Databricks Runtime 機械学習を比較したものです。
機能 | AI Runtime | Databricks Runtime 機械学習を使用したクラシックコンピュート |
|---|---|---|
総所有コスト（TCO） | 管理されたServerless GPUインフラストラクチャ、高throughputパフォーマンス、最適化されたデータ読み込み、およびSpark Connectを介したSparkアクセスによるTCOの削減。ワークロードで使用されるコンピュートに対してのみ料金が発生します。Databricks は、クラスター、ドライバー、および GPU のヘルスを管理します。 | クラスター管理のオーバーヘッド、Startupの遅さ、および最適化されていないデータの読み込みとチェックポイント処理による高い TCO。クラスター構成とGPUの健全性を管理しますが、これによりGPUクラスターを取得および維持するためのコストが上昇します。 |
開発者体験 | Databricks CLI、IDEs、およびノートブックから開発およびデプロイします。ネイティブ Ray サポート。依存関係を完全に制御する最小限のスタンダード環境、一般的なAIおよび機械学習パッケージを含むDatabricks AI環境、またはカスタムDockerイメージから選択します。 | ノートブックで開発するか、SSHトンネル経由でIDEから接続します。GPUトレーニングワークロード用の専用CLIはありません。Ray は Spark 上でランします。ランタイムバージョンに関連付けられた膨大な数のプリインストール済みライブラリ（AIや機械学習に関係のないパッケージを含む）。 |
スケールとパフォーマンス | マルチノードトレーニングおよびバッチ推論。最適化されたデータの読み込みとチェックポイント処理。長いトレーニングランに対して高い GPU 信頼性。 | ノードとネットワーキングを自分で構成するため、マルチノードトレーニング用に最適化されていません。データの読み込みとチェックポイント処理を手動で最適化し、GPU の健全性を手動で検証する必要があります。 |
総所有コスト（TCO）
AI ランタイム は、管理された高性能 Serverless GPU を使用して総所有コストを削減します。
- Startupの高速化： Serverless GPU インフラストラクチャはオンデマンドで利用できるため、GPU クラスターの起動を待つ必要はありません。クラシック GPU クラスターは、クラスターのサイズと GPU の可用性によっては、起動に数分以上かかる場合があります。
- 従量課金価格： ワークロードが使用するServerless GPU コンピュートに対してのみ料金を支払うため、アイドル状態のクラスターの管理や料金の支払いは不要です。
- GPU利用率の向上: 柔軟なコンピュートオプション、高速なデータ読み込み、効率的なチェックポインティング、マルチノードトレーニングにより、GPUのアイドル時間を削減します。
- 管理負荷の軽減: AIランタイムは、コンピュートのデプロイ、クラスターのネットワーキング、GPUの健全性管理、CUDAドライバーのアップグレードを処理します。クラシックコンピュートでは、チームがノード管理、クラスター構成、および継続的なインフラストラクチャのメンテナンスを処理します。
開発者体験
AI ランタイム は、 AI およびディープラーニング ワークロードに柔軟な開発者エクスペリエンスを提供します。
- 接続: ノートブックで作業するか、SSHトンネル経由（ベータ版）でIDEから接続するか、Databricks CLIでワークロードをサブミットします。ランを自動化するには、ジョブをスケジュールするか、宣言型オートメーションバンドルを使用します。クラシックコンピュートには、GPUトレーニングワークロードをサブミットするための専用CLIがありません。
- 専用のディープラーニングランタイム： AI ランタイムは、 Ray や PyTorch などのフレームワークをネイティブにサポートしています。依存関係スタックを完全に制御するには スタンダード環境 を、一般的なAIおよび機械学習パッケージを含む Databricks AI環境 を、または カスタムDockerイメージ を選択してください。クラシックランタイムには、ランタイムバージョンに結び付けられたプレインストールライブラリが多数含まれています。
- デバッグと監視: 組み込みの MLflow 統合を使用して、エクスペリメントの追跡、コンピュート使用率の監視、モデルの管理、および問題のトラブルシューティングを行います。クラシックコンピュートでは、 Logs とコンピュート使用率メトリクスは MLflow ランに自動的に保存されません。
- セキュアなデータアクセス： Unity Catalogで管理される構造化データと非構造化データに、Apache Sparkクラスターを実行せずにSpark Connect経由でアクセスできます。
スケールとパフォーマンス
AI ランタイム は、ディープラーニング ワークロードを効率的にスケールするのに役立ちます。
- 最適化されたデータの読み込みとチェックポイント： High-throughputのデータの読み込みと非同期分散チェックポイント処理により、トレーニングパイプラインが高速化され、GPUのアイドル時間を最小限に抑えます。クラシックコンピュートには、ネイティブの高throughputデータローダーと分散チェックポイントがありません。AI ランタイムでのトレーニングのパフォーマンスと復元力の向上を参照してください。
- 組み込みのGPU復元力: 継続的な自動健全性チェックにより、障害が発生したGPUノードを検出および分離できるため、長時間のトレーニングランの中断が軽減されます。クラシックコンピュートでは、自分で GPU ノードの正常性を維持する必要があり、不適切なノードを分離するにはアクティブなワークロードを中断する必要があります。Databricks エンジニアリングブログのDatabricks AI で GPU の信頼性を維持する方法を参照してください。
- マルチノードトレーニング: 高速ネットワークと自動環境構成により、単一のGPUからマルチノード分散トレーニングへスケールアップします。マルチノードトレーニングをサポートするアクセラレータについては、「ハードウェアオプション」を参照してください。
- カスタムバッチ推論: GPUクラスターを管理することなく、分散GPU全体で大規模なカスタムバッチ推論をランします。
Genie Codeでクラシックコンピュートから移行する
Genie Codeは、ワークロードを従来のコンピュートから移動する際に、AIランタイムに接続されたノートブックでのコードのリファクタリングと環境のセットアップを自動化するのに役立ちます。移行ステップの完全なリストについては、「 従来のGPUワークロードをServerlessに移行する」を参照してください。
Genie Codeで自動化される処理
Genie Codeは、次の移行タスクに役立ちます：
- リファクタリング:
TorchDistributorを使用するノートブックなど、 Databricks Runtime ML ノートブックを、databricks.airの@distributedデコレーターを使用する AI ランタイム ノートブックに変換します。 - 依存関係の解決: ノートブックのインポートを評価し、欠落しているパッケージや互換性のないパッケージを特定し、Serverless GPU環境を構成します。
- マルチランク エラー診断: すべてのノードの出力 Logs を分析して、GPU メモリ不足（OOM）エラーや通信のハングアップなどの根本原因を特定します。
Genie Code移行プロンプトの例
Genie Codeに指示できるプロンプトの例を次に示します。
- コード変換: "このノートブックを TorchDistributor から databricks.air @distributed デコレーターに移行します。"
- 環境のセットアップ： "インポートされたパッケージを確認し、Databricks AI環境またはStandard環境のいずれかを推奨して、必要な%pip installコマンドを生成します。"
- デバッグ: "すべてのランクにわたる分散トレーニング Logsを分析して、ジョブが失敗した理由を特定します。"