为什么要把「赠额」和「余额」分开看

API 聚合网关（也叫中转站、聚合站）的免费额度通常有两种来源：

  • 赠额（trial / gift credit）：注册、活动、邀请、渠道商赠送产生的额度，成本为零，但几乎都带附加条件。
  • 充值余额（top-up balance）：你付过钱的余额，通常没有过期问题，但也不是「免费」的部分。

很多人的踩坑方式是：把两者混在一个 key 里跑，结果赠额先被扣完、限速触发、请求报错，而真正需要跑的生产流量也被一起拖慢。

正确的顺序是：先分清额度类型，再查三件事——有效期、限速档、可迁移性，最后才决定这段流量交给谁跑。

操作步骤

第一步：把赠额从余额里「隔离」出来

  1. 登录网关后台，找到账单 / 用量（Billing / Usage）页面。
  2. 看额度明细：通常会分成 gift、bonus、trial、balance、top-up 等条目。
  3. 如果平台支持创建多个 API Key，为赠额单独建一个 Key，只跑测试、脚本、批处理这类可中断的任务。
  4. 生产请求走另一个 Key（充值余额或付费渠道），避免赠额耗尽时把生产流量一起带崩。

> 这一步的价值不在省钱，而在于把「失败范围」限制住。

第二步：确认有效期与刷新规则

不同网关的赠额有效期差异很大，常见几类：

  • 固定天数：注册后 N 天内有效（常见 7 / 14 / 30 天），到期作废，不刷新。
  • 月度刷新：每月固定额度，用不完不累积（少数平台支持累积）。
  • 活动型：随节日、首发、联名活动发放，通常有明确截止日期。
  • 邀请型：被邀请方首次充值或首次调用后触发，可能延迟到账。

要查的地方：账单页的额度说明、FAQ / 公告、以及渠道商的说明邮件。不确定的数额一律按「约」估算，别当成固定收入做预算。

第三步：查限速档位，而不是只看总额

赠额最容易被忽略的限制是速率：

  • 每分钟请求数（RPM）
  • 每分钟 Token 数（TPM）
  • 并发上限
  • 是否允许流式（stream）
  • 是否限制特定模型（贵的模型常常不给赠额用）

实操建议：用同一个 prompt 分别打赠额 Key 和余额 Key，记录首字延迟和失败率。如果赠额 Key 在高并发下频繁 429，就把它定位成「离线批处理专用」，而不是在线服务。

第四步：评估可迁移性

这一条最容易被漏掉，但决定了赠额到底值不值钱：

  • 赠额能否用于该网关的全部模型，还是只限部分？
  • 能否通过 OpenAI 兼容接口调用？
  • 能否导出用量记录，方便和自有账单对账？
  • 如果网关停止服务，这条链路里有多少是你能带走的（自己的 prompt、自己的缓存、自己的日志）？

判断标准很简单：能迁移的部分是你的资产，不能迁移的部分只是租用。

第五步：做一张「额度台账」

用一张表管住所有网关：

| 网关 | 额度类型 | 约额度 | 到期日 | RPM/TPM | 可用模型 | 用途 |

|---|---|---|---|---|---|---|

每周花十分钟更新一次，比临时抱佛脚有效得多。

注意事项

  • 不要用赠额跑不可重试的任务：长任务中途额度耗尽，重跑成本可能高于省下的钱。
  • 不要把赠额当收入：活动型赠额随时可能调整，预算里只算充值余额。
  • 注意数据流向：中转站会经手你的请求内容，敏感数据不要走赠额渠道。
  • 注意地区与合规：部分网关对可用区域有限制，跨境使用前先确认。
  • 注意 key 泄露：赠额 Key 也等于真金白银，公开仓库里不要硬编码。
  • 不要同时开太多网关：维护成本会吃掉省下来的额度，建议控制在 2–3 家。

适用场景

  • 个人开发者做原型验证、脚本批处理、离线数据清洗。
  • 小团队在正式采购前，用赠额跑通链路、验证模型效果。
  • 已有自建网关（LiteLLM / One API 等），想把赠额作为「兜底上游」接入。
  • 需要多模型对比评测，但不想为每个模型单独付费。

小结

聚合网关的免费额度不是「领了就完事」，而是一份带条件的临时资源。真正提高可用性的动作只有三个：隔离 Key、查清有效期、查清限速。把这三件事做完，赠额才能从「偶尔能用」变成「稳定可依赖的测试通道」。