Important
この機能は パブリック プレビュー段階です。
Note
もしDatabricks classic ComputeでRayを使っているなら、Databricks Runtime MLの Ray on Databricksを参照してください。
RayはPythonワークロードのスケーリングを目的としたオープンソースフレームワークです。 AIランタイム上でRayを動かすなら、基盤となるGPUインフラのプロビジョニングや管理をしなくても可能です。
なぜAIランタイムでRayを使うのか
Rayは、モデルトレーニング、バッチ推論、データ処理、ハイパーパラメータチューニングなどのPythonワークロードの配布に一般的に使われています。 AI Runtimeでは、RayはUnity Catalogボリュームのデータにアクセスし、MLflowで実験を追跡し、本番ワークフローの一部として実行できます。
AI Runtimeでは Ray Core、 Ray Data、 Ray Train、 Ray Tune などの一般的なレイライブラリを使用できます。 既存のRayワークロードは引き続きライブラリの標準APIを使用できます。
レイがAIランタイムでどのように動作するか
すべてのRayアプリケーションはRayクラスタ上で動作し、そのクラスタには1つ以上のノードが含まれることがあります。 AI Runtimeはノードをプロビジョニングし、Rayは利用可能なCPUおよびGPUリソースにわたってタスクやアクターをスケジュールします。 Rayの起動方法は実行インターフェースによります:
| Interface | Nodes | Ray を開始する |
|---|---|---|
| Notebook | ノートブックに接続された単一のノード |
serverless_gpuのパッケージからray_init()に電話してください |
| Databricks コマンドラインインターフェース (CLI) | 1つ以上のノードの固定集合 | ノード0でヘッドを起動し、残りのノードを再利用可能なブートストラップスクリプトでワーカーとして結合します |
ノートブックでRayを使う
ノートパソコンがAI Runtime GPUコンピュートに接続されている場合、serverless_gpuパッケージのray_init()を使って接続ノードでRayを起動します:
from serverless_gpu import ray_init
ray_init()
ray_init() 標準 ray.init() APIを呼び出し、Databricksドライバープロキシ経由でRayダッシュボードへのアクセスを設定し、ノートブック出力にダッシュボードURLを印刷します。 ダッシュボードを使って、コードが実行されている間にRayジョブ、タスク、アクター、ログ、リソース使用状況をチェックできます。
Note
ray_init() 環境バージョン5以上が必要です。 Databricks AI v6にはRayが含まれています。 Standard v6を使う場合は、 ray_init()に連絡する前にRayをインストールしてください。 「 環境を設定する」を参照してください。
ノートブックの例
| 例 | Description |
|---|---|
| レイコア ハローワールド | 非同期GPUタスクを接続された計算に提出し、Rayダッシュボードでスケジューリングを確認し、結果を取得します。 |
| CIFAR-10 ハイパーパラメータチューニングとレイチューン | PyTorch画像分類器で並行分数GPU試験を実行し、非同期連続半分アルゴリズム(ASHA)を使って性能不振な構成を早期に止めます。 |
| Qwen2.5-32BのRay DataおよびvLLMによるバッチ推論 | 8つの永続的vLLMレプリカを8台のH100 GPU上でマルチリンガルバッチ推論を実行し、その結果をUnityカタログのボリュームにParquetとして保存します。 |
DatabricksのCLIでRayを使いましょう
AIランタイム用のDatabricksのCLIコマンドは、単一ノードおよび多ノードのRayワークロードをサポートします。 ワークロード構成では、固定 accelerator_type と総 num_acceleratorsを指定します。
Ray Coreの入門レシピには再利用可能なブートストラップスクリプトが含まれています。 ワークロードのcommandで、RAY_ENTRYPOINTをPythonファイルのパスに設定し、ブートストラップスクリプトを実行します。 ブートストラップスクリプトは以下のことをします:
- ノード0でレイヘッドを起動し、設定済みのエントリポイントを実行します。
- 他のノードではRayワーカーを起動し、エントリーポイントが実行される間も接続を維持します。
- エントリーポイントが終わると、レイプロセスは停止します。
アプリケーション内で、 ray.init(address="auto")でクラスターに接続します。
標準環境では、ray[data]、ray[train]、ray[tune]などのrayや必要な追加要素をワークロード依存関係に追加します。 Databricks AI v6にはRayが含まれています。
Ray と共に始めましょう
以下の最小限の例は、主要なRayライブラリを紹介し、同じクラスタブートストラップパターンを共有しています。
| 例 | Description |
|---|---|
| レイ・コア | 2台のA10 GPUでRayクラスターを立ち上げ、GPUごとにRay Coreタスクを1つずつスケジュールします。 |
| レイ・トレイン | 合成データ上で小型の多層パーセプトロンを、GPUごとに1人のRay Trainワーカーで訓練します。 |
| レイデータ | Rayクラスター全体で合成データ処理パイプラインを実行します。 |
| レイ・チューン | 合成データに対して小型の多層パーセプトロンをチューニングし、GPUごとに1回の試行を行います。 |
追加のCLI例
| 例 | Description |
|---|---|
| Ray TrainによるResNet-50の微調整 | ResNet-50を2つのノードにまたがって、A10 GPUごとに1つの分散データ並列ワーカーで微調整します。 |
| Qwen2.5-3BによるRay Trainによる微調整 | Qwen2.5-3Bを8xのH100ノード上でGPUごとに分散データパラレルワーカー1つにして微調整します。 |
| Ray Data と vLLM を使用したバッチ推論 | Qwen2.5-7B-Instructで回答を生成し、その結果をParquetとしてUnityカタログのボリュームに書き込みます。 |
| Ray TuneによるLoRAハイパーパラメータ検索 | 4つのA10 GPUでQwen2.5-0.5BのLoRA構成を検索し、ASHAスケジューラーでパフォーマンス不振の試験を停止しましょう。 |
| Ray TuneによるXGBoostハイパーパラメータ検索 | 4台のA10 GPUでXGBoostのハイパーパラメータを検索し、最適な構成をMLflowに記録し、Unity Catalogにモデルを登録します。 |
データと Databricks の機能を使用する
RayワークロードはUnity Catalogボリュームのデータにアクセスし、MLflowで実行を記録し、宣言的自動化バンドルで定義されたLakeflowジョブタスクとして実行できます。
Unity カタログにおけるデータへのアクセス
Unityカタログテーブル内の表形式データについては、 ray.data.read_databricks_tables() を使ってテーブルを読み込んだり、DatabricksのSQLウェアハウスでSQLクエリを実行したりします。 倉庫ID、カタログ、スキーマを指定してください。AI RuntimeはローカルのSparkセッションを提供しません。 SQLを使って、Rayが結果を処理する前に結合、集約、フィルターを実行できます。
ファイルベースや非構造化データの場合は、Unity Catalogボリュームをご利用ください。 レイワーカーは /Volumes/<catalog>/<schema>/<volume>/... パスを使ってファイルにアクセスできます。 例えば、Ray DataはParquetファイルを ray.data.read_parquet() で読み取り、 Dataset.write_parquet()で結果を書き込むことができます。
ワークロードを追跡して統合管理
MLflowを使って、Rayワークロードのパラメータ、指標、アーティファクトを記録しましょう。 「 実験の追跡と観測可能性」を参照してください。
ワークロードをスケジュール化したり、CPUのデータ準備タスクで組み合わせる場合は、Lakeflow JobsとDeclarative Automation Bundlesをご利用ください。 「GPU ワークロードのスケジュール設定とタスクの作成」を参照してください。
既存のRayワークロードの移行
セルフマネージドのRayワークロードの移行には、インフラ構成やサービス統合をAIランタイム実行モデルに置き換えることが含まれます。
ワークロードを評価する
移行前に制限を確認してください。 ワークロードが1種類のアクセラレータで固定サイズのクラスタで動作可能か確認してください。
ワークロードを移行する
セルフマネージドのRayワークロードを移行するには:
- インタラクティブなシングルノード開発にはノートブック、シングルノードまたはマルチノードジョブにはDatabricks CLIを選びましょう。
- 既存のクラスターリソースをAIランタイムのアクセラレータタイプとアクセラレータ数にマッピングします。 ハードウェア オプションを参照してください。
- 既存のクラスターの起動を、ノートブックでは
ray_init()に、Databricks CLI ワークロードではドキュメントに記載されているヘッド ノードおよびワーカー ノードのブートストラップに置き換えます。 - ワークロードのPython依存関係を宣言し、データ、チェックポイント、モデル、出力パスを更新します。
- 最小の適用構成でワークロードを検証します。 意図した固定トポロジーをテストする前に、データアクセス、リソースリクエスト、出力を確認してください。
Limitations
AIランタイム上のRayには以下の制限があります:
- Rayクラスターは、ワークロード期間中固定されたノード数を持っています。 レイクラスターのオートスケーリングはサポートされていません。
- ワークロード内のすべてのノードは同じ
accelerator_typeを使用します。 RayクラスターはCPU専用とGPUワーカーグループを別々に含めたり、CPUとGPUの容量を独立してスケールさせることもできません。 - ノートブックは接続された単一のノードでRayを起動します。 マルチノードのRayクラスターにはDatabricksのCLIを使いましょう。
- Databricksドライバープロキシを通じたRayダッシュボードへのアクセスは現在、ノートブックワークロードのみで利用可能です。
Tip
CPU準備とGPU処理が別々の段階として動作できる場合は、マルチタスクのLakeflowジョブを使用し、Unityカタログボリュームを通じてタスク間でデータをやり取りします。