*结论前置：评估一款大模型是否值得用，不能只看官方跑分和 API 单价。官方跑分无法交叉验证，单价相同不代表成本相同，而且模型能力普遍偏科。落地时最容易踩三个坑：拿官方跑分当唯一依据、只比对单价、把模型当整体评估。下面是完整记录。
背景
过去四十天，海外头部厂商密集发布了七款新模型。团队决定做一次选型评估，把「感觉这个模型不错」变成可复核的流程。
我最初用的方法很原始：看官方跑分、比 API 单价、听同行口碑。三轮下来，发现结论完全站不住。当时的工作流是：候选模型先跑一轮官方榜单，再拿两个真实业务场景做点测。流程看着挺完整，问题出在判断依据上。
改造前后对比
换成三维评估模型之后，对比大致是这样：
| 维度 | 改造前（凭直觉） | 改造后（三维评估） |
|---|---|---|
| 评估依据 | 官方跑分 | 第三方综合榜 + 专业能力榜 |
| 成本口径 | 只比对 API 单价 | 单价 + token 消耗 + 缓存 + 推理强度 |
| 评估粒度 | 整个模型 | 拆到具体高频任务类型 |
| 语言适配 | 看英文榜首 | 单独评估中文可用性 |
| 结论形式 | 「感觉还行」 | recommend / trial / skip 三档 |
踩坑一：把官方跑分当唯一依据
第一版我完全以官方跑分为准，结果选到的模型在专业能力榜上排名靠后。
原因很直接：官方跑分的测试集自选、指标自定、发布时间自控，本质是产品说明。
能交叉验证的数据只来自第三方评测，而且要区分综合榜与专业榜------两者结论经常不一致。
踩坑二：只比对 API 单价
这是最尴尬的一个。两款模型的输入输出单价完全相同，我据此认为成本相当。
上线后账单远超预算。回头看才发现两块被漏掉了：一是 token 消耗量，偏向长思考、长输出的模型单次调用吃掉更多；二是缓存价格。
公开数据里，有的模型缓存单价是每百万 token 一美元，有的只需零点一到零点二美元，差了五到十倍。对长链路 Agent 应用，缓存才是主要成本项。
单价相同不等于成本相同，这一条我花了两个月才真正接受。
踩坑三：把模型当整体评估
我一开始给「整个模型」打分，问题是无法定位短板。
换成按任务类型拆分之后，结论清晰了很多：以本次评估的新模型为例，强弱排序大致是知识工作、科研、写代码、Agent 操作。在「操作电脑」类目上，它在八个模型中排倒数第二。
这意味着：如果核心任务是知识问答，它可能很合适；如果核心任务是端到端自动执行，短板正好命中要害。
一个容易被忽略的维度：语言
这款模型在英文写作盲测中排名居首，但中文写作反馈是「味道重」。
对中文内容团队来说，英文榜首不能直接换算成可用性，必须单独测。我们后来加了一步：把同一份中文素材同时喂给三个候选模型，做人工盲评，结论比看榜单可靠得多。
写在最后
这轮评估做下来，最大的体会是：选型的方法论比选型的结果更重要。
三维模型本身不复杂，难的是承认它覆盖不到的地方------比如工程摩擦、团队习惯、以及某些只有长期使用才能暴露的问题。如果重来一次，我会把评估顺序倒过来：先拆任务，再选模型，最后才比价格。至少在下一次模型发布的时候，团队不用再从零吵一遍。
评估这件事，最怕的是凭感觉。有记录，才有复用。