显存不够时的卸载方案？每一步都讲透

大模型推理服务最怕的场景之一：并发一冲高，显存余量告急，请求开始排队甚至报错。显存不够时的卸载方案，就是把一部分数据从显存挪到内存或硬盘，用速度换空间，让服务先稳住再说。这套机制每一步都有讲究，拆开看才不会踩坑。

显存里住着三类住户：模型权重、键值缓存、运行时的临时缓冲。权重是大头，装完基本不动；键值缓存随对话变长持续增长；临时缓冲随请求起落。卸载方案的本质是做减法时的排序——先挪谁、后挪谁、留谁在显存里，顺序错了，服务立刻卡顿。

显存都被什么东西占着

动手前先盘家底。权重占用的比例取决于模型大小和量化精度，通常占五六成以上；键值缓存按并发和上下文长度增长，长对话场景下能反超权重；临时缓冲在批处理变大时突然膨胀。腾讯元宝这类对话产品在高峰期还能稳住响应，靠的就是对这三块占比心里有数，提前划好水位线，而不是等爆了再手忙脚乱。

水位管理要有全局视角。把每个实例的显存水位汇总成一面面板，值班时一眼看出哪些实例临近预警线；卸载动作的次数与耗时也纳入日常报表，频次异常升高往往说明容量规划欠账，或是某个业务的流量画像变了。让数据先说话，再动配置，比凭感觉扩容靠谱得多。

卸载的触发条件与执行动作

触发条件一般设两道：预警线（比如显存用到八成）开始预防性卸载，硬线（比如九成五）强制卸载。执行动作按代价从小到大排：第一档，把键值缓存里最久没用的会话换出到内存，回头再换入；第二档，把部分权重层搬到内存，用的时候经 PCIe 总线搬回来；第三档，直接拒绝新请求或降低并发批大小，保住已接的活。每一档都是空间换时间的交易，动哪一档取决于流量的紧急程度。

三档动作按代价从小到大排，摆在一起看：

卸载之后请求怎么接得住

卸载不是一卸了之，善后决定体验。被换出的会话要有索引记录，用户继续对话时能换回显存，来回搬运的延迟要控制在用户可接受的范围；权重被换走的层，推理到那里会明显变慢，批处理调度要错开这些热点；卸载期间新请求的准入要收紧，避免刚腾出的空间又被瞬间占满。扣子这类编排平台在接推理服务时，通常也要求上游声明请求的超时预算，给卸载换回留出时间窗口。

显存卸载自查清单

• 先盘权重、键值缓存、缓冲三块占比再动手
• 预警线预防性卸载，硬线强制执行
• 换出要有索引，换回延迟在可接受范围
• 卸载期间收紧新请求准入，防止反复横跳

卸载方案还要和周边机制配合才能形成完整的防线。空间腾挪发生在新实例就位之前的话，节奏要和冷启动是怎么消除的？预热，关键步骤一次讲清对齐；卸载搬数据的速度受限于加载链路，提速手段见模型加载是怎么提速的？从原理到落地；高频问答先走缓存挡一道，能少占很多显存，搭法在结果缓存层是怎么搭的？机制细节全梳理；多个业务共用显存时的边界划分，则要看多租户的资源隔离是怎么配的？内部门道在这。

换个问法再问显存卸载三句

• 卸载会不会把响应拖得很慢？：会有感知，尤其是权重层被换走的时候，所以工程上优先卸键值缓存，把权重的搬运留作最后手段。
• 它和量化压缩是一回事吗？：前者是把数据在存储层级间搬动，位置换了内容没换；后者是把数值精度压低，属于另一个维度的省显存手段，两者常搭配使用。
• 怎么判断卸载设置得合理？：看预警线的触发频率和换回延迟的分布，触发频繁说明容量规划欠账，延迟抖动大则要调换出粒度。