NVIDIA Attribution：診斷結論應當獲得多大的處置權

NVIDIA 在2026 年 11 月 2 日的文章中介紹了用於診斷分散式 AI 工作負載故障的開源 Attribution 工具。

本文提出的是面向維運團隊的評估框架，並非產品跑分或部署實測。

先明確要作出的決定

事故現場通常需要回答兩個問題：現在可以安全地做什麼，以及怎樣才能查清事情為什麼發生？如果把它們合併，團隊容易走上一條代價很高的捷徑：一個看似合理的解釋，還沒有接受檢驗，就變成了修改基礎設施的授權。

設想一個假設情境：訓練任務連續停止兩次。把下一次執行遷到備用節點，可能是可逆的臨時控制措施；更換原節點的硬體，則是另一種程度的承諾。同一份初步報告可以引出這兩種行動，但它們所需的證據門檻不應相同。因此，報告應寫明支持哪項決定、由誰負責，以及出現什麼新觀察後需要推翻原判斷。

這是我們評估歸因軟體的核心標準：它有沒有改善這些選擇的品質？總能給出漂亮答案的介面，未必比保留疑問、同時指出成本最低的區分性測試的介面更有價值。

分類標籤還不足以決定維修方案

專案儲存庫說明，其工作是關聯日誌，而非探測硬體；是否更換硬體由維運人員決定。採購和試點應當尊重這個邊界。

我們建議分別審查三種輸出：候選解釋、挑戰該解釋所需的證據，以及允許採取的回應。對於被懷疑的零組件，應詢問現有觀察能否區分內部缺陷與外部中斷。若不能，就保留兩種可能。即使某項分類可信度很高，其範圍仍可能太廣，無法支持某一種具體維修。

與其給診斷結果製作排行榜，不如建立決策紀錄：當時建議做什麼，實際做了什麼，當時掌握哪些證據，後來發生了什麼。這樣才能區分錯誤解釋與事後看來不必要、但當時合理的預防措施，也不會僅僅因為重新啟動後任務成功，就把功勞全部記給診斷。

為證據保留設置獨立驗收

Kubernetes 文件指出，驅逐 Pod 會移除相關容器及其日誌。因此，恢復速度與證據能否繼續取得，應分開測試。

我們建議從一個刻意選擇的低重要性任務開始演練。在任何破壞性清理之前，驗證有權限的應變人員能從其他位置取回範圍明確的事故紀錄，並標註缺失的輸入。為收集過程設置有文件依據的時限，避免調查無限期阻礙服務恢復。不要把機密資訊與不必要的業務資料放進封存檔，也要為保留的證據設置到期時間。

接著，由第二名應變人員在不依賴第一人記憶的情況下還原事故。如果這需要某條沒有紀錄的查詢、私人筆記本，或已經消失的終端機工作階段，即使任務恢復執行，這次演練也不應通過。目標是提供可以移交和複核的依據，而非無限增加日誌。

不確定性也需要測試

OpenTelemetry 日誌模型區分事件發生時間與觀察時間。我們建議延遲一條輸入流，檢查結論是否相應變得謹慎。

還有幾項值得做的測試，它們是本文建議，並非對產品功能的聲明：移除一個證據來源；放入兩種互相競爭的解釋；更新規則後重播同一事故。每次結論改變，都要求審查人員說明原因。系統不應因為表現出確定性而得到獎勵，尤其當這種確定性依賴於它從未收到的事實時。

PyTorch 的 torchrun 文件將按時間戳選取每個節點最早錯誤作為根因的方法稱為啟發式方法。因此，應調查最早回報的程序，而不是直接將責任歸給它。

自動處置之前，先計算犯錯的代價

試點應該像統計漏報一樣認真統計錯誤干預。不必要地移除健康節點會占用容量，反覆重試失敗任務則會消耗時間與算力。哪種成本更重要，取決於備用容量、任務緊急程度，以及行動能否撤銷。示範環境中的某個門檻，不值得不加判斷地照搬。

我們建議為試點設定明確終點：審查人員能夠從建議行動追溯到已保留的證據，說清剩餘不確定性，並按照書面規則撤銷行動或升級處理。在達到這個條件前，讓建議與現有維運流程並行運作，而不要把每條診斷直接連接到自動修復。

商業層面真正需要回答的是：扣除接入和維護成本後，這個流程能否減少可避免的決策錯誤與重複調查？NVIDIA Attribution 提供了一個及時討論這個問題的機會。可信答案需要在真實維運限制下進行本地試點，不能假定一個新的診斷標籤已經解決了故障。