如何用K8S Kueue & Cohort 有效的管理GPU/CPU資源 ?

#kubernetes #nvidia #devops

如何用K8S Kueue & Cohort 有效的管理GPU/CPU資源 ?

在常見的AI 工作環境中，我們常需要在同一個 K8s 叢集上，同時運行給醫師使用的即時臨床推論 API，同時也要因應醫院內AI…

UpdatedMarch 24, 2026•2 min read

J JhihHao Wu **近期研究重點包含 AI Agent 的供應鏈攻擊、PII 偵測模型評估，以及醫療 AI 在臨床流程中的安全落地。

在這裡，我分享深度技術實測報告（如 NVIDIA NeMo, WildGuard）與職場技術成長心得，致力於在 AI 浪潮中打造具備資安韌性的解決方案。

On this page

如何用K8S Kueue & Cohort 有效的管理GPU/CPU資源 ?Cohort — 制定全院預算與共享規則階層式資源池 (Hierarchical Cohorts)以業務優先級來給資源？ClusterQueue — 處理任務的「檢傷分級」1. 資源運用等級之分 2. 排隊策略 (Queueing Strategy) — 急診室 vs. 門診 3. 緊急手術的搶佔 (Preemption)

如何用K8S Kueue & Cohort 有效的管理GPU/CPU資源 ?

在常見的AI 工作環境中，我們常需要在同一個 K8s 叢集上，同時運行給醫師使用的即時臨床推論 API，同時也要因應醫院內AI 科學家的模型訓練任務，或是測試團隊的批次測試，而這三者的需求截然不同：一個要求絕對的低延遲，一個需要長時間的大算力，另一個則追求吞吐量，要怎麼有效自動化的分配一直是個滿常見的問題，而解法當然也不只一種，不過我們可以看看原生的 K8S 提供的什麼樣的機制。

Kueue 的哲學核心，就是將您的組織架構與業務優先級，直接映射為資源調度的策略，而方法會圍繞著 Cohort 與 ClusterQueue 這兩個重要的模組。

讓我們用一個大家都能懂的比喻，管理一個 AI 運算叢集，就像管理一間大型綜合醫院。

`Cohort` — 制定全院預算與共享規則

Cohort 像是醫院的管理委員會，不直接接觸病患，但負責制定全院的資源總量，以及各科部（例如：心臟科、神經科）之間的資源共享與優先級規則。

階層式資源池 (Hierarchical Cohorts)

過去在習慣上，每個專案的資源都被鎖死在自己的 Namespace 裡，A 專案閒置的 GPU，B 專案再緊急也無法使用而這件事剛好可以利用 Cohort 來讓資源可以彈性一點

頂層 Cohort (全院總預算)：我們先建立一個 medical-center-wide-gpus 的頂層 Cohort，它持有醫院內所有的 100 張 A100 GPU。
部門 Cohort (科部預算)：在其下，我們根據業務線建立 clinical-division（臨床醫學部）和 research-division（研究部）兩個子 Cohort。

# 全院總資源  
apiVersion: kueue.x-k8s.io/v1beta1  
kind: Cohort  
metadata:  
  name: "medical-center-wide-gpus"  
spec:  
  resourceGroups:  
  - flavors:  
    - name: "nvidia-a100"  
      resources:  
      - name: "nvidia.com/gpu"  
        nominalQuota: 100  

---  
# 臨床醫學部 Cohort  
apiVersion: kueue.x-k8s.io/v1beta1  
kind: Cohort  
metadata:  
  name: "clinical-division"  
spec:  
  parent: "medical-center-wide-gpus"  
  # ... 等等介紹

簡單來看，資源在頂層是流通的。當研究部夜間沒任務時，他們的潛在配額可以被產品部的線上服務完整地使用，GPU 利用率趨近 100%。

以業務優先級來給資源？

當大家都需要資源時，誰該優先？這時候揪該派出fairSharing.weight 登場了，概念上不是要設定資源的上限，而是設定「資源競爭時」的分配策略。

# 臨床醫學部，業務優先級高，權重 75%  
apiVersion: kueue.x-k8s.io/v1beta1  
kind: Cohort  
metadata:  
  name: "clinical-division"  
spec:  
  parent: "medical-center-wide-gpus"  
  fairSharing:  
    weight: "0.6"  
---  
# 研究部，權重 25%  
apiVersion: kueue.x-k8s.io/v1beta1  
kind: Cohort  
metadata:  
  name: "research-division"  
spec:  
  parent: "medical-center-wide-gpus"  
  fairSharing:  
    weight: "0.4"

這樣設定的好處是在沒有門診或是看診的非GPU 競爭時段，研究部可以借用空閒的全部資源，可以利用這樣的空擋來使用GPU處理大規模的測試或是訓練，而在競爭資源時，Kueue 會根據 6:4 的權重，確認輔助臨床決策的GPU與AI模型能優先獲得資源。

`ClusterQueue` — 處理任務的「檢傷分級」

如果 Cohort 是管理委員會，那 ClusterQueue 就是每個科部底下的「檢傷分級中心」，所有運算任務（病患）都在這裡報到、排隊，並被分配到具體的資源（手術室）。

1. 資源運用等級之分

AI 任務對 GPU 的需求各不相同。ClusterQueue 允許我們為 GPU 定義不同的用途，

apiVersion: kueue.x-k8s.io/v1beta1  
kind: ClusterQueue  
metadata:  
  name: "ai-model-training-cq"  
spec:  
  cohort: "research-division"   
  resourceGroups:  
  - coveredResources: ["nvidia.com/gpu"]  
    flavors:  
    - name: "a100-high-end"   # 訓練用  
      resources:  
      - name: "nvidia.com/gpu"  
        nominalQuota: 10     
    - name: "a100-mig-10"     # 推論測試  
      resources:  
      - name: "nvidia.com/gpu"  
        nominalQuota: 20

2. 排隊策略 (Queueing Strategy) — 急診室 vs. 門診

StrictFIFO：嚴格控管先進先出，像預約門診，雖然公平但可能因一個其中一個大任務卡住而導致整個queue效率低下。
BestEffortFIFO (預設)：盡可能的處理任務先進先出，比較像急診室邏輯，如果 1 號重症病患在等待較大的資源，則會先處理 2 號病患的縫合需求（小資源），來讓所有任務的效率最大化。

3. 緊急手術的搶佔 (Preemption)

大部分的Queue設計都會有保障服務品質 (QoS) 的機制，當一個臨床判斷LDCT的 API 請求（最高優先）進來，而資源全滿時，ClusterQueue 會啟動搶佔機制，會自動暫停或終止一個正在運行的低優先級研究任務，釋放 GPU 給臨床的需求使用。

最後讓我們把上面概念串起來

宏觀層 (Cohort)：我們定義了 medical-center-wide-gpus 作為總資源池，下面有 clinical-division (權重 0.6) 和 research-division (權重 0.4) 兩個子 Cohort。

執行層 (ClusterQueue)：

當一個臨床 API 請求進來，而所有 GPU 正被一個大型訓練任務佔用時，Kueue 的決策流程如下：
API 任務進入，發現無資源可用
向 research-division Cohort 求援
Kueue 檢查 medical-center-wide-gpus 的全局使用情況，發現 clinical-division 的實際使用率 (0%) 遠低於其權重 (60%)。
搶佔機制啟動！ Kueue 會從 research-division 的 training-job-cq 中，搶佔一個 GPU。
臨床 API 任務立即獲得資源並執行，服務品質得到保障。