Ray sur le Runtime d'exécution de l'IA
Si vous utilisez Ray sur le compute classique de Databricks avec Databricks Runtime ML, consultez Ray sur Databricks.
Ray est un framework open source pour mettre à l’échelle les workloads Python. Vous pouvez exécuter Ray sur AI Runtime sans avoir à provisionnement ou à gérer l’infrastructure GPU sous-jacente.
Pourquoi utiliser Ray sur Runtime ?
Ray est couramment utilisé pour distribuer des charges de travail Python comme l'entraînement de modèle, l'inférence par 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 les expérimentations avec MLflow et s'exécuter dans le cadre des 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 l'IA Runtime
Chaque application Ray s’exécute sur un cluster Ray, qui peut contenir un ou plusieurs nœuds. AI Runtime provisionne les nœuds, et Ray planifie les tâches et les acteurs sur leurs ressources CPU et GPU disponibles. La façon de start Ray dépend de l’interface d’exécution :
Interface | Nœuds | start Ray |
|---|---|---|
Notebook | Le nœud unique attaché au notebook | Appelez |
CLI Databricks | Un ensemble fixe d'un ou plusieurs nœuds | start le head sur le nœud 0 et joignez les nœuds restants en tant que Worker à l’aide d’un script d’amorçage réutilisable |
Utiliser Ray dans les 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 attaché :
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 imprime 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 de Ray pendant que votre code s’exécute.
ray_init() nécessite la version 5 ou une version supérieure de l’environnement. Dans la version 5, importez-la depuis serverless_gpu plutôt que databricks.air. Databricks AI v6 inclut Ray. Si vous utilisez la version 6 standard, installez Ray avant d’appeler ray_init(). Voir Configurer votre environnement.
Exemples de notebooks
Exemple | Description |
|---|---|
Soumettez des tâches GPU asynchrones sur le compute attaché, examinez le scheduling dans le tableau de bord Ray et récupérez les résultats. | |
Exécutez des essais concomitants sur GPU fractionnaire pour un classificateur d'images PyTorch et utilisez l'algorithme ASHA (asynchronous successive halving algorithm) pour arrêter prématurément les configurations sous-performantes. | |
Exécutez une 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. |
Utiliser Ray avec la CLI Databricks
Les commandes CLI Databricks 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 de votre fichier Python et exécutez le script d'amorçage. Le script d'amorçage effectue les opérations suivantes :
- Sur le nœud 0, il start le head Ray et exécute le point d’entrée configuré.
- Sur tous les autres nœuds, il start un Worker Ray et le maintient connecté pendant l'exécution du point d'entrée.
- Une fois que le point d'entrée est 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 petit perceptron multicouche 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. | |
Réglez un petit perceptron multicouche sur des données synthétiques avec un essai par GPU. |
Exemples CLI supplémentaires
Exemple | Description |
|---|---|
Affinez ResNet-50 avec un worker parallèle de données distribuées par GPU A10 sur deux nœuds. | |
Affinez Qwen2.5-3B avec un worker de parallélisation de données distribuées par GPU sur un nœud 8x H100. | |
Générez des réponses avec Qwen2.5-7B-Instruct et écrivez les résultats dans un volume Unity Catalog au format Parquet. | |
Rechercher des configurations LoRA pour Qwen2.5-0.5B sur quatre GPU A10 et arrêter les essais peu performants avec le planificateur ASHA. | |
Recherchez les hyperparamètres XGBoost sur quatre GPU A10, Log la meilleure configuration sur MLflow et inscrivez le modèle dans Unity Catalog. |
Travailler avec des données et des fonctionnalités Databricks
Les charges de travail Ray peuvent accéder aux données dans les volumes Unity Catalog, enregistrer des exécutions avec MLflow et s’exécuter en tant que tâches Lakeflow Jobs définies avec Declarative Automation Bundles.
Accéder aux données dans Unity Catalog
Pour les données tabulaires dans 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 le 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 traite les résultats.
Pour les données non structurées et basées sur des fichiers, 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 des résultats avec Dataset.write_parquet().
Suivre et orchestrer les charges de travail
Utilisez MLflow pour enregistrer des parameter, des indicateurs et des artefacts à partir d’une charge de travail Ray. Voir Suivi et observabilité de l’Experimentation.
Pour planifier la charge de travail ou la composer avec des tâches de préparation des 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
Pour migrer une charge de travail Ray autogérée, vous devez remplacer la configuration de son infrastructure et ses intégrations de services par le modèle d'exécution de l'environnement d'exécution de l'IA Runtime.
Évaluez votre charge de travail
Avant de procéder à la migration, examinez les limitations. Confirmez que la charge de travail peut s’exécuter sur un cluster de taille fixe avec 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 du cluster existant vers un type d'accélérateur et un nombre d'accélérateurs AI Runtime. Voir Options matérielles.
- Remplacez le cluster startup existant par
ray_init()dans un notebook ou le head and worker bootstrap documenté dans un 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, aux points de contrôle, au modèle et aux sorties.
- 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 sur Runtime de l'IA présente les limites suivantes :
- Le cluster Ray possède un nombre fixe de nœuds pendant toute la durée d'une charge de travail. Le dimensionnement automatique des clusters 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 des groupes de Worker CPU uniquement et GPU séparés, ou monter en charge les capacités CPU et GPU indépendamment. - Un Notebook start Ray sur son nœud unique associé. Utilisez le CLI Databricks pour un cluster Ray à plusieurs nœuds.
- L'accès au tableau de bord Ray via le proxy du driver Databricks n'est actuellement disponible que pour les workloads de notebook.
Si la préparation CPU et le traitement GPU peuvent être exécutés comme des étapes distinctes, utilisez un Lakeflow Job multitâche et transférez les données entre les tâches via un volume Unity Catalog.