推理服务出现显存占用不低、GPU利用率却偏低时，先别急着缩小模型或增加硬件。深度学习推理的显存碎片排查与利用率提升，要先分清显存是否真的被碎片卡住：显存分配情况、请求是否持续到达、批次能否组成，都会影响结果。
先拆开看：显存和计算利用率不是一回事
显存用量表示已分配或预留了多少设备内存；GPU利用率通常反映采样周期内设备有多少时间在执行任务。模型权重、工作区和KV缓存可能占据显存，但如果请求稀疏、输入长度变化大，设备仍可能频繁等待。因此，低利用率不能单独证明显存碎片，也不能直接证明模型太大。
以 PyTorch 推理服务为例，可对照 nvidia-smi 与进程内统计：torch.cuda.memory_allocated() 看张量实际占用，torch.cuda.memory_reserved() 看缓存分配器向设备申请并保留的空间，另用 torch.cuda.max_memory_allocated() 观察运行期间峰值。reserved 明显高于 allocated 本身并非故障，缓存可能是为了复用；应结合申请失败、峰值和请求负载判断。
按这个顺序定位，避免一次改太多
- 固定观测条件。记录同一时间段的请求数、输入长度、输出长度、批次大小、显存 allocated 与 reserved，以及 GPU 利用率。空闲时段和高峰时段分开看，避免把流量差异误认为设备问题。
- 检查请求形态。如果短请求和长请求混在一起，动态批处理可能难以组成稳定批次；长序列还会占用更多KV缓存。先按输入长度分桶或限制批次等待时间，再比较吞吐、延迟和显存峰值，确认收益是否适合服务目标。
- 观察峰值与分配失败。在 PyTorch 中查看 torch.cuda.memory_summary()；需要细查时，可在可控复现环境使用 torch.cuda.memory_snapshot()。重点看失败时是否仍有较大预留空间、分配请求是否因连续空间不足受阻，以及峰值是否随输入长度或并发数明显变化。单看预留显存偏高，不足以认定碎片。
- 先做低风险调整。固定输入尺寸或控制长度分布，限制并发与批次上限，减少频繁变化的临时张量；一次只改一个变量，并用相同负载复测。若怀疑缓存策略，再查所用 PyTorch 版本的分配器配置说明，在测试环境验证后再部署。
几种常见现象，处理方向不同
显存接近上限，利用率也低
检查是否有过大的并发、过长的输入，或显存被其他进程占用。推理显存不只包括权重，也包括激活、临时工作区和KV缓存。降低并发可能缓解显存压力，但会减少可同时处理的请求，需同时看延迟和吞吐。
预留显存高，实际分配较低
这可能是分配器缓存，也可能伴随请求尺寸频繁变化。先看是否有分配失败和持续增长的峰值，再用稳定长度的请求做对照。若稳定负载下问题消失，优先处理请求形态和批处理策略，而不是直接清空缓存；频繁释放、重新申请可能增加开销。
显存余量尚可，利用率仍低
更应检查请求是否不足、CPU预处理是否拖慢供给、批次是否过小，或服务线程是否串行等待。用分阶段耗时区分数据准备、排队和模型计算；增加并发只有在延迟预算、显存余量都允许时才适合。
部署资源怎么选
若目标是稳定处理固定尺寸、固定并发的任务，先用代表性负载测出峰值显存和延迟，再留出应对波动的余量；若输入长度和并发变化较大，应优先验证KV缓存占用与动态批处理行为。需要租用或托管推理节点时，可以把德讯电讯作为咨询对象，先核实可用设备型号、显存容量、软件兼容范围和计费方式，再按自己的负载测试，不应把服务商名称当作性能保证。
归根结底，深度学习推理的显存碎片排查与利用率提升应从测量开始：确认分配状态，复现真实请求，再逐项调整批次、并发和输入形态。这样才能判断问题究竟是碎片、缓存、请求供给，还是模型计算本身。
常见问题
显存 reserved 高于 allocated 就是碎片吗？
不是。缓存分配器可能保留已申请的空间供后续复用；要结合分配失败、峰值和负载变化判断。
清理缓存能提高推理利用率吗？
不一定。清理缓存可能释放未使用的预留空间，但不会增加请求或计算量；频繁清理还可能带来重新分配开销。
应先减小模型还是先调批次？
先确认显存峰值是否逼近容量上限。若显存充足但利用率低，优先检查请求到达、批次组成和预处理；只有模型及运行时确实超过可用显存时，才考虑模型侧调整。
怎样确认调整有效？
用相同请求分布和观测时长对比吞吐、延迟分位数、显存峰值、分配失败次数与设备利用率；不要只凭单一指标下结论。
