为什么先看限速，不看总额

大多数人打开控制台的 Billing 页看「还剩多少」，但 Free Tier 真正卡住你的是速率：每分钟请求数（RPM）、每分钟 token 数（TPM）、每天请求数（RPD）。同一份额度，在交互式对话里可能十分钟就打满 RPM，而在批处理里可以平稳用上一整天。所以正确顺序是：先读限流页，再分配任务。

操作步骤

第一步：把限流页抄成一张表

对每个已开通 Free Tier 的厂商，去官方文档的 Rate limits / Quotas 页面，记录四项：RPM、TPM、RPD（若有）、以及额度刷新周期（按日/按月）。常见情况：主流厂商的免费层通常给到个位数到十几 RPM、每天数千到数万 token 量级，具体以你账号所在地区的官方文档为准，不要照抄别人的截图。

第二步：按「速率档位」给任务分类

  • 交互档：需要秒级响应的对话、写作辅助。只吃 RPM，token 消耗小。
  • 批处理档：摘要、分类、Embedding、离线标注。吃 TPM 和 RPD，可以排队。
  • 兜底档：前两档超限时的备用 Key/备用厂商。

同一份额度只用来跑交互档是浪费，只用来跑批处理档又会撞 RPD。正确做法是让批处理跑在低峰时段（多数厂商限速按分钟滚动，夜间同样有效），交互档只在白天用。

第三步：写一个「限速感知」的调用壳

在代码里维护每个厂商的 RPM/TPM 配置，用令牌桶做本地节流；收到 HTTP 429 时读取响应头里的 Retry-After 或 x-ratelimit-reset-*，按提示退避，而不是固定 sleep。这样同一份额度不会因为无谓重试被浪费。

第四步：多厂商互补，而不是叠加总额

把 2–3 家官方 Free Tier 接进同一个调用壳，按任务类型路由：交互档走延迟低的，批处理档走 TPM 宽松的，兜底档在 429 时自动切换。注意：这不是「聚合网关换额度」，而是你自己按速率档位编排同一批官方额度。

第五步：把「额度刷新」写进调度

多数免费层按自然日或滚动 24 小时刷新，部分按自然月。把批处理任务排在额度刷新后的第一个窗口跑，避免月末额度耗尽。用 Cron 或调度器把刷新时间写死，不要凭记忆。

注意事项

  • 免费层的速率限制会随厂商负载动态调整，文档数字可能滞后，以实际 429 响应为准。
  • 免费层通常不含 SLA，不要用于生产关键路径。
  • 部分厂商要求绑定信用卡才给免费层，部分不需要；开卡前先确认计费项，避免误触付费。
  • 不要用多账号绕过限速，多数厂商的服务条款明确禁止，风险是封号而非省钱。
  • 免费层的模型版本可能落后于付费层，先用 /models 接口确认可用模型名。

适用场景

个人开发者做副业项目、小团队做原型验证、学生做课程作业与实验、需要长期跑批处理但预算为零的场景。不适合对延迟和可用性有硬性要求的生产系统。