pynvml多卡监控可行但需手动处理设备枚举、错误隔离和日志对齐；分布式下nvidia-smi的CSV输出更稳定，因pynvml易因单卡异常（如失联、超温、被锁）导致整体中断，且无软失败机制。
直接结论：用 pynvml 封装多卡监控是可行的，但必须手动处理设备枚举、错误隔离和日志时间对齐；分布式场景下，nvidia-smi 的 CSV 输出更稳定，pynvml 容易因某张卡异常导致整个监控中断。
为什么 pynvml 在多卡环境下容易崩
pynvml 调用底层 NVML 接口时，一旦某张 GPU 失联（比如驱动重载、ECC 错误、热插拔）、温度超限或被其他进程锁死，nvmlDeviceGetHandleByIndex(i) 就会抛出 NVMLError_Uninitialized 或 NVMLError_NoPermission，而默认不带 try/catch 的循环会直接退出。这不是代码写得不够健壮，而是 NVML 本身的约束——它不提供“尽力获取可用卡”的软失败模式。
常见错误现象：
-
NVMLError_DriverNotLoaded：容器里没挂载/dev/nvidiactl设备节点 -
NVMLError_InvalidArgument：传入的 GPU 索引超出实际数量（比如nvmlDeviceGetCount()返回 2，但硬写死循环到 4） - 监控脚本静默退出，日志断在某次调用后，无任何报错痕迹
pynvml 多卡封装的关键防护点
必须把每张卡的采集逻辑独立包裹，不能共用 handle 或共享异常处理块。以下是最小可用结构：
立即学习“Python免费学习笔记（深入）”；
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
import pynvml
from typing import List, Dict, Optional
<p>def get_gpu_stats(device_id: int) -> Optional[Dict]:
try:
handle = pynvml.nvmlDeviceGetHandleByIndex(device_id)
mem = pynvml.nvmlDeviceGetMemoryInfo(handle)
util = pynvml.nvmlDeviceGetUtilizationRates(handle)
temp = pynvml.nvmlDeviceGetTemperature(handle, pynvml.NVML_TEMPERATURE_GPU)
return {
"id": device_id,
"mem_used_mb": mem.used // 1024<strong>2,
"mem_total_mb": mem.total // 1024</strong>2,
"gpu_util_pct": util.gpu,
"temp_c": temp,
}
except pynvml.NVMLError:
return None # 不抛出，让上层决定是否跳过</p><p>def collect_all_gpus(max_gpus: int = 8) -> List[Dict]:
stats = []
for i in range(max_gpus):
s = get_gpu_stats(i)
if s is not None:
stats.append(s)
return stats
要点说明：
-
max_gpus不要依赖nvmlDeviceGetCount()动态返回值作为循环上限——它可能在运行中突变为 0（比如驱动崩溃），应设为合理上限（如 8）并靠get_gpu_stats内部容错兜底 - 显存单位统一转成 MB，避免字节级数字干扰日志可读性
- 不要在
collect_all_gpus里调用nvmlInit()和nvmlShutdown()——初始化一次即可，且应在主程序最外层做，否则并发调用会冲突
分布式日志规约：为什么不用 JSON 行格式
在多进程/多节点训练中（比如 torch.distributed.launch 或 Slurm），多个 pynvml 实例同时写日志，若用 JSON 每行一条记录，极易出现换行符错位（一个进程写一半被另一个截断），导致下游解析失败。更稳妥的是固定字段 CSV：
# 示例输出（带毫秒时间戳 + 进程 PID） 2026-04-19T14:15:22.123,1234,gpu0,65,3240,8192,72.1 2026-04-19T14:15:22.123,1234,gpu1,41,2100,8192,68.3
字段顺序固定为：timestamp,pid,gpu_id,mem_used_mb,mem_total_mb,gpu_util_pct,temp_c。这样：
- 可用
awk -F, '$4 > 95 {print}' logs.csv快速筛高显存报警 - Spark/Flink 可直接按逗号切分，无需 JSON 解析器
- 即使某行损坏（如少一个字段），也不影响其他行解析
PyTorch 分布式训练中真正该盯的指标
单看 gpu_util_pct 容易误判。比如 DDP 模式下，GPU 利用率可能长期 90%+，但实际是 NCCL 同步在占满 PCIe 带宽，计算单元空转。此时应交叉比对：
-
torch.cuda.memory_allocated()：确认显存是否真被模型张量占用，而非缓存堆积 -
nvidia-smi dmon -s u -d 1：看sm（流处理器）利用率是否同步高，排除仅tx（传输）高导致的假饱和 - 每个 rank 单独打日志，用
torch.distributed.get_rank()标注来源，避免把 rank 0 的日志当成全局代表
最容易被忽略的是：pynvml 获取的温度、功耗等指标，在多卡共享散热模组时（如 A100-SXM4），单卡读数可能无法反映局部热点；而 nvidia-smi --query-gpu=temperature.memory 提供的显存温度，比 GPU 核心温度更能预警显存颗粒老化问题。
