选择量化方式（Q4、Q5、Q8, FP16)

#量化：为了节省内存，您需要牺牲什么

模型由数十亿个数值组成，这些数值就是权重。在 FP16 格式下，每个权重占用 16 位：一个拥有 80 亿参数的模型大小约为 16 GB。量化用更少的位数存储每个权重。根据 llama-quantize 工具的文档，这一过程会减小模型体积，并可能加快推理，但代价是精度损失，可通过困惑度或 Kullback-Leibler 散度来衡量。llama.cpp、Ollama 和 LM Studio 使用的 GGUF 格式涵盖了这些变体。合适的选择取决于三个量：显卡的显存或 Mac 的内存容量、模型大小，以及您打算使用的上下文长度。在大多数情况下，Q4_K_M 在质量与体积之间提供了最佳平衡，因为质量损失仍然较小，而模型大小降至 FP16 的约 30%。

#解析名称：Q4_K_M、Q5_K_S、Q8_0、IQ3_XXS

数字（Q2 至 Q8）

每个权重的名义位数。实际值更高，因为部分敏感张量仍保持较高精度：Q4_K_M 实测为每个权重 4.89 位。

_0 和 _1

旧格式，精度统一。Q8_0因其几乎无精度损失而被保留使用，但Q4_0和Q5_0已被K系列变体取代。

_K

K量化是较新的技术，根据张量的重要性分配比特。

S, M, L

Small、Medium、Large：在相同的量化位数下，M 为重要张量保留的位数比 S 更多，因此模型体积略大，质量损失也略小。

IQ

I-quants 量化采用重要性矩阵：在大小相同的情况下，它们在极低位宽（低于 4 比特）下能更好地保留模型质量，但解码时需要稍多一些计算。它们依赖一个 imatrix 文件。

#决策表：模型大小与实测损失

llama-quantize 的 README 列出了 Llama 3.1 8B 每个权重所占的位数以及各格式的大小。Ollama 模型库则显示同一模型所分发文件的大小。两个来源的数据大致吻合，可用于估算同系列其他模型的大小。

关于最后一列，需要补充一点：以困惑度衡量的质量损失数据来自 llama.cpp 仓库中的一篇讨论，该讨论转载了工具帮助中的表格；这张表于 2023 年基于一个 70 亿参数的模型制作。这些数据说明的是各格式的相对排序，并不能准确反映当前模型的表现，其中一些模型更为敏感。

#几秒钟内计算模型的内存需求

GGUF文件大小可通过以下公式计算：参数（以十亿为单位）乘以每个权重的比特数，再除以八，得到吉字节。以70B Q4_K_M为例：70 × 4.89 ÷ 8 ≈ 42.8 GB，这与llama.cpp的表格中Llama 3.1 70B（43.1 GB）的数值相符。此外还需加上KV缓存，其大小随上下文增长，以及系统预留的余量。

taille du fichier (Go) ≈ paramètres (milliards) × bits par poids ÷ 8

Exemple : 32 milliards en Q5_K_M
32 × 5,70 ÷ 8 ≈ 22,8 Go
+ cache KV (selon le contexte) + 1 à 2 Go de marge

#量化对模型质量的实际影响

困惑度测量对各格式的排序呈现出一致的规律：比特数越多，损失越小。但困惑度并不能很好地预测具体能力。2026 年 1 月发表在 arXiv 上的一项研究比较了 Llama-3.1-8B-Instruct 的不同 llama.cpp 格式，并进行了推理、知识和指令遵循测试：在 WikiText-2 上，困惑度从 FP16 的 7.32 到 Q3_K_S 的 8.96 不等。作者指出，困惑度并不能全面预测下游表现。Q5_0 的平均得分甚至略高于 FP16（69.92% 对 69.47%），这属于测量噪声，并不意味着模型有所改进。

值得关注的结果涉及数学推理：在 GSM8K 上，得分从 FP16 下的 77.63 降至 Q3_K_S 下的 68.31。作者建议避免激进的 3 位量化，并在任务涉及多步推理时优先选择 Q4_K_S 或 Q5_0。因此，计算、代码和长链推理最先受到量化的负面影响，而不是日常对话。

从 Q8 到 Q6

在已发布的表格中，实际表现差异不可测量。

从Q6到Q4_K_M

质量损失较小，主要在需要长时间推理的任务、代码任务以及语料中占比较低的语言上较为明显。

低于4位

推理能力明显下降：除非出于内存限制，否则应避免使用。

#为什么模型文件越小，生成速度也越快

llama.cpp 的 README 中基于 Llama 3.1 8B 的测量结果说明了一个指南常常遗漏的要点：文本生成每生成一个 token 都会读取所有参与计算的权重，因此主要取决于需要读取的字节数。在该表格中，生成吞吐量从 Q8_0 的约 51 tokens/秒提高到 Q4_K_M 的约 72 tokens/秒，再到 Q2_K_S 的 90 tokens/秒。而提示词处理速度则稳定在约 800 tokens/秒，因为它受限于计算能力，而非内存。这些数字来自仓库中某一具体硬件上的测量，并不是您机器的性能数据；请记住这一趋势：位数越少，生成速度越快。

这带来两个实际影响。首先，在这些测量中，从 Q4_K_M 改为 Q8_0，以获得难以察觉的质量提升，会损失约 30% 的生成速度。其次，权重量化与 KV 缓存量化是两个独立的设置：后者减少长上下文的内存占用，并在专门的指南中介绍。

#遵循三条规则进行选择

1. 01
   从您可用的内存出发

   可用容量为 NVIDIA 或 AMD 显卡的显存，或 Mac 的统一内存减去为系统预留的约 25%。如果模型超出可用容量，部分计算会转移到 CPU，速度会下降，往往慢上数倍。
2. 02
   选择采用 Q4_K_M 量化后能装入可用内存的最大模型

   在内存占用相同的情况下，采用 4 位量化的较大模型通常优于采用 8 位量化的较小模型。这是一条广泛认可的经验法则，需要在您自己的任务上验证，尤其是代码相关任务。
3. 03
   随后利用剩余空间提高精度

   为上下文预留显存后，如果仍有 VRAM 剩余，就改用 Q5_K_M，再改用 Q6_K。这样带来的提升，小于换用更大一级模型所带来的提升。

ollama run llama3.1:8b-instruct-q5_K_M

Ollama 模型库中的标签标明了每种变体的格式和大小；如果省略后缀，Ollama 就会使用该模型的默认标签。在 Hugging Face 上，GGUF 文件的文件名中包含量化格式的名称。

#I-quants 与低于 4 位的量化格式

llama.cpp 的表格可以衡量实际节省的空间。对于 Llama 3.1 8B，IQ4_XS 的大小为 4.17 GiB，而 Q4_K_M 为 4.58 GiB，约小 9%；IQ3_XXS 为 3.04 GiB；IQ2_XXS 为 2.23 GiB。在仓库公布的测量结果中，这些格式的生成速度与 K-quants 接近，每秒仅相差几个 token，因此额外的解码开销较小。不过，I-quants 的效果取决于 imatrix 的质量和模型本身：只有在内存无法容纳 Q4_K_M 时，使用它们才有意义。

IQ4_XS

大小接近 Q4_K_M，但小约 9%。显存容量紧张时很有用。

IQ3_XXS 和 IQ3_S

一个 13B 模型的权重约占 5 GB，推理能力会有明显下降。

IQ2 和 IQ1

仅适用于超大规模模型，且只在其他方案都无法装入内存时使用。对于此类量化，保真度需要通过测量来评估：参见 Kimi K3 的示例，其中动态 1 位量化与原始模型的一致率仅为 78.9%。

#直接以 4 位格式发布的模型

某些较新的模型不再先以 16 位训练，再进行压缩：它们通过量化感知训练直接生成 4 位权重。Kimi K3 就是一个例子：其模型说明注明权重采用 MXFP4、激活采用 MXFP8，并使用量化感知训练。对于这些模型，原生文件本身就是基准；进一步量化为更低位宽的格式，造成的质量损失比对 16 位模型进行量化更大。转换模型前，请务必阅读模型说明。

#根据内存容量该如何选择

#深入了解

• Q4_K_M、Q5_K_M 和 Q6_K 的实际应用
• 理解上下文窗口
• 量化 KV 缓存：节省 VRAM
• GGUF、safetensors：理解这些格式
• VRAM 计算器

• 来源：llama-quantize的README（llama.cpp）
• 来源：关于 llama.cpp 量化技术的 arXiv 研究报告（2026）
• 来源：Ollama 上的 Llama 3.1 标签
• 来源：llama.cpp关于量化方法的讨论