导语：跑训练/推理时，GPU利用率、显存、掉卡这些指标怎么看？故障如何快速定位和处理？本文从实战视角，拆解三类高频问题，给出可操作的排障流程，并比较租用与自建场景的差异，帮你少走弯路。
一、监控指标全景：利用率/显存/功耗/温度
GPU监控的第一步是理解四个核心指标。利用率表示计算核心的忙碌程度，显存占用表示已分配显存大小，功耗反映实时电力消耗，温度则是芯片表面温度。以下表格给出常见异常与告警建议：
| 指标 | 含义 | 常见异常 | 告警建议 |
|---|---|---|---|
| GPU利用率 | 计算核心活动时间占比 | 训练时长期过低、波动剧烈 | 连续10分钟低于10%（需结合负载） |
| 显存占用 | 已分配显存容量 | 接近上限、OOM | 超90%并继续增长 |
| 功耗 | 典型功率范围（如~300W） | 低于预期或异常升高 | 与利用率严重不匹配 |
| 温度 | 核心温度 | 过热降频、黑屏 | 持续超85°C |
注意：这些阈值是经验性建议，不同型号有差异。在实际判断中，还需要结合任务类型。比如推理任务，利用率可能只有30%但吞吐已达标，这时纠结利用率没有意义。当算力从“按GPU数量”转向“按Token产出”计费时，每分每秒的产出效率比单纯的利用率更有价值。正如行业观察指出的，竞争核心正从GPU数量走向Token制造效率。
二、常用监控工具：nvidia-smi/NVML/DCGM/云平台面板
选择工具取决于你的角色。命令行工具适合快速排查，平台面板适合长期观察。下表列出主要工具：
| 工具 | 用途 | 关键命令/说明 |
|---|---|---|
| nvidia-smi | 命令行查看 | nvidia-smi 查看状态；nvidia-smi -l 1 每秒刷新 |
| NVML | 编程接口 | 用于脚本采集，如nvidia-smi --query-gpu=utilization.gpu,memory.used |
| DCGM | 数据中心级监控 | dcgmi -r 运行诊断，支持遥测与故障检测 |
| 云平台面板 | 租用场景 | 提供历史曲线与告警 |
实际使用中，如果只是临时看，nvidia-smi足够；如果要在生产环境持续监控，可部署DCGM或自研采集器。对于租用GPU，云平台通常已经内置了基础监控，你只需要会看告警即可。工具选型没有绝对标准，关键是能快速拿到“利用率、显存、温度”这三个数。
三、利用率异常排查：训练吞卡/推理低效
利用率低不一定代表GPU有问题，有可能是进程根本没跑满。先按四步走：
- 用
nvidia-smi确认当前哪些进程在占用GPU，以及利用率是否长时间为0。 - 用
top或ps查看CPU利用率，确认是否存在数据加载瓶颈。 - 检查存储或网络是否成为限制因子。
- 如果训练吞吐不稳定，尝试增大batch size或启用数据预取。
对于训练任务，利用率频繁波动可能意味着多个进程在争抢资源，或者分布式训练中某张卡拖慢整体。推理场景利用率低很常见，因为请求是稀疏的。此时不应盲目加大并发，而应看延迟与吞吐是否符合业务目标。在Token计费时代，真正要盯的是每百万Token成本，而不是GPU是否转满。这就解释了为什么有的推理服务利用率不高却依然盈利。
四、显存问题实战：OOM/碎片/泄漏
OOM（out of memory）是训练和推理中最常见的报错之一。常见原因包括：模型参数量与显存容量不匹配、batch size过大、显存泄漏或碎片化。排查时先用nvidia-smi查看当前显存占用，确认是峰值超限还是持续增长。
| 原因 | 特征 | 应对 |
|---|---|---|
| 模型过大 | 加载时直接OOM | 换小模型或降低精度 |
| batch过大 | 反向传播时OOM | 减小batch或梯度累积 |
| 泄漏 | 训练过程显存缓慢增长 | 检查显存释放逻辑 |
| 碎片化 | 显存占用不高但仍报OOM | 使用显存整理或重启进程 |
优化手法包括：混合精度、梯度累积、torch.cuda.empty_cache()、设置max_split_size_mb等。注意这些是通用建议，具体还需结合框架文档。有时只是简单重启进程就能解决碎片问题，但长期仍要优化分配。
五、掉卡故障处理：NVML错误/设备消失/PCIe问题
掉卡的典型现象：nvidia-smi列出设备但状态异常，或直接少一张卡；应用返回CUDA error: device lost。系统性排查步骤如下：
- 查看系统日志：
dmesg | grep NVRM，确认是否有NVRM错误信息。 - 检查PCIe设备是否还在：
lspci | grep -i nvidia，看是否有未知设备。 - 尝试软件复位：
nvidia-smi --gpu-reset -i <id>（注意在脱离运行任务时执行）。 - 检查电源和散热，过热或供电不足都可能导致掉卡。
- 如果上述都无效，可能是硬件故障，需关机更换设备或联系云厂商。
在多卡环境中，掉卡往往导致训练中断。为了防止扩散，建议设置心跳检测与自动重试，并在框架中启用弹性训练，让故障卡被自动剔除。记住不存在100%避免掉卡的方法，但完善的监控和快速恢复机制能让损失最小化。
六、多卡与租用场景：多卡同步/租用环境排障
多卡环境下的故障定位相对复杂。同步失败时，往往会显示某张卡超时，此时需要用分布式训练框架的日志定位是哪个rank出错。可以用nvidia-smi -q -d GPU查看每张卡的详细信息，比如温度、EEC错误。常见故障有：NVLink通信异常、PCIe中断、GPU时钟波动。
租用与自建在监控上存在天然差异：
| 维度 | 租用GPU | 自建服务器 |
|---|---|---|
| 监控方式 | 使用平台面板，自定义受限 | 自由部署DCGM等 |
| 排障权限 | 无法物理操作，依赖工单 | 可自行重启、换卡 |
| 责任划分 | 硬件故障归平台 | 自己全权负责 |
租用场景下，你应当优先使用平台提供的诊断工具，并与客服沟通。算家云等平台将算力包分为专业版与青春版，专业版更强调长期稳定运行，可能提供更好的监控与支持。在急用时，可以考虑短期测试版，但生产环境建议选择专业版。总之，选择租用还是自建，要看你对监控细度和响应速度的要求。
小结：监控与排障是一个循环。建议先设定合理的告警阈值，然后定期演练恢复流程。如果你有购买或租用需求，可参考租用市场、硬件选购以及托管服务。