---
title: "api中转站怎么选：可用率、计费、数据政策等 8 项可核对的检查"
description: "选 api中转站时，看宣传不如看能核对的东西。本文给出 8 项检查：公开可用率口径、计费单位、数据政策、接口格式、条款、故障复盘、延迟与授权声明，每项附验证方法和 curl 命令。"
url: https://cdnping.org/blog/api-relay-how-to-evaluate
language: zh-CN
published: 2026-10-18
category: "开发工具"
tags: ["API中转","大模型API","可用率","计费","数据政策","开发工具"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# api中转站怎么选：可用率、计费、数据政策等 8 项可核对的检查

选 api中转站，先看它给出的东西能不能自己核对：可用率有没有公开的原始数据和计算口径，账单能不能和每次请求的 token 对上，数据怎么处理有没有写成文字。能核对的服务，出了问题你至少知道问题在哪；只能“相信”的服务，出了问题只能等。

下面是 8 项检查，每项都写了怎么验证，适合在充值或订阅之前做一遍。

## api中转站到底做了什么，为什么要单独评估？

中转站（也叫 API 网关、聚合网关）在你和模型提供方之间多加了一层：你的请求先到它的入口，再由它转发到上游。好处是换模型只改一个接口地址，结算方式也可能更方便；代价是多了一个会出故障、会计费、会接触你请求内容的环节。

所以评估的对象有三个：这一层自己稳不稳，它怎么收钱，它怎么对待你的数据。上游模型本身的质量和故障，是另一回事，要分开看。

## 8 项检查清单（可以直接照做）

| # | 检查项 | 合格的样子 | 怎么验证 |
|---|---|---|---|
| 1 | 公开可用率与口径 | 有原始计数可下载，写明分子分母 | 拉取数据，自己算一遍 |
| 2 | 计费单位与账单 | 单位有换算公式，单次请求可对账 | 发固定请求，对比 usage 与扣费 |
| 3 | 数据保留政策 | 写明是否落盘、是否训练、是否转售 | 找到书面条款并截图存档 |
| 4 | 接口格式 | 写明兼容哪种格式，流式与工具调用可用 | 用你实际的工具跑一次 |
| 5 | 退款与发票 | 条款写在页面上，而不是“联系客服” | 看页面，不看聊天记录 |
| 6 | 故障复盘 | 故障后有时间、影响范围和原因说明 | 找最近一次故障的记录 |
| 7 | 出口与延迟 | 入口延迟稳定，首 token 时间可接受 | 在自己的网络里测连接与 TTFT |
| 8 | 授权声明 | 如实说明与模型厂商的关系 | 看官网是否声称“官方授权” |

下面逐项展开。

### 1. 可用率数字是怎么算出来的？

“99.9% 可用”这句话本身没法验证。要问三件事：

- 统计对象：是定时探测（每几分钟 ping 一次入口），还是真实用户请求？探测只说明入口通不通，真实请求才反映你实际遇到的失败。
- 失败的定义：4xx（如密钥错误、额度不足）算不算失败？上游超时算谁的？口径不同，同一段时间能算出差很多的数字。
- 能不能拿到原始数据：只有一个百分比，就只能信；有逐小时的成功和失败计数，才能自己复算。

下面以 AGI Plan 为例，看“可核对”是什么样。先说明关系：AGI Plan 是 cdnping 的商业合作方。这里用它举例，是因为它的数据公开、我们能完整引用，不代表推荐结论。

它的可用率接口不需要登录：

```bash
# 默认返回 CSV；加 format=json 返回 JSON
curl -s "https://agiplan.dev/api/status/requests?month=2026-10&format=json"
```

返回的是逐小时、逐能力组的成功和失败计数。口径写明为：可用率 = 成功 /（成功 + 因平台自身原因失败），只有 5xx 算平台失败。cdnping 的 [AGI Plan 状态页](/status/agiplan) 镜像展示同一份数据。

我们在 2026-10-17 从这个接口取的数据快照（窗口为 2026-10-15 19:00 至 2026-10-17 18:00，北京时间，共 48 个小时桶）里：

- 48 小时合计成功 13,963 次、失败 2,177 次，按上面的口径算出约 86.5%。
- 失败集中在 10 月 16 日 14:00 和 15:00 两个小时：这两小时成功 1,119 次、失败 1,599 次，单小时可用率分别约 47.9% 和 34.2%。
- 按能力组的 30 天可用率：国产组约 98.0%，均衡组约 95.0%，前沿组约 94.4%，快速组约 81.7%。

这些数字并不好看。数据公开以后，坏的时段也会摆在那里：你能看出故障集中在哪几个小时、哪个能力组，再判断自己的用法能不能接受。只有一个百分比、没有原始计数，就做不了这种判断。

评估任何一家时，可以照这个方法做：拿到原始数据，自己求和，看最差的那几个小时，再看分组差异。

### 2. 计费单位能不能和请求对上？

中转站常用自定义单位（点数、积分、CU 之类）。要确认两件事：单位和 token 之间有没有公开的换算公式，单次请求的扣费能不能查到明细。

例如 AGI Plan 写明 1 CU = 基准模型 1,000 个输出 token，按量充值 1 元 = 500 CU。有了公式，你才能把账单换算回 token，再和模型官方价格对比。

验证方法：发一个输入、输出都固定的小请求，记下响应里的 `usage` 字段，再去后台看这次扣了多少。

```bash
export BASE="https://relay.example.com"   # 示例地址，换成你要评估的服务
export KEY="sk-..."

curl -s "$BASE/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"<模型名>","max_tokens":50,
       "messages":[{"role":"user","content":"只回答数字：1+1="}]}' \
  | python3 -m json.tool | grep -A4 usage
```

同样的请求连发 5 次，扣费应该基本一致。如果后台只有余额变化、查不到单次明细，月底就很难对账。模型调价、换算比例调整时，也要能及时知道，方法见 [大模型 API 价格变动的三路追踪](/blog/track-llm-price-and-model-changes)。

### 3. 你的请求内容会被存下来吗？

请求里常有代码、文档甚至密钥。要找的是书面条款，至少回答三个问题：请求正文是否落盘、保留多久；是否用于训练；是否转售或共享给第三方。

能写成一句话的政策更好核对。例如 AGI Plan 写的是“请求正文默认不落盘，内容不训练、不转售”。找到条款后截图并记下日期，条款日后改了，你手里有对照。

不管条款写得如何，不要把生产密钥、用户隐私数据放进提示词，这一条对官方 API 同样适用。

### 4. 支持哪种接口格式，你的工具能不能直接用？

现在常见的有 OpenAI 格式和 Anthropic 格式两种。例如 Claude Code 走 Anthropic 格式，Codex 走 OpenAI 格式。只兼容一种，意味着你有一部分工具接不上。

验证时别只跑一次普通对话，至少覆盖这三项：

1. 流式输出：加 `"stream": true`，看是否逐段返回，而不是攒到最后一次性吐出。
2. 工具调用：用你实际的 agent 工具跑一个需要读文件或执行命令的任务。
3. 长上下文：塞一份较长的文件，看会不会被截断或报错。

各工具的接口地址怎么改，可以参考 [Claude Code、Codex、OpenCode 自定义接口配置](/blog/configure-custom-api-endpoint-claude-code-codex)。

### 5. 退款和发票写在哪里？

这一项只看一件事：条款是否写在公开页面上。“有问题找客服”不算写明。需要报销的团队，要确认发票类型和开具方式是否在页面上说清楚。

聊天记录里的承诺很难作为依据，书面条款至少能截图存档。条款如果标注为草案或“即将上线”，就按还没有处理。

### 6. 出过故障吗，有没有复盘？

任何服务都会出故障。据 cdnping 从官方状态页同步的事件记录（截至 2026-10-17 的快照），2026-09-17 以来 OpenAI 记录了 25 条事件（其中 major 4 条），Claude 记录了 8 条（其中 major 6 条）。中转站的可用率上限受上游影响，这是事实；要看的是它出问题时说不说清楚。

验证方法：翻它的公告、状态页或更新日志，找最近一次故障，看有没有写明开始和结束时间、影响了哪些模型或分组、原因是上游还是自身、之后改了什么。

回到第 1 项的例子：公开计数能告诉你 10 月 16 日下午那两小时失败很多，但计数本身不给原因。所以第 1 项和第 6 项要一起看，前者告诉你“发生了什么”，后者告诉你“为什么，以后会不会再来”。状态页的事件等级怎么读，见 [怎么看 OpenAI 和 Claude 状态页](/blog/how-to-read-ai-status-pages)；近期上游故障的汇总在 [2026 年 9–10 月 AI 服务故障盘点](/blog/ai-service-incidents-sep-oct-2026)。

### 7. 从你这里访问，延迟能接受吗？

中转站的延迟由两段组成：你到它入口的网络，加上它到上游的转发与推理。别人测出来的数字只代表别人的网络，要在自己的环境里测。

第一步，打开 cdnping [在线测速](/)，在浏览器里看各 API 入口的“首次连接”（含 DNS 与 TLS 握手）和“往返”（连接复用后 3 次请求的中位数）。

第二步，用 curl 拆开看各阶段耗时：

```bash
curl -s -o /dev/null "$BASE/v1/models" \
  -H "Authorization: Bearer $KEY" \
  -w "DNS %{time_namelookup}s | TCP %{time_connect}s | TLS %{time_appconnect}s | 首字节 %{time_starttransfer}s | 总计 %{time_total}s\n"
```

在一天里的不同时段各测几次。`/v1/models` 不经过推理，反映的主要是网关本身；真正影响体验的是流式请求的首 token 时间（TTFT）。三段延迟怎么区分，参见 [AI API 延迟拆解：连接、往返与 TTFT](/blog/api-latency-connect-rtt-ttft)。

另外，同一个模型名，背后可能是不同的推理供应商和不同的量化精度，输出质量和速度都可能不同。可以在 cdnping [模型监测](/models) 看各供应商的可用率和量化标注，背景知识见 [推理供应商与 fp8、fp4 量化](/blog/llm-quantization-fp8-fp4-providers)。同一模型在不同供应商上的可用率差距，见 [同一模型换个 OpenRouter 供应商，可用率能差多少](/blog/same-model-different-providers-uptime)。

### 8. 它说自己是“官方授权”吗？

去模型厂商的官方渠道核实，而不是看中转站自己怎么说。如实说明自己身份的服务更可信一些。例如 AGI Plan 在官网明确说明自己不是官方授权渠道。

另外，部分模型在部分地区不提供服务。中转站标注的地区可用性（例如“仅境外”）以其官方页面为准，使用时请遵守模型厂商的服务条款和当地法规。

## 检查完怎么做决定？

把 8 项结果填进上面的表格，按这个顺序取舍：

1. 第 3、8 项有一项说不清，直接排除。数据政策和身份说明是底线。
2. 第 1、2 项决定能不能长期用。可用率无法复算、账单无法对账的服务，适合小额试用，不适合放进工作流。
3. 第 4、7 项决定好不好用。这两项和你的工具、网络强相关，只能自己测。
4. 第 5、6 项决定出事时的处境。条款和复盘越清楚，出问题后的沟通成本越低。

先小额或按量开始，用自己的真实任务跑一周，同时每天拉一次公开可用率数据（如果有的话），和你自己的报错日志对照。两边对得上，再考虑长期订阅。