为什么「额度刷新周期」比「额度多少」更重要

官方 free tier 的额度通常不是一次性发完就没了。多数平台采用周期性刷新：有的是滚动窗口（rolling window），有的是每天固定时间重置，有的是每月按计费周期重置。

理解刷新机制的实际意义是：你可以用「节奏」而不是「囤积」来获得持续可用的免费调用量。同样是一份免费额度，算准刷新点的人能稳定跑通一个每日任务，没算准的人会在月中就被速率限制卡死。

下面按刷新机制分三类讲，每类给出可操作的判断方法和调用安排。注意：各平台具体额度数字会调整，本文不给出固定数值，只给判断与操作方法。

操作步骤

第一步：在控制台里找到「限额」页而不是「用量」页

大多数平台的计费控制台里有两个容易混淆的页面：

  • Usage / 用量页：显示你已消耗多少。
  • Limits / Rate limits / 限额页：显示你的上限、刷新周期、以及当前档位。

判断刷新机制，看限额页里的措辞：

  • 出现 per minute / per day / RPM / TPM / RPD 这类单位，说明是滚动窗口或每日重置。
  • 出现 per month / billing cycle / monthly credits，说明是月度重置，通常和账单周期绑定。
  • 出现 trial credits / expire on，说明是一次性额度且有有效期，这类要优先用掉。

第二步：按机制安排调用节奏

滚动窗口型（按分钟/小时）：

  • 特征是限制描述里带 per minute、per hour。
  • 做法：把批量任务拆成小批，中间加固定间隔，而不是一次性打满。很多平台的限流是「滑动」的，你连续打满反而会触发更长的冷却。
  • 适合：实时对话类应用、需要低延迟的 demo。

每日重置型（按天）：

  • 特征是限制描述里带 per day、daily quota。
  • 做法：先确认重置时区。不少平台按 UTC 重置，换算到北京时间通常是早上。把每日的批处理任务放在重置后不久跑，能拿到一整天最充裕的额度。
  • 适合：每天跑一次的摘要、报表、数据清洗任务。

月度重置型（按账单周期）：

  • 特征是限制描述里带 per month、monthly。
  • 做法：记录你的账单周期起始日，月初集中做需要大量 token 的实验（比如长文档处理、批量评测），月末留给轻量调用。
  • 适合：阶段性项目、需要一次性跑大量推理的实验。

一次性试用额度（trial credits）：

  • 特征是带有效期。
  • 做法：这类额度不会刷新，会过期。优先用于验证生产链路，别留着做实验。

第三步：把刷新点写进你的调度里

如果你用脚本或工作流调用 API：

  1. 在代码里对 429（Too Many Requests）做指数退避重试，而不是直接失败。
  2. 记录每次 429 的时间戳，连续记几天就能反推出真实的刷新窗口。
  3. 把大批量任务调度到刷新后不久执行。

这一步比读文档更可靠，因为文档有时不写清楚具体窗口，而 429 的时间分布会直接暴露规律。

第四步：确认账号等级是否会改变限额

免费额度的限额经常和账号状态挂钩：

  • 是否完成邮箱验证。
  • 是否绑定支付方式（有的平台绑定后免费档位上限会变）。
  • 是否完成组织/团队认证。

如果你发现限额和文档不符，先去账号设置里确认这几项状态。

注意事项

  • 免费档位的模型范围通常有限。免费额度可能只覆盖部分模型，旗舰模型往往不在免费范围内，调用前先确认。
  • 免费档位的数据使用条款可能不同。部分平台在免费档位下会使用你的输入输出做改进，商用或处理敏感数据前务必读条款。
  • 速率限制和额度限制是两件事。额度没用完也可能因为 RPM/TPM 被限流，两者要分开处理。
  • 额度政策会变。平台会随时调整免费档位的范围和上限，本文只讲方法，不承诺具体数值，请以你账号内实际显示的限额为准。
  • 不要用多账号绕过限制。多数平台的服务条款禁止此类行为，可能导致封号。

适用场景

  • 个人开发者做副业项目，需要长期稳定的免费调用量。
  • 学生或研究者跑周期性实验（每日/每周任务）。
  • 团队在正式采购前做技术验证，希望控制成本。
  • 需要把免费额度当作「保底容量」，和付费额度混合使用。

小结

官方 free tier 的真正用法不是「领一次」，而是「按周期用」。先分清你的额度属于滚动窗口、每日重置、月度重置还是一次性试用，再据此安排任务节奏，你就能在不付费的前提下维持一条稳定的调用链路。