Together AI 推出 GPU 叢集自動修復功能，支援多階段故障處理

背景

在大型 GPU 叢集中，硬體故障是常見現象，例如 Xid（NVIDIA GPU 驅動程式記錄的錯誤代碼） 錯誤、雙位元 ECC（Error Correcting Code，錯誤檢查與校正記憶體技術）（錯誤檢查與校正）錯誤、GPU 從 PCIe（Peripheral Component Interconnect Express，高速電腦匯流排標準） 匯流排斷線或 InfiniBand（一種高頻寬、低延遲的網路通訊標準） 連結不穩定，這些問題可能導致分散式訓練任務停滯或推論副本當機。傳統上，發現故障容易，但從故障到節點恢復健康的過程複雜且耗時。Together AI 今年早些時候宣布推出全自動節點修復功能，協助客戶與內部推論平台提升工作負載韌性並減少停機時間。 官方原文・Together AI Blog

發生什麼事

Together AI 宣布其自動修復功能今日全面可用（Generally Available），包含被動健康檢查、修復建議、自動修復政策（Auto-remediation policy，定義修復動作是否需人工核准及等待時間的規則）、等待閒置控制（Wait for idle（等待閒置），等待節點上無運行中 GPU 工作負載後才執行修復）、升級階梯（escalation ladder，故障未解決時自動採用更重修復動作的機制）、安全護欄（safety rails，防止修復動作造成大範圍影響的限制機制）以及 API 和主控台修復功能。此外，基於節點標籤的修復合約功能目前處於預覽（Preview）階段，允許使用者整合自有的檢測系統。 官方原文・Together AI Blog

重點內容

該系統採用「被動健康檢查」（Passive health checks，持續監控節點狀態而不主動干擾工作負載）機制，持續監控虛擬機內部與底層主機。檢測範圍涵蓋虛擬機內的 kernel log（核心日誌）、DCGM（資料中心 GPU 管理工具）以及 Node Problem Detector（節點問題檢測器），可識別 Xid 錯誤、ECC 錯誤、熱節流（thermal throttling，因溫度過高而自動降低效能以保護硬體）、唯讀檔案系統等問題。主機端則監控 InfiniBand 軌道狀態與連結抖動（link flapping，網路連結頻繁斷線與重連）。每個警報都會附带穩定摘要、白話描述與機器可讀的證據負載（machine-readable evidence payload，供程式自動解析的結構化故障資料），例如 Xid 代碼與 NVIDIA 助記符（mnemonic，NVIDIA 定義的錯誤代碼縮寫名稱），或熱節流的峰值溫度與節流次數。 官方原文・Together AI Blog

修復政策分為「平台決定做什麼」與「使用者決定是否與何時執行」。平台將每個訊號映射到最輕量的修復動作，使用者可在主控台的 Repairs（修復分頁） 分頁設定預設為「修復前核准」或「全自動」。在全自動模式下，使用者可針對特定故障類型（如 Xid 119 和 95）設定自動核准重啟，而其他故障則仍需人工審核。此外，系統提供「等待閒置」控制，確保節點在 Kubernetes（容器編排系統） 上無請求 GPU 的 Pod（Kubernetes 中最小的可部署單元，包含一個或多個容器） 或在 Slurm（一種常用的叢集工作排程系統） 上無分配任務時才進行修復，預設最大等待時間為 2 小時，上限為 24 小時。 原文

修復動作遵循升級階梯，從輕到重依序為：重啟（Reboot（重啟），保留本地 /scratch 和 /tmp 資料）、快速重新佈建（Quick reprovision（快速重新佈建），在健康主機上從乾淨映像重建虛擬機）（Quick reprovision，從乾淨映像重建 VM（Virtual Machine，虛擬機），遺失本地資料）、遷移至新主機（Migrate to new host（遷移至新主機），在不同硬體上重建虛擬機並將舊主機送驗證）（Migrate to new host，在不同硬體上重建 VM）以及移除（Remove（移除），將節點從叢集中剔除並送修）（Remove，送修 RMA（Return Merchandise Authorization，退貨授權維修流程），僅限人工啟動）。若同一台機器在同一動作執行兩次後故障重現，系統會自動升級修復動作，例如第三次 Xid 重啟失敗將轉為快速重新佈建。遷移動作需有證據支持，例如節點上目前有嚴重警報或過去十天內曾有嚴重警報，否則將改為快速重新佈建。 原文

系統內建多層安全護欄以應對警報風暴，包括持續性檢查（persistence，訊號需持續一段時間才觸發修復建議）（訊號需持續一段時間才產生建議）、冷卻期（cooldown，修復後暫停產生新建議的時間窗口）（修復後約 30 分鐘內不產生新建議）、並行預算（concurrency budget，限制同時執行的修復動作數量）（依叢集節點數調整，每個節點池一次僅執行一個修復）以及斷路器（circuit breaker，當大量節點同時故障時暫停自動修復以防止錯誤擴散）（當大量節點同時故障時觸發，防止錯誤修復叢集層級問題）。此外，當節點遷移或移除後，舊主機將自動進入驗證流程，執行 GPU、NCCL（NVIDIA Collective Communications Library，用於多 GPU 通訊的庫）、InfiniBand 和儲存檢查，通過則回歸資源池，失敗則自動開立硬體工單。 原文

對使用者的意義

開發者與企業可透過 Together AI 主控台的 Repairs 分頁查看待處理建議與歷史紀錄，並設定自動修復政策。API 修復請求會附带 linked_alerts（連結警報，API 回應中包含的關聯警報資訊）（連結警報），讓外部工具能看到與主控台相同的證據。對於運行大型 GPU 艦隊的团队，可透過 API、主控台或節點標籤（預覽功能）整合自有檢測系統，如 NVSentinel（NVIDIA 提供的 GPU 監控與診斷工具） 或內部掃描器，所有修復請求都會進入同一個控制平面進行容量檢查、稽核與安全護欄處理。 官方原文・Together AI Blog

限制與未定事項

基於節點標籤的修復合約功能目前處於預覽階段。部分故障（如 Xid 79）需要 GPU 斷電，VM 重啟無法解決，需使用主機電源循環（Host power cycle（主機電源循環），對實體主機進行斷電重啟以解決特定 GPU 故障）（Host power cycle）功能，該功能亦處於預覽階段。未來計畫包括 NVSwitch（NVIDIA 的 GPU 互連交換器技術） 覆蓋（針對 NVSwitch 互連晶片故障的檢測支援）（SXid（NVSwitch 錯誤代碼） 故障（NVSwitch 特有的錯誤代碼））、將修復進度寫回節點元資料以及整合健康檢查與修復歷史的單一介面。 官方原文・Together AI Blog