在大規模 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 表示將持續增加新的檢測信號和修復動作，以擴大覆蓋範圍並縮短恢復時間。