企業 AI 資料中心建置研究 (六)：AI 叢集的軟體大腦 —— Kubernetes、Slurm 與 Ray
此篇文章探討硬體建置完成後，該如何調度 AI 算力。解答企業 IT 最常問的問題：「現有的 K8s 團隊能直接管理 AI 叢集嗎？」並解析 Slurm、K8s 與 Ray 的架構分工。
WRITTEN BY
- Name
- Harry Chang
一、 背景與核心發現
在解決了電力、散熱 【AI 040】 與底層網路後，AI 工廠的硬體拼圖已經全部就位。接下來，IT 部門面臨的是「軟體調度 (Orchestration)」的問題：當資料科學家想要跑一個需要 512 張 GPU 的訓練任務時，他該怎麼把任務丟給機房？
許多企業直覺的想法是：「我們公司早就全面容器化了，原本的 DevOps 團隊非常熟悉 Kubernetes (K8s)，直接用 K8s 來管理 GPU 叢集就好啦！」
此篇文章的核心發現為：這是一個極度危險的誤區。 Kubernetes 天生是為了「微服務」設計的，而 AI 訓練屬於「高效能運算 (HPC)」的範疇。如果硬拿原生的 K8s 來排程大型 AI 訓練，不僅會導致 GPU 嚴重的閒置與死鎖，還會讓除錯變得異常困難。目前在企業 AI 架構中，Kubernetes、Slurm 與 Ray 正在形成一種「互補而非取代」的全新堆疊架構。
二、 為什麼原生 Kubernetes 管不好 AI 訓練？
要理解 K8s 的局限，必須先了解「微服務」與「AI 訓練任務」在基因上的根本差異。
- 容錯邏輯不同 (獨立 vs 幫派)：
- K8s (微服務)：假設你開了 10 個網頁伺服器容器 (Pod)，其中 1 個當機了，K8s 會自動把它重啟。剩下的 9 個還是能正常服務客戶。
- AI 訓練 (幫派調度 Gang Scheduling)：大模型訓練是「同進同退」的。如果你需要 512 張 GPU，你必須「同時」拿到 512 張才能開始算。如果只拿到 511 張，程式根本跑不動。如果訓練到一半有 1 張卡壞了，剩下的 511 張也不能繼續算，必須全部停下來退回上一個 Checkpoint。原生的 K8s 並不懂這種「不給全就拉倒 (All-or-Nothing)」的調度邏輯。
- 生命週期不同 (常駐 vs 批次)： K8s 擅長管理「永遠不關機」的服務 (Long-running services)。但 AI 訓練是一個「批次任務 (Batch Job)」，跑了三個禮拜算完後就結束了，必須立刻把昂貴的 GPU 釋放給下一個排隊的人。K8s 原生的排隊系統 (Queueing) 對於複雜的 GPU 資源搶佔與優先級分配非常薄弱。
三、 Slurm：超級電腦老將的復興
既然 K8s 不好用，那 AI 巨頭們都在用什麼？答案是一個早在 AI 爆發前就存在多年的 HPC 系統：Slurm。
Slurm (Simple Linux Utility for Resource Management) 一直是全球超級電腦 (Top500) 最愛用的排程器。
- 為 Batch 與 Gang Scheduling 而生：它天生就懂「排隊」跟「要馬全給、要馬不給」。資料科學家只要寫一個腳本：「我需要 64 個節點、每個節點 8 張 GPU、跑 7 天」，Slurm 就會把它放進佇列，等資源一空出來，立刻完美地鎖定 512 張 GPU 讓任務啟動。
- NVIDIA 的黃金標準：NVIDIA 內部的巨型叢集 (如 Selene、Eos)，以及對外販售的 Base Command Manager 軟體，底層深度依賴 Slurm。如果你買了整座 DGX SuperPOD，原廠給你的預設大腦就是 Slurm。
四、 Ray：分散式運算的萬能膠水
如果底層交給了 Slurm 或 K8s，那上層寫 Python 的資料科學家怎麼辦？難道他們要為了不同的機房，去學怎麼寫 K8s YAML 檔或是 Slurm 的 sbatch 腳本嗎？
這時，Ray 崛起了（由 UC Berkeley 開發，商用公司為 Anyscale，OpenAI 訓練 ChatGPT 的核心框架）。
Ray 的定位是「分散式應用的運算層」，它卡在「開發者」與「底層排程器」之間。
- 對開發者來說：你只要在 Python 程式碼加上
@ray.remote，Ray 就會自動把你的函數丟到幾千台機器上去平行運算。開發者感覺就像在用一台有一萬顆 CPU 的超級筆電。 - 對基礎設施來說：Ray 可以順利地安裝在 K8s 之上 (KubeRay)，也可以跑在 Slurm 之上。它把底層硬體的複雜性給「屏蔽」掉了。
圖解：企業 AI 叢集軟體堆疊架構
五、 企業行動建議 (Action Items)
針對軟體調度層的選擇，企業 IT 團隊應採取以下分工策略：
- 純 AI 研發中心 / 大型預訓練：選擇 Slurm 如果這個機房 100% 只用來做 AI 模型訓練（例如買了幾百張 GPU 專門練大語言模型），請果斷讓 IT 團隊學習 Slurm。不要硬用 K8s，這會省下無數排解 GPU 死鎖與網路拓撲問題的時間。
- 混合 IT 環境 / 推論服務：選擇 K8s + 外掛 (Volcano) 如果 GPU 資源需要跟公司現有的網頁 API、資料庫共用，或者主要任務是「模型推論 (Inference)」，那麼繼續使用 Kubernetes 是對的。但務必幫 K8s 安裝專門針對 AI 設計的 Batch 排程外掛（例如開源的 Volcano 或 YuniKorn），補足 K8s 缺乏的 Gang Scheduling 能力。
- 無條件導入 Ray 作為運算中介層 強烈建議讓資料科學家團隊熟悉 Ray 框架。一旦 AI 團隊的程式碼是基於 Ray 撰寫的，未來無論公司的底層機房要從 K8s 搬到 Slurm，還是從地端搬到公有雲，程式碼都不需要大幅修改，實現真正的「算力自由」。
延伸探討： 軟體與硬體都準備就緒後，企業即將面臨最大的靈魂拷問：「我們到底需要買多少張 GPU？」做一個 RAG 系統跟從頭預訓練一個 LLM，算力需求差了多少倍？下一篇文章 【AI 042】 將為你拆解不同 AI 任務場景的算力需求與採購指南。