Suivi et observabilité des expériences

Important

Cette fonctionnalité est disponible en préversion publique.

AI Runtime s’intègre en mode natif à MLflow pour le suivi des expériences et inclut un volet de ressources GPU intégré pour la surveillance de l’utilisation, de la mémoire et de la température. Utilisez MLflow pour journaliser les métriques et les exécutions, afficher la sortie d’entraînement dans le notebook et l’interface utilisateur MLflow, enregistrer des points de contrôle de modèle dans les volumes du catalogue Unity et suivre l’intégrité du GPU pendant l’exécution de votre code.

Intégration de MLflow

AI Runtime s’intègre en mode natif à MLflow pour le suivi des expériences, la journalisation des modèles et la visualisation des métriques.

Recommandations d’installation :

• Mettez à niveau MLflow vers la version 3.7 ou ultérieure et suivez les modèles de flux de travail d’apprentissage profond.

• Activer l’autologging pour PyTorch Lightning :

  import mlflow
  mlflow.pytorch.autolog()
  

• Personnalisez votre nom d’exécution MLflow en encapsulant votre code d’entraînement de modèle dans l’étendue de l’API mlflow.start_run() . Cela vous permet de contrôler le nom de l’exécution et vous permet de redémarrer à partir d’une exécution précédente. Vous pouvez personnaliser le nom d’exécution à l’aide du run_name paramètre dans mlflow.start_run(run_name="your-custom-name") ou dans des bibliothèques tierces qui prennent en charge MLflow (par exemple, Hugging Face Transformers). Sinon, le nom d’exécution par défaut est jobTaskRun-xxxxx.

  from transformers import TrainingArguments
  args = TrainingArguments(
      report_to="mlflow",
      run_name="llama7b-sft-lr3e5",  # <-- MLflow run name
      logging_steps=50,
  )
  

• Lorsque vous utilisez l’API GPU sans serveur, chaque appel à .distributed() crée automatiquement une exécution d’expérience MLflow. S'il est appelé au sein d'une exécution MLflow active, une exécution enfant imbriquée est créée sous l'exécution parente active.

  import mlflow
  
  with mlflow.start_run() as outer_run:
      ...
      run_train.distributed()  # creates a nested child run under outer_run
  

• Pour personnaliser l’expérience utilisée par .distributed(), appelez mlflow.set_experiment() avant l’appel .distributed()ou définissez la variable d’environnement MLFLOW_EXPERIMENT_NAME . Le nom de l’expérience par défaut est /Users/{WORKSPACE_USER}/{notebook-name}. Utilisez toujours des chemins absolus.

  import mlflow
  mlflow.set_experiment("/Users/<username>/my-experiment")
  run_train.distributed()
  

  Alternatively:

  import os
  os.environ["MLFLOW_EXPERIMENT_NAME"] = "/Users/<username>/my-experiment"
  

• Pour reprendre une exécution MLflow précédente, utilisez mlflow.start_run(run_id="<previous-run-id>").

• Pour reprendre une exécution MLflow précédente avec .distributed(), définissez MLFLOW_RUN_ID avant de l’appeler :

  os.environ["MLFLOW_RUN_ID"] = "<previous-run-id>"
  run_train.distributed()
  

• Définissez le paramètre step dans MLFlowLogger sur des numéros de batch raisonnables. MLflow possède une limite de 10 millions d’étapes de métrique. Par conséquent, la journalisation de chaque batch lors d’exécutions de formation de grande ampleur risque d’atteindre cette limite. Consultez l’article Limites des ressources.

Consultation des journaux

• Sortie du notebook : les sorties et les erreurs standard de votre code de formation s’affichent dans la sortie de la cellule de notebook.
• Journaux MLflow : l’interface utilisateur de l’expérience MLflow affiche les métriques d’apprentissage, les paramètres et les artefacts.

Création de points de contrôle

Pour l’entraînement distribué, sauvegardez l’état du modèle et de l’optimiseur dans des volumes Unity Catalog en utilisant l’API Torch Distributed Checkpoint (DCP) avec les serverless_gpu.data.UCVolumeWriter backends et stockage serverless_gpu.data.UCVolumeReader . Sauvegarder de façon asynchrone pour que l’entraînement continue pendant que le point de contrôle est téléchargé, et le point de contrôle est assez souvent pour limiter le travail perdu après une interruption. Parce qu’un point de contrôle modèle ne capture pas la position du pipeline de données, il faut aussi faire checkpoint à votre pipeline de données afin qu’une exécution reprise continue sur les données correctes.

Pour le schéma complet de checkpointing, voir Améliorer la performance et la résilience de l’entraînement sur l’exécution IA.

Surveiller les ressources GPU

Utilisez le volet ressources GPU pour surveiller l’intégrité et l’utilisation du GPU pendant que votre code s’exécute sur AI Runtime. Le volet prend en charge les charges de travail à nœud unique et à plusieurs nœuds.

Pour ouvrir le volet, connectez votre bloc-notes à AI Runtime, puis cliquez sur Ressources GPU dans le volet latéral droit.

Le volet affiche les métriques suivantes pour chaque GPU :

• Pourcentage d’utilisation du GPU
• Utilisation de la mémoire GPU
• Température

Le volet interroge les métriques toutes les 10 secondes et conserve jusqu’à 2 heures d’historique. Cliquez sur Actualisez pour récupérer les dernières valeurs immédiatement. Après 5 minutes d’inactivité, le volet s’interrompt ; rouvrez-le pour reprendre la surveillance.

Collaboration multi-utilisateurs

• Pour vous assurer que tous les utilisateurs peuvent accéder au code partagé (par exemple, les modules d’assistance ou les fichiers YAML d’environnement), stockez-les au /Workspace/Shared lieu de dossiers spécifiques à l’utilisateur comme /Workspace/Users/<your_email>/.
• Pour le code en cours de développement actif, utilisez des dossiers Git dans des dossiers /Workspace/Users/<your_email>/ spécifiques à l’utilisateur et envoyez (push) aux dépôts Git distants. Cela permet à plusieurs utilisateurs d’avoir un clone et une branche spécifiques à l’utilisateur, tout en utilisant un référentiel Git distant pour le contrôle de version. Consultez les meilleures pratiques d’utilisation de Git sur Databricks.
• Les collaborateurs peuvent partager et commenter des blocs-notes.

Limites globales dans Azure Databricks

Consultez l’article Limites des ressources.