Trainieren eines LLM mit Ray auf AKS

In diesem Artikel reichen Sie einen RayJob ein, der Qwen2.5-7B-Instruct mithilfe von LLaMA-Factory und verteiltem Ray Train auf dem viggo-NLG-Datensatz feinabstimmt. Der Auftrag verwendet vier Mitarbeiter mit jeweils einer GPU, liest Schulungsdaten aus Azure Blob Storage und lädt den trainierten LoRA-Adapter für nachgeschaltete Ableitung hoch.

Wichtig

Open-Source-Software wird überall in AKS-Dokumenten und -Beispielen erwähnt. Software, die Sie bereitstellen, ist von AKS-Vereinbarungen zum Servicelevel, der eingeschränkten Garantie und dem Azure-Support ausgeschlossen. Wenn Sie Open-Source-Technologie zusammen mit AKS nutzen, nutzen Sie die Supportoptionen, die von den jeweiligen Communitys und Projektbetreuenden angeboten werden, um einen Plan zu entwickeln.

Microsoft übernimmt die Verantwortung für die Erstellung der Open-Source-Pakete, die wir auf AKS bereitstellen. Diese Verantwortung beinhaltet die vollständige Übernahme des Build-, Scan-, Signier-, Validierungs- und Hotfix-Prozesses sowie die Kontrolle über die Binärdateien in Container-Images. Weitere Informationen finden Sie unter Sicherheitsrisikomanagement für AKS und AKS-Supportabdeckung.

Voraussetzungen

Festlegen von Umgebungsvariablen

Navigieren Sie zum LLM-Schulungsbeispiel im geklonten Repository, und konfigurieren Sie die erforderlichen Umgebungsvariablen:

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

Hinweis

Wenn Sie Team-Warteschlangen (Option B) konfiguriert haben, legen Sie export QUEUE_NAME=team-a oder export QUEUE_NAME=team-b fest, bevor Sie source env.example ausführen. Die Standardeinstellung QUEUE_NAME=default funktioniert nur mit der Konfiguration mit einer einzelnen Warteschlange (Option A).

Workload übermitteln

Übermitteln Sie das verteilte Training RayJob:

./submit.sh

Das Skript erstellt eine ConfigMap aus dem Schulungsskript, rendert die Manifestvorlage mit vier GPU-Workern über envsubstund wendet sie an. Kueue lässt den Job zu, wenn in der konfigurierten Warteschlange vier GPUs verfügbar sind.

Tip

Führen Sie die Ausführung aus ./submit.sh --dry-run , um das gerenderte Manifest zu überprüfen, ohne es auf den Cluster anzuwenden.

Fortschritt überwachen

Suchen und exportieren Sie den Auftragsnamen, wenn Sie sich in einer neuen Shell befinden:

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

Überwachen Sie den RayJob-Status und die Kueue-Zulassung:

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

Erwartete Ausgabe, wenn der Einzelvorgang abgeschlossen ist:

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

Verfolgen Sie die Protokolle des Head-Pods:

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

Überprüfen der Ergebnisse

Überprüfen Sie den Upload des LoRA-Adapters:

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

Erwartete Ausgabe:

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

Überprüfen Sie, ob der latest.txt-Zeiger geschrieben wurde (wird vom Batch-Inferenzbeispiel zur automatischen Erkennung verwendet):

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

Erwartete Ausgabe:

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

Konfigurationsreferenz

Variable Vorgabe Description
AZURE_STORAGE_ACCOUNT_NAME (erforderlich) Speicherkonto aus Modul 1
NUM_WORKERS 4 GPU-Worker-Replikate (4 x jeweils 1 GPU)
QUEUE_NAME default Name der Kueue LocalQueue
LLM_DATA_CONTAINER llm-pipeline BLOB-Container für Eingabedaten
LLM_LORA_CONTAINER llm-pipeline Blob-Container für LoRA-Upload
CONFIGMAP_NAME llm-training-scripts Name für die ConfigMap, die das Schulungsskript hält

Bereinigen von Ressourcen

Löschen Sie den RayJob und dessen ConfigMap:

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

Nächste Schritte

Führen Sie die Batch-Inferenz mit dem trainierten Adapter aus

  • Last updated on