Verfolgen und Beobachtbarkeit von Experimenten

AI-Runtime integriert sich nativ in MLflow zur Nachverfolgung von Experimenten und enthält einen integrierten GPU-Ressourcenbereich zur Überwachung der Auslastung, des Arbeitsspeichers und der Temperatur. Verwenden Sie MLflow, um Metriken und Ausführungen zu protokollieren, die Trainingsausgabe im Notebook und in der MLflow-Benutzeroberfläche anzuzeigen, Modell-Checkpoints in Volumes im Unity Catalog zu speichern und den GPU-Zustand zu überwachen, während Ihr Code ausgeführt wird.

MLflow-Integration

AI-Runtime integriert sich nativ in MLflow für die Experimentnachverfolgung, Modellprotokollierung und Metrikvisualisierung.

Setupempfehlungen:

• Aktualisieren Sie MLflow auf Version 3.7 oder höher, und folgen Sie den Deep Learning-Workflowmustern.

• Autologging für PyTorch Lightning aktivieren:

  import mlflow
  mlflow.pytorch.autolog()
  

• Passen Sie Ihren MLflow-Laufnamen an, indem Sie den Modellschulungscode innerhalb des mlflow.start_run() API-Bereichs einschließen. Dadurch können Sie den Namen der Ausführung steuern und einen Neustart aus einer vorherigen Ausführung ausführen. Sie können den Ausführungsnamen mithilfe des run_name Parameters in mlflow.start_run(run_name="your-custom-name") oder in Drittanbieterbibliotheken anpassen, die MLflow unterstützen (z. B. Hugging Face Transformers). Andernfalls lautet jobTaskRun-xxxxxder Standardlaufname .

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

• Bei Verwendung der Serverless GPU-API wird bei jedem Aufruf von .distributed() automatisch ein MLflow-Experimentlauf erstellt. Wenn dies innerhalb eines aktiven MLflow-Laufs aufgerufen wird, wird stattdessen ein verschachtelter Kindlauf unter dem aktiven Elternlauf erstellt.

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

• Um das verwendete .distributed()Experiment anzupassen, rufen Sie mlflow.set_experiment() vor dem Aufrufen .distributed()auf, oder legen Sie die MLFLOW_EXPERIMENT_NAME Umgebungsvariable fest. Der Standardname des Experiments lautet /Users/{WORKSPACE_USER}/{notebook-name}. Verwenden Sie immer absolute Pfade.

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

  Alternatively:

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

• Um eine vorherige MLflow-Ausführung fortzusetzen, verwenden Sie mlflow.start_run(run_id="<previous-run-id>").

• Um einen vorherigen MLflow-Lauf mit .distributed() wiederaufzunehmen, setzen Sie MLFLOW_RUN_ID, bevor Sie es aufrufen:

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

• Legen Sie den Parameter step in MLFlowLogger auf angemessene Batchnummern fest. MLflow hat eine Grenze von 10 Millionen Metrikschritten, sodass das Protokollieren aller einzelnen Batches bei großen Schulungsläufen diesen Grenzwert erreichen kann. Sie Ressourceneinschränkungen.

Anzeigen von Protokollen

• Notebook-Ausgabe: Standardausgabe und Fehler aus dem Trainingscode werden in der Ausgabe der Notebook-Zelle angezeigt.
• MLflow-Protokolle: Die Benutzeroberfläche des MLflow-Experiments zeigt Schulungsmetriken, Parameter und Artefakte an.

Modellprüfpunkterstellung

Für verteilte Schulungen speichern und laden Sie Modellprüfpunkte asynchron auf Unity-Katalogvolumes, die die gleiche Governance wie andere Unity Catalog-Objekte bereitstellen. Verwenden Sie UCVolumeWriter und UCVolumeReader aus dem Paket serverless_gpu.data mit der Torch Distributed Checkpoint (DCP)-API. Diese Speicher-Backends wickeln sämtliche E/A über ein schnelles lokales Verzeichnis ab (/tmp, das auf serverlosen GPU-Knoten NVMe-basiert ist), und laden Daten in das Unity Catalog-Volume hoch bzw. daraus herunter, was schneller ist, als Checkpoint-Shards direkt auf den FUSE-Mount zu schreiben. Metadaten-Unteilbarkeit wird beibehalten: Der Writer veröffentlicht die .metadata Datei erst, nachdem die Datenshards den Upload abgeschlossen haben.

Prüfpunkt reicht oft aus, um verlorene Arbeit nach einer Unterbrechung zu begrenzen, aber nicht so oft, dass der E/A-Aufwand die Schulung verlangsamt. Zielen Sie auf einen Prüfpunkt alle 30 Minuten auf eine Stunde und optimieren Sie das Intervall basierend auf Ihrer Schrittzeit und Prüfpunktgröße.

Um Prüfpunkte im Hintergrund hochzuladen, während das Training fortgesetzt wird, übergeben Sie ein UCVolumeWriter als storage_writer an dcp.async_save. Für asynchrones Speichern ist ein CPU-Backend für die Prozessgruppe erforderlich. Initialisieren Sie es also mit torch.distributed.init_process_group(backend="cpu:gloo,cuda:nccl", ...):

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

Lade einen Checkpoint mit UCVolumeReader:

from serverless_gpu.data import UCVolumeReader

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

Datenpipeline-Checkpointing

Ein Modell-Checkpoint erfasst den Zustand des Modells und des Optimierers, aber nicht die Position Ihrer Datenpipeline innerhalb des Datensatzes, sodass ein fortgesetzter Lauf nicht bis genau zu dem Sample vorspulen kann, bei dem er unterbrochen wurde. Berücksichtigen Sie dies bei der Wiederaufnahme: Starten Sie beim Neustart an einer Epochengrenze neu, oder verfolgen Sie verarbeitete Samples oder Shards in Ihrem eigenen Trainingszustand, damit Sie diese bei der Wiederaufnahme überspringen können.

Überwachen von GPU-Ressourcen

Verwenden Sie den GPU-Ressourcenbereich , um die GPU-Integrität und -Auslastung zu überwachen, während Ihr Code auf AI-Runtime ausgeführt wird. Der Bereich unterstützt Workloads mit einem einzelnen Knoten sowie mit mehreren Knoten.

Um den Seitenbereich zu öffnen, verbinden Sie Ihr Notebook mit der AI Runtime und klicken Sie dann im rechten Seitenbereich auf GPU-Ressourcen

Im Bereich werden die folgenden Metriken für jede GPU angezeigt:

• Prozentuale GPU-Auslastung
• GPU-Speicherauslastung
• Temperatur

Der Bereich ruft die Metriken alle 10 Sekunden ab und speichert bis zu 2 Stunden Verlauf. Klicken Sie auf Aktualisieren Sie , um die neuesten Werte sofort abzurufen. Nach 5 Minuten Inaktivität wird der Bereich pausiert; öffnen Sie ihn erneut, um die Überwachung fortzusetzen.

Zusammenarbeit mit mehreren Benutzern

• Um sicherzustellen, dass alle Benutzer auf freigegebenen Code zugreifen können (z. B. Hilfsmodule oder Umgebungs-YAML-Dateien), speichern Sie sie in /Workspace/Shared anstelle von benutzerspezifischen Ordnern wie /Workspace/Users/<your_email>/.
• Verwenden Sie für Code, der sich in der aktiven Entwicklung befindet, Git-Ordner in benutzerspezifischen Ordnern /Workspace/Users/<your_email>/ und pushen Sie zu Remote-Git-Repos. Auf diese Weise können mehrere Benutzer über einen benutzerspezifischen Klon und eine Verzweigung verfügen, während weiterhin ein Git-Remote-Repository für die Versionssteuerung verwendet wird. Schauen Sie sich bewährte Methoden für die Verwendung von Git auf Databricks an.
• Mitarbeiter können Notebooks freigeben und kommentieren .

Globale Grenzwerte in Azure Databricks

Sie Ressourceneinschränkungen.