选型的判断顺序

参数表能回答的问题其实很有限，但它能帮你快速排除掉大半候选。建议按这个顺序过一遍。

第一步：硬约束。要不要读图、读音频？上下文得多长？ 有没有数据出境或合规要求？这些是「不满足就直接出局」的条件，先筛掉最省事。

第二步：成本结构而不是单价。把你的真实输入输出比代进去算月成本， 再排序。做摘要（长输入短输出）看重输入价，做生成（短输入长输出）看重输出价， 结论经常和「谁单价低」相反。这一步直接用月成本估算器。

第三步：效果自测。剩下两三个候选，拿你自己的二三十条真实输入盲评一遍。 这一步没有捷径，公开榜单和你的场景往往对不上——尤其是中文长文、垂直领域术语、 需要严格遵守输出格式的任务，差异常常比榜单分数大得多。

第四步：工程属性。限流额度够不够、是否支持流式与工具调用、 SDK 与 OpenAI 兼容端点是否顺手、报错信息是否可读。这些不影响「能不能用」， 但决定上线后你要不要天天救火。

不要只锁死一家

实践中越来越常见的做法是多家并用：把简单任务分流给便宜的轻量档， 难任务走旗舰，再留一家做故障切换。代价是要在代码里做一层统一封装， 但收益很实在——某家涨价、限流、出故障时，你不至于整条业务线停摆。

做这层封装时，优先挑支持 OpenAI 兼容端点的厂商，切换成本基本就是改个 base_url 和模型名。 具体做法可以看多家 API 统一封装那篇。