你刚测了一家中转站，延迟看着不错，或者偶尔蹦出一个 5xx，就开始纠结要不要换。问题往往不在这一两次结果，而在你根本不知道这个数字是怎么算出来的、分母是谁、观测了多久。这篇把三个指标拆开讲：分母是什么、窗口多长才有意义、噪声从哪来，再给一张先怀疑谁的排查顺序表，以及样本不够时的加观测办法。
你刚测了一家中转站，延迟看着不错，或者偶尔蹦出一个 5xx，就开始纠结要不要换。问题往往不在这一两次结果，而在你根本不知道这个数字是怎么算出来的、分母是谁、观测了多久。同一份原始数据，换个算法能得出完全相反的结论。
这篇把延迟、可用率、错误率三个指标拆开讲：分母是什么、窗口多长才有意义、噪声从哪来，再给一张「先怀疑谁」的排查顺序表，以及样本不够时该怎么加观测。目标不是让你算出精确数字，而是让你在数据不足时知道该闭嘴，在数据够了之后知道往哪查。
三个指标，先问分母是谁
所有指标都是「分子除以分母」，但大多数人只看分子。延迟你测得快，是因为请求短、还是因为线路好？可用率你算得高，分母是十次还是上千次？错误率里那些 401，到底该算在谁头上？先把口径钉死，再谈数字好不好看。
| 指标 | 分母是谁 | 常见口径陷阱 |
|---|---|---|
| 延迟 | 你实际发出的那批请求 | 首字时间、整段完成时间、单次往返混着比，等于没比 |
| 可用率 | 窗口内发起的请求数 | 把一次连续失败算成一个故障区间，比率会虚高 |
| 错误率 | 窗口内返回的响应数 | 4xx 多半是客户端配置问题，不该记到站点账上 |
- 延迟至少分三种：首字时间、整段完成时间、单次往返，量之前先固定一种，别拿 A 家的首字去比 B 家的整段
- 可用率的分母是「窗口内发起的请求数」，不是「你感觉它挂了的那段时间」，连续失败怎么计数要提前定规则
- 错误率必须先区分 4xx 和 5xx：401、404 这类先查自己的 Key、Base URL 和参数，别急着骂站点
- 量延迟之前，先到 /tools/speed-test 量出你自己这条链路的基线，不然测出来的数字里一半是你自己的问题
观测窗口与噪声从哪来
单次结果没有统计意义。网络抖动、你的机器负载、跨境线路、对端瞬时排队，任何一个都能让一次请求变慢或者直接超时。你看到的不是站点的真实水平，而是「你的链路 + 对端 + 那一刻」的叠加结果。
窗口太短还会把周期性波动误判成故障。高峰和凌晨完全是两个世界，只测下午一次就下结论，换个时段结论就翻。所以关键不是测得多准，而是测的时段够不够散。
- 本地网络与代理
- 先排除自己这端的抖动，换个网络或关掉代理再测一次
- DNS 解析
- 解析慢会拖慢首字时间，但和模型本身没关系
- 客户端超时设置
- 超时设得太短，会把正常的慢响应记成失败
- 流式响应中断
- 长输出被截断是链路问题还是服务端问题，要分开看
- 你的并发量
- 并发一上来错误率就变，这是你的用法在放大风险
先怀疑谁：排查顺序表
遇到异常，最省时间的做法是按固定顺序往下查，而不是随机换站点。下面这张表是排查顺序，不是结论表，每一步都要拿到证据才能往下走。
| 顺序 | 先查什么 | 判断标准 |
|---|---|---|
| 第一步 | 查自己：Key、Base URL、协议配对、超时重试 | 可用 /base-url 核对兼容层，配置错了先改配置 |
| 第二步 | 查单点还是普遍：换客户端、换网络、换时段各试一次 | 只有一处挂，说明是你那条链路的问题 |
| 第三步 | 查错误类型分布：4xx 多还是 5xx 和超时多 | 4xx 占多数回到配置，5xx 和超时才指向服务端 |
| 第四步 | 查站点侧历史表现，看是不是全局性波动 | 对照 /ai-status 一类监控页面确认范围 |
- 只有一处挂、换个客户端就好，这是你那条链路的问题，换站点解决不了
- 同样的 Key 换网络也挂，再换时段还是挂，才开始怀疑服务端
- 4xx 占多数说明请求本身有问题，先别动供应商
- 5xx 和超时占多数，才值得去对比别家的表现
- 确认是全局性波动，再决定是等它恢复还是安排迁移
样本太少怎么加观测
样本没攒够之前，任何「可用率百分之多少」都是心理安慰。宁可多看几天趋势，也别拿三五次结果去对比两家。加观测的本质是让数据量追上你的结论强度。
- 固定一组探针同一个模型、同一段提示词、同一长度输出，参数不要中途改，改了就不具备可比性。
- 固定时段打点每天固定几个时段各打几发，至少覆盖高峰和低谷，攒够天数再算比率。
- 结果落到表里时间、时段、状态码、首字时间、总耗时，字段越简单越容易坚持，字段设计可参考 /usage-log-fields 的思路。
- 保留异常样本出错的原始请求和响应留档，后面跟客服对质或者迁移时，这就是证据。
- 攒够再下结论在样本量够之前，只描述现象不下判断，避免把噪声当成趋势。
单个数字不能说明问题，能被复现的趋势才能。
什么情况下这套读法不适用
这套读法默认你关心的是「稳定调用」。如果你做的不是这件事，权重就要重新分配，别被指标牵着走。
- 只做低频离线任务、对延迟不敏感时，可用率权重可以降下来，注意力放到计费口径和模型是否被掉包上
- 需要长上下文或特定能力时，稳定性再好看也补不了能力缺口，先回到任务本身再看指标
- 单次突发故障不等于站点不可用；反过来，长期平稳也不等于没有掉包风险，两类检查要分开做
- 涉及数据边界的问题不在这篇范围，先读 /key-safety 把原则定下来，指标再好也不能越过这条线
- 需要横向比多家时，先去 /rankings 看当时的整体表现，别拿自己的单点结果去对别人的汇总数字
常见问题
我测了一次延迟很低，是不是说明这家站很快？
不能。单次结果受线路、时段、对端排队影响很大，可能是运气好。正确做法是固定口径、多个时段各测一轮，先用自己的基线去比。基线怎么量可以看站内的接口测速工具，测完再决定要不要换。
偶发几个 5xx 就要换站吗？
先别急。看错误率的分母和窗口：是集中在一小段时间还是分散全天，是一路 5xx 还是夹着超时。零星且集中在高峰期，多半能忍；持续且跨时段出现，才值得考虑迁移。同时先排除自己链路的问题。
样本太少时怎么快速判断？
没法快速判断，只能加观测。固定探针、固定时段、固定请求内容，连续跑几天再看趋势。如果非要当下决定，就按风险来：先把钱分开放、小额试水，等数据够了再决定加仓还是撤。
