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.
Neste artigo, você enviará um RayJob que ajusta o modelo meteorológico básico do Microsoft Aurora em dados regionais do WeatherBench2 usando LoRA. O trabalho é executado em uma única GPU A100, o Kueue controla a admissão e o trabalho grava o ponto de verificação do adaptador e as métricas de treinamento no Armazenamento de Blobs do Azure.
Importante
O software de código aberto é mencionado em toda a documentação e amostras do AKS. O software que você implanta está excluído dos contratos de nível de serviço do AKS, garantia limitada e suporte do Azure. Ao usar tecnologia de código aberto junto com o AKS, consulte as opções de suporte disponíveis nas comunidades e mantenedores de projetos respectivos para desenvolver um plano.
A Microsoft assume a responsabilidade por criar os pacotes de código aberto que implantamos no AKS. Essa responsabilidade inclui ter propriedade completa do processo de criação, verificação, sinalização, validação e hotfix, junto com o controle sobre os binários em imagens de contêiner. Para obter mais informações, confira Gerenciamento de vulnerabilidades para o AKS e Cobertura de suporte do AKS.
Pré-requisitos
- Infraestrutura implantada seguindo Implantar infraestrutura para Ray e Kueue no AKS.
- Filas do Kueue configuradas seguindo Configurar filas do Kueue para cargas de trabalho do Ray no AKS.
- Pelo menos uma GPU A100 disponível no cluster (este exemplo usa uma GPU).
- Dados do Aurora WeatherBench2 enviados para o armazenamento de blob (o módulo de infraestrutura do Terraform faz o upload desses dados automaticamente).
-
envsubstinstalado (pacotegettextno Linux,brew install gettextno macOS).
Definir variáveis de ambiente
Navegue até o exemplo de ajuste fino do Aurora no repositório clonado e configure as variáveis de ambiente necessárias:
cd <path-to-cloned-repo>/AKS/examples/kueue-and-ray-on-aks/3-workloads/aurora-finetune
export AZURE_STORAGE_ACCOUNT_NAME=$(terraform -chdir=../../1-infrastructure/terraform output -raw storage_account_name)
source env.example
O arquivo env.example define valores padrão, incluindo a imagem do Ray, o nome da fila e os parâmetros de treinamento. A variável JOB_NAME é gerada automaticamente com um carimbo de data e hora.
Observação
Se você configurou filas de equipe (Opção B), defina export QUEUE_NAME=team-a ou export QUEUE_NAME=team-b antes de executar source env.example. O padrão QUEUE_NAME=default só funciona com a configuração de fila única (Opção A).
Enviar a carga de trabalho
Submeta o RayJob ao cluster:
./submit.sh
O script cria um ConfigMap do script de treinamento Python, renderiza o modelo de manifesto por meio envsubste o aplica ao cluster. O Kueue admite o trabalho quando a cota da GPU estiver disponível na fila configurada.
Tip
Execute ./submit.sh --dry-run para validar o manifesto renderizado sem aplicá-lo ao cluster.
Monitorar o progresso
Encontre e exporte o nome do trabalho se estiver em um novo shell:
export JOB_NAME=$(kubectl -n ray get rayjob --no-headers -o custom-columns=":metadata.name" | grep aurora-finetune)
Assista ao status do RayJob e à admissão de Kueue:
kubectl -n ray get rayjob ${JOB_NAME} -w
kubectl -n ray get workload -w
Saída esperada quando o trabalho for concluído:
NAME JOB STATUS DEPLOYMENT STATUS START TIME END TIME AGE
aurora-finetune-xxxxxxxxxx SUCCEEDED Complete 2026-01-01T00:00:00Z 2026-01-01T00:08:00Z 8m
NAME QUEUE RESERVED IN ADMITTED FINISHED AGE
rayjob-aurora-finetune-xxxxxxxxxx-xxxxx default cluster-queue True True 8m
Acompanhe os logs do worker:
kubectl -n ray logs -l ray.io/cluster=$(kubectl -n ray get rayjob ${JOB_NAME} -o jsonpath='{.status.rayClusterName}') -f
Verificar os resultados
Verifique os artefatos enviados para o armazenamento de blobs:
az storage blob list -c aurora --prefix checkpoints/${JOB_NAME}/ \
--account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login -o table
Resultado esperado:
Name Blob Type Blob Tier Length Content Type
------------------------------------------------------ ----------- ----------- -------- ------------------------
checkpoints/<job-name>/last.safetensors BlockBlob Hot 11432328 application/octet-stream
checkpoints/<job-name>/train-metrics.json BlockBlob Hot 985 application/json
Baixe e inspecione as métricas de treinamento:
az storage blob download -c aurora \
-n checkpoints/${JOB_NAME}/train-metrics.json \
--account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login \
--file /tmp/train-metrics.json
cat /tmp/train-metrics.json | python3 -m json.tool
Resultado esperado:
{
"final_loss": 24051.97,
"initial_loss": 24183.10,
"loss_history": [24183.10],
"loss_improvement": 131.13,
"max_steps": 1,
"trainable_parameters": 2850816,
"gpu_name": "NVIDIA A100-SXM4-80GB",
...
}
A loss_history matriz deve conter valores finitos (não NaN), confirmando que o caminho de dados e o treinamento do modelo estão funcionando corretamente.
Referência de configuração
| Variable | Default | Description |
|---|---|---|
AZURE_STORAGE_ACCOUNT_NAME |
(necessário) | Conta de armazenamento do Módulo 1 |
AURORA_INPUT_CONTAINER |
aurora |
Contêiner para dados de entrada |
AURORA_OUTPUT_CONTAINER |
aurora |
Contêiner para pontos de verificação |
AURORA_INIT_FILE |
init-2021-01-01-00z.npz |
Nome do arquivo NPZ inicial |
AURORA_TRUTH_FILE |
truth-2021-01-01-06z.npz |
Nome do arquivo NPZ verdadeiro |
AURORA_MAX_STEPS |
1 |
Etapas de treinamento |
AURORA_LORA_RANK |
8 |
Classificação LoRA |
AURORA_LEAD_HOURS |
6 |
Tempo de previsão (deve ser um múltiplo de 6 horas) |
AURORA_REQUIRE_GPU_NAME |
A100 |
Proteção de substring do nome da GPU |
QUEUE_NAME |
default |
Nome de Kueue LocalQueue |
CONFIGMAP_NAME |
aurora-finetune-scripts |
Nome do ConfigMap que contém o script de treinamento |
Limpar os recursos
Exclua o RayJob e seu ConfigMap:
kubectl -n ray delete rayjob ${JOB_NAME}
kubectl -n ray delete configmap ${CONFIGMAP_NAME}