本地部署大模型显存不够怎么办

本地跑模型最常撞的墙就是显存爆掉：启动直接报 OOM，或者跑起来几轮对话就被吃掉一大截。很多人第一反应是把模型再压一档，结果质量掉得自己都不认识。这篇不讲原理课，只给一套排查顺序——先确认是权重占满还是上下文和并发吃掉的，再决定是降量化、开分层卸载，还是干脆换个参数规模更合适的模型。

本地跑模型最常撞的墙就是显存爆掉：启动直接报 OOM，或者跑起来几轮对话就被吃掉一大截，甚至几个请求一起进来就崩。很多人第一反应是把模型再压一档，结果质量掉得自己都不认识，白折腾一圈。

这篇不讲原理课，只给一套排查顺序——先确认是权重占满，还是上下文和并发吃掉的，再决定是降量化、开分层卸载，还是干脆换个参数规模更合适的模型。三条路各有代价，别一上来就全上。

先定位：显存到底被谁吃掉了

显存占用大致分三块：模型权重本身、KV 缓存、以及框架和显存碎片的预留。权重是固定开销，KV 缓存会随上下文长度和并发数往上走，碎片预留则跟框架和驱动有关。

• 把上下文长度调到最短、并发降到 1，再启动一次；如果这时候能跑起来，问题多半在缓存不在权重
• 记录现象属于哪一类：启动即 OOM、跑一会儿才 OOM、还是多请求才 OOM，三种对应三种解法
• 动手前先看显卡实际可用显存，别按标称算，桌面环境和其他进程会一直吃掉一块
• 顺手看一眼系统内存占用，卸载和切分路线会把压力转到内存上

路线一：降量化档位，代价最小但要看任务

从高精度往低精度走，显存大致按位宽等比下降，但质量损失不是线性的，越往低档位掉得越明显。所以降档不是越低越好，而是找到任务还能接受的那一档。

• 适合降档的任务：分类、信息抽取、摘要、格式转换，这类任务对细节容忍度高
• 不适合硬降的任务：长链条推导、代码生成、多语言混排，低档位容易出现结构崩坏
• 降档后做一次验证：拿五到十条你自己的真实输入重跑，对比输出结构和字段是否还稳定
• 不要同时堆多组档位组合，先固定一档跑通，再往下试一档，否则排查不了是哪一步坏的

各档位在常见硬件上的实际表现差异，站内有专门的实测记录，可以去 /tools/speed-test 看当时的数字，别只信参数表。

路线二：分层卸载与张量切分，慢一点但能跑起来

1. 先小比例试把少量层放到内存，启动后看显存余量和每 token 速度，能接受再加大比例
2. 盯住内存卸载是把压力从显存转到内存，内存不够会从 OOM 变成系统级卡死，先看内存余量
3. 多卡再谈切分张量切分把权重摊到多张卡上，但卡间带宽跟不上时，通信比计算还久，先确认互联条件
4. 记录可接受点把能跑稳的比例和速度记下来，下次直接复用，不用重新试

这条路线的特点是用速度换可行性。如果你要做的是交互式对话，速度掉太多体验会很差；如果是离线批处理，慢一点基本无所谓。

路线三：砍上下文和并发，最容易被忽略的一步

上下文窗口开多大，KV 缓存就跟着占多少。日常问答根本用不到超长窗口，把系统提示词和历史轮数裁剪一遍，往往能省出可观的一块，而且对多数任务效果没影响。

• 按实际需要设上下文长度，别默认拉满，拉满的代价是每轮都在为用不到的空间付费
• 并发数是显存杀手，单请求能跑不代表能同时跑几个，压测前先按单并发跑稳
• 裁剪历史轮数：把过期的对话摘要掉或直接丢弃，多数任务不需要全量历史
• 并发上限设在刚好够用的位置，超出就排队，别让请求把显存顶爆

这一块和量化叠加使用，通常比一味往低档位压更划算，因为省下来的显存不牺牲模型权重质量。

路线四：换模型或换卡，承认配置不匹配

模型规模和显存档位有基本对应关系，硬塞只会换来极低速度。换一个参数规模更合适的同系列小尺寸版本，微调和提示词的迁移成本最低，通常比继续折腾量化更省心。

判断线很直白：如果为了跑通已经牺牲到影响输出质量，那这条路线其实已经失败了，不如承认配置不匹配，换模型或换硬件。真要守住大模型，先按部署测算把卡数算清楚再下单，站内 /sites 有各家方案的对照，可以去核对当时的数字。