Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel führen Sie einen RayJob aus, der die vLLM-Offline-Batchinferenz mithilfe des LoRA-Adapters ausführt, der durch das LLM-Trainingsbeispiel erzeugt wurde. Der Job liest den Viggo-Test-Split und den LoRA-Adapter aus Azure Blob Storage, erstellt Vorhersagen auf einer einzelnen GPU und lädt die Ergebnisse 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
- Infrastruktur, die gemäß Infrastruktur für Ray und Kueue auf AKS bereitstellen bereitgestellt wurde.
- Kueue-Warteschlangen, die gemäß Konfigurieren von Kueue-Warteschlangen für Ray-Workloads auf AKS konfiguriert wurden.
- Mindestens eine A100-GPU im Cluster verfügbar.
- LLM-Training nach Durchführen des Trainings eines LLM mit Ray auf AKS – der LoRA-Adapter muss unter
llm-pipeline/lora/in Blob Storage vorhanden sein. -
envsubstinstalliert (gettextPaket unter Linux,brew install gettextunter macOS).
Festlegen von Umgebungsvariablen
Navigieren Sie zum Batch-Ableitungsbeispiel im geklonten Repository, und konfigurieren Sie die erforderlichen Umgebungsvariablen:
cd <path-to-cloned-repo>/AKS/examples/kueue-and-ray-on-aks/3-workloads/batch-inference
export AZURE_STORAGE_ACCOUNT_NAME=$(terraform -chdir=../../1-infrastructure/terraform output -raw storage_account_name)
source env.example
Hinweis
Wenn Sie Teamwarteschlangen (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
Batch-Ableitung RayJob übermitteln:
./submit.sh
Das Skript erstellt eine ConfigMap aus dem Ableitungsskript, rendert die Manifestvorlage über envsubstund wendet sie an. Kueue lässt den Einzelvorgang zu, wenn 1 GPU in der konfigurierten Warteschlange verfügbar ist.
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 batch-inference)
Ü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
batch-inference-xxxxxxxxxx SUCCEEDED Complete 2026-01-01T00:00:00Z 2026-01-01T00:09:00Z 9m
NAME QUEUE RESERVED IN ADMITTED FINISHED AGE
rayjob-batch-inference-xxxxxxxxxx-xxxxx default cluster-queue True True 9m
Arbeitsprotokolle verfolgen:
kubectl -n ray logs -l ray.io/cluster=$(kubectl -n ray get rayjob ${JOB_NAME} -o jsonpath='{.status.rayClusterName}') -f --tail=100
Überprüfen der Ergebnisse
Vorhersagedateien in Blob Storage auflisten:
az storage blob list -c llm-pipeline --prefix "inference/${JOB_NAME}/" \
--account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login -o table
Erwartete Ausgabe:
Name Blob Type Blob Tier Length Content Type
--------------------------------------------------- ----------- ----------- -------- ------------------------
inference/<job-name>/metrics.json BlockBlob Hot 128 application/octet-stream
inference/<job-name>/predictions.jsonl BlockBlob Hot 411777 application/octet-stream
Laden Sie die Vorhersagen herunter, und überprüfen Sie sie:
az storage blob download -c llm-pipeline \
-n "inference/${JOB_NAME}/predictions.jsonl" \
--account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login \
--file /tmp/predictions.jsonl
head -1 /tmp/predictions.jsonl | python3 -m json.tool
Erwartete Ausgabe:
{
"input": "I'm wondering, have you played any games you found genuinely shocking?",
"expected": "request(specifier[shocking])",
"generated": "request_explanation"
}
Konfigurationsreferenz
| Variable | Vorgabe | Description |
|---|---|---|
AZURE_STORAGE_ACCOUNT_NAME |
(erforderlich) | Speicherkonto aus Modul 1 |
JOB_NAME |
batch-inference-<timestamp> |
Eindeutiger RayJob-Name |
QUEUE_NAME |
default |
Name der Kueue LocalQueue |
LLM_DATA_CONTAINER |
llm-pipeline |
Blob-Container mit Viggo-Testdaten |
LLM_LORA_CONTAINER |
llm-pipeline |
Blob-Container mit LoRA-Adaptern |
CONFIGMAP_NAME |
batch-inference-scripts |
Name für die ConfigMap, die das Ableitungsskript 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}
Um die gesamte Infrastruktur abzubauen, siehe Infrastruktur bereitstellen – Ressourcen bereinigen.