免费额度怎么用才够：别省着用，把它花在买信息上

2026-08-07

我遇到过好几个团队是这么用免费额度的：拿到 key 之后小心翼翼，一天只敢跑几条，生怕”用完了就没了”。两个月后我再问结论，得到的回答是”还在测”——测了什么说不清，单次任务花多少 token 不知道，格式失败率没统计过，只留下一句”感觉还行”。额度这时候要么过期了，要么还剩大半，但两种情况的结果一样：这段试用期没有产出任何能拿去做决策的东西。

免费额度的价值不在于省了那点钱。真正决定你后面几个月账单的，是”选哪个模型、每个任务要花多少 token、能不能达到验收标准”这几个问题的答案。免费额度是你在还没掏钱的时候唯一能拿到这些答案的窗口。所以正确的用法跟直觉相反：尽快把它花掉，花在能减少不确定性的事情上。 省下来的额度一分钱价值都没有，换来的答案才有。

一、先分清你手上的是哪一种免费额度

“免费额度”这个词被混着用了，实际上是两种完全不同的东西，规划方式也完全不同。

第一种是赠送金额。平台给你一笔可消费的余额，按正常价格从里面扣，扣完为止，通常还带一个到期日。它的关键变量是两个：总量和截止日。规划方式是做除法——设额度为 X，你单位任务的实际成本为 c，有效期还剩 D 天，那么这笔额度总共够跑 X / c 次任务；如果你想在到期前把它用完，每天至少要跑 X / (c × D) 次。这个式子的意义在于：只要你算过一次，就会发现”省着用”根本用不完，绝大多数人到期时剩下的额度都是白扔的。

这里有个先有鸡还是先有蛋的问题：c 你一开始并不知道。所以赠送金额型额度的第一件事永远是先跑几十条真实任务，把单位成本量出来，再回头算 X/c。怎么量、按什么口径折算，可以配合 token 成本估算方法一起做。

第二种是速率配额。平台不给你钱，而是给你一组”每分钟/每天最多能做多少”的上限，免费用但跑不快。它没有”总量花完”这回事，却有”今天到顶了、明天重置”这回事。规划方式不是除法算总量，而是算每天能跑多少次，以及跑完需要多少时间。

分不清这两者会导致很典型的误判：拿速率配额型的平台去做”额度够不够”的规划，或者拿赠送金额型的平台去做”每分钟能并发几路”的规划，两边都会得出没用的结论。

顺带一提，各家究竟给不给赠送额度、给多少、有没有有效期，是会变的，而且很多平台压根不公开写。这类信息以你自己控制台里看到的为准，别信任何二手盘点（包括我这篇）。想看更早的一版横向梳理可以参考各家免费额度盘点，但同样请以官方页面为准。

二、速率配额怎么读：以 Groq 免费层为例

速率配额型额度里，把限速表逐模型公开的平台不多。Groq 是公开的，下面这张是它官方文档限速页上的免费层（Free Plan）原表，核对日期 2026-08-07，以 Groq 官方限速页为准（https://console.groq.com/docs/rate-limits）：

模型	RPM	RPD	TPM	TPD
orpheus-arabic-saudi	10	100	1.2K	3.6K
orpheus-v1-english	10	100	1.2K	3.6K
llama-3.1-8b-instant	30	14.4K	6K	500K
llama-3.3-70b-versatile	30	1K	12K	100K
gpt-oss-120b	30	1K	8K	200K
gpt-oss-20b	30	1K	8K	200K
qwen3.6-27b	30	1K	8K	200K
whisper-large-v3	20	2K	—	—

官方还有两句说明特别重要：速率限制适用于组织级别，不适用于个别用户；以及先撞到哪个阈值，哪个就生效。

第一句意味着，你和同事共用一个组织的 key，配额是共享的——你在本地跑评测的时候同事那边的脚本也在消耗同一份 RPM。这是免费层最常见的”我明明没跑多少怎么就被限了”的来源。

第二句是读这张表的关键。RPM（每分钟请求数）、RPD（每天请求数）、TPM（每分钟 token 数）、TPD（每天 token 数）这四个维度是同时生效的，不是取最宽松的那个，而是取最早撞上的那个。

用 TPD 反推每天能跑多少次调用

假设一个具体场景（以下 token 数量均为假设值，用来做算术演示，你自己的数值必须实测）：某个任务单次调用大约输入 1200 token、输出 300 token，合计 1500 token。按上表算：

llama-3.3-70b-versatile：TPD 100K ÷ 1500 ≈ 66 次/天。而 RPD 是 1K（1000 次），远远撞不到——先到顶的是 token 数，不是请求数。分钟维度上，TPM 12K ÷ 1500 = 8 次/分钟，RPM 30 同样撞不到。也就是说，你以 8 次/分钟的节奏跑，大约 8 分多钟就把一整天的配额用光了。
gpt-oss-120b：TPD 200K ÷ 1500 ≈ 133 次/天；TPM 8K ÷ 1500 ≈ 5 次/分钟。约 27 分钟跑完一天的量。
llama-3.1-8b-instant：TPD 500K ÷ 1500 ≈ 333 次/天；TPM 6K ÷ 1500 = 4 次/分钟。约 83 分钟跑完一天的量。

注意 8b-instant 这一行很有意思：它的 TPM 反而比 70b 更低（6K vs 12K），但 TPD 高出五倍（500K vs 100K）。它慢，但一天能跑的总量多。 这直接决定了你该用哪个模型跑批量评测——如果评测集大，8b-instant 的日额度更适合承载；如果是要验证大模型效果，就得接受一天只能跑几十条的现实，或者把评测拆成几天。

哪个维度先撞，取决于你的单次 token 量

同一行的四个数字之间存在一个分水岭，用除法就能求出来：

分钟维度的分水岭 = TPM ÷ RPM。单次 token 低于它，先撞 RPM；高于它，先撞 TPM。
- llama-3.1-8b-instant：6000 ÷ 30 = 200 token
- llama-3.3-70b-versatile：12000 ÷ 30 = 400 token
- gpt-oss-120b / gpt-oss-20b / qwen3.6-27b：8000 ÷ 30 ≈ 267 token
天维度的分水岭 = TPD ÷ RPD。
- llama-3.3-70b-versatile：100000 ÷ 1000 = 100 token
- gpt-oss-120b / gpt-oss-20b / qwen3.6-27b：200000 ÷ 1000 = 200 token
- llama-3.1-8b-instant：500000 ÷ 14400 ≈ 35 token

真实的对话或抽取任务，单次很难低于几百 token，所以在天维度上几乎必然是 TPD 先撞顶，RPD 那一列基本用不上。这解释了一个常见困惑：“我今天才发了两百多个请求，RPD 明明是 1K，怎么就 429 了？“——因为它比的不是请求数，是 token 数。撞限后的错误码识别与退避重试怎么写，见 429 与限速类错误的处理。

whisper-large-v3 那一行是另一类情况：只给了 RPM 20 和 RPD 2K，TPM/TPD 为空。音频类任务的计量口径本来就跟文本不同，别硬套 token 公式。

三、免费额度该用来买哪些信息（按优先级）

这是本文的核心。免费额度是有限的，先花在哪里决定了它的回报。我按重要性从高到低排：

1. 效果是否达到你的验收标准

这条压倒一切。如果模型做不到你要的效果，后面所有的成本、限速、延迟讨论都没有意义。

怎么用最少的额度测出来：先手工挑 20 到 30 条最难的样本——不是随机抽，是专门挑你业务里最容易出错的那一类（长文本、含表格、多轮指代、边界情况）。难样本上过不了关的模型，简单样本上表现再好也没用。这一步的目的不是给出准确率数字，而是快速淘汰。按前面的算术，30 条 × 1500 token = 45,000 token，即使在 TPD 100K 的模型上也只占不到一半的日额度，一个下午就能筛掉一批候选。

淘汰之后再上完整评测集。这时候样本量才需要往上堆。

2. 你的单位任务 token 消耗

这是性价比最高的一个数字，因为它换平台不变。模型价格会调、免费政策会改、平台会换，但”我这个任务平均要花 1200 输入 + 300 输出”这个结论，只要提示词和任务不变，拿到哪个平台都能直接用来估算成本。

怎么用最少的额度测出来：从响应体里读用量字段，别自己数字符。跑 50 到 100 条覆盖典型长度分布的真实样本，记录每条的输入 token、输出 token，然后算中位数和 90 分位，别只算平均值——长尾样本才是账单和限速的真正来源。有了这个分布，你就能同时做三件事：算成本、按上面的公式反推每天能跑多少、以及做并发规划（参见并发与吞吐规划）。

3. 格式稳定性与失败率

模型”大体上能做对”和”能稳定输出可解析的结构”是两回事。JSON 少个括号、字段名飘了、多包一层 markdown 代码块，在生产里都是要人工兜底的成本。

怎么用最少的额度测出来：把结构化输出的解析器提前写好，评测时直接跑解析，统计”解析失败率”和”字段缺失率”两个数。这不需要额外调用——你跑效果评测的那批响应，顺手统计一遍就有了。把失败的原始响应存下来，它们后面写重试和修复逻辑时是直接可用的素材。

4. 撞限时的真实表现

限速表告诉你阈值在哪，但没告诉你撞上去之后是什么体验：返回什么错误码、错误体长什么样、多久能恢复、是硬拒绝还是排队。这些只有撞一次才知道。

怎么用最少的额度测出来：这一项恰恰是”故意浪费额度”最划算的地方。挑一个便宜的小模型、用最短的提示词，故意在一分钟内打满 RPM，把返回的状态码和响应体原样记录下来。短提示词意味着这次实验消耗的 token 极少，但换来的信息（错误码长什么样、你的重试逻辑会不会死循环）价值很高。Groq 的错误码里除了常规的 429，还有 498、499 这类自定义码，具体含义以官方错误码文档为准——重点是你的客户端要能认得出它们、而不是当成未知错误崩掉。

5. 国内可达性与延迟的量级

海外平台从国内直连的可达性和稳定性，是很多方案最后卡住的地方。

怎么用最少的额度测出来：可达性这件事甚至不需要消耗多少额度——用最短的请求（几十个 token）在不同时段打几十次，记录成功率和往返耗时的分布就够了。你要的不是精确毫秒数，而是量级判断：是”几百毫秒可用”、“两三秒勉强”、还是”经常连不上”。注意在你实际部署的网络环境里测，本地开发机的结果不能代表服务器机房。

四、免费额度上别做的三件事

别把免费额度用于生产流量。 免费层限速是组织级共享的，一旦线上有真实用户，你的评测脚本、同事的调试、线上请求会互相抢配额，然后在你最不希望的时候一起 429。更麻烦的是免费层的服务承诺通常与付费层不同，出问题时你没有任何依据去要说法。免费额度只用于评测和验证，生产从第一天就走付费通道。

别按免费层的限速做容量规划然后直接上线。 这是我见过后果最严重的一种。免费层的 RPM/TPM 跟付费层完全是两套数字，你在免费层上”跑通了 8 次/分钟”，不代表付费后就是这个数，更不代表这个数够你的业务用。容量规划必须基于你打算实际使用的那一档的限速，而那一档的数值要去官方限速页确认。

别为了省额度而缩小评测样本。 用 10 条样本得出的”准确率 90%“，换一批 10 条可能就是 60%，这个结论不足以支撑任何决策。样本太小的评测不是”省了额度”，是”额度白花了”——你付出了调用，却没换回可信的信息。真要压缩，压缩的方向是减少候选模型数量（先用难样本快速淘汰）、缩短提示词的冗余部分，而不是砍样本量。

五、额度到期前的检查清单

不管是赠送金额到期还是你决定结束试用，收尾这一步决定了这段时间的产出能不能留下来：

该测的全部测完，尤其是排在前面的效果验收和单位 token 消耗，别留到最后一天。
数据落盘：单位 token 消耗的分布（中位数 / 90 分位）、解析失败率、失败样本原文、错误码样本、延迟分布。这些数字写进文档，不要只留在某次终端输出里。
评测集本身要留下来，而且要整理成可复用的形式：输入、期望输出、评分脚本三件套。下次换平台、换模型版本，直接重跑就有结论，不用从头再来一遍。
把这一轮的结论写成一句能拿去做决策的话，比如”任务 A 用中等尺寸模型可以过验收，单次约 1500 token，格式失败率在可接受范围”。写不出这句话，说明前面漏测了东西。

有了这套数据，后面按成本挑模型就是查表的事，不用再凭感觉，具体的比较方法见按成本选模型。

六、同时试用多个平台时的组织方法

试用不止一家的时候，最容易出的错是每家用不一样的输入、不一样的判断标准、结果记在不一样的地方，最后得到一堆彼此没法比较的印象：“A 感觉聪明一点""B 好像快些”。这种印象在开会的时候撑不过三个追问。

要让多平台试用产出可比的结论，需要固定三样东西：

同一批输入。 冻结一个评测集，所有平台跑完全相同的样本、完全相同的提示词。提示词只要为某家做了适配调整，那一家的结果就不能再和别家横向比——真要做适配对比，就把”通用提示词”和”适配提示词”当作两个独立条目分别记录。

同一套验收标准。 评分规则先写死再开跑，别一边看结果一边调标准，那样只会得出”我最想选的那家最好”。有主观判断的项（比如文风），至少固定成一个 1 到 5 的打分表，并且同一个人打完所有平台。

同一张记录表。 每次调用至少记这几列：平台、模型 ID、样本 ID、输入 token、输出 token、耗时、状态码、是否解析成功、评分。有了这张表，所有结论都是它的聚合，任何人都可以复算。反过来说，如果一个结论没法从表里查出来，那它就只是印象。

还有个实操细节：不同平台的模型 ID 命名风格不一样，有的是扁平名，有的是”组织/模型名”的写法，记录表里一律存原始 ID 字符串，别自己简化，否则过两周你会分不清当时到底跑的是哪个。

自查清单

你手上的额度是赠送金额（算总量和到期日）还是速率配额（算每天能跑多少），分清了吗？
如果是赠送金额，用 X / (c × D) 算过每天至少要跑多少次才用得完吗？
如果是速率配额，用官方限速页的 TPD 除以你的单次 token 量，反推过每天能跑多少次吗？知道 RPM/RPD/TPM/TPD 是同时生效、先撞先算吗？
单位任务的 token 消耗量出来了吗？记的是中位数和 90 分位，还是只有一个平均值？
最难的那 20 到 30 条样本先跑了吗，还是把额度花在了简单样本上？
故意撞过一次限速、把错误码和响应体记下来了吗？客户端能认出这些码而不是直接崩？
评测集、评分脚本、记录表是不是已经整理成下次能直接重跑的形式？
有没有把免费层的限速数字当成上线后的容量依据？（如果有，重新按你实际要用的那一档核算。）

最后重复一遍那个反直觉的判断：免费额度不是用来省钱的，是用来买信息的。 到期时额度剩得越多，通常说明这段试用越失败。