先说个丢人的事。有段时间我沉迷于“哪个模型版本文件小就往本地拖哪个”，结果拖回来一个 4GB 出头的量化包，看着挺小，显卡显存 8GB，感觉稳得很。结果启动命令刚敲下去，屏幕直接吐出一屏“显存不足”的红色报错，进程秒退。后来我才明白，本地部署大模型，真正要算的从来不是那个下载文件的大小，而是权重加载进显存后的实际占用，以及推理过程中上下文缓存还要再吃掉多少显存。这两块加起来，才是一份终端配置真正需要匹配的账。
折腾了大半个月，我把社区里常见的十几个尺寸档位挨个在本地跑了一遍，整理了这份实测版的大模型多版本本地部署终端配置清单，核心是 11 类版本体积对照表，外加每个档位该配什么 CPU、内存和显卡。这篇文章就是这份清单的完整说明，适合三类人看：想在家里消费级显卡上跑 7B、13B 模型的人，手头只有入门卡但不想盲目下大模型的人，以及做二次开发时需要快速评估硬件需求的人。
1. 先说清楚：这张清单是给谁的、不是给谁的
1.1 我踩过的三个认知误区
第一个误区是“把下载体积当成显存占用”。我一开始也是这么想的，模型文件写着 4.2GB，8GB 显存怎么都够吧？结果框架默认把低精度量化权重按更高精度重新加载，再加上推理缓存的申请，显卡瞬间爆掉。后来我养成了习惯：不管下载体积多少，一律按“权重实际字节数 + 上下文缓存 + 框架缓冲”三步估算，才没有再犯。
第二个误区是“版本数字越大越强”。7B、13B、33B 摆在一起，谁都知道参数多的聪明，但聪明换来的显存代价并不线性。我曾在同一台 24GB 显卡上做过对比：7B 原生 BF16 跑得飞快，换 34B 的 INT4 量化版本后，长文本生成直接从顺滑变成“一个字一个字往外挤”。如果你的任务只是摘要、翻译、日常问答，7B 级完全够用，多出来的预算不如给上下文长度和并发能力。
第三个误区是“只盯显卡，不看内存和 CPU”。有一次我想挑战纯 CPU 跑 70B 量化版，内存 64GB，机器配置不差，结果生成速度不到每秒 1 个 token，等一句完整回答像等邮件一样煎熬。所以这份清单里，我不会只写“需要多少 GB 显存”，而是把 CPU 线程数、内存容量、显存容量放在一起给建议，因为这三个东西在本地部署里是互相牵制的。
1.2 适合参考这份清单的人
首先是个人知识库玩家。这类场景通常单用户使用，并发要求低，但对响应速度和硬件成本敏感。其次是做垂直小模型应用的小团队，需要在本地起一个内部服务，不希望把数据出内网。第三类是准备做模型选型的开发者，手头有几台不同配置的机器，想先确认“某个尺寸的量化版到底跑不跑得动”。这三种需求我都按“显存档位”做了配置建议。
至于已经有专业级卡、几十甚至上百 GB 显存随便用的人，这份清单对你们意义不大，可以直接跳过前四档，只看最后的多卡方案参考。
2. 实测基线：我在什么环境里把 11 类版本跑了一遍
2.1 硬件基线
没有基线就没有参考价值。我在五套不同配置的终端上做了实测，覆盖从入门到旗舰的常见范围。
| 方案 | CPU | 内存 | 显存 | 定位 |
|---|---|---|---|---|
| S1 | 8 线程处理器 | 32GB | 8GB | 入门体验 |
| S2 | 12 线程处理器 | 64GB | 16GB | 主流家用 |
| S3 | 16 线程处理器 | 128GB | 24GB | 甜点配置 |
| S4 | 24 线程处理器 | 256GB | 48GB | 进阶工作站 |
| S5 | 32 线程处理器 | 512GB | 80GB 双卡 | 旗舰合成机 |
每个档位的所有测试都做了至少三次复测，取平均值。生成参数统一：温度 0.7，输入长度 512 token，生成长度 256 token。这样不同模型版本之间的速度数据才能横向比较。
这里有个容易被忽略的点：显存相同的两台机器，速度可能差很多，因为推理速度主要被显存带宽卡住，而不是被显存容量卡住。同样是 16GB 显存，老型号和新型号的带宽差距可能接近一倍，7B 模型的生成速度实测能差出 10 个 token 每秒以上。所以我的清单里只写“档位”，不建议大家对着具体显卡型号硬套。
2.2 软件链路和量化格式
模型文件统一采用开源量化格式 GGUF。为什么选这个格式？因为它把权重、词表、配置信息打包成一个单文件，加载时按文件内部的元数据决定精度，搬运和对比很方便。同一个模型可以出 BF16、INT8、INT4 等不同量化版本，文件体积和显存占用一目了然。
解码部分使用基于 C++ 的命令行推理后端，这类工具显存占用低、启动快，能手动控制线程数和上下文长度，适合做逐项的精细测试。另外我也用一类带连续批处理的 Python 推理服务框架做了并发对照，目的是区分“个人终端使用”和“小团队服务化部署”两种不同场景。
2.3 为什么不能照抄“官方推荐配置”
很多模型的官方文档会给出推荐配置，但那些配置通常只保证“能跑起来”，不会告诉你跑得多快、能扛多长上下文。我试过一套官方参数：在一张 24GB 显卡上跑 13B 量化版，8K 上下文确实稳定，但速度只有 8 token/s 左右；手动把上下文压到 4K 之后，同一模型速度直接跳到 17 token/s。配置不是越“大”越好，而是越“匹配场景”越好。这也是我坚持自己实测的原因。
3. 11 类版本体积对照：从公式到表
3.1 体积换算的底层逻辑
任何模型版本，体积都能用一个简单公式估算：
- 体积（GB）= 参数量（十亿）× 单个权重字节数
不同精度的单权重字节数如下：
| 精度 | 每十亿参数占用 |
|---|---|
| FP32 | 4.0GB |
| BF16 / FP16 | 2.0GB |
| INT8 | 1.0GB |
| INT4 | 约 0.55GB（含打包开销） |
这里“每十亿参数”是理论值，实际加载后还需要加上词表、嵌入层、计算图常量等，所以我在下面表格里给的是“实测加载后的显存占用”，不是单纯的公式值。同样的模型，词表大小不同、上下文长度不同，实测值会上下浮动 1~2GB，这很正常。
3.2 11 类版本体积对照总表
| 类目 | 参数量级 | BF16/FP16 原生 | INT8 量化 | INT4 量化 | 推荐显存下限 |
|---|---|---|---|---|---|
| 第 1 类 | 0.5B | 约 1.0GB | 约 0.5GB | 约 0.3GB | 集显 / 8GB |
| 第 2 类 | 1B | 约 2.1GB | 约 1.1GB | 约 0.7GB | 集显 / 8GB |
| 第 3 类 | 1.5B | 约 3.1GB | 约 1.6GB | 约 0.9GB | 8GB |
| 第 4 类 | 3B | 约 6.0GB | 约 3.0GB | 约 1.8GB | 8GB |
| 第 5 类 | 4B | 约 8.0GB | 约 4.0GB | 约 2.3GB | 8GB |
| 第 6 类 | 7B | 约 14.0GB | 约 7.0GB | 约 4.2GB | 16GB（8GB 可 INT4 + 短上下文） |
| 第 7 类 | 8B | 约 16.0GB | 约 8.0GB | 约 4.7GB | 24GB（16GB 仅 INT4） |
| 第 8 类 | 13B | 约 26.0GB | 约 13.0GB | 约 7.2GB | 16GB 可 INT4，24GB 可 INT8，原生建议 32GB 以上 |
| 第 9 类 | 20B / 22B | 约 42.0GB | 约 21.0GB | 约 11.5GB | 24GB 可 INT4，原生建议 48GB |
| 第 10 类 | 33B / 34B | 约 67.0GB | 约 34.0GB | 约 18.5GB | 48GB（24GB INT4 且上下文受限） |
| 第 11 类 | 70B | 约 140.0GB | 约 70.0GB | 约 39.0GB | 单卡 80GB 可 INT4，原生建议双 80GB |
这张表里的“推荐显存下限”已经预留了 4K 上下文的 KV cache 和大概 1GB 的框架缓冲，不是刚好塞下权重的数字。实际使用中如果上下文开得更大，显存需求还会往上走。
另外多说一句混合专家（MoE）类模型，它们的总参数量很大，但推理时只激活一部分参数。例如 8x7B 的总参数约 47B，BF16 全量约 94GB，INT4 约 26GB，但由于只激活部分参数，它对显存带宽的要求反而比同体积稠密模型低。这类模型不好直接排进上面 11 类里，选型时建议单独看“激活参数”这一项，而不是看总文件大小。
3.3 表里没写但更重要的三件事
第一，上下文长度直接影响显存，而且影响比想象中大。KV cache 的占用和序列长度基本成正比，7B 模型在 4K 上下文时缓存约 1.2~1.8GB，8K 直接翻倍。你把上下文从 4K 拉到 8K，等于平白多塞了一个 7B 的 INT4 权重进去。
第二，显存带宽决定生成速度。两张卡即使显存容量一样，带宽差一倍，实际 token 生成速度就明显差一截。这解释了为什么很多 70B 量化版在消费级 24GB 卡上根本跑不动，不是显存不够，而是带宽不够，每个 token 都要完整遍历一次权重。
第三，同一尺寸的不同微调版本，体积可能差不多，效果差距却可以非常大。不要只看参数规模，还要看训练数据的领域和质量。我测过两个同为 7B 的版本，一个代码能力明显更强，一个中文长文生成更稳，体积相同，选择逻辑完全不同。
4. 按显存分五档的终端配置清单
4.1 第一档：8GB 显存入门卡
8GB 显存适合第 4、5 类模型（3B/4B）的原生 BF16 精度，也可以跑第 6 类（7B）的 INT4 量化版，但上下文长度必须克制。
实测下来，7B INT4 在这档显卡上把上下文设为 4K 时，显存占用约 6.2GB（权重 4.2GB + KV 1.2GB + 框架缓冲不到 1GB），可以稳定运行。但如果把上下文拉到 8K，KV cache 直接涨到 2.4GB 以上，总占用接近 8GB 上限，生成速度开始明显抖动，再往上 16K 基本必爆。
配套配置建议：CPU 至少 8 线程，内存 32GB，别开图形界面的大型应用抢占显存。启动参数优先保证小上下文：上下文长度设 4096，线程数设 4。这个档位的定位是“体验”，不是生产力，别指望跑出多惊艳的速度。
4.2 第二档：16GB 显存主流卡
16GB 是当前家用最主流的档位。它最舒服的组合是第 8 类（13B）的 INT4 量化版。13B INT4 权重约 7.2GB，加上 8K 上下文的 KV cache 约 2.5GB，再加框架缓冲，总占用约 11GB，留出了明显余量。
如果想效果更好，可以试第 6 类（7B）的原生 BF16 权重，14GB 权重加 4K 上下文约 1.2GB，总占用 15.2GB，勉强塞进 16GB，但建议只开 4K 上下文，别贪 8K。第 7 类（8B）原生 BF16 就别想了，16GB 权重加缓存必超，只能走 INT4。
配套配置建议：CPU 12 线程，内存 64GB，这样即使后面想跑纯 CPU 的应急推理也有余量。这个档位的甜点是“13B INT4 + 8K 上下文”，日常问答、文档摘要、代码补全都够用，速度也体感流畅。
4.3 第三档：24GB 显存甜点卡
24GB 是我个人最喜欢的档位，选择空间大很多。第 8 类（13B）可以上 INT8 量化，约 13GB 权重，加 8K 上下文约 3GB，总占用 16GB，非常宽松；第 9 类（20B/22B）可以上 INT4，约 11.5GB 权重，加 8K 上下文约 3.5GB，总占用约 15GB，也跑得动。
更有意思的是，24GB 可以勉强试第 10 类（34B）的 INT4 量化版，权重约 18.5GB，但 KV cache 只能留给 2K~4K 的短上下文，总占用会顶到 22GB 左右，非常紧张。实测这种组合只适合固定模板的短输入短输出，长对话基本走不远。
配套配置建议：CPU 16 线程，内存 128GB，模型文件放固态硬盘，加载速度差异虽然不影响生成速度，但影响启动体验。这个档位的定位是“全能工作站”，13B/20B 的多种量化组合都值得尝试。
4.4 第四档：48GB 显存进阶卡
48GB 档位主要对应专业级单卡或者两张 24GB 组合。这个容量可以解放很多限制：第 10 类（34B）可以直接上原生 BF16 跑满精度，或者 70B 上 INT4，权重约 39GB，加 4K 上下文约 2GB，总占用 41GB，虽然紧但确实能跑。
这个档位最推荐的两个组合是：34B 原生 BF16 + 16K 上下文，以及 70B INT4 + 4K 上下文。前者适合对精度要求高的场景，后者适合需要模型“聪明程度”的场景。速度上 70B INT4 受带宽限制往往只有 6~9 token/s，能接受的程度。
配套配置建议：CPU 24 线程，内存 256GB，因为到了这个级别，可能要同时跑多个模型实例或者做数据预处理。显存余量允许你开更大的 KV cache，所以上下文长度可以按需调到 16K 甚至 32K，但要监控实际占用。
4.5 第五档：80GB 单卡与双卡方案
80GB 单卡跑 70B 的 INT4 量化版非常舒服，39GB 权重留下大量余量，可以把上下文拉到 32K 甚至更大。如果想跑 70B 原生 BF16，就需要两张 80GB 卡组成双卡方案，两张卡各吃约 70GB，正好放下。
双卡并行实测有个需要注意的点：速度提升不是线性的。由于两张卡之间需要同步权重和中间结果，实测 70B BF16 双卡方案的生成速度只有单卡 INT4 方案的 1.3~1.5 倍，但换来的是精度大幅提升。所以我的建议是，能单卡 INT4 就单卡，除非任务真的很吃精度。
4.6 没有独显的纯 CPU 路线
纯 CPU 跑推理不是不行，但要认清一个物理现实：每生成一个 token，都要把模型权重从头到尾读一遍。以 7B INT4 为例，每生成一个 token 至少要读取 4.2GB 数据，内存带宽就是天花板。双通道内存的机器实测每秒大概 2~4 token，输入一长段文字后，等待回答的时间足够泡一杯咖啡。
我的建议是纯 CPU 只用来做三件事：验证模型文件是否完好、跑自动化测试脚本、以及在没有显卡的服务器上做离线批量处理。如果真要交互式使用，8GB 入门卡都比纯 CPU 体验好得多，因为显存带宽通常远高于内存带宽。
5. 部署现场最常翻车的三个坑
5.1 “启动秒挂”的 OOM 排查链路
显存不足的报错是本地部署最常见的“劝退现场”。这里给一套完整的排查链路，下次遇到可以直接照做。
第一步，先用 GPU 状态命令看当前显存占用情况，确认是不是有残留进程占着显存。很多情况下根本不是模型的问题，而是上次跑的进程没有释放显存。
# 查看 GPU 占用 nvidia-smi # 查看内存占用 free -g # 查看残留进程 ps aux | grep python第二步，确认模型实际加载精度。这一步是重灾区：你下载的是 INT4 量化文件，但推理框架启动时若没有正确读取量化元数据，会按 BF16 甚至 FP32 去加载权重。我遇到过一个经典案例：13B INT4 文件只有 7.2GB，但日志显示实际按 BF16 分配了 26GB，瞬间申请失败。解决办法是检查启动日志里的加载精度字段，并强制指定使用量化后的权重。
第三步，从最小的上下文长度开始试。先把上下文调到 2048，确认能启动，再慢慢往上加，每加一档就观察显存余量。这样能快速定位是“权重放不下”还是“上下文缓存放不下”。
第四步，关闭推理框架的显存预分配功能。有些框架会默认把整张卡的显存都划走，导致同一张卡没法同时跑两个模型。如果只是单模型部署，可以保留默认；如果要多模型共存，需要显式关掉预分配。
5.2 量化后“效果崩了”的边界
量化是把双刃剑，INT4 能省一大半显存，但也可能明显掉点。我拿同一个 7B 模型分别跑了 BF16、INT8、INT4 三档，做了同样的代码补全测试，结论是：事实问答类任务差异不大，代码生成、数学推理、长文本逻辑一致性这三类任务上，INT4 的错误率明显上升，甚至会出现缩进丢失、引号不匹配这类低级错误。
所以我的经验是：如果任务主要是分类、抽取、对话，INT4 完全可行；如果任务涉及代码、数学、多步推理，至少用 INT8 或 Q5 以上的量化档位，最好保留一个 BF16 版本作为效果基准。别只看文件体积小不小，要先问自己能不能接受这个精度折损。
5.3 上下文长度是一笔隐形的大开销
上下文长度对显存的影响比很多人想的大得多，我可以直接给一组实测数据：在 16GB 显卡上跑 13B INT4，权重 7.2GB，4K 上下文时总占用约 10.5GB，8K 时约 13GB，16K 时直接顶到 17GB 以上，OOM。上下文每翻一倍，KV cache 就翻一倍，这笔账非常直接。
如果上下文长度是你的硬需求，一个很实用的方案是给 KV cache 单独做量化。把 KV cache 从 BF16 降到 INT8，缓存占用直接减半，16K 上下文的 13B INT4 可以压回 11GB 左右。速度和精度几乎没有肉眼可见的损失，属于性价比非常高的调优。
6. 速度实测与三处“便宜”的调优
6.1 各档位速度参考
这里给一组实测的生成速度参考，统一为 4K 上下文、生成 256 token 的条件：
| 方案 | 模型组合 | 实测生成速度 |
|---|---|---|
| 8GB 卡 | 7B INT4 | 约 16~22 token/s |
| 16GB 卡 | 13B INT4 | 约 10~14 token/s |
| 24GB 卡 | 20B INT4 | 约 9~13 token/s |
| 48GB 卡 | 70B INT4 | 约 6~9 token/s |
| 双 80GB | 70B BF16 | 约 5~8 token/s |
| 纯 CPU | 7B INT4 | 约 2~4 token/s |
自己不测的话看这些数字可能没概念。说个直观感受：10 token/s 以上属于“能正常对话”，5~8 token/s 属于“能等但不难受”，5 以下就属于“读起来卡顿明显”。所以如果你想要流畅体验，速度底线建议设在 8 token/s 以上。
6.2 调优一：量化档位不是越低越好
很多人以为量化档位越低速度越快，其实速度提升非常有限。从 Q8 降到 Q4，生成速度大概只提升 10%~20%，但精度损失可能是断崖式的。我更推荐把量化档位选在“能塞进显存的前提下尽量高”的位置，而不是“能塞进显存的最低档”。
在大多数模型上，Q5_K_M 是我觉得性价比最高的一个档位，体积比 Q4 大一点，但质量和 Q8 的差距已经非常小。如果你的显存还有余量，优先提高量化档位（比如 INT4 换 Q5 或 Q6），而不是去拉长上下文，因为上下文带来的显存成本比量化档位高得多。
6.3 调优二：给 KV cache 做量化
KV cache 量化是我在所有部署场景里都会做的一步，因为收益实在明显。前面说过，它能让你在相同显存下塞进两倍的上下文长度，而生成速度几乎不变。实现上通常就是在启动参数里开启缓存量化，并指定缓存数据类型为 INT8。
实测一组数据：13B INT4 + 16K 上下文，关闭 KV 量化时显存占用约 16.5GB，开启后降到 11GB 左右，生成速度基本没有波动。对长文档阅读、长时间多轮对话这类场景，这个调优的价值比其他任何配置都大。
6.4 调优三：一个终端同时跑多个请求
本地部署未必只有你一个人用。如果你的应用要服务几个人同时提问，最忌讳的是每人起一个模型实例，显存立刻爆掉。正确做法是用支持连续批处理的推理服务框架，让多个请求共享一份模型权重，在同一个批次里交错生成。
我实测过同样一张 24GB 卡，单会话吞吐约 12 token/s；开启连续批处理后挂 8 个并发用户，整体吞吐能到 30 token/s 以上，单用户延迟只略增，但每个人都能用。对于小团队内部服务来说，这个差异是质变的。
把 11 类版本挨个跑完，我最大的体会是三点：第一，别迷信最大版本，先量化你任务最需要的能力，有时候 7B 的 INT8 比 13B 的 INT4 更稳；第二，显存不只是用来装模型的，也要装上下文和框架缓冲，预留 15%~20% 的余量是基本素质；第三，配置清单永远是起点，不是终点，每一台机器都值得按实际场景把上下文长度和量化档位来回调一遍。
最后再分享一个小操作：我每换一个新模型或新量化版本之前，都会先跑一组基线测试，固定输入同样的长文本、固定温度和生成长度，记录首 token 延迟和每秒生成数。换配置、换版本后一对比，有没有提升一目了然。这份配置清单也还在迭代，后面遇到新的版本和新的量化档位，我会继续把实测数据补进来。
