主题
参数量取舍（实验：8B 对比 14B）
本章要回答的问题：8B 和 14B 到底差在哪？为什么本书选 8B 当主力，14B 只用来做对比实验？
参数量买到的是什么
参数量的第一性原理来自缩放定律（scaling law）：在其他条件相同的情况下，参数更多、训练数据更多的模型，损失更低（引用 [1]）。Chinchilla 的结论进一步给出一个经验比例：在固定计算预算下，参数量和数据量应该同步增长，大约每参数 20 个训练 token（引用 [2]）。
但训练最优不等于推理最优。推理时你关心的不是"同样的算力谁的损失低"，而是"在我能接受的延迟和内存里，谁答得更好"。这两件事的方向经常相反：
- 参数翻倍，质量可能提升几个百分点；
- 参数翻倍，内存翻倍，decode 速度大致减半。
所以参数量不是一个"越大越好"的旋钮，而是一笔交易。
三个模型的实际账本
| 模型 | 总参数 | Q4_K_M 权重 | 每 token KV（f16） | M4 理论 decode 上限（估算） |
|---|---|---|---|---|
Qwen3.5-9B | 9B | 5.68 GB | 32 KiB | 约 21 token/s |
Qwen3-14B | 14.8B | 9.0 GB | 160 KiB | 约 13 token/s |
Gemma-4-26B-A4B | 26B（激活约 4B） | 16.95 GB | 混合结构，按层算 | 按激活部分约 46 token/s（估算） |
（参数与上下文取自模型卡与 config.json，引用 [3][4]；权重取自 GGUF 仓库，引用 [5][6]。Gemma-4-26B-A4B 的权重见 2.3 节。KV 与速度按 1.4、1.5 节的公式估算；MoE 的速度估算假设只读取激活的专家。）
本书说的"8B 级"实际使用 Qwen3.5-9B——这一代没有 8B 档，下文一律写 9B。
这张表里最值得注意的是 9B 和 14B 的 KV 差距：5 倍。原因不是参数量，而是架构——9B 是混合线性注意力，只有 1/4 的层有 KV Cache；14B 是标准 Transformer。这说明"参数多 60%"并不能推出"内存多 60%"，架构的影响可能更大。
9B 和 14B 的对比不干净
这一点必须提前说清楚，否则后面的实验结论会被误读。
Qwen3.5-9B 和 Qwen3-14B 不是同一代模型。前者更新、分词器更大、架构不同。所以两者对比时，差异来自三个变量叠加：规模、代际、架构。你无法从结果里分离出"多 5.8B 参数贡献了多少"。
那为什么还这么选？因为本书的目标不是做消融研究，而是回答一个工程问题：在 24GB 的机器上，多花 3.3 GB 内存和一半的速度，换 14B，值不值？
这个问题的答案取决于任务：
- 如果任务是"从检索片段里摘出答案并附出处"，9B 通常够用，速度优势明显；
- 如果任务需要多步推理、单位换算、条款比对，14B 的准确率优势可能盖过速度劣势；
- 如果是批量离线处理（不在乎延迟），更大模型几乎总是更划算。
本书的立场是：默认 9B，遇到明确的失败再升到 14B，并用评估集证明升级有效。 这个顺序比"一上来就选最大的"更省钱，也更符合"先跑起来再优化"的原则。
24GB 的预算怎么分
把 1.6 节的账本套进来，24GB Mac 的可用额度约 18–19 GB（估算）：
| 方案 | 权重 | KV | 其他开销 | 小计 | 含 20% 余量 | 结论 |
|---|---|---|---|---|---|---|
| 9B + 8K | 5.68 | 0.27 | 1.5 | 7.45 GB | 8.9 GB | 舒适，可开 2–3 并发 |
| 14B + 8K | 9.0 | 1.34 | 1.5 | 11.84 GB | 14.2 GB | 可行，余量中等 |
| 14B + 32K | 9.0 | 5.37 | 1.5 | 15.87 GB | 19.0 GB | 卡在可用额度边缘 |
| 26B-A4B + 8K | 16.95 | 约 1 | 1.5 | 19.45 GB | 23.3 GB | 超出可用额度，只能勉强跑 |
"并发"是一个容易被忽略的乘数：每个并发请求都有自己的 KV Cache，权重则是共享的。9B + 8K 单请求含余量约 8.9 GB，三个并发再加两份 KV（0.54 GB），约 9.4 GB，仍然舒适；14B + 32K 单请求就要 19.0 GB，两个并发直接超出 24GB 的上限。
什么时候该升到 14B
给几条可操作的判断，而不是"看情况"：
- 评估集上 9B 的错误集中在"需要多步推理"的题，而不是"找不到材料"——后者是检索问题，换模型没用。
- 延迟预算允许。 如果首字延迟目标 3 秒、输出 200 token，14B 在 M4 上大约需要 3 + 200/13 ≈ 18 秒（估算），大概率不达标。
- 并发低。 一两个人用，单请求延迟可以放宽；十个人同时用，就必须算总吞吐。
- 内存有余量。 24GB 上跑 14B + 长上下文已经开始挤压系统，32GB 会舒服很多。
反过来，如果 9B 的失败是"答非所问""引用错段落""答得太啰嗦"，先修检索和提示词，不要换模型。这是第六部分反复强调的归因顺序。
动手实验
动手实验：9B 与 14B 的性价比
假设：在"从材料中摘取答案"类任务上，9B 与 14B 的准确率差距小于 10 个百分点，而 9B 的速度快约 1.5 倍；在需要多步推理的任务上，差距会扩大。
准备：在 eval/ 里建一个 20 题的小集，每题包含问题、标准答案、出处（文档名 + 页码），覆盖三类任务：直接摘取、跨段组合、简单推理。
命令：
bash
# 速度基线
llama-bench -m "$MODEL" -p 512 -n 128 -r 5 -o csv
llama-bench -m Qwen3-14B-Q4_K_M.gguf -p 512 -n 128 -r 5 -o csv # 可选，需另行下载
# 质量对照：同一提示词、同一采样参数、同一上下文长度，各跑 20 题
mkdir -p out
for i in $(seq -w 1 20); do
llama-completion -m "$MODEL" -c 8192 --temp 0 -n 256 \
-f eval/prompts/q$i.txt --no-display-prompt > out/q$i.txt
done记录：每题是否正确（对照标准答案人工判定）、是否给出正确出处、输出 token 数、耗时。按任务类型分组统计，不要只报总分。数据存 benchmarks/param-tradeoff/。
用 llama-completion 而不是 llama-cli，是因为前者的标准输出只有生成内容，可以直接重定向；后者会把启动 banner 一并写进去，还要手工剔除。代价是不套对话模板——跨模型比较时这反而是优点：模板差异被排除，只剩权重差异。上线路径上的模板效应留给 3.3 节和服务接口实验。
参考资料
- Kaplan, J. et al. Scaling Laws for Neural Language Models. arXiv:2001.08361. https://arxiv.org/abs/2001.08361
- Hoffmann, J. et al. Training Compute-Optimal Large Language Models. arXiv:2203.15556. https://arxiv.org/abs/2203.15556
- Qwen. Qwen3.5-9B 模型卡与
config.json. https://huggingface.co/Qwen/Qwen3.5-9B - Qwen. Qwen3-14B 模型卡与
config.json. https://huggingface.co/Qwen/Qwen3-14B - Unsloth. Qwen3.5-9B-GGUF. https://huggingface.co/unsloth/Qwen3.5-9B-GGUF
- Qwen. Qwen3-14B-GGUF. https://huggingface.co/Qwen/Qwen3-14B-GGUF