前言：為什麼 AI 時代的 Kubernetes 不一樣？
這幾年 AI 跟大型語言模型的浪潮席捲整個 IT 產業，不管是企業、研究機構還是學校，對高效能運算的胃口越來越大。而 Kubernetes 已經從單純的容器編排工具，搖身一變成了 AI 資料中心的標準底座。不過說實話，K8s 在面對 AI 工作負載時，絕對不是開箱即用那麼簡單——計算、儲存、網路、調度，每個層面都有不少眉角要處理。
我自己在實務中也碰過不少坑，今天就從工程師最熟悉的「計算、儲存、網路」三大面向，加上調度這個關鍵環節，來聊聊跑 AI 大模型的 K8s 叢集，跟我們平常用的那種通用型 K8s 到底差在哪裡。
計算層面：GPU 異質資源的管理挑戰
標準的 Kubernetes 在調度容器時，主要就看兩個東西：CPU 跟記憶體。容器說「我要 2 核 CPU + 4GB RAM」，K8s 就去找符合條件的節點把它放上去，邏輯非常單純。
但問題來了——AI 工作負載需要 GPU，而 K8s 原生根本不認識 GPU 這種「異質資源」。它不知道節點上有幾張卡、每張卡的顯存多大、算力如何分配。
K8s 社群也很清楚，異質硬體種類繁多（GPU、NPU、FPGA、RoCE 網卡等等），不可能每種都自己開發支援。所以他們設計了 Device Plugin 這個插件框架，讓硬體廠商自己實作對接邏輯，即時回報節點上 GPU 的使用狀況，協助 K8s 做出正確的調度決策。
| GPU 管理模式 | 說明 | 適用場景 |
|---|---|---|
| 整卡分配 | 每個容器獨佔 1 張 GPU | 大模型訓練、高效能推理 |
| vGPU 切分 | 1 張 GPU 虛擬化為多個 vGPU，分配給不同容器 | 推理服務、開發測試環境 |
| MIG (Multi-Instance GPU) | A100 以上支援硬體級切分，顯存與算力完全隔離 | 多租戶共享、混合工作負載 |
| 多容器共享 | 多個容器分時共用同一張 GPU | 離峰利用率優化 |
值得一提的是，K8s 從 1.27 版本開始引入了 DRA（Dynamic Resource Allocation）框架，允許更靈活的動態資源切分。在 2026 年的 KubeCon Europe 上，NVIDIA 更是將其 DRA 驅動程式捐贈給了 CNCF，這代表 GPU 資源管理正在從各家自幹的 Device Plugin 時代，走向更標準化的未來。不過目前多數生產環境仍以 Device Plugin 為主流做法。
另外還有一個容易被忽略的坑：K8s 的異質資源調度框架規定資源分配必須是整數。也就是說容器可以要 1 張 GPU，但不能要 0.5 張。如果想實現多個容器共用一張 GPU（比如白天跑推理、晚上跑訓練），Device Plugin 的邏輯就得再往上疊加不少複雜度。
儲存層面：大規模訓練資料的就近快取
K8s 本身其實不直接管儲存，它管的是容器「怎麼接上」儲存——透過 PV/PVC 機制，讓容器裡的程式可以像存取本地檔案一樣使用遠端儲存。
但 AI 訓練場景的儲存需求跟一般應用完全不在同一個量級。訓練資料集動輒幾百 TB，而且訓練是多輪迭代的過程——每個 epoch 結束後，模型需要重新從檔案系統載入資料進行下一輪訓練。
| 儲存方案 | 特點 | 瓶頸 |
|---|---|---|
| 遠端物件儲存 (如 S3/OBS) | 容量大、成本低 | 每個 epoch 重新讀取延遲極高 |
| 分散式快取系統 | 利用節點本地 NVMe 快取資料 | 需額外部署與維運 |
| 本地化儲存 (如 HwameiStor) | 資料就近存取、低延遲 | 容量受限於本地磁碟 |
想像一下 100TB 的訓練資料，每個 epoch 都得從遠端 OBS 桶重新讀一遍，光 I/O 等待就能讓 GPU 閒置大半時間。所以「如何把大量樣本資料就近快取」就成了 AI + K8s 架構中必須認真對待的課題。
常見的做法是部署分散式快取加速系統，利用伺服器本身自帶的高速 NVMe 本地碟來快取訓練資料，並透過分散式檔案系統達到全量快取的效果。這樣在多輪訓練中，樣本資料的讀取速度可以大幅提升，直接加快整體訓練進度。
網路層面：RDMA 參數面網路的必要性
標準 K8s 的網路模型裡，每個容器就一張 eth0 網卡、一個網路平面，不管是 overlay 還是 underlay，解決的都是「能不能通」的問題。
但大規模分散式訓練完全是另一回事。百億、千億參數的大模型在訓練時，梯度參數需要在多個節點之間高速交換。如果走普通的 TCP/IP 乙太網路，光是參數同步的通訊開銷就能拖垮整個訓練效率。
這時候就需要 RDMA（Remote Direct Memory Access）網路登場了。RDMA 的核心優勢在於：
- 繞過 TCP/IP 協定棧，減少軟體層的處理延遲
- 不需要 CPU 介入，直接從網卡硬體進行資料傳輸
- 網路傳輸效能大幅提升，顯著加快訓練參數的交換速度
所以在 AI 叢集中，除了底層的容器通訊網路之外，還會多出一條「參數面」網路。一般基於成本考量會採用 RoCE（RDMA over Converged Ethernet）方案——用 IB 網卡搭配一般乙太網路交換器來實現，而非使用昂貴的 InfiniBand 專用交換器。
| 網路類型 | 用途 | 關鍵技術 |
|---|---|---|
| 容器網路（資料面） | 容器間基本通訊 | CNI (Calico/Cilium/Spiderpool) |
| RDMA 網路（參數面） | 訓練參數梯度同步 | RoCE + PFC 流控 + NCCL |
不過 RDMA 協定有個硬需求：網路必須是無損的，否則效能會斷崖式下降。要在乙太網路上實現無損傳輸，就需要引入 PFC（Priority-Based Flow Control）流控機制，而且交換器端跟伺服器的 RoCE 網卡端都要同時配置，調優的複雜度比一般網路高出不少。
更進一步，RoCE 網卡本身也是一種異質資源，同樣需要透過 Device Plugin 來管理。而且 GPU 跟 RoCE 網卡之間存在硬體拓撲的親和性——必須把物理位置相近的 GPU 和網卡配對使用，才能發揮最佳效能。這又給調度層增加了額外的複雜度。
調度層面：Gang Scheduling 與資源死鎖
標準 K8s 的調度邏輯是一次處理一個 Pod：拿一個容器、找到合適的節點、放上去、再處理下一個。但分散式 AI 訓練不是這樣運作的。
一個分散式訓練任務通常由一組容器組成，它們必須同時啟動才能進行集合通訊（AllReduce 等），這就是所謂的 All-or-Nothing 原則，也叫 Gang Scheduling。
如果沒有 Gang Scheduling 會怎樣？想像兩個大型訓練任務各需要 4 張 GPU，叢集總共 6 張。任務 A 先搶到 3 張，任務 B 也搶到 3 張，結果兩個任務都湊不齊需要的資源，誰都跑不起來——經典的資源死鎖。
| 調度框架 | 核心能力 | 補充功能 |
|---|---|---|
| Volcano | Pod-group 組調度、Gang Scheduling | SSH 免密登入、MPI Hostfile |
| Kueue (K8s SIG) | 佇列式資源管理、公平調度 | 多租戶資源配額、優先級搶佔 |
| KAI Scheduler (NVIDIA) | Gang Scheduling + Bin-packing | GPU 拓撲感知、碎片整理 |
2026 年值得關注的是 NVIDIA 開源的 KAI Scheduler，它作為 kube-scheduler 的補充調度器運行，專門處理 GPU AI 工作負載。除了 Gang Scheduling 之外，它還實現了 bin-packing 策略——盡量把工作負載集中到最少的節點上，保留連續的 GPU 區塊給大型多卡任務使用。根據 CNCF 成員組織的實測數據，進階 GPU 調度可以將利用率從 13% 提升到 37%，部分場景甚至突破 80%。
總結：AI 叢集的四大差異化競爭力
Kubernetes 已經是 AI 資料中心的標準底座，這點毫無疑問。但 AI 基礎設施的硬體成本極為高昂（一條 200Gb 的參數面網路線就要好幾千元，一台 8 卡 GPU 伺服器更是動輒百萬以上），所以提升資源利用率就成了投資報酬率最高的切入點。
| 優化方向 | 具體做法 | 效果 |
|---|---|---|
| 調度增強 | Gang Scheduling、Bin-packing、佇列管理 | 減少資源死鎖與碎片化 |
| GPU 虛擬化 | vGPU/MIG 切分、多容器共享 | 提升 GPU 整體利用率 |
| 儲存加速 | 分散式快取、本地化儲存 | 減少 I/O 等待、加快訓練迭代 |
| 網路加速 | RDMA/RoCE 參數面網路 | 加速模型參數同步 |
從我個人的經驗來看，要把一個 AI 平台的底層做好，光是 Kubernetes 本身的複雜度就不小了，再加上 GPU 管理、高速網路、分散式儲存這些額外的維度，所需投入的工程量確實可觀。但反過來說，這也正是技術團隊可以建立差異化競爭力的地方。
如果你也在建設 AI 基礎設施，歡迎留言交流你的踩坑經驗。
發佈留言