7B、14B、70B、旗舰 API——模型越大效果越好，但账单与延迟也越吓人。选型不是”越大越好”或”越小越省”的二选一，而是一道效果-成本-延迟的三目标优化题。本文给出成本模型、量化杠杆与分层路由三个决策工具。

先建成本模型：钱花在哪

推理成本由三部分构成：

  • 显存占用 ≈ 参数量 × 每参数字节（FP16=2B、INT8=1B、INT4=0.5B）+ KV cache（随上下文长度线性增长）。7B FP16 ≈ 14GB 显存起步；70B FP16 单卡放不下
  • 计算量 ≈ 2 × 参数量 × token 数（每 token 一次全参数矩阵乘）——参数翻倍，每 token 成本翻倍
  • 延迟 = 首 token 延迟（prefill，随输入长度）+ 逐 token 生成（decode，受显存带宽限制）

由此推出硬约束：候选模型必须先过”显存放得下”与”延迟可接受”两关，效果比较只在过关者之间进行。

量化：最便宜的降成本杠杆

  • FP16 → INT8：显存减半，多数任务效果损失 <1%
  • INT8 → INT4：再减半，复杂推理开始可见损失（用 AWQ/GPTQ 等校准量化可缓解）
  • 实践顺序：先试 INT4/INT8 量化版大模型，对比 FP16 小模型——**”量化的大”常常赢过”全精的小”**（知识容量在参数里，量化只是压缩表示）

效果-规模的经验规律

  • 通用能力随规模平滑上升（scaling law），但特定垂直任务上，微调小模型可追平甚至超过通用大模型（ LoRA 微调 7B 在分类/抽取类任务上常见追平 70B 零样本）
  • 推理类任务（数学/多步规划）规模收益最陡，小模型天花板明显
  • 因此选型第一问：**任务是需要”广博知识+复杂推理”，还是”窄域模式匹配”**？前者买大，后者训小

分层路由：让每个 token 花该花的钱

生产系统的标准架构是模型路由（LLM router）：

  • 简单请求（FAQ、格式转换、简单分类）→ 1-3B 本地小模型或量化 7B
  • 中等请求（摘要、普通问答）→ 7-14B
  • 困难请求（复杂推理、代码生成、多文档综合）→ 70B+ 或旗舰 API
  • 路由器本身：一个小分类模型或规则+置信度回退（小模型低置信时升级大模型）

成本收益：80% 流量落在小模型时，总成本可降一个数量级而体验无损。

决策速查表

场景 推荐 理由
端侧/边缘、离线 1-3B INT4 显存与功耗硬约束
垂直分类/抽取 微调 7-8B 窄域任务微调收益最大
通用助手自托管 14B INT8 / 32B INT4 效果成本平衡点
复杂推理/代码 70B+ 或旗舰 API 规模收益最陡区
流量大成本敏感 路由分层 让简单请求便宜
原型验证 API 旗舰 先验证价值再谈成本

别忘了隐性成本

  • 上下文长度：长上下文使 KV cache 显存暴涨，RAG 场景控制召回量比选小模型更省钱
  • 批处理与并发：decode 阶段显存带宽是瓶颈，batch 提升吞吐但不降单请求延迟——成本核算要按吞吐口径
  • 失败重试：小模型错误率高的任务，重试与人工兜底成本可能反超大模型一次做对

模型选型的完整答案 = 显存/延迟硬约束过滤 → 量化杠杆压成本 → 任务类型定规模（窄域训小、推理买大）→ 路由分层省总账。记住”量化的大常赢全精的小”与”80% 流量该走小模型”两条经验，多数选型争论就有了裁决依据。