免费额度api

做原型时不想还没上线就先充值，压测时又怕把付费额度打光——这时候免费额度API就派上用场了。但各家免费额度的领法、限制、有效期、能不能商用都不一样，随手挑一家很容易在关键时刻被限流卡住。这篇给一套盘点和验证的顺序：先定需求口径，再筛平台，最后自己跑一轮探针确认能撑住。

做原型时不想还没上线就先充值，压测时又怕把付费额度打光，这时候免费额度API就派上用场了。但各家免费额度的领法、限制、有效期、能不能商用都不一样，随手挑一家很容易在关键时刻被限流卡住。

这篇给一套盘点和验证的顺序：先定需求口径，再筛平台，最后自己跑一轮探针确认能撑住。全文不给死数字，凡是额度、限速、价格这类会变的东西，都告诉你去哪个站内页面核对当时的实际情况。

先想清楚你要白嫖的是哪种额度

免费额度这个词太笼统。你要的到底是「够我跑通一次demo」，还是「够我连续几周挂着跑小流量」，还是「够我在半小时内打到并发上限」，这三件事对同一个平台的要求完全相反。先把自己归到哪一类，后面筛平台才不会捡了总量丢了限速。

一次性原型验证

只求能跑通、能出结果，总量小、次数少，对限速和时间不敏感

持续小流量跑通

要求额度能按周期恢复、限速别太低，不然第二天就跑不动

短时高压压测

最看每分钟能发多少次请求，总量反而是次要的，撑不住就测不出拐点

除了类别，还要列一张自己的约束表：能不能接受输入数据被平台留存或用于训练、要不要商用授权、是否必须固定地区节点。这三条里任何一条卡住，后面额度再香也白搭。

• 把需求写成一句话：「我要在X周内、用不超过Y次调用、验证Z功能」，写不出来说明还没想清
• 标出绝对不能妥协的一条（通常是数据条款或商用授权），它是硬筛条件
• 把可妥协的放宽，比如延迟、并发、模型新旧，这些后面可以按平台调
• 这一步没做完就去申请，很容易拿到一个额度充足但限速极低的账号，白忙一场

去哪找这些免费入口：三类来源分开看

免费入口大体分三类，三类混着看最容易乱。官方平台的试用额度最稳但门槛也最高，开源托管平台限制少但稳定性看运气，聚合与中转渠道来得快但存活期短。先把来源分类，再决定每类里挑几家。

名单从哪来？先到站内的入口过一遍，再逐家确认免费位。不要凭记忆列，平台隔一段时间就会改规则。

• 到 大模型平台目录：计费与限制（/ai-nav/category/ai-model-platform） 先列出候选名单，看每家计费口径那一栏
• 到 官方 API 价格（/official-api） 核对官方渠道当时的档位与接入方式
• 把候选按上面三类归属标一下，避免把中转渠道当成官方免费位来规划
• 名单先宽后窄，先收十家再砍，比一开始只盯两家要好调

盘一家平台要看的 6 项，缺一项都别下结论

拿到候选名单后，别急着注册。先按下面六项逐家过一遍，能大大减少「申请完才发现不能用」的情况。每一项都记来源，写「官网文档写着」比写「听说」有用得多。

1. 第一步：看额度形式按 token 送、按请求数送、还是按天数开放，形式决定你该拿它干什么。按天开放的适合集中跑，按量送的适合摊开用。
2. 第二步：看有效期一次性送完就过期，还是按周期刷新。前者只能做验证，后者才有机会做长期依赖，这一步直接决定它能不能进你的备选池。
3. 第三步：看限速每分钟请求数和每分钟 token 数通常是分开放的两个指标，两个都要问。只看到总量没看限速，压测时一定踩坑。
4. 第四步：看覆盖模型免费位通常只覆盖小模型或旧档位，确认你要测的那个在不在里面，别测到一半发现主力模型不在免费范围内。
5. 第五步：看结算顺序免费额度用完之后是直接停，还是自动转到付费并扣款。这条最容易出意外，尤其绑了卡之后。
6. 第六步：看授权范围能否商用、输出能否入库、数据是否被用于训练。做原型时无所谓，转生产就是硬门槛。

六项里如果有两项以上是「没查到」或者「文档没说清」，把这家先放一边，等它更新或直接跳过。模棱两可的条款在执行时通常按对你不利的方向解释。

把清单做成一张能决策的表

信息收集完，落到一张表上。表格的价值不在记录，而在帮你做减法：同一行里，只要「必须绑卡」和「用超自动扣费」同时为是，除非你已经准备好付费，否则直接删行。

具体的数值不要凭印象填，也不要在方案里写死。到 价格变动追踪（/price-watch） 看当时的记录，再对照各厂商页确认。表里还可以加一列「适合做什么」，比如仅压测、可做长期原型、只能做兜底，这一列才是你真正要看的结论。

• 先淘汰必须绑卡且用超自动扣费的项，除非你本来就是付费用户
• 再淘汰覆盖模型里没有你要测的那一款的项
• 剩余项里，把「有效期一次性」的单独归到只能做验证那一组
• 最后按「适合做什么」排序，压测、原型、兜底各留一到两家就够

别信说明书：自己跑一轮小探针

文档写的限速和实际触发的限速经常对不上，尤其是免费位。注册完先别写业务代码，花十几分钟跑一轮小探针，把真实行为摸出来，后面省的时间远多于这十几分钟。

1. 连发请求看触发点先发十几次连续请求，记录第几次开始返回限速错误，和文档写的数字对比，用真实的那一个。
2. 跑长文本看计费口径发一段固定长度的长输入，观察是被时长、token 还是请求数卡住，这决定你后面怎么裁输入。
3. 记错误码和重试信息把响应头里带的重试等待时间记下来，这些是写退避逻辑的依据，别等上线了才现编。
4. 量延迟基线用 接口测速：先量出你的延迟基线（/tools/speed-test） 把延迟和成功率记下来，作为是否可用的底线。

探针只用最小可用的调用量，别拿正式任务去试。测完把结果直接填回上面那张表，把「文档值」换成「实测值」。

原型阶段怎么用才不浪费额度

额度到手后，浪费往往不是花在核心功能上，而是花在反复试探和重复提问上。原型阶段的目标是尽快验证，不是把每个可能性都试一遍。下面几个动作都很朴素，但省额度效果明显。

• 把调用集中成少数几个任务，不要一个功能反复试探，免费额度经不起碎请求
• 输入做裁剪：无关上下文、重复指令先删掉，同样一次调用能省下的就是额度
• 缓存固定结果：同一提示反复问的，本地存一份，不要每次都打请求
• 给账号设一个自用的用量记录，参照 真实用量榜（/usage） 的量级估算，防止跑飞
• 把每次调用的目的写一行注释，回头能判断哪次是必要的、哪次可以合并

压测阶段怎么在不烧钱的前提下拿到数据

压测和原型是两种活。原型怕总量不够，压测怕速率上不去。所以压测阶段要盯的是并发和错误率拐点，而不是总共发了多少请求。压测前先把目标写下来，测的是并发上限、限速触发点，还是错误恢复，三个目标测法完全不同。

1. 写清压测目标一行话说明这次要测什么，目标不清的压测跑完也只有一堆数字，得不出结论。
2. 小步阶梯加压从低并发往上阶梯加，每次只加一档，观察错误率拐点出现在哪一档，跳档加压会掩盖拐点。
3. 区分可重试与真失败限速类错误重试有意义，超时和鉴权错误重试就是白费额度，还会把日志搞乱。
4. 结束立刻停脚本压测完马上停掉并记下当时的免费余额，避免脚本跑过夜把额度耗空。

压测结论要写进文档：在什么并发下开始出现限速、恢复需要多久、哪些错误可以重试。这份记录比一次性的吞吐数字更有用，方案评审时也更好讲。

什么情况下这套清单不适用

免费额度不是万能兜底，有些场景用工程手段也兜不住，提前识别比事后补救划算。下面几种情况，建议直接按付费方案规划，别把免费位写进关键路径。

反过来说，内部Demo、技术选型对比、教学演示这几种场景，免费额度非常合适。判断标准就一条：这个调用失败了会不会影响别人。不会，就大胆用免费位；会，就换方案。

额度规则会变，清单要定期重跑

免费额度本质是获客手段，收缩、改条款、下线都很常见。今天能用的清单，过一段时间可能一半失效。所以清单不是一次性产物，得有一个重跑机制，否则你是在用过期信息做决策。

• 给表加一列「上次核对时间」，超过你自己定的周期就标灰，提醒重查
• 关注平台公告和模型目录变化，新上架的模型常带一波短期免费位
• 重点复核三项：有效期、限速、结算顺序，这三项变化最频繁也最影响决策
• 价格与档位随时在动，写进方案前统一到 官方 API 价格（/official-api） 再确认一次

重跑一遍的成本不高，通常半小时内能更新完。但如果你把某家免费位写进了交付方案却没复核，等到执行当天发现限速变了，代价就不是半小时了。

免费额度只解决「先跑起来」，不解决「一直跑下去」，把这两件事分清楚，清单才有用。