很多人一上来就问「到底选大的还是小的」，结果被参数、跑分和别人的推荐带偏。这篇不给你标准答案，而是给一套自己算得出来的判断顺序：先看任务错一次的代价，再看延迟和显存能不能兜住，最后才谈模型大小。看完你能画出自己场景下的大小模型分界线，也知道什么情况下这个判断不成立。
很多人一上来就问「到底选大的还是小的」，结果被参数、跑分和别人的推荐带偏。这篇不给你标准答案，而是给一套自己算得出来的判断顺序：先看任务错一次的代价，再看延迟和显存能不能兜住，最后才谈模型大小。
看完你能画出自己场景下的大小模型分界线，也知道什么情况下这个判断不成立。下面按能力差异、成本延迟、场景对照、落地步骤、常见误判五段走，每段都落到能动手做的事上。
差别到底在哪：不是只有参数数量
大小模型最实在的差别有三条：能不能泛化到没见过的任务、对模糊指令的容错、长链条推理的稳定度。参数规模主要影响这三项，不是说大模型「什么都更强」。有些任务上小模型照样打平，只是它撑不住新花样。
- 泛化
- 遇到训练里没见过的任务形态时，能不能给出可用结果
- 容错
- 你的指令写得含糊、格式不规整时，模型能不能猜对你的意图
- 长链条推理
- 需要多步中间结论的任务，前面错一步后面会不会崩
联系在于两者同源：小模型常由大模型蒸馏或剪枝而来，能力分布接近，但天花板低一档。所以你在熟悉的任务上能追平，一遇到新场景就掉队。选型时先问自己：这个任务的输入形态稳定吗？稳定就偏向小模型。
什么情况下差异不明显：任务边界清晰、输出格式固定、有明确参考答案的场景，大小模型的实际差距会明显收窄。反过来，任务还在探索期、你连输入输出长什么样都没定，这时候比大小没意义。别只盯参数量，量化档位、上下文长度、是不是推理型，对结果的影响可能比参数规模还大。这几个概念先去站内 /ai-dict/category/tech 对齐，再谈比较。
成本和延迟：小模型省的不只是钱
成本要分三笔算，别混在一起：单次调用费、单位时间吞吐（同一张卡能扛多少并发）、首字延迟。小模型在吞吐和延迟上通常占优，调用费的优势反而是其次——因为并发不够要加卡，那才是大头。具体单价到 /models 价格页和 /price-watch 核对当时的数字。
| 维度 | 大模型的典型表现 | 小模型的典型表现 |
|---|---|---|
| 单次调用费 | 偏高 | 偏低 |
| 并发吞吐 | 同卡并发少 | 同卡并发多 |
| 首字延迟 | 通常更长 | 通常更短 |
| 重试概率 | 低容忍任务上更低 | 边界模糊时更高 |
显存决定你能跑多大的模型，也决定并发上限。按参数量和量化档位算一遍，再去 /models/deploy 核对部署侧的实际口径，别凭感觉估。什么情况下小模型不省钱：任务需要多轮重试、需要人来复核输出，人工成本会吃掉省下的算力钱。自建还是按量调用的分界，另有一篇讲透了，这里只管「同一预算下选大还是选小」。
适用场景对照：谁干什么活
- 高容错、大批量、格式固定：分类打标、内容初筛、结构化抽取、意图识别，小模型通常是更划算的起点
- 低容错、长链条、要解释：复杂代码改动、跨文档推理、方案设计、合规审阅，大模型或推理型的下限更稳
- 混合架构是常态：小模型做前置过滤和路由，大模型只处理被挑出来的疑难样本，这是最容易被忽略的省钱方式
- 还在探索期的任务：先别优化模型大小，先把输入输出定下来
混合架构值得单独说一句。举个例子，一家 5 人小团队做客服工单分类，可以让小模型先跑一遍分类和路由，把置信度低的那部分丢给大模型兜底。这样既压住了平均延迟，又不会在最难的样本上翻车。实现上就是两段调用加一个阈值判断，不需要复杂工程。
落地动作：四步定下你的分界线
- 写代价写下任务错一次的代价和可接受的错误率。没有这个数就没法比较，也说不清「够用」是什么标准。
- 跑样本准备二三十条真实样本，大小模型各跑一遍，人工只看「能不能用」，先不评分。这一步是为了筛掉明显不合适的选项。
- 分失败原因把不达标的样本按失败原因分类：知识不够、指令没跟住、还是推理断了。只有第三类才值得上更大的模型，前两类多半是提示和数据的问题。
- 定降级顺序先降量化档位，再减小模型，最后才降上下文和并发。顺序反了会白花很多时间，还容易把问题归错地方。
定完别忘留回退方案。模型换代时怎么验证新版本没退化，可以照 model-upgrade-migration-checklist 那篇的流程走一遍。分界线不是定一次就完事，任务变了、数据变了都要重跑。
容易踩的三个误判
- 把「大模型答得漂亮」当成「我的任务需要大模型」：多数场景差的是提示和数据处理，不是模型规模
- 用榜单名次代替实测：榜单任务和你的任务经常不是一回事，差距多大得自己跑，榜单怎么读看 ai-benchmark-ranking-reading
- 只比单价不比总成本：重试次数、人工复核、并发不够要加卡，这些都不在单价里
不适用提醒：如果你的场景有硬性合规要求或数据不能出内网，选型顺序要整体重排，先过合规再谈大小。这种情况下可选的模型范围会被卡死，前面的成本比较可能直接用不上。
选大还是选小，从来不是模型的问题，是你任务的问题。下一步拿你手上最真实的一批样本，去站内模型库和部署页面对一遍参数量、量化档位和上下文口径，再回来定自己的分界线。→
常见问题
小模型是不是就是大模型压缩出来的？
不全是。有蒸馏、剪枝、量化这几条路，也有直接从小规模从头训练的。差别在于前者和原模型的能力分布更像，后者可能在某些专项上更稳但在通用任务上更弱。判断方法不是看它怎么来的，而是拿你自己的样本跑一遍，看失败样本错在哪。
参数越大效果一定越好吗？
不一定。同一代架构下通常成立，但跨代、跨训练数据、跨量化档位就不成立。更常见的情况是：一个大模型量化到很低档位，反而不如一个原生就小的模型稳。所以比较时要固定其他变量，只动参数量这一项。
预算有限先砍哪一项？
先砍并发和上下文长度，再降量化档位，最后才换更小的模型。原因是前三项影响的是速度和边界，换模型影响的是能力下限。不过这条顺序在你对延迟极度敏感时不适用，那种情况要先保速度。
