选LLM API中转商前：5项指标自测清单（附Python脚本）

买同一个模型的API访问权限，通过不同的中转商（relay/reseller）获取，很快你就会发现它们根本不是一回事。有的高峰期频繁超时，有的中位延迟很快但P95表现糟糕，还有的甚至在200状态码的响应体里悄悄塞错误信息。

如果你正在为同一个模型挑选API中转服务商，仅凭感觉做决定往往会踩坑。下面这份清单总结了提交前应该核查的5项关键指标，并附上一段可以自己运行的Python探测脚本。

为什么“同一个模型”并不等于“同样的服务”

不同中转商转售的可能是完全相同的模型名称，但它们在网络链路、负载调度、限流策略上的差异，会直接决定你的实际体验。核心矛盾在于：模型质量是一回事，服务可靠性是另一回事。把这两件事混在一起判断，是最常见的误区。

要做出靠谱的选择，关键是把评估拆解成几个可量化、可复现的维度，而不是依赖“我感觉这家挺快”这类主观印象。

五项核心指标清单

1. 对等比较，别混着比

只对比提供相同模型名称的中转商。一旦把不同模型放在一起比，你讨论的就从“可靠性问题”变成了“质量问题”，结论自然失真。确保你测的是同一个 model 字段，才能把变量控制住。

2. 测可用性，不要凭感觉

一个请求只要出现以下任一情况，就应判定为失败：超时、返回非2xx状态码、或返回了错误负载（error payload）。

更重要的是，报告成功率时必须附带样本量。“19/20”和“950/1000”所代表的证据强度完全不同——前者可能只是运气，后者才有统计意义。别让小样本给你虚假的安全感。

3. 关注P95，而非平均值

用户真正能感知到的是慢请求的“长尾”，而平均值恰恰会把长尾掩盖掉。一个中位延迟很漂亮的服务，可能在P95上让部分请求卡顿到无法接受。衡量延迟时，P95（95分位延迟）比均值更能反映真实的最差体验区间。

4. 记录测量时间点

一个中转商在凌晨03:00表现良好，到了晚上21:00可能就彻底崩了。网络和负载随时间波动，因此每一个数字都必须打上时间戳。脱离时间上下文的性能数据，参考价值非常有限。

5. 缺失数据就标注缺失

如果某家服务你没能测到，就如实标注“无数据”，绝不要用猜测去填补空白。用估算值冒充真实测量，只会让整份评估失去可信度。

一段最小化探测脚本

下面这段Python脚本实现了上述思路的核心：对指定端点发起N次请求，统计成功率与P95延迟，并记录检测时间。

import time, statistics, requests, datetime as dt

def probe(base_url, key, model, n=20, timeout=60):
    lat, ok = [], 0
    for _ in range(n):
        t0 = time.perf_counter()
        try:
            r = requests.post(f"{base_url}/v1/chat/completions",
                headers={"Authorization": f"Bearer {key}"},
                json={"model": model, "max_tokens": 16,
                      "messages": [{"role": "user", "content": "Reply with OK"}]},
                timeout=timeout)
            body = r.json()
            if r.ok and "choices" in body:
                ok += 1
                lat.append(time.perf_counter() - t0)
        except Exception:
            pass
    p95 = statistics.quantiles(lat, n=20)[18] if len(lat) >= 2 else None
    return {"checked_at": dt.datetime.utcnow().isoformat() + "Z",
            "success": f"{ok}/{n}", "p95_s": p95}

脚本的几个设计细节值得留意：它用 r.ok and "choices" in body 双重判断成功，既检查状态码也检查响应体结构，正好对应第2点里“200里藏错误”的坑；用 statistics.quantiles 取第18个分位点近似P95，呼应第3点；返回值里带上 checked_at 时间戳，落实第4点。

一个重要提醒：只探测你被允许测试的端点，并把 n 保持在较小的值，避免对任何服务商造成压力式请求。这既是技术伦理，也能让你的测试不被对方限流干扰。

statistics.quantiles(lat, n=20)[18]这一行值得展开说明。Python标准库的quantiles函数将数据划分为n个等份，返回n-1个分割点。当n=20时，返回19个分位点，索引0对应第5百分位（P5），索引18对应第95百分位（P95）。这是一种利用已有标准库近似计算P95的轻量方案，无需引入numpy等外部依赖。需要注意的是，当样本量lat较小时（比如仅5-10个成功请求），分位数估算误差会较大，这也是脚本设定len(lat) >= 2才计算、并建议n取合理值（如20以上）的原因。在精度要求更高的场景下，可以改用numpy.percentile(lat, 95)或增大采样次数来提升可靠性。

不想自己跑脚本怎么办

如果你不想自建这套流程，原作者提到一直在用 Folkbench 做类似的事：它针对同一模型对各中转商按统一的公开指标（可用性、响应时间、价格）排名，每条结果都标注检测时间，缺失数据保持可见，并把商业投放与排名顺序分开处理。

需要说明的是，这是原文作者的单一来源推荐，使用前建议自行验证其指标口径是否与你的需求匹配。

小结

挑选LLM API中转商，本质是一场可靠性评估而非模型评测。把“对等比较、测可用性、看P95、记时间、缺失即缺失”这五点落到实处，再配合一段轻量脚本做实测，就能把“哪家更好”从玄学变成有数据支撑的判断。至于你还会追踪哪些额外指标——比如计费准确性、长连接稳定性——这正是值得持续积累的经验。

背景补充

P95（第95百分位数）是统计学中的分位数概念：将所有请求的延迟从低到高排列，P95表示有95%的请求延迟低于这个值，换言之它反映了最慢的那5%请求的入场门槛。与之对比，平均值会被少数极端慢请求"拉高"，但同时也被大量快请求"拉低"，最终呈现一个看起来还不错却掩盖了真实痛点的数字。实际产品中，如果P95延迟达到10秒，意味着每20个用户里就有1个会遭遇令人沮丧的等待体验，这在高并发场景下会造成显著的用户流失。除P95外，更严格的评估场合还会关注P99甚至P99.9，以捕捉极端长尾——取决于你的业务对偶发卡顿的容忍度。

"200状态码里藏错误信息"是LLM API中转服务中一种特别隐蔽的故障模式。标准HTTP协议约定2xx表示请求成功，但部分中转商在遇到上游限流、余额耗尽或模型不可用时，仍返回HTTP 200，而将错误信息以JSON字段（如{"error": "upstream overloaded"}）塞入响应体，而非标准的choices结构。如果你的客户端只检查状态码而不解析响应体，就会把这类失败误判为成功，导致可用性数据虚高。这也是脚本中使用r.ok and "choices" in body双重判断的原因——前者检查HTTP层，后者检查业务层，两者缺一不可。