显卡跑得好好的，nvidia-smi 一看显存占了八成多，到底该不该慌？显存使用率没有统一的「正常值」，取决于模型大小、量化档位、上下文长度和并发数。这篇给你一套判断口径和排查顺序：先分清固定占用和浮动占用，再按进程、缓存、碎片、泄漏四层往下查，最后说清什么情况下高占用其实完全正常。
显卡跑得好好的，nvidia-smi 一看显存占了八成多，到底该不该慌？这事没有统一的答案。显存使用率不存在一个放之四海皆准的「正常值」，它取决于模型大小、量化档位、上下文长度和并发数。同一张卡跑不同配置，正常占用区间能差出一大截，脱离负载谈百分比基本没有意义。
这篇给你一套可落地的判断口径：先把固定占用和浮动占用分开，量出你这台机器的基线，再按进程、缓存、碎片、泄漏四层往下查，最后说清哪些高占用其实完全正常、不用乱动。想把结论落到自己机器上，可以先到站内的部署测算页面按你的模型和量化档位算一遍，心里有个数再对照监控。
先破一个误区：不存在统一的「正常显存使用率」
很多人问「多少算正常」，潜台词是想要一个阈值，比如超过多少就报警。但阈值是跟着负载走的：同一张卡跑小模型短上下文，占用可能很低；换上大模型、长上下文、量化档位又低，占用直接顶到高位，这并不代表出问题。所以别盯百分比，盯信号。
- 是否还有余量：峰值时显存没被吃满、还能再进来一路请求，这就是健康；
- 是否随时间单调上涨：空闲时段占用应该回落或持平，一路爬升才可疑；
- 是否和吞吐对得上：请求数涨、占用跟着涨是正常的，请求停了占用还涨就不正常；
- 固定与浮动要分开：模型权重和运行时是固定底，KV 缓存和请求是浮动量，混在一起看最容易误判。
先量出你这台机器的基线，再谈正不正常
没有基线就没有异常。同型号的卡、同样的模型，在不同机器上因为驱动、框架版本、预留池配置不同，占用也不一样。所以第一步不是查问题，而是给自己这台机器记几个基准数，之后所有「看着变高」都拿它对照，而不是凭感觉。
- 空载记一次只加载模型、不接任何请求，等几秒稳定后记下显存占用。这就是权重加运行时的固定底，也是后面所有判断的起点。
- 单请求记一次发一条正常长度的请求跑完，记录峰值。峰值减掉空载底，得到单条请求的浮动量。
- 加并发再记一次把并发逐步往上加，观察显存增量和吞吐是否同步。每路并发的增量记下来，并发上限心里就有数了。
- 写进运维记录把这三个数连同模型、量化档位、上下文长度一起记下来，放在随手能查到的地方。下次报警直接对照，不用重新测。
这几个数会随框架和配置变，所以定期复测一次比较稳妥。具体模型的显存占用测算和不同量化档位的差异，可以到站内的部署测算页面按当时的配置核对数字。
使用率偏高时，按这四层顺序排查
排查要有顺序，别一上来就怀疑泄漏。按下面的层次往下走，绝大多数「显存异常」在前两层就能解释清楚，真正需要深挖的很少。下面这张表把每层的典型特征和动作列在一起，照着做就行。
| 排查层 | 典型特征 | 先做什么 |
|---|---|---|
| 进程层 | 空载占用就偏高，或换了模型没变化 | 看有哪些进程在占卡，清掉僵尸进程和没退干净的服务 |
| 缓存与显存池 | 空闲后占用不回落，但请求一进来还能跑 | 这是框架设计行为，不是泄漏，确认预留池配置是否过大 |
| 碎片层 | 利用率高但可用余量小，长跑之后变差 | 请求长度忽长忽短时明显，重启一次能缓解就是碎片 |
| 泄漏层 | 空闲后占用仍单调上涨，重启也很快回到高位 | 压测前后对比占用曲线，能稳定复现才值得深挖 |
第三层的碎片和第四层的泄漏最容易混。区分方法很简单：重启后占用回落且能稳定维持，多半是碎片，考虑固定请求长度、定期重启；重启后很快又爬到高位、且和请求数严格同步上涨，才往泄漏方向查。缓存与显存池的典型行为是「占着不还但能复用」，框架主动保留是为了下次分配更快，这是预期内的。
这些情况占用高是正常的，别乱动
有些高占用就是设计如此，看到就重启反而打断了正常服务。判断标准是看负载和占用是否匹配：长上下文、高并发、大预留池这几种情况，占用高是取舍的结果，不是故障。
- 长上下文场景：KV 缓存本来就会吃掉一大块，上下文越长越明显，属于正常开销；
- 并发拉满的批处理：为了吞吐故意把显存用满，牺牲一点余量换吞吐，是预期内的取舍；
- 预留池配得大：权重本身不大但预留池大，比例看着高，实际还留着可用余量；
- 要警惕的反例：没有请求时占用仍持续爬升、重启后立刻回到高位、同一负载下占用比之前明显更高。
换句话说，正常与否要看「和什么比」。和空载比、和昨天的同负载比、和吞吐曲线比，都比单看一个百分比靠谱。如果确实需要压低占用，量化、分片、offload 是几条主要路径，具体怎么选、各自的代价是什么，站内有一份显存优化的清单可以对照着看。
把监控做成习惯：看什么、多久看一次
排查是一次性的，监控是长期的。与其等出问题再查，不如把几个关键曲线盯住。短周期看瞬时值和温度，防止突发打满；长周期看占用曲线的形状，有没有台阶式上涨、有没有和请求数脱钩，这些形状比单点数值更能说明问题。
出现异常时，先做一次干净重启再复现。能稳定复现的才值得深挖，不能复现的多半是上一次运行残留或缓存没释放。把「请求数—显存占用」两条线画在一张图上，是最省事的判断办法：两条线同步涨是正常，请求停了占用还涨就有问题。平时想快速确认机器状态，可以用站内的测速工具跑一轮，结合监控一起看。
下一步先量出自己这台机器的基线，再对照站内的部署测算页面核对当前配置的预期占用，心里有数之后报警才有意义。→常见问题
显存占到 90% 以上是不是就要出事？
不一定。关键看有没有请求在排队、有没有 OOM 报错、占用是不是稳定在一个高位。稳定高位说明你把余量用上了，是好事；但如果同时伴随请求变慢、偶发 OOM，说明余量不够，要么降并发要么降上下文。
怎么快速区分是显存泄漏还是框架缓存？
看空闲态。停掉所有请求等几分钟，占用回落说明是缓存，属于正常；占用一直不降、并且随累计请求数单调上涨，才更像泄漏。另一个办法是重启服务后跑同样的压测，两次曲线形状差很多就值得查。
同一张卡，为什么换个模型占用差这么多？
权重体积、量化档位、上下文长度、注意力实现方式都会影响。想横向比，先对齐这四个变量，再拿站内部署测算页面按同一口径算一遍，不然比出来的数没有参考价值。
