AI ランタイムは、カスタムのディープ ラーニング モデル上でトレーニング、ファインチューニング、バッチ推論の実行に対応するサーバーレス GPU コンピューティングです。 これらのワークロードをDatabricks Runtime MLでクラシック コンピュート上で実行する場合、Databricksは総所有コストの低減、より柔軟な開発者エクスペリエンス、マルチノード スケールのためにAI Runtimeへの移行を推奨しています。 以下のセクションでは、MLエンジニアとプラットフォームチーム向けに両者を比較し、Genie Codeがどのように移行を助けるかを説明します。
AI Runtime とクラシック コンピューティングを比較
以下の表は、クラシックコンピュート上のAIランタイムとDatabricksランタイムMLを比較しています。
| Capability | AI ランタイム | Databricks Runtime ML のクラシック コンピュート |
|---|---|---|
| 総保有コスト (TCO) | 管理されたサーバーレスGPUインフラ、高スループット性能、最適化されたデータロード、Spark Connectを通じたSparkアクセスによりTCOを低減します。 ワークロードで使用されるコンピューティングに対してのみ支払います。 Azure Databricksはクラスタ、ドライバー、GPUの健全性を管理してくれます。 | クラスタ管理のオーバーヘッド、起動の遅さ、最適化されていないデータロードやチェックポイントによるTCOの増加。 クラスタ構成やGPUの健全性を管理する必要があり、そのためGPUクラスターの取得や維持コストが上がります。 |
| 開発者エクスペリエンス | Databricks の CLI、IDE、ノートブックから開発およびデプロイします。 ネイティブ Ray サポート。 依存関係を完全に制御するには最低限の標準環境、共通のAIやMLパッケージを持つDatabricksのAI環境、またはカスタムDockerイメージを選びましょう。 | ノートブックで開発するか、SSHトンネル経由でIDEから接続してください。 GPUトレーニング用の専用CLIはありません。 RayはSparkで動いている。 ランタイムバージョンに紐づいた多数のプリインストールライブラリで、AIや機械学習とは無関係なパッケージも含まれています。 |
| スケールとパフォーマンス | マルチノードトレーニングとバッチ推論。 最適化されたデータロードとチェックポイント処理。 長時間のトレーニングランでもGPUの高い信頼性。 | ノードやネットワークは自分で構成するため、マルチノードトレーニングには最適化されていません。 データの読み込みやチェックポイントを最適化し、GPU の正常性を手動で検証します。 |
総所有コスト
AI ランタイムは、管理対象の高性能サーバーレス GPU で総所有コストを削減します:
- 起動の速さ: サーバーレスGPUインフラはオンデマンドで利用可能なので、GPUクラスターの起動を待つ必要がありません。 クラシックGPUクラスターは、クラスタサイズやGPUの利用状況によっては、起動までに数分以上かかることがあります。
- 従量課金制: ワークロードが使用するサーバーレスGPU計算分のみを支払い、アイドルクラスターの管理や支払いは不要です。
- GPU利用率の向上: 柔軟な計算オプション、高速なデータロード、効率的なチェックポイント、マルチノードトレーニングにより、アイドルGPU時間が削減されます。
- 管理負担の軽減: AIランタイムはコンピュートのデプロイ、クラスタネットワーキング、GPUの健全性管理、CUDAドライバーのアップグレードを担当します。 クラシックコンピュートでは、ノード管理、クラスタ構成、継続的なインフラ保守をチームが担当します。
開発者エクスペリエンス
AI ランタイムは、AI とディープ ラーニングのワークロードに対して柔軟な開発者エクスペリエンスを提供します。
- 接続性:ノートブックで作業したり、SSHトンネル(ベータ版)経由でIDEから接続したり、Databricks CLIでワークロードを送信したりできます。 実行を自動化するには、ジョブをスケジュールするか、Declarative Automation Bundles を使用します。 Classic Compute には、GPU トレーニング ワークロードを送信するための専用 CLI はありません。
- 専用のディープラーニングランタイム: AIランタイムはRayやPyTorchなどのフレームワークをネイティブにサポートしています。 依存関係スタックを完全に制御するには 標準環境 、共通のAIやMLパッケージを持つ Databricks AI環境 、または カスタムDockerイメージを選びましょう。 クラシックランタイムには、ランタイムバージョンに紐づいた多数のプリインストールライブラリが含まれています。
- デバッグと可観測性:組み込みのMLflow統合を使用して、実験の追跡、計算利用率の監視、モデルの管理、問題のトラブルシューティングを行えます。 クラシック コンピューティングの場合、ログとコンピューティングの使用率メトリックが ML フロー実行に自動的に保存されることはありません。
- 安全なデータアクセス:Apache Spark クラスターを稼働させることなく、Spark Connect を通じて、Unity Catalog によって管理される構造化データおよび非構造化データにアクセスできます。
スケールとパフォーマンス
AIランタイムはディープラーニングワークロードを効率的にスケールさせるのに役立ちます:
- 最適化されたデータロードとチェックポイント: 高スループットのデータロードと非同期分散チェックポイントは、トレーニングパイプラインを加速し、アイドルGPU時間を最小限に抑えます。 クラシックコンピュートにはネイティブの高スループットデータローダーや分散チェックポイント機能がありません。 詳細は「 AI ランタイムにおけるトレーニングパフォーマンスとレジリエンスの改善」を参照してください。
- 内蔵GPUレジリエンス: 継続的な自動ヘルスチェックにより、故障したGPUノードを検出・隔離し、長期トレーニングの妨げを軽減します。 クラシックコンピュートではGPUノードの健全性を自分で維持し、不良ノードを分離するにはアクティブなワークロードを中断する必要があります。 Databricksエンジニアリングブログで、 Databricks AI全体でGPUの信頼性を維持する方法 をご覧ください。
- マルチノードトレーニング: 単一のGPUからマルチ ノード分散トレーニング へとスケールアップし、高速ネットワークと自動環境構成が可能です。 マルチノードトレーニングをサポートするアクセラレータについては、 ハードウェアオプションをご覧ください。
- カスタムバッチ推論: GPUクラスターを管理せずに分散GPU間で大規模な カスタムバッチ推論 を実行できます。
Genie Codeでクラシックコンピュートから移行
Genie Code は、ワークロードをクラシックコンピュートから移行する際、AI Runtimeに接続されたノートブックでのコードリファクタリングや環境設定の自動化を支援します。 移行手順の全リストについては、「 クラシックGPUワークロードをサーバーレスに移行する」をご覧ください。
Genie Code の自動化の対象
Genie Codeは以下の移行作業を支援します:
-
リファクタリング:
TorchDistributorを使うDatabricksランタイムMLノートブックを、databricks.airの@distributedデコレーターを使用するAIランタイムノートブックに変換します。 - 依存関係解決: ノートブックのインポートを評価し、欠落または互換性のないパッケージを特定し、サーバーレスGPU環境を構成します。
- マルチランクエラー診断: すべてのノードの出力ログを解析し、GPUメモリ外(OOM)エラーや通信ハングなどの根本原因を特定します。
Genie Code の移行用プロンプトの例
以下は Genie Codeに与えられるプロンプトの例です。
- コード変換: 「このノートブックを、TorchDistributor から databricks.air @distributed デコレーターに移行してください。」
- 環境設定: 「インポートしたパッケージを検査し、Databricks AIかStandard環境のいずれかを推奨し、必要な %pip インストールコマンドを生成します。」
- デバッグ: 「すべてのランクで分散トレーニングのログを分析して、ジョブが失敗した原因を判断してください。」