在本文中，您會提交一個 RayJob，使用 LLaMA-Factory 和分散式 Ray Train，在 viggo NLG 資料集上微調 Qwen2.5-7B-Instruct。 這個工作需要四名工作者，每人一台 GPU，從 Azure Blob 儲存體 讀取訓練資料，並上傳訓練好的 LoRA 介面卡進行下游推論。
重要
整個 AKS 文件和範例都會提及開放原始碼的軟體。 您部署的軟體會從 AKS 服務等級協定、有限保固和 Azure 支援 中排除。 當您搭配 AKS 使用開放原始碼技術時，請參閱個別社群和專案維護人員所提供的支援選項，以開發計畫。
Microsoft 負責建置我們在 AKS 上部署的開源套件。 該責任包括擁有組建、掃描、簽署、驗證和 Hotfix 程式的完整擁有權，以及控制容器映像中的二進位檔。 如需詳細資訊，請參閱 AKS 弱點管理和 AKS 支援涵蓋範圍。
必要條件
- 基礎結構是依照 在 AKS 上為 Ray 和 Kueue 部署基礎結構 進行部署的。
- 已依照在 AKS 上為 Ray 工作負載設定 Kueue 佇列完成 Kueue 佇列設定。
- 叢集中至少有四顆 A100 GPU（此例使用四名工作者，每人一台 GPU）。
- Viggo 資料集已上傳至位於
llm-pipeline/data/的 Blob 儲存體（此作業由基礎架構 Terraform 模組自動完成）。 -
envsubst已安裝（Linux 上為gettext套件，macOS 上為brew install gettext）。
設定環境變數
前往複製倉庫中的 LLM 訓練範例，並設定所需的環境變數：
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
附註
如果你已設定團隊佇列（選項 B），請先設定export QUEUE_NAME=team-a或export QUEUE_NAME=team-b，再執行source env.example。 預設 QUEUE_NAME=default 設定僅適用於單排列配置（選項 A）。
提交工作負載
提交分散式訓練 RayJob：
./submit.sh
此指令碼會從訓練指令碼建立 ConfigMap，透過 envsubst 使用四個 GPU 工作節點呈現資訊清單範本，並套用該資訊清單。 當配置佇列中有四張 GPU 可用時，Kueue 會承認該任務。
Tip
執行 ./submit.sh --dry-run 以驗證渲染的清單，但不套用到叢集。
監視進度
如果你是在新的 shell 中，請找出並匯出作業名稱：
export JOB_NAME=$(kubectl -n ray get rayjob --no-headers -o custom-columns=":metadata.name" | grep llm-training)
請觀看 RayJob 狀態與 Kueue 的承認：
kubectl -n ray get rayjob ${JOB_NAME} -w
kubectl -n ray get workload -w
工作完成時的預期輸出：
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
追蹤 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
驗證結果
檢查 LoRA 適配器上傳：
az storage blob list -c llm-pipeline --prefix lora/ \
--account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login -o table
預期產出：
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
驗證 latest.txt 指標是否被寫入（用於批次推論的自動發現範例）：
az storage blob download -c llm-pipeline -n lora/latest.txt \
--account-name ${AZURE_STORAGE_ACCOUNT_NAME} --auth-mode login
預期產出：
azure://llm-pipeline@<storage-account>.blob.core.windows.net/lora/<job-name>
設定參考
| 變數 | 預設 | Description |
|---|---|---|
AZURE_STORAGE_ACCOUNT_NAME |
（必修） | 模組1的儲存帳戶 |
NUM_WORKERS |
4 |
GPU 工作節點副本（4 個副本，每個副本各有 1 個 GPU） |
QUEUE_NAME |
default |
Kueue LocalQueue 名稱 |
LLM_DATA_CONTAINER |
llm-pipeline |
Blob 容器用於輸入資料 |
LLM_LORA_CONTAINER |
llm-pipeline |
用於 LoRA 上傳的 Blob 容器 |
CONFIGMAP_NAME |
llm-training-scripts |
儲存訓練腳本的 ConfigMap 名稱 |
清理資源
刪除 RayJob 及其對應的 ConfigMap：
kubectl -n ray delete rayjob ${JOB_NAME}
kubectl -n ray delete configmap ${CONFIGMAP_NAME}