Treine um LLM com o Ray no AKS.

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

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}

Próximas Etapas