本地大模型学习 02：Q4 与 Q8 量化对照，精度是否值得内存成本

上一阶段我已经能在 LM Studio 中加载 Qwen3.5 4B，通过本地 API 发送请求，并观察提示词、推理模式、temperature、token、上下文长度和 TTFT 的变化。这一阶段继续追问一个更实际的问题：同一个模型换成更高精度的量化版本后，回答真的会明显变好吗？它增加的内存和速度成本是否值得？

这次实验仍然在 Apple M5、16 GB 统一内存的 Mac 上完成。实验设计和排查有 AI 助手协助，但下面的指标来自我实际加载模型、发送请求和读取进程状态的结果。

先说结论

我比较了同一个 Qwen3.5 4B 的 Q4_K_S 和 Q8_0 两个 GGUF 版本，并保持上下文长度、并行数、GPU 卸载、提示词和采样参数一致。

Q8 的资源估算约为 Q4 的 1.99 倍，请求后的 RSS 高约 45.5%。这组 656 token 的短输入中，TTFT 只增加约 2.8%，没有出现与内存成本同等幅度的延迟增加。

我又用同一条故障分析任务比较回答质量。两个版本都完成了要求的四个部分，但没有观察到 Q8 的明确质量收益。Q8 的回答更长，并加入了 KV Cache、GC、Swap、OOM 等记录外机制；这些词只是模型提出的候选解释，不是实验记录已经证明的事实。

因此，在当前任务和这台 Mac 上，我选择 Q4_K_S 作为日常主力。只有在某个具体的质量敏感任务经过独立评测，确实显示 Q8 有收益时，才有理由临时使用 Q8_0。

量化到底改变了什么

Quantization（量化）是把模型权重从较高数值精度压缩为更少位数表示的方法。它主要改变每个权重的存储方式，不改变模型的参数数量；Qwen3.5 4B 仍然是大约 40 亿参数。

这次比较的两个版本是：

• Q4_K_S：较低位数的 GGUF 量化版本，文件更小，预计更省内存。
• Q8_0：较高位数的 GGUF 量化版本，量化误差通常更小，但存储和运行成本更高。

“量化位数更高”只说明权重表示可能更精细，不等于每一个任务都会得到更准确的答案。最终是否值得，要同时看资源、速度和任务质量。

实验如何控制变量

为了不把模型规模、后端或上下文配置的影响误认为量化差异，我固定了以下条件：

实验前我的预测是：Q8 文件更大、内存占用更高，TTFT 和生成速度可能变慢，回答质量可能略有提升，但简单任务未必能看出来。

先建立 Q4 基线

下面的命令是本次实验使用的本机模型加载方式。它只改变本地 LM Studio 的当前加载模型，不会修改模型文件；执行前需要已经安装 LM Studio，并确保没有其他请求依赖这个本地服务。

风险等级：CAUTION（会切换本地模型，短暂影响本机服务）

作用： 加载 Q4_K_S，作为后续 Q8_0 对照的基线。 执行对象： 当前 Mac 上的 LM Studio 本地模型服务。 前提： 模型已经出现在 LM Studio 的模型列表中；--context-length、--parallel 和 --gpu 是本次实验需要保持不变的条件。 验证： 使用 lms ps --json 检查模型标识、上下文长度和并行数。

~/.lmstudio/bin/lms load unsloth/qwen3.5-4b \
  --context-length 8192 \
  --parallel 4 \
  --gpu max \
  --identifier qwen35-q4 \
  --yes

~/.lmstudio/bin/lms ps --json | jq '.[] | {
  identifier,
  status,
  contextLength,
  parallel
}'

Q4 成功加载后的状态是 qwen35-q4、上下文长度 8192、并行数 4。加载时资源估算显示为 2.41 GiB。

固定短输入：观察输入处理和资源快照

这个请求让模型严格只输出“收到”，目的是让输出阶段尽可能短，主要观察输入 token 数和 TTFT。README.md 的实际路径需要替换为读者自己的学习项目目录；本次实验是在该项目目录中执行的。

风险等级：INFO（只读性能测量）

作用： 将同一份文本发送给当前加载的模型，记录 input token、TTFT 和生成速度。 执行对象： 本机 http://127.0.0.1:1234 的 LM Studio Local Server。 前提： Local Server 已启动，README.md 存在，MODEL_ID 必须与 lms ps 中的 identifier 一致。 验证： 返回中的 error 应为 null，并检查 stats 中的统计字段。

MODEL_ID=qwen35-q4

REQUEST=$(jq -n --arg model "$MODEL_ID" --rawfile input README.md '{
  model: $model,
  system_prompt: "请严格只回答：收到",
  input: $input,
  reasoning: "off",
  temperature: 0.1,
  max_output_tokens: 16,
  stream: false
}')

printf '%s' "$REQUEST" \
| curl -sS -N 'http://127.0.0.1:1234/api/v1/chat' \
  -H 'Content-Type: application/json' \
  --data-binary @- \
| jq '{
  error,
  input_tokens: .stats.input_tokens,
  output_tokens: .stats.total_output_tokens,
  ttft_seconds: .stats.time_to_first_token_seconds,
  tokens_per_second: .stats.tokens_per_second,
  output
}'

Q4 的返回是：输入 656 token，输出 2 token，TTFT 为 1.139743 秒，生成速度为 36.718807 token/s，回答内容为“收到”。请求后的 llama-server RSS 快照为 2936.7 MiB。

这里有一个重要限制：输出只有 2 个 token，因此 tokens_per_second 受测量粒度和固定开销影响很大，不能把它当成稳定的解码吞吐结论。这个请求更适合观察短输入的 TTFT 和运行状态。

换成 Q8，只改变量化版本

记录完 Q4 后，我卸载它，再加载同一个基础模型的 Q8_0 版本。卸载和加载是可逆的，但会让当前本地服务短暂没有可用模型，因此没有在有实际调用者的服务上执行。

风险等级：CAUTION（切换本地服务中的模型）

作用： 卸载 Q4 并加载 Q8，保持上下文、并行和 GPU 配置不变。 执行对象： 当前 Mac 上的 LM Studio Local Server。 重要参数： 只有模型来源、identifier 和量化版本改变；其他加载参数必须与 Q4 相同。 验证： lms ps --json 应显示 qwen35-q8、8192 和并行数 4。

~/.lmstudio/bin/lms unload qwen35-q4

~/.lmstudio/bin/lms load lmstudio-community/qwen3.5-4b \
  --context-length 8192 \
  --parallel 4 \
  --gpu max \
  --identifier qwen35-q8 \
  --yes

~/.lmstudio/bin/lms ps --json | jq '.[] | {
  identifier,
  status,
  contextLength,
  parallel
}'

Q8 成功加载，资源估算显示为 4.80 GiB。使用同样的 656 token 输入后，TTFT 为 1.171647 秒，输出仍然是 2 token 的“收到”，请求后 RSS 为 4272.9 MiB。

Q8 的资源成本明显更高，但短输入的 TTFT 只比 Q4 高约 2.8%。这提醒我，模型加载资源和一次短请求的首字延迟不是同一个指标，不能因为模型文件接近两倍，就直接推断 TTFT 也会接近两倍。

质量敏感任务：更详细不等于更可靠

性能测试之后，我用同一条故障分析任务比较回答质量。提示词要求模型分成四部分：直接证据、最可能的推断、仍未证明的事项、两个只读验证步骤，并明确禁止把推断写成事实。

输入记录只有四条：模型加载成功；并发数为 1 时 18 秒完成；并发数为 4 时出现 memory pressure warning 并在 60 秒后超时；没有模型文件读取或校验错误。

质量任务的接口统计如下：

两种量化都完整输出了四个部分，直接证据也都抓住了两个重点：并发升高后出现内存压力警告和请求超时，以及日志没有模型文件错误。

差异出现在推断的展开方式上。Q8 提到了“上下文缓存膨胀”“GC 停顿”“交换延迟”“OOM”等机制；Q4 则提到了 GPU 显存、堆内存、CPU 调度、磁盘 I/O 和网络带宽等可能性。这些机制都没有出现在给定记录里，因此最多只能算候选假设，不能算已经发生的事实。

Q8 的回答更长，并没有因此变成更有证据的回答。相反，回答越详细，越需要检查其中是否混入了记录外推断。Q4 的答案也不是完全没有越界，但在这一个样本中更简洁；这仍然不足以证明 Q4 在所有分析任务上都优于 Q8。

这次实验实际证明了什么

这次实验支持以下结论：

1. 在相同基础模型和加载配置下，Q8_0 的文件与运行资源成本明显高于 Q4_K_S。
2. 对 656 token 的短输入，Q8 的 TTFT 只比 Q4 略高，资源成本和 TTFT 增幅没有同步扩大。
3. 在这条质量敏感任务上，Q8 没有显示明确的质量收益；更长的回答不能替代更充分的证据。
4. 评估本地模型时，应该同时记录资源、延迟、输出格式、事实边界和未证明事项。

这次实验不能证明：

• Q8 在所有任务上都比 Q4 更准确；
• 一次 RSS 快照就等于模型完整的统一内存占用；
• 单次 TTFT 或生成速度就是长期稳定性能；
• 模型提到的 KV Cache、GC、Swap 或 OOM 一定真实发生。

我的选择与下一步

在 16 GB 统一内存的 Mac 上，Q4_K_S 已经能够满足当前的 API、结构化输出和故障分析学习任务。Q8_0 的资源成本更高，但本次没有显示足以抵消成本的质量改进，所以我把 Q4_K_S 作为日常主力。

下一步不再下载更多相邻量化版本，而是使用已有固定测试集，选择事实问答、资料不足时的拒答、严格格式总结和客观权衡等代表性题目，建立一个小型质量评测。只有当具体任务出现 Q4 明显不足时，才重新测试 Q8 是否值得启用。