Compartilhar via

Acompanhamento e observabilidade de experimentos

Importante

O AI Runtime para tarefas de nó único está na Visualização Pública. A API de treinamento distribuído para cargas de trabalho de várias GPUs permanece em Beta.

Este artigo descreve como usar o MLflow, monitorar a integridade da GPU, exibir logs e gerenciar pontos de verificação de modelo no AI Runtime.

Integração com o MLflow

O AI Runtime integra-se nativamente ao MLflow para acompanhamento de experimentos, registro em log de modelos e visualização de métricas.

Recomendações de instalação:

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

  • Habilitar o registro automático para pyTorch Lightning:

    import mlflow
mlflow.pytorch.autolog()

  • Personalize o nome da execução do MLflow ao encapsular o código de treinamento do modelo dentro do escopo da API mlflow.start_run(). Isso fornece 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 parâmetro run_name em mlflow.start_run(run_name="your-custom-name") ou em bibliotecas de terceiros que dão suporte ao MLflow (por exemplo, Hugging Face Transformers). Caso contrário, o nome de execução padrão será 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 sem servidor inicia automaticamente um experimento do MLflow com o nome /Users/{WORKSPACE_USER}/{get_notebook_name()} padrão. Os usuários podem substituí-la com a variável de ambiente MLFLOW_EXPERIMENT_NAME. Sempre use caminhos absolutos para a variável de ambiente MLFLOW_EXPERIMENT_NAME.

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

  • Retome o treinamento anterior ajustando a configuração MLFLOW_RUN_ID da execução anterior.

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

  • Configure o parâmetro step em MLFlowLogger para números de lote razoáveis. O MLflow tem um limite de 10 milhões de etapas de métricas: o registro de cada lote em treinamentos em larga escala pode atingir esse limite. Confira Limites de recursos.

Exibindo logs

  • Saída do notebook — A saída padrão e os erros do código de treinamento aparecem na saída da célula do notebook.
  • Logs de driver – acessíveis por meio do painel de computação para depuração de problemas de inicialização, problemas de configuração de ambiente e erros de runtime.
  • Registros do MLflow — Métricas de treinamento, parâmetros e artefatos podem ser exibidos na interface de experimento do MLflow.

Ponto de verificação de modelo

Salve pontos de verificação de modelo em volumes do Catálogo do Unity, que fornecem a mesma governança que outros objetos do Catálogo do Unity. Use o seguinte formato de caminho para fazer referência a arquivos em volumes de um notebook do Databricks:

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

Salve pontos de verificação em volumes da mesma maneira que você os salva no armazenamento local.

O exemplo a seguir mostra como gravar um ponto de verificação do PyTorch em volumes do Catálogo do 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)

Essa abordagem também funciona para pontos de verificação distribuídos. O exemplo a seguir mostra o ponto de verificação de modelo distribuído com a API de Ponto de Verificação Distribuído da Tocha:

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 de vários usuários

  • Para garantir que todos os usuários possam acessar o código compartilhado (por exemplo, módulos auxiliares ou arquivos YAML do ambiente), armazene-os em /Workspace/Shared vez de pastas específicas do usuário, como /Workspace/Users/<your_email>/.
  • Para o código que está em desenvolvimento ativo, use diretórios Git em pastas específicas /Workspace/Users/<your_email>/ do usuário e faça push para repositórios Git remotos. Isso permite que vários usuários tenham um clone e branch específicos do usuário, enquanto ainda usam um repositório Git remoto para controle de versão. Consulte as práticas recomendadas para usar o Git no Databricks.
  • Os colaboradores podem compartilhar e comentar em blocos de anotações.

Limites globais no Databricks

Confira Limites de recursos.

  • Last updated on