显存不足的排查顺序
推理服务报显存不足时，先分清是物理占用真的不够，还是分配器缓存把空间占着：两者处理方式不同。读报错原文能看到申请大小、卡容量、已分配与已保留的完整账单。第二步确认这张卡上是否有其他进程占用，第三步才从并发、序列长度与精度三个方向收敛修复，避免一上来就重启。
取证
取证
# 卡的容量与占用
nvidia-smi --query-gpu=index,memory.used,memory.total --format=csv
# 谁是占用方
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv
# 报错原文：注意申请大小与已保留两项
grep -i -m5 'out of memory' server.log三步动作
- 先止损：限制在途请求数与显存预算比例，或临时调低上下文上限后重启
- 再核对：确认同卡是否还有训练任务、调试脚本等进程占着显存
- 后根治：按量化降精度、张量并行扩卡、限制输入输出长度三条路选一条落地
报错文本怎么读
| 信息项 | 含义 | 判断 |
|---|---|---|
| 申请大小 | 本次尝试分配的显存 | 明显偏大多与长输入或大批次有关 |
| 卡容量 | 设备总显存 | 与采购规格核对，确认没有看错卡 |
| 已分配 | 张量实际占用 | 持续接近容量说明业务本身偏重 |
| 已保留 | 分配器持有的总量 | 保留远高于分配时缓存占着空间 |
| 空闲但分配失败 | 总量够但没有连续大块 | 典型碎片特征，需要调整分配策略 |
重启回收的是碎片与缓存：如果同一个配置在运行一段时间后周期性失败，说明根因在于长度分布或并发上限，而不是服务本身不稳定。
把显存预算比例调到接近上限来「榨干」显卡会让问题更早出现：短上下文压测看不出异常，长上下文并发时会比之前更早失败。