適用於: ✔️ AKS 自動化 ✔️ AKS 標準
在 AKS 上執行 GPU 工作負載需要適當的設定與持續驗證,以確保運算資源可存取、安全且被最佳化利用。 本文概述管理支援 GPU 節點、驗證配置及減少工作負載中斷的最佳實務。
對於大多數生產環境中的 AKS 工作負載,建議的預設選項是 AKS Automatic。 AKS 自動提供可投入生產的基準環境,具備預先設定的作業、安全性保護措施,以及 SLA 支援的 Pod 就緒能力,協助團隊降低第 2 天的平台額外負荷。
GPU 工作負載請選擇 AKS Automatic 或 AKS Standard
請參考以下指引作為起點:
| 劇本 | 建議的路徑 | 原因為何 |
|---|---|---|
| 大多數生產型 GPU 工作負載 | AKS 自動化系统 | 生產環境就緒的預設設定、內建保護措施,以及更低的叢集作業額外負荷。 |
| 從部署到穩定生產的更快路徑 | AKS 自動化系统 | 透過 Pod 就緒 SLA 提供預先設定的叢集作業與可預測的啟動行為。 |
| 先進平台自訂與明確的操作控制 | AKS 標準 | 在自訂節點池生命週期與平台調校方面提供更大彈性。 |
| 專門且非預設的平台架構需求 | AKS 標準 | 可對基礎架構的行為和設定進行更多手動控制。 |
欲了解更多資訊,請參閱《Azure Kubernetes Service (AKS) Automatic 簡介》。
AKS Automatic 為生產 GPU 工作負載提供的服務
AKS Automatic 透過提供以下功能,協助建立生產 GPU 工作負載的堅實營運基準:
- 適用於生產環境的叢集配置預設值。
- 內建最佳實務與保障措施。
- 具備 SLA 支援的 Pod 就緒狀態,實現可預測的啟動行為。
- 受控叢集作業,減少第 2 天的手動工作。
這些平台預設並不能取代本文所述的工作負載層級最佳實務,例如部署控制、驗證檢查及隔離政策。
GPU 工作負載,如 AI 模型訓練、即時推論、模擬與視訊處理,通常依賴於:
- 正確的 GPU 驅動程式和執行階段相容性。
- GPU 資源的準確排程。
- 存取容器內的 GPU 硬體裝置。
設定錯誤可能會導致高成本、未預期的工作失敗或 GPU 使用量過低。
強制執行 GPU 工作負載放置
預設情況下,AKS 排程器會將 Pod 放置在任何具有足夠 CPU 和記憶體的可用節點上。 若無法控制工作負載配置,可能會產生以下兩種問題:
- 排程器可能會把 GPU 工作負載放在沒有 GPU 的節點上,導致工作負載無法啟動。
- 通用工作負載可能佔用 GPU 節點,浪費昂貴資源。
若要強制執行正確的放置:
使用類似
[gpu-vendor].com/gpu: NoSchedule的鍵(例如nvidia.com/gpu: NoSchedule)為您的 GPU 節點加上污點。 這個污點會阻止非 GPU 工作負載被排程到這些節點上。在 GPU 工作負載 Pod 規格中新增符合的容忍度,以便它可以排程在點化的 GPU 節點上。
在你的 Pod 中定義 GPU 資源請求和限制,確保排程器能保留 GPU 容量。 例如:
resources: limits: [gpu-vendor].com/gpu: 1使用驗證原則或許可控制器來強制執行 GPU 工作負載,包含必要的容忍度和資源限制。
此方法可保證只有已 GPU 就緒的工作負載會進入 GPU 節點,並可存取所需的特殊計算資源。
在 AKS Automatic 中,平台防護機制預設已預先設定。 你仍然會套用工作負載層級的擺放控制來強制執行嚴格的 GPU 排程行為。
驗證 GPU 驅動程式安裝與執行時準備狀況
部署生產 GPU 工作負載之前,一律驗證您的 GPU 節點集區:
- 配備相容的 GPU 驅動程式。
- 主控良好的 Kubernetes 裝置外掛程式 DaemonSet。
- 將
[gpu-vendor].com/gpu公開為可排程的資源。
您可以使用與 GPU 廠商相關聯的系統管理介面 (SMI),以確認在 GPU 節點集區上目前執行的驅動程式版本。
下列命令會從 GPU 裝置外掛程式部署 Pod 內部執行 nvidia-smi,以驗證已啟用 NVIDIA GPU 的節點集區上的驅動程式安裝和執行階段的整備度:
kubectl exec -it $"{GPU_DEVICE_PLUGIN_POD}" -n {GPU_NAMESPACE} -- nvidia-smi
您的輸出應該與下列範例輸出類似:
+-----------------------------------------------------------------------------+
|NVIDIA-SMI 570.xx.xx Driver Version: 570.xx.xx CUDA Version: 12.x|
...
...
對每個 GPU 節點池重複這個 kubectl exec 指令,確認節點上安裝的驅動程式版本。
在已啟用 AMD GPU 的節點集區上,或部署 AMD GPU 元件,並在 ROCm 裝置外掛程式 Pod 中執行 amd-smi 命令,以確認安裝的驅動程式版本。
將已啟用 GPU 的節點保持更新至最新的節點 OS 映像
若要確保 AKS 上 GPU 工作負載的效能、安全性和相容性,使用最新建議的節點 OS 映像將 GPU 節點集區保持在最新非常重要。 這些更新非常重要,因為它們:
- 包含最新的生產等級 GPU 驅動程式,取代任何已取代或生命週期結束 (EOL) 版本。
- 已針對與您目前 Kubernetes 版本的相容性進行完整測試。
- 解決由 GPU 廠商識別的已知弱點。
- 納入最新的作業系統和容器執行階段改良功能,以增強穩定性與效率。
將你的 GPU 節點池升級到 AKS 發布的最新推薦節點作業系統映像檔,方法是設定 自動升級通道 或 手動升級。 您可以使用 AKS 發行追蹤器來監視和追蹤最新的節點映像版本。
對於大多數正式環境情境,請先以 AKS Automatic 作為預設基準。 如果你使用 AKS 標準版,請明確設定升級通道和維護視窗。
使用共用叢集時區隔 GPU 工作負載
如果具有 GPU 節點集區的單一 AKS 叢集執行多個類型的 GPU 工作負載,例如模型訓練、即時推斷或批次處理,則務必區隔這些工作負載,以便:
- 避免不同工作負載類型之間的意外干擾或資源爭用。
- 改善安全性並維持合規性界限。
- 簡化每個工作負載類別的 GPU 資源使用量管理的和監視。
您可以使用命名空間和網路原則,在單一 AKS 叢集內隔離 GPU 工作負載。 這可透過工作負載特定配額、限制和記錄設定,實現更清楚的治理。
範例案例
考慮一個 AKS 叢集,其主控不需要彼此通訊的兩個不同 GPU 工作負載類型:
- 訓練工作負載:資源密集型 AI 模型訓練工作。
- 推論工作負載:延遲敏感的即時推論服務。
您可以使用下列步驟來區隔兩個工作負載:
使用
kubectl create namespace命令為每個工作負載類型建立專用的命名空間。kubectl create namespace gpu-training kubectl create namespace gpu-inference依類型為 GPU 工作負載 Pod 加上標籤,如下列範例所示:
metadata: namespace: gpu-training labels: workload: training套用網路原則以隔離工作負載類型之間的流量。 下列資訊清單會封鎖
gpu-training命名空間的所有輸入和輸出 (除非明確允許):apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-cross-namespace namespace: gpu-training spec: podSelector: {} policyTypes: - Ingress - Egress ingress: [] egress: []
原則如下:
- 套用至
gpu-training命名空間中的所有 Pod。 - 預設會拒絕所有傳入和傳出流量,支援強式隔離。
此模型可增強共用 GPU 環境中的清晰度、控制和安全,尤其是工作負載類型有不同的執行階段設定檔、風險層級或作業需求時。
使用多重執行個體 GPU (MIG) 最佳化 GPU 節點上的資源使用量
不同的 GPU 工作負載有不同的記憶體需求。 較小規模的部署,如 NVIDIA A100 40GB,可能不需要整張 GPU。 不過,單一工作負載預設會佔用 GPU 資源,即使使用量過低也一樣。
AKS 支援 GPU 節點上的資源最佳化,方法是使用多重執行個體 GPU (MIG) 將 GPU 節點分割成較小的扇區,使得小組可以更有效率地排程較小的工作。 深入了解支援的 GPU 大小,以及如何開始使用 AKS 上的多重執行個體 GPU。
使用暫時性 NVMe 資料磁碟作為高效能快取
對於在 AKS 中的 GPU VM 上執行的 AI 工作負載,快速且可靠地存取暫存儲存體對於最大化定型和推斷效能至關重要。 短暫存在的 NVMe 資料磁碟提供高輸送量、低延遲的儲存空間,直接連接至 VM 主機,非常適合用於快取資料集、儲存中間檢查點和模型參數,或在資料預處理和分析過程中提供暫存空間等情況。
為 AI 工作負載部署已啟用 GPU 的節點集區時,請設定暫時 NVMe 資料磁碟,以做為高效能的快取或臨時空間。 這種方法有助於消除 I/O 瓶頸、加速資料密集型操作,並確保您的 GPU 資源在等待資料時不會閒置。
Azure 支援跨越多種 Azure GPU VM 家族的短暫 NVMe 資料磁碟。 根據 GPU 虛擬機大小,虛擬機最多可擁有八顆臨時 NVMe 資料磁碟,總容量最高可達 28 TiB。 如需 VM 大小的詳細設定,請參閱 ND H100 v5 系列文件 或所選 GPU 系列的 VM 大小文件。
若要簡化佈建和管理,請使用 Azure 容器儲存體,它可以自動偵測和協調 Kubernetes 工作負載的暫時性 NVMe 磁碟。
建議的場景包括:
- 針對 AI 訓練和推斷,快取大型資料集和模型檢查點。
- 針對 AI 推斷快取模型權數。 例如,KAITO 託管模型作為本地 NVMe 上的 OCI 物件。
- 提供批次工作與資料管線的快速臨時空間。
這很重要
暫時性 NVMe 磁碟上的資料是暫時的,如果解除配置或重新部署 VM,就會遺失。 僅將這些磁碟用於非重要、暫時性資料,並將重要資訊儲存在持續性 Azure 儲存體解決方案上。
如需暫時性 NVMe 資料磁碟的詳細資訊,請參閱 AKS 中暫時性 NVMe 資料磁碟的最佳做法。
相關內容
欲了解更多關於 AKS 與 GPU 工作負載的資訊,請參閱以下文章:
- Azure Kubernetes Service (AKS) 自動化導論
- 建立 AKS 自動叢集
- 在 AKS 叢集上建立啟用 GPU 的節點集區。
- 使用自我管理的 NVIDIA DCGM 匯出工具來監視 GPU 工作負載。
- 使用 KEDA 和 DCGM 匯出工具,根據常見的 GPU 計量自動調整您的 GPU 工作負載。