硬件监控与排障

大模型服务能启动不代表能长期稳定运行。线上真正难处理的问题，往往不是“模型不会推理”，而是 GPU 利用率忽高忽低、显存突然打满、温度降频、Xid 错误、驱动异常、某张卡掉线，最后表现为请求超时、吞吐下降或训练任务 hang 住。

硬件监控的目标不是堆一堆指标，而是回答三个问题：

资源是否真的被有效使用。
当前瓶颈在 GPU、显存、CPU、网络、存储还是调度。
异常发生时，能不能快速定位到进程、卡、节点和时间段。

核心判断

大模型硬件排障要同时看“业务指标”和“硬件指标”。只看 nvidia-smi 不够，因为 GPU 利用率正常也可能 P99 延迟很差；只看接口延迟也不够，因为根因可能是显存碎片、ECC 错误、PCIe 降速、温度降频或某个 worker 被调度到错误拓扑。

1. 监控对象

大模型训练和推理至少要覆盖这些对象：

对象	关键问题	常用指标
GPU	算力是否被吃满，是否降频或报错	utilization、SM utilization、clock、temperature、power、Xid
显存	模型、KV Cache 和运行时开销是否有余量	used memory、free memory、reserved memory、OOM 次数
GPU 互联	多卡通信是否成为瓶颈	NVLink / PCIe 吞吐、NCCL 性能、拓扑
CPU / 内存	tokenizer、调度、后处理是否拖慢 GPU	CPU utilization、load average、RSS、page cache、swap
存储	模型加载、checkpoint、日志是否受阻	IO latency、throughput、inode、磁盘空间
网络	多机通信、模型分发、请求入口是否稳定	bandwidth、retransmit、packet drop、RDMA counters
进程	哪个服务占用了资源，是否泄漏	PID、容器、模型实例、显存占用、重启次数

实际运维中，最有价值的是把这些指标和业务维度关联起来，例如：

哪个模型实例。
哪个 GPU UUID。
哪个节点。
哪个容器或 Pod。
哪个版本的模型和推理框架。
哪段压测或线上流量。

否则看到“显存满了”也很难判断是正常预留、请求突发、内存泄漏还是其他进程抢卡。

2. `nvidia-smi` 能看什么

nvidia-smi 是最常用的 GPU 现场诊断工具，适合快速判断卡是否存在、驱动是否可用、显存是否被占用、温度和功耗是否异常。

常用命令：

nvidia-smi
nvidia-smi -L
nvidia-smi pmon -s um
nvidia-smi dmon -s pucvmt
nvidia-smi topo -m

含义大致如下：

命令	用途
`nvidia-smi`	查看 GPU、驱动、CUDA 版本、显存、功耗、温度和进程
`nvidia-smi -L`	列出 GPU 和 UUID，适合和监控标签对齐
`nvidia-smi pmon`	按进程查看 GPU 使用情况
`nvidia-smi dmon`	连续采样 GPU 功耗、温度、显存、利用率
`nvidia-smi topo -m`	查看 GPU、CPU、网卡之间的拓扑关系

如果只想取结构化字段，可以用：

nvidia-smi --query-gpu=index,uuid,name,temperature.gpu,power.draw,utilization.gpu,utilization.memory,memory.used,memory.total,ecc.errors.uncorrected.volatile.total --format=csv

排障时建议记录：

GPU index 和 GPU UUID。
driver version 和 CUDA version。
当前进程 PID。
显存占用和 GPU 利用率。
温度、功耗、时钟频率。
是否有 ECC / Xid 错误。

注意：GPU index 可能因为重启、容器映射或调度方式变化而改变，生产监控里更建议使用 GPU UUID 作为稳定标识。

3. DCGM 和生产监控

nvidia-smi 适合人工现场排查，生产环境更常用 NVIDIA DCGM 采集指标，再接入 Prometheus、Grafana 或其他监控系统。

DCGM 的价值在于：

可以持续采集 GPU 健康状态。
能暴露更细的硬件计数器。
适合 Kubernetes 或多节点集群统一监控。
能记录 ECC、Xid、PCIe、NVLink 等异常。
可以和告警系统联动。

常见采集链路：

GPU
  -> DCGM / DCGM Exporter
  -> Prometheus
  -> Grafana
  -> Alertmanager

监控面板建议至少分四层：

面板	关注点
节点视图	单台机器上的 GPU、CPU、内存、磁盘、网络是否健康
GPU 视图	每张卡的利用率、显存、温度、功耗、错误计数
服务视图	每个模型实例的 QPS、TTFT、TPOT、P95 / P99、错误率
集群视图	多节点资源分布、掉卡、重启、调度失败、热点节点

对于大模型推理，硬件监控最好和推理框架指标一起看，例如：

当前 running requests。
waiting queue 长度。
batch size。
KV Cache 使用率。
prefill / decode token 吞吐。
TTFT 和 TPOT。
由于 OOM、限流、超时导致的失败数。

只有 GPU 指标没有业务指标，容易误判。例如 GPU 利用率低，可能是没有流量，也可能是 tokenizer、调度、网络、存储或 batch 策略拖住了 GPU。

4. GPU 利用率怎么看

GPU utilization 不是越高越好，也不是越低就一定浪费。它必须结合场景判断。

场景	常见现象	判断方式
训练	GPU 利用率应相对持续较高	如果周期性掉到很低，检查数据加载、通信、checkpoint
推理 prefill	短时间算力压力高	长 prompt、批处理会拉高利用率
推理 decode	可能更受显存带宽影响	小 batch 下 GPU utilization 不一定很高
低流量服务	GPU 利用率低是正常现象	重点看延迟、成本和扩缩容策略
高并发服务	GPU 利用率高但 P99 差	检查队列、batch、KV Cache、限流和调度

常见误区：

只看平均利用率：平均 70% 看起来不错，但如果周期性掉到 0%，训练 step time 可能很差。
把低利用率都当成 GPU 问题：数据加载、CPU tokenizer、网络转发、存储读取都可能让 GPU 等待。
把高利用率都当成健康：GPU 满载但请求排队严重，用户体验仍然很差。
忽略 memory utilization：decode 阶段可能受显存带宽限制，而不是纯算力限制。

排查 GPU 利用率低时，可以按这个顺序看：

是否真的有足够请求或训练 batch。
CPU、tokenizer、数据加载是否成为瓶颈。
是否频繁等待网络、存储或 checkpoint。
batch 策略是否过于保守。
多卡通信是否拖慢 step 或 decode。
是否有某张卡成为 straggler。

5. 显存监控

显存是 LLM 部署中最容易触发硬错误的资源。推理时可以粗略理解为：

显存占用 = 模型权重 + KV Cache + 激活/临时张量 + runtime / workspace + 通信缓冲 + 预留内存池

生产监控要区分：

指标	含义	排障价值
used memory	已被进程占用或预留的显存	判断是否接近 OOM
free memory	当前剩余显存	判断是否还有突发余量
reserved memory	框架预留但未必实际使用的显存	区分正常预留和泄漏
KV Cache usage	KV Cache 块或页的使用率	判断长上下文和并发压力
OOM count	OOM 发生次数	判断是否需要限流或调整配置

显存高占用不一定是异常。vLLM、TensorRT-LLM、SGLang 等推理框架可能会预留大块显存来减少动态分配和碎片。真正要关注的是：

显存是否持续增长且不回落。
OOM 是否集中在长输入、高并发或特定模型版本。
空闲显存是否足以覆盖 P95 / P99 请求长度。
是否有无关进程占用同一张卡。
是否多实例共用 GPU 导致互相抢显存。

更多显存组成见：显存和模型尺寸与显存估算。

6. OOM 排查

OOM 要先判断发生阶段，不同阶段的处理方向完全不同。

阶段	典型现象	常见原因	处理方向
模型加载	服务启动失败	权重太大、精度太高、GPU 不够	换小模型、量化、多卡切分、换更大显存
prefill	长输入时报错	prompt 太长、batch 太大、临时张量过多	限制输入长度、调低 batch、启用更优 attention
decode	生成过程中显存上涨	KV Cache 增长、并发过高、输出过长	限制并发和输出长度、KV Cache 优化
长时间运行后	开始正常，运行一段时间后 OOM	显存碎片、泄漏、请求分布变化	重启实例、升级框架、调整内存池
多服务共存	单独运行正常，共存后失败	多进程抢显存	绑定 GPU、隔离实例、限制显存比例

排查步骤：

记录 OOM 的时间、模型、请求长度、并发和 GPU UUID。
确认 OOM 发生在加载、prefill、decode 还是运行一段时间后。
用 nvidia-smi 查是否有其他进程占用显存。
查看推理框架日志里的 max context、batch、KV Cache 配置。
检查最近是否改过模型精度、上下文长度、并发上限或框架版本。
用真实流量分布压测，而不是只用短 prompt 测试。

常用缓解手段：

降低 max_model_len。
降低最大并发或 batch 上限。
限制最大输入和输出 token。
使用 INT8 / INT4 量化。
启用 PagedAttention、KV Cache 量化或 FP8 KV Cache。
减少同一张卡上的模型实例数。
为热更新、突发流量和长尾请求保留显存余量。

不要只用“模型能启动”作为上线标准。上线前必须用接近真实的输入长度、输出长度和并发分布压测 OOM 边界。

7. 温度、功耗和降频

GPU 温度和功耗异常会直接影响性能稳定性。很多“吞吐突然下降”的问题，本质上是散热、供电或功耗限制导致的降频。

需要关注：

指标	异常表现	可能原因
temperature	温度持续偏高	风道差、机房温度高、灰尘、风扇异常
power draw	长期贴近功耗上限	任务满载、功耗限制过低、供电不足
clocks	频率低于预期	温度墙、功耗墙、驱动策略、MIG / vGPU 限制
throttle reason	出现 thermal / power throttle	散热或供电约束

现场可以看：

nvidia-smi dmon -s pucvmt
nvidia-smi -q -d TEMPERATURE,POWER,CLOCK,PERFORMANCE

处理方向：

检查机箱风道、风扇、灰尘和机房温度。
确认 GPU 是否长期触发 thermal throttle 或 power throttle。
检查功耗上限是否被人为设置过低。
检查同机多卡是否存在某张卡温度明显高于其他卡。
对高密度服务器，确认进风温度和机柜散热能力。

温度和功耗问题通常不是靠改模型参数解决的。如果硬件长期处于边界状态，即使服务能跑，也会带来延迟抖动和故障率上升。

8. ECC、Xid 和硬件错误

ECC 和 Xid 是 GPU 健康监控里最重要的错误信号。

8.1 ECC

ECC 用于发现和纠正显存位错误。需要区分：

类型	含义	处理建议
corrected ECC	已纠正错误	少量偶发可观察，持续增长要关注
uncorrected ECC	未纠正错误	高风险，建议隔离节点或更换硬件
volatile ECC	当前运行周期内统计	重启后可能清零
aggregate ECC	累计统计	用于判断硬件长期健康

如果 uncorrected ECC 出现，训练可能 silent corruption，推理可能产生错误结果或进程崩溃。生产环境应把这类节点从调度池摘除，保留日志后做硬件诊断。

8.2 Xid

Xid 是 NVIDIA 驱动报告的 GPU 错误代码，通常出现在系统日志或 dmesg 中。

查看方式：

dmesg -T | grep -i xid
journalctl -k | grep -i xid

常见诱因包括：

驱动或 CUDA 版本不兼容。
GPU 硬件异常。
PCIe 链路问题。
电源或散热问题。
kernel 执行异常。
容器或多进程访问 GPU 的方式不正确。

处理建议：

记录 Xid code、GPU UUID、时间和对应进程。
查同一台机器是否多张卡同时报错。
查是否伴随温度、功耗、ECC 或 PCIe 错误。
对比最近是否升级驱动、CUDA、内核或推理框架。
频繁复现时先摘除节点，再做驱动和硬件诊断。

不要只重启服务后继续使用。频繁 Xid 可能说明硬件或驱动状态已经不可信。

9. GPU 掉卡和驱动问题

GPU 掉卡通常表现为：

nvidia-smi 看不到某张卡。
容器内看不到 GPU。
训练任务 hang 住或 NCCL 报错。
推理 worker 重启后无法重新绑定 GPU。
系统日志出现 PCIe、Xid 或驱动错误。

基础排查：

nvidia-smi -L
lspci | grep -i nvidia
lsmod | grep nvidia
dmesg -T | grep -i nvidia
dmesg -T | grep -i xid

判断方向：

现象	可能原因
`lspci` 看不到 GPU	硬件、主板、供电、PCIe 插槽或固件问题
`lspci` 能看到但 `nvidia-smi` 看不到	驱动加载失败、版本不匹配、内核模块异常
宿主机正常，容器看不到	runtime、设备映射、权限或 Kubernetes device plugin 问题
任务运行中掉卡	Xid、过热、供电、PCIe 链路或驱动崩溃
多机任务 hang	某节点 GPU 异常触发 NCCL 等待

生产处理原则：

先隔离异常节点，避免调度新任务。
保留 nvidia-smi -q、dmesg、驱动版本和任务日志。
如果只是容器映射问题，优先修 runtime 或 device plugin。
如果宿主机也异常，不要反复拉起业务进程。
频繁掉卡的节点应做硬件巡检或返修。

10. 多卡和拓扑排障

多卡服务除了单卡健康，还要看 GPU 之间、GPU 和网卡之间的距离。

常用命令：

nvidia-smi topo -m
nvidia-smi topo -p2p r
lspci -tv
numactl --hardware

重点看：

GPU 之间是 PCIe、NVLink 还是 NVSwitch。
P2P 是否可用。
GPU 是否跨 CPU socket 通信。
网卡是否靠近参与 RDMA 的 GPU。
多卡任务是否被调度到拓扑不合理的卡组。

典型问题：

8 卡机器只用了拓扑距离很远的几张卡，通信慢。
GPU 和网卡跨 NUMA 节点，RDMA 性能差。
tensor parallel 跨了低速 PCIe 链路，吞吐不升反降。
某张卡变慢，导致整个数据并行任务等待。

多卡性能排障不要只看总 GPU 数。卡的位置、互联方式和调度分组会直接影响训练 step time 和推理延迟。

11. CPU、内存、存储和网络也要一起看

很多看起来像 GPU 的问题，根因不在 GPU。

表现	可能根因
GPU 利用率低	CPU tokenizer 慢、数据加载慢、请求不足、网络等待
首次请求很慢	模型冷加载、磁盘慢、权重未缓存
训练周期性卡顿	checkpoint 写盘、数据集读取、网络同步
推理 P99 高	队列堆积、长 prompt、日志阻塞、KV Cache 紧张
多副本扩容慢	镜像太大、模型权重分发慢、对象存储带宽不足

建议同步采集：

top
free -h
df -h
iostat -x 1
ip -s link
ss -s

LLM 服务里 CPU 和系统内存经常被低估。tokenizer、请求解析、RAG 检索、日志、后处理和调度都可能发生在 CPU 侧。GPU 很贵，但它经常在等别的环节。

12. 告警建议

告警不要只按固定阈值写死，要结合趋势、持续时间和业务影响。

告警项	建议判断
GPU 不可见	任意生产 GPU 从监控中消失，立即告警
GPU 利用率异常低	有流量或训练任务时持续低利用率，告警
显存接近上限	持续高占用且剩余空间不足以覆盖突发，告警
OOM	任意 OOM 计数增加，按服务等级告警
温度过高	持续高温或出现 thermal throttle，告警
功耗/频率异常	满载时频率明显低于基线，告警
ECC uncorrected	立即告警并隔离节点
Xid	记录所有 Xid，频繁或严重 Xid 立即告警
worker 重启	GPU worker 异常重启次数增加，告警
P99 延迟恶化	和硬件指标联动分析

告警需要避免两个极端：

阈值太低，频繁误报，最后没人看。
阈值太高，只在服务已经不可用时才报警。

更好的方式是建立基线。例如同一型号 GPU、同一模型、同一并发下，正常的 GPU 利用率、显存曲线、温度、功耗、TTFT 和 TPOT 大致是什么样。偏离基线比单个阈值更有诊断价值。

13. 排障流程

遇到线上硬件相关问题时，可以按下面顺序收敛。

13.1 先确认影响面

是单个请求、单个模型、单个实例，还是整个集群。
是训练、推理、模型加载，还是扩容阶段。
是平均延迟变差，还是 P99 变差。
是吞吐下降，还是错误率上升。
是否集中在某台机器、某张 GPU、某个模型版本。

13.2 再看硬件健康

nvidia-smi
nvidia-smi -L
nvidia-smi -q
dmesg -T | grep -i xid

关注：

GPU 是否全部可见。
是否有 ECC 或 Xid。
温度和功耗是否异常。
显存是否被意外进程占用。
驱动和 CUDA 版本是否变化。

13.3 然后看资源瓶颈

现象	优先检查
OOM	显存、KV Cache、请求长度、并发、其他进程
GPU 利用率低	CPU、数据加载、tokenizer、网络、batch
GPU 利用率高但慢	显存带宽、队列、batch、P99 长请求
多卡慢	拓扑、NCCL、NVLink / PCIe、NUMA、网卡位置
运行一段时间后变慢	显存碎片、日志、缓存、温度、泄漏

13.4 最后做复现和隔离

用相同模型、相同输入长度、相同并发复现。
对比健康节点和异常节点。
单卡任务和多卡任务分开测试。
业务流量和硬件压测分开测试。
异常节点先隔离，避免继续污染线上结果。

14. 常见场景速查

问题	快速判断	常见处理
模型启动 OOM	权重和显存余量不匹配	量化、换卡、多卡切分、减小模型
长上下文 OOM	KV Cache 增长过快	限制上下文、降低并发、KV Cache 优化
GPU 利用率低	GPU 在等 CPU / IO / 网络 / 请求	查 tokenizer、数据加载、batch 和队列
P99 延迟高	长尾请求或队列堆积	限流、分级调度、拆分长短请求
训练 hang	某节点或通信异常	查 NCCL、Xid、网络、掉卡
吞吐突然下降	降频、温度、功耗或某实例异常	查温度、clock、power、worker 日志
`nvidia-smi` 无卡	驱动或硬件异常	查 `lspci`、内核日志、驱动模块
单机正常多机慢	网络或拓扑问题	跑 NCCL tests，查 RDMA / RoCE / IB

15. 上线检查清单

上线前建议确认：

每张 GPU 都有稳定 UUID 标签。
DCGM 或等价采集已经接入监控。
服务指标和 GPU 指标能按实例关联。
已经用真实输入长度和并发压测。
已知 OOM 边界和降级策略。
已配置最大输入、最大输出和最大并发限制。
已有 ECC、Xid、掉卡和 worker 重启告警。
多卡服务已经验证拓扑和 NCCL 性能。
模型权重、镜像和缓存路径不会拖慢扩容。
异常节点有隔离和恢复流程。

16. 总结

硬件监控不是单独看 GPU 利用率，而是把模型、请求、推理框架、GPU、显存、CPU、存储、网络和调度放在一起看。

业务异常
  -> 定位模型 / 实例 / 节点 / GPU
  -> 查看显存、利用率、温度、功耗、ECC、Xid
  -> 关联请求长度、并发、队列、KV Cache
  -> 区分 GPU 问题、系统问题和调度问题
  -> 隔离、复现、修复、建立告警

真正可靠的 LLM 部署，需要在上线前知道资源边界，在运行中持续记录硬件状态，在故障时能快速把“哪张卡、哪个进程、哪个请求、哪个时间点”串起来。这样排障才不会停留在重启服务和猜测原因。

1. 监控对象​

2. nvidia-smi 能看什么​

3. DCGM 和生产监控​

4. GPU 利用率怎么看​

5. 显存监控​

6. OOM 排查​

7. 温度、功耗和降频​

8. ECC、Xid 和硬件错误​

8.1 ECC​

8.2 Xid​

9. GPU 掉卡和驱动问题​

10. 多卡和拓扑排障​

11. CPU、内存、存储和网络也要一起看​

12. 告警建议​

13. 排障流程​

13.1 先确认影响面​

13.2 再看硬件健康​

13.3 然后看资源瓶颈​

13.4 最后做复现和隔离​

14. 常见场景速查​

15. 上线检查清单​

16. 总结​