很多人把 DeepSeek 的小尺寸模型下载下来，双击跑一下发现要么加载半天，要么一提问就报显存不够，其实问题多半不在显卡本身，而在量化档位、上下文长度和框架的显存预留没对上。这篇不堆参数表，而是从「你手上有什么卡」出发，给一套按显存反推配置、按量化反推质量的动作清单，顺便说清哪些情况下这台机器根本不该硬跑。
把 DeepSeek 的小尺寸模型拉下来想本地跑，结果加载半天没动静，或者刚问一句就提示显存不足——这种情况太常见了。多数时候不是你的卡太差，而是量化档位选高了、上下文长度开太大了、或者框架悄悄做了显存预留你没算进去。
这篇不给你背参数表，而是从「你手上是什么卡」出发，反过来推该选什么量化档、上下文留多长、要不要开并发。先给结论：显存够不够，取决于权重、KV 缓存、框架开销这三块加起来的峰值，而不是只看模型文件多大。下面逐块拆。
为什么小模型的显存总对不上
最常见的误判是只盯着参数量。一看到「小模型」就觉得随便什么卡都能跑，结果人家说的是一份已经量化过的权重文件，你下的是原始精度版本，两者体积差着好几倍。还有一个坑是只算权重、不算运行时开销，加载成功不等于能连续对话。
- 只看参数量、不看量化档位：同一个模型不同量化版本，占用能差出一大截
- 只算权重、不算 KV 缓存和框架预留：一开长上下文或多轮对话就爆
- 把「能加载」当成「能用」：加载进显存只是起点，跑起来还要额外空间
- 忽略内存和磁盘：加载阶段卡住不动，往往压根不是显存的问题
同样的权重在不同框架下占用差别也不小。有的框架会预留一块固定缓冲，有的会把部分层放到内存里换显存，还有的默认把最大上下文拉到很大。具体某版本在某框架下的表现，到 工具目录（/tools） 里对照着看当时的说明更靠谱，别凭印象。
先把权重显存这笔账算对
权重的估算思路很简单：参数量乘以每个权重占用的字节数，再乘一个额外开销系数。参数量看模型说明，字节数取决于量化档位，额外开销系数是给框架的临时缓冲留的余量，一般往上浮一档更保险。这三样里，只有字节数是你能直接选的。
| 量化档位方向 | 每个权重大致字节数 | 适合的用途 | 不适用的情况 |
|---|---|---|---|
| 高精度档 | 偏多 | 摘要改写、需要稳定指令跟随 | 显存紧张、只做简单补全 |
| 中等档 | 居中 | 通用问答、分类抽取 | 对格式稳定性要求极高的场景 |
| 低比特档 | 偏少 | 单轮补全、草稿生成 | 长指令、复杂格式、中文标点要求严 |
| 最低档 | 最少 | 只做关键词或短分类 | 任何需要连贯输出中文的任务 |
注意这张表只给方向，不给具体数字——档位和字节数的对应关系会随量化方案变化，到 模型资料库（/models） 核对当前那版的具体说明。估算出权重占用后，记得它只是下限，下面还要往上加。
低比特档位不是不能用，而是要看任务。做选择题式的分类，低档也能扛；一旦要它按固定格式输出、或者整段中文改写，低档经常开始丢标点、漏指令。出现这种情况就是该往上调一档的信号，而不是继续调参数硬撑。
上下文长度才是显存刺客
KV 缓存会随上下文长度线性增长，上下文拉得越长，它越可能比权重本身还占地方。很多人权重算得好好的，一开长上下文就崩，就是漏了这一块。真正决定你能开多长的，是「权重加 KV 缓存」的合计峰值。
- 先定任务需要多长上下文个人闲聊和短问答，几百到一千多 token 够用；整份文档问答、整个代码文件分析才需要长上下文。先问自己到底是哪类，别默认拉满。
- 在部署配置里限制最大上下文大多数本地框架都有最大上下文参数，把它压到任务实际需要的长度，省下来的显存可以直接换并发或者换更长的输出。
- 跑一轮观察有没有溢出连续对话几轮，看是否稳定。如果只在长输入时报错，基本就是上下文这块超了，回头再压。
什么情况必须保留长上下文？整份文档问答、跨文件代码理解，这类砍了就没法干活。什么情况砍掉没损失？单轮补全、短分类、固定格式抽取，砍到够用还能顺带提速。
别只盯显存：内存和磁盘同样会拦住你
加载阶段权重往往先要落到内存或磁盘上，内存不够的表现是「卡住不动」而不是直接报错，很容易被误判成显卡问题。所以排查前先看内存占用和磁盘剩余空间，别一上来就怀疑显卡。
- 内存不够：加载进度条走一半停住，风扇转但没反应
- 磁盘不够：下载解压中途失败，或提示写入错误
- 量化文件和原始权重混放：重复占空间，还容易路径冲突
- 加载到一半失败：多半是文件不完整或格式不被当前框架支持
磁盘占用这块，站内已有按文件体积逐项核对清单的思路，可以照那个方式先确认空间够不够，再谈显存。把原版权重和量化文件分开目录放，能省掉不少重复下载的麻烦。
量化档位怎么挑：按用途而不是按数字大小
挑档位的第一原则是先定用途再定档位，而不是谁数字小谁快就用谁。不同任务对精度的敏感度差别很大，选错档位的代价是输出质量肉眼可见地掉。
| 用途 | 精度敏感度 | 档位倾向 | 调档信号 |
|---|---|---|---|
| 摘要、改写 | 高 | 中高精度档 | 句子变碎、逻辑跳 |
| 分类、抽取 | 中 | 中等档 | 标签偶尔错、字段漏 |
| 代码补全 | 中高 | 中高精度档 | 括号不配、变量名乱 |
| 草稿、关键词 | 低 | 低比特档即可 | 几乎无伤大雅 |
低比特档的典型退化表现要记住：指令跟随变差、输出格式不稳、中文标点乱。出现这三类现象就先往上调一档，别在低档上反复调提示词。具体「档位对应什么卡、能跑多快」的数值，站内有页面持续更新，去那里对当时的数字比看我这里写死更靠谱。
并发上来之后显存和速度怎么变
并发数一增加，每个请求各自的 KV 缓存会一起增长，所以估算思路是单请求占用乘以并发数，再加上框架的固定开销。个人用基本是单请求串行，只有当多人共用或者要对外提供服务时，才值得认真算并发这笔账。
谈并发之前先量延迟基线，不然你连「变慢了多少」都不知道。拿自己的机器到 测速页面（/tools/speed-test） 跑一遍，记下单请求的响应时间，再决定要不要加并发。
- 单请求串行：个人本地使用，够用，省显存
- 低并发：小团队两三人轮流用，注意 KV 缓存同步增长
- 高并发：对外提供服务，通常得换卡或直接上 API
- 并发拉满才报错：说明不是权重问题，是 KV 缓存加上去超了
同一份权重，不同框架的显存表现差在哪
同样一份量化权重，换个本地框架跑，显存占用、加载速度、支持的量化格式都可能不一样。这里不写成排名，只说取舍方向：有的框架加载快但量化支持窄，有的占用控制得好但配置项多。
一个隐藏坑是量化格式选错，框架可能加载失败，也可能悄悄回退到 CPU 上跑。你以为在用显卡，其实全靠处理器在扛，慢得离谱还查不出原因。
- 确认真的跑在 GPU 上看框架日志或状态输出里有没有明确指出使用显卡设备，没有就是回退了。
- 确认量化格式被支持选框架明确支持的格式，别自己转一个不认识的丢进去。
- 对比两种框架的占用同一份权重分别加载，比峰值显存，选更合适的那个。
推理框架的横向对比站内有专门页面，这篇只聊和显存相关的差异。真要选型，去 排行榜与对比（/rankings） 看当时的结论，别只看单篇经验帖。
显存不够时的排查顺序
显存报警了别急着换硬件，按下面的顺序一条条试，绝大多数情况在前三步就能救回来。每一步都要有对应的观测指标，才能判断到底有没有起效。
- 限制上下文长度把最大上下文压到任务实际需要，重跑；观察是否还在长输入时报错。
- 降量化档位从当前档往下调一档，重跑；看显存峰值降了多少，输出质量掉了多少。
- 降并发把并发数降到单请求，重跑；如果一下就好了，说明问题在 KV 缓存叠加。
- 换框架换一个显存控制更好的本地框架试试；对比同一任务的峰值占用。
- 最后才考虑换卡前面都试过还不行，再评估是否需要更高显存的卡或直接改用 API。
什么情况该直接放弃本地跑？频繁长上下文、多人共用、需要稳定响应——这几种场景本地小模型经常力不从心，用 API 反而更省事、更稳。要不要换，到 价格追踪（/price-watch） 对照当时的成本再决定，别凭感觉。
下一步拿你自己的机器先跑一遍基线，再对照上面的顺序逐条排查，比反复猜卡够不够用高效得多。→常见问题
只有核显或者集显的笔记本，能不能跑这个尺寸的模型？
能加载不等于能用。核显通常要走共享内存，速度会慢到难以交互，长一点的回答要等很久。如果你的用途只是偶尔试玩，可以降量化档位、缩短上下文硬撑；如果要每天拿它干活，建议直接走 API，或者参考站内算力平台的租卡思路换一条路。
为什么我按参数量算出来的显存够，实际却报显存不足？
常见原因是只算了权重，没算 KV 缓存和框架预留。上下文设得越长、并发越多，KV 缓存越大；框架本身还会占一部分做临时缓冲。把最大上下文长度调小、并发降到 1，再重新加载一次，通常就能看出差在哪一部分。
量化到最低档会不会把模型能力废掉？
看任务。做摘要、分类、关键词抽取这类容错高的活，低档位通常还能用；做需要严格格式输出、多步推理或者代码补全的活，低档位容易出现指令跟随变差、格式跑偏。判断办法是拿你自己的几条真实输入跑一遍对比，别只看别人说能跑。
该在配置里把上下文长度设成多少？
按你实际最长的一条输入来定，不要照抄模型支持的上限。留一点余量给输出，剩下的都砍掉，砍下来的显存可以直接换更稳的响应。如果确实需要处理整篇长文档，更现实的方案是分段处理或者换用长上下文模型，而不是硬撑本地小模型。
同一台机器，换框架能不能省出一块显存？
会有差别，但方向不一定。有的框架预分配更激进、速度快但吃显存，有的更省但加载慢、首次响应久。选框架要连加载速度、量化格式支持一起看，站内有本地部署框架的对比页可以对着挑，别只盯显存一个数。
