別只盯著 GPU:AI 平臺工程真正的挑戰是異質基礎設施
CNCF Blog · 2026-09-04
CNCF Blog 於 2026-09-04 刊出 Vultr 工程師 Kasia Hilborne 的文章,主張 AI 基礎設施規劃若只圍繞 GPU 打轉,會漏掉整條 pipeline 裡其餘資源的協調問題。文章舉出一條典型路徑:資料 → CPU 前處理 → GPU 推論 → CPU 後處理 → 應用程式,說明 GPU 的實際吞吐量其實取決於前後兩端 CPU 階段的效率。
原本的問題
多數團隊規劃 AI 叢集時,採購決策幾乎只看 GPU 型號與數量,卻忽略資料前處理、tokenization、檢索、orchestration 與後處理這些階段同樣吃資源。GPU 利用率偏低往往不是 GPU 本身的問題,而是上游 CPU 準備資料的速度跟不上,或下游後處理造成佇列堆積。文章指出,只監控 GPU 使用率的觀測方式,會讓團隊看不到真正的瓶頸出在管線的哪一段。
採用的方法
文章把 Kubernetes 定位為協調這些異質資源的共同 orchestration 層,讓 CPU、GPU、記憶體、儲存與網路都能用同一套宣告式模型管理。舉例來說,Dynamic Resource Allocation(DRA)透過 KEP-4381 擴充了 Kubernetes 的資源模型,讓工作負載能以宣告式方式請求特定裝置,不必再依賴節點層級的裝置設定。DRA 本身不是重點,重點是方向:專用運算資源正逐漸被納入跟其他應用程式相同的雲原生資源模型裡。DRA 自 v1.30 進入 alpha,並在 v1.35 成為穩定且無法關閉的內建功能。
| 比較項目 | Device Plugin API | DRA(resource.k8s.io) |
|---|---|---|
| 裝置篩選 | 僅能依數量 | 以 CEL 表示式做細粒度屬性篩選 |
| 裝置共享 | 每個 container 各自請求,不可共享 | 多個 container/Pod 可共享同一資源 |
| 設定層級 | 綁定在節點上設定 | 依工作負載個別設定 |
| 核心物件 | 無集中分類 | DeviceClass、ResourceClaim、ResourceSlice 集中管理 |
影響範圍
當專用裝置的請求方式跟一般資源一致後,平台團隊需要的是能橫跨整條管線的觀測能力,把基礎設施 telemetry 跟應用程式 telemetry 對應起來,而不是只盯著加速器的使用率數字。資源配對必須依管線階段分工:CPU 負責資料準備、檢索與應用邏輯,GPU 負責高度平行的訓練與推論,記憶體、儲存與網路則負責讓資料與產出物順暢流動。
Kubernetes 沒有變難,是 AI 工作負載讓它重新令人生畏
CNCF Blog · 2026-09-04
同日,Fairwinds 技術長 Andy Suderman 在 CNCF Blog 發表文章,指出即使 Kubernetes 基礎設施已經成熟,團隊一旦把訓練與推論工作負載搬上去,仍會感受到像是在學一套全新維運紀律的落差感。作者把這種感覺類比成第一次從 Windows 換成 Linux:平台本身沒有變難,難的是要重新建立起一整層維運紀律。
原本的問題
文章列出幾個讓團隊重新感到陌生的具體場景:
- GPU 資源閒置卻持續計費,缺乏自動釋放機制
- 訓練工作帶來的 bursty traffic,和一般 web 流量的擴縮邏輯不同
- 推論服務需要乾淨的擴縮與自動復原,失敗不能只靠人工介入
- 資料管線的一致性要跟應用程式堆疊同步維護
- 實驗性工作失敗時,需要 guardrails 防止拖垮共享叢集的穩定性
- 資料存取需要額外的安全邊界
用受管服務起步門檻很低,像 GKE、AKS、EKS 都能讓團隊很快跑出第一個叢集,但這解決的只是「有沒有 Kubernetes 可用」,不是「AI 工作負載能不能穩定跑在生產環境」。
影響範圍
作者認為問題核心從基礎設施架設轉移到日常治理:資源配置、成本控制與平台穩定性都需要持續介入,而不是架好叢集就結束。job 排程位置、GPU 使用率監控與跨團隊的資源邊界,變成維運團隊每天要處理的例行事項,而非上線前一次性的規劃項目。
原始來源:CNCF Blog