返回博客

想换一个 AI 网关?先把这份检查清单跑一遍

评估任何 OpenRouter 替代品或 AI API 网关都适用的实操清单:OpenAI 兼容深度、账单是否透明、调用失败要不要付费、试用门槛、状态页可信度。

Apiko 团队

如果你已经在用 OpenRouter 调用模型,应该很熟悉这个品类的卖点:一个 key、一份账单、接入一堆模型。这个思路本身没问题,对不少团队来说也是够用的默认选择。但"找一个 OpenRouter 替代品"是个很模糊的诉求——同一个品类里,不同网关在计费精度、失败重试、以及到底多大程度上兼容 OpenAI 协议这几件事上,差异可以很大。

这篇不是产品对比评测。它是一份检查清单,可以拿去套用在任何一个 AI API 网关上——包括你现在正在用的那个——在你把生产流量真正切过去之前先跑一遍。文中提到 OpenRouter 的地方只作为这个品类的公开、通用背景,不涉及任何无法验证的评测或数字;需要举例说明某一项具体怎么落地时,我们会用 Apiko 的实际机制来讲,因为这是我们最熟悉的网关。

为什么"选网关"不能靠感觉,得靠清单

大多数人评估一个网关,做到"curl 能跑通"就算过关了。这一步当然必要,但远远不够。网关卡在你的应用和每一次模型调用之间——如果它的计费口径含糊、重试是静默的、状态页只是摆设,你不会在接入的第一天发现问题,而是会在出故障、账单对不上,或者两者一起发生的时候才发现。这类失败模式往往很"无聊"、发作很慢,恰恰因为不惊艳,所以五分钟的 demo 里根本看不出来。

下面把要核查的问题分成五类。每一类都该当作"过/不过"的硬门槛,而不是加分项。

检查清单

1. OpenAI 兼容——兼容到什么程度,而不只是"兼容不兼容"

"OpenAI 兼容"这个说法很容易被用得很松。具体应该追问:

  • /chat/completions 能不能直接用你现成的 OpenAI SDK 跑通,还是需要一个专门 fork 出来的客户端?
  • 支不支持流式返回?最后一个 chunk 里带不带真实的用量数据(stream_options: { include_usage: true }),还是要你在客户端自己猜 token 数?
  • 换模型是不是只改一个 model 字符串就够了,还是每换一家供应商都要改请求结构?

真正做到 OpenAI 兼容的网关,你的代码里只需要改两处:baseURL 和 API key。其余的一切——SDK、请求/响应结构、错误信封——都保持不变。这是及格线。在 Apiko 上,接入被刻意压缩成三步:创建一个 API key,把 baseURL 指向网关,调用目录里的任意模型。只要你的代码已经会说"OpenAI 的语言",它天然就会说"Apiko 的语言"。

curl {GATEWAY_BASE_URL}/chat/completions \
  -H "Authorization: Bearer $APIKO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.2",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

{GATEWAY_BASE_URL} 换成你实际部署环境的网关地址——具体地址和当前可用模型的 id 列表以 /docs 为准,因为目录会随着新渠道上线而变化。

2. 账单透明——你能不能用日志把账单"复算"出来

这一项是最多团队会跳过、之后又会后悔的一项。应该问评估中的网关:

  • 定价页上写的价格,和计费引擎实际用来扣费的数字,是不是同一个数?还是说定价页只是一个会跟实际情况脱节的营销页?
  • 计费依据的是供应商真实返回的 token 用量,还是一个粗略估算?
  • 用量日志能不能导出,能不能自己核对某一笔扣费是否合理?

一个连"这笔调用为什么扣了我 $X"都答不上来的网关,还没准备好承接生产流量。Apiko 的定价页数据来自计费引擎读取的同一个数据源,单位是每 100 万 token 的美元价格——具体价格请以 /pricing 页面的实时数字为准,不要参考任何写在博客文章里的数字,因为价格会变。用量日志会记录模型、prompt/completion token 数、耗时、是否走了流式、以及实际扣费金额,并且支持导出 CSV 用于对账。

3. 调用失败了,你要不要为此付钱

这是清单里杠杆最大的一个问题,也是最容易被忽视的——直到某个上游渠道哪天状态不好,你才会想起来问。

  • 如果模型供应商返回 5xx,网关会不会自动切换到别的渠道重试,还是直接把错误抛回给你?
  • 如果所有重试都失败了,这次调用是要计费,还是会退款?
  • 有没有一份文档化的错误码表可以照着写重试逻辑,而不是靠翻工单一点点摸索出来?

值得具体问清楚的计费流程是:请求发出时先按估算金额预扣,等供应商返回真实响应后按真实 token 用量结算,如果最终这次上游调用彻底失败,预扣的部分会自动退款——你不会为一次没有产出任何结果的调用付钱。一个说不清楚这个流程细节的网关,大概率也没有把它真正实现到位。

| 状态码 | 常见原因 | 应该发生什么 | |---|---|---| | 401 | key 缺失或无效 | 检查 Authorization 头和 key 状态 | | 402/403 | 余额不足 | 先充值再重试 | | 404 | 模型或路径不存在 | 对照实时目录核对模型 id | | 429 | 触发限流 | 退避后重试 | | 5xx | 上游渠道故障 | 网关自动跨渠道重试;最终仍失败则不应计费 |

4. 试用与接入门槛

在把一个网关正式接进真实代码库之前,你会希望能先发一点真实流量出去,而不用先走一轮采购流程:

  • 不绑卡能不能注册并发出一次真实调用?
  • 有没有试用额度?宣传的额度数字和实际到账的数字是不是一致?
  • 试用额度用完之后,充值是自助完成的,还是要开工单?

Apiko 新账号注册后会自动获得一笔试用额度,无需绑卡,目录里的所有模型都可以用——具体到账多少以你账户内实际显示的数字为准,因为这是一个 admin 可配置的项目。试用额度之外,配额包是自助的一次性购买,支付完成后立即计入余额;没有订阅,也没有最低消费门槛。

5. 状态可见性——出问题前你能不能先自己查一遍

如果某个模型开始报错,你会想先确认这是自己代码的问题还是上游渠道的问题,而不是两眼一抹黑地开始 debug:

  • 有没有一个公开的状态页,还是只能去 Discord 里问?
  • 状态页反映的是模型的当前可用情况,还是一张一直"全绿"的静态图?
  • 有没有可以程序化轮询的 API,还是只有给人看的一个页面?

Apiko 的 /status 页面按模型展示可用性,大约每分钟刷新一次,如果底层检查没有及时跑,它会主动标记自己为"过期"——所以看到绿色状态,意味着确实刚刚检查过,而不是没人管它。

也拿这份清单检查一下自己在用的网关

之所以把这篇写成清单而不是评测,是刻意的选择:正确答案从来不是"换成某某网关",而是"不管你现在用的是谁,先照着这五项核实一遍——包括你正在用的这一个"。OpenRouter,在大多数工程师熟悉的通用意义上,是最早把这个品类和这套接口约定推广开来的产品之一。至于某个具体网关是否适合你的流量,取决于它对上面这些问题的回答能不能对得上你真实的业务场景,而不是取决于哪个名字更耳熟。

如果想直接拿这份清单来检查 Apiko:去注册拿一笔试用额度,把你现有的 OpenAI 客户端指向网关,再照着上面提到的 /status 和用量日志跑几次真实调用看看。目录里所有模型的实时 token 价格,随时可以在 /pricing 查到。