NVIDIA gds-diag 開源診斷工具：讓 Claude Code、Codex 找出 GPU 儲存傳輸卡在哪裡
NVIDIA gds-diag 開源工具搭配 Claude Code、Codex Skill，檢查 GPUDirect Storage 路徑、容器與設定。解析診斷結果、工具依賴及修補權限。
GPU 算得快，不代表資料一定送得快。NVIDIA 新工具 gds-diag 要檢查的，就是儲存到顯示記憶體的資料路徑，是否照預期運作。
GPUDirect Storage 可以減少資料經 CPU 與系統記憶體中轉，但驅動、檔案系統與容器設定，都會影響能否真正走直接路徑。
NVIDIA 在 2026 年 10 月 30 日介紹這項開源診斷工具，並提供可由 Claude Code、Codex 使用的 Agent Skill。
工具負責做可重複的檢查，代理則協助把人的問題對應到命令，再把結果解釋成下一步。
這對管理 GPU 主機或容器的開發者有用，因為它先回答設定卡在哪裡，避免把更換模型當成儲存問題的解法。
要看懂診斷結果，得先分清楚資料真的直達 GPU，還是仍透過 CPU 中轉的相容模式。
gds-diag 診斷的是什麼，為何能跑不代表走直接路徑？
gds-diag 針對 GPUDirect Storage 的執行條件與資料路徑檢查，沒有另外提供模型推論服務。GPUDirect Storage 簡稱 GDS，讓儲存資料能以支援的路徑送往 GPU，減少 CPU 中轉。
GPU 的顯示記憶體保存運算需要的資料。如果搬資料成為瓶頸，即使模型與晶片都有能力，整段工作仍可能在等待輸入，因此系統狀態值得和模型能力分開看。
NVIDIA 官方介紹指出，GDS 配置涉及硬體、軟體與儲存方式。診斷工具會依檔案系統與目前環境，找出阻礙或可能不理想的設定，並提供對應處理方向。
其中相容模式，也就是 compat，仍透過 CPU 暫存資料再搬送。這能讓某些工作繼續運作，卻和資料直接傳輸不同，所以「應用程式沒報錯」不足以證明已走到預期路徑。
例如主機安裝了相關套件，容器卻看不到必要裝置，程式與主機就可能呈現不同情況。若只看主機上的安裝清單，仍無法回答容器內到底發生什麼事。
這次的新事件是診斷工具與代理技能的公開介紹，GDS 本身已有既有技術與文件。因此讀者應看新工具如何縮小排查範圍，不把公告日期誤認為所有底層能力都剛推出。
所以診斷要對準實際使用的路徑與環境，不能只看機器裝了什麼。不同階段需要的第一個問題，也不完全相同。對尚未安裝的機器，先了解準備缺口就有用，對已提供服務的機器，則需要把結果接回目前工作正在使用的環境。
從安裝前到容器內，應先問哪一個問題？
工具的子命令依工作階段分工，讓尚未安裝的主機與已在執行的容器不必混著排查。依官方程式庫文件，工具本身使用 Linux 與 Python 3.8 以上版本，不需額外第三方套件。
這是執行診斷程式的條件，和完整 GDS 環境不同。官方列出已驗證 CUDA 12.2、GDS 1.7.2 與更新版本，多數執行階段檢查仍需要相關套件與適當硬體，深入診斷也可能需要較高權限。
還沒安裝，也能先做準備檢查
pre-install 用來看主機安裝前是否具備條件，因此不要求先裝好 GDS。若尚未建置環境，先跑這類檢查，比直接要求驗證已安裝執行階段更符合當下問題。
post-install 則確認已安裝的執行環境與版本組合。mount-check 對準一個實際掛載路徑，這裡的掛載路徑就是程式讀取儲存資料的位置，不能隨意換成另一個未使用的目錄代表結果。
如果問題出在容器，container-check 會看裡面能否取得必要裝置、檔案、工具與系統資訊。容器是把應用與執行環境包在一起的方式，能看見什麼仍受啟動設定影響。
config-audit 處理設定內容，support-matrix 提供支援方式參考。還不清楚問題在哪時，all 可以執行建議的一般診斷順序，再依輸出往下縮小。
設定審查也能分成正在生效與準備採用的檔案。官方提供指定設定檔並忽略本機環境覆寫的方式，讓人先檢查候選設定，而不必為了知道內容是否合理，就立刻改動主機。
這對交接很實際。如果某份設定在一台機器通過、另一台卻不同，可能除了檔案內容，還有環境變數影響實際結果。保存檢查是否使用覆寫的條件，才比較容易找出兩邊差在哪裡。
這種分工讓團隊可以先回答一件事：現在要確認安裝條件、特定資料路徑，還是容器內的可見範圍。選到相關命令，輸出才不會混進大量與問題無關的訊息。
目標範圍對了，FAIL 或 WARN 才能對應到真正需要處理的地方。接著還要理解這些標記所代表的確定程度。
FAIL、WARN 與支援矩陣，如何避免把參考表當實測？
FAIL 指出阻礙，WARN 提醒可能影響的設定，INFO 則提供資訊。官方表示，通過項目通常在詳細輸出模式才顯示，因此畫面上沒有一長排 PASS，也不代表每項都未執行。
每個發現會說明問題、處理方向與相關文件。對使用者而言，比起只讀一個紅色標記，更重要的是知道它檢查的目標、當時環境與判定原因。
例如設定檔拼錯欄位，和容器沒有取得裝置，是不同問題。前者要回到設定內容，後者要看容器啟動方式，不能因為都出現警告就用同一個修法。
靜態支援與目前執行狀態不同
支援矩陣描述各種檔案系統可能使用的路徑，讓人知道技術上要比較什麼。加入 --live 才會進一步查看目前執行環境，因此參考表與主機當下檢查需要分開讀。
即使全域設定開啟某種傳輸方式，也不代表每個檔案系統都能使用。支援路徑受平台、儲存與軟體條件共同影響，仍應依該路徑的實際結果判讀。
NFS 網路檔案系統也有自己的直接傳輸機制，不能因名稱相同，就套用本機 NVMe 儲存的說法。對一般讀者而言，保留「不同儲存路徑需要不同條件」這個區分，比背下所有縮寫更有用。
需要交接時，可以保存 JSON 輸出，也就是可由程式讀取的結構化紀錄。它能把命令結果留給後續流程，但仍要一起記下是哪個主機、容器與路徑，否則只剩一份沒有對象的報告。
如果後來更換設定，也應保留修改前的結果。當新檢查出現不同訊息，才能知道是原問題消失、另一個條件被看到，還是其實換了檢查位置。
把來源、命令與輸出留在一起，代理才有依據提出範圍合適的下一步。這也是 Skill 適合負責解讀、卻不應自己重寫所有檢查規則的原因。
Claude Code、Codex 的 Skill，為何不重寫檢查規則？
Skill 用來選擇命令與解釋結果，確定性探測仍交給 Python 工具。Skill 是提供代理按情境使用的工作指引，它讓自然語言問題能接到已有的檢查方式。
官方共用技能明確要求，以程式負責探測、解析、支援矩陣與設定驗證。代理的工作是理解操作目標、選最合適的子命令，再解釋輸出代表什麼。
這能減少兩套規則分別維護的問題。如果代理另外憑記憶判斷哪些設定有效，而程式採另一套版本條件，相同主機就可能得到兩種互相矛盾的答案。
在官方程式庫中開啟 Claude Code 或 Codex 時，專案已提供對應的技能探索路徑。使用者可以自然描述問題，或明確要求使用 gds-diag 技能，仍應確認實際執行了哪條命令。
代理看不到裝置，不等於主機沒有裝置
官方技能也處理代理沙盒的可見範圍。沙盒是限制程式能接觸哪些資源的執行環境，有時候主機驅動正常，代理執行的位置卻看不到 GPU 裝置。
若因此直接斷定驅動壞掉，就可能把問題帶到錯誤方向。指引要求先辨識是否受到執行環境限制，再透過適當授權或由操作人員在一般主機環境確認。
這個限制也適用於診斷結論的交接。報告可以寫出「在這個容器看不到必要裝置」，卻不能省掉範圍，直接變成整台主機未安裝或硬體故障。
診斷與修改因此仍要保持可分辨。代理能把原因說得合理，不代表系統狀態已經改變，真正的修補還需要對應操作與重新檢查。
以容器缺少裝置為例，修補後要怎麼確認？
NVIDIA 的官方動態示範呈現代理從容器可見資訊找出啟動設定缺口，再處理對應腳本。這是官方展示，本文沒有在自己的 GPU 主機重跑。
示範的意義是把人描述的「容器裡不能用」縮小成具體配置問題。代理先讀診斷，再提出修法，使用者便能知道為什麼要改這個地方，而不只是接受一長串命令。
工具本身只提供緩解建議，不會直接替使用者改掉系統設定。代理是否能修改檔案或執行後續操作，則依本機工具設定與權限政策處理，不能保證所有環境都會自動修好。
重查要回到相同容器與路徑
如果原問題發生在某個容器，修改主機後只看主機檢查通過，仍未回答原容器是否取得必要資源。應讓新啟動設定確實套用，再回到原本環境重新檢查。
同樣地，原工作讀取的是網路掛載，改用本機磁碟測過，只能說明另一條路徑。要證明原問題縮小，就要讓檢查對象與實際工作保持一致。
若修補消除一個阻礙，還可能露出下一個設定問題。例如容器終於看得到裝置後，才能進一步驗證執行版本與儲存路徑，不能因第一個警告消失就預設全部成立。
在正式環境，這些修改也要配合團隊原有程序。先保存診斷、說明改動範圍與回復方式，再執行有需要的調整，比把每一條建議都當成必須立即套用更清楚。
只有在相同容器與掛載路徑重新檢查後，修補才和原本問題連得起來。確認設定成立後，還有最後一個不同問題：實際工作是否因此變快。
哪些團隊適合先用，哪些結論仍不能直接下？
已經要部署或排查 GDS 的團隊，可以先用 gds-diag 整理系統證據。如果只是一般模型使用者，沒有管理主機或儲存環境的需求，這套工具不會直接替聊天或生圖增加能力。
它最有價值的地方，是把主機準備、容器可見性、設定與資料路徑分開。這讓團隊在請其他人協助時，可以帶著明確輸出討論，減少只憑「很慢」推測問題。
但設定通過與效能提升仍有差別。確認直接路徑可用後，應以相同模型、資料與工作條件量測吞吐或等待，才能知道原本的瓶頸是否真的在資料傳輸。
若工作主要受模型計算或其他流程限制，即使路徑修正，整體時間也不必然有相同比例的改善。官方沒有提供一個能套到所有部署的加速百分比，因此不宜自行估算節省幅度。
程式庫的原始碼採 Apache 2.0 授權，技能文件與非程式資產另列 CC-BY-4.0 AND Apache-2.0。這些是專案文件列出的條款，不代表官方部落格的所有圖片都自動取得任意重製權。
對部署者而言，先把實際診斷對象與操作權限安排好，再用這套工具找出路徑與設定問題，會比把代理當成通用自動修機服務更合適。
確認資料路徑成立之後，再量測真實工作吞吐，才能知道改善是否來自儲存設定，也才能判斷還需調整哪一段。
延伸閱讀：NVIDIA DSX OS 擴充開源元件：AI 工廠從機架到可訓練，中間還缺什麼？
延伸閱讀：Claude Code 2.1.314 加入寫入目錄限制：讓代理改檔前，先畫清楚工作範圍
常見問題
沒有 GPU，也能執行 gds-diag 嗎？
部分子命令可以。官方文件列出安裝前檢查不需要先裝好 GDS，支援矩陣與設定審查也能在沒有 GPU 時使用，但實際執行階段驗證仍需要對應環境。
代理找到問題後，會自動改掉系統嗎？
診斷程式本身只提出處理方向。代理能否執行修改，依本地權限與政策決定，因此應確認改了什麼，再回到相同目標重新檢查。
相容模式可以當成直接傳輸嗎？
相容模式仍使用 CPU 中轉，和預期的直接路徑不同。應看工具對指定路徑的診斷，並用實際工作量測效果，不能只憑程式正常執行判定已使用直接傳輸。
想持續追蹤 AI 代理、GPU 基礎設施與部署工具，歡迎免費訂閱 AI 郵報。
