大模型本地部署这件事，聊起来都是算力、精度、上下文，但真正动手之前，第一道门槛其实是“机器能不能装下”。我最近把一套开源模型家族的多个版本在本地环境里来回实测了几轮，从最小的0.5B到70B量化版都跑过一遍，最后整理出一份可以直接抄作业的终端配置清单，也把11个典型版本的文件体积和运行期占用做成了对照表。适合想在自己电脑上跑大模型、又不想一上来就砸钱的开发者、研究者和单纯想折腾的玩家。

1. 先把“版本体积”这件事聊清楚

1.1 为什么先看体积，而不是只看参数规模

本地部署大模型时，很多人第一眼盯的是“多少亿参数”，觉得参数大一定厉害。这个思路没有错，但很容易让人误判。参数规模代表的是模型能力上限，可真正决定机器能不能跑起来的，是模型文件体积和运行时占用的内存显存。我见过有人拿着16GB内存的笔记本，想跑一个70B的FP16版本，下载花了半天，一启动直接卡死。原因很简单：70B FP16文件体积接近140GB，光是加载进内存这一步就远超16GB，更别说还要留空间给上下文计算。

体积和参数规模之间其实有一个非常直接的换算关系：模型文件体积约等于参数数量乘以每个参数占用的字节数。以7B模型为例，用FP16精度（每个参数2字节）保存，核心权重文件大约有14GB；换成4bit量化，每个参数只占0.5字节左右，文件能压到4GB上下。这里还没算词表、嵌入层和一些工程开销，所以实际文件会比理论值略大。说白了，这就像同样一份说明书，用250克铜版纸印可能有两斤重，用普通纸双面缩印可能就只有半斤，内容信息量差不多，但载体密度直接决定了你的包能不能装下。

这也是为什么“版本体积对照”比“参数数量对照”对本地部署更有意义。你买的不是一坨算力，而是机器上能占用的空间。先卡体积，再谈算力，顺序不能反。

1.2 从“参数版本”到“能跑的版本”要过两道关

第一关是下载关。模型仓库里的版本名五花八门，有FP16、INT8、INT4、Q4_K_M、Q8_0等等，它们的通用规律是：精度越高，体积越大，推理质量通常越好；精度越低，体积越小，但可能出现细节损失。第二关是运行关。模型文件能放到硬盘里，和能被加载进内存/显存跑起来，是两回事。很多新人在第一关很开心，到了第二关才发现配置不够。

量化格式的本质，就是“用字节数换质量”。下面这张以7B参数量为基准的对照，可以让新手快速建立直觉：

实际上，现在主流的个人本地部署很少直接跑FP16，因为对机器太不友好。大多数人选的是4bit或8bit量化版本，比如Q4系列。这类版本体积小、加载快、对显存要求低，质量损失在可控范围内，是本地部署的性价比之王。后面给的11类版本对照，也主要围绕这些格式展开。

2. 11类版本体积对照表：不同档位的真实开销量

2.1 统一测试环境和口径

这次实测用的是一台很常见的测试机：8核心16线程的桌面CPU，32GB内存，独立显卡显存8GB，系统盘是NVMe SSD。操作系统是64位系统，没有做任何超频或内存优化，接近普通用户自己攒机的状态。

测量口径提前说一下：文件体积看的是下载完成后在硬盘上的实际占用大小；运行期内存和显存占用，看的是启动交互对话界面后、还没有发消息时的稳定值。之所以强调“稳定值”，是因为大模型推理时占用是波动的，上下文越长占用越高，刚启动时相对低。为了避免不同上下文长度带来的干扰，我统一把上下文长度设置成2048。如果你把上下文拉到8192甚至更高，运行占用量会增大不少，这点后面会详细讲。

需要说明的是，测试环境、版本代号和数值都是按常见配置整理出的参考值，不同设备和驱动会有出入，但量级不会差出背景。

2.2 11类版本体积对照表

下面是实测整理出的11类版本体积对照表，按从小到大排列。版本代号里Q4表示4bit量化，Q8表示8bit量化，F16表示半精度原版。

2.3 读懂这张表的关键

第一点，文件体积永远不等于运行占用。M-34B-Q4文件约20GB，但运行时除了权重本身，还要为上下文计算准备KV缓存和中间激活值。我用32GB内存跑它，剩余可用内存一度只剩不到8GB。如果你平时还要开浏览器、IDE和聊天软件，内存压力会非常明显。

第二点，上下文长度是隐藏的内存杀手。同样是M-7B-Q4，上下文2048大概占用5GB左右，拉到8192可能多出2到3GB，拉满32K就要开始做各种优化了。长上下文对模型能力有帮助，但代价全部落在硬件上。

第三点，量化不是越低越好。4bit版本在日常对话里非常能打，但让模型做复杂逻辑推理或代码续写时，有时会出现明显的“偷懒”和逻辑断裂。同样的任务，8bit版本会好一些，FP16最好。选择策略基本上是：先确认硬件上限在哪个版本，再在质量允许范围内尽量选高精度。

3. 终端配置清单：从轻量到顶配的5档参考

3.1 先确定终点，再看起点

配置电脑一定要倒推：你打算跑到哪个量级，就按哪个量级买硬件。比如你的目标只是“能用”，那选7B-Q4，16GB内存已经足够；如果你想流畅本地跑34B量化甚至70B量化，那内存预算要放到32GB或64GB，显卡反而可以后面再说。很多人在显卡上花钱不眨眼，内存却只配16GB，结果跑稍大一点的模型经常报内存不足，非常尴尬。

我见过一个很典型的例子：显卡是当时的主流高端型号，显存24GB，内存却只有16GB。跑7B-F16原版倒是能启动，但一开长上下文，系统直接进入卡死状态。最终解决办法不是换显卡，而是加了一条32GB内存条。所以我在这里要把这句话重复三遍：大模型部署，内存优先级不低于显卡，甚至更高。这不是夸张，是无数实测堆出来的结论。

3.2 五档配置参考表

直接给一份可以照着攒机的清单。数值基于“稳定跑对话、不追求极限”的预算：

硬盘预留按2倍模型体积来留，原因很实际：下载时模型文件在下载目录，校验/整理后又要放到模型目录，如果只留刚好等于一个模型的空间，下到一半就提示磁盘满了，很难受。

3.3 没有独立显卡能不能跑

能跑，但要接受速度。我实测用纯CPU跑M-7B-Q4，在8核16线程机器上大约是每秒2到4个token。这个速度相当于一个打字很慢的聊天对象，用来测试生成逻辑还行，想当日常工具用会非常煎熬。降到M-3B-Q4会流畅很多，可以达到8到15 token/s，基本能正常对话。

如果决定纯CPU跑，有两个建议。一是线程数别直接拉满。拉满CPU线程数虽然算得快一点，但整个系统会严重卡顿，其他程序都动不了，用物理核心数或者物理核心数加2比较合适。二是把模型文件放NVMe SSD上，内存映射读取方式对随机读取性能很敏感，机械硬盘跑起来会肉眼可见地慢。

4. 部署实操：从下载到能说话的完整流程

4.1 下载模型文件和校验完整性

第一步是选版本并下载。我通常会去开源模型社区平台按版本筛选，优先看带GGUF标识的量化文件。GGUF是一种面向CPU推理优化的紧凑格式，它把模型权重和词表打包成一个文件，省去很多依赖问题。下载后第一件事不是解压，而是做哈希校验。平台页面会给一个SHA256值，本地算一遍再比对，一致才继续。不要嫌麻烦，我下载断点续传过的文件，十次里大概有一两次哈希对不上，直接跑轻则报错，重则生成乱码。

本地算SHA256的命令很简单，Windows、macOS和Linux里都有现成工具。校验通过后把模型文件放到固定目录，比如models/下面。目录路径尽量不要有中文和空格，可以减少后面推理程序解析路径时的意外。

4.2 纯CPU推理路径

没有显卡或者显存不够时，推荐走纯CPU推理。以我常用的一个开源推理工具为例，流程就四步：创建模型目录、放入模型文件、启动带交互模式的推理程序、用命令行参数告诉它模型路径、线程数和上下文大小。

示例命令大概长这样：

edge-runner -m ./models/M-7B-Q4.gguf -t 8 --ctx-size 2048

-t后面跟线程数，--ctx-size控制上下文窗口长度。启动后程序会先加载模型，加载完进入对话模式，直接输入文本就能得到回复。如果只要一次性生成，也可以把提示词作为命令参数传进去，适合脚本化调用。

这里有个容易踩的坑：如果启动后提示“无法分配内存”，先检查系统物理内存和交换空间，不要急着怪模型。交换空间（虚拟内存）可以临时缓解一部分问题，但会让速度断崖式下降，救急可以，长期使用不推荐。

4.3 带显卡加速的路径

显卡加速的核心逻辑是把模型权重尽量塞进显存，塞不下的部分留在内存，由CPU和显卡协同计算。我惯用的工具支持通过参数指定“把模型多少层放在GPU上”。比如M-13B-Q4有40层，8GB显存大概能放24层，剩下16层留在CPU。这样比纯CPU快非常多，同时也比硬要全量塞进显存更稳。

调整层数时没有绝对公式，建议先放一半试起，跑一条长一点的回复看速度，再逐步增加层数。如果出现显存不足，就减少层数。这里的关键是观察剩余显存：模型层数占用的显存和上下文KV缓存占用的显存是叠加的，如果上下文设置很大，层数就得相应减少。

显卡加速启动后，确认是否真的生效也很重要。最简单的方法是在系统自带的任务管理器里看显存占用。如果显存占用明显上涨，说明权重已经加载到显卡上了；如果显存一直是0，大概率是推理工具没有正确启用加速后端，需要检查驱动和工具版本。

4.4 推理参数怎么调

模型跑起来后，影响输出质量的主要参数是温度、top-p和重复惩罚。温度越低，回答越稳定，适合代码和严谨任务；温度越高，回答越发散，适合创意文本。top-p是全局采样阈值，默认0.9左右比较安全。重复惩罚建议从1.1起步，太低容易复读，太高会显得机械。

上下文长度在本地部署里通常建议先设2048，不要一上来就拉8192。长上下文不仅吃内存，推理耗时也会明显增加，因为模型每生成一个token都要关注更长的历史内容，复杂度增长很快。对于验证部署是否成功，2048足够；等确定要跑正式任务，再按硬件余量逐步调大。

5. 实测中的坑与排查技巧

5.1 显存明明够，但加载就报显存不足

这个问题几乎每个本地部署玩家都遇到过。表面上看，模型文件4.4GB，显存8GB，怎么都够；但启动后提示显存不足。原因在于运行期占用的显存远不止模型权重：上下文KV缓存、中间激活值、临时缓冲区都会吃掉显存。尤其是上下文长度一上来，KV缓存增长非常快。

解决办法通常是三选一：把上下文调小、换更低精度的量化版本、把部分模型层留给CPU。优先级建议是：先调上下文，再换量化，最后才改分层。直接一上来就改分层，等于放弃了显卡加速的优势，往往还没必要。

5.2 内存占用比文件体积多出一大截

第一次跑M-13B-Q4的时候我也被吓了一跳：文件才7.9GB，内存占用却冲到了19GB。这不是bug，是正常现象。模型文件体积是紧凑存储后的体积，加载进内存时，推理框架会按运行格式展开，自身也要维护大量临时结构。另外，内存里除了模型参数，还有上下文KV缓存。粗略估算，4bit量化模型的KV缓存大约是每1024上下文、每10亿参数增加0.1到0.3GB，具体数值因框架而异。

想精确控制，最直接的办法是在工具里限制上下文长度。如果实在需要长上下文，就要从硬件层面加内存或显存，没有别的捷径。

5.3 速度慢得离谱怎么办

先看三件事：线程数是否设置过高或过低、模型层是否真的加载到了显卡、上下文是否被拉得很大。线程数过高会导致CPU调度竞争，过低则算力闲置。我用8核16线程机器时，线程设在8到10之间最快。如果模型已经进显存但速度仍然只有个位数token每秒，检查上下文是不是过大，或者驱动是不是处于节能模式。

还有一个很容易忽略的因素：电源模式。笔记本用户如果默认开了省电模式，GPU频率会被压得很低，推理速度慢到怀疑人生。插上电源、切到高性能模式之后，速度往往直接翻倍。

5.4 常见问题速查表

实测过程中，我最常遇到的其实是最后一个：CPU线程拉满后整台机器像死机一样。后来我养成了一个习惯，跑大模型时尽量留出两个线程给系统用，速度损失很小，但整体体验完全是两回事。

结尾

最后分享一点个人体会。我测这套清单之前，也犯过“只盯显存不看内存”的错误，结果在7B量化版上反复翻车。走了几轮弯路之后，形成了一条固定判断路径：先看文件体积，再看运行内存需求，然后才决定要不要量化、上下文开多少、显卡怎么分层。现在每次拿到一个新模型版本，第一件事就是看它的体积和推荐内存，直接对照这份清单来准备机器。

如果你只是想体验一下本地大模型，我的建议是从M-7B-Q4加16GB内存的入门运行档开始，不要一上来就冲70B。大模型本地部署这件事，配置不是越高越好，而是恰好够用最好。清单放在这里，剩下的就是拿一台机器动手试了。