Kelpflux：Slurm on Kubernetes 的 GPU 工作負載智慧排程

共享 GPU 叢集，為什麼還會等？

同一個叢集同時跑推論、訓練和資料前處理時，GPU 使用率變高不代表工作就排得好。短工作可能被長工作擋住，節點縮容也可能在沒有保存狀態時打斷訓練。Kubernetes 擅長容器與彈性伸縮，Slurm 擅長批次工作、資源分配和隊列；問題是兩者的強項沒有自然接在一起。

我把問題收斂成一個可操作的系統：研究者仍然用熟悉的 sbatch 送出工作，平台則把 Slurm 放在 Kubernetes 上，讓 CPU、GPU worker pool 能依需求伸縮。GPU 共享用 MPS 處理，節點退出時把 checkpoint 納入 draining 條件，並用 Prometheus 追蹤佇列和叢集狀態。

讓排程決策留在可退回的路徑上

從 sbatch 提交、策略服務回退到 Slurm GPU 放置的關係如圖所示。

排程策略不是另起一套會阻塞提交的控制面。job_submit.lua 呼叫策略服務取得建議，逾時或回傳無效時退回啟發式排程。模擬器讓策略同時學習「選哪個工作、放到哪張 GPU」；實機介接則只調整工作優先順序，GPU 放置仍交給 Slurm。這個差別很重要：論文中的聯合動作空間不能直接當成實機已接管 GPU 放置的證據。

這個專案的重點是把訓練出的策略放進能運作的 HPC 平台：彈性 CPU／GPU 資源、MPS 共用、checkpoint-aware draining，以及 Prometheus 觀測要一起成立。單獨在模擬器裡得到較好的排序，還不能說明實機上的工作真的會更快完成。

數字成立的條件

論文以 RTX 4070 與 RTX 3080 組成異質 2-GPU 測試叢集；每組負載用 10 個隨機種子、每個種子 150 個工作，混合 BERT 推論、ResNet 訓練、Qwen 微調和 cuBLAS。下表是平均工作完成時間（JCT，秒；越低越好），不是單次最佳成績：

以逐種子比較計算，中、重度負載的平均 JCT 改善約 8.1–12.0%；論文的統計檢定也支持這兩組負載的差異。輕度負載則不能一概而論：四種學習策略中只有 RDSAC-CVaR 達統計顯著。這份研究成果獲 TANET 2026 接受，但目前證據只涵蓋上述小型異質叢集與工作分布。

平均值變好，也不代表每個工作都更快：中、重度負載下，學習策略的 P99 完成時間都高於 Backfill，公平性指標也由約 0.8 降至約 0.7。實機決策延遲平均約 0.19 毫秒，約 12% 的決策因低信心走回退路徑；這說明策略能接進提交流程，卻不能替長尾與公平性背書。下一步應把等待最久的工作與使用者公平性放進目標，而不只優化平均 JCT。

我會留下的研究習慣

我會先把控制邊界、失效路徑和可觀測指標寫清楚，再討論模型是否有效。Kelpflux 讓我把「提出一個排程策略」推進到「在實機上比較，並能解釋結果只在哪些條件下成立」。

完整系統與研究材料見 Kelpflux 原始碼。