模型选择最容易被榜单牵着走。榜单能说明基础能力，但业务系统还要面对成本、延迟、稳定性、上下文长度、工具调用、数据合规和供应商可用性。真正的选择标准应该来自场景，而不是来自模型名字。
先定义任务类型
知识问答、代码生成、长文总结、结构化抽取、客服回复、工具调用、多模态理解，对模型能力的要求不同。一个适合写作的模型未必适合稳定输出 JSON，一个擅长推理的模型也未必适合低延迟客服场景。
把评估样例做在前面
选择模型前，先准备 50 条真实业务样例。每条样例要包含输入、期望输出、评分规则和不能犯的错误。用同一套样例跑多个模型，比看通用榜单更接近真实决策。
不要忽略可替换性
生产系统不应该被某一个模型绑定。提示词、输出 schema、工具接口和评估流程都要尽量模型无关。这样当成本、质量或供应策略变化时，系统可以平滑切换。
常见取舍
- 高推理质量通常意味着更高成本和更长延迟。
- 长上下文方便但不等于高质量，噪声会稀释关键证据。
- 低成本模型适合批量分类、草稿生成和预处理。
- 高风险场景需要更严格的评估、审计和人工确认。
选择清单
- 是否用真实样例评估过。
- 是否记录成本、延迟、错误类型和拒答表现。
- 是否能稳定输出下游需要的格式。
- 是否满足数据合规和部署要求。
- 是否设计了模型切换和回滚方案。