模型选型：参数量、架构与量化精度对成本的影响

模型选型这事儿，说白了就是「用多大的枪打多大的鸟」。我见过不少团队，上来就上 70B，结果 GPU 集群烧钱烧得心疼，最后发现 7B 微调一下完全够用。反过来也有，用 7B 硬扛复杂推理任务，效果差到被业务方投诉。

这一章，咱们就掰开揉碎聊聊：不同参数量到底差多少钱？MoE 是不是真的省钱？量化精度怎么选才不翻车？

参数量级：7B、13B、70B 的真实成本差异

先看一组我实际跑过的数据。假设你用 A100-80G，FP16 精度，单次推理的 batch size = 1：

模型规模	显存占用（FP16）	单次推理延迟	单卡吞吐（req/s）	单次推理成本（估算）
7B	~14 GB	~30 ms	~30	极低
13B	~26 GB	~60 ms	~15	中等
70B	~140 GB	~300 ms	~3	高

注意，70B 单卡根本放不下，必须用张量并行。我习惯用 8 卡 A100 跑 70B，这时候通信开销会吃掉不少性能。实际吞吐不是 3 req/s，而是 2 左右。

那什么时候该用大模型？我个人经验是：

• 7B：文本分类、简单问答、代码补全、摘要生成。效果够用，成本可控。
• 13B：中等复杂度的对话、翻译、逻辑推理。性价比最高的区间。
• 70B：复杂推理、数学证明、长文本理解、代码生成。只有业务价值足够高时才上。

稠密模型 vs MoE：省钱还是烧钱？

MoE（Mixture of Experts）这两年特别火。说白了，就是把一个大模型拆成多个「专家」，每次推理只激活其中一部分。听起来很省对吧？

嗯，这里要注意：MoE 的参数量看着大，但实际计算量确实小。比如 Mixtral 8x7B，总参数量 46B，但每次推理只激活两个专家，实际计算量相当于 12B 左右。

但成本不是这么简单算的。我踩过一个坑：

来看对比：

模型	总参数量	激活参数量	FP16 显存	推理延迟	适用场景
Llama 2 13B（稠密）	13B	13B	~26 GB	~60 ms	通用任务
Mixtral 8x7B（MoE）	46B	~12B	~92 GB	~70 ms	高吞吐、多任务
Llama 2 70B（稠密）	70B	70B	~140 GB	~300 ms	复杂推理

你看，MoE 的延迟确实接近 13B，但显存成本接近 70B。所以：

• 如果你追求低延迟，MoE 很香。计算量小，响应快。
• 如果你追求低显存，MoE 不香。参数全加载，卡数少不了。
• 如果你做批量推理，MoE 的吞吐优势会放大。因为计算量小，单卡能塞更多请求。

量化精度：FP16、INT8、INT4 的成本博弈

量化，说白了就是给模型「减肥」。FP16 是 16 位浮点，INT8 是 8 位整数，INT4 是 4 位整数。位数越少，模型越小，推理越快，但精度可能下降。

我直接给结论：

精度	显存节省	推理加速	精度损失	我的推荐
FP16	基准	基准	无	开发调试、精度敏感场景
INT8	~50%	~1.5x - 2x	几乎无感	生产环境首选
INT4	~75%	~2x - 3x	部分任务有感知	显存极度紧张时使用

为什么会这样？因为 INT8 量化技术已经很成熟了。我用过 GPTQ、AWQ、GGUF 这些方案，INT8 下 7B 模型从 14 GB 降到 7 GB，单卡就能跑，延迟从 30 ms 降到 18 ms 左右。

INT4 呢？嗯，这里要小心。我踩过坑：

所以我的建议是：

• FP16：基准线，用于对比和调试。
• INT8：默认选择，性价比最高。
• INT4：仅当显存不够或需要极致吞吐时使用，且必须做效果验证。

一张图看懂选型逻辑

下面这张图总结了我做模型选型时的决策路径：

这张图的逻辑很简单：先看精度要求，再看延迟要求，最后组合出最优方案。你想想看，如果业务场景是智能客服，精度要求不高但延迟要快，那 INT8 + MoE + 7B 就是最佳组合。如果是代码生成，精度敏感，那就 FP16 + 稠密 + 13B 起步。