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.

AI Runtime kan systeemeigen worden geïntegreerd met MLflow voor het bijhouden van experimenten en bevat een ingebouwd deelvenster GPU-resources voor het bewaken van het gebruik, het geheugen en de temperatuur. Gebruik MLflow om metrische gegevens en uitvoeringen te registreren, trainingsuitvoer in het notebook en de MLflow-gebruikersinterface weer te geven, modelcontrolepunten op te slaan in Unity Catalog-volumes en GPU-status bij te houden terwijl uw code wordt uitgevoerd.

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,
    )
    
  • Wanneer u de Serverless GPU-API gebruikt, wordt bij elke aanroep van .distributed() automatisch een MLflow-experimentrun gemaakt. Als dit wordt aangeroepen binnen een actieve MLflow-run, wordt in plaats daarvan een geneste child run gemaakt onder de actieve parent run.

    import mlflow
    
    with mlflow.start_run() as outer_run:
        ...
        run_train.distributed()  # creates a nested child run under outer_run
    
  • Als u het experiment wilt aanpassen dat door .distributed() wordt gebruikt, roept u mlflow.set_experiment() aan voordat u .distributed() aanroept, of stelt u de omgevingsvariabele MLFLOW_EXPERIMENT_NAME in. De standaardnaam van het experiment is /Users/{WORKSPACE_USER}/{notebook-name}. Gebruik altijd absolute paden.

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

    Alternatively:

    import os
    os.environ["MLFLOW_EXPERIMENT_NAME"] = "/Users/<username>/my-experiment"
    
  • Als u een vorige MLflow-uitvoering wilt hervatten, gebruikt u mlflow.start_run(run_id="<previous-run-id>").

  • Als u een eerdere MLflow-uitvoering wilt hervatten met .distributed(), stelt u MLFLOW_RUN_ID in voordat u deze aanroept:

    os.environ["MLFLOW_RUN_ID"] = "<previous-run-id>"
    run_train.distributed()
    
  • Stel de step parameter in MLFlowLogger in op een redelijk aantal batches. MLflow heeft een limiet van 10 miljoen metriekstappen, dus het loggen van elke afzonderlijke batch tijdens grote trainingsruns kan ertoe leiden dat deze limiet wordt bereikt. Zie Resourcelimieten.

Logboeken weergeven

  • Notebookuitvoer: Standaarduitvoer en fouten uit uw trainingscode worden weergegeven in de uitvoer van de notebookcel.
  • MLflow-logboeken: in de ui van het MLflow-experiment worden metrische trainingsgegevens, parameters en artefacten weergegeven.

Modelcontrolepunten

Voor gedistribueerde training slaat u asynchroon controlepunten voor modellen op en laadt u ze in Unity Catalog-volumes, die dezelfde governance bieden als andere Unity Catalog-objecten. Gebruik UCVolumeWriter en UCVolumeReader uit het serverless_gpu.data pakket met de DCP-API ( Torch Distributed CheckPoint ). Deze back-ends van opslag faseren alle I/O via een snelle lokale map (/tmpmet NVMe-ondersteuning op serverloze GPU-knooppunten) en uploaden naar of downloaden van het Unity Catalog-volume, wat sneller is dan het rechtstreeks schrijven van controlepunt-shards naar de FUSE-koppeling. Atomiciteit van metagegevens blijft behouden: de schrijver publiceert het .metadata bestand pas nadat de gegevensshards zijn geüpload.

Opmerking

UCVolumeWriter, UCVolumeReaderen UCVolumeDataset vereist GPU-omgeving 5 of hoger (serverloze GPU Python API 0.5.16+).

Controlepunt is vaak genoeg om verloren werk na een onderbreking te beperken, maar niet zo vaak dat de I/O-overhead de training vertraagt. Streef ernaar elke 30 minuten tot een uur één controlepunt in te plannen, en stem het interval af op basis van je stapduur en de omvang van het controlepunt.

Als u controlepunten op de achtergrond wilt uploaden terwijl de training doorgaat, geeft u een UCVolumeWriter door als aan storage_writerdcp.async_save. Asynchrone opslagbewerkingen vereisen een CPU-backend in de procesgroep, dus initialiseer deze met 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

Een controlepunt laden met UCVolumeReader:

from serverless_gpu.data import UCVolumeReader

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

Controlepunten voor gegevenspijplijnen

Een modelcontrolepunt legt model- en optimalisatiestatus vast, maar niet de positie van uw gegevenspijplijn in de gegevensset, dus een hervate uitvoering kan niet snel worden doorgestuurd naar het exacte voorbeeld waar deze is gestopt. Houd hier rekening mee in hoe u verder gaat: opnieuw opstarten vanaf een tijdsgrens, of verwerkte voorbeelden of shards bijhouden in uw eigen trainingsstatus, zodat u ze kunt overslaan bij hervatten.

GPU-resources bewaken

Gebruik het deelvenster GPU-resources om de GPU-status en -gebruik te bewaken terwijl uw code wordt uitgevoerd op AI Runtime. Het deelvenster biedt ondersteuning voor workloads met één knooppunt en meerdere knooppunten.

Als u het deelvenster wilt openen, verbindt u uw notebook met AI Runtime en klikt u vervolgens op chippictogram.GPU-resources in het rechterdeelvenster.

Deelvenster GPU-resources met metrische gegevens over gebruik, geheugen en temperatuur voor elke GPU.

In het deelvenster worden de volgende metrische gegevens weergegeven voor elke GPU:

  • GPU-gebruikpercentage
  • GPU-geheugengebruik
  • Temperatuur

Het deelvenster haalt elke 10 seconden metriekgegevens op en bewaart een geschiedenis van maximaal 2 uur. Klik op het pictogram Vernieuwen.Vernieuwen om de meest recente waarden onmiddellijk op te halen. Na 5 minuten zonder activiteit wordt het deelvenster gepauzeerd; open het opnieuw om de controle te hervatten.

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 Azure Databricks

Zie Resourcelimieten.