Partager via

Suivi et observabilité des expériences

Important

AI Runtime pour les tâches à nœud unique est disponible en préversion publique. L’API d’entraînement distribuée pour les charges de travail multi-GPU reste en version bêta.

Cet article explique comment utiliser MLflow, surveiller l’intégrité du GPU, afficher les journaux et gérer des points de contrôle de modèle sur AI Runtime.

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,
)

  • L’API GPU serverless lance automatiquement une expérience MLflow avec le nom /Users/{WORKSPACE_USER}/{get_notebook_name()}par défaut. Les utilisateurs peuvent le remplacer avec la variable MLFLOW_EXPERIMENT_NAMEd’environnement. Utilisez toujours des chemins absolus pour la variable d’environnement MLFLOW_EXPERIMENT_NAME :

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

  • Reprendre l'entraînement précédent en configurant le paramètre MLFLOW_RUN_ID de l'exécution antérieure :

    mlflow.start_run(run_id="<previous-run-id>")

  • Définissez le step paramètre dans MLFlowLogger à des nombres de lots raisonnables. MLflow possède une limite de 10 millions d'étapes métriques : la journalisation de chaque lot lors de grandes exécutions d’entraînement risque d'atteindre cette limite. Consultez l’article Limites des ressources.

Consultation des journaux

  • Sortie du bloc-notes — Les sorties et les erreurs standard de votre code d'entraînement s'affichent dans la sortie de la cellule du bloc-notes.
  • Journaux de pilote : accessible via le panneau de calcul pour le débogage des problèmes de démarrage, les problèmes de configuration de l’environnement et les erreurs d’exécution.
  • Journaux MLflow : les métriques d’apprentissage, les paramètres et les artefacts sont visibles dans l’interface utilisateur de l’expérience MLflow.

Point de contrôle de modèle

Enregistrez des points de contrôle de modèle dans des volumes de catalogue Unity, qui fournissent la même gouvernance que d’autres objets de catalogue Unity. Utilisez le format de chemin suivant pour référencer des fichiers dans des volumes à partir d’un notebook Databricks :

/Volumes/<catalog>/<schema>/<volume>/<path>/<file-name>

Enregistrez les points de contrôle dans les volumes de la même façon que vous les enregistrez dans le stockage local.

L’exemple ci-dessous montre comment écrire un point de contrôle PyTorch dans des volumes de catalogue Unity :

import torch

checkpoint = {
    "epoch": epoch,  # last finished epoch
    "model_state_dict": model.state_dict(),  # weights & buffers
    "optimizer_state_dict": optimizer.state_dict(),  # optimizer state
    "loss": loss,  # optional current loss
    "metrics": {"val_acc": val_acc},  # optional metrics
    # Add scheduler state, RNG state, and other metadata as needed.
}
checkpoint_path = "/Volumes/my_catalog/my_schema/model/checkpoints/ckpt-0001.pt"
torch.save(checkpoint, checkpoint_path)

Cette approche fonctionne également pour les points de contrôle distribués. L’exemple ci-dessous montre le point de contrôle de modèle distribué avec l’API Torch Distributed Checkpoint :

import torch.distributed.checkpoint as dcp

def save_checkpoint(self, checkpoint_path):
    state_dict = self.get_state_dict(model, optimizer)
    dcp.save(state_dict, checkpoint_id=checkpoint_path)

trainer.save_checkpoint("/Volumes/my_catalog/my_schema/model/checkpoints")

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 qui est en 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 Databricks

Consultez l’article Limites des ressources.

  • Last updated on