AI架构09|选大模型,别只看排行榜

排行榜给了我们一个方便的起点，却很容易制造错觉：排名最高的模型，好像天然就是项目的最佳选择。可通用基准测的是平均能力，生产系统面对的是具体任务、真实流量和明确预算。两者之间还有一段很长的距离。

模型比较应从一组代表真实业务的样本开始。客服要覆盖常见问题、高风险问题和拒答场景；文档抽取要包含长表格、扫描件与异常格式；代码任务要用团队真实语言和仓库约束。只有同一评估集、同一评分规则，模型结果才可比较。

质量达到门槛后，再看延迟、吞吐和稳定性。一个复杂任务偶尔使用强模型没有问题，若每次输入都走最昂贵路径，费用与排队时间会迅速放大。实践中更合理的是模型路由：简单请求交给轻量模型，复杂请求再升级，关键任务保留人工确认。

Google Cloud 的生成式 AI 部署指南把模型质量、延迟、费用、许可、数据位置与运维能力都列为选择因素。托管模型省去基础设施维护，更新速度快；开放权重模型提供更多部署与定制控制，但团队要承担容量、补丁、伸缩和安全责任。

数据驻留和许可证也不是附注。受监管数据能否离开指定区域，模型输出能否用于商业产品，供应商是否保留输入，这些条件可能直接排除某条路线。所谓控制权，不是“自己部署”四个字，而是愿意长期承担由此带来的工程责任。

模型市场变化很快，把提示、参数和供应商 SDK 散落在业务代码里，后续替换会很痛苦。更稳妥的做法是建立统一调用接口，记录每次请求的模型版本、费用、延迟和评估结果。切换模型时先做影子测试，再逐步放量。

个人观点，最佳模型不是一张固定名单，而是一个持续评估结果。今天合适的选择，可能因为价格、版本或任务分布变化而失效。架构要允许替换，团队才不会被一次选型锁死。

选型结果最好分成“默认、升级和备用”三档。默认模型覆盖大多数请求，升级模型只处理复杂或高价值任务，备用模型用于主服务不可用时维持关键能力。每一档都用相同评估集验证，并明确切换条件。这样模型选择就从一次采购决定，变成可观察、可调整的运行策略，也能减少价格或服务变化带来的被动。