nvidia_gpu_exporter：用 nvidia-smi 或 NVML 把 NVIDIA 显卡指标喂给 Prometheus

它填的是数据中心之外那块监控空白

NVIDIA 官方监控栈的重心在数据中心：DCGM 与 GPU Operator 覆盖的是 A100、H100 那一类卡，以及配套的 Kubernetes 环境。README 明确列出了这个项目瞄准的场景：GeForce/RTX 这类消费与准专业显卡上，官方工具暴露的信息很少，nvidia-smi 往往反而是唯一稳定的利用率、显存、功耗与温度来源。另一类是小型 Kubernetes 集群、边缘设备和 homelab，它们想要 GPU 指标，但不想为此引入整套 NVIDIA GPU Operator。第三类是 vGPU guest、MIG 切片、受限容器这类环境，更深的 GPU 计数器根本没有暴露出来，而 nvidia-smi 仍然能回答。README 还提到混合新旧显卡的机群需要一个行为一致的 exporter，以及游戏主机上边玩边看仪表盘这种用法。判断标准其实很简单：如果你已经在 Kubernetes 上跑数据中心卡并且装了 GPU Operator，README 自己就说 DCGM-exporter 大概更合适。

默认后端：解析 nvidia-smi，而不是链接 C 库

默认路径不依赖任何 C 绑定，它执行 nvidia-smi(.exe) 命令，解析其输出，再转成 Prometheus 指标。这个选择带来两个直接后果。第一，可移植性：README 说它能在 Linux、Windows 和 macOS 上跑，裸机、Docker、Kubernetes 都可以，Windows 上不需要 Docker 也不需要 Linux。第二，字段是自动发现的。README 把它写成 auto-discovery of the metric fields，也就是从 nvidia-smi 实际能吐出的字段里推导指标，新驱动增加字段时不用改代码，这是它宣称的 future-compatible 含义。代价是采集链路多了一层文本解析，指标类型和标签集受 nvidia-smi 输出格式的约束，而不是来自驱动的结构化 API。对于只想要利用率、显存、功耗、温度这几项的读者，这一层解析不构成问题；如果你需要更细的计数器，就得看下一节的 NVML 后端。

实验性 NVML 后端补上了哪些字段，又为什么还叫实验性

在 Linux 上，exporter 可以完全跳过 nvidia-smi，直接从 NVIDIA 驱动库（NVML）读取。README 给出的兼容承诺很具体：默认后端提供的每一个指标，在名称、标签和取值上都保持一致，所以现有仪表盘和告警不需要改动。在此之上，它增加了 nvidia-smi 拿不到的几个指标族：按 MIG 实例划分的指标、XID 错误计数器、总能耗计数器，以及 PCIe 吞吐。官方 Grafana 仪表盘为这些指标准备了面板，在默认后端上它们是空的，切到 NVML 后端才会填上。它作为独立的发布形态存在，已经默认使用该后端：从 releases 页面取 -nvml 归档，或者使用 -nvml 镜像标签。README 把它标为实验性的理由也写得很直白：需要跨更多驱动版本和 GPU 代际做测试。作者在文档里请试用者无论结果好坏都去开 issue，说这才是让它脱离实验标签的途径。换句话说，这个后端的成熟度取决于社区反馈量，而不是代码本身是否写完。

跑起来：Docker、二进制与不需要显卡的 demo 模式

README 的快速开始针对的是已装好 NVIDIA 驱动和 NVIDIA Container Toolkit 的 Linux 机器，命令是 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 属于工具类能力相符。NVML 后端的容器写法相同，只把镜像标签换成 utkuozdemir/nvidia_gpu_exporter:latest-nvml。没有显卡也能验证采集链路：nvidia_gpu_exporter --collect.backend demo 会在任何机器上提供合成指标，README 说默认模拟两块 H200，数值会波动，还带一套 MIG 拓扑和一段 XID 错误历史，NVML 独有的指标族也会出现。这意味着你可以在接入生产 Prometheus 之前，先把抓取配置和仪表盘调通。Windows、macOS、各类软件包、Kubernetes 以及不用 Docker 的安装方式，README 指向 docs/INSTALL.md，本文没有这些文档内容，无法展开。

远程执行与后台采集这两个设计选择

README 的高亮列表里有一条容易被忽略：exporter 不必运行在被监控的机器上，它可以被配置为远程执行 nvidia-smi 命令。这适合无法在 GPU 主机上常驻进程的场景，但也意味着采集路径跨了网络，nvidia-smi 的调用延迟和失败模式都会进入指标采集链路，超时与权限问题需要在部署时单独考虑。另一条是可选的后台采集：让 nvidia-smi 按定时器执行，而不是每次抓取都跑一次。这个开关直接影响 Prometheus 配置。默认按抓取触发时，指标反映的是抓取瞬间的状态，抓取频率由 scrape_interval 决定；切到后台采集后，数值的更新节奏由 exporter 自己的定时器决定，Prometheus 抓到的可能是上一次定时的结果。README 另外提到可选的按进程 GPU 指标，能看到哪个进程占用了多少显存。对排查多进程共用一张卡的情况，这一项比总量指标有用得多，但它同样受制于 nvidia-smi 本身能否列出进程信息。

什么时候它不该出现在你的清单里

最直接的边界 README 已经写明：在 Kubernetes 上跑数据中心卡、并且已经装了 GPU Operator 的场合，DCGM-exporter 更合适。两者的差别不在输出格式，而在数据来源的层级。DCGM-exporter 走的是 NVIDIA 的数据中心监控框架，能拿到 nvidia-smi 文本输出里根本不存在的计数器；这个项目默认后端的天花板就是 nvidia-smi 能打印的内容，NVML 后端虽然绕过了文本解析并补上若干指标族，但 README 把它定位在实验状态，需要跨驱动版本验证。第二个限制来自维护模式。README 顶部有一段警告，作者说明这是业余时间维护的副项目，看 issue 或 PR 可能很慢，也可能根本顾不上。这不是缺陷，但对把它放进关键监控链路的人来说是必须计入的风险：你依赖的是一个明确声明响应时间无保证的项目。第三，如果目标机器上 nvidia-smi 本身不工作，或者输出格式因为驱动或容器权限被裁剪，默认后端就没有可解析的输入，这时候问题不在 exporter。

许可证与升级成本

项目采用 MIT 许可证，这是宽松型许可，通常意味着可以修改、再分发并用于商业环境，前提是保留版权与许可声明。这里只描述许可证类型，具体合规判断请咨询法务，本文不提供法律意见。升级方面，仓库的发布节奏可以从给定信息里看到：v1.15.0 与 v1.15.1 都在 2026 年 9 月 2 日发布，相隔约一小时，v1.14.0 在 2026 年 8 月 12 日，属于较密集的小版本迭代。README 没有提供配置兼容性承诺或废弃策略，因此升级前应当核对目标版本的发布说明。一个已知的形态差异是 NVML 后端以独立的 -nvml 归档和镜像标签发布，这意味着你在部署清单里锁定的标签决定了后端，切换后端等于换镜像，而不是改一个配置项。

编辑结论

如果你手上是 GeForce/RTX 这类消费级卡、小规模 Kubernetes 集群、homelab，或者 vGPU、MIG 切片这类深层计数器被锁住但 nvidia-smi 仍能应答的环境，这个 exporter 值得先跑起来看指标是否够用；如果已经在 Kubernetes 上装了 GPU Operator 并跑数据中心卡，DCGM-exporter 更合适，不必绕这一层。动手前先确认三件事：目标机器上 nvidia-smi 能否正常输出、Prometheus 的 scrape_interval 与 --collect.interval 的取值关系、以及是否需要 NVML 后端独有的 MIG 与 XID 指标。需要后两者时，用 latest-nvml 镜像标签或 -nvml 归档，并把它当作实验特性对待，先在非关键机器上验证驱动版本兼容性。

官方来源

1. Issues
2. License: MIT
3. README
4. Releases
5. utkuozdemir/nvidia_gpu_exporter on GitHub