在大規模 GPU 叢集中，硬體故障是常態。Xid 錯誤、雙位 ECC 錯誤、GPU 從 PCIe 匯流排脫落或 InfiniBand 鏈路抖動，都可能讓分散式訓練任務停滯或使推理副本下線。發現問題往往不難，難的是從故障發生到節點恢復健康之間的所有環節。Together 今年早些時候推出了全自動節點修復功能，現已正式可用，本文詳細拆解其設計和工作原理。
傳統節點自動修復通常只依賴一個訊號：節點變為 NotReady。但 NotReady 無法區分節點是真正故障還是短暫不可達。當儲存或網路事件同時影響多個節點時，所有受影響節點都會變為 NotReady，容易觸發大規模誤替換。因此 Together 的自動修復遵循一條原則：沒有失敗的健康檢查，就不進行節點修復，且每次修復都攜帶支援證據。
整個管道分為四個階段：檢測故障、決定是否及何時行動、修復節點、重新驗證機器。前三個階段在使用者叢集內執行，第四階段在 Together 基礎設施上對騰出的物理主機進行。檢測從 hypervisor 兩側進行：VM 內部透過 exporter 監控核心日誌中的 Xid 和 PCIe 脫落、DCGM 的 ECC 和熱節流指標、Node Problem Detector 的檔案系統只讀等問題；主機側則監控 InfiniBand 鏈路狀態和主機可達性。所有告警都附帶穩定的摘要、通俗描述和機器可讀的證據負載，確保控制台、API 和通知中的資訊一致。
策略層面，平臺負責決定“做什麼”——每個訊號對映到能修復它的最輕量動作；使用者決定“是否做”和“何時做”。在修復選項卡中，自動修復策略預設是“修復前批准”，即每條建議都等待人工接受或覆蓋。使用者也可以切換為“全自動”，但這不是一刀切開關，而是透過修復動作清單按故障分組選擇信任的項。在 Xid 組內，還可以按程式碼設定同意策略，例如自動批准 Xid 119 和 95 的重啟，而遷移仍需審批。等待空閒設定確保修復在節點真正空閒時進行（Kubernetes 上無 Pod 請求 GPU，Slurm 上無分配），最大等待時間預設 2 小時、上限 24 小時，也可選擇“不中斷執行中的作業”。每次修復都會記錄請求者、批准者、規則和時間。
除了內建檢測，團隊可以透過 API、控制台或節點標籤（預覽）引入自己的檢測系統。節點標籤方式允許任何有 RBAC 許可權的檢測器透過新增註解和標籤發起修復請求，系統會將其記錄為外部請求者，確保可追溯且無法冒充使用者。檢測器名稱加請求 ID 作為冪等鍵，防止重複掃描導致節點被多次重啟。外部請求可要求重啟、快速重建或遷移，但“移除”始終只能由人工發起。這些請求跳過審批佇列，但仍需透過證據門禁、容量檢查和預算限制，且每叢集有上限，避免缺陷檢測器造成災難。
修復動作按從輕到重分為四級：重啟（就地重啟 VM，保留本地 /scratch 和 /tmp 資料）、快速重建（在健康主機上從乾淨映象重建 VM，丟失本地資料）、遷移到新主機（在不同硬體上重建 VM，舊主機進入重新驗證）、移除（拉出節點進行 RMA，始終人工發起）。同一修復不會無限迴圈：如果同一機器上同一動作已執行兩次後故障再次出現，下一次建議會上升一級。階梯按機器、叢集、告警和 Xid 程式碼跟蹤，超過一週的嘗試不計入，已取消或自愈的建議也不計入。遷移需要關鍵告警證據，否則降級為快速重建。對於需要 GPU 斷電的故障（如 Xid 79），預覽版提供主機電源迴圈，無需 BMC 憑據，並透過啟動 ID 檢查防止重複迴圈。
系統內建多層獨立護欄以應對告警風暴：訊號必須持續一定時間才成為建議；每次修復後節點有約 30 分鐘冷卻；併發預算根據叢集節點數設定，每個節點池同時只執行一個修復；當單個叢集產生大量相關自動修復時斷路器跳閘；每次修復只針對一個目標；告警清除後建議自動消失。控制平面採用複製架構，所有寫入冪等並檢查預期狀態，兩個副本競爭同一節點只會產生一個修復。
當節點遷移或移除後，原機器不會直接回到池中，也不會排隊等待人工診斷。一旦舊 VM 消失，機器立即進入重新驗證流程，在 Together 基礎設施上執行診斷，確保只有健康的機器才能重新加入叢集。目前，被動健康檢查、修復建議、自動修復策略（包括按故障和按節點同意）、等待空閒控制、升級階梯、安全護欄以及 API 和控制台修復均已正式可用；基於節點標籤的修復合約處於預覽階段。Together 表示將持續增加新的檢測訊號和修復動作，以擴大覆蓋範圍並縮短恢復時間。