选型方法论：一张决策表

本章要回答的问题：面对一个陌生场景，我能不能用一张表推出该选哪个模型、哪个量化、哪个引擎？

先写约束，再谈模型

选型失败的常见原因，是先有偏好（"我想用某某模型"），再去找理由。正确顺序是反过来：把约束写成清单，让清单去筛模型。

需要写下来的六项：

没有量化过的约束不算约束。"要快"不是约束，"首字 2 秒内、每秒 15 token 以上"才是。

第一步：算内存预算。 用 1.6 节的公式，从可用内存倒推权重上限。24GB Mac 的可用额度约 18–19 GB，扣掉 KV、缓冲和余量，权重最好不超过 15 GB。

第二步：定规模档。 权重上限除以每参数字节（Q4_K_M 约 0.6 字节/参数，估算），得到参数量上限。15 GB ÷ 0.6 ≈ 25B，但这是极限值，实际建议留一档：24GB 机器上 9B–14B 是舒适区，26B 级需要谨慎。

第三步：选架构。 显存紧、要求稳定 → dense；显存宽裕、追求"同延迟下更强" → MoE。判据很简单：MoE 的权重必须全部装下，装不下就没有意义。

第四步：选 2–3 个候选。 同一档位里挑不同家族，避免"全家桶"式对比（三个都是 Qwen，测不出家族差异）。本书选 9B dense + 14B dense + 26B MoE，就是为了覆盖三个维度。

第五步：定量化。 先 Q4_K_M，它是质量与体积的默认平衡点。如果内存还有富余且任务对精度敏感，升到 Q5_K_M 或 Q8_0；如果内存不够，降到 Q3_K_M 并接受质量损失。第四部分会给评估方法。

第六步：自测并记录。 用 2.5 节的 12–20 题小集，跑正确率、输出 token 数、耗时、峰值内存。记录格式见下。

把六步画成流程，只有一处真正的分岔（图 2.6-1）：MoE 的权重能不能整套装进可用内存。装不下就没有「折中方案」——它连启动都做不到。

图 2.6-1顺序不能反：先约束后模型，先预算后规模。反过来的结果是先选中一个模型，再找理由支持它。15 GB ÷ 0.6 字节/参数 ≈ 25B 为估算（Q4_K_M 约 0.6 字节/参数）。

这张表覆盖本书会遇到的多数场景。它不是真理，是一组有理由的默认值。表中的型号与体积见 2.1–2.3 节的模型卡与 GGUF 仓库（引用 [1]–[3]），引擎与协议见引用 [4]–[6]。

选型结论要能被别人复核。每次决策至少留下这些字段：

日期：
场景与任务：
硬件（机型/内存/GPU）：
约束（延迟、并发、语言、合规）：
候选模型（仓库 + commit）：
量化格式与文件大小：
引擎与版本：
上下文长度与 KV 估算：
自测结果（正确率 / 输出 token / 耗时 / 峰值内存）：
评估集位置：
结论与理由：
未解决的风险：

把它存进 eval/ 或项目文档。三个月后有人问"为什么选这个"，答案在这里，而不是在某个人的记忆里。

先选模型，再找硬件。 顺序反了，最后只能在"跑不动"和"降级到不能用"之间选。

用榜单代替自测。 榜单筛候选可以，定稿不行（2.5 节）。

忽略分词效率。 两个模型参数一样，中文 token 数差 30%，成本和延迟就差 30%。这是选型里最容易被漏掉的一项。

忽略上下文的成本。 只算权重不算 KV，是 OOM 的头号原因（1.6 节）。

不考虑升级路径。 客户的数据会增长，并发会增长，模型会换代。选型时就要想清楚：换模型要不要重做检索？量化格式能不能平滑迁移？

这一部分结束时，你应该已经有一个明确的结论：用哪个模型、哪个量化、大概多快、占多少内存。

接下来的第三部分处理"怎么把它跑成一个服务"：模型格式、引擎选择、对话模板、采样参数、API 封装、并发与测量。第四部分处理"压缩到什么程度还能用"。这两部分合起来，才是完整的"部署一个模型"。