Trenowanie modelu LLM za pomocą Ray na platformie AKS

W tym artykule przesyłasz zadanie RayJob, które dostraja model Qwen2.5-7B-Instruct na zbiorze danych viggo NLG przy użyciu LLaMA-Factory i rozproszonego Ray Train. Zadanie używa czterech węzłów roboczych, z których każdy ma po jednym procesorze GPU, odczytuje dane treningowe z usługi Azure Blob Storage i przesyła wytrenowany adapter LoRA na potrzeby późniejszego wnioskowania.

Important

Oprogramowanie typu open source jest wymienione w dokumentacji i przykładach usługi AKS. Oprogramowanie, które wdrażasz, jest wykluczone z umów dotyczących poziomu usług AKS, ograniczonej gwarancji i wsparcia technicznego platformy Azure. W miarę korzystania z technologii open source wraz z usługą AKS zapoznaj się z opcjami pomocy technicznej dostępnymi w odpowiednich społecznościach i opiekunami projektów, aby opracować plan.

Firma Microsoft ponosi odpowiedzialność za tworzenie pakietów typu open source wdrażanych w usłudze AKS. Ta odpowiedzialność obejmuje posiadanie pełnej kontroli nad procesem kompilacji, skanowania, podpisywania, weryfikacji i szybkich poprawek, a także nad plikami binarnymi w obrazach kontenerów. Aby uzyskać więcej informacji, zobacz zarządzanie podatnościami dla AKS i zakres wsparcia dla AKS.

Prerequisites

  • Infrastruktura wdrożona zgodnie z Wdrażanie infrastruktury dla Ray i Kueue na AKS.
  • Kolejki Kueue skonfigurowane zgodnie z Konfigurowanie kolejek Kueue dla obciążeń Ray w usłudze AKS.
  • Co najmniej cztery układy GPU A100 dostępne w klastrze (w tym przykładzie użyto czterech węzłów roboczych, z których każdy ma jeden układ GPU).
  • Zestaw danych Viggo został przesłany do magazynu obiektów blob pod adresem llm-pipeline/data/ (odbywa się to automatycznie za pomocą modułu infrastruktury Terraform).
  • envsubst zainstalowano (gettext pakietu w systemie Linux, brew install gettext w systemie macOS).

Ustawianie zmiennych środowiskowych

Przejdź do przykładu trenowania LLM w sklonowanym repozytorium i skonfiguruj wymagane zmienne środowiskowe:

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

Note

Jeśli skonfigurowano kolejki zespołowe (opcja B), ustaw wartość export QUEUE_NAME=team-a lub export QUEUE_NAME=team-b przed uruchomieniem polecenia source env.example. Wartość domyślna QUEUE_NAME=default działa tylko z konfiguracją pojedynczej kolejki (opcja A).

Prześlij zadanie

Prześlij rozproszone szkolenie RayJob:

./submit.sh

Skrypt tworzy obiekt ConfigMap ze skryptu treningowego, renderuje szablon manifestu z czterema procesami roboczymi GPU za pomocą envsubst, a następnie go stosuje. Kueue dopuszcza zadanie, gdy w skonfigurowanej kolejce dostępne są cztery GPU.

Wskazówka

Uruchom polecenie ./submit.sh --dry-run , aby zweryfikować renderowany manifest bez stosowania go do klastra.

Monitorowanie postępu

Znajdź i wyeksportuj nazwę zadania, jeśli jesteś w nowej powłoce:

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

Obserwuj stan RayJob i dopuszczenie przez Kueue:

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

Oczekiwane dane wyjściowe po zakończeniu zadania:

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

Ujmij dzienniki zasobnika głównego:

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

Weryfikowanie wyników

Sprawdź przesyłanie adaptera LoRA:

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

Oczekiwane dane wyjściowe:

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

Sprawdź, czy zapisano latest.txt wskaźnik (używany przez przykład wnioskowania wsadowego do automatycznego wykrywania):

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

Oczekiwane dane wyjściowe:

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

Dokumentacja konfiguracji

Zmienna Default Description
AZURE_STORAGE_ACCOUNT_NAME (wymagane) Konto usługi Storage z modułu 1
NUM_WORKERS 4 Repliki workerów GPU (4 x po 1 GPU każda)
QUEUE_NAME default Nazwa kolejki lokalnej Kueue
LLM_DATA_CONTAINER llm-pipeline Kontener obiektów blob dla danych wejściowych
LLM_LORA_CONTAINER llm-pipeline Kontener obiektów blob do przesyłania LoRA
CONFIGMAP_NAME llm-training-scripts Nazwa obiektu ConfigMap zawierającego skrypt trenowania

Uprzątnij zasoby

Usuń obiekt RayJob i jego ConfigMap:

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

Następne kroki

Uruchom wnioskowanie wsadowe z użyciem wytrenowanego adaptera

  • Last updated on