为什么先做「指纹审计」而不是先领额度

大多数人拿到聚合网关的免费额度后，第一反应是赶紧跑几个请求，把额度花掉。结果两周后回头看，账单里只剩一串模型名和几个数字，既说不清哪笔额度来自哪个上游，也不知道哪个 Key 还能续、哪个已经过期。

聚合网关的价值不在于「多一个免费入口」，而在于它把多个上游的额度收敛到同一套 Key、同一套计费口径下。这让你有机会做一件官方控制台做不到的事：给每一份额度打指纹，建台账。

操作步骤

第一步：在网关里建一张「额度台账」表

新建一个表格（Notion、飞书多维表格、或本地 CSV 都行），固定这几列：

  • 额度来源：上游厂商名（如某聚合平台自带的免费模型池、平台赠送的试用金、绑定的官方 Free Tier 转发）
  • 模型标识：网关里实际调用的模型 ID，而不是上游原始名字
  • 限速指纹：RPM / TPM / 并发上限 / 单日上限，实测出来的，不是页面写的
  • 到期条件：按时间到期，还是按用量烧完，还是按账户状态
  • 可续性：能否通过签到、邀请、周期重置续上
  • 当前余量：从网关的用量页读取

这张表是后面所有决策的依据，先建表再调用。

第二步：用「探测请求」实测限速指纹

页面写的限速经常和实际不一致，尤其是聚合网关对免费额度做了二次限流。做法是：

  1. 对每个模型发一组小请求（例如 10 次、每次几十 token），记录返回的 429 触发点；
  2. 逐步加大到触发限流，记下当时的每分钟请求数；
  3. 隔 1 分钟再试，确认是滑动窗口还是固定窗口重置；
  4. 把实测值写进「限速指纹」列。

这一步只需要几十次极小的调用，成本可以忽略，但决定了你后面能不能把它排进自动化任务。

第三步：核对模型映射，找出「同名不同源」

聚合网关常用别名把多个上游的同名模型聚到一起。同一个 gpt-4o-mini 之类的别名，背后可能在不同时段路由到不同上游，计费口径和限速都不同。

审计方法：调用时读取响应里的上游标识（多数网关会在响应头或返回体里带 provider 字段），连续采样几十次，看这个别名背后到底有几个来源、各自占比多少。把结果记进台账的「模型标识」列，注明别名与真实上游的对应关系。

第四步：按「可续性」给额度分三档

  • 长期养：能周期重置或有稳定免费池的，优先绑定到日常小流量任务（摘要、分类、embedding）；
  • 一次性烧：试用金类、到期即失效的，安排给批量离线任务，一次性跑完；
  • 观察档：限速指纹不稳定、上游频繁切换的，先不接入任何自动化，只做人工测试。

第五步：每月做一次「到期巡检」

固定一个日期（比如每月 1 号），打开台账逐行核对：余量、到期条件、上游是否还在。聚合网关的上游会变，某个免费池可能某天悄悄下线，台账不巡检就会失真。

注意事项

  • 不要用探测请求去压测：审计的目的是记录指纹，不是把额度跑满。大量并发探测可能触发账户风控。
  • 额度台账不要只记数字：只记「还剩多少」没有意义，必须同时记来源和限速，否则无法复用。
  • 别名映射会漂移：网关调整路由策略后，之前的指纹可能失效，巡检时要重新采样。
  • 区分「平台赠送」与「上游 Free Tier 转发」：前者受平台规则约束，后者受上游规则约束，两类的到期逻辑完全不同。
  • 不要把审计脚本写成高频轮询：用低频、小批量的方式采样即可。

适用场景

  • 手上有多个聚合网关账号、免费额度来源混杂的独立开发者；
  • 需要把免费额度排进定时任务（日报摘要、内容分类、批量 embedding）的小团队；
  • 想判断「这个网关的免费池值不值得长期依赖」的技术选型阶段；
  • 已经踩过「额度突然没了但不知道为什么」的坑、想建立可追溯机制的人。

和其他路线的区别

这条路不追求「多领一份」，而是追求「把已经领到的搞清楚」。指纹审计做完之后，你再去做注册试用金、路由降级、周期领取，都会更有针对性——因为你知道哪份额度值得花时间续，哪份可以直接放弃。