打算用开源模型做产品，翻了一圈排行榜反而更犹豫：同一家模型在 A 榜排前面、B 榜掉到中游，参数规模又对不上自己的活。这篇不替你选模型，而是给你一套读榜和对照的方法：先分清榜单测的是什么，再按你的任务类型去站内页面核当时的数字，最后落到可验证的小规模试跑。
打算用开源模型做产品，翻了一圈排行榜反而更犹豫：同一家模型在 A 榜排前面、B 榜掉到中游，参数规模又跟自己的活对不上。这不是你看不懂榜，而是榜单本来测的就是不同东西。这篇不替你选模型，只给一套读榜和对照的方法：先分清榜单在测什么，再按任务类型去站内页面核当时的数字，最后落到可验证的小规模试跑。
有个前提得先说清楚：排行榜是筛掉明显不合适的候选，不是替你下决定。它能告诉你的，是某个模型在一批公开题目上的相对表现；它不能告诉你的，是你的私有数据、延迟要求、部署预算下它到底能不能用。所以下面每一节都配了可执行动作，看完能直接上手。
先搞清榜单到底在测什么
排名对不上，多半是因为榜单测的维度不同。综合能力榜考的是多学科题目，代码榜考的是补全和算法题，中文与长文本榜考的是阅读理解和长上下文召回，众测盲测榜靠人投票。同一模型在这几类榜上的位置差异很大，拿一个榜的结论去推另一个榜，基本会错。
| 榜单类型 | 主要测什么 | 适合拿来判断 |
|---|---|---|
| 综合能力榜 | 多学科客观题 | 通用问答、常识推理的粗筛 |
| 代码榜 | 补全、算法、仓库级任务 | 写代码、改代码类场景 |
| 中文与长文本榜 | 阅读理解、长文档召回 | 中文问答、合同与报告处理 |
| 众测盲测榜 | 真人或模型对评的偏好 | 开放式生成、聊天体验 |
还有两个细节值得看：题目是不是选择题型，选择题型容易被训练数据覆盖，开放式生成更接近真实使用；榜单有没有多时段或众测交叉验证的成分，单次自评分数参考价值有限。具体口径到 /benchmarks 和 /benchmarks/registry 看条目说明，那里写了每张榜的题目构成和更新方式。
按你的任务类型挑对应的榜
选型的第一步不是看谁第一，而是先确认你的任务属于哪一类。写代码就去看代码类榜，中文问答和长文档处理看中文与长上下文类榜，图像音视频看多模态类榜。拿综合榜当唯一依据，很容易选出一个哪项都不突出、又贵又慢的模型。
- 任务对照：写代码看代码类榜，中文与长文档看中文与长上下文类榜，图音视频看多模态类榜，别拿综合榜做唯一依据
- 垂类场景（法律、医疗、金融）通用榜参考价值低，优先看垂类模型目录并用实际样本试跑
- 把参数量、上下文长度、是否支持函数调用、许可证这几项硬指标单独列一栏，它们比排名更能决定能不能用
- 候选控制在三到五家，取太多会拖慢试跑和对比的节奏
这里有个容易踩的坑：同一个模型不同尺寸版本会分别上榜，排名可能差得很远。挑候选时要连尺寸和量化方式一起记下来，否则试跑阶段会发现跑的是另一个东西。硬指标和许可证先去 /models 核对，商用限制看 /open-weight-license-basics。
从榜单到候选短名单的操作步骤
榜单看完，接下来是从一堆名字里筛出能试的短名单。顺序别反：先卡硬条件，再比能力，最后算成本。反过来做，你会把时间花在一批根本部署不了的模型上。
- 第一步 筛硬条件许可证能否商用、上下文长度够不够、多语言是否覆盖、部署形态是本地还是托管。不满足的直接划掉，规格到 /models 核对，许可证细节看 /open-weight-license-basics。
- 第二步 按任务取候选按你任务对应的榜单，取靠前的三到五家作为候选，不要十家。同时把每家的尺寸、量化方式和推理框架记在表格里。
- 第三步 用自己的样本试跑整理一批真实业务样本，同一提示词、同一评测方式跑一遍，记录可用率、需要返工的比例、明显跑偏的情况。样本量不用大，覆盖你的典型场景即可。
- 第四步 单独算成本把候选的调用或部署成本各算一遍，换算成单位任务成本。排名靠前和单位成本低经常不同向，这一步会改变你的排序。
数字要去哪查、什么时候会变
榜单排名、分数区间、各模型规格都在变，正文里写死某个数字，过不了几天就过期。所以这篇只给路径：需要具体数字时，一律到站内对应页面看当时的数据，自己记下来的基线比转发来的截图可靠。
- 榜单条目与口径
- 到 /benchmarks 和 /benchmarks/registry 看每张榜测什么、怎么更新
- 模型规格与许可证
- 到 /models 看尺寸、上下文、部署形态，许可证到 /open-weight-license-basics
- 推理与托管开销
- 到 /inference 看当时的服务与开销情况，用于单位任务成本估算
- 真实调用热度
- 到 /usage 看实际被用得多不多，热度高一般意味着踩坑的人多、资料也多
- 价格波动
- 到 /price-watch 看当时的变动记录
- 部署与算力测算
- 到 /models/deploy 和 /compute/sizing 做显存与并发估算
还有一个习惯值得养：给自己建一份基线记录，把同一批样本在候选模型上的表现、跑的时间、用的参数写下来，隔一段时间复测一次。榜单更新很快，你自己的基线才是判断“换了模型有没有变好”的依据。
这些情况下排行榜参考价值有限
排行榜不是万能的，下面几种情况下它的解释力会明显下降。遇到这些情况，别硬从榜里找答案，先回到自己的场景做验证。
- 任务高度定制、依赖私有知识和内网数据时，通用榜几乎说明不了问题，得靠微调或检索增强，参见 /fine-tune-prompt-rag
- 对延迟、并发、显存有硬约束时，先做部署测算（/models/deploy、/compute/sizing），榜单靠前的模型可能根本跑不动
- 榜单题目饱和后头部分数挤在一起，排序噪声大于真实差距，这时按成本和可维护性选更实际
- 模型更新频率高、你只需要短期验证时，追最新的榜不如锁定一个版本先跑通流程
判断标准可以简化成一句话：如果你的任务能在公开题目上复现，榜单参考价值高；如果任务靠私有数据或特殊流程，榜单只能当排除法用，先划掉明显不行的，剩下的靠试跑定。
下一步打开榜单页面对照你的任务类型筛一遍候选，再去模型库核对规格和许可证，最后用自己的样本跑一轮小规模对比，边跑边记录基线。→常见问题
开源模型排行榜上的第一名，是不是直接拿来用就行？
不一定。榜单衡量的是它在统一题目下的表现，你的任务分布、语言、上下文长度、部署环境都可能不一样。建议把榜首当候选之一，用你自己的真实样本跑一轮对比，同时确认许可证、上下文和硬件能撑住，再决定。
同一个模型在不同榜单名次差很多，该信哪个？
先看两个榜单测的题型和评测方式是否相同。综合题、代码题、中文长文本、众测盲测测的不是一回事。选和你任务最接近的那类榜，其余当旁证；分数挤在一起时不要纠结名次。
只看榜单不看别的，最容易踩什么坑？
两个坑：一是拿综合榜第一去干垂类活，效果落差大；二是忽略部署成本，榜单靠前的模型可能显存不够或吞吐太低。查榜后请补一步：算一遍自己场景的显存、并发和单位任务成本。
