作者： Ollama量化怎么选：q4_K_M、q8_0还是fp16
用算术选择Ollama量化：比较q4_K_M、q8_0和fp16的实际文件大小与内存占用，说明4 bit性能损失通常出现在哪里。
Ollama 量化会改变什么
Ollama 量化会使用少于模型训练文件的位数来存储模型中的每个权重。以 q4_K_M 结尾的标签表示每个权重约使用 4 bit，而 fp16 使用 16 bit，因此下载文件大小约为原来的四分之一，机器为生成每个 token 读取的字节数也约为四分之一。权重会被舍入到较粗的网格上，而不是直接丢弃；对于大多数模型，使用 4 bit 时，其回答方式与全精度模型接近。
这就是完整的权衡：内存占用大幅降低，每秒生成的 token 数增加，但准确性会有小幅损失。下面介绍如何在下载一个无法装入内存的文件前，根据具体模型和具体机器，预测这两方面的表现。
如果 Ollama 尚未运行，请先参阅在 VPS 上安装 Ollama。本文假定 ollama ls 已可正常运行。
如何读取 Ollama 量化标签，例如 q4_K_M
本地模型以 GGUF 文件形式发布。GGUF 是 llama.cpp 用于在磁盘上存储权重的格式。Ollama 基于 llama.cpp 构建，因此 Ollama 标签会原样使用 llama.cpp 的量化名称。
数字表示目标位宽。 q4 表示大多数权重张量按每个 4 位进行打包。q8 表示 8 位。fp16 完全未量化：它是使用 16 位浮点数表示的模型，这是大多数模型发布时采用的精度。
K 表示 K-quant。 权重会被分成较小的块，每个块都会在打包值旁存储自己的缩放因子。某个块中的权重如果都接近 0.01，就可以使用精细的缩放因子。包含一个较大离群值的块则需要使用较粗的缩放因子。正是这些块级缩放因子使 4 位文件仍然可用，也正因为如此，4 位文件的每个权重实际上绝不会恰好占用 4 位。
末尾的字母表示混合方式。 S、M 和 L 决定有多少张量会提升到目标位宽以上。在 q4_K_M 中，舍入后损失最大的张量会使用更高位宽存储，而大部分权重仍保持 4 位。因此，在文件大小几乎相同的情况下，q4_K_M 的输出优于较旧的 q4_0。
不要根据输入的名称猜测，而应让 Ollama 查询磁盘上的实际内容：
ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_Mollama show 会输出 architecture、parameters、quantization、context length 和 embedding length。对于几个月前拉取、已经不记得当时选择了哪个版本的模型，quantization 行才是实际依据。
每个权重的位数决定文件大小
所有大小估算都从一个数字开始：格式平均为整个文件中的每个权重分配多少位。llama.cpp 在其量化文档中发布了 Llama 3.1 8B 的实测数据。这些数据也适用于结构相近的稠密模型。
The data behind this chart
[
{
"label": "F16",
"bits_per_weight": 16,
"file_gib": 14.96
},
{
"label": "Q8_0",
"bits_per_weight": 8.5,
"file_gib": 7.95
},
{
"label": "Q6_K",
"bits_per_weight": 6.56,
"file_gib": 6.14
},
{
"label": "Q5_K_M",
"bits_per_weight": 5.7,
"file_gib": 5.33
},
{
"label": "Q4_K_M",
"bits_per_weight": 4.89,
"file_gib": 4.58
},
{
"label": "Q3_K_M",
"bits_per_weight": 3.99,
"file_gib": 3.74
}
]表格中令人意外的是第二列。Q4_K_M 并不是每个权重4位。它实际使用 4.89 位，因为块缩放因子和提升精度的张量也会占用实际空间。Q8_0 实际使用 8.5 位，而不是8位，原因相同。使用实测值计算，结果与实际文件大小相差通常不超过几个百分点：
weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB这就是一个大小为 4.58 GiB 的 Q4_K_M 文件，仅通过两个数字即可计算出来。加载后，权重占用的内存大小也大致如此。Ollama 加载时不会解包任何内容：量化权重以相同的紧凑格式驻留在内存中，每个块在使用时才会转换。
Ollama 实际为每种模型大小提供的内容
对于大多数模型系列，模型库会发布 q4_K_M、q8_0 和 fp16 标签。以下是截至 2026 年 8 月从模型页面标签列表中读取的 Qwen3 各尺寸。
The data behind this chart
[
{
"label": "Qwen3 4B",
"q4_K_M_gb": 2.6,
"q8_0_gb": 4.4,
"fp16_gb": 8.1
},
{
"label": "Qwen3 8B",
"q4_K_M_gb": 5.2,
"q8_0_gb": 8.9,
"fp16_gb": 16
},
{
"label": "Qwen3 14B",
"q4_K_M_gb": 9.3,
"q8_0_gb": 16,
"fp16_gb": 30
},
{
"label": "Qwen3 32B",
"q4_K_M_gb": 20,
"q8_0_gb": 35,
"fp16_gb": 66
}
]这里默认标签很重要。ollama pull qwen3:8b 下载的内容与 ollama pull qwen3:8b-q4_K_M 完全相同，都是 5.2 GB，因为不带后缀的标签就是 q4_K_M 构建版本。Q4_K_M 并不是模型库勉强提供的折中选项，而是上游选择的默认版本。因此，对于尚未自行测试的模型，优先匹配该版本是合理的做法。在 VPS 上运行 Qwen 3 时，标签选择也遵循同样的原则。
这些比例适用于每一行。从 q4_K_M 切换到 q8_0 时，所需空间大约增加百分之七十，而不是正好翻倍。这是因为嵌入张量和输出张量的缩放方式与其他张量不同。fp16 所需空间约为 q4_K_M 的 3 倍。32B 模型使用 q4_K_M 时，权重就占用 20 GB，这已经超过 16 GB 服务器在保留任何上下文窗口时的容量。要了解不同机器适合运行哪些模型，请参阅 可以自行托管哪些模型。
为什么 KV 缓存是第二项与上下文相关的成本
权重是固定成本。KV 缓存（键和值缓存）是可变成本。上下文窗口中的每个 token 都会为每一层保留对应的键和值向量，因此缓存会随允许的窗口大小线性增长。模型加载时会为整个窗口分配缓存，而不是等对话逐步填满后再分配。这就是为什么即使提示词只有一个单词，较长的窗口也会占用内存。
KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16: 2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token这些模型参数来自模型自身的配置：36 个层、8 个键/值头，以及 128 的头维度。ollama show 提供架构和参数数量，模型在 Hugging Face 上的 config.json 提供其余信息。将每个 token 的成本乘以窗口大小后，缓存占用就不再是可以忽略的误差。
The data behind this chart
[
{
"label": "4k",
"kv_cache_gb": 0.6,
"floor_ram_gb": 5.8
},
{
"label": "8k",
"kv_cache_gb": 1.21,
"floor_ram_gb": 6.4
},
{
"label": "16k",
"kv_cache_gb": 2.42,
"floor_ram_gb": 7.6
},
{
"label": "32k",
"kv_cache_gb": 4.83,
"floor_ram_gb": 10
}
]在 Ollama 默认的 4096 tokens 窗口下，缓存会在权重之外额外占用 0.6 GB。将窗口提高到 32k 后，仅缓存就会达到 4.83 GB。这几乎与量化权重占用的内存相同，整个模型所需内存的下限也会变成 10 GB。之所以称为下限，是因为计算缓冲区和操作系统还会额外占用内存。模型加载后，从 ollama ps 的 SIZE 列读取实际数值。
使用 Ollama 作为服务时，窗口在服务器端设置，而不是按请求设置：
OLLAMA_CONTEXT_LENGTH=8192 ollama serve对于使用 systemd 安装的情况，应改为在 drop-in 配置中设置：
sudo systemctl edit ollama[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"使用 sudo systemctl restart ollama 重启，然后检查 ollama ps 的 CONTEXT 列，确认运行中的模型实际加载时使用的窗口大小。OLLAMA_KV_CACHE_TYPE 会对缓存本身进行量化：f16 是默认值，q8_0 的内存占用约为 f16 的一半，q4_0 的内存占用约为其四分之一。这是全局选项，因此服务器上的每个模型都会采用相同设置。在配置较小且窗口较长的机器上，将缓存减半所释放的内存多于任何其他单项调整。设置 num_ctx 及其成本详细介绍窗口本身。
8、16 或 32 GB VPS 的适用配置
需要为预算预留空间、KV 缓存，以及操作系统和其他运行中程序所需的余量。在小型 VPS 上，预留 2 GB 通常比较宽裕。
8 GB。 4B 模型使用 q4_K_M 时占用 2.6 GB，还能为较长上下文窗口留出空间。8B 模型使用 q4_K_M 时可以配合默认的 4k 窗口运行，但余量很小。这里不要规划 8B 配合 32k 窗口，因为 10 GB 的最低内存需求已经超过这台 VPS 的容量。
16 GB。 8B 使用 q4_K_M 时，配合 16k 或 32k 窗口都比较宽裕。14B 使用 q4_K_M 时，权重占用 9.3 GB，配合适中的窗口可以运行。8B 使用 q8_0 时占用 8.9 GB，因此也能运行。在您自己的提示词上比较这两种配置，是您在这个主题上投入 1 小时最有价值的方式。
32 GB。 14B 使用 q8_0（16 GB）和 32B 使用 q4_K_M（20 GB）都可以加载。32B 构建配合较大窗口时会逼近内存上限，因此应监控 ollama ps，不要想当然地认为一定可用。
量化首先会损害什么
量化误差不会均匀影响模型的各项能力。流畅性通常最后才受影响，这也正是问题容易被忽视的原因：严重量化的模型仍然可以写出通顺的句子。首先受损的是精确性。模型对版本号、API 签名或日期的准确记忆会先出现问题。长链路推理也容易受影响，因为第 2 步中的小错误可能在第 8 步变成错误答案。严格的输出格式同样如此，一个括号错误就可能导致工具调用失败。
最后一种情况是实际测试量化效果的最好方法。当模型必须返回由代码解析的 JSON 时，量化损害会表现为解析错误，而不是模糊的文本质量下降，因此当天就能发现。编码代理是最严格的测试场景，因为它会连续驱动模型执行工具调用。因此，让代理连接到您的 Ollama 服务器，通常只需一个下午就能暴露过于激进的量化问题。
低于 4 bit 后，性能损失会明显加剧。q3 和 2 bit 类型适用于需要将大型模型压缩到小型硬件上的场景；如果替代方案是完全无法运行模型，它们确实是可行选项。但它们不适合作为默认选择。q4_K_M 和 q8_0 之间的差距通常很小，仅凭已发布的困惑度表无法判断哪一种更适合您的工作负载，因此不要用这种方式做决定。请分别使用您自己的 30 条提示词测试两种量化，并阅读输出结果。
何时值得为 q8_0 或 fp16 分配内存
仅当内存确实充足，且任务对小错误非常敏感时，才选择 q8_0：例如结构化提取、工具调用，以及必须通过编译的代码。此时购买的是容错余量，而不是明显更聪明的模型。
选择 fp16 只有两个原因。要么您要自行量化模型，需要源文件；要么您要测量基线，以确定自己的四位量化版本损失了多少。使用 fp16 提供服务所需的内存是 q4_K_M 的三倍，但大多数人无法在盲测中分辨出差异；在仅使用 CPU 的设备上，token 速率还会降至三分之一。
更有力的规则是：在内存预算固定时，使用 q4_K_M 的更大模型通常优于使用 q8_0 的更小模型。9.3 GB 的 14B 权重与 8.9 GB 的 8B 权重占用的 RAM（随机访问内存）几乎相同，而更大的模型掌握的信息更多。请使用您自己的提示词进行测试，不要仅凭此结论判断。
仅使用 CPU 进行推理受内存带宽限制
大多数 VPS 方案没有 GPU，因此模型会在主机 CPU 上使用系统内存运行。此时，生成速度受内存带宽限制，而不是算力限制，因为生成每个 token 都需要读取一遍全部权重。这样就形成了一个与您购买的 CPU 核心数无关的上限。
tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB = 9.6 tokens/s qwen3 8B q4_K_M
50 GB/s / 8.9 GB = 5.6 tokens/s qwen3 8B q8_0
50 GB/s / 16 GB = 3.1 tokens/s qwen3 8B fp16对于双通道 DDR4-3200 主机，50 GB/s 大致是理论值。您实际可用的带宽更低，因为 VPS 会与同一台机器上的其他租户共享这条总线。因此，应将这些数字视为几乎无法达到的上限。真正有用的是其变化趋势：在 CPU 上，将每个权重的位数减半，token 速率大致会翻倍。在没有 GPU 的机器上，量化是最有效的提速手段。
提示词处理的情况不同。读取长提示词主要受计算能力限制，而不是受带宽限制，因此增加 CPU 核心数有助于提示词处理，但几乎不会提高生成速度。一台能够快速处理 4k 提示词、随后却生成缓慢的机器，其行为是正常的。
不要直接相信上述计算结果。使用相同的提示词，在每种量化设置下，测量您自己的机器每秒生成的 token 数，并以测量结果为准。
自行量化模型
Ollama 可以从 fp16 或 fp32 源模型构建量化模型。当您完成微调但没有可用的库标签时，这一功能很有用。将 Modelfile 指向未量化的权重：
FROM /path/to/my/model/f16然后进行构建并确认：
ollama create --quantize q4_K_M mymodel
ollama show mymodel--quantize 接受 q8_0、q4_K_S 和 q4_K_M。这里没有 q6_K 或 q5_K_M 选项，因此您需要使用 llama.cpp 自带的工具进行量化，然后导入生成的 GGUF 文件。ollama show 中的 quantization 行用于验证构建结果是否符合要求。
出错时您会看到什么
所有任务都在 CPU 上运行，而您原本预期使用 GPU。 查看 PROCESSOR 列：
ollama ps输出内容为 100% GPU、100% CPU，或类似 48%/52% CPU/GPU 的拆分结果。拆分表示权重和 KV cache 无法全部放入 VRAM（视频内存，即显卡上的内存），因此模型的一部分被放入系统内存。此时速度会降至接近仅使用 CPU 的速率，因为每个 token 都要等待较慢的那一部分。请缩小上下文窗口、对 cache 进行量化，或使用更小的构建版本。增加 CPU 核心数没有帮助。
模型在加载过程中被终止。 检查内核日志和服务日志：
sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50包含 Out of memory: Killed process 的日志行表示权重、KV cache 和缓冲区的总大小超过了该主机的内存容量。在未配置 swap 的 VPS 上，这一行出现前，整台机器可能会卡顿数秒。
回答质量变差，但您没有修改任何内容。 同一模型的两个构建版本可能在 ollama ls 中以不同标签并存，而拉取未带后缀名称的脚本会跟随库当前为该名称指向的版本。请针对客户端请求的确切标签运行 ollama show，并读取 quantization 行，不要仅依赖配置文件中的名称。
FAQ
应该拉取哪种 Ollama 量化版本？
从 q4_K_M 开始。这是 Ollama 库为大多数模型提供的默认标签，因此 ollama pull qwen3:8b 和 ollama pull qwen3:8b-q4_K_M 会获取同一个文件。只有在显存充足且任务对小误差非常敏感时，才改用 q8_0，例如工具调用或结构化 JSON 输出。在内存预算固定时，q4_K_M 的较大模型通常优于 q8_0 的较小模型，因此应先测试这组搭配，再考虑为更高精度分配 RAM。
q4_K_M 真的表示每个权重 4 bit 吗？
不是。在 Llama 3.1 8B 上测得的数值为每个权重 4.89 bit。这是因为每个权重块都会保存自己的缩放值，最敏感的张量会提升到更宽的数据类型。基于同样的原因，Q8_0 的测量值是每个权重 8.5 bit，而不是 8 bit。估算时应使用测量值：参数数量乘以每个权重的 bit 数，再除以 8，即可得到文件大小（字节）。
仅使用 CPU 的 VPS 运行 8B 模型需要多少 RAM？
需要加上权重、KV cache 和余量。Qwen3 8B 使用 q4_K_M 时，权重占用 5.2 GB。在默认的 4096 token 上下文窗口下，cache 还会增加 0.6 GB，因此在计入计算缓冲区和操作系统之前，最低需要约 5.8 GB。在 32k 窗口下，cache 本身就占用 4.83 GB。短窗口建议准备 8 GB，长窗口建议准备 16 GB。
服务器有 GPU，为什么模型仍占用 100% CPU？
运行 ollama ps，查看 PROCESSOR 列。100% CPU 或类似 48%/52% CPU/GPU 的拆分表示权重和 KV cache 无法全部放入显存，因此 Ollama 将部分或全部模型放入系统内存。通常原因是上下文窗口大于显卡容量，因为模型加载时会为整个窗口分配 cache。使用 OLLAMA_CONTEXT_LENGTH 减小窗口，将 OLLAMA_KV_CACHE_TYPE=q8_0 设置为当前值的一半，或拉取更小的量化版本。