Aanbevolen procedures voor serverloze GPU-rekenkracht

In dit artikel vindt u aanbevelingen voor aanbevolen procedures voor het gebruik van serverloze GPU-rekenkracht in uw notebooks en taken.

Door deze aanbevelingen te volgen, verbetert u de productiviteit, kostenefficiëntie en betrouwbaarheid van uw workloads in Azure Databricks.

De juiste rekenkracht gebruiken

• Serverloze GPU-rekenkracht gebruiken. Deze optie wordt geleverd met torch, cuda en torchvision, geoptimaliseerd voor compatibiliteit. Exacte pakketversies zijn afhankelijk van de omgevingsversies.
• Selecteer uw accelerator in het zijpaneel.
  • Gebruik voor externe gedistribueerde trainingsworkloads een A10 GPU. Dit is de client om later een taak naar de externe H100 te verzenden.
  • Voor het uitvoeren van grote interactieve taken op het notebook zelf kunt u uw notebook koppelen aan H100, wat 1 knooppunt (8 H100 GPU's) in beslag neemt.
• Om het gebruik van GPU's te voorkomen, kunt u uw notebook koppelen aan een CPU-cluster voor sommige bewerkingen zoals git-kloon en het converteren van Spark DataFrame naar DE MDS-indeling (Mosaic Data Shard).

Aanbevelingen voor MLflow

Gebruik MLflow 3 op Databricks voor een optimale ML-ontwikkelingscyclus. Volg deze tips:

• Werk de MLflow van uw omgeving bij naar versie 3.6 of hoger en volg de MLflow Deep Learning-stroom in de MLflow 3 Deep Learning-werkstroom.

• Stel de step parameter in MLFlowLogger op een redelijk aantal batches. MLflow heeft een limiet van 10 miljoen metrische stappen die kunnen worden vastgelegd. Zie Resourcelimieten.

• Schakel mlflow.pytorch.autolog() in wanneer Pytorch Lightning als trainer wordt gebruikt.

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

• Met de serverloze GPU-API wordt een MLflow-experiment gestart om metrische systeemgegevens te registreren. Standaard wordt de naam /Users/{WORKSPACE_USER}/{get_notebook_name()} gebruikt, tenzij de gebruiker deze overschrijft met de omgevingsvariabele MLFLOW_EXPERIMENT_NAME.

  • Wanneer u de MLFLOW_EXPERIMENT_NAME omgevingsvariabele instelt, gebruikt u een absoluut pad. Bijvoorbeeld/Users/<username>/my-experiment.
  • De naam van het experiment mag niet de naam van de bestaande map bevatten. Als dit bijvoorbeeld my-experiment een bestaande map is, wordt in het bovenstaande voorbeeld een foutmelding weergegeven.

  import os
  from serverless_gpu import distributed
  os.environ['MLFLOW_EXPERIMENT_NAME'] = '/Users/{WORKSPACE_USER}/my_experiment'
  @distributed(gpus=num_gpus, gpu_type=gpu_type, remote=True)
  def run_train():
  # my training code
  

• Als u de training van een vorige uitvoering wilt hervatten, geeft u de MLFLOW_RUN_ID van de vorige uitvoering als volgt op.

  import os
  os.environ[‘MLFLOW_RUN_ID’] = <previous_run_id>
  run_train.distributed()
  

Modelcontrolepunt

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 benadering werkt ook voor gedistribueerde controlepunten van meerdere knooppunten. 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, environment.yaml), maakt u git-mappen in /Workspace/Repos of /Workspace/Shared in 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, maar 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.