Acompanhamento e observabilidade de experimentos

Importante

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

O AI Runtime integra-se nativamente ao MLflow para acompanhamento de experimentos e inclui um painel interno de recursos de GPU para monitorar a utilização, a memória e a temperatura. Use o MLflow para registrar métricas e execuções, exibir a saída de treinamento no notebook e a interface do usuário do MLflow, salvar pontos de verificação de modelo em volumes do Catálogo do Unity e acompanhar a integridade da GPU enquanto o código é executado.

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,
    )
    
  • Ao usar a API de GPU sem servidor, cada chamada a .distributed() cria automaticamente uma execução de experimento no MLflow. Se for chamado dentro de uma execução ativa do MLflow, uma execução filha aninhada será criada sob a execução pai ativa em vez disso.

    import mlflow
    
    with mlflow.start_run() as outer_run:
        ...
        run_train.distributed()  # creates a nested child run under outer_run
    
  • Para personalizar o experimento usado por .distributed(), chame mlflow.set_experiment() antes de invocar .distributed()ou defina a variável de MLFLOW_EXPERIMENT_NAME ambiente. O nome do experimento padrão é /Users/{WORKSPACE_USER}/{notebook-name}. Sempre use caminhos absolutos.

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

    Alternatively:

    import os
    os.environ["MLFLOW_EXPERIMENT_NAME"] = "/Users/<username>/my-experiment"
    
  • Para retomar uma execução anterior do MLflow, use mlflow.start_run(run_id="<previous-run-id>").

  • Para retomar uma execução anterior do MLflow com .distributed(), defina MLFLOW_RUN_ID antes de chamá-la:

    os.environ["MLFLOW_RUN_ID"] = "<previous-run-id>"
    run_train.distributed()
    
  • Configure o parâmetro step em MLFlowLogger para números de lote razoáveis. O MLflow tem um limite de 10 milhões de passos de métricas, portanto, registrar todos os lotes em execuções de treinamento extensas pode fazer com que esse limite seja atingido. Confira Limites de recursos.

Exibindo logs

  • Saída do notebook: a saída padrão e os erros do seu código de treinamento são exibidos na saída da célula do notebook.
  • Logs do MLflow: A interface de usuário do experimento do MLflow exibe métricas de treinamento, parâmetros e artefatos.

Ponto de verificação de modelo

Para treinamento distribuído, salve e carregue pontos de verificação de modelo de forma assíncrona nos volumes do Catálogo do Unity, que fornecem a mesma governança que outros objetos do Catálogo do Unity. Use UCVolumeWriter e UCVolumeReader do pacote serverless_gpu.data com a API Torch Distributed Checkpoint (DCP). Esses back-ends de armazenamento preparam todas as E/Ss por meio de um diretório local rápido (/tmp, que é apoiado por NVMe em nós de GPU sem servidor) e são carregados ou baixados no volume do Unity Catalog, que é mais rápido do que gravar fragmentos de ponto de verificação diretamente na montagem do FUSE. A atomicidade dos metadados é preservada: o gravador publica o arquivo .metadata somente depois que seus fragmentos de dados terminam de ser enviados.

Observação

UCVolumeWriter, UCVolumeReader e UCVolumeDataset exigem ambiente de GPU 5 ou superior (API Python Serverless GPU 0.5.16+).

Defina pontos de verificação com frequência suficiente para limitar o trabalho perdido após uma interrupção, mas não com tanta frequência a ponto de a sobrecarga de E/S deixar o treinamento mais lento. Aponte para um ponto de verificação a cada 30 minutos a uma hora e ajuste o intervalo com base no tempo da etapa e no tamanho do ponto de verificação.

Para carregar pontos de verificação em segundo plano enquanto o treinamento continua, passe um UCVolumeWriter como o storage_writer para dcp.async_save. Os salvamentos assíncronos exigem um backend de CPU para o grupo de processos; portanto, inicialize-o com 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

Carregue um ponto de verificação com UCVolumeReader:

from serverless_gpu.data import UCVolumeReader

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

Ponto de verificação do pipeline de dados

Um ponto de verificação de modelo captura o modelo e o estado do otimizador, mas não a posição do pipeline de dados dentro do conjunto de dados, portanto, uma execução retomada não pode avançar rapidamente para o exemplo exato em que ele parou. Leve isso em conta ao retomar: reinicie a partir do início de uma época ou rastreie as amostras ou os fragmentos já processados no seu próprio estado de treinamento para poder ignorá-los ao retomar.

Monitorar recursos de GPU

Use o painel de recursos de GPU para monitorar a integridade e a utilização da GPU enquanto seu código é executado no AI Runtime. O painel oferece suporte a cargas de trabalho de nó único e de vários nós.

Para abrir o painel, conecte seu notebook ao AI Runtime e, no painel lateral direito, clique em ícone de chip.Recursos de GPU

Painel de recursos de GPU mostrando métricas de utilização, memória e temperatura para cada GPU.

O painel exibe as seguintes métricas para cada GPU:

  • Percentual de utilização da GPU
  • Uso de memória de GPU
  • Temperatura

O painel consulta as métricas a cada 10 segundos e mantém até 2 horas de histórico. Clique no ícone Atualizar.Atualize para buscar os valores mais recentes imediatamente. Após 5 minutos de inatividade, o painel pausa; reabra-o para retomar o monitoramento.

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 ramificação 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 em Azure Databricks

Confira Limites de recursos.