接入大模型前如何筛掉不合适的候选
大模型选型指南配置的核心不是先看排行榜，而是先把业务任务、调用量、上下文长度和预算写成一张筛选表，再用同一批真实样例验证。
参数规模只能说明大概能力，决定能不能长期用的是计费方式、限速规则、上下文上限和部署条件。
先把需求写成可比较的条件
选型前要回答四个问题，否则对比会变成凭感觉：
- 任务类型：是问答、摘要、代码生成、结构化抽取还是多轮对话，不同类型对模型的要求差别很大。
- 输入输出规模：单次请求大概多少字，是否需要长文档或多轮上下文，这直接决定上下文窗口是否够用。
- 调用方式：只能走 API，还是允许私有化部署，这会影响数据出不出内网。
- 预算与并发：每天大概多少次调用，能接受多少延迟，是否有峰值并发。
把这些写成一张表，每个候选模型占一行，填不出来的项就是后续要验证的点。
用硬条件先做一轮排除
先筛掉明显不满足的候选，避免在细节上浪费时间：
- 上下文长度不够处理最长输入的直接排除，不要指望靠截断解决。
- 数据不能出内网的，排除纯 API 方案，只看支持私有化部署的模型。
- 调用量大的场景，先看计费单位和限速规则，单价低但限速严格的方案可能跑不动。
- 需要稳定输出的抽取类任务，优先看是否支持结构化输出或函数调用。
这一步不需要跑测试，靠公开文档就能完成。
文档里查不到的项，标记为待验证，不要默认它支持。
用统一样例做小规模验证
筛到两三个候选后，准备二十到五十条真实业务样例，同一批输入分别跑各个模型，记录四项结果：回答是否可用、平均响应时间、单次调用成本和失败率。
验证时注意保持条件一致：相同的提示词、相同的温度参数、相同的输入长度。
否则对比结果没有意义。
对于抽取类任务，可以直接统计字段准确率；
对于问答类任务，建议人工标注可用与不可用两档，不必追求精细打分。
如果候选里既有 API 也有私有化部署，成本口径要分开算：API 按调用量和单价估算，私有化要加上硬件折旧和运维人力，两者不能直接比单价。
容易踩的几个坑
- 只看参数规模：同规模模型在不同任务上的表现可能差很多，必须用自己任务的样例验证。
- 忽略上下文计费：长文档场景下输入 token 往往占大头，只比较输出单价会低估成本。
- 忽视限速：免费额度或低价档位常有限速，峰值时可能出现排队或报错。
- 用公开跑分代替实测：跑分适合初筛，最终决定仍要看业务样例的通过率。
怎么确认选型结果可用
选定模型后，用一周左右的实际流量做灰度验证，重点看三项指标：调用成功率、平均延迟和单次任务成本。
如果失败率偏高，先排查是提示词问题、输入超长还是限速触发，再决定是否换模型。
确认稳定后，把筛选表、验证样例和结论一起存档，后续模型更新时可以按同样流程复测，而不是重新凭感觉选一遍。
