为什么选聚合网关这条线

官方 Free Tier 的问题是分散：每家一个控制台、一套限速、一种计费口径。API 聚合网关（OpenRouter、Together、Fireworks、DeepInfra、Novita 等一类「多模型统一入口」服务）把多家模型放在同一个 OpenAI 兼容端点后面，注册通常会给一笔试用金或若干免费模型调用额度。它的价值不在于额度大，而在于同一把 Key 能覆盖多个模型，额度可以集中消耗、集中观测。

本方案的目标不是「领一笔」，而是把网关的试用金做成一条可轮换的供给线：主 Key 跑日常，备用 Key 在主 Key 限速或余额见底时自动接管。

操作步骤

第一步：按「计费口径」挑网关，而不是按名气

注册前先看三件事，全部在定价页或控制台可见：

  1. 试用金是否有有效期。多数网关的注册赠额有 30 天左右的窗口，也有部分标注「永久可用但仅限免费模型」。有效期决定你把它当「一次性测试」还是「月度补给」。
  2. 免费模型池是否独立于试用金。不少网关有两套东西：一笔现金赠额（可调任意模型）+ 一个 :free 后缀的免费模型池（限速、可能限并发）。两者要分开记账。
  3. 是否要求绑卡。部分网关注册即可用，部分需要最低充值才解锁赠额。不绑卡的优先，避免自动续费风险。

第二步：开户后先做「验额」，别急着写代码

拿到 Key 后，用一次最小调用确认三件事：赠额是否真的到账、限速是多少、错误码长什么样。

```bash

curl https://<gateway>/api/v1/chat/completions \

-H "Authorization: Bearer $KEY" \

-H "Content-Type: application/json" \

-d '{"model":"<free-model-id>","messages":[{"role":"user","content":"ping"}],"max_tokens":8}'

```

再查一次余额端点（多数网关提供 /api/v1/credits 或 /key 之类的接口），把「调用前余额」和「调用后余额」记下来。如果两次余额都没变，说明你走的是免费模型池而不是赠额，这决定了后面路由怎么配。

第三步：在网关内部配「模型别名 + 降级链」

这是本方案的核心。网关一般支持把多个模型挂在一个别名下，或提供 fallback 配置。做法是：

  • 主别名指向赠额可覆盖的付费模型（质量优先）；
  • 备用别名指向免费模型池（限速优先）；
  • 客户端只认一个 base_url 和一个 model 名，降级在网关侧完成。

如果网关不提供原生 fallback，就在客户端做一层薄封装：捕获 429 / 402 / 余额不足错误，切到备用别名重试一次。这一层大约 30 行代码，是整个方案里唯一需要写的部分。

第四步：多网关轮换，把「一次性赠额」拉成时间线

单家赠额总有用完的一天。准备 2–3 家网关，按到期日排序：先把最早过期的赠额跑完，再切下一家。控制台里的余额和到期时间每周看一次即可，不需要天天盯。

轮换的关键是统一接口：所有网关都走 OpenAI 兼容协议，切换时只改 base_url 和 api_key 两个环境变量，业务代码不动。

注意事项

  • 赠额通常不可转让、不可提现，所谓「可迁移」指的是你可以把调用迁移到另一家网关，而不是把余额转走。
  • 免费模型池普遍限速且可能排队，不适合做实时交互；把它放在降级链末端，而不是主路径。
  • 部分网关会因异常调用模式（高频、超长上下文）直接封禁试用账号，验额阶段不要压测。
  • 赠额到期不提醒，建议自己在日历上记一笔，到期前一周集中把剩余额度用在一个真实任务上（批量分类、语料清洗），而不是浪费掉。
  • 各家的具体额度、有效期、限速变化很快，注册前以定价页当前展示为准，本文不写死数字。

适用场景

  • 个人开发者做原型验证，不想为每个模型单独开户；
  • 小团队需要一个统一入口做多模型对比评测；
  • 已有主用官方 API，但想在限速或余额耗尽时有兜底；
  • 需要快速横向比较多个开源模型在同一任务上的表现。

不适合的场景

  • 生产环境的高并发实时服务（免费额度撑不住）；
  • 对数据驻留有硬性合规要求的场景（请求会经过第三方网关）；
  • 需要稳定 SLA 的商业交付。