Suivi des Experimentation et observabilité

info

Aperçu

Cette fonctionnalité est en aperçu public.

Le Runtime IA s'intègre en mode natif avec MLflow pour le suivi des expérimentations et comprend un volet des Ressources GPU intégré pour le monitoring de l'utilisation, de la mémoire et de la température. Utilisez MLflow pour log les métriques et les exécutions, afficher la sortie d'entraînement dans le Notebook et l'interface utilisateur MLflow, enregistrer les points de contrôle du modèle dans les volumes Unity Catalog et suivre l'état du GPU pendant l'exécution de votre code.

Intégration MLflow

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

Recommandations de configuration :

• Passez à MLflow version 3,7 ou une version ultérieure et suivez les modèles de flux de travail d'apprentissage profond.

• Activer le log automatique pour PyTorch Lightning :

  Python

  import mlflow
  mlflow.pytorch.autolog()

• Personnalisez le nom de votre exécution MLflow en encapsulant votre code d'entraînement de modèle dans la portée de l'API mlflow.start_run(). Ceci vous donne le contrôle sur le nom d'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 parameter run_name 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). Autrement, le nom d'exécution par default est jobTaskRun-xxxxx.

  Python

  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 Serverless GPU, chaque appel à .distributed() crée automatiquement une exécution d'expérience MLflow. Si elle est appelée au sein d'une exécution MLflow active, une exécution enfant imbriquée est créée sous le parent actif à la place.

  Python

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

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

  Python

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

  Alternativement :

  Python

  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 :

  Python

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

• Définissez le step paramètre dans MLFlowLogger à des nombres de batch raisonnables. MLflow a une limite de 10 millions d'étapes de métrique, de sorte que l'enregistrement de chaque batch sur de grandes exécutions d'entraînement peut atteindre cette limite. Voir les limites de ressources.

Consultation des logs

• **Sortie du Notebook** : la sortie standard et les erreurs de votre code d'entraînement apparaissent dans la sortie de la cellule du Notebook.
• Logs MLflow : L'interface utilisateur de l'expérience MLflow affiche les métriques d'entraînement, les paramètres et les artefacts.

Création de points de contrôle de modèle

Pour l'entraînement distribué, enregistrez et chargez les points de contrôle du modèle de manière asynchrone vers les volumes Unity Catalog, qui offrent la même gouvernance que les autres objets Unity Catalog. Utilisez UCVolumeWriter et UCVolumeReader du package serverless_gpu.data avec l’API Torch Distributed Checkpoint (DCP). Ces backends de stockage mettent en scène toutes les E/S via un répertoire local rapide (/tmp, qui est sauvegardé par NVMe sur les nœuds GPU serverless) et upload vers ou download depuis le volume Unity Catalog, ce qui est plus rapide que d’écrire les fragments de checkpoint directement sur le montage FUSE. L’atomicité des métadonnées est préservée : l’auteur ne publie le fichier .metadata qu’une fois que ses fragments de données ont terminé leur upload.

remarque

UCVolumeWriter, UCVolumeReader et UCVolumeDataset nécessitent un environnement GPU 5 ou supérieur (Serverless GPU Python API 0.5.16+).

Effectuer des points de contrôle assez souvent pour limiter la perte de travail après une interruption, mais pas trop souvent pour que les frais généraux d'E/S ne ralentissent pas la formation. Visez un point de contrôle toutes les 30 minutes à une heure, et ajustez l'intervalle en fonction de votre temps d'étape et de la taille du point de contrôle.

Pour upload des points de contrôle en arrière-plan pendant que l’entraînement se poursuit, passez un UCVolumeWriter comme storage_writer à dcp.async_save. Les sauvegardes asynchrones nécessitent un backend CPU sur le groupe de processus, initialisez-le donc avec torch.distributed.init_process_group(backend="cpu:gloo,cuda:nccl", ...):

Python

import torch.distributed.checkpoint as dcp
from serverless_gpu.data import UCVolumeWriter

checkpoint_path = "/Volumes/my_catalog/my_schema/model/checkpoints"
writer = UCVolumeWriter(checkpoint_path)

future = dcp.async_save(state_dict, storage_writer=writer)
# ...continue training...
future.result()  # blocks until the upload lands on the UC volume

Charger un point de contrôle avec UCVolumeReader:

Python

from serverless_gpu.data import UCVolumeReader

reader = UCVolumeReader(checkpoint_path)
dcp.load(state_dict, storage_reader=reader)

Points de contrôle de pipeline de données

Un point de contrôle de modèle capture l'état du modèle et de l'optimiseur, mais pas la position de votre pipeline de données dans le dataset, de sorte qu'une exécution reprise ne peut pas avancer rapidement vers l'échantillon exact où elle s'est arrêtée. Tenez-en compte dans la manière dont vous reprenez : redémarrez à partir d'une limite d'époque, ou suivez les échantillons ou les fragments traités dans votre propre état d'entraînement afin de pouvoir les ignorer lors de la reprise.

Surveiller les ressources GPU

Utilisez le volet **Ressources GPU** pour surveiller la santé et l'utilisation du GPU pendant l'exécution de votre code sur AI Runtime. Le volet prend en charge les charges de travail à nœud unique et multi-nœuds.

Pour ouvrir le volet, connectez votre Notebook à 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 Refresh pour récupérer immédiatement les dernières valeurs. Après 5 minutes d'inactivité, le volet se met en pause ; rouvrez-le pour reprendre le monitoring.

Collaboration multi-utilisateur

• Pour que tous les utilisateurs puissent accéder au code partagé (par exemple, les modules d’assistance ou les fichiers YAML d’environnement), stockez-les dans /Workspace/Shared au lieu de dossiers spécifiques à l’utilisateur comme /Workspace/Users/<your_email>/.
• Pour le code en cours de développement, utilisez les dossiers Git dans les dossiers spécifiques à l'utilisateur /Workspace/Users/<your_email>/ et poussez vers les référentiels Git distants. Ceci permet à plusieurs utilisateurs d'avoir un clone et une branch spécifiques à l'utilisateur, tout en utilisant un référentiel Git distant pour le contrôle de version. Consultez les bonnes pratiques pour l'utilisation de Git sur Databricks.
• Les collaborateurs peuvent partager et commenter des Notebooks.

Limites globales dans Databricks

Consultez les Limites des ressources.