Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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âmetrorun_nameemmlflow.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_runPara personalizar o experimento usado por
.distributed(), chamemlflow.set_experiment()antes de invocar.distributed()ou defina a variável deMLFLOW_EXPERIMENT_NAMEambiente. 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(), definaMLFLOW_RUN_IDantes de chamá-la:os.environ["MLFLOW_RUN_ID"] = "<previous-run-id>" run_train.distributed()Configure o parâmetro
stepemMLFlowLoggerpara 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 Recursos de 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 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/Sharedvez 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.