显存碎片是怎么回事
长跑的推理进程不断申请、释放不同尺寸的显存块，空闲空间被切成许多小洞，最后出现「总容量够、却没有连续大块可分配」的失败。它的典型表征是预留量高、实际占用低，报错时还显示有大片缓存未被使用。治理方向是让分配更规整，或定期把进程重启到干净状态。
基本信息
| 成因 | 不同尺寸块反复申请与释放 |
|---|---|
| 现象 | 总量够但申请大块失败 |
| 表征 | 预留高、实际占用低 |
| 缓解 | 调整分配策略或定期重启 |
| KV 侧 | 分页管理本身已减轻碎片 |
典型使用场景
- 长跑实例偶发 OOM，而显存看着还够
- 排查「重启就好、跑两天又坏」的规律性问题
- 给进程加健康重启策略前先确认收益
- 评估切换分配策略能否真正缓解
- 把 OOM 发生时间与实例运行时长一起记录，识别碎片型规律
两个常用开关
两个常用开关
# 先试其一，不要同时开，便于归因
# PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
# PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:512
# 观察预留与实际占用的差额
nvidia-smi --query-gpu=memory.used --format=csv -l 1三个量怎么看
| 量 | 含义 | 异常表现 |
|---|---|---|
| 预留量 | 已向驱动申请 | 长期高于业务所需 |
| 实际占用 | 被张量使用的部分 | 与预留差距大 |
| 失败时机 | 申请连续大块时 | 峰值与碎片叠加触发 |
分页管理的 KV 缓存池本身已减轻 KV 侧碎片；权重加载与临时张量仍走常规分配器，需要常规手段处理，两部分要分开看。
治理顺序先看负载趋势：如果请求长度与并发在持续上涨，根因是容量而不是碎片，加重启只是把症状往后推。
碎片与容量是两个方向：前者随时间累积、重启有效；后者随负载变化、重启无效。先用这个特征区分，再决定治理方案。
重启后把显存曲线与上一次对比：确认碎片确实被清掉，而不是碰巧这批请求都比较短。