A
Member
推理服务跑久了，明明总显存还够，新请求却报显存不足，很多时候是显存碎片，不是真的没显存。我的排查和缓解思路如下。
一、先确认是不是碎片。看显存总量、已分配、空闲三者的关系：空闲不少、但最大连续块不够放一个请求，就是典型碎片；再看长短请求混跑时碎片是不是随时间变大，能快速定性。
二、查 KV Cache 预留策略。PagedAttention 这类分页机制就是把 KV 切成块，减少外部碎片；但块大小、预留比例设得不合理，内部碎片又会起来。先对照块大小和平均序列长度，别照搬默认配置。
三、查调度策略。长请求和短请求混在一个队列里，长请求占着大块显存不放，短请求进不来；按长度分桶、限制并发长请求数、给短请求留预留池，往往比加卡见效快。
四、查释放与复用。请求结束后的显存是不是及时释放、缓存有没有被前缀缓存长期占着、权重和激活的峰值有没有重叠，这些都要看时序曲线，不能只看某一时刻的快照。
五、留好基线。把并发数、平均长度、碎片率、拒绝率记成一组，改完配置再跑同一负载对照，别凭感觉说“好像稳了”。
你们多卡推理服务遇到显存碎片，最后是靠分页、调度还是预留池解决的？
一、先确认是不是碎片。看显存总量、已分配、空闲三者的关系：空闲不少、但最大连续块不够放一个请求，就是典型碎片；再看长短请求混跑时碎片是不是随时间变大，能快速定性。
二、查 KV Cache 预留策略。PagedAttention 这类分页机制就是把 KV 切成块，减少外部碎片；但块大小、预留比例设得不合理，内部碎片又会起来。先对照块大小和平均序列长度，别照搬默认配置。
三、查调度策略。长请求和短请求混在一个队列里，长请求占着大块显存不放，短请求进不来；按长度分桶、限制并发长请求数、给短请求留预留池，往往比加卡见效快。
四、查释放与复用。请求结束后的显存是不是及时释放、缓存有没有被前缀缓存长期占着、权重和激活的峰值有没有重叠，这些都要看时序曲线，不能只看某一时刻的快照。
五、留好基线。把并发数、平均长度、碎片率、拒绝率记成一组，改完配置再跑同一负载对照，别凭感觉说“好像稳了”。
你们多卡推理服务遇到显存碎片，最后是靠分页、调度还是预留池解决的？