选型时最容易卡在「同一个模型，三家网站给的结论不一样」：有人拿榜单分数说话，有人贴单价截图，还有人只凭手感。这篇不替你做决定，而是告诉你哪些站该看、每类站适合回答什么问题、看到数字后该去站内哪一页核对口径，最后产出一张能拿给团队看的对照表。
选型时最容易卡在「同一个模型，三家网站给的结论不一样」：有人拿榜单分数说话，有人贴单价截图，还有人只凭手感。问题不在谁撒谎，而在于每类站回答的根本不是同一个问题。这篇文章不替你做决定，只帮你把「该看哪些站、每类站适合回答什么、看到数字后去哪一页对齐口径」这条链路走通。
目标很具体：最后你手上要有一张能直接拿给团队看的对照表，每一行数据都能写清来源页码和观察时间，而不是几张来路不明的截图拼在一起。下面按四类站分工、核对顺序、表格怎么拼、什么时候不该信这四件事依次说。
先分清四类站，各自只擅长回答一种问题
把网站混着看，就会得到互相打架的结论。先给它们分个类，每一类只拿它最擅长的那部分信息，其余一律当线索不当证据。分类的依据不是站点大小，而是它的数据是怎么来的。
| 站点类型 | 擅长回答 | 看之前要确认什么 |
|---|---|---|
| 能力测评类 | 同一套题上谁更稳、谁更容易翻车 | 先读 /benchmarks 与 /benchmarks/registry 的题目口径说明 |
| 价格类 | 同样调用量下谁更便宜 | 输入输出是否分开计价、缓存命中怎么算，先到 /official-api 对齐 |
| 聚合类 | 快速试跑，哪个接口今天能通 | 限速和免费位随时会变，读完 /openrouter 与 /inference 自己再测一次 |
| 人气类 | 别人在怎么用、风向在哪 | 真实用量榜只反映别人的任务分布，不等于适配你的场景 |
能力类站点的坑在于题目饱和：一套题跑久了，头部模型的分数会挤在一起，分差很小的时候其实什么都说明不了。任务类型和你的实际场景不匹配时，结论失真更明显。所以看能力类数据之前，先花两分钟读口径说明，搞清楚这套题考的是什么、有没有区分度。
价格类站点的坑在口径。同样是调用一次，输入和输出往往分开计价，缓存命中与否差别也不小，图片输入经常会折算成 token。你不去 /official-api 把计费项对齐，比出来的便宜可能只是别人口径写得更宽松。聚合类的榜单和免费位适合快速试跑，但限速和可用性会变，看完要自己再测一遍才作数。
看到一个结论后的核对顺序
不管你从哪个站看到一个吸引人的结论，都按同一套顺序核对一遍。顺序的意义在于：先确认模型还在不在、再确认计费项、再代入自己的用量、最后量本地延迟。跳过任何一步，后面的数字都可能是错的。
- 确认模型条目与规格去 /models 找模型条目，确认它是不是已经下架的别名、上下文长度和模态支持写的是什么。拿一个已下架的名字做对比，后面全白做。
- 核对计费项与限制到对应厂商页核对当前计费项，比如 /official-api/providers/deepseek、/official-api/providers/openai。重点看输入输出是否分开、有没有缓存价、速率限制是多少。
- 代入自己的用量用 /tools/model-cost-calculator 和 /tools/token-price-calculator，把你真实业务的输入输出比例代进去。别人的截图只代表别人的调用结构。
- 量本地延迟基线用 /tools/speed-test 在你自己的网络下跑一次，速度类结论必须本地复现。机房里跑得快，不代表你办公室的网络里也快。
这四步做完，你手里至少有了四个可引用的来源页码。之后无论谁来质疑你的结论，你都能说清这个数字是哪一页、什么时间看的，而不是「我记得有人说过」。
别人的截图证明不了你的成本，只有你自己的调用结构能。
给自己拼一张能落地的对照表
拼表的关键不是列得多，而是维度固定、来源单一。维度今天定明天改，就没法横向比；同一行数据东拼西凑来自三个站，出问题时你都不知道该去找哪一页。
- 固定五个维度：任务类型、上下文长度需求、是否需要多模态、单次调用成本量级、可用性要求，中途不要加减
- 每一行只填一个来源，并在备注里写明来自哪一页，避免同一行混用多个口径
- 样本任务固定三条：一条日常任务、一条你的边界场景、一条故意刁难的，三条都过再进候选名单
- 标注价格与能力的观察时间，模型和报价变动频繁，过两周必须去 /price-watch 重看一次
- 候选数量控制在三到四个，太多会拖成无休止的对比，反而选不出来
成本量级这一列不要填具体数字，写清「按你当前调用结构大致处于什么档位」就够了，具体数字到 /tools/model-cost-calculator 现算。三条样本任务是最关键的一步：它把网站上的通用结论拉回你自己的场景，只有三条都过，才值得进候选。
什么情况下这些网站不该作为依据
有些场景下，公开站点的任何结论都不适用，硬套只会误导决策。遇到下面这些情况，直接转到部署侧或内部评估，别在公开榜单上浪费时间。
- 涉及私有数据、合规要求或必须内网访问时，公开站结论不适用，要转到部署侧评估，参考 /models/deploy 与 /compute/sizing
- 限时免费额度、活动价格不要写进长期选型，活动一结束口径就变了，你的成本模型也跟着失真
- 榜单分差很小的时候不要当决策依据，这时用你自己的三条样本任务做判定，哪个更顺就用哪个
- 只来自单一未署名来源的对比数字一律不采信，找不到口径说明就直接跳过，省下的时间比省下的钱值
还有一条容易被忽略：模型和报价都在变，你三个月前存的对照表很可能已经过期。表格里一定要留一列观察时间，超过你觉得合理的周期就整体重跑一遍核对顺序，而不是只改其中一格。
下一步先去 /sites 把上面四类站各挑一个存下来，再按 /rankings 和 /price-watch 核对当时的数字，最后用 /tools/speed-test 在你自己的网络下量一遍延迟。把这三件事做完，你的对照表才有资格进团队评审。→常见问题
有没有一个网站能把能力和价格一次比完？
没有哪一家能同时把两件事做准。能力看测评类站点，价格看官方价目和比价页，两边的口径本来就不一样。可行做法是各取一处数据，再到 /models 确认规格、到 /tools/model-cost-calculator 按自己的用量算一遍，把结果拼成一张自己的对照表。
聚合平台上的免费模型和官方口径的数字对不上，以哪个为准？
以官方厂商页为准。聚合平台会做限速、排队和额度调整，展示的数字和实际能拿到的能力经常有差距。要接生产就先按官方的计费与限制预估，再在聚合平台上小流量试，最后去 /price-watch 看有无调价记录。
网站上给的对比结论能直接拿去做技术评审材料吗？
不建议直接引用。评审看的不是谁排前面，而是你的场景下成本、延迟、可用性是否达标。带上三条自己的样本任务结果、价格观察时间和来源页面链接，比贴一张截图有说服力，也方便后续复核。如果涉及合规或私有数据，公开站结论基本用不上。
