Databricks CLI と AI ランタイム を使用する
databricks air CLIは、オンデマンドのServerlessGPUコンピュートプラットフォームであるAI ランタイムでシングルノードおよびマルチノードのGPUワークロードを実行します。YAMLでワークロードのコンピュート、環境、コマンドを定義し、databricks air runでサブミットします。
AI ランタイムは、GPUのプロビジョニングと環境設定を処理し、ランステータス、Log、システムメトリクス、およびMLflowトラッキングを提供します。YAML および CLI ワークフローは、ワークロードの定義、送信、および監視を行うことができるコーディング エージェントと自然に連携します。
CLIを使用して次の操作を行います：
- ローカル環境から Python アプリケーションを開発し、繰り返します。
- ソース管理できるYAMLファイルで、繰り返し可能な単一ノードまたはマルチノードのワークロードを定義します。
- ターミナルまたは自動化された開発ワークフローからワークロードを送信および管理します。
一般的なワークロードには、LLMのファインチューニングとポストトレーニング、分散トレーニング、バッチ推論、Rayアプリケーション、ハイパーパラメータ検索などがあります。
ワークスペースの要件については、 要件を参照してください。ワークロードを送信するには、 クイックスタートに従ってください。
AI ランタイムのDatabricks CLIコマンドは、AI ランタイムワークロードと同じコンプライアンス標準を満たしています。サポートされている標準と例外については、 コンプライアンス セキュリティ プロファイルを参照してください。
databricks air コマンドとワークロード構成は、databricks-air パッケージの従来の Python ベースの air CLI とは異なります。「Python CLI の移行」をご覧ください。
実行可能なサンプルを探索する
AI ランタイムクックブックには、モデルトレーニング、ファインチューニング、バッチ推論、Ray、ハイパーパラメータ検索の実行可能な Databricks CLI ワークロードが含まれています。各レシピには、ワークロード YAML ファイル、ソースコード、およびそれを実行するための手順が含まれています。
ワークロードのラン方法
ワークロードYAMLファイル、必要に応じてアプリケーションコード、そしてアプリケーションを起動するコマンドを提供します。ワークロードを送信する場合：
- ワークロード定義は、サポートされているスキーマおよび構成の制約に対して検証されます。
code_sourceが構成されている場合、選択したコードはスナップショットとしてパッケージ化され、upload されます。- 要求された GPU コンピュートと環境は、各ノードで準備されます。
- ワークロードYAMLで指定されたコマンドは、各ノードでランします。
送信は、ワークロードを識別するジョブ実行IDを返します。これを使用して、ステータスの確認、Logsと構成の検査、またはワークロードのキャンセルを行います。ジョブランページと MLflow エクスペリメントを表示して、実行の詳細、システムメトリクス、Log、アーティファクトを確認することもできます。
このワークフローは、GPUインフラストラクチャを設定または維持することなく、管理されたGPUプロビジョニング、再現可能な環境セットアップ、および組み込みのオブザーバビリティを提供します。
Workload 構成
ワークロードYAMLファイルは、次のコンポーネントを記述します。
- エクスペリメント : ワークロードを追跡する MLflow エクスペリメントおよびラン。
- 環境 : 使用する管理対象環境、依存関係、または カスタム Docker イメージ。
- コンピュート : プロビジョニングするアクセラレータのタイプと数。
- コードソース ：ワークロードで使用できるようにするアプリケーションコードのオプションのスナップショット。
- コマンド : アプリケーションを起動するシェルコマンド。
- ランタイム設定 : 再試行、タイムアウト、環境変数、シークレット、権限などのオプション。
構成フィールドと例については、 Workload YAML リファレンスを参照してください。
アプリケーションコードをuploadする
code_sourceを使用して、ワークロードと一緒にアプリケーションファイルをuploadします。AI ランタイムはuploadされたディレクトリをすべてのノードで使用できるようにし、 $CODE_SOURCE_PATHをその場所として設定します。たとえば、次のコマンドはuploadディレクトリから train.pyを実行します。
command: python "$CODE_SOURCE_PATH/train.py"
現在の作業ツリーをuploadするか、GitのBranchまたはcommitを選択できます。完全な例については、「 クイックスタート」を参照してください。
ワークロードの開発と管理
開発は通常、このプロセスに従います。
- アプリケーションコードとワークロードYAMLをローカルで開発します。
databricks air run --file <file> --dry-runを使用してYAMLをローカルで検証します。databricks air run --file <file>を使用してワークロードをサブミットします。--watchを追加して、ランが終了するまでLogsをストリームします。databricks air get、databricks air list、およびdatabricks air logsを使用して、ワークロードとLogsを検査します。- 必要に応じて、
databricks air cancelで実行中のワークロードを停止できます。
すべてのコマンドとフラグについては、air コマンド グループを参照してください。
スケジュールされたラン、マルチタスク ワークフロー、または環境全体でのプロモーションの場合、 databricks air convert-to-dabs をバンドルの開始点として使用できます。GPU ワークロードのスケジュールとタスクの作成を参照してください。
MLflowでワークロードを追跡する
送信された各ワークロードは Databricks ジョブランで表され、MLflow のエクスペリメントによって追跡されます。
- Databricks ジョブラン : ジョブランページでワークロードのステータス、実行試行、および出力を表示します。
- MLflowエクスペリメント : 自動的にキャプチャされたシステムメトリクス、ワークロード構成、Logsを含むMLflowランが含まれます。アプリケーションは、MLflow APIs を使用してカスタムパラメーター、メトリクス、アーティファクトをログに記録することもできます。
databricks air get、databricks air logs、databricks air cancelなどのコマンドでは、ジョブランIDを使用します。エクスペリメントの追跡と観察可能性を参照してください。
シングルノードおよび分散ワークロードをラン
AI ランタイムは、構成されたコマンドをプロビジョニングされた各ノードで1回ランします。分散ワークロードの場合、NUM_NODES、NODE_RANK、LOCAL_WORLD_SIZE、MASTER_ADDR、MASTER_PORTなどの調整変数を提供します。
この実行モデルはフレームワークに依存しません。コマンドは、torchrun、Ray ブートストラップ スクリプト、または別のフレームワーク ランチャーを呼び出すなど、分散フレームワークを起動して構成する必要があります。完全なワークロードについては、「 AI ランタイム クックブック」を参照してください。
AI エージェントの使用
databricks-ai-runtime エージェントスキルは、Claude Code、Cursor、Codex などの AI エージェントが Databricks CLI を介して AI ランタイムを操作するための手順を提供します。これを使用して、ワークロード YAMLの作成、GPUトレーニングジョブの送信、ランステータスの確認、Logsのストリーム、ランのキャンセルを行います。また、カスタム Dockerイメージのガイダンスも含まれています。
Databricks CLI をインストールして認証を構成した後、次のコマンドを実行します。
databricks aitools install --skills-only --skills databricks-ai-runtime
プロンプトに従って、AI エージェントとインストール範囲を選択します。インストール オプションについては、aitoolsコマンド グループを参照してください。スキルでカバーされている内容については、AI ランタイムでエージェントスキルを使用するを参照してください。