Mettez en production les charges de travail d'entraînement

info

Aperçu

Cette fonctionnalité est en Aperçu public.

Utilisez DABs pour définir une charge de travail d’entraînement AI Runtime sous forme de code. Conservez-le dans le contrôle des sources, déployez-le dans tous les environnements, planifiez-le et associez-le à d’autres tâches. Cette page présente la méthode d’entraînement personnalisée (« bring-your-own-training »), dans laquelle un ai_runtime_task exécute votre propre commande sur un répertoire de code sur un compute GPU serverless.

astuce

Principaux enseignements

• Utilisez Declarative Automation Bundles pour définir des charges de travail d'entraînement sous forme de code, les déployer dans tous les environnements et les planifier.
• Le ai_runtime_task exécute votre propre commande sur un répertoire de code (bring-your-own-training).
• Combinez des tâches GPU et CPU dans des jobs multitâches.

Il s’agit d’une tâche différente de l’exécution d’un notebook sur GPU Serverless via un bundle. Pour obtenir un exemple de base de bundle notebook sur GPU, consultez Planifier avec l’API Jobs et Declarative Automation Bundles.

Configuration requise

• Un workspace avec AI Runtime activé. Consultez les exigences.
• La CLI Databricks (interface en ligne de commande) installée et configurée pour déployer des bundles.

Définir une tâche AI Runtime dans un bundle

Un ai_runtime_task nomme un Experimentation, pointe vers votre code d'entraînement avec code_source_path, et déclare un déploiement : la commande à exécuter et le GPU sur lequel l'exécuter. Ajoutez-le à un Job dans votre bundle :

YAML

resources:
  jobs:
    train:
      tasks:
        - task_key: train
          ai_runtime_task:
            experiment: my-experiment
            code_source_path: ./dist/code.tgz
            deployments:
              - command_path: ./command.sh
                compute:
                  accelerator_type: GPU_1xA10
                  accelerator_count: 1

code_source_path pointe vers votre code d’entraînement sous forme de package, et command_path est le script exécuté par la tâche. Les nouvelles tentatives, les délais d’expiration et les autorisations sont définis au niveau de la tâche et du job, comme pour n’importe quel job Databricks ; vos pratiques existantes en matière de bundle restent donc applicables. Pour savoir comment package et référencer votre code, consultez Expédier votre code d’entraînement.

ai_runtime_task champs

Champ	Type	Description
experiment	Chaîne	Obligatoire. Le nom de l’Experimentation MLflow pour l’exécution. Voir Suivi des Experimentation et observabilité.
code_source_path	Chaîne	Le code d’entraînement à exécuter : le fichier de sortie d’un artefact tgz mis en package, ou un chemin /Workspace ou /Volumes vers du code déjà upload. Voir Envoyez votre code d’entraînement.
deployments	Séquence	Obligatoire. Un déploiement unique décrivant la commande et le compute sur lequel l’exécuter. Chaque entrée contient command_path, compute et éventuellement name.
deployments[].command_path	Chaîne	Obligatoire. Le script que la tâche exécute sur chaque nœud.
deployments[].compute.accelerator_type	Chaîne	Obligatoire. Le type de GPU, par exemple GPU_1xA10, GPU_1xH100, GPU_8xH100 ou GPU_8xB300.
deployments[].compute.accelerator_count	Entier	Obligatoire. Le nombre total de GPU sur l’ensemble des nœuds, soit un multiple du nombre de GPU par nœud encodé dans accelerator_type.
deployments[].name	Chaîne	Nom optionnel pour le déploiement, utilisé dans les logs et l’interface utilisateur.
docker_image_url	Chaîne	Une image Docker personnalisée facultative dans laquelle exécuter la commande, au lieu de l'environnement géré. Consultez Utiliser des images Docker personnalisées avec l'ancienne CLI Python.
mlflow_run	Chaîne	Un nom d’affichage facultatif pour l’exécution MLflow.
mlflow_experiment_directory	Chaîne	Un répertoire de workspace facultatif sous lequel l’Experimentation est créée. Doit start par /Workspace. Définissez ceci lors de l’exécution en tant que Service Principal qui ne possède pas de répertoire utilisateur default.
mlflow_artifact_location	Chaîne	Un emplacement racine facultatif pour les artefacts MLflow, par exemple un chemin /Volumes/<catalog>/<schema>/<volume>/…. Doit correspondre à l’emplacement des artefacts d’une Experimentation existante ou être omis.

Champ	Type	Description
experiment	Chaîne	Obligatoire. Le nom de l’Experimentation MLflow pour l’exécution. Voir Suivi des Experimentation et observabilité.
code_source_path	Chaîne	Le code d’entraînement à exécuter : le fichier de sortie d’un artefact tgz mis en package, ou un chemin /Workspace ou /Volumes vers du code déjà upload. Voir Envoyez votre code d’entraînement.
deployments	Séquence	Obligatoire. Un déploiement unique décrivant la commande et le compute sur lequel l’exécuter. Chaque entrée contient command_path, compute et éventuellement name.
deployments[].command_path	Chaîne	Obligatoire. Le script que la tâche exécute sur chaque nœud.
deployments[].compute.accelerator_type	Chaîne	Obligatoire. Le type de GPU, par exemple GPU_1xA10, GPU_1xH100, GPU_8xH100 ou GPU_8xB300.
deployments[].compute.accelerator_count	Entier	Obligatoire. Le nombre total de GPU sur l’ensemble des nœuds, soit un multiple du nombre de GPU par nœud encodé dans accelerator_type.
deployments[].name	Chaîne	Nom optionnel pour le déploiement, utilisé dans les logs et l’interface utilisateur.
docker_image_url	Chaîne	Une image Docker personnalisée facultative dans laquelle exécuter la commande, au lieu de l'environnement géré. Consultez Utiliser des images Docker personnalisées avec l'ancienne CLI Python.
mlflow_run	Chaîne	Un nom d’affichage facultatif pour l’exécution MLflow.
mlflow_experiment_directory	Chaîne	Un répertoire de workspace facultatif sous lequel l’Experimentation est créée. Doit start par /Workspace. Définissez ceci lors de l’exécution en tant que Service Principal qui ne possède pas de répertoire utilisateur default.
mlflow_artifact_location	Chaîne	Un emplacement racine facultatif pour les artefacts MLflow, par exemple un chemin /Volumes/<catalog>/<schema>/<volume>/…. Doit correspondre à l’emplacement des artefacts d’une Experimentation existante ou être omis.

Définissez les nouveaux essais, les délais d'attente, les autorisations et l'environnement (environment_key) sur la tâche et le job, et non à l'intérieur de ai_runtime_task. Pour la référence complète de la tâche, consultez la tâche AI Runtime.

Configurez l'accélérateur matériel

Définissez accelerator_type sur le GPU requis par votre charge de travail, et accelerator_count sur le nombre total de GPU. Le compte est un multiple du nombre de GPU par nœud : 1 pour GPU_1xA10 et GPU_1xH100, et 8 pour GPU_8xH100 et GPU_8xB300. Un compte supérieur à la taille par nœud exécute la tâche sur plusieurs nœuds (par exemple, GPU_8xH100 avec accelerator_count: 16 s’exécute sur deux nœuds). Pour obtenir des conseils sur le choix d’un accélérateur, consultez les options matérielles.

remarque

Pour les exécutions multi-nœuds, AI Runtime exécute votre commande sur chaque nœud et renseigne les variables d’environnement d’entraînement distribué standard dans l’environnement de la tâche : NUM_NODES, WORLD_SIZE, LOCAL_WORLD_SIZE, MASTER_ADDR et MASTER_PORT. Lisez-les à partir de votre commande (par exemple, un lancement torchrun) ; vous ne les définissez pas dans le bundle.

Définir l’environnement et les dépendances

Déclarez un bloc environments sur le job et faites-y référence depuis la tâche avec environment_key. Runtime installe les dépendances répertoriées avant l'exécution de votre commande :

YAML

resources:
  jobs:
    train:
      tasks:
        - task_key: train
          environment_key: default
          ai_runtime_task:
            # experiment, code_source_path, and deployments as above
      environments:
        - environment_key: default
          spec:
            environment_version: '6'
            dependencies:
              - numpy

Pour les environnements disponibles, consultez Set up your environment.

Livrez votre code d’entraînement

code_source_path indique à la tâche où se trouve votre code d’entraînement. Il prend l’une des deux formes suivantes :

• Un artefact tgz sous forme de package — déclarez un artefact et faites pointer code_source_path vers son fichier de sortie. Databricks crée le tarball et l’upload sur databricks bundle deploy. Voici comment expédier du code depuis un répertoire de projet local ou une révision Git validée.
• Un chemin de Workspace ou de volume — code déjà upload, utilisé tel quel.

Packaged artifact

Déclarez un tgz artifact et pointez code_source_path vers son fichier de sortie. Sur databricks bundle deploy, la CLI génère l'archive tar, l'upload, et la tâche l'extrait et exécute votre commande dessus :

YAML

artifacts:
  code:
    type: tgz
    path: .
    include: [src]
    files:
      - source: ./dist/code.tgz
resources:
  jobs:
    train:
      tasks:
        - task_key: train
          ai_runtime_task:
            code_source_path: ./dist/code.tgz

Utilisez include pour empaqueter des fichiers depuis votre arbre de travail, ou git pour capturer l'état instantané d'une branch validée ou d'un commit.

Workspace or volume path

Pour utiliser du code qui est déjà upload, définissez code_source_path sur un chemin /Workspace/… ou /Volumes/…. Databricks utilise le chemin tel quel et n'empaquette rien.

Les champs d’artefact tgz :

Champ	Description
type	tgz génère une archive tar compressée à partir des fichiers sources, au lieu d’exécuter une commande build.
path	Le répertoire de base à package. Les chemins include et les noms d’entrée de l’archive y sont relatifs.
include	Une liste de sous-chemins de path à package. À omettre pour package l’ensemble de path. Prend en compte .gitignore; le sync.include et le sync.exclude globaux du bundle ne s’appliquent pas. Alternative à une commande build.
git	Prendre un instantané d’une référence Git validée au lieu de l’arbre de travail. Définissez git.branch ou git.commit (commit l’emporte lorsque les deux sont définis). Alternative à une commande build.
files[].source	Chemin d'accès de l'archive tar compilée. Pointer code_source_path vers ceci.

Champ	Description
type	tgz génère une archive tar compressée à partir des fichiers sources, au lieu d’exécuter une commande build.
path	Le répertoire de base à package. Les chemins include et les noms d’entrée de l’archive y sont relatifs.
include	Une liste de sous-chemins de path à package. À omettre pour package l’ensemble de path. Prend en compte .gitignore; le sync.include et le sync.exclude globaux du bundle ne s’appliquent pas. Alternative à une commande build.
git	Prendre un instantané d’une référence Git validée au lieu de l’arbre de travail. Définissez git.branch ou git.commit (commit l’emporte lorsque les deux sont définis). Alternative à une commande build.
files[].source	Chemin d'accès de l'archive tar compilée. Pointer code_source_path vers ceci.

remarque

AI Runtime extrait votre code dans un répertoire et l’expose en tant que variable d’environnement CODE_SOURCE_PATH. Référencez-le à partir de votre commande pour que les chemins relatifs soient résolus, par exemple cd "$CODE_SOURCE_PATH" avant d’exécuter votre script.

Exemple complet

Cet exemple s’entraîne sur un seul GPU A10 à partir d’un projet local, sans configuration de CLI préalable autre que l’installation et la configuration de la CLI Databricks. Le projet comporte trois fichiers :

Text

my-training/
├── databricks.yml
├── command.sh
└── src/
    └── train.py

command.sh est le point d’entrée nommé par command_path. Il se déplace dans le répertoire de code extrait et exécute le script d’entraînement :

Bash

#!/usr/bin/env bash
set -euo pipefail
cd "$CODE_SOURCE_PATH"
python train.py

databricks.yml nomme le bundle, package src/ en tant qu’artefact tgz, l’exécute en tant qu’ ai_runtime_task, installe numpy dans l’environnement de tâche et définit les cibles de développement et de production :

YAML

bundle:
  name: my-training

artifacts:
  code:
    type: tgz
    path: .
    include: [src]
    files:
      - source: ./dist/code.tgz

resources:
  jobs:
    train:
      name: my-training
      tasks:
        - task_key: train
          environment_key: default
          ai_runtime_task:
            experiment: /Users/me@example.com/my-training
            code_source_path: ./dist/code.tgz
            deployments:
              - command_path: ./command.sh
                compute:
                  accelerator_type: GPU_1xA10
                  accelerator_count: 1
      environments:
        - environment_key: default
          spec:
            environment_version: '6'
            dependencies:
              - numpy

targets:
  dev:
    mode: development
    default: true
  prod:
    mode: production

Déployez le bundle et lancez le job. databricks bundle deploy génère et upload l’artefact tgz et crée le Job ; databricks bundle run le start :

Bash

databricks bundle deploy --target dev
databricks bundle run train --target dev

Créer des flux de travail multi-tâches

Un ai_runtime_task est une tâche de job Databricks ; il s’intègre donc au reste d’un job. Vous pouvez exécuter une étape de préparation avant l’entraînement, combiner des tâches GPU et CPU dans un même job et utiliser différents accélérateurs par tâche.

Ordonnez les tâches avec depends_on

Utilisez depends_on pour exécuter des tâches en séquence. Le pipeline suivant exécute un Notebook de préparation, puis une tâche d’entraînement sur GPU qui ne start qu’une fois la tâche de préparation terminée avec succès :

YAML

resources:
  jobs:
    train_pipeline:
      tasks:
        - task_key: prep
          notebook_task:
            notebook_path: ./prep.py
        - task_key: train
          depends_on:
            - task_key: prep
          ai_runtime_task:
            experiment: my-experiment
            code_source_path: ./dist/code.tgz
            deployments:
              - command_path: ./command.sh
                compute:
                  accelerator_type: GPU_1xA10
                  accelerator_count: 1

Associer des tâches GPU et CPU

Dans le pipeline ci-dessus, seule l’étape d’entraînement nécessite un GPU. Confier les tâches sans GPU, telles que la préparation des données, à des tâches distinctes permet de consacrer le temps GPU à l’entraînement.

remarque

Un ai_runtime_task ne prend pas en charge les valeurs de tâche de job Databricks ({{tasks.<task_key>.values.<name>}} ou dbutils.jobs.taskValues). Pour transférer des données entre les étapes, écrivez-les dans un emplacement partagé que les deux tâches peuvent lire, tel qu'un volume Unity Catalog ou un fichier de workspace, et faites référence à cet chemin depuis chaque tâche.

Programmer la charge de travail

Ajoutez un schedule au job pour l’exécuter à intervalle régulier. Déployez le planning en mode suspendu afin que le déploiement du bundle ne start pas les exécutions de manière autonome, puis réactivez-le lorsque vous êtes prêt :

YAML

resources:
  jobs:
    train_pipeline:
      schedule:
        quartz_cron_expression: '0 0 9 * * ?'
        timezone_id: UTC
        pause_status: PAUSED

Passer du développement à la production

La promotion du développement à la production est une fonctionnalité standard du bundle que la tâche AI Runtime hérite sans modification.

Cibles et modes de bundle

Définissez une cible de production avec mode: production en même temps que votre cible de développement. La cible contrôle l'endroit où le bundle se déploie et la façon dont ses Ressources sont nommées :

YAML

targets:
  dev:
    mode: development
    default: true
  prod:
    mode: production

Déployez et exécutez

Déployez et exécutez le bundle sur une cible à l’aide des commandes de bundle standard :

Bash

databricks bundle deploy --target dev
databricks bundle run train_pipeline --target dev

Étapes suivantes

• Exécutez et gérez des charges de travail AI Runtime à partir de la ligne de commande avec Use the Databricks CLI with AI Runtime.
• Suivez les exécutions d’entraînement et gérez les points de contrôle. Consultez Suivi de l'Experimentation et observabilité.