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 otimiza o Qwen2.5-7B-Instruct no conjunto de dados NLG Viggo usando o LLaMA-Factory e o treinamento distribuído do Ray. O trabalho usa quatro workers com uma GPU cada, lê os dados de treinamento do Armazenamento de Blobs do Azure e carrega o adaptador LoRA treinado para inferência subsequente.
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 de acordo com Configurar filas do Kueue para cargas de trabalho do Ray no AKS.
- Pelo menos quatro GPUs A100 disponíveis no cluster (este exemplo usa quatro workers com uma GPU cada).
- Conjunto de dados Viggo carregado no armazenamento de blobs em
llm-pipeline/data/(feito automaticamente pelo módulo Terraform de infraestrutura). -
envsubstinstalado (pacotegettextno Linux,brew install gettextno macOS).
Definir variáveis de ambiente
Navegue até o exemplo de treinamento llm 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/llm-training
export AZURE_STORAGE_ACCOUNT_NAME=$(terraform -chdir=../../1-infrastructure/terraform output -raw storage_account_name)
source env.example
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
Envie o treinamento distribuído RayJob:
./submit.sh
O script cria um ConfigMap a partir do script de treinamento, renderiza o modelo de manifesto com quatro workers de GPU via envsubst e o aplica. O Kueue aceita o trabalho quando quatro GPUs estão disponíveis 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 da tarefa se você estiver em um novo shell:
export JOB_NAME=$(kubectl -n ray get rayjob --no-headers -o custom-columns=":metadata.name" | grep llm-training)
Acompanhe o status do RayJob e a admissão do 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
llm-training-xxxxxxxxxx SUCCEEDED Complete 2026-01-01T00:00:00Z 2026-01-01T00:19:00Z 19m
NAME QUEUE RESERVED IN ADMITTED FINISHED AGE
rayjob-llm-training-xxxxxxxxxx-xxxxx default cluster-queue True True 19m
Acompanhe os logs do pod principal:
kubectl -n ray logs -f -l ray.io/cluster=$(kubectl -n ray get rayjob ${JOB_NAME} -o jsonpath='{.status.rayClusterName}') -c ray-head
Verificar os resultados
Verifique o upload do adaptador LoRA:
az storage blob list -c llm-pipeline --prefix lora/ \
--account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login -o table
Resultado esperado:
Name Blob Type Blob Tier Length Content Type
----------------------------------------- ----------- ----------- -------- ------------------------
lora/latest.txt BlockBlob Hot 86 application/octet-stream
lora/<job-name>/rng_state_3.pth BlockBlob Hot 14725 application/octet-stream
Verifique se o ponteiro latest.txt foi escrito (usado pelo exemplo de inferência em lote para detecção automática):
az storage blob download -c llm-pipeline -n lora/latest.txt \
--account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login
Resultado esperado:
azure://llm-pipeline@<storage-account>.blob.core.windows.net/lora/<job-name>
Referência de configuração
| Variable | Default | Description |
|---|---|---|
AZURE_STORAGE_ACCOUNT_NAME |
(necessário) | Conta de armazenamento do Módulo 1 |
NUM_WORKERS |
4 |
Réplicas de workers de GPU (4 x 1 GPU cada) |
QUEUE_NAME |
default |
Nome de Kueue LocalQueue |
LLM_DATA_CONTAINER |
llm-pipeline |
Contêiner de blobs para dados de entrada |
LLM_LORA_CONTAINER |
llm-pipeline |
Contêiner de blobs para carregar o LoRA |
CONFIGMAP_NAME |
llm-training-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}