Een LLM trainen met Ray op AKS

In dit artikel dient u een RayJob in waarmee u Qwen2.5-7B-Instruct verder afstemt op de Viggo NLG-gegevensset met behulp van LLaMA-Factory en gedistribueerde Ray Train. De taak maakt gebruik van vier werkrollen met elk één GPU, leest trainingsgegevens uit Azure Blob Storage en uploadt de getrainde LoRA-adapter voor downstreamdeductie.

Belangrijk

Opensource-software wordt vermeld in AKS-documentatie en -voorbeelden. Software die u implementeert, is uitgesloten van AKS-serviceovereenkomsten, beperkte garantie en Azure-ondersteuning. Wanneer u opensource-technologie naast AKS gebruikt, raadpleegt u de beschikbare ondersteuningsopties van de respectieve community's en projectonderhouders om een plan te ontwikkelen.

Microsoft neemt de verantwoordelijkheid voor het bouwen van de opensource-pakketten die we implementeren op AKS. Deze verantwoordelijkheid omvat het volledige eigendom van het bouw-, scan-, onderteken-, validatie- en hotfixproces, samen met controle over de binaire bestanden in container images. Zie Beveiligingsbeheer voor AKS - en AKS-ondersteuningsdekking voor meer informatie.

Vereisten

  • Infrastructuur uitgerold volgens Infrastructuur voor Ray en Kueue implementeren op AKS.
  • Kueue-wachtrijen die zijn geconfigureerd volgens Kueue-wachtrijen configureren voor Ray-workloads op AKS.
  • Ten minste vier A100 GPU's die beschikbaar zijn in het cluster (in dit voorbeeld worden vier werkrollen met elk één GPU gebruikt).
  • Viggo-gegevensset geüpload naar blobopslag op llm-pipeline/data/ (automatisch uitgevoerd door de Terraform-infrastructuurmodule).
  • envsubst geïnstalleerd (gettext pakket in Linux, brew install gettext in macOS).

Omgevingsvariabelen instellen

Navigeer naar het LLM-trainingsvoorbeeld in de gekloonde opslagplaats en configureer de vereiste omgevingsvariabelen:

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

Notitie

Als u teamwachtrijen (optie B) hebt geconfigureerd, stelt u deze in export QUEUE_NAME=team-a of export QUEUE_NAME=team-b voordat u deze uitvoert source env.example. De standaardinstelling QUEUE_NAME=default werkt alleen met de configuratie van één wachtrij (optie A).

Workload indienen

Verzend de gedistribueerde training RayJob:

./submit.sh

Het script maakt een ConfigMap op basis van het trainingsscript, geeft de manifestsjabloon weer met vier GPU-werkrollen via envsubsten past deze toe. Kueue geeft de taak toe wanneer er vier GPU's beschikbaar zijn in de geconfigureerde wachtrij.

Tip

Voer ./submit.sh --dry-run uit om het gerenderde manifest te valideren zonder dit toe te passen op het cluster.

Voortgang bijhouden

Zoek en exporteer de taaknaam als u zich in een nieuwe shell bevindt:

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

Bekijk de RayJob-status en Kueue-toelating:

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

Verwachte uitvoer wanneer de taak is voltooid:

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

Volg de logs van de head-pod:

kubectl -n ray logs -f -l ray.io/cluster=$(kubectl -n ray get rayjob ${JOB_NAME} -o jsonpath='{.status.rayClusterName}') -c ray-head

Resultaten controleren

Controleer het uploaden van de LoRA-adapter:

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

Verwachte uitvoer:

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

Controleer of de latest.txt pointer is weggeschreven (gebruikt door het batchinferentievoorbeeld voor automatische ontdekking):

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

Verwachte uitvoer:

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

Configuratiegids

Variabele Default Description
AZURE_STORAGE_ACCOUNT_NAME (vereist) Opslagaccount van module 1
NUM_WORKERS 4 GPU-werkreplica's (elk 4 x 1 GPU)
QUEUE_NAME default Naam van Kueue LocalQueue
LLM_DATA_CONTAINER llm-pipeline Blobcontainer voor invoergegevens
LLM_LORA_CONTAINER llm-pipeline Blobcontainer voor LoRA-upload
CONFIGMAP_NAME llm-training-scripts Naam voor de ConfigMap die het trainingsscript bevat

De hulpbronnen opschonen

Verwijder de RayJob en de bijbehorende ConfigMap:

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

Volgende stappen 

Batchinferentie uitvoeren met de getrainde adapter

  • Last updated on