Rilevamento e osservabilità dell'esperimento

Il runtime di intelligenza artificiale si integra in modo nativo con MLflow per il rilevamento degli esperimenti e include un riquadro delle risorse GPU predefinito per il monitoraggio dell'utilizzo, della memoria e della temperatura. Usa MLflow per registrare metriche e run, visualizzare l'output dell'addestramento nel notebook e nell'interfaccia utente di MLflow, salvare i checkpoint del modello nei volumi di Unity Catalog e monitorare lo stato della GPU durante l'esecuzione del codice.

Integrazione di MLflow

Il runtime di intelligenza artificiale si integra in modo nativo con MLflow per il rilevamento dell'esperimento, la registrazione dei modelli e la visualizzazione delle metriche.

Consigli per la configurazione:

• Aggiornare MLflow alla versione 3.7 o successiva e seguire i modelli del flusso di lavoro di Deep Learning.

• Abilitare la registrazione automatica per PyTorch Lightning.

  import mlflow
  mlflow.pytorch.autolog()
  

• Personalizzate il nome dell'esecuzione in MLflow incapsulando il vostro codice di addestramento del modello nel contesto API mlflow.start_run(). In questo modo è possibile controllare il nome dell'esecuzione e consentire il riavvio da un'esecuzione precedente. È possibile personalizzare il nome dell'esecuzione usando il run_name parametro in o nelle mlflow.start_run(run_name="your-custom-name") librerie di terze parti che supportano MLflow (ad esempio Hugging Face Transformers). In caso contrario, il nome di esecuzione predefinito è jobTaskRun-xxxxx.

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

• Quando si usa l'API GPU serverless, ogni chiamata a .distributed() crea automaticamente un esperimento MLflow. Se viene chiamato all'interno di un'esecuzione MLflow attiva, viene invece creata un'esecuzione figlia annidata sotto l'esecuzione padre attiva.

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

• Per personalizzare l'esperimento utilizzato da .distributed(), chiamare mlflow.set_experiment() prima di richiamare .distributed(), oppure impostare la variabile di ambiente MLFLOW_EXPERIMENT_NAME. Il nome predefinito dell'esperimento è /Users/{WORKSPACE_USER}/{notebook-name}. Usare sempre percorsi assoluti.

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

  Alternatively:

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

• Per riprendere un'esecuzione precedente di MLflow, usare mlflow.start_run(run_id="<previous-run-id>").

• Per riprendere un'esecuzione precedente di MLflow con .distributed(), impostare MLFLOW_RUN_ID prima di chiamarla:

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

• Impostare il parametro step in MLFlowLogger a valori ragionevoli di batch. MLflow ha un limite di 10 milioni di passaggi delle metriche, quindi la registrazione di ogni singolo batch in esecuzioni di training di grandi dimensioni può raggiungere questo limite. Vedere Limiti delle risorse.

Visualizzazione dei log

• Output del notebook: l'output standard e gli errori del codice di training vengono visualizzati nell'output della cella del notebook.
• Log di MLflow: l'interfaccia utente dell'esperimento MLflow visualizza metriche, parametri e artefatti di training.

Il checkpoint del modello

Per il training distribuito, salva e carica i checkpoint del modello in modo asincrono nei volumi di Unity Catalog, che offrono lo stesso livello di governance degli altri oggetti di Unity Catalog. Usare UCVolumeWriter e UCVolumeReader del pacchetto serverless_gpu.data con l'API Torch Distributed Checkpoint (DCP). Questi back-end di archiviazione fanno transitare tutte le operazioni di I/O attraverso una directory locale veloce (/tmp, basata su NVMe nei nodi GPU serverless) e caricano i dati nel volume di Unity Catalog o li scaricano da esso, operazione più veloce rispetto alla scrittura diretta dei frammenti di checkpoint nel mount FUSE. L'atomicità dei metadati viene mantenuta: il writer pubblica il .metadata file solo dopo il completamento del caricamento delle partizioni di dati.

Crea checkpoint abbastanza spesso da limitare la perdita di lavoro dopo un'interruzione, ma non così spesso da rallentare l'addestramento a causa del sovraccarico di I/O. Mirare a un checkpoint ogni 30 minuti a un'ora e ottimizzare l'intervallo in base al tempo di passaggio e alle dimensioni del checkpoint.

Per caricare i checkpoint in background mentre l'addestramento continua, passa UCVolumeWriter come storage_writer a dcp.async_save. I salvataggi asincroni richiedono un back-end della CPU nel gruppo di processi, quindi inizializzarlo con 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

Carica un checkpoint con UCVolumeReader:

from serverless_gpu.data import UCVolumeReader

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

Salvataggio dei checkpoint della pipeline di dati

Un checkpoint di un modello acquisisce lo stato del modello e dell'ottimizzatore, ma non la posizione della pipeline dei dati all'interno del dataset, quindi l'esecuzione ripresa non può avanzare rapidamente fino al campione esatto in cui si era interrotta. Tenere conto di questo nel modo in cui si riprende l'addestramento: riavviare dal confine di un'epoca oppure tenere traccia dei campioni o degli shard già elaborati nel proprio stato di addestramento, in modo da poterli saltare alla ripresa.

Monitorare le risorse GPU

Usare il riquadro Risorse GPU per monitorare l'integrità e l'utilizzo della GPU mentre il codice viene eseguito in Runtime di intelligenza artificiale. Il riquadro supporta sia carichi di lavoro a nodo singolo che a più nodi.

Per aprire il riquadro, connettere il notebook al runtime di intelligenza artificiale e quindi fare clic Risorse GPU nel riquadro a destra.

Nel riquadro vengono visualizzate le metriche seguenti per ogni GPU:

• Percentuale di utilizzo GPU
• Utilizzo della memoria GPU
• Temperatura

Il riquadro interroga le metriche ogni 10 secondi e conserva fino a 2 ore di cronologia. Fare clic Aggiornare per recuperare immediatamente i valori più recenti. Dopo 5 minuti di inattività, il riquadro viene sospeso; riaprirlo per riprendere il monitoraggio.

Collaborazione multiutente

• Per garantire che tutti gli utenti possano accedere al codice condiviso (ad esempio, moduli helper o file YAML dell'ambiente), archivialo in /Workspace/Shared invece che in cartelle specifiche dell'utente come /Workspace/Users/<your_email>/.
• Per il codice in fase di sviluppo attivo, usare le cartelle Git nelle cartelle /Workspace/Users/<your_email>/ specifiche dell'utente e eseguire il push nei repository Git remoti. Ciò consente a più utenti di avere un clone e un ramo specifici dell'utente, pur usando un repository Git remoto per il controllo della versione. Vedere le procedure consigliate per l'uso di Git in Databricks.
• I collaboratori possono condividere e commentare i notebook.

Limiti globali in Azure Databricks

Vedere Limiti delle risorse.