Experimenten bijhouden en waarneembaarheid

Belangrijk

AI Runtime voor taken met één knooppunt bevindt zich in openbare preview. De gedistribueerde trainings-API voor workloads met meerdere GPU's blijft bèta.

In dit artikel wordt beschreven hoe u MLflow gebruikt, de GPU-status bewaakt, logboeken bekijkt en modelcontrolepunten beheert in AI Runtime.

MLflow-integratie

AI Runtime kan systeemeigen worden geïntegreerd met MLflow voor het bijhouden van experimenten, modelregistratie en visualisatie van metrische gegevens.

Aanbevelingen voor installatie:

• Werk MLflow bij naar versie 3.7 of hoger en volg de deep learning-werkstroompatronen.

• Automatische logboeken inschakelen voor PyTorch Lightning:

  import mlflow
  mlflow.pytorch.autolog()
  

• Pas de naam van de MLflow-uitvoering aan door uw modeltrainingscode binnen het mlflow.start_run() API-bereik in te kapselen. Hiermee hebt u controle over de naam van de uitvoering en kunt u opnieuw opstarten vanaf een vorige uitvoering. U kunt de uitvoeringsnaam aanpassen met behulp van de run_name parameter in mlflow.start_run(run_name="your-custom-name") of in bibliotheken van derden die MLflow ondersteunen (bijvoorbeeld Hugging Face Transformers). Anders is jobTaskRun-xxxxxde standaarduitvoeringsnaam.

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

• De Serverloze GPU-API start automatisch een MLflow-experiment met de standaardnaam /Users/{WORKSPACE_USER}/{get_notebook_name()}. Gebruikers kunnen deze overschrijven met de omgevingsvariabele MLFLOW_EXPERIMENT_NAME. Gebruik altijd absolute paden voor de MLFLOW_EXPERIMENT_NAME omgevingsvariabele:

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

• Hervat de vorige training door het instellen van de MLFLOW_RUN_ID van de eerdere uitvoering.

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

• Stel de step parameter in MLFlowLogger in op een redelijk aantal batches. MLflow heeft een limiet van 10 miljoen metrische stappen: het vastleggen van elke batch in grote trainingsuitvoeringen kan deze limiet bereiken. Zie Resourcelimieten.

Logboeken weergeven

• Notebookuitvoer : standaarduitvoer en fouten uit uw trainingscode worden weergegeven in de uitvoer van de notebookcel.
• Stuurprogrammalogboeken : toegankelijk via het rekenpaneel voor opstartproblemen, problemen met de omgevingsinstellingen en runtimefouten.
• MLflow-logboeken : trainingsgegevens, parameters en artefacten kunnen worden weergegeven in de gebruikersinterface van het MLflow-experiment.

Modelcontrolepunten

Sla modelcontrolepunten op in Unity Catalog-volumes, die dezelfde governance bieden als andere Unity Catalog-objecten. Gebruik de volgende padindeling om te verwijzen naar bestanden in volumes vanuit een Databricks-notebook:

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

Sla controlepunten op dezelfde manier op als u ze opslaat in lokale opslag.

In het onderstaande voorbeeld ziet u hoe u een PyTorch-controlepunt schrijft naar Unity Catalog-volumes:

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)

Deze aanpak werkt ook voor gedistribueerde controlepunten. In het onderstaande voorbeeld ziet u controlepunten voor gedistribueerde modellen met de Torch Distributed Checkpoint-API:

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

Samenwerking tussen meerdere gebruikers

• Om ervoor te zorgen dat alle gebruikers toegang hebben tot gedeelde code (bijvoorbeeld helpermodules of YAML-bestanden in de omgeving), slaat u ze op in /Workspace/Shared plaats van gebruikersspecifieke mappen, zoals /Workspace/Users/<your_email>/.
• Voor code die actief is ontwikkeld, gebruikt u Git-mappen in gebruikersspecifieke mappen /Workspace/Users/<your_email>/ en pusht u naar externe Git-opslagplaatsen. Hierdoor kunnen meerdere gebruikers een gebruikersspecifieke kloon en vertakking hebben, terwijl ze nog steeds een externe Git-opslagplaats gebruiken voor versiebeheer. Bekijk de aanbevolen procedures voor het gebruik van Git op Databricks.
• Samenwerkers kunnen notitieblokken delen en er opmerkingen bij plaatsen .

Globale limieten in Databricks

Zie Resourcelimieten.