Partilhar via

Rastreio e observabilidade de experimentos

Importante

O tempo de execução da IA para tarefas de nó único está em Pré-visualização Pública. A API de treino distribuída para cargas de trabalho multi-GPU permanece em Beta.

Este artigo descreve como usar o MLflow, monitorizar a saúde da GPU, visualizar registos e gerir checkpoints de modelo no tempo de execução da IA.

Integração MLflow

O AI Runtime integra-se nativamente com o MLflow para acompanhamento de experiências, registo de modelos e visualização de métricas.

Recomendações de configuração:

  • Atualize o MLflow para a versão 3.7 ou mais recente e siga os padrões de fluxo de trabalho de deep learning.

  • Ativar o autologging para o PyTorch Lightning:

    import mlflow
mlflow.pytorch.autolog()

  • Personalize seu nome de execução MLflow encapsulando seu código de treinamento de modelo dentro do escopo da mlflow.start_run() API. Isso lhe dá controle sobre o nome da execução e permite que você reinicie a partir de uma execução anterior. Você pode personalizar o nome da execução usando o run_name parâmetro em mlflow.start_run(run_name="your-custom-name") ou em bibliotecas de terceiros que suportam MLflow (por exemplo, Hugging Face Transformers). Caso contrário, o nome de execução padrão é jobTaskRun-xxxxx.

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

  • A API de GPU Serverless lança automaticamente um experimento MLflow com o nome /Users/{WORKSPACE_USER}/{get_notebook_name()}predefinido . Os utilizadores podem sobrescrevê-lo com a variável de ambiente MLFLOW_EXPERIMENT_NAME. Use sempre caminhos absolutos para a variável de ambiente MLFLOW_EXPERIMENT_NAME:

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

  • Retome o treino anterior definindo o MLFLOW_RUN_ID da corrida anterior:

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

  • Defina o parâmetro step em MLFlowLogger para números de lote razoáveis. O MLflow tem um limite de 10 milhões de passos métricos — registar cada lote durante grandes execuções de treino pode atingir esse limite. Consulte Limites de recursos.

Registos de visualização

  • Saída do caderno — A saída padrão e os erros do seu código de treino aparecem na saída da célula do caderno.
  • Registos de drivers — Acessíveis através do painel de computação para depurar problemas de arranque, problemas de configuração do ambiente e erros de execução.
  • Registos MLflow — Métricas de treino, parâmetros e artefactos podem ser vistos na interface do experimento MLflow.

Salvamento de ponto de verificação de modelos

Guardar pontos de verificação de modelo em volumes do Unity Catalog, que fornecem a mesma governação que outros Objetos do Unity Catalog. Use o seguinte formato de caminho para referenciar ficheiros em volumes a partir de um caderno Databricks:

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

Guarda os checkpoints nos volumes da mesma forma que os guardas no armazenamento local.

O exemplo abaixo mostra como escrever um checkpoint do PyTorch para volumes do Unity Catalog:

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)

Esta abordagem também funciona para pontos de controlo distribuídos. O exemplo abaixo mostra o checkpointing de modelos distribuídos com a 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")

Colaboração multiutilizador

  • Para garantir que todos os utilizadores possam aceder a código partilhado (por exemplo, módulos auxiliares ou ficheiros YAML do ambiente), armazene-os em /Workspace/Shared em vez de pastas específicas do utilizador como /Workspace/Users/<your_email>/.
  • Para código que está em desenvolvimento ativo, use pastas Git em pastas /Workspace/Users/<your_email>/ específicas do usuário e envie por push para repositórios Git remotos. Isto permite que vários utilizadores tenham um clone e uma ramificação específicos para cada um, enquanto continuam a usar um repositório Git remoto para controlo de versões. Consulte as práticas recomendadas para usar o Git no Databricks.
  • Os colaboradores podem partilhar e comentar em blocos de notas.

Limites globais no Databricks

Consulte Limites de recursos.

  • Last updated on