Rastreio e observabilidade de experimentos

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.

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.

Salvamento de ponto de verificação de modelos

Para treino distribuído, guarde e carregue checkpoints do modelo de forma assíncrona em volumes do Unity Catalog, que fornecem a mesma governação que outros objetos do Unity Catalog. Utilize UCVolumeWriter e UCVolumeReader do pacote serverless_gpu.data com a API Torch Distributed Checkpoint (DCP). Estas infraestruturas de armazenamento processam todas as operações de E/S através de um diretório local rápido (/tmp, que é baseado em NVMe nos nós de GPU sem servidor) e carregam para ou transferem do volume do Unity Catalog, o que é mais rápido do que escrever fragmentos de ponto de verificação diretamente no ponto de montagem FUSE. A atomicidade dos metadados é preservada: o autor publica o .metadata ficheiro apenas depois de os fragmentos de dados terminarem de ser carregados.

Crie pontos de controlo com frequência suficiente para limitar o trabalho perdido após uma interrupção, mas não com tanta frequência que a sobrecarga de I/O abrande o processo de treino. Tenta um ponto de controlo a cada 30 minutos a uma hora, e ajusta o intervalo com base no tempo do teu passo e tamanho do ponto de controlo.

Para enviar checkpoints em segundo plano enquanto o treino prossegue, passe UCVolumeWriter como storage_writer para dcp.async_save. As operações de gravação assíncronas requerem um backend de CPU no grupo de processos, por isso, 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 controlo 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 controlo do modelo guarda o estado do modelo e do otimizador, mas não a posição da sua pipeline de dados no conjunto de dados, pelo que uma execução retomada não pode avançar diretamente até à amostra exata onde parou. Tenha isto em conta na forma como retoma o processo: reinicie a partir do início de uma época, ou registe as amostras ou partições já processadas no seu próprio estado de treino para poder ignorá-las ao retomar.

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 Recursos da GPU no painel lateral direito.

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 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.