Rastreio e observabilidade de experimentos

Importante

Este recurso está no Public Preview.

O AI Runtime integra-se nativamente com o MLflow para acompanhamento de experiências e inclui um painel de recursos da GPU incorporado para monitorizar a utilização, memória e temperatura. Utilize o MLflow para registar métricas e execuções, ver os resultados do treino no notebook e na interface do utilizador do MLflow, guardar pontos de verificação do modelo em volumes do Unity Catalog e acompanhar o estado da GPU enquanto o código está em execução.

Tip

  • O AI Runtime integra-se nativamente com o MLflow para acompanhamento de experiências e registo de modelos.
  • Um painel de recursos da GPU incorporado mostra utilização, memória e temperatura.
  • Guardar os checkpoints dos modelos em volumes do Unity Catalog.

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

  • Ao usar a API Serverless GPU, cada chamada a .distributed() cria automaticamente uma execução de experiência no MLflow. Se for chamada no âmbito de uma execução ativa do MLflow, é criada, em vez disso, uma execução filha aninhada na execução principal ativa.

    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 MLFLOW_EXPERIMENT_NAME variável de ambiente. O nome padrão do experimento é /Users/{WORKSPACE_USER}/{notebook-name}. Usa sempre 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 MLflow anterior com .distributed(), defina MLFLOW_RUN_ID antes de o chamar:

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

  • 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, por isso registar cada lote em grandes treinos pode atingir esse limite. Consulte Limites de recursos.

Registos de visualização

  • Saída do notebook: A saída padrão e os erros padrão do seu código de treino são apresentados na saída da célula do notebook.
  • Registos MLflow: A interface do experimento MLflow apresenta métricas de treino, parâmetros e artefactos.

Se não conseguires ver registos

O separador Logs na página de execução do MLflow transmite os logs da execução de trabalhos Databricks associada à execução do MLflow, pelo que o acesso é governado pelas permissões desse trabalho. Se o separador mostrar Não tem acesso a estes registos, o utilizador não tem permissões suficientes.

O acesso à execução no MLflow não implica acesso ao trabalho. Pode ter a permissão da experiência do MLflow e, ainda assim, ser-lhe negado o acesso aos registos. Para obter acesso, peça aos utilizadores com permissões Pode gerir ou a um administrador do espaço de trabalho que lhe concedam pelo menos Pode ver na tarefa. Consulte Acesso de Controlo a um trabalho para saber como as permissões são concedidas.

Salvamento de ponto de verificação de modelos

Para o treino distribuído, guarde o estado do modelo e do otimizador em volumes do Unity Catalog utilizando a API Torch Distributed Checkpoint (DCP) com os backends de armazenamento serverless_gpu.data.UCVolumeWriter e serverless_gpu.data.UCVolumeReader. Guarde de forma assíncrona para que o treino continue enquanto o ponto de controlo é enviado, e crie pontos de controlo com frequência suficiente para limitar a perda de trabalho após uma interrupção. Como um ponto de verificação do modelo não capta a posição do pipeline de dados, guarde também um ponto de verificação do pipeline de dados para que, quando a execução for retomada, prossiga com os dados corretos.

Para consultar o padrão completo de pontos de verificação, veja Melhorar o desempenho da formação e a resiliência no AI Runtime.

Monitorizar recursos da GPU

Usa o painel de recursos da GPU para monitorizar a saúde e utilização da GPU enquanto o teu código corre em tempo de execução de IA. O painel suporta tanto cargas de trabalho de nó único como de múltiplos nós.

Para abrir o painel, liga o teu portátil ao AI Runtime e depois clica no ícone do chip.Recursos da GPU no painel lateral direito.

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

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

  • Percentagem de utilização da GPU
  • Utilização da memória da GPU
  • Temperatura

O painel consulta as métricas a cada 10 segundos e mantém até 2 horas de histórico. Clica no ícone de atualizar.Atualize para obter imediatamente os valores mais recentes. Após 5 minutos de inatividade, o vidro faz uma pausa; Reabra para retomar a monitorização.

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 Azure Databricks

Consulte Limites de recursos.

  • Last updated on