Entraîner un LLM avec Ray sur AKS

Dans cet article, vous soumettez un RayJob qui affine Qwen2.5-7B-Instruct sur le jeu de données Viggo NLG à l’aide de LLaMA-Factory et de Ray Train en mode distribué. La tâche utilise quatre processus de travail avec un GPU chacun, lit les données d’apprentissage depuis Stockage Blob Azure et téléverse l’adaptateur LoRA entraîné pour les inférences en aval.

Prérequis

• Infrastructure déployée à la suite de Déployer l’infrastructure pour Ray et Kueue sur AKS.
• Les files d’attente Kueue configurées en suivant Configurer les files d’attente Kueue pour les charges de travail Ray sur AKS.
• Au moins quatre GPU A100 disponibles dans le cluster (cet exemple utilise quatre workers avec un GPU chacun).
• Jeu de données Viggo téléversé vers le stockage Blob à l’emplacement llm-pipeline/data/ (opération effectuée automatiquement par le module d’infrastructure Terraform).
• envsubst installé (gettext package sur Linux, brew install gettext sur macOS).

Définir des variables d’environnement

Accédez à l’exemple d’apprentissage LLM dans le référentiel cloné et configurez les variables d’environnement requises :

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

Soumettre la charge de travail

Soumettez le RayJob d’entraînement distribué :

./submit.sh

Le script crée un ConfigMap à partir du script d’entraînement, affiche le modèle de manifeste avec quatre workers GPU via envsubst, et l’applique. Kueue autorise l’exécution du job lorsque quatre GPU sont disponibles dans la file d’attente configurée.

Surveiller la progression

Recherchez et exportez le nom de la tâche si vous êtes dans un nouveau shell :

export JOB_NAME=$(kubectl -n ray get rayjob --no-headers -o custom-columns=":metadata.name" | grep llm-training)

Surveillez le statut du RayJob et l’admission de Kueue :

kubectl -n ray get rayjob ${JOB_NAME} -w
kubectl -n ray get workload -w

Sortie attendue lorsque le travail se termine :

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

Suivez les journaux du 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

Vérifier les résultats

Vérifiez le chargement de l’adaptateur LoRA :

az storage blob list -c llm-pipeline --prefix lora/ \
  --account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login -o table

Sortie attendue :

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

Vérifiez que le latest.txt pointeur a été écrit (utilisé par l’exemple d’inférence par lot pour la découverte automatique) :

az storage blob download -c llm-pipeline -n lora/latest.txt \
  --account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login

Sortie attendue :

azure://llm-pipeline@<storage-account>.blob.core.windows.net/lora/<job-name>

Référence de configuration

Nettoyer les ressources

Supprimez RayJob et son ConfigMap :

kubectl -n ray delete rayjob ${JOB_NAME}
kubectl -n ray delete configmap ${CONFIGMAP_NAME}

Étapes suivantes