Rilevamento e osservabilità dell'esperimento

Importante

Il runtime di intelligenza artificiale per le attività a nodo singolo è disponibile in anteprima pubblica. L'API di training distribuita per i carichi di lavoro con più GPU rimane in beta.

Questo articolo descrive come usare MLflow, monitorare l'integrità della GPU, visualizzare i log e gestire i checkpoint del modello in runtime di intelligenza artificiale.

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

• L'API GPU serverless avvia automaticamente un esperimento MLflow con il nome /Users/{WORKSPACE_USER}/{get_notebook_name()}predefinito . Gli utenti possono sovrascriverlo con la variabile MLFLOW_EXPERIMENT_NAMEdi ambiente . Usare sempre percorsi assoluti per la variabile di MLFLOW_EXPERIMENT_NAME ambiente:

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

• Riprendere il training precedente impostando il parametro MLFLOW_RUN_ID dai dati dell'esecuzione precedente.

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

• Impostare il parametro step in MLFlowLogger a valori ragionevoli di batch. MLflow ha un limite di 10 milioni di passaggi delle metriche. La registrazione di ogni singolo batch in esecuzione di allenamenti di grandi dimensioni può portare a 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 dei driver : accessibile tramite il pannello di calcolo per il debug di problemi di avvio, problemi di installazione dell'ambiente ed errori di runtime.
• Log di MLflow : le metriche di training, i parametri e gli artefatti sono visualizzabili nell'interfaccia utente dell'esperimento MLflow.

Il checkpoint del modello

Salvare i checkpoint del modello nei volumi di Unity Catalog, che offrono la stessa governance degli altri oggetti di Unity Catalog. Usare il formato di percorso seguente per fare riferimento ai file nei volumi da un notebook di Databricks:

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

Salva i checkpoint sui volumi nello stesso modo in cui li salvi nella memoria locale.

L'esempio seguente illustra come scrivere un checkpoint PyTorch nei volumi del catalogo Unity:

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)

Questo approccio funziona anche per i checkpoint distribuiti. L'esempio seguente mostra il checkpoint del modello distribuito con l'API Torch Distributed Checkpoint:

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

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 Databricks

Vedere Limiti delle risorse.