我们测了 194 家站点：这份数据能回答什么、不能回答什么

先把「数据是什么」说清楚

本站的数据来源是三块，性质完全不同：

我们刻意把这两类分开呈现，原因在《为什么要把「宣传值」和「实测值」分开》那篇公告里写过 —— 但现在值得再强调一次：如果混在一起，你会误以为倍率也是测出来的。

能回答什么（四类问题）

一、横向比较：哪家整体更快、更稳

这是数据最擅长的用途。

因为 194 家是在同一套口径、同一个探测点、同一时间段下测的，横向比较是有效的 —— 相对关系比绝对值更可靠。

可以支持的判断：

• A 家的可用率明显高于 B 家；
• C 家的延迟长期低于同类的其它站；
• 某家站最近一个月的稳定性比上个月明显下降。

二、趋势：某家站在变好还是变差

可用率与连续可用天数是时间序列，所以趋势判断是有效的。

这一项的实际价值最大 —— 一家站的「跑路前兆」往往表现为可用率下滑（见《中转站「跑路」之前，通常会有这六个信号》）。本站的数据能提供一个客观的观察点。

三、覆盖面：模型供应的广度

「接口探测到的模型数」反映了各站的模型覆盖范围。

可以支持的判断：

• A 家的模型清单比 B 家丰富；
• 某个小众模型在哪些站有供应。

不能支持的判断：清单里有的模型是不是都能用、质量如何。

四、价格基准：判断倍率是否合理

本站的官方价目表（/model/lists）是独立于中转站的第三方基准。

可以支持的判断：

• 某站标称的 0.3 倍率对应实付多少钱；
• 这个价格相对官方价属于哪个区间（30%–70% 是官转的常见区间，低于 30% 需要警惕）。

不能回答什么（五类问题）

一、模型是真的还是假的

本站不做模型验真。 我们不跑模型指纹、不做参数边界测试。

「接口探测到 24 个模型」这句话的含义严格来说是：/v1/models 返回了 24 个条目。它不表示这 24 个都能用，更不表示它们真的对应标称的模型。

所以：验真必须你自己做，或者用专门做这件事的平台。

二、生成质量如何

本站不测输出质量。 没有质量评分，没有 benchmark。

原因很直接：质量强依赖你的具体任务。同一个模型在摘要任务上可能很好、在代码任务上可能不行。任何统一的质量评分都会误导。

三、首字延迟（TTFT）

本站测的是站点可达性与首页响应，不是模型生成的首字延迟。

这两者差异很大：一家站可能首页很快但生成很慢（排队严重），也可能首页慢但生成快。

所以本站的延迟数据不能直接用来判断「它用起来快不快」。 后者需要你自己测（见《自建探针》）。

四、能力支持情况

不测：流式实现质量、工具调用兼容性、结构化输出、多模态、缓存计费、语音、图片生成。

这些全部需要你自己验证。 本站的相关教程（流式六种异常、函数调用兼容性、JSON mode、缓存计费）就是为了让你能自己测。

五、「哪家最好」

本站不做综合排名推荐。

不做的原因有三：

1. 场景不同，最优解不同（见《选型决策树》）；
2. 排名会诱导「只看名次不看条件」的使用方式；
3. 我们有商业利益（收录与广告），做排名会构成利益冲突。

关于数据口径的三个提醒

1. 探测点单一

所有探测都从同一台服务器发出。这意味着：

• 与你从自己的网络访问的结果可能不同；
• 如果你的用户分布在不同地区，本站数据不能替代多节点监测。

2. 探测内容有限

探测的是可达性与响应时间，用的是一个最小请求。

它不能反映：高峰期排队、大请求的处理能力、不同模型的差异。

3. 可用率的统计口径

可用率是基于成功请求的比例，有最小样本数要求（样本不足时不参与排名，避免「1 次成功 = 100%」的失真）。

具体的阈值与窗口写在《可用率是怎么测出来的》一篇里。如果你要用这个数字做决策，建议先读那篇。

怎么用这份数据

一句话：当筛子用，不要当结论用。

正确的用法：

1. 用可用率 + 延迟做初筛，把 194 家缩到 10 家左右；
2. 用模型覆盖与倍率进一步缩小到 3–5 家；
3. 然后在候选里自己验证：能力测试、小额对账、并发梯度、观察一个业务周期。

错误的用法：

• 「可用率 100% 就一定好」—— 可能是样本少；
• 「排第一的就是最好的」—— 排序依据是单一维度；
• 「它标称 0.1 倍率所以很划算」—— 那是自宣值，且低价有其成本结构上的原因。

最后一句

我们提供数据的目的是降低你的筛选成本，不是替你决策。第三、四层（验证与策略）只能由你自己完成 —— 但那两层的成本并不高，本站的相关教程加起来大约两小时的阅读量，就能覆盖绝大部分要点。

真正省时间的做法是：用数据缩短候选名单，把省下来的时间用在验证上，而不是用在「再比一比价格」上。