国产模型对比

很多人上手第一步就卡在选型：同一个活，同事说这家强，朋友说那家好，真正自己试又不知道该怎么比。国产模型这两年更新快、名字多、档位杂，光看宣传很难判断哪个适合自己。这篇不讲谁第一，只给一套可复用的对比框架：先按能力象限归类，再按任务卡需求，最后用站内资料和自测两步落地，顺带说清什么情况下这套框架不适用。

选型卡壳很常见：同一个活，同事说 A 家强，朋友说 B 家好，真轮到自己试又不知道从哪比。国产模型这两年更新快、名字多、档位杂，光看宣传页很难判断谁适合自己。这篇不讲谁第一，只给一套能反复用的对比框架：先按能力象限归类，再按任务卡硬需求，最后用站内资料加自测两步落地。

需要提前说清楚：框架是起点不是结论。模型迭代会改规格，今天的分档过几个月可能就变了；所以下面凡是涉及具体数字（价格、上下文长度、限速）的地方，都让你自己到站内页面核对当时的值，而不是替你记住一个会过期的答案。

别按名次比，先按能力象限归类

直接拿两家模型跑同一道题排序，是最容易踩坑的做法。同一个模型在不同任务象限里的表现能差很远：长文档摘要稳，不代表结构化输出也稳；代码补全顺手，不代表中文多轮对话就顺。先归类，再在同一象限内比较，结论才站得住。

• 分类依据看官方说明和站内模型库的规格描述，别只看厂商宣传口径
• 先确定你的任务落在哪个象限，再往下比，跨象限硬比容易得出错误结论
• 象限归属会随版本迭代变化，隔一段时间回站内模型库重看一遍

先问清楚：这活到底谁来干

选型最常见的失败，是需求没写清楚就开始比模型。建议先把需求落到三条硬指标上：能接受的最大等待时间、必须支持的能力、绝对不能出的错。拿这三条去对模型，比看任何评测榜单都直接。注意这条不适用于探索型场景——如果你还在试方向，硬指标会限制思路，这时候先广撒网再收口。

1. 写需求卡用三行写下：等多久算超时、必须支持哪项能力（长文/图片/结构化输出）、哪类错误不能容忍。写完先自己读一遍，看是否具体到能拿它拒绝一个模型。
2. 对官方规格到 /official-api 及其厂商页逐家核对上下文长度、输入输出格式、限速口径，比如 /official-api/providers/deepseek、/official-api/providers/zhipuai、/official-api/providers/alibaba、/official-api/providers/moonshotai。核对时记下当时的值，不要凭记忆。
3. 筛出两到三家不符合硬指标的直接淘汰，剩下的进自测环节。别一次铺开五六家，那样只会让对比成本失控。

用一套小样本自测，而不是看别人结论

别人的评测结论只能当线索，不能当依据——任务不同、提示词不同，跑出来的结果就没法平移。更靠谱的做法是自己搭一套小样本，跑完之后存下来，模型换代时重跑同一套，这样版本之间的对照才有意义。样本量太小或任务太单一时不适用，那种情况下自测噪音比信号大。

• 准备 10 到 20 条你自己的真实任务样本，覆盖正常、边界、容易出错三类情况
• 同一条提示词跑多家，记录输错、漏项、格式跑偏各出现几次，而不是只记「感觉好不好」
• 先量延迟基线：用 /tools/speed-test 测各家的响应时间，再决定要不要引入排队和重试机制
• 结果存档并标注测试条件，下次换代时重跑同一套样本

自测还有个附带好处：跑完你会知道哪家模型需要更啰嗦的提示词、哪家对格式指令更敏感。这些信息写进你的调用层，比换模型带来的收益往往更大。

容易被忽略的三件事：稳定性、限流与迁移成本

很多人比完单价就下单，上线后才发现高峰期限流、输出长度一超标成本就上去、想换一家又要重写业务逻辑。这三件事在选型阶段就得摊开算，具体数字到站内对应页面核对当时的实时值。

薄适配这件事要看团队规模：三五人小团队自用工具，写死一家反而省事；但只要产品面向外部用户，换模型是迟早的事，这层适配就越早留越好。

什么情况下这套对比方法不好使

框架不是万能的，有几种情况它帮不上忙，早点识别能省下不少时间。判断标准很简单：如果你的可选项本身就没几个，或者约束不在能力维度上，那横向对比的边际收益就很低。

• 合规和数据不出内网有硬要求时，先看私有化路径，能选的范围会大幅收窄，横向对比意义变小
• 垂类任务（法律、医疗、代码）通用能力对比参考价值有限，要看垂类目录里的实际适配情况
• 预算或资质决定只能用某一家时，直接把精力放在提示词和流程优化上，比继续比模型更划算
• 只是在做演示或原型验证时，选调用最顺的那家即可，不必走完整对比流程

选型的目标不是找到最强的模型，而是找到在你的约束条件下最不容易出错的那一个。