面向大規模 AI 訓練與推理的企業級基礎設施
現代 AI 工作負載需要專為該用途打造的基礎設施，並能從單臺 GPU 工作站擴充套件到數百個互聯節點。Workstation AI 提供工具、架構與專業能力，用以設計、部署和管理由 Kubernetes 編排的 GPU 叢集，讓您的團隊把精力放在模型開發上，而不是基礎設施的複雜性上。
GPU 叢集架構概覽
設計良好的 GPU 叢集結合高效能運算節點、高速互連、共用儲存與智慧編排。了解其架構，是建立可靠 AI 基礎設施的基礎。
- 每個運算節點通常容納 4 至 8 顆 GPU（NVIDIA A100、H100 或 L40S），透過 NVLink 或 NVSwitch 連接，節點內通訊頻寬最高達 900 GB/s。
- 專用的管理平面負責作業排程、資源分配、健康監控與使用者存取控制，讓資料平面能專心處理訓練流量。
- 頭節點是使用者提交作業、存取 Jupyter 環境及使用 MLOps 工具的入口，且不佔用 GPU 資源。
- InfiniBand HDR（200 Gbps）或 RoCE v2 等高速網路架構連接各節點以進行分散式訓練，將梯度同步延遲降至最低。
- 共用平行檔案系統（Lustre、GPFS 或 BeeGFS）提供大規模資料集 I/O 所需的吞吐量，避免造成儲存瓶頸。
適用於 AI 工作負載的 Kubernetes
Kubernetes 已成為 AI 基礎設施事實上的編排器，提供宣告式資源管理、自動擴展，以及豐富的 GPU 感知元件生態系。
- ✓NVIDIA GPU Operator 可在所有節點上自動部署 GPU 驅動程式、容器工具組、裝置外掛程式與監控匯出器，免除手動管理驅動程式。
- ✓Kubernetes 裝置外掛程式將 GPU 資源暴露給排程器，實現細緻的配置，例如要求特定 GPU 型號、MIG（Multi-Instance GPU）切片，或分時共用存取。
- ✓包含 bin-packing、拓樸感知放置與 gang scheduling 在內的自訂排程政策，確保多 GPU 工作落在互連拓樸最佳的節點上。
- ✓以命名空間為基礎的資源配額與優先順序類別，讓團隊共用叢集，同時確保正式環境推論工作負載的 SLA 優先於實驗性訓練執行。
- ✓整合 Volcano 或 Apache YuniKorn，可提供專為 AI 與 HPC 工作負載打造的批次排程功能，支援公平分享佇列與作業搶佔。
GPU 叢集上的 MLOps 管線
端到端的 MLOps 管線將原始資料轉化為已部署的模型，並在每個階段都具備完整的可重現性、版本控管與可觀測性。
- ✓資料擷取與前處理管線在 CPU 節點上以 Apache Spark 或 Dask 執行，並將清理完成的資料集送入共用儲存，供 GPU 訓練階段使用。
- ✓MLflow 或 Weights & Biases 等實驗追蹤平台會擷取超參數、指標與產出物，讓數百次訓練執行之間的比較可以重現。
- ✓分散式訓練框架（PyTorch DDP、DeepSpeed、Horovod）協調跨多張 GPU 與多個節點的梯度更新，並由 Kubernetes 管理 Pod 的放置與生命週期。
- ✓模型登錄庫以中繼資料與血統為訓練後的模型進行版本控管，並整合 CI/CD 管線，自動化驗證、A/B 測試與金絲雀部署。
- ✓以 Triton Inference Server、vLLM 或 KServe 提供推論服務，具備動態批次處理、模型組合，以及依請求負載自動調整 GPU 規模，帶來低延遲的預測。
分散式 AI 的網路
網路效能往往是分散式訓練的瓶頸。選擇合適的網路架構與設定，對擴展效率至關重要。
- ✓InfiniBand HDR/NDR 搭配 RDMA，提供最低延遲與最高頻寬（每埠 200-400 Gbps），非常適合 64 個以上節點的大規模訓練。
- ✓RoCE v2（RDMA over Converged Ethernet）是具成本效益的替代方案，可在標準乙太網路交換器上運行，同時仍支援 RDMA 以降低 CPU 負擔。
- ✓網路拓樸很重要：胖樹與軌道最佳化設計可將超額訂閱降至最低，而 NVIDIA 的 SHARP 協定則將集合運算卸載到網路交換器本身。
- ✓在 Kubernetes 環境中，Multus CNI 讓 Pod 可同時連接主要叢集網路與供訓練流量使用的次要高速 RDMA 網路。
- ✓使用 SR-IOV 虛擬功能的網路隔離，讓每個訓練 Pod 直接存取網路介面卡硬體，繞過核心堆疊以達到線速效能。
AI 工作負載的儲存解決方案
AI 工作負載的儲存需求多元：訓練資料需要高吞吐量的平行讀取、檢查點需要低延遲存取，資料集與產出物則需要持久的物件儲存。
- ✓NFS 仍是較小型叢集與共用家目錄的實用選擇，但其吞吐量限制，使其在超過數個節點後不適合作為主要的訓練資料儲存。
- ✓Ceph 提供統一的儲存平台，涵蓋區塊（RBD）、檔案（CephFS）與物件（RGW）介面，可橫向擴展至 PB 等級，並內建複寫與抹除編碼。
- ✓Longhorn 是輕量級的 Kubernetes 原生儲存方案，提供複寫式區塊儲存，非常適合較小型 GPU 叢集中的模型檢查點與持久性磁碟區。
- ✓使用 Alluxio 或 JuiceFS 的高效能快取層，可彌補速度較慢的物件儲存（相容 S3）與 GPU 資料載入器吞吐量需求之間的落差。
- ✓分層儲存策略不可或缺：運算節點上以快速 NVMe SSD 處理暫存與檢查點，以平行檔案系統處理使用中的資料集，並以冷物件儲存做封存。
監控 GPU 使用率
掌握 GPU 健康狀態與使用率，對於最大化基礎設施投資報酬，以及在影響訓練執行之前找出效能瓶頸至關重要。
- ✓DCGM（Data Center GPU Manager）Exporter 會收集超過 50 項 GPU 指標，包括 SM 使用率、記憶體頻寬、溫度、耗電量與 ECC 錯誤計數，供 Prometheus 擷取。
- ✓Grafana 儀表板提供每顆 GPU、每個節點與每項工作的即時與歷史使用率檢視，讓團隊找出閒置資源並調整合適的配置規模。
- ✓針對 GPU 記憶體使用率、熱節流與 Xid 錯誤設定警示，可進行預防性維護，避免硬體故障中斷長達數日的訓練。
- ✓與 Kubernetes 指標（kube-state-metrics）整合，可將 GPU 使用率與 Pod 排程決策關聯起來，協助管理員最佳化裝箱與節點池規模。
- ✓依命名空間或團隊以 GPU 小時指標進行成本歸屬，可建立內部分攤模式，鼓勵有效率地使用資源，並為基礎架構擴充提供依據。
從工作站擴展到資料中心
依您的 AI 目標選擇合適的規模。每個層級都建立在前一層之上，Workstation AI 並提供各層級之間的遷移路徑。
| 層級 | GPU | 使用場景 | 網路 | 儲存 | 編排 |
|---|---|---|---|---|---|
| 單台工作站 | 1-2 顆 GPU | 原型開發、小型模型微調、推論開發 | PCIe / NVLink | 本機 NVMe SSD | Docker / Docker Compose |
| 小型叢集 | 8-32 個 GPU（2-4 個節點） | 最高 7B 參數的模型訓練、多模型推論服務 | 25-100 GbE / RoCE v2 | NFS / Longhorn | K3s / MicroK8s |
| 中型叢集 | 32-128 個 GPU（4-16 個節點） | 訓練 7B-70B 參數模型、大規模正式環境推論 | InfiniBand HDR 200G | Ceph / BeeGFS | Kubernetes + GPU Operator |
| 大型叢集 | 128-1000+ 顆 GPU（16-128 個節點） | 基礎模型訓練、多租戶 AI 平台 | InfiniBand NDR 400G | Lustre / GPFS + 物件儲存 | Kubernetes + Volcano + Slurm |
端到端 MLOps 流水線
From data ingestion to model serving, a well-architected MLOps pipeline on Kubernetes automates every stage of the machine learning lifecycle.
Data Ingestion
Preprocessing
Distributed Training
Experiment Tracking
Model Registry
Inference Serving