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.

Tip

• AI Runtime s’intègre nativement avec MLflow pour le suivi des expériences et la journalisation des modèles.
• Un panneau de ressources GPU intégré affiche l’utilisation, la mémoire et la température.
• Sauvegardez les points de contrôle des modèles dans des volumes du catalogue Unity.

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.

Si vous ne pouvez pas consulter les journaux

L’onglet Logs de la page d’exécution MLflow affiche en continu les journaux de l’exécution du job Databricks associée à l’exécution MLflow ; l’accès est donc régi par les autorisations de ce job. Si l’onglet affiche Vous n’avez pas accès à ces journaux, cela signifie que l’utilisateur ne dispose pas des autorisations suffisantes.

L’accès à l’exécution dans MLflow n’implique pas l’accès à la tâche. Vous pouvez disposer de l’autorisation sur l’expérience MLflow et pourtant vous voir refuser les logs. Pour y accéder, demandez aux utilisateurs disposant des droits Peut gérer ou à un administrateur de l’espace de travail de vous accorder au moins l’autorisation Peut voir sur la tâche. Voir Contrôle de l’accès à une tâche pour savoir comment les permissions de tâche sont accordées.

Création de points de contrôle

Pour l’entraînement distribué, sauvegardez l’état du modèle et de l’optimiseur dans Unity Catalog volumes à l’aide de l’API Torch Distributed Checkpoint (DCP) avec les backends de stockage serverless_gpu.data.UCVolumeWriter et serverless_gpu.data.UCVolumeReader. Sauvegardez de manière asynchrone pour que l’entraînement continue pendant le téléversement du point de contrôle, et effectuez des points de contrôle suffisamment souvent pour limiter la perte de travail après une interruption. Comme un point de contrôle du modèle ne capture pas la position du pipeline de données, enregistrez également un point de contrôle de votre pipeline de données afin qu’une exécution redémarrée reprenne sur les bonnes données.

Pour le modèle complet de points de contrôle, voir Améliorer les performances et la résilience de l’entraînement dans AI Runtime.

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.