Suivi des Experimentation et observabilité
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 :
Pythonimport 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 parameterrun_namedansmlflow.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 estjobTaskRun-xxxxx.Pythonfrom 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.Pythonimport 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(), appelezmlflow.set_experiment()avant d'invoquer.distributed(), ou définissez la variable d'environnementMLFLOW_EXPERIMENT_NAME. Le nom de l'Experiment default est/Users/{WORKSPACE_USER}/{notebook-name}. Utilisez toujours des chemins absolus.Pythonimport mlflow
mlflow.set_experiment("/Users/<username>/my-experiment")
run_train.distributed()Alternativement :
Pythonimport 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éfinissezMLFLOW_RUN_IDavant de l'appeler :Pythonos.environ["MLFLOW_RUN_ID"] = "<previous-run-id>"
run_train.distributed() -
Définissez le
stepparamètre dansMLFlowLoggerà 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 l’état du modèle et de l’optimiseur dans des volumes Unity Catalog à l’aide de l’API Torch Distributed Checkpoint (DCP) avec les backends de stockage serverless_gpu.data.UCVolumeWriter et serverless_gpu.data.UCVolumeReader. Enregistrez de manière asynchrone afin que l’entraînement se poursuive pendant l’upload du point de contrôle, et créez des points de contrôle assez souvent pour limiter la perte de travail après une interruption. Comme un point de contrôle de modèle ne capture pas la position du pipeline de données, créez également un point de contrôle pour votre pipeline de données afin qu’une exécution reprise se poursuive sur les données correctes.
Pour le modèle complet de points de contrôle, consultez Améliorer les performances et la résilience de l’entraînement sur AI Runtime.
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/Sharedau 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.