dcgmi 是 Nvidia datacenter-gpu-manager 的命令行程序，可以用来采集 GPU 各类子资源的利用率数据，揭示的数据比 nvidia-smi 更详细，也更便于对接监控系统（比如 Prometheus）。这次我主要想用它来看模型训练过程中的 NVLink 带宽使用情况。
在一个已经完成 Nvidia 训练环境配置的服务器上安装 dcgmi，主要有以下几步：
1. 如果服务器上有 NVSwitch，比如 A100/800，或者部分 V100，需要先安装 nvidia-fabric-manager，注意 nvidia-fabric-manager 的版本要和 GPU 驱动版本严格一致，包括小版本号（nvidia-smi 显示的驱动版本）。
2. 如果服务器上有 NVSwitch，还需要安装 libnvidia-nscq，版本也要和驱动严格一致。
3. 安装 datacenter-gpu-manager。
4. 启用并启动 nvidia-fabricmanager 服务，注意服务名(nvidia-fabricmanager)、包名(nvidia-fabric-manager)和进程名(nv-fabricmanager)的区别。根据启动成功与否，可检查 /var/log/fabricmanager.log 中的错误信息。
systemctl enable nvidia-fabricmanager systemctl start nvidia-fabricmanager
5. 启用并启动 nvidia-dcgm服务，注意包名(datacenter-gpu-manager)、服务名(nvidia-dcgm)和实际命令/进程名(nv-hostengine)的区别。根据启动成功与否，可检查 /var/log/nv-hostengine.log 中的错误信息。
systemctl enable nvidia-dcgm
systemctl start nvidia-dcgm
但是整套配置下来，我还是遇到了不少问题，有些是配置问题，有些是文档未明确说明的问题。甚至我找到 Nvidia 的售后工程师咨询，他们都没法给我答案，后来还是我自己摸索出来了，做个记录。
1. nvidia-dcgm 服务启动成功，但又没完全成功
启动服务时候没有报错，但是执行监控命令时出错，其实启动的时候 /var/log/nv-hostengine.log 就已经出现无法加载 nscq 库的错误，只不过没影响服务的启动。因为 nscq 是对 nvswitch 的查询，用户如果不需要查询 nvswitch 的数据，可以接受这个错误。
ERROR [13862:13862] [[NvSwitch]] Could not load NSCQ. dlwrap_attach ret: Can not access a needed shared library (-79): If this system has NvSwitches, please ensure that the package libnvidia-nscq is installed on your system and that the service user has permissions to access it. [/workspaces/dcgm-rel_dcgm_3_3-postmerge/modules/nvswitch/DcgmNvSwitchManager.cpp:798] [DcgmNs::DcgmNvSwitchManager::AttachToNscq]
ERROR [13862:13862] [[NvSwitch]] AttachToNscq() returned -25 [/workspaces/dcgm-rel_dcgm_3_3-postmerge/modules/nvswitch/DcgmNvSwitchManager.cpp:632] [DcgmNs::DcgmNvSwitchManager::Init]
ERROR [13862:13862] [[NvSwitch]] Could not initialize switch manager. Ret: DCGM library could not be found [/workspaces/dcgm-rel_dcgm_3_3-postmerge/modules/nvswitch/DcgmModuleNvSwitch.cpp:34] [DcgmNs::DcgmModuleNvSwitch::DcgmModuleNvSwitch]
虽然我已经安装了 libnvidia-nscq 库，但 nv-hostengine 就是找不到 NSCQ 对应 so。我在这个问题上困扰了很久，Nvidia 的工程师也没法给我解释原因，只是一遍一遍地让我去看文档，甚至重装系统。
我觉得他的建议不靠谱，后来还是自己找到了原因，那就是 datacenter-gpu-manager 对 libnvidia-nscq 也有隐式的版本依赖。虽然在文档和包依赖中完全没有体现这种依赖关系，但我通过降级 datacenter-gpu-manager 到与 libnvidia-nscq 时间上更接近的版本解决了这个找不到 so 的问题。
之所以想到去尝试降级版本，还是因为 Nvidia 各种环境和驱动版本的强绑定，让我免不了去怀疑一下这个。
2. 查询部分指标 DCGM_FI_PROF_* 时出错
在执行 dcgmi dmon -e 449,1011,1012 时，命令行显示如下错误：
Error setting watches. Result: The third-party Profiling module returned an unrecoverable error
查看 /var/log/nv-hostengine.log，有如下错误日志：
ERROR [225876:233276] [[Profiling]] [ProfModule][PerfWorks] Got status 1 from NVPW_DCGM_PeriodicSampler_BeginSession() on deviceIndex 0 [/workspaces/dcgm-rel_dcgm_2_3-post
merge/dcgm_private/modules/profiling/DcgmLopGpu.cpp:351] [DcgmLopGpu::BeginSession]
ERROR [225876:233276] [[Profiling]] EnableMetrics returned -37 The third-party Profiling module returned an unrecoverable error [/workspaces/dcgm-rel_dcgm_2_3-postmerge/dc
gm_private/modules/profiling/DcgmModuleProfiling.cpp:2461] [DcgmNs::Modules::Profiling::DcgmModuleProfiling::ReconfigureLopGpu]
ERROR [225876:233276] [[Profiling]] Unable to reconfigure LOP metric watches for GpuId {0} [/workspaces/dcgm-rel_dcgm_2_3-postmerge/dcgm_private/modules/profiling/DcgmModu
leProfiling.cpp:2545] [DcgmNs::Modules::Profiling::DcgmModuleProfiling::ChangeWatchState]
导致这个错误的原因是对于这些 Profile 指标（1001-1014 ），NV 的 Profiler 对每个硬件使用了一个唯一锁。当你启动了超过 1 个的 nv-hostengine （包括内建的），比如使用 NCGM-Exporter 容器时，已经启动了一个内建的 nv-hostengine，然后又在主机上又启动了一个 nv-hostengine 服务，在访问这些指标时，就会出现这种访问失败。解决方案就是一台服务器仅启动一个 nv-hostengine 服务，然后所有的客户端都用本地或者远程的方式去访问它（5555 端口）。
这类问题在云场景下可能更常见，因为云服务商可能已经在租用的 GPU 服务器上部署了 DCGM 监控，你再去部署就可能遇到硬件锁的问题。
3. DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL 的单位
我最早看到这个指标是在 NCGM-Exporter 的输出指标中，但是无论是文档、配置文件还是输出接口中，都没有写明这个指标的单位和计算逻辑。我问 Nvidia 的售后工程师，他告诉我这个指标的单位是 B/s，LoL！
后来仔细查 NCGM 的文档，发现 NCGM-Exporter 的所有指标其实都源自 NCGM 的接口，但还是没看到这个指标的单位和计算逻辑。
最后使用 dcgmi dmon -e 449,1011,1012 做了一下对比，才发现其输出头中有个不起眼的 MB 字样：
#Entity NBWLT NVLTX NVLRX ID MB/
我做了一下数字的校验，基本可以明确 DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL[449] 约等于 (DCGM_FI_PROF_NVLINK_TX_BYTES[1011] + DCGM_FI_PROF_NVLINK_RX_BYTES[1012]) / 1048576，所以单位应该是 MB/s 。
4. NCGM-Exporter 的采集延迟和精度
用 docker 跑 NCGM-Exporter 镜像时，发现指标的输出非常慢，输出的值看起来也很奇怪。后来自己构建了一下，研究了一下命令行参数，才发现默认采集的周期是 30s 一次。这种采样精度下，输出的指标值能准确才怪了。正常 dcgmi 采样的频率是 1s 一次，最低可以配置到 100ms 一次。NCGM-Exporter 有命令行参数可以调整这个采样频率，但需要你自己用修改 Dockerfile 去重建镜像。或者可以考虑启动的时候将启动脚本映射到外部文件？没尝试。