nvidia_gpu_exporter：用 nvidia-smi 當資料來源的 Prometheus GPU 匯出器
Nvidia GPU exporter for prometheus using nvidia-smi binary OR using NVML
秒懂
- 它是什麼？
- 這個 Go 專案把 nvidia-smi 的輸出解析成 Prometheus 指標，因此 Windows、macOS、vGPU guest 與 MIG 切片都能被監控；代價是它拿不到 nvidia-smi 本身不提供的底層計數器，除非改用實驗性的 NVML 後端。
- 適合誰用？
- 如果你的機器是 GeForce/RTX、vGPU guest、MIG 切片或 Windows 主機，而 nvidia-smi 是唯一穩定可得的資料來源，這個匯出器值得先跑一次 docker run --gpus all -e NVIDIA_DRIVER_CAPABILITIES=utility -p 9835:9835 utkuozdemir/nvidia_gpu_exporter:latest 再 curl http://localhost:9835/metrics 核對欄位。若你已在 Kubernetes 上跑資料中心卡並裝了 NVIDIA GPU Operator，DCGM-exporter 才是對的選擇，因為它走的是 DCGM 而非命令列解析。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它填補的是 nvidia-smi 與 Prometheus 之間那段空白
資料中心卡的監控路徑很清楚：NVIDIA GPU Operator 加上 DCGM-exporter，指標齊全、標籤正規。問題出在這條路徑覆蓋不到的地方。消費級 GeForce 與 RTX 卡上，較深的 GPU 計數器多半不開放；vGPU guest 與 MIG 切片只暴露部分欄位；Windows 主機根本沒有那套容器化堆疊；老卡與新卡混雜的機隊，很難要求每台都裝同一套 agent。這些場景裡唯一到處都在、行為又一致的介面，就是 nvidia-smi 這支執行檔。
專案的目標讀者因此相當具體：跑家用或小型工作室 GPU 的人、在 homelab 與 edge box 上想要 GPU 指標但不想引入整套 Operator 的人、以及被鎖在容器或虛擬化環境裡、只能拿到 nvidia-smi 那幾個欄位的人。README 把這些寫成 use cases 清單，同時也直說：如果你是在 Kubernetes 上跑資料中心卡、而且 GPU Operator 已經裝好，DCGM-exporter 更合適。這種自我限縮在匯出器專案裡並不常見，但對讀者是有用的訊號。
解析命令列輸出，而不是連結驅動程式
預設後端做的事情很單純：執行 nvidia-smi，取得輸出，解析成欄位，再轉成 Prometheus 指標。專案說明它會自動探索 nvidia-smi 能吐出的 metric 欄位，這個設計讓它對未來新增的欄位保持相容，因為欄位清單不是硬編碼的。代價是資料品質完全取決於 nvidia-smi 的輸出格式，而那個格式是給人看的文字，不是穩定的機器介面。
有兩個機制值得注意。第一，它不需要跑在被監控的機器上：可以設定讓它遠端執行 nvidia-smi 命令，這對無法在目標主機上裝東西的環境很實用，但也把網路與認證的複雜度帶進來。第二，可以選擇背景收集，讓 nvidia-smi 依計時器執行，而不是每次 scrape 都跑一次。這個選項存在的原因很明顯：nvidia-smi 是外部行程，每次 scrape 都 fork 一次，在 scrape 間隔很短時會產生可觀的額外負擔。
另有選用的 per-process GPU 指標，可以看到哪個行程佔用多少 GPU 記憶體。這在推論服務與訓練任務共卡的機器上，往往是唯一能回答「是誰把記憶體吃光」的資料。
NVML 後端走的是完全不同的路：在 Linux 上跳過 nvidia-smi，直接從 NVIDIA 驅動函式庫讀取。專案強調既有指標的名稱、標籤與數值保持不變，因此現有儀表板與告警不會壞掉；額外增加的是 nvidia-smi 給不出的家族，包括 per-MIG-instance 指標、XID 錯誤計數、總能量計數與 PCIe 吞吐。官方 Grafana 儀表板已經為這些留了面板，預設後端下是空的，切到 NVML 後才會有資料。
啟動方式與幾個真正會絆倒人的設定
Linux 上最快的一條路是容器。README 給的指令是 docker run -d --name nvidia_gpu_exporter --restart unless-stopped --gpus all -e NVIDIA_DRIVER_CAPABILITIES=utility -p 9835:9835 utkuozdemir/nvidia_gpu_exporter:latest，之後用 curl http://localhost:9835/metrics 確認輸出。NVIDIA_DRIVER_CAPABILITIES=utility 這個環境變數不能省，因為它決定容器內是否拿得到 nvidia-smi。
沒有 GPU 也能先看輸出長什麼樣：nvidia_gpu_exporter --collect.backend demo 會在任何機器上提供合成指標。預設模擬兩張 H200，數值會波動，並帶有 MIG 拓樸與 XID 錯誤歷史。要在正式環境之前驗證 Prometheus 的 scrape 設定、標籤重寫與儀表板變數，這是最省事的做法，因為它連 Linux 都不需要。
想試 NVML 後端，發行頁有預設使用該後端的 -nvml 壓縮檔，容器則用 -nvml 映像標籤，例如 utkuozdemir/nvidia_gpu_exporter:latest-nvml，其餘參數與預設後端相同。完整的後端比較與目前限制寫在 docs/CONFIGURE.md 的 experimental-native-nvml-backend 一節，設定鍵與行為差異以那裡為準。
安裝管道不只容器：README 指向 docs/INSTALL.md，涵蓋 Windows、macOS、各類套件、Kubernetes 與不使用 Docker 的執行方式，winget 也在其中。
實驗性標籤與維護節奏是兩個分開的風險
NVML 後端被標為實驗性，理由寫得很直白：需要在更多驅動版本與 GPU 世代上測試。這不是模糊的免責聲明，而是一個具體的驗證缺口。專案也直接邀請使用者開 issue 回報結果，不論好壞，並說這正是讓它脫離實驗標籤的方式。換句話說，如果你需要 per-MIG 指標或 XID 計數，你同時也是在替這個後端做測試。
另一個風險與程式碼無關。README 開頭有一段警告，說明這是作者閒暇時間維護的 side project，issue 或 PR 可能很久才被看到，甚至永遠不會。這句話應該被當成維運成本來評估，而不是客套話。匯出器本身邏輯不複雜，解析層出問題時通常看得出來，但若你打算把它放進需要明確回應時間的生產路徑，這個維護節奏就是必須先接受的前提。
還有一個結構性的限制：預設後端的天花板就是 nvidia-smi 的天花板。在 vGPU guest、MIG 切片或受限容器裡，nvidia-smi 能回答的欄位本來就少，匯出器不會變出更多。這不是缺陷，而是這個設計選擇的必然結果，也是它能在那些環境裡運作的原因。
與 DCGM-exporter 的差別在資料取得方式
README 自己點名的替代方案是 NVIDIA 的 DCGM-exporter。兩者的差異不在指標數量多寡，而在資料怎麼來。DCGM-exporter 透過 NVIDIA 的資料中心 GPU 管理函式庫取得指標，需要驅動與函式庫支援，在 Kubernetes 上通常與 GPU Operator 一起部署。nvidia_gpu_exporter 則是執行命令列工具再解析文字輸出，因此不需要 C 綁定，也不需要 Linux。
這個差別決定了適用邊界。DCGM 路線在資料中心卡上是原生且完整的，指標語意清楚、標籤設計適合大規模機隊。命令列解析路線則在 DCGM 到不了的地方還有答案：Windows 主機、macOS、vGPU guest、老舊或混合的卡。反過來說，如果你已經有 GPU Operator，再加一層文字解析只是多一個會壞的環節，而且拿到的指標更少。
值得注意的是兩條路線並不互斥。專案自己的 NVML 後端就是在往原生讀取的方向靠，只是目前仍標為實驗性，且僅限 Linux。一個機隊裡同時存在資料中心卡與消費級卡時，分開部署兩套匯出器，比勉強用一套覆蓋全部更合理。
授權與升級成本
授權是 MIT，對商業部署與修改都相對寬鬆，沒有 copyleft 的傳染性要求。這裡不提供法律意見，實際條文與著作權聲明以倉庫中的 LICENSE 檔案為準。
升級成本取決於你依賴哪一層。指標名稱、標籤與數值在兩個後端之間保持一致，這是專案明確承諾的，因此儀表板與告警在切換後端時不需要改寫。真正需要留意的是解析層：nvidia-smi 的輸出格式由驅動決定，驅動更新可能改變欄位或排版，而自動探索欄位的機制雖然提高了相容性，卻也意味著新欄位會突然出現在指標裡。若你的 Prometheus 設定了嚴格的指標白名單或 recording rule，這種新增值得先在 demo 模式下觀察。
專案近期發布節奏穩定，v1.15.1、v1.15.0 與 v1.14.0 集中在 2026 年 8 月至 9 月之間。升級時建議先看 release notes 中關於後端與指標家族的變動，再決定是否跟進，尤其是使用 -nvml 標籤的部署。
編輯結論
如果你的機器是 GeForce/RTX、vGPU guest、MIG 切片或 Windows 主機，而 nvidia-smi 是唯一穩定可得的資料來源，這個匯出器值得先跑一次 docker run --gpus all -e NVIDIA_DRIVER_CAPABILITIES=utility -p 9835:9835 utkuozdemir/nvidia_gpu_exporter:latest 再 curl http://localhost:9835/metrics 核對欄位。若你已在 Kubernetes 上跑資料中心卡並裝了 NVIDIA GPU Operator，DCGM-exporter 才是對的選擇，因為它走的是 DCGM 而非命令列解析。導入前務必先確認三件事：nvidia-smi -q 在你機器上實際吐出的欄位、--collect.nvidia-smi-command 在容器內的路徑是否正確、以及需要 per-MIG 或 XID 計數器時是否接受 -nvml 映像標籤仍被標為實驗性。作者在 README 明說這是閒暇時間維護的 side project，issue 與 PR 可能很久才回應，這件事本身就是採用決策的一部分。
社群筆記