团队要接一个大模型，会议室里通常先吵参数和榜单，最后谁也没说清为什么选它。这篇不评哪个模型强，而是把「为什么选这个」拆成几个可验证的维度：任务类型、能力边界、成本口径、可控性与退出成本。按这个顺序走一遍，你能给出一个有理由、能复盘、出了事也知道往哪退的选型结论。
团队要接一个大模型，会议室里通常先吵参数和榜单，最后谁也没说清为什么选它。这篇不评哪个模型强，而是把「为什么选这个」拆成几个可验证的维度：任务类型、能力边界、成本口径、可控性与退出成本。
按这个顺序走一遍，你能给出一个有理由、能复盘、出了事也知道往哪退的选型结论。核心不是找「最强」的那个，而是找到「在你的约束下最合适」的那个，并且能把这个理由写进决策文档里。
先定任务类型，再谈模型特点
很多人一上来就问「哪个模型最好」，但这个问题没有答案，因为不同任务对模型的要求完全不一样。正确顺序是先把自己的任务归类，再拿类别的硬要求去筛模型。归类之后你会发现，候选池从十几个直接缩到三五个。
- 短问答与分类：要求稳定、便宜、响应快，对长文本能力没要求
- 长文生成与改写：吃上下文，看超长输入后质量是否掉
- 代码与结构化输出：要稳 JSON、稳函数调用，对话好看不算数
- 多模态解析：图片、表格、扫描件，测的是解析准确率不是聊天
归类完再列硬约束：输出要多长、是否必须返回稳定 JSON、是否要联网或读文件、延迟能不能忍。这几条比任何榜单都更能筛掉候选。同一任务写 3-5 条真实输入做小样测试，比看榜单直接得多；榜单只用于初筛。
| 约束类型 | 要问的问题 | 不满足的后果 |
|---|---|---|
| 输出长度 | 单次输出能否覆盖最长用例 | 截断、需要二次拼接 |
| 格式稳定 | JSON 解析失败率是否可接受 | 下游流程频繁报错 |
| 时效知识 | 要不要外挂检索 | 答非所问、编造事实 |
| 延迟 | 用户能忍几秒 | 体验崩、被迫换模型 |
什么情况下不适用：任务本身还没定义清楚时，选型结论只能算暂定。先把验收标准写出来，再回来选，不然选完还要推翻。
能力边界的三个易被忽略点
能力边界不是「这个模型会不会做」，而是「在什么条件下它还做得动」。下面三个点是最常在选型后翻车的地方，建议逐条拿自己的数据测一遍，而不是靠感觉。
- 测上下文与长文喂进你真实文档的最长版本，看超长之后质量是否掉。规格字段去 /models 看，实际表现去 /models/deploy 做测算。
- 测结构化输出与工具调用要接 Agent 或函数调用时，先单独测 JSON 稳定性和工具调用成功率，别用对话表现替代。
- 测知识新鲜度与幻觉倾向涉及时效信息必须配检索，参考 /stacks/vector-dbs 与 /embeddings 选型，别指望模型自己知道。
这三个点是相互独立的：一个模型长文很强，不代表它 JSON 稳；JSON 稳，也不代表它知道新东西。所以别用「综合感受」下结论，得分项测、分项记。
什么情况下不适用：垂类场景比如法律、医疗、金融，建议先看 /stacks/specialized-models 再决定是否用通用模型硬撑，硬撑的代价往往在后期才暴露。
成本口径要统一了再比
成本比较最常见的错误，是拿 A 家的输入价去对 B 家的输出价，或者只看单价不看用量结构。正确做法是先把三家候选换算到同一单位，再比总账。
- 统一口径：换算成每千次任务成本、每万字成本或每张图成本，用 /tools/model-cost-calculator 和 /tools/token-price-calculator 对齐
- 算隐性成本：重试、失败重跑、上下文冗长带来的额外 token、限流排队，都是真实支出
- 量延迟基线：用 /tools/speed-test 先量出你的网络基线，再看模型本身响应，两者混在一起容易误判「模型慢」
- 查官方价目：到 /official-api 核对当时的数字，租卡与按量 API 的取舍参考 /compute/tco
| 成本项 | 怎么量化 | 容易被漏掉的原因 |
|---|---|---|
| 显性单价 | 统一到每千次任务 | 各家计价维度不同 |
| 重试成本 | 失败率 × 单次成本 | 失败率没单独统计 |
| 上下文冗余 | 实际输入 token 均值 | 按理论值估算 |
| 排队时间 | 高峰期排队占比 | 只测了低谷 |
什么情况下不适用：流量极小或波动极大时，固定订阅和按量计费的结论会反过来。小流量下固定成本更划算，波动大时按量更安全，按你的实际曲线判断。
可控性与退出成本：决定长期用不用
前面三步是「现在能不能用」，这一步是「以后还愿不愿意用」。很多团队选型时不算退出成本，结果用了半年发现换不动，只能继续加钱。
- 数据合规
- 能不能走私有化、要不要过内网，参考 /safety 与 /compute/domestic 判断可行路径
- 供应商稳定性
- 看服务历史与限流记录，/ai-status 和 /resets 反映一部分，第三方渠道另按 /tools/verify 的检测口径核实
- 退出成本
- 换模型要重写多少提示词、重跑多少评测、下游依赖多少，列一张迁移清单，参考 /ai-nav/category/ai-api 里同类接口的兼容情况
把退出成本写成清单之后，你会发现有些模型「现在便宜但换不起」，有些「单价高但接口通用、切走容易」。这两种在长期账上是反过来的，选型时要把这张清单一起交给决策人。
什么情况下不适用：一次性的临时项目不值得为可控性多付成本，直接选最省事的那条路。可控性是给要长期跑的业务的，不是给两周就下线的实验的。
下一步把候选模型按任务类型、能力边界、成本口径、退出成本四个维度填一张对照表，数据到站内相关页面核对当时的数字，别凭印象拍板。→常见问题
模型选型到底该先看榜单还是先看自己的任务？
先看自己的任务。榜单适合把候选从几十个缩到三五个，榜单的题目和你手头的活往往不是一回事，题饱和和任务不匹配的问题在 /benchmarks/registry 里有说明。缩小范围后必须用自己的数据跑一遍小样测试，再定结论。
同一个任务，选官方 API 还是走中转、租卡自建？
看三点：数据能不能出内网、流量是否稳定到值得固定成本、以及你对延迟和可用性的容忍度。流量小且波动大走按量最省心；有合规硬要求或长期高负载，再看租卡和私有化。算总账可参考 /compute/tco。
选型结论多久要复检一次？
不用定期复检，而是按触发条件复检：主力模型有明显更新、价格或限流政策调整、任务类型变化、出现一次影响业务的故障。价格和版本变动可在 /price-watch 与 /models 追踪，避免凭印象判断。
