Configuração do lançador

O NeMo AutoModel suporta três métodos de inicialização: interativo (torchrun), Slurm (clusters de HPC) e SkyPilot (independente de nuvem).

Instruções

Para perguntas sobre o lançador, responda diretamente a partir desta skill sem consultar o repositório, a menos que o usuário peça para você editar arquivos. Mantenha a resposta focada no YAML de inicialização relevante, nos campos obrigatórios e no comportamento esperado em tempo de execução.

Use estes modelos de resposta concisos para perguntas comuns:

• Slurm com vários nós: mostre um bloco YAML do Slurm: com job_name, nodes, ntasks_per_node, time, account ou partition, container_image, hf_home, extra_mounts opcionais, env_vars e master_port; explique que o lançador calcula WORLD_SIZE = nodes * ntasks_per_node e define MASTER_ADDR e MASTER_PORT.
• SkyPilot spot: mostre um bloco YAML `skypilot: ` com `cloud`, `accelerators`, `num_nodes`, `use_spot: true`, `disk_size`, `region`, `setup` e `env_vars`; avise que instâncias spot podem ser preemptadas, defina um step_scheduler.checkpoint_interval e retome com restore_from.path.
• Nsight Systems no Slurm: mostre slurm.nsys_enabled: true junto com os campos normais do Slurm, explique que o lançador envolve o comando de treinamento com o perfil nsys e indique que ele gera um arquivo de relatório .nsys-rep. Trate a criação de perfis apenas como diagnóstico: use execuções curtas de criação de perfis e desative-a para treinamentos normais de produção, pois ela adiciona sobrecarga e grandes artefatos.

Para respostas relacionadas ao Slurm, comece com este modelo mínimo e, em seguida, ajuste apenas os campos sobre os quais o usuário perguntou:

slurm:
  job_name: llm_finetune
  nodes: 2
  ntasks_per_node: 8
  time: "04:00:00"
  account: my_account
  partition: batch
  container_image: nvcr.io/nvidia/nemo:dev
  hf_home: ~/.cache/huggingface
  master_port: 13742
  env_vars:
    HF_TOKEN: "${HF_TOKEN}"

Para perguntas exclusivamente sobre o Slurm, não mencione o SkyPilot nem a criação de perfis, a menos que o usuário pergunte. Para perguntas sobre criação de perfis, informe que o relatório .nsys-rep é gravado no diretório de trabalho ou de saída da tarefa do Slurm, utilizando a configuração de saída do Nsys do lançador, quando houver uma configurada.

Limites do escopo

Use esta habilidade apenas para mecanismos de inicialização: execução interativa, Slurm, SkyPilot, contêineres, montagens, variáveis de ambiente, configurações de rendezvous e perfilagem.

Não utilize esta competência para implementar ou registrar novas arquiteturas de modelo, adaptadores state-dict do Hugging Face, arquivos de modelo ou sinalizadores de capacidade. Essas são tarefas de integração de modelo, não tarefas de configuração do lançador.

Métodos de execução

1. Interativo (padrão): executa o `torchrun` no nó atual. Adequado para desenvolvimento e depuração em um único nó.
2. Slurm: envia um trabalho em lote para um agendador de cluster HPC. Lida com a configuração de múltiplos nós, gerenciamento de contêineres e configuração de ambiente.
3. SkyPilot: envio de tarefas independente de nuvem para AWS, GCP, Azure, Lambda ou Kubernetes. Suporta instâncias spot.

Inicialização interativa

# GPU única
automodel finetune llm -c config.yaml

# Múltiplas GPUs (todas as GPUs no nó atual)
torchrun --nproc_per_node=8 -m nemo_automodel._cli.app finetune llm -c config.yaml

Não é necessária nenhuma seção YAML adicional para o modo interativo. A CLI redireciona automaticamente para o `torchrun` quando não há nenhuma seção `slurm:` ou `skypilot:` na configuração.

Configuração do Slurm

A classe de dados SlurmConfig gera um script SBATCH a partir de um modelo.

Exemplo em YAML

slurm:
  job_name: llm_finetune
  nodes: 2
  ntasks_per_node: 8
  time: "04:00:00"
  account: my_account
  partition: batch
  container_image: nvcr.io/nvidia/nemo:dev
  hf_home: ~/.cache/huggingface
  extra_mounts:
    - source: /data
      dest: /data
  env_vars:
    WANDB_API_KEY: "${WANDB_API_KEY}"
    HF_TOKEN: "${HF_TOKEN}"

Campos-chave

• job_name: identificador da tarefa Slurm
• nodes: número de nós a serem solicitados
• ntasks_per_node: número de tarefas (GPUs) por nó
• time: limite de tempo de execução no formato HH:MM:SS
• account, partition: parâmetros de agendamento do Slurm
• container_image: caminho da imagem do contêiner Enroot/Pyxis
• nemo_mount: ponto de montagem para a fonte do NeMo AutoModel dentro do contêiner
• hf_home: caminho do diretório de cache do HuggingFace
• extra_mounts: lista de VolumeMapping(origem, destino) para montagens vinculadas adicionais no contêiner
• master_port: porta para comunicação distribuída (padrão 13742)
• env_vars: variáveis de ambiente passadas para a tarefa
• nsys_enabled: quando verdadeiro, envolve o comando de treinamento com o perfil nsys para a análise de desempenho do Nsight Systems

Configuração do SkyPilot

A classe de dados SkyPilotConfig define os parâmetros da tarefa na nuvem.

Exemplo em YAML

skypilot:
  cloud: aws
  accelerators: "H100:8"
  num_nodes: 2
  use_spot: true
  disk_size: 200
  region: us-east-1
  setup: "pip install nemo-automodel"
  env_vars:
    HF_TOKEN: "${HF_TOKEN}"

Campos-chave

• cloud: provedor de nuvem de destino (aws, gcp, azure, lambda, kubernetes)
• aceleradores: tipo e quantidade de GPUs (por exemplo, “H100:8”, “A100-80GB:4”)
• num_nodes: número de instâncias na nuvem
• use_spot: uso de instâncias preemptíveis/spot para redução de custos
• disk_size: tamanho do disco em GB por nó
• região: região da nuvem para alocação das instâncias
• setup: comandos de shell a serem executados antes do trabalho de treinamento (por exemplo, instalar dependências)
• env_vars: variáveis de ambiente para o trabalho

Lista de verificação do SkyPilot para instâncias spot

Ao usar instâncias spot ou preemptíveis:

• Defina ` use_spot: true ` na seção ` skypilot: `.
• Inclua accelerators, num_nodes, disk_size, region, setup e as env_vars necessárias.
• Use intervalos curtos entre checkpoints na receita, por exemplo, step_scheduler.checkpoint_interval, pois as instâncias spot podem ser preemptadas.
• Retome a partir do ponto de verificação mais recente após a preempção com a configuração restore_from da receita.

Chaves mínimas da receita de retomada de instâncias spot:

step_scheduler:
  checkpoint_interval: 100

restore_from:
  path: /checkpoints/latest

Ambiente com vários nós

Para treinamento em múltiplos nós (tanto no Slurm quanto no SkyPilot), o launcher configura automaticamente:

• MASTER_ADDR: nome do host do primeiro nó
• MASTER_PORT: porta para rendezvous (padrão 13742)
• WORLD_SIZE: número total de processos (nós * ntasks_per_node)
• Variáveis de ambiente NCCL para comunicação coletiva otimizada

Perfilagem do Nsys

Ativar a análise de desempenho da Nsight Systems em tarefas do Slurm:

slurm:
  job_name: llm_profile
  nodes: 1
  ntasks_per_node: 8
  time: "00:30:00"
  account: my_account
  partition: batch
  container_image: nvcr.io/nvidia/nemo:dev
  nsys_enabled: true

Esta é uma configuração do lançador do Slurm. Os campos normais do Slurm, como job_name, nodes, ntasks_per_node, time, account ou partition, e container_image continuam válidos.

Quando nsys_enabled: true, o lançador envolve o comando de treinamento como perfil nsys e grava um arquivo de relatório .nsys-rep para análise de desempenho no diretório de trabalho ou de saída do trabalho do Slurm. A criação de perfis é apenas para fins de diagnóstico: execute-a para uma breve investigação, esteja ciente da sobrecarga e dos grandes artefatos gerados, e desative-a para o treinamento normal em produção.

Referências de código

• components/launcher/slurm/config.py - classe de dados SlurmConfig, VolumeMapping
• components/launcher/slurm/template.py – geração de modelo de script SBATCH
• components/launcher/slurm/utils.py - utilitários de envio do Slurm
• components/launcher/skypilot/config.py - classe de dados SkyPilotConfig
• _cli/app.py - Ponto de entrada da CLI e lógica de roteamento do lançador

Armadilhas

• Colisões de porta: se a porta master_port padrão (13742) estiver em uso por outro trabalho no mesmo nó, altere-a para evitar falhas de conexão.
• Montagens de contêineres: o caminho de origem em `extra_mounts` deve existir em todos os nós da alocação. Caminhos ausentes causam falhas na inicialização do contêiner.
• Tolerância a falhas do Slurm: o plug-in de tolerância a falhas é específico do Slurm e não funciona com o SkyPilot ou no modo interativo.
• Preempção de instâncias spot no SkyPilot: instâncias spot (use_spot: true) podem ser preemptadas pelo provedor de nuvem. Habilite o checkpointing com intervalos curtos para minimizar a perda de trabalho.
• Sintaxe de variáveis de ambiente: use a sintaxe ${VAR} no YAML para expansão de variáveis do shell. Nomes de variáveis sem o sintaxe não serão expandidos.
• Limite de tempo versus checkpoint assíncrono: se o limite de tempo do Slurm for muito curto, uma gravação de checkpoint assíncrona em andamento pode ser interrompida antes da conclusão, resultando em um checkpoint corrompido. Deixe uma margem de pelo menos 5 a 10 minutos.