技術指南

用於 ML 工作負載的 Kubernetes

Kubernetes 是一個開源系統,可以跨機器叢集自動調度、擴展和重新啟動容器化程式。

概述

Kubernetes 是一個開源系統,可以跨機器叢集自動調度、擴展和重新啟動容器化程式。對於機器學習,它可以讓團隊將需要 GPU 的訓練作業和延遲敏感的模型伺服器打包到共享硬體上,而無需照顧單獨的伺服器。

ML 工作負載的 Kubernetes 是一個技術構建塊,會大規模影響模型品質、基礎設施成本、延遲和可靠性。

深入探討

Kubernetes 最初是在 Google 上建置的,用於運行 Web 服務,它將您的叢集視為由 CPU、記憶體和 GPU 組成的大池,然後決定哪台機器運行每個容器。 ML 團隊之所以依賴它,是因為工作負載是突發性的且成本高昂:訓練運行可能需要 8 個 GPU 持續 6 個小時,然後什麼都不需要。 Kubernetes 將該 pod 調度到具有空閒 GPU 的節點上,當作業完成時,它會釋放硬體。它還使推理伺服器保持活動狀態,重新啟動崩潰的容器並在電腦之間傳播副本以實現彈性。 Kubeflow、Ray 和 KServe 等構建於其之上的工具添加了特定於 ML 的部分,例如分散式訓練運算符、超參數調整和自動縮放模型端點,因此資料科學家可以使用更高層級的抽象化而不是原始 YAML。

技術洞察

Kubernetes 透過裝置外掛程式分配 GPU,這些外掛程式會宣傳 nvidia.com/gpu 等資源,調度程式會根據 pod 的請求進行比對。污點和容忍度使廉價的 CPU 作業遠離昂貴的 GPU 節點,而節點選擇器和關聯規則將訓練固定到特定的硬體。對於多 GPU 訓練,操作員建立一組相互發現並執行 PyTorch DDP 或 Horovod 等框架的 Pod,使用 NCCL 在叢集網路上交換梯度。

掌握用於 ML 工作負載的 Kubernetes

Kubernetes 是一個開源系統,可以跨機器叢集自動調度、擴展和重新啟動容器化程式。對於機器學習,它可以讓團隊將需要 GPU 的訓練作業和延遲敏感的模型伺服器打包到共享硬體上,而無需照顧單獨的伺服器。 ML 工作負載的 Kubernetes 是一個技術構建塊,會大規模影響模型品質、基礎設施成本、延遲和可靠性。為了建立深入的理解,請將 Kubernetes for ML Workloads 視為一種操作模型,而不是單一功能:定義所需的結果,澄清假設,並將系統可以可靠地執行的操作與仍需要專家判斷的操作分開。

在實務中,使用 Kubernetes 進行機器學習工作負載的強大團隊會根據可靠性和成本來最佳化架構、資料和基礎架構選擇。他們記錄明確的成功標準,根據實際數據和工作流程進行測試,並根據觀察到的失敗模式而不是一次性基準測試勝利進行迭代。這就是理論理解轉變為跨產品、政策和營運的持久能力的地方。

多年來,架構決策決定著效能和營運成本。同時,優化一個基準測試可以隱藏更廣泛的系統弱點。最具彈性的方法是將實驗速度與治理規則結合:運行試點、捕獲證據、發布決策日誌,並隨著模型行為、使用者期望和監管要求的發展不斷更新保障措施。

戰略影響

多年來,架構決策決定著效能和營運成本。

多年來,架構決策決定著效能和營運成本。在高品質部署中,這會轉化為可衡量的操作規則、所有權邊界和定期審查儀式,以便團隊可以增強信心,而不是擴大模糊性。

技術教育幫助團隊選擇正確的堆疊,而不僅僅是最新的堆疊。

技術教育幫助團隊選擇正確的堆疊,而不僅僅是最新的堆疊。在高品質部署中,這會轉化為可衡量的操作規則、所有權邊界和定期審查儀式,以便團隊可以增強信心,而不是擴大模糊性。

更好的工程選擇可以減少生產中的可靠性事故。

更好的工程選擇可以減少生產中的可靠性事故。在高品質部署中,這會轉化為可衡量的操作規則、所有權邊界和定期審查儀式,以便團隊可以增強信心,而不是擴大模糊性。

ML 工作負載的 Kubernetes 的未來

期待更緊密的 ML 整合:群組調度會立即啟動所有分散式訓練 Pod,或完全不啟動;部分和時間切片 GPU 共享,以便多個輕量作業共享一張卡;以及尊重快速 NVLink 互連的拓撲感知佈局。 Kubernetes 上的無伺服器推理(將請求之間的端點擴展到零)正在成熟。隨著模型的膨脹,調度程式越來越多地跨多個叢集和雲端進行協調,Kueue 和 Volcano 等基於佇列的公平共享系統正在成為管理稀缺 GPU 容量的標準。

現實世界的實施

研究實驗室使用 Kubeflow Training Operator 在四個節點上啟動 32-GPU PyTorch 分散式訓練作業,然後在收斂時自動釋放 GPU。

一家電子商務公司透過 KServe 提供其推薦模型,該模型會在閃購期間自動擴展副本,並在一夜之間回落。

一家銀行以 Kubernetes CronJobs 的形式運行夜間批次評分作業,將它們在備用 CPU 節點上排隊,這樣它們就不會與白天的服務流量競爭。

一家新創公司使用 Kubernetes 上的 Ray 來運行並行超參數掃描,在現場實例上啟動數十個短期試用 Pod 以降低成本。

實施模式

ML 工作負載的 Kubernetes 實踐

研究實驗室使用 Kubeflow Training Operator 在四個節點上啟動 32-GPU PyTorch 分散式訓練作業,然後在收斂時自動釋放 GPU。

研究實驗室使用 Kubeflow Training Operator 在四個節點上啟動 32-GPU PyTorch 分散式訓練作業,然後在收斂時自動釋放 GPU。當團隊預先定義品質閾值、為邊緣情況保留人工升級路徑並隨著時間的推移追蹤生產力增益和錯誤成本時,通常會獲得更好的結果。

ML 工作負載的 Kubernetes 實踐

一家電子商務公司透過 KServe 提供其推薦模型,該模型會在閃購期間自動擴展副本,並在一夜之間回落。

一家電子商務公司使用 KServe 為其推薦模型提供服務,該模型會在限時搶購期間自動擴展副本並在一夜之間回落。當團隊預先定義品質閾值、為邊緣情況保留人工升級路徑並隨著時間的推移追蹤生產力增益和錯誤成本時,通常會得到更好的結果。

ML 工作負載的 Kubernetes 實踐

一家銀行以 Kubernetes CronJobs 的形式運行夜間批次評分作業,將它們在備用 CPU 節點上排隊,這樣它們就不會與白天的服務流量競爭。

一家銀行以 Kubernetes CronJobs 的形式每晚執行批次評分作業,將它們在備用 CPU 節點上排隊,這樣它們就不會與白天的服務流量競爭。當團隊預先定義品質閾值、為邊緣情況保留人工升級路徑並隨著時間的推移追蹤生產力增益和錯誤成本時,通常會得到更好的結果。

ML 工作負載的 Kubernetes 實踐

一家新創公司使用 Kubernetes 上的 Ray 來運行並行超參數掃描,在現場實例上啟動數十個短期試用 Pod 以降低成本。

一家新創公司使用 Kubernetes 上的 Ray 來運行並行超參數掃描,在現場實例上啟動數十個短期試用 Pod 以降低成本。當團隊預先定義品質閾值、為邊緣情況保留人工升級路徑並隨著時間的推移追蹤生產力增益和錯誤成本時,通常會獲得更好的結果。

風險與防護欄

!

優化一項基準測試可以隱藏更廣泛的系統弱點。

!

基礎設施和維護成本常常被低估。

!

隨著系統變得更加複雜,安全性和可觀察性差距可能會擴大。

實施路線圖

1

在實施之前定義延遲、品質和成本目標。

在實施之前定義延遲、品質和成本目標。將每個步驟視為證據門:如果不符合標準,則暫停推出,縮小差距,然後再擴大使用。

2

在實際負載和資料條件下進行基準測試。

在實際負載和資料條件下進行基準測試。將每個步驟視為證據門:如果不符合標準,則暫停推出,縮小差距,然後再擴大使用。

3

儀器監控錯誤、漂移和使用者影響。

儀器監控錯誤、漂移和使用者影響。將每個步驟視為證據門:如果不符合標準,則暫停推出,縮小差距,然後再擴大使用。

4

在擴展之前準備回滾和事件回應路徑。

在擴展之前準備回滾和事件回應路徑。將每個步驟視為證據門:如果不符合標準,則暫停推出,縮小差距,然後再擴大使用。

不斷探索