为什么路由层比赠额数字更重要
多数聚合网关的免费额度并不是「一次性打进账户的余额」，而是按模型、按区域、按限速分组拆开发放的。你在控制台看到的赠额数字，往往对应多个不同的上游通道；某个通道耗尽时，额度数字可能还没归零。
所以正确的顺序是：先摸清路由，再决定怎么花。
操作步骤
第一步：先把「模型映射表」抄下来
在网关的模型列表页（通常是 /v1/models 或控制台的 Model 页）导出全部模型 ID，重点关注：
- 同一个上游模型是否有多个别名（如
gpt-4o/gpt-4o-2024-xx/ 带-free或:free后缀的变体）。 - 哪些模型标注为 free / trial / preview。
- 每个模型的 context 上限与是否支持流式。
把这份表存成本地 JSON，后面所有脚本都从它读取，避免手写模型名写错导致 404 白白消耗重试次数。
第二步：用最小请求探测每条通道的限速分组
对每个候选模型发 1 次极短请求（max_tokens 设成 5～16），记录响应头里的 x-ratelimit-* 字段和返回的 model 字段。很多网关会把实际路由到的上游写在响应体里——这能告诉你「免费模型 A」到底打到了哪家。
注意：不同限速分组之间通常互不影响，一个分组打满后换另一个分组往往还能继续跑。
第三步：按「能力分层」而不是按「价格」选模型
把模型分成三层：
- 廉价层：小参数模型或带 free 后缀的模型，用于分类、抽取、格式化、改写这类高频低难度任务。
- 主力层：中等能力模型，用于主要生成任务，只在廉价层失败时升级。
- 兜底层：旗舰模型，仅用于最终校验或极少数困难样本。
免费额度优先喂给廉价层，兜底层设一个每日硬上限。这是把赠额用满最有效的一步。
第四步：配置「失败降级链」
在客户端或网关侧配置一条降级顺序：廉价层模型 → 同层另一个别名 → 主力层。触发条件建议设为：429、5xx、以及超时。
如果你用 LiteLLM、One API 这类自建网关，可以直接在 config 里写 fallbacks 列表；如果用托管网关，就在自己的代码里包一层重试函数，按状态码决定是否换模型。
第五步：把区域节点当成独立额度来源
部分网关提供多区域入口（如全球节点、亚洲节点、欧洲节点），免费额度与限速分组可能是分别计算的。做法是：在探测阶段给每个区域入口各发一次探测请求，记录限速头；然后在客户端按「区域」做轮询，而不是只用一个 base URL。
这一步的收益取决于网关是否真的分区计额——探测结果会直接告诉你答案，不要凭猜测配置。
第六步：给每条通道加「额度看板」
写一个每天跑一次的脚本：对每个模型别名发一次探测请求，记录成功/失败与限速头，输出成表格。连续记录一周，你就能看出哪些通道在什么时间点容易打满、哪些别名其实是同一通道的重复入口。
注意事项
- 免费通道的能力常被降级：带 free 后缀的模型可能被限制上下文长度或禁用某些参数，先用小请求验证参数兼容性。
- 不要用免费通道跑长上下文：一次超长请求可能直接吃掉整天的免费额度，且失败重试会重复计费。
- 遵守平台条款：不要用多账号刷额度、不要伪造请求头绕过限速，这类行为通常会被封禁，且违反服务条款。
- 额度数字不等于可用性：控制台显示有余额但请求 429，说明是该分组的限速在起作用，不是额度耗尽。
- 模型别名会变：网关的免费模型列表更新频繁，脚本要从模型列表接口动态读取，不要硬编码。
适用场景
- 个人开发者做原型验证，需要在不付费的前提下跑通完整链路。
- 小团队做内部工具，主要负载是分类、抽取、摘要这类低难度高频任务。
- 需要在多个上游之间做 A/B 对比评测，但预算有限。
- 作为付费通道的兜底：主通道故障时自动降级到免费通道。
不适用场景
- 需要稳定 SLA 的生产服务。
- 需要长上下文（如整本书、整份合同）的批处理任务。
- 对输出一致性要求极高的场景——免费通道背后的上游可能在请求之间切换。