輝達Attribution診斷工具公開上架GitHub　Recovery整合仍需核准存取

輝達(NVIDIA，NVDA)的分散式AI工作診斷工具NVIDIA Attribution，已出現在官方文件與公開GitHub儲存庫中。

輝達2日在技術部落格介紹另一項產品NVIDIA Recovery，並表示可選擇將Attribution與Recovery整合。Attribution的組成與支援範圍則列於官方文件。

官方文件將Attribution分為自架REST服務與藍圖兩部分。服務接收標準化的可觀測性資料，並回傳個別工作的診斷結果。

藍圖會從排程器與遙測系統收集日誌和指標，再呼叫服務並儲存結果；工具也包含用來查看診斷結果的唯讀儀表板。

診斷結果包含失敗狀態、詳細分類，以及在證據支持下判定的原因、相關節點和導致故障的事件鏈。系統會將每項工作的多種症狀與可能原因一併呈現。

文件範例將128個節點出現的通訊症狀與「NCCL invalid NIC selection」錯誤歸入同一個「system_software」分類。文件指出，這是說明功能的案例。

Attribution會比對已收集的日誌和指標進行診斷，不會直接檢查硬體，也不會執行診斷命令。

若證據同時符合多種可能原因，結果會標示為「ambiguous」；證據不足時則回傳「unattributed」。因此，診斷結果是供營運人員檢視的資訊，不能視為已確認的原因。

支援的排程器為Slurm 25.11以上版本。若以JobSet形式進行分散式訓練，則需要搭配Kueue v0.6以上版本及JobSet v0.5以上版本。

文件列出的支援GPU包括A100、H100、L40S、B200、GB200和GB300。GB200與GB300的規則適用範圍仍在成熟中，NVIDIA KAI Scheduler的診斷功能則尚未實作。

3日確認時，GitHub儲存庫為公開狀態，Attribution程式碼標示採用Apache 2.0授權。儲存庫是否公開，以及Recovery整合所需的建置與部署條件，仍須分開確認。

Recovery概覽文件仍保留「目前尚無法公開取得Attribution來源碼」的說明，與儲存庫的公開狀態及文件中的來源碼存取指引並不一致。

Recovery的Attribution整合說明指出，建置時需要經核准的來源碼存取權限。因此，儲存庫公開與取得整合建置所需的存取權，不能視為相同條件。

Recovery是另一項產品，會在偵測到故障後隔離節點，並透過檢查點協調工作重新啟動。與本刊先前報導的Recovery故障偵測與重新啟動功能相比，Attribution負責診斷可能原因與症狀發生路徑。

輝達在官方文件中舉例，根據RDMA架構GPU叢集的診斷結果修復基礎設施並調整壅塞後，工作中斷的平均間隔約增加3倍。文件未公開具體測量值與比較方法，因此不能將此視為Attribution單獨帶來的一般性效能提升幅度。