Ray sur AI Runtime
Aperçu
Cette fonctionnalité est en Aperçu public.
Si vous utilisez Ray sur le compute classique Databricks avec Databricks Runtime ML, consultez Ray sur Databricks.
Ray est un framework open source dédié à la mise à l'échelle des charges de travail Python. Vous pouvez exécuter Ray sur AI Runtime sans avoir à provisionnement ni à gérer l'infrastructure GPU sous-jacente.
Pourquoi utiliser Ray sur AI Runtime
Ray est couramment utilisé pour distribuer des charges de travail Python telles que l'entraînement de modèles, l'inférence de batch, le traitement de données et l'ajustement des hyperparamètres. Sur AI Runtime, Ray peut accéder aux données des volumes Unity Catalog, suivre des expérimentations avec MLflow et s'exécuter dans le cadre de workflows de production.
Vous pouvez utiliser des bibliothèques Ray courantes telles que Ray Core, Ray Data, Ray Train et Ray Tune sur AI Runtime. Les workloads Ray existants peuvent continuer à utiliser les APIs standard des bibliothèques.
Comment Ray fonctionne avec AI Runtime
Chaque application Ray s’exécute sur un cluster Ray, qui peut contenir un ou plusieurs nœuds. AI Runtime assure le provisionnement des nœuds, et Ray planifie les tâches et les acteurs sur les ressources CPU et GPU disponibles. La manière dont vous start Ray dépend de l’interface d’exécution :
Interface | Nœuds | Start Ray |
|---|---|---|
Notebook | Le nœud unique associé au notebook | Appelez |
CLI Databricks | Un ensemble fixe d’un ou plusieurs nœuds | start the head sur le nœud 0 et connectez les nœuds restants en tant que Worker à l’aide d’un script de démarrage réutilisable. |
Utiliser Ray dans des Notebooks
Lorsque votre notebook est connecté au compute GPU AI Runtime, utilisez ray_init() depuis le SDK Databricks AI Runtime pour start Ray sur le nœud associé :
from databricks.air import ray_init
ray_init()
ray_init() appelle l’API ray.init() standard, configure le tableau de bord Ray pour un accès via le proxy du driver Databricks et affiche l’URL du tableau de bord dans la sortie du notebook. Utilisez le tableau de bord pour inspecter les jobs, les tâches, les acteurs, les logs et l'utilisation des ressources Ray pendant l'exécution de votre code.
ray_init() nécessite la version 5 de l'environnement ou une version ultérieure. Dans la version 5, importez-le depuis serverless_gpu au lieu de databricks.air. Databricks AI v6 inclut Ray. Si vous utilisez Standard v6, installez Ray avant d'appeler ray_init(). Voir Configuration de votre environnement.
Exemples de Notebook
Exemple | Description |
|---|---|
Soumettez des tâches GPU asynchrones sur le compute attaché, inspectez la planification dans le tableau de bord Ray et récupérez les résultats. | |
Exécuter des essais concurrents sur GPU fractionnaire pour un classificateur d’images PyTorch et utiliser l’algorithme de halving successif asynchrone (ASHA) pour interrompre prématurément les configurations sous-performantes. | |
Exécutez l’inférence par batch multilingue avec huit réplicas vLLM persistants sur 8 GPU H100 et enregistrez les résultats au format Parquet dans un volume Unity Catalog. |
Utilisation de Ray avec la CLI Databricks
Les commandes Databricks CLI pour AI Runtime prennent en charge les charges de travail Ray à nœud unique et à nœuds multiples. Dans la configuration de la charge de travail, spécifiez un accelerator_type fixe et le num_accelerators total. La recette de start de Ray Core inclut un script d’amorçage réutilisable. Dans le command de la charge de travail, définissez RAY_ENTRYPOINT sur le chemin d’accès à votre fichier Python, puis exécutez le script d’amorçage. Le script d’amorçage effectue les opérations suivantes :
- Sur le nœud 0, cela start le head Ray et exécute le point d'entrée configuré.
- Sur tous les autres nœuds, cela start un Worker Ray et le maintient connecté pendant l'exécution du point d'entrée.
- Une fois le point d'entrée terminé, il arrête les processus Ray.
Dans l’application, connectez-vous au cluster avec ray.init(address="auto").
Avec l'environnement Standard, ajoutez ray ou le supplément requis, tel que ray[data], ray[train] ou ray[tune], aux dépendances de la charge de travail. Databricks AI v6 inclut Ray.
Premiers pas avec Ray
Les exemples minimaux suivants présentent les principales bibliothèques Ray et partagent le même modèle d’amorçage de cluster.
Exemple | Description |
|---|---|
Start un cluster Ray sur deux GPU A10 et planifiez une tâche Ray Core par GPU. | |
Entraînez un perceptron multicouche de petite taille sur des données synthétiques, avec un Worker Ray Train par GPU. | |
Exécuter un pipeline de traitement de données synthétiques sur un cluster Ray. | |
Ajuster un petit perceptron multicouche sur des données synthétiques, avec un essai par GPU. |
Exemples supplémentaires de CLI
Exemple | Description |
|---|---|
Affinez ResNet-50 avec un Worker de traitement parallèle distribué des données par GPU A10 sur deux nœuds. | |
Affinez Qwen2.5-3B avec un Worker de parallélisme distribué des données par GPU sur un nœud équipé de 8 GPU H100. | |
Générez des réponses avec Qwen2.5-7B-Instruct et écrivez les résultats au format Parquet dans un volume Unity Catalog. | |
Recherchez des configurations LoRA pour Qwen2.5-0.5B sur quatre GPU A10 et arrêtez les essais sous-performants avec le planificateur ASHA. | |
Rechercher les hyperparamètres de XGBoost sur quatre GPU A10, Log la meilleure configuration dans MLflow et enregistrer le modèle dans Unity Catalog. |
Travailler avec les données et les fonctionnalités de Databricks
Les charges de travail Ray peuvent accéder aux données des volumes Unity Catalog, enregistrer les exécutions avec MLflow et s’exécuter en tant que tâches Lakeflow Jobs définies avec Declarative Automation Bundles.
Accédez aux données dans Unity Catalog.
Pour les données tabulaires d’une table Unity Catalog, utilisez ray.data.read_databricks_tables() pour lire une table ou exécuter une query SQL via un warehouse Databricks SQL. Spécifiez l’ID du warehouse, le catalogue et le schéma, car l’AI Runtime ne fournit pas de session Spark locale. Vous pouvez utiliser SQL pour effectuer des jointures, des agrégations et des filtres avant que Ray ne traite les résultats.
Pour les données basées sur des fichiers et non structurées, utilisez un volume Unity Catalog. Les Worker Ray peuvent accéder aux fichiers en utilisant leurs chemins /Volumes/<catalog>/<schema>/<volume>/.... Par exemple, Ray Data peut lire des fichiers Parquet avec ray.data.read_parquet() et écrire les résultats avec Dataset.write_parquet().
Suivre et orchestrer les charges de travail
Utilisez MLflow pour enregistrer les paramètres, les métriques et les artefacts d’une charge de travail Ray. Consultez Suivi et observabilité de l'Experimentation.
Pour planifier la charge de travail ou la composer avec des tâches de préparation de données CPU, utilisez Lakeflow Jobs et Declarative Automation Bundles. Voir Planifier des charges de travail GPU et composer des tâches.
Migrer une charge de travail Ray existante
La migration d'une charge de travail Ray autogérée implique de remplacer sa configuration d'infrastructure et ses intégrations de service par le modèle d'exécution d'AI Runtime.
Évaluer votre charge de travail
Avant de procéder à la migration, consultez les limitations. Confirmez que la charge de travail peut s'exécuter sur un cluster de taille fixe doté d'un seul type d'accélérateur.
Migrer la charge de travail
Pour migrer une charge de travail Ray autogérée :
- Choisissez un notebook pour le développement interactif à nœud unique ou la CLI Databricks pour les jobs à nœud unique ou à nœuds multiples.
- Mappez les ressources de clusters existantes à un type d’accélérateur AI Runtime et à un nombre d’accélérateurs. Consultez les options matérielles.
- Remplacez le Startup du cluster existant par
ray_init()dans un Notebook ou le processus d’initialisation documenté du head et du Worker dans une charge de travail Databricks CLI. - Déclarez les dépendances Python de la charge de travail et mettez à jour ses chemins d’accès aux données, au point de contrôle, au modèle et au résultat.
- Validez la charge de travail sur la plus petite configuration applicable. Confirmez son accès aux données, ses demandes de ressources et ses sorties avant de tester la topologie fixe prévue.
Limitations
Ray on AI Runtime présente les limitations suivantes :
- Le cluster Ray a un nombre de nœuds fixe pendant toute la durée d’une charge de travail. Le dimensionnement automatique du cluster Ray n’est pas pris en charge.
- Tous les nœuds d'une charge de travail utilisent le même
accelerator_type. Un cluster Ray ne peut pas contenir de groupes de Worker distincts dédiés uniquement au CPU et au GPU, ni monter en charge la capacité CPU et GPU de manière indépendante. - Un notebook start Ray sur son nœud unique associé. Utilisez la CLI Databricks pour un cluster Ray à nœuds multiples.
- L'accès au tableau de bord Ray via le proxy du driver Databricks n'est actuellement disponible que pour les charges de travail de notebook.
Si la préparation sur CPU et le traitement sur GPU peuvent s'exécuter en tant qu'étapes distinctes, utilisez un Lakeflow Job multi-tâche et transmettez les données entre les tâches via un volume Unity Catalog.