Melhores práticas para computede GPU sem servidor

Este artigo apresenta recomendações de boas práticas para usar compute GPU serverless em seu Notebook e Job.

Seguindo essas recomendações, você aumentará a produtividade, a relação custo-benefício e a confiabilidade de suas cargas de trabalho no Databricks.

Mova o código de carregamento de dados para dentro do decorador @distributed.

O tamanho dataset pode exceder o tamanho máximo permitido pelo pickle. Portanto, recomenda-se que o dataset seja gerado dentro do decorador, da seguinte forma:

Python

from serverless_gpu import distributed

# this may cause pickle error
dataset = get_dataset(file_path)
@distributed(gpus=8, remote=True)
def run_train():
  # good practice
  dataset = get_dataset(file_path)
  ....

Use o computecorreto

• Utilize compute GPU sem servidor. Esta opção inclui torch, cuda e torchvision otimizados para compatibilidade. As versões exatas dos pacotes dependerão das versões do ambiente.

• Selecione seu acelerador no painel lateral de ambiente.

  • Para cargas de trabalho de treinamento remoto distribuído, utilize uma GPU A10, que posteriormente será o cliente para enviar um Job para o H100 remoto.
  • Para executar tarefas interativas de grande porte no próprio notebook, você pode conectá-lo a um H100, o que ocupará 1 nó (8 GPUs H100).

• Para evitar o uso excessivo de GPUs, você pode conectar seu notebook a um cluster de CPUs para algumas operações, como clonagem de repositórios Git e conversão de MDS.

Recomendações do MLflow

Para um ciclo de desenvolvimento de ML ideal, use MLflow 3 no Databricks. Siga estas dicas:

• Atualize MLflow do seu ambiente para a versão 3.0 ou mais recente e siga o MLflow aprendizagem profunda flow em MLflow 3 aprendizagem profunda fluxo de trabalho.

• Defina o parâmetro step em MLFlowLogger para um número razoável de lotes. MLflow tem um limite de 10 milhões de passos que podem ser registrados. Consulte os limites de recursos.

• Habilite mlflow.pytorch.autolog() se PyTorch Lightning for usado como treinador.

• Personalize o nome da sua execução do MLflow encapsulando o código de treinamento do seu modelo dentro do escopo da API mlflow.start_run() . 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 parâmetro run_name 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 default é jobTaskRun-xxxxx.

  Python

  from transformers import TrainingArguments
  args = TrainingArguments(
      report_to="mlflow",
      run_name="llama7b-sft-lr3e5",  # <-- MLflow run name
      logging_steps=50,
  )

• A API de GPU serverless inicia um experimento MLflow para log métricas do sistema. Por default, ele usa o nome /Users/{WORKSPACE_USER}/{get_notebook_name()} a menos que o usuário o sobrescreva com a variável de ambiente MLFLOW_EXPERIMENT_NAME.

  • Ao definir a variável de ambiente MLFLOW_EXPERIMENT_NAME , use um caminho absoluto. Por exemplo,/Users/<username>/my-experiment.
  • O nome do experimento não deve conter o nome da pasta existente. Por exemplo, se my-experiment for uma pasta existente, o exemplo acima resultará em erro.
  Python

  import os
  from serverless_gpu import distributed
  os.environ['MLFLOW_EXPERIMENT_NAME'] = '/Users/{WORKSPACE_USER}/my_experiment'
  @distributed(gpus=num_gpus, gpu_type=gpu_type, remote=True)
  def run_train():
  # my training code

• Para retomar o treinamento de uma execução anterior, especifique o MLFLOW_RUN_ID da execução anterior da seguinte forma.

  Python

  import os
  os.environ[‘MLFLOW_RUN_ID’] = <previous_run_id>
  run_train.distributed()

Colaboração multiusuário

• Para garantir que todos os usuários possam acessar o código compartilhado (por exemplo, módulos auxiliares, environment.yaml), crie pastas git em /Workspace/Repos ou /Workspace/Shared em vez de pastas específicas do usuário como /Workspace/Users/<your_email>/.
• Para código que está em desenvolvimento ativo, use pastas Git em pastas específicas do usuário /Workspace/Users/<your_email>/ e envie para repositórios Git remotos. Isso permite que vários usuários tenham um clone (e branch) específico para cada usuário, mas ainda utilizem um repo Git remoto para controle de versão. Consulte as melhores práticas para usar o Git no Databricks.
• Os colaboradores podem compartilhar e comentar no Notebook.

Limites globais no Databricks

Consulte os limites de recursos.