做选型时最常见的卡点：手头有个具体业务，一边是参数不大、能本地跑的通用小模型，一边是号称精通某行业的大模型，两边都有人推荐，却没人告诉你什么任务该归哪边。这篇不评谁强，只给一条从任务性质出发的划分路径，以及分不清时先做哪个小验证。
选型会上最常出现的僵局：手头有个很具体的业务，一边是参数不大、能塞进自己机器里跑的通用小模型，一边是号称精通某个行业的大模型，两边都有人推荐，可没人告诉你这个任务到底该归哪边。问题往往不在于谁更强，而在于这两个词根本不在同一个评价体系里。
这篇不评高低，只给一条从任务性质出发的划分路径，以及两边都拿不准时先做哪个小验证。适用于你已经有明确业务场景、正在纠结技术路线的阶段；如果你连任务边界都还没定，那要先回去把需求写清楚，下面的方法用不上。
先把两条坐标轴分开：参数量是「大小」，训练目标是「通用还是垂域」
「小模型」描述的是参数规模，「垂域大模型」描述的是训练数据与任务覆盖范围，两者不在同一维度。所以「小模型 vs 垂域大模型」这个问法本身就带偏，你以为在比两个同类东西，其实一个在说个头，一个在说专业方向。
- 通用小模型
- 参数规模小、走通用语料路线，能力上限有限但部署轻
- 通用大模型
- 参数规模大、覆盖面广，什么都能聊但行业细节容易泛泛
- 垂域小模型
- 规模不大、专攻某一类任务，常见做法是在通用小模型上做微调
- 垂域大模型
- 规模大且训练语料偏向某个行业，擅长该行业的术语与默认前提
四种组合都真实存在，选型必须落到某个组合上，而不是停在「小」和「垂域」这两个标签里互相比。建议的顺序是：先定任务范围，再定规模。反过来先盯着参数数字挑，很容易选到一个能力过剩或者能力错位的方案。
通用小模型的实际定位：处理的是「格式清晰、答案收敛」的活
通用小模型最适合的场景，有一个共同特征：正确答案基本唯一，人看一眼就能判对错。它不需要理解你为什么这么问，只要把输入按规则映射成输出，稳定性往往比大模型还好，因为它本来就没什么可发挥的空间。
- 意图分类：把一句话分到几个预设类别里
- 字段抽取：从文本里抠出固定几个槽位并归一化格式
- 短文本改写：把口语改成书面、把长句压成一句
- 固定格式转换：结构化数据之间来回倒
- 简单问答路由：判断该走哪个下游流程或知识库
不适用的情况也要说清楚：需要跨文档推理、需要行业默认前提、输出对措辞精度敏感的任务，通用小模型通常会露怯，表现为反复要你补背景、或者回答看着对但细节不对。它的真正优势不在能力上限，而在于能放进你自己的机器、延迟可控、数据不出内网。
垂域大模型的定位：吃的是行业语料和行业默认前提
垂域大模型解决的是一类很具体的问题：通用模型不懂这行的说法。术语、口径、判例、规范、内部约定俗成的表达方式，这些东西通用模型不是不会，而是它得靠你每次补一遍背景才答得对，而垂域模型可能默认就知道。
代价是覆盖面窄。换到相邻领域，它可能退化得比通用模型还明显，别默认它样样更强。所以看一个垂域模型，不要只看它在主场表现多好，要问三个问题：语料来自哪、覆盖哪些子任务、超出范围时的退化表现是什么样。
| 观察维度 | 通用小模型 | 垂域大模型 |
|---|---|---|
| 术语理解 | 需要你补背景 | 多数情况默认懂 |
| 跨领域迁移 | 本来就通用，谈不上迁移 | 换领域可能明显退化 |
| 输出稳定性 | 格式任务很稳 | 自由问答波动更大 |
| 部署位置 | 通常可本地 | 多为远端调用 |
| 主要短板 | 能力上限低 | 场景覆盖窄 |
判断方法给一个：把同一段业务文本，交给通用模型和垂域模型各答一次，看谁需要你额外补充背景信息更少。补得少的那个，在这个任务上大概率更合适。
按任务性质分流：一张对照表帮你先归位
判断顺序建议从任务性质开始，而不是从模型名字开始。先问这个任务要的是什么：是把已知规则套到新数据上，还是要理解一段没见过的业务语境。前者偏工程，后者偏理解，两条路对应的选型完全不同。
| 任务特征 | 优先方向 | 理由 |
|---|---|---|
| 答案唯一、格式固定、量大 | 通用小模型或轻量微调 | 成本与延迟占优，稳定性够 |
| 术语密集、依赖行业规范 | 垂域模型或通用大模型加知识 | 知识缺口靠规模补不动 |
| 需要解释判断理由 | 通用大模型为主力 | 推理与表达更可控 |
| 两类都沾的混合流程 | 拆成两段分别处理 | 比换模型更省钱也更好排查 |
最后一行值得展开：很多团队卡住，是因为想让一个模型包办全流程。更务实的做法是前段用小模型把输入抽取归一化，后段交给理解力更强的一边。分段之后，出问题时你能快速定位是抽取错了还是理解错了。
分不清时的四步验证：先花半天做小样本对照，别直接立项
- 第一步：挑样本从真实业务里选几十条有代表性的输入，必须包含边界情况和反例，不能只用顺手的那几条。样本来源要能追溯到实际日志，不要自己编。
- 第二步：同条件跑对照同一提示词、同一批输入，两边各跑一遍，记录需要人工修正的地方。修正次数本身不重要，修正的类型才重要。
- 第三步：给修正分类把修正动作分成两类：补背景信息算知识缺口，改措辞算表达能力缺口。知识缺口靠垂域模型或知识库解，表达缺口靠更大的通用模型或调整提示解，方向别搞反。
- 第四步：算单位成本与延迟估算上线后单位请求的花费与响应时间，到 模型成本计算器（/tools/model-cost-calculator） 和 接口测速（/tools/speed-test） 拿当时的数字核对，不要凭印象拍。
什么情况下这套验证不适用：你的业务量极小、或者任务频率低到一年跑几次，那就不值得花时间做对照，直接用能力上限更高的一边把事做完更划算。验证的成本要和业务价值对上。
成本与运维口径：不只看单价，看单位可用结果的花费
算账时最容易漏掉人工复核这一步。垂域模型往往单价更高但人工返工更少，通用小模型单价低但可能需要配一层规则或校验兜底，兜底逻辑本身也要人维护。把这两块算进去，很多场景的胜负会在这一步翻盘。
- 单位可用结果花费 = 调用成本 + 人工复核成本 + 兜底规则维护成本
- 数据合规要一起看：涉及内部资料的场景，能不能本地跑往往比能力高低更先决
- 延迟也是成本：需要人等着看的流程，响应慢会直接拖低使用意愿
- 配额与限速会影响峰值表现，别只测平均情况
具体价格与配额随时间变化很快，别记住任何数字，需要时到 官方 API 价格（/official-api） 和 价格变动追踪（/price-watch） 看当时的数字。如果你打算走中转服务，那还要额外确认渠道的稳定性，这部分可以到 中转站目录（/sites） 里对比。
许可证与迁移：选之前先问能不能换、换了要动多少
有两个问题最好在动手前就问清楚，而不是上线之后才补：这个权重能不能商用、边界在哪；以及如果哪天要换模型，我需要改多少东西。前者是合规风险，后者是沉没成本，两者都比一时的效果差异更影响长期决策。
授权范围到 AI 模型库（/models） 和 安全与合规（/safety） 核对，别只看宣传页的说法。迁移能力则靠自己设计：把提示词、输出解析、校验规则和模型本身解耦，换模型时只替换调用层，上层业务逻辑不动。
| 迁移检查项 | 怎么确认 |
|---|---|
| 回归输入跑一遍 | 同一批样本，换模型前后各跑一次 |
| 输出差异比对 | 哪些修正变多、哪些变少 |
| 格式解析没坏 | 结构化输出的字段仍然能解析 |
| 延迟可接受 | 端到端时间仍在业务容忍区间 |
| 回退路径可用 | 旧方案能一键切回去 |
规模或业务范围发生明显变化时，优先重新做一次小样本验证，而不是直接沿用旧结论。模型的适用边界会随任务漂移，去年跑得通的方案今年不一定还成立。
下一步先按任务性质把候选归位，再去核对当时的成本与合规口径，两份信息凑齐再立项，比先选模型后补论证省事得多。→常见问题
小模型是不是就是能力弱的模型？
不完全是。小模型的上限确实低，但它的价值在于能放进自己的环境、延迟低、数据不出门。判断标准不是强弱，而是你的任务答案是否收敛、格式是否清晰。答案唯一且量大的活，小模型往往比大模型更合适。
垂域大模型一定比通用大模型好吗？
只在它覆盖的那一小块领域里可能更好，换到相邻领域很可能退化得比通用模型明显。选之前要问清语料来源、覆盖的子任务范围，以及超出范围时的表现，别默认它样样更强。
不做微调，用提示词加行业资料能不能替代垂域模型？
很多场景可以，尤其是知识类问答。区别在于：垂域模型把行业前提学进了权重，提示词方案要靠你每次补齐。如果补齐成本可控、答案可校验，先用提示词验证更划算；如果每次都要补一大堆背景且容易漏，才考虑更重的方案。
怎么判断我的任务该归哪一类？
拿几十条真实输入两边各跑一遍，把问题分成两类：需要补背景信息才算知识缺口，需要改措辞算表达能力缺口。前者偏知识问题，后者偏模型能力问题，两类对应的解法不一样，别混着一起判断。
两个都上，怎么分流量？
常见做法是前段用小模型做归一化和路由，判断这单该走哪条路，复杂的再交给另一边。前提是路由判断本身要可靠，建议先用离线样本验证路由准确率，再决定要不要接入线上。
