显存占用监控在推理平台的落地，核心不是“看数字”，而是建立一套从采集、告警到自动调度的闭环机制，让每一块GPU都花在刀刃上。
做过推理服务的人都有这种体验：模型上线时显存看着刚好够用，跑几天后莫名其妙OOM；或者一张卡上占着3个实例，其中两个其实在摸鱼，显存不像CPU利用率那样波动剧烈，它是“温水煮青蛙”式的风险源，今天这篇就聊聊,怎么把显存监控从工具体系真正落到业务里。
为什么显存监控在推理平台上是硬需求
推理平台和训练平台最大的区别在于服务连续性，训练任务挂了可以重启，推理服务挂了直接损失线上请求，而显存问题正好是推理服务最常见的“隐形杀手”。
显存泄漏是推理服务最长尾的故障
推理框架加载模型、处理请求时，如果存在张量缓存未释放、动态shape导致的内存碎片，显存占用就会缓慢爬升，业内专家指出，这种泄漏在长稳运行下几乎是必然出现的，只是时间快慢的问题，没有监控，你只能等OOM告警响了再去手动重启,客户体验已经受损。
多模型共存让显存分配变成“搭积木”
很多推理平台为了降本，会把多个小模型塞进同一张GPU，这时候显存监控的粒度就很重要你得知道每个实例实际占了多少，是峰值占得多还是均值占得多，否则新模型调度上去,可能一启动就把别人的显存挤爆。
显存监控直接决定推理平台的成本核算
GPU是推理平台最贵的资源，老板问你“卡都用满了吗”，你不能只回答“任务都在跑”，显存利用率是比“是否空闲”更精细的成本指标。显存占用率长期低于50%的卡，本质上就是钱在睡觉。
推理平台显存占用监控怎么实现
“显存占用监控怎么实现”是运维同学最常搜的词，实现路径分三层：采集层、存储层、展示告警层，不需要一上来就搞复杂架构,从最少必要功能起步即可。
采集层：别只盯着nvidia-smi裸奔
nvidia-smi是最基础的命令，但它的输出是瞬时的，对于监控来说有两个硬伤：一是拿不到历史趋势，二是无法区分进程内不同实例的占用,实用的方案是组合拳：
- 用
nvidia-smi --query-gpu=memory.used,memory.total --format=csv定时抓取，配合crontab写入时序数据库（如Prometheus）。 - 针对单个进程的显存，使用
nvidia-smi --query-compute-apps=pid,used_memory --format=csv,这个能看到每个PID的显存占用。 - 如果跑的是Triton或TensorRT，还需要接框架自己的metrics接口，它们能输出每个模型实例的显存统计,比底层命令更准确。
存储层：时序数据是标配
建议直接把监控数据打到Prometheus里，用node_exporter + nvidia_gpu_exporter这样的标准组件，数据保留期至少
30天，因为显存泄漏的周期往往以周为单位，如果不想自建，云厂商的托管监控服务也能用,但要留意采集粒度和维度是否支持GPU标签。
展示与告警：别等OOM才报警
告警阈值不能拍脑袋定，行业共识认为，显存使用率超过85%就要注意，连续5分钟超过90%应该触发警告，但更重要的是“变化量告警”比如一个实例的显存每小时增长超过2%，即便绝对值不高，也意味着可能存在泄漏,用PromQL写个简单的增长率查询即可实现。
落地实操：从采集到告警的完整步骤
光讲概念没用，给一套可操作的路径，假设你手里有台NVIDIA A10,跑着两个TorchServe实例。
第一步：部署基础采集器
在GPU节点上安装nvidia_gpu_exporter，它默认暴露9101端口，输出nvidia_gpu_memory_used_bytes和nvidia_gpu_memory_total_bytes等指标，然后配置Prometheus的scrape job，每15秒拉一次,命令大致是：
docker run -d -p 9101:9101 --gpus all --name nvidia-exporter nvidia/gpu-prometheus-exporter
注意容器里要挂载/usr/bin/nvidia-smi,否则读不到数据。
第二步：在Grafana里画两条曲线
一条是整卡显存占用率，一条是每个实例（按PID或容器ID分组）的占用，后者在Grafana里用by (instance)聚合就行，曲线图的好处是能直观看到“锯齿状”的分配释放过程，如果锯齿的基线在缓慢上升,基本就是泄漏。
第三步：配置基于增长率的告警规则
Prometheus规则里可以这样写：
- alert: GPUMemoryGrowth expr: delta(nvidia_gpu_memory_used_bytes[1h]) > 2e9 for: 2h
意思是每小时显存增长超过2GB且持续2小时，就触发告警，这个阈值可以根据你的模型实际大小调整,小模型可以降到500MB。
第四步：联动自动处理
告警发出后，如果只是手动重启，那监控的价值少了一半，进阶做法是把告警接到Kubernetes的事件机制里，自动驱逐异常Pod并重新调度，但要注意，重启前必须dump当前显存快照和模型加载日志,不然下次复现还是两眼一抹黑。
GPU显存监控工具对比：开源自建vs云厂商方案
很多人纠结要不要自建，这里对比一下主流路径,帮你做决策。
| 方案 | 优势 | 劣势 | 适合场景 |
|---|---|---|---|
nvidia-smi + crontab + 文本日志 |
零依赖，任何机器都能用 | 无聚合能力，没有告警 | 临时排查、单机调试 |
Prometheus + nvidia_gpu_exporter + Grafana |
开源免费，生态成熟，可自定义告警 | 需要维护一套监控组件 | 中小规模推理集群（<50卡） |
| 云厂商GPU监控（如简米云、火山引擎） | 开箱即用，按维度自动聚合 | 细粒度指标可能收费，跨云迁移有锁定 | 用了云GPU且不想维护infra |
| DCGM（NVIDIA数据中心GPU管理器） | 指标丰富，支持多GPU深度诊断 | 部署复杂，学习曲线陡 | 大型生产集群，需要硬故障检测 |
工具对比的核心结论是：先看你的卡数和管理能力，卡少且需求简单，别上DCGM，累死运维，卡多且涉及多租户，那DCGM的XID错误检测、温度/功耗关联分析就是刚需。
推理场景下显存优化与监控的配合
监控不只是“看”，它要反过来指导优化，这里说一个真实常见的场景：BERT模型用TorchServe部署，默认加载PyTorch的CUDA缓存，显存占用可能虚高，监控发现某个实例显存利用率长期只有30%，但你实际压测又发现吞吐没问题这是PyTorch的memory_caching在起作用，这时可以通过torch.cuda.empty_cache()或max_split_size_mb参数调整缓存策略,把显存还给其他任务。
小技巧：用监控数据反推batch大小
你不需要盲试batch size，看监控曲线里显存的“波峰-波谷”差值，这个差值就是单次推理的临时张量开销，如果差值远小于总显存，说明batch size还有提升空间，反过来，如果波峰触顶但波谷很低，说明缓存碎片化严重，考虑换用torch.cuda.memory_stats()来定位具体哪类张量占了大头。
多租户隔离时，监控粒度必须到“容器”级
在K8s里跑推理，nvidia-smi看到的PID是宿主机视角，很难对应到Pod，要么用nvidia-ml-py库结合容器cgroup来聚合，要么直接改Pod的resources字段，让K8s的Device Plugin去上报显存，推荐后者，因为nvidia-smi在MIG模式下会看不到子实例，而Device Plugin能准确感知MIG分区的显存。
显存泄漏的排查路径：监控数据怎么用
一旦告警触发，你手里有的是一堆时序曲线，别急着翻代码,按这个顺序查：
- 看趋势曲线的斜率变化：如果斜率是突变式的，多半是某个请求触发了异常分支,比如超长输入序列导致中间张量暴涨。
- 对比同一模型在不同GPU上的表现：如果A卡泄漏但B卡不泄漏，大概率是GPU硬件故障或驱动版本不一致,而不是代码问题。
- 抓取泄漏前的堆栈：在告警触发后，用
py-spy dump --pid <pid>抓Python栈,看是否卡在某个自定义算子或数据集加载逻辑上。
常见问题排查：显存占用虚高怎么处理
有些“显存占用”其实不是真占用，比如CUDA的缓存策略会让nvidia-smi显示很高，但实际模型不一定一直在用，区分方法是执行torch.cuda.empty_cache()后立刻看那条曲线，如果
掉了一块，说明是缓存；如果纹丝不动，才是模型权重加激活值的真实占用，TensorRT的显存池策略类似，启动时预留大块显存，运行时复用，这时监控指标要看“实际使用峰值”而不仅是“已分配显存”，如果你是跑大模型推理，注意FlashAttention之类的算子会额外占显存,监控曲线里出现周期性脉冲是正常的。
为什么监控落地后你的平台算力反而“变多”了
很多平台部署显存监控后，反而能多塞几个实例，原因很简单以前为了保证不OOM，预留了20%~30%的冗余显存，有了精确监控和自动扩容，冗余可以压缩到10%以下，以一个8卡A100节点为例，每卡还有30GB显存可挖掘，就能多部署2个7B参数的模型实例，这不是玄学，是监控给你敢于“贴着边缘跑”的信心。
不过要泼一盆冷水：监控本身也会消耗资源，采集频率过高（比如1秒一次）会额外占用GPU的context，对推理时延有微妙影响，实测下来，15秒采集间隔既不影响性能，也不会漏掉瞬时尖峰，如果遇到显存突发暴涨的极端场景，配合nvidia-smi -lms 100做短时高频采样即可,不必长期开。
显存监控是推理平台精细化的第一步
没有显存占用监控，推理平台的运维就是“盲人摸象”，有了它，你才能回答三个问题：模型运行是否稳定、资源分配是否合理、成本有没有浪费，落地路径不需要一步到位，从一个节点、一个告警规则、一张曲线图开始，跑通后再逐步扩展，等你的平台能自动根据显存趋势调整实例数量时，运维才算真正从“救火”转向“经营”，最后记住一个原则，监控的终点不是报警，而是把报警变成自动动作,这才是它该有的价值。
Q&A：关于显存占用监控的常见疑惑
Q: 显存占用监控和显存溢出告警有什么区别？
A: 前者是持续性观测，记录趋势和分布，用于容量规划和泄漏排查；后者是阈值触发的事件，只负责告诉你“现在快满了”，实践中，溢出告警是监控规则的一种，但监控的价值远大于告警，它还能帮你看到“没溢出但效率低”的问题。
Q: 监控数据保存多久合适？
A: 如果只用于排障，保存7天足够，但要想分析显存泄漏的周期规律，建议原始数据保留30天，聚合数据保留3个月，超过3个月的监控历史基本没有业务价值,反而占用存储成本。
Q: 模型版本更新后，显存监控基线要不要重新校准？
A: 要，换模型结构、调batch size、改精度（如FP16转INT8），显存占用都会变化，建议每次发版后，观察24小时的监控曲线，把告警阈值按新基线上调或下调，不校准的话，要么频繁误报，要么漏报，上一次校准如果和模型发布是同一天,那排查时也更容易定位是模型变化导致的占用波动。