我们的探针架构：本机探测、抽样验真与数据留存
更新时间
RelayPick 的探针为单点部署，每 10 分钟探测一次全部在榜站点，5xx 响应与超时均计入失败，原始响应留存 90 天供复核。
单点部署，不是分布式拨测
RelayPick 的可用性探针是单点部署。文中所说的在线率、掉线时长，都来自这一条探测路径，而不是把若干探测路径的结果做交叉投票。
单点的含义是：同一时刻、同一网络出口，对全部在榜站点发出探测。它能稳定地比较站点之间的相对可用性，但不能代表用户在其他网络环境下的访问结果。截至 2026-08-13，公开口径与本文一致。这些数据会汇总进 排行榜 的稳定性维度。
每 10 分钟一次的可用性探测
探针每 10 分钟对全部在榜站点探测一次。5xx 响应与请求超时都计入失败，不区分“服务器错误”与“网络不通”。
这个口径会让一部分因本机出口抖动造成的失败也被算进去。代价是可能把探测点自身的网络问题记到站点头上；好处是规则简单、可复现，不在事后用主观判断把失败改写成“那次不算”。
连续掉线是否超过 24 小时，也按同一口径累计。站点页上的稳定性数字，应读成该探测点看到的失败比例，而不是全球用户的平均体验。对照某一站时，可从例如 云梯 Relay 的公开指标看窗口内的结果。
验真抽样是另一套机制
可用性探针回答的是“现在能不能连上”。验真回答的是“连上之后，是不是宣称的那个模型”。
验真走独立的每日分散抽样，频率低于每 10 分钟一次的探针，检测项与 /check 工具相同：响应指纹、Tokenizer 边界、上下文长度、限速自述、流式超时。不想等下一次抽样，可以自己在浏览器里对目标站点跑一遍 /check。
两套机制分开，是为了避免用高频可用性探测去打真实模型接口。探针失败只影响稳定性统计；验真失败影响真实性维度，并通过率掉到 0.6 以下时触发判定未通过。
90 天原始留存意味着什么
原始响应当场不会写成结论。探测与抓取的原始响应留存 90 天，供复核当时到底返回了什么，而不是只留下一个聚合后的成功率。
90 天之后按清理策略删除。对更早窗口的争议，只能依据已经滚动聚合过的统计，而不能再打开当时的原始包。90 天是留存上限，不是“90 天内每一条都会展示在前台”。
RelayPick 不销售 API 额度，不接受排名付费。探针与验真都按同一套公开口径执行。
常见问题
- 单点探测会不会因为网络问题误判站点故障？
- 会。RelayPick 的可用性探针是单点部署，5xx 响应与请求超时统一计失败，不区分站点故障和探测点到站点之间的网络不通。因此单次失败不足以说明站点不可用；连续掉线超过 24 小时才会按规则扣 15 分并预警。读稳定性数字时，应把它理解为该探测点看到的结果。
- 探针和 /check 工具是同一套东西吗？
- 不是。探针是服务器侧后台任务，每 10 分钟探测全部在榜站点的可用性；/check 是浏览器直连目标站点的验真工具，由用户在页面上发起。验真抽样与 /check 的检测项相同，但抽样是每日分散执行的后台任务，也不等同于可用性探针。
- 原始响应为什么只留 90 天？
- 按当前实现，探测与快照的原始响应留存 90 天供复核。超过这一窗口的原始包会按清理策略删除，公开页上保留的是聚合后的统计。90 天是留存上限，不是前台会逐条展示留存期内的全部原始响应。