本地模型量化的真实内存账单

选本地模型时，盯着「4-bit」和文件大小，很容易得到一个能下载、却跑不稳的方案。这篇文章的核心判断是：量化同时改变存储开销、精度和运行速度，位宽只解释其中一部分。显存够不够，还得把上下文缓存算进去。

它值得读的地方，是把文件名背后的账拆开了：为什么同样叫 4-bit，体积不同；为什么大小接近，速度能差三倍；以及有限显存究竟该留给权重精度，还是上下文。不过，文中的部分格式解释和性能结论，也需要带着前提看。

「4-bit」为什么算不准显存

量化把模型权重换成低精度表示。FP32 每个参数占 32 位，INT8 占一个字节，4-bit 则进一步压缩。模型架构不变，变化的是权重的存储方式，以及还原这些权重需要的辅助数据。

原文列出的 7B 模型参考体积是：FP32 约 28 GB，FP16/BF16 约 14 GB，INT8 约 7 GB，Q4_0 约 3.8 GB。它们适合判断数量级，不能直接当运行预算。

原因之一是辅助信息也占空间。量化后的整数需要配合缩放系数，部分格式还要保存偏移量、分层缩放等信息。再加上部分张量仍保留 fp32 或 fp16，一个标成「4-bit」的文件，实际可能需要约 4.5–4.85 bits per weight，也就是每个权重平均占用的位数。作者提醒，按名称估算可能出现约一成偏差；显存没有余量时，这就足以让加载失败。

更大的漏项是 KV cache，即生成过程中保存的注意力键值缓存。权重文件大小没有包含它，也没有包含激活值和上下文缓冲区。

原文举了一个具体配置：32 层、32 个注意力头、每头 128 维，BF16 缓存每个元素占 2 字节，再乘键和值两份，每个 token 约占 0.5 MB。上下文达到 32k token，缓存就约需 16 GB。

这个数字依赖模型结构，不能套给所有模型，但它足以解释一个常见误判：短提示词能跑，长文档一塞就爆显存。

文件放得下，只代表权重放得下。

原文给出的应对方式，是通过 --cache-type-k、--cache-type-v，将缓存设为 q8_0 或 q4_0。这里压缩的是缓存，需要和权重量化分别考虑。

同样的位宽，为什么速度和质量都不同

量化通常按块处理权重。以 Q4_0 为例，每块包含 32 个权重；如果每块保存一个 16 位缩放系数，平均到每个权重上，就多出 0.5 位开销。

块越小，越容易照顾局部数值差异，但辅助信息占比越高。块越大，开销更容易摊薄，却需要处理更多不同分布的数值。

Q4_K 等 K-quants 使用更大的超级块，并增加子块缩放；Q4_1 一类格式还保存块偏移量。它们都在回答同一个问题：有限的存储空间，怎样分给数值本身和还原数值的信息，才能少丢精度。

因此，「都是 4-bit」并不能说明两种格式等价。

速度还受解码方式影响。原文引用 GSQ-RCO 模型卡中的一组测试：两个体积接近的构建，分别使用普通 Q2_0 和 IQ2_XS。处理输入提示词时，吞吐是 367.49 对 108.19 tokens/s；逐个生成输出时，是 93.79 对 70.30 tokens/s。前者的提示词处理速度超过后者三倍，而且文件更小的那个反而更快。

这两种速度要分开看。长文档输入更关心提示词处理，持续输出代码则还要看生成吞吐。只看一个 tokens/s，很容易选错。

原文还称，查表构建在不同任务类别间的吞吐波动达到 45 tokens/s，普通构建约为 2。但这些属于所引用模型卡的测试，不能当成作者自己的全面实测；提供的正文也没有交代完整硬件、运行参数和复现过程。

另一个需要打问号的地方，是原文把 IQ 类型概括为使用算术编码的熵编码格式，并关联 --imatrix 校准与查表解码。正文没有给出足够的实现依据，不能据此认定所有 IQ 格式都采用这种机制。能保留下来的判断是：解码路径会影响速度，具体格式仍需查实现。

GGUF 文件名能告诉你多少

GGUF 文件名里的 Q4_K_M、IQ3_XS，表示主要量化类型，不是文件内每个张量的完整清单。实际文件可能混用多种精度，小张量也可能保留 fp32。

UD、_XL、GSQ-RCO 等标签还可能代表制作者的量化配方。标签相同，不保证体积和质量相同。

原文介绍的 GSQ-RCO 构建，把选择进一步细化到每个张量：在明确的体积预算内，由受约束的优化器分配量化类型，并用 rco-allocation.txt 记录分配结果。文件名中的 2.40、3.00、3.50，表示目标平均位宽。

这条思路有吸引力：先规定能接受多大的文件，再决定哪些张量值得保留更多精度。不过，「未来会从挑格式转向报预算」仍是作者的趋势判断。

对于现阶段选型，原文给了几档起点：

• 6–8 GB 显存，可以从 Q4_K_M 开始，尝试短上下文的 7–8B 模型。
• 12 GB 显存，可以考虑 Q5_K_M，或选择 Q4，为上下文留下更多空间。
• 16–24 GB 显存，可以考虑 Q6_K，也可以尝试更大模型的低位宽版本；接近 24 GB、又想运行大模型时，需要关注缓存量化。

这些是试跑入口，不是容量保证。尤其「大模型低位宽常常胜过小模型高精度」的说法，仍取决于模型、任务和运行条件。

我的判断

我认同作者把权重、缓存和运行速度分开算账。这比按显存容量推荐一个文件名，更接近日常使用。

但文章没有证明某种量化路线普遍占优。它引用的 3.00 bpw 构建，任务平均分为 92.57，BF16 基线为 93.12，体积缩小 4.7 倍。这支持「特定测试中，明显压缩仍能保留接近基线的表现」，不足以推出复杂代码修改、中文问答和长上下文检索都能保持同等质量。作者也承认，零样本平均分中超过 100% 的恢复率可能只是噪声，不能当作能力提升。

相比直接使用 FP16/BF16，量化提供了明确的资源收益；相比只追求最低位宽，它又要求付出选型和验证成本。「12 GB 时优先给上下文留空间」有实用价值，但没有对照数据，仍应当作经验建议。短输入任务可能更需要精度，长仓库上下文则更容易被缓存卡住。

量化方案应该由实际任务验收，位宽只能帮你缩小候选范围。

能拿来做什么

• 给本地 AI 编程准备一组固定任务，覆盖代码补全、跨文件修改和已有测试修复，用同样的提示词比较候选文件的正确率与完成时间。
• 处理长文件或仓库上下文时，同时记录输入长度和显存峰值；如果短输入正常、长输入失败，先检查 KV cache，再决定是否降低权重精度。
• 比较大小接近的 GGUF 文件时，分别记录提示词处理速度和生成速度，并检查模型卡中的运行条件、校准说明及 rco-allocation.txt。
• 按原文的显存档位选出少量候选，再用自己的任务决定空间该留给更大模型、更高精度还是更长上下文。