6GB 显存怎么选本地大模型从 Q4 文件到运行预算

下载本地大模型时，我觉得最容易花冤枉时间的地方，是看到一个 Q4 文件只有几 GB，就以为自己的显卡肯定够用。模型下完能加载，塞进一段长材料却开始报显存不足，或者回答慢到不想再用，这两种情况都值得在下载前考虑。

我之前用 Unsloth Desktop，在 RTX 3060 6GB、32GB 系统内存的电脑上跑过 Qwen-Image 2.1。1024×1024、40 步，一次复杂提示词出图约等了 40 分钟。那次主生成器实际按 BF16 加载，配合卸载运行。这个经历让我更在意两件事：实际加载了什么，以及等待时间能不能接受。

这次讨论文本大模型的下载选择。生图那次的耗时不能拿来预测聊天速度；下面用官方文件大小和能复算的空间预算，说明 6GB 显存还要给哪些东西留位置。

下载页的总容量不等于你要下载的容量

拿 Qwen 官方的 Qwen3-8B-GGUF 文件页举例。2026 年 10 月 18 日，页面展示的几种文件大小如下，单位是网站使用的十进制 GB：

所选量化版本与单文件大小：

Q4_K_M：5.03GB
Q5_K_M：5.85GB
Q8_0：8.71GB

完整文件名例如 Qwen3-8B-Q4_K_M.gguf。Q8_0 文件已经大于 6GB，完整权重常驻这张显卡显然不现实，需评估卸载或其他设备；较小的两个版本也要继续算运行余量。

仓库页面显示的总容量约 32GB，里面包含多个量化版本。对这个单文件文本模型，选择一个受当前工具支持的版本即可，没必要为了试一次，把整套不同量化文件都下载下来。换成分片模型，则要下齐所选版本的全部分片，不能只取第一片。

我会先看客户端支持什么，再看文件。GGUF 是文件容器，里面可以放不同类型的权重；工具还要支持模型架构和相应量化类型。改个扩展名，解决不了兼容问题。GGUF 规范

BF16 INT8 和 Q4 各省在哪里

模型权重可以先理解为训练后保存下来的一大批数字。参数数量不变，每个数字用的位数减少，保存它们需要的空间通常就会下降。

假设恰好有 80 亿个参数，全部用同一位数编码，暂时不算任何辅助信息：

编码与理论裸权重空间：

BF16 或 FP16：16GB
8 位编码：8GB
4 位编码：4GB

计算很直接：参数数量 × 位数 ÷ 8。8B 里的 B 是十亿，不能当成文件单位的字节。这张表也不能直接拿来决定买多大显存的卡。

4 位编码只有 16 种状态，要表示原来那些细碎的小数，还需要缩放等辅助信息。以 llama.cpp 的 Q4_0 块为例，32 个权重的 4 位编码占 16 字节，再配一个 2 字节系数，合计 18 字节，平均每个权重占 4.5 位。80 亿个权重按这种块结构计算，数据就已经约 4.5GB，还没加其他内容。Q4_0 官方块定义

Q4_K_M 又有自己的编码和混合精度安排，可以对照 llama.cpp 的量化实现。回到上面的真实文件，5.03GB 才是这份下载需要面对的体积；“8B 乘半字节等于 4GB”只能作为入门估算。

文件放得下还要给对话缓存留空间

运行时除了权重，还要放对话缓存、中间计算结果和临时工作区。桌面显示、其他软件以及后端自身也可能占用显存。

其中，KV cache 可以理解为模型保留的前文计算状态。有了它，生成下一段文字时就不用把此前所有状态重新计算一遍。对普通全注意力模型，缓存通常会随已处理的 token 数增加。token 是模型切分文字后的单位，不能直接换算成同样数量的汉字。Hugging Face 缓存说明

这部分可以算一个具体例子。Qwen3-8B 的官方配置有 36 层、8 个 KV 头，每个头 128 维。假设只处理一条序列，K 和 V 都用 16 位保存，不量化缓存，也不计其他结构开销：

纯 KV 数据字节数 = 2份 K/V × 36层 × 8个KV头 × 128维 × 已缓存token数 × 2字节 4096 个 token：576MiB 8192 个 token：1152MiB = 1.125GiB

输入材料和后来生成的内容都会影响需要保留的上下文，不能只按输入那一小段话做预算。有些后端还会按配置预分配缓存，因此刚加载完、尚未聊很长时，也可能已经占去一块空间。

再把单位统一一下：5.03GB 的文件约为 4.68GiB。用文件体积粗估常驻权重，再加上这个 8192 token 的理论缓存，两项已经约 5.81GiB，临时工作区和其他占用都还没算。这是容量规划的粗算，不是 Qwen3-8B 在某个客户端里的显存实测。

如果显存紧，我会先缩短上下文，或换更小的模型做验证。别一边开很长的上下文，一边只盯着 Q4 这两个字符。滑动窗口、缓存量化和 CPU 卸载会改变预算，实际使用哪一种，要看模型和后端配置。本例 Qwen3-8B 的官方配置未启用滑动窗口，不能假设有个开关就能直接获得这项省显存效果。

显示 BF16 要分清是在说保存还是计算

权重怎样保存，和运算时使用什么格式，可以分别设置。

例如 bitsandbytes 可以同时配置 load_in_4bit=True 与 bnb_4bit_compute_dtype=torch.bfloat16。前者控制 4 位权重，后者选择 BF16 计算。优化后的实现可以把解码与运算融合起来，无需先把整份权重还原成常驻显存的 16 位副本。官方配置示例

所以，看到 BF16，应该继续看它描述的是权重、计算，还是某个独立组件。单看一个模型条目名或精度徽标，判断不了整套运行方式。bitsandbytes 的例子也不能直接套到所有 GGUF 后端，更不能据此认定某个客户端量化失败。

同样的道理，6GB 独立显存和 32GB 系统内存，需要分别看占用。卸载可以让部分数据留在系统内存中，但搬运和计算都有代价，不能把它们当成一块没有速度损失的 38GB 显存。llama.cpp 的 CPU 与 GPU 混合推理说明

Q4 和 Q8 的取舍要拿自己的任务试

减少编码位数，通常会带来数值误差。可以把它想成一把刻度变少的尺子：同一段范围里，可表示的位置更稀疏了。实际量化会通过分组、缩放和混合精度等办法处理误差，下面的均匀网格只用于解释原理。

这张图不能用来推导“回答准确率下降多少”。某个权重的误差，也不能直接换算成代码正确率或摘要遗漏率。选择时，我会准备自己常用的材料：一段要总结的文字、一段需要解释的代码，或者一个有明确答案的问题。

比较量化版本时，固定基础模型、提示词、上下文和采样设置。看它有没有漏掉关键条件，代码能不能按预期执行，长材料中的信息能不能找回来。聊天语气顺畅，只能说明这次聊天看着顺畅。

速度也单独看。文件缩小，读取权重时可能少搬一些数据；解码、计算内核和 CPU/GPU 搬运又会增加成本。不要把文件缩小比例直接当成速度提升比例。PyTorch 推理优化案例

已有 6GB 显存我会按这个顺序试

下载前确认兼容。 看客户端支持的模型架构、文件格式与量化类型。下载页给出的安装命令不等于你的硬件已经满足运行条件。
先看完整文件大小。 不把仓库总容量当作必需下载量，也不把某一个分片当成完整权重。SSD 还要考虑下载缓存和工作文件，空间紧时先只保留一个候选版本。
先做短任务。 用工具正常支持的设置、单路生成和较短上下文确认加载与输出，再逐步增加材料长度。每次只改一个变量，才知道是哪项设置影响了占用。
检查真正的运行配置。 记录模型文件、客户端版本、上下文、缓存精度、卸载方式，以及运行时报告的内存占用。输入处理、等待首个输出和后续生成，可能慢在不同环节。
把真实任务跑完。 看结果正确性、峰值占用和等待时间。能进聊天窗口，还不足以判断每天用起来是否省心。