對於許多初入 AI 基礎設施領域的工程師來說，可能會認為 GPU 就像一張大一點的顯示卡，只要把它們塞進伺服器並用 Kubernetes 管理就好。但實際上，當規模達到訓練（Training）或大規模推論（Inference）涉及數百甚至數千顆 H100 或 GB200 時，這已經變成了一場極其複雜的硬體與網路協調戰爭。
在這種環境下，傳統的混沌工程（Chaos Engineering）——例如隨機殺掉一個 Pod 或模擬網路延遲——完全不足以應對。因為 GPU 集群的失效模式與 CPU 集群截然不同，且一次失效造成的金錢損失（硬體成本與算力浪費）極其驚人。
GPU 集群的複雜性來源
在進入混沌工程之前，必須理解 GPU 集群的三個核心複雜度：
第一是拓樸感知調度（Topology-aware Scheduling）。GPU 之間不是簡單的網路連接，而是透過 NVLink 或 InfiniBand 等高速互連技術。物理距離越近，通訊越快。如果一個訓練任務被分散在不同的機架（Rack，效能可能會從 600Gbps 掉到 100Gbps，導致整體訓練速度大幅下降。
第二是硬體變異性（Variability）。即便型號完全相同的 GPU，由於散熱、電壓或製造誤差，效能並不一致。在 Allreduce（一種所有 GPU 共同參與的同步操作）中，整個任務的速度取決於最慢的那顆 GPU（Laggard）。這意味著一顆表現不佳的 GPU 會拖慢整個集群的後腿。
第三是記憶體存取非對稱性（NUMA, Non-Uniform Memory Access）。GPU 物理上連接在特定的 CPU 核心與記憶體通道上。如果調度時將 GPU 分配到不對應的 NUMA 節點，會導致 CPU 與 GPU 之間的資料傳輸必須跨越插槽，造成效能損失甚至高達 40%。
為什麼傳統混沌工程失效？
在傳統的微服務環境中，我們處理的是無狀態（Stateless）工作負載，硬體是廉價且可替換的。但在 GPU 訓練環境中，工作負載是有狀態的（Stateful），模型權重（Weights）巨大，且所有 GPU 必須同步工作。
如果一個節點失效，整個訓練任務通常會直接崩潰，而非像微服務那樣僅僅是部分功能失效。此外，GPU 有其特有的失效模式，例如 XID 錯誤（GPU 的故障碼）、ECC 記憶體位元翻轉（Bit-flip）或熱限速（Thermal Throttling），這些都是傳統 CPU 混沌工具無法模擬的。
GPU 集群的七種故障注入策略
為了建立強韌的 AI 基礎設施，建議從以下七個維度進行故障注入測試：
DCGM 故障注入 利用 NVIDIA 的 DCGM（Data Center GPU Manager）直接向 GPU 注入故障，例如模擬 NVLink 斷線、電源異常或 XID 錯誤。這能測試監控系統是否能即時發現硬體故障，以及調度器能否自動將故障節點剔除。
資源耗盡測試（GPU Burn） 使用 GPU Burn 等工具將 GPU 推至極限，模擬 VRAM 溢位（OOM）或極端高溫。這可以用來測試熱管理系統是否正常，以及當一個 GPU 滿載時，是否會影響同節點的其他任務（Noisy Neighbor 噪聲鄰居效應）。
網路層級故障 針對 RDMA（遠端直接記憶體存取，一種繞過作業系統核心直接讀寫記憶體的技術）進行測試。由於 RDMA 繞過了核心，傳統的 iptables 或 tc 工具失效，必須透過修改 NCCL 環境變數或編寫 eBPF Hooks（一種在核心層級監控與攔截事件的技術）來注入延遲或丟包。
檢查點（Checkpointing）混沌測試 訓練大型模型時，定期儲存狀態（Snapshot）至關重要。測試重點在於：如果非同步快照過程中儲存空間滿了，或者儲存網路發生分區（Partition），訓練任務是否會崩潰，還是能優雅地恢復。
NUMA 錯配測試 透過工具強制將任務分配到不對應的 NUMA 節點，觀察監控系統是否能偵測到這種隱蔽的效能下降（Silent Performance Degradation），而非僅僅看到 GPU 利用率 100% 就認為正常。
拓樸失效測試 模擬單個機架或單個 NVSwitch 失效，驗證集群在失去部分高速互連路徑時，是否能快速重新調度到另一組連續的物理節點上。
變異性壓力測試 故意將任務部署在已知效能較差的 GPU 上，驗證變異性感知調度（Variability-aware Scheduling）是否能正確地將高優先級任務移至高效能節點。
建立可觀測性的反饋迴路
混沌工程的目的不是為了破壞，而是為了驅動可觀測性（Observability）。
正確的流程應該是：注入故障 $\rightarrow$ 檢查監控是否發現 $\rightarrow$ 驗證告警是否觸發 $\rightarrow$ 確認調度器是否自動修復 $\rightarrow$ 優化監控指標。
許多團隊發現，雖然 nvidia-smi 顯示 GPU 正常，但任務速度卻慢了 30%，這就是因為缺乏對 PCIe 頻寬或 NUMA 狀態的監控。透過主動注入故障，工程師可以發現這些監控盲點，並在真正的生產事故發生前補齊指標。
總結
對於管理昂貴 GPU 集群的團隊來說，混沌工程是降低財務風險的必要手段。不要等到數百萬美金的集群因為一顆 GPU 的熱限速而導致訓練停擺時才發現監控不足。建議從 DCGM 故障注入與網路測試開始，逐步建立一套能自動偵測、避開故障節點並快速恢復的韌性基礎設施。
來源：infoq.com - Chaos Engineering GPU Clusters
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。