Ollama量化怎么选：q4_K_M、q8_0还是fp16

Ollama 量化会改变什么

Ollama 量化会以少于训练文件的位数存储模型中的每个权重。以 q4_K_M 结尾的标签表示每个权重约使用 4 bit，而 fp16 使用 16 bit，因此下载文件大小约为原来的四分之一，计算每个 token 时，机器读取的字节数也约为四分之一。权重会被舍入到较粗的网格上，而不是直接丢弃；对于大多数模型，使用 4 bit 时，其回答方式与全精度下接近。

这就是完整的权衡：内存占用大幅降低，每秒生成的 token 数增加，但准确性会略有下降。下面介绍如何在下载文件前，针对特定模型和特定服务器预测这两方面的影响，避免花 20 分钟下载一个无法装入内存的文件。

如果 Ollama 尚未运行，请先阅读在 VPS 上安装 Ollama。本页面假定 ollama ls 已经正常运行。

如何读取 Ollama 量化标签，例如 q4_K_M

本地模型以 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_M

ollama show 会输出 architecture、parameters、quantization、context length 和 embedding length。对于几个月前拉取、已经不记得当时选择了哪个版本的模型，quantization 行才是准确依据。

每个权重占用的位数决定文件大小

所有大小估算都从一个数字开始：整个文件平均每个权重使用多少位。llama.cpp 在其量化文档中公布了 Llama 3.1 8B 的实测数据。这些数据也适用于形状相近的其他稠密模型。

[
  {
    "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 标签。少数较新的模型系列不遵循这一模式，在模型库中仅显示为云端标签，任何大小都没有可供拉取的模型。这就是 尝试在 VPS 上运行 GLM 5.2 时遇到的限制。以下是截至 August 2026 的 Qwen3 大小，数据来自模型页面上的标签列表。下面的每个数值表示磁盘占用，而不是 RAM 占用；其中两个或三个模型就可能占满小型 VPS 的根卷。因此，在开始收集标签前，最好先了解 Ollama 将下载的模型存储在哪里。

[
  {
    "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 的三倍。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 的成本乘以窗口大小后，缓存就不再是可以忽略的误差。

[
  {
    "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 token 窗口下，缓存会在权重之外额外占用 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 及其成本详细介绍了窗口本身。缓存还会按并发请求槽分配一次，而不是按服务器分配一次。因此，如果允许 Ollama 同时处理两个请求，刚才估算的数值就会翻倍。这也是选择并行槽数量和队列限制背后的计算依据。

8、16 或 32 GB VPS 上适合运行的模型

预算应包括权重、KV cache，以及操作系统和其他运行中组件所需的余量。在小型 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，因此也能运行。针对您自己的提示词比较这两种配置，是您在这个问题上最值得投入的一小时。

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 的机器上，fp16 还会使 token 生成速率降至三分之一。

在内存预算固定时，更可靠的规则是：使用 q4_K_M 的较大模型通常优于使用 q8_0 的较小模型。14B 权重占用 9.3 GB，8B 权重使用 q8_0 占用 8.9 GB；两者的 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 的主机，量化是可用的最大提速手段。最终速率是否可接受取决于模型，而 在 VPS 上运行 Nemotron 3.5 Lightning 会针对一个特定的构建版本、标签和内存配置完成这项计算。等待时间的另一部分取决于模型生成的内容长度，因为即使速率达到每秒 10 个 token，生成 600 个 token 的回答也需要整整 1 分钟。因此，使用 num_predict 限制回复长度 通常比进一步降低精度更能减少等待时间。

提示词处理的情况不同。读取长提示词主要受算力限制，而不是内存带宽限制，因此增加 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 文件。导入方式还有一个容易踩坑的问题：聊天模板不匹配会导致模型输出乱码。将 GGUF 文件导入 Ollama 介绍了完整流程。ollama show 中的 quantization 行用于确认构建结果符合您的要求。

发生问题时的现象

所有任务都在 CPU 上运行，而不是预期的 GPU。 查看 PROCESSOR 列：

ollama ps

其中会显示 100% GPU、100% CPU，或类似 48%/52% CPU/GPU 的拆分结果。拆分表示权重和 KV cache 无法全部装入 VRAM（video RAM，即显卡上的内存），因此部分模型被放入系统内存。随后速度会接近仅使用 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 上下文窗口下，缓存还会增加 0.6 GB。因此，在计算缓冲区和操作系统占用内存之前，最低需要约 5.8 GB。在 32k 窗口下，仅缓存就占用 4.83 GB。短窗口按 8 GB 规划；如果需要长窗口，则按 16 GB 规划。

为什么机器有 GPU，但模型仍占用 100% CPU 运行？

运行 ollama ps，然后查看 PROCESSOR 列。100% CPU 或类似 48%/52% CPU/GPU 的拆分结果表示权重和 KV cache 无法全部放入显存，因此 Ollama 将部分或全部模型放入系统内存。通常原因是上下文窗口超过了显卡容量，因为模型加载时会为整个窗口分配缓存。使用 OLLAMA_CONTEXT_LENGTH 减小窗口，将 OLLAMA_KV_CACHE_TYPE=q8_0 设置为缓存大小的一半，或拉取更小的量化版本。