为什么「限速分层」比「额度数字」更值得研究
大多数聚合网关（中转站）在注册试用期给的不是一笔纯粹的余额，而是「余额 + 速率档位」的组合：低档位便宜但慢、高档位快但贵，部分平台还按模型分池限速。很多人把赠额全部打在高档位模型上，几天就见底；也有人全部走低档位，结果体验差、任务跑不完。真正有效的做法是把同一笔赠额按速率档位拆开，让每一档只承担它最擅长的任务。
操作步骤
第一步：先摸清网关暴露的三类档位
登录后不要急着调模型，先找到控制台里的限速与计费说明，逐项记录：
- 速率档位：每分钟请求数（RPM）与每分钟 Token 数（TPM）的分档规则，通常低档位 RPM 高但 TPM 低，高档位反之。
- 模型分池：同一网关内，旗舰模型与轻量模型往往限速不同，轻量模型通常有独立的、更宽松的免费池。
- 并发上限：单 Key 的并发连接数限制，这决定了你能不能用并发换吞吐。
记录成一张表，标注每档的「单位 Token 成本」与「实际可用速率」。这一步不做，后面全是盲调。
第二步：按任务类型分配档位
把日常调用分成三类，分别绑定不同档位：
- 批量离线任务（摘要、分类、清洗）：走轻量模型池 + 低速率档位，用队列慢慢跑，不占高档位配额。
- 交互式任务（对话、代码补全）：走中档位，保证首字延迟可接受。
- 高价值单次任务（复杂推理、长文档分析）：只在必要时走高檔位旗舰模型，并做调用前预检。
关键原则：高档位只给不可替代的请求，其余全部下沉。
第三步：本地路由做降级
在客户端侧（例如用 LiteLLM、One API 或自写一层薄代理）配置路由规则：
- 主路由指向中档位模型；
- 捕获 429（限速）与 5xx 错误后，自动降级到轻量模型池重试；
- 对超长输入做前置截断或分段，避免单个请求打爆 TPM；
- 对非关键请求加随机抖动与重试退避，减少撞限速的概率。
这样即使赠额速率被压，工作流也不会整体卡死。
第四步：用「速率账本」监控消耗
每天记录三个数：各档位实际消耗 Token、触发 429 的次数、平均延迟。当某一档 429 频繁出现，说明该档位已接近瓶颈，应把该档任务继续下沉或改到夜间跑。
注意事项
- 限速规则会变：网关的档位与分池规则常随运营调整，务必以控制台当期说明为准，不要照搬旧教程。
- 免费额度的有效期：多数试用金有明确到期时间，速率分层只能延长「用得久」，不能延长「有效期」，到期前要做一次集中清理。
- 并发不等于速率：提高并发可能直接触发封禁或降级，先小步试探。
- 不要用多账号刷档位：违反平台条款，且多数网关有设备与支付指纹风控。
- 降级要有质量兜底：轻量模型输出质量不同，关键任务需人工抽检。
适用场景
- 个人开发者用试用金跑批量数据处理，希望撑到项目上线；
- 小团队把赠额当「过渡期算力」，需要在预算批下来前维持服务；
- 需要多模型对比评测，希望在不额外付费的前提下覆盖多个模型池。
一个最小可用的配置思路
在本地代理里维护一张「任务 → 档位」映射表，请求进来先查表决定目标模型与最大重试次数，再交给路由层；路由层只做两件事：限速退避与降级重试。整个链路不超过百行代码，但能把赠额的可用时长拉长数倍。