一、选型不是选最强
每天都有"最强模型"的说法，但真正做过项目的人都知道，最强不等于最合适。
我用六个维度做对比表，每次选型都过一遍。
二、六个维度
一、能力边界。
不是平均分，是看在你关心的那类任务上稳不稳。翻译、摘要、代码、结构化抽取、长文理解，得分能差很远。
二、成本。
要算单次任务的全部开销：输入、输出、重试、检索。很多人只算输出费用，漏了重试。
三、延迟。
首字延迟比总时长重要。用户愿意等一分钟的出图，不愿意等十秒的空屏。
四、上下文长度。
不要太迷信标称值。长上下文里的中间信息容易被忽略，这个现象很普遍。
五、可控性。
能不能稳定输出格式、能不能拒答、能不能限长度。做不到这几点，上不了生产。
六、部署方式。
云 API、私有部署、端侧。三者的成本结构和合规要求完全不同。
三、怎么做对比才有效
不要拿公开榜单当依据。自己掉二十条真实任务当测试集。
每条任务要有标准答案，而且答案要能自动校验。格式类任务（JSON、表格）最适合这么测。
然后算三个数：通过率、平均耗时、平均成本。
三个数一起看，选型就清楚了。
四、一个常见误区
"先用最强的，后面再降配"——这句话在实际项目里很少成立。
因为提示词、格式约束、重试策略都是围绕某个模型调优的。换模型等于重新调一轮。
更好的做法是先拿中档模型跑通全链路，确认业务逻辑没问题，再考虑升级。
五、文档比参数重要
模型文档里的限制条款往往决定了它能不能用。
比如速率限制、最大输出、支持的文件类型、是否允许商用。这些细节在宣传页里都找不到，但都会卡你。
万象云档 的"人工智能&大模型"分类里有不少模型手册与接入文档，220 篇的体量不算多，反而好挑。我一般先看限制条款那一章，再决定要不要读下去。
六、一句总结
选型的本质是取舍，不是评选。
知道自己最不能放弃哪个维度，选择就简单了。