垂域小模型和垂域大模型对比

很多团队做垂域项目时，第一反应是「参数越大越准」，结果卡在两头：小模型效果压不住，大模型一张卡跑不动、成本也收不回。这篇不评谁强谁弱，而是给一套可执行的判断顺序——先看任务形态和数据量，再算显存与并发，最后用一小批真实样本把两条路都跑一遍再定。

很多团队做垂域项目，第一反应是「参数越大越准」，结果往往卡在两头：小模型效果压不住，大模型一张卡跑不动、成本也收不回来。问题不在谁强谁弱，而在于选型顺序搞反了——先看任务形态和数据量，再算显存与并发，最后用一小批真实样本把两条路都跑一遍再定。

这篇给一套可执行的判断流程，帮你判断垂直领域到底该用垂域小模型还是垂域大模型。不承诺结论，只给判断标准和动作，每条判断都写清楚什么情况下不适用。看之前可以先到模型资料库熟悉候选范围，具体价格、参数、上下文长度这些数字到 /models 核对当时的版本。

先分清任务形态，再谈模型大小

判断顺序的第一层不是模型，而是任务。同一段业务文本，让模型做「抽字段」「分类打标」「固定格式改写」，这类窄任务往往小模型微调后就能吃下；让模型做多轮对话、跨章节长文推理、边聊边查资料，宽任务更依赖大模型的基础能力。先归类，再看模型库，能省掉大量试错。

窄任务

输入输出结构固定，比如抽取订单要素、判定工单类别，小模型微调后通常够用

宽任务

多轮对话、长文档推理、需要上下文推理和常识补全，基础能力弱的小模型容易崩

知识要新

领域知识经常更新，优先 RAG 加通用模型，不要把知识训进权重

格式要稳

输出必须严格符合模板或术语口径，才值得考虑微调

常见翻车是把「知识要新」和「格式要稳」混在一件事里。知识要新，说明你在跟时效赛跑，走 RAG 更新检索库比重训便宜；格式要稳，说明你在锁口径，走微调或约束解码更合适。两件事混在一起，就会觉得小模型怎么调都不对——其实不是模型不行，是路线选错了。

写清适用边界之前，先填一张选型前提表。输入长度、输出结构、可接受错误率、不适用场景这四项必须写出来，再去看 /models 里有哪些候选。不适用场景那一栏尤其重要，它决定了后面验证样本怎么挑，也决定了上线后出问题能不能解释清楚。

数据量与微调投入值不值

第二层是盘家底：你有多少标注样本。几百条标注通常只够做提示工程加 RAG，上千条且标注口径一致才值得走微调。这个门槛不是死的，不同任务的样本效率差别很大，具体到 /tools 里的训练与微调相关页面看当时的说明，别拿别人的经验数直接套。

• 先数有效标注：口径不一致、互相矛盾的样本要先清洗，否则微调只会学到噪声
• 把标注人力、训练算力、每次换版重跑三项加总，再和直接调接口的费用对比
• 领域知识更新频繁，优先 RAG，避免每次改知识都要重训
• 只有在术语、格式、口径必须严格锁死时，才考虑把知识训进权重
• 小模型微调便宜但天花板低，大模型微调贵且迭代慢，别只看单次训练成本

成本对比要算全周期，不是算一次训练。小模型路线后续每次换版都要重跑训练和评测，大模型路线则是调用费用随量增长。两条路的成本曲线形状不同：一条前期投入重、后期边际低，一条前期轻、随用量线性上升。量小的时候大模型路线更省心，量大的时候小模型路线才可能划算，分界点要按自己的调用量算。

显存、并发和延迟决定能不能上大模型

第三层才是很多人跳过的现实问题：大模型你的机器扛不扛得住。显存不是只看参数量，同一模型在不同量化档位、不同上下文长度下占用差别很大。具体数字用部署测算页按参数量、量化精度、上下文长度和并发数算一遍，到 /tools/speed-test 或同类测算页面核对当时的数值。

并发不是显存够就行，还要看吞吐和首 token 延迟。高并发场景把大模型全部塞进一张卡，往往延迟先崩，用户等到第一句话出来就流失了。判断顺序建议固定下来，每一步不达标就回到上一个方案，别硬扛。

1. 单请求先跑通能用最小配置回答一个真实问题，确认输入输出通路没问题
2. 算目标并发下的显存按实际并发数倒推，量化和上下文长度一起调，看哪组能同时塞下
3. 测延迟是否达标首 token 延迟和整体生成时间都要测，用真实输入而不是短样例
4. 决定单卡还是多卡单卡装不下再考虑多卡，注意多卡带来的通信开销
5. 核算多卡成本多卡能跑通不代表划算，把成本和收益放一起看再定

如果延迟或显存卡死，先别急着换更大机器。回到任务层，看能不能把宽任务拆成窄任务，或者用小模型做路由、大模型只处理疑难样本。这种混合方案在延迟和成本上往往比单一大模型更可控，代价是架构复杂度上升，需要额外的调度逻辑。

许可证、私有化和换代回退

技术可行之后还有一层容易忽略：许可证和私有化。开源权重不等于随便商用，先核对许可证对商用、再分发、调用量的限制。涉及数据不出内网的场景，还要确认权重能否离线部署、有没有额外的合规要求，拿不准就走官方托管通道并保留合规记录。

垂域小模型常被集成进产品里对外提供能力，要额外确认许可证对「模型即服务」和衍生模型的约束。有些许可证允许自用但不允许拿模型本身对外售卖，这类条款在选型阶段就要看清，否则上线后再改架构代价很大。具体条款到 /sites 里的模型与工具页面核对当时的说明。

上线前预留换代路径，比选哪个模型更重要。接口层做统一封装、提示词和评测样本独立存放，模型换代时先跑同一批样本对照，再决定是否切换，别直接全量替换。这样即使今天选的小模型明天不够用，换大模型或换供应商也只是配置改动。

两周小规模验证清单

判断到这一步，剩下的动作是用真实数据把两条路都跑一遍。选 30 到 50 条真实业务样本，覆盖典型输入和边界输入，两条路线用同一套提示词、同一批样本。别只用自己随手编的短句，那测不出真实分布下的差距。

• 样本要覆盖边界输入：空值、超长、口语化、带错别字
• 两条路线提示词尽量一致，否则比的不是模型而是提示词
• 可用率、修正耗时、成本三项一起看，别只看主观「感觉更聪明」
• 先设淘汰线再开跑，避免跑完再找理由说服自己
• 结论写成一页纸，明确适用场景和不适用场景

验证通过再扩到全量数据，并把评测样本沉淀成回归集。回归集的价值在换代时体现出来：模型更新、供应商切换、提示词改动，都拿同一批样本跑，看指标有没有退步。没有回归集的团队，每次换代都像重新选型，重复交学费。