Groq 免费额度能跑多少量：逐模型限速表的读法与用量规划

2026-08-07

我第一次带团队接 Groq 的时候，产品经理问的第一句话是「这个免费额度值多少钱」。这句话问出来，后面的估算就已经歪了。

Groq 的免费层不给你一个金额池子。它给的是一张速率表：每分钟允许发多少请求、每天允许发多少请求、每分钟允许消耗多少 token、每天允许消耗多少 token。花不完不会累积，第二天清零重来；花完了也不是「扣光了余额」，而是当前这个计数窗口内被挡住，等窗口滚过去自然放行。

这个认知差是很多人估算翻车的根源。习惯了「注册送 X 元」那一套的人，会拿单价去除额度，算出一个「能跑多久」的数字。但在 Groq 这套口径下，正确的问题是另一个：我这个应用的调用形状——多久发一次、每次吃多少 token——能不能塞进这张表里。关于不同平台的免费额度到底有哪几种形式，我在各家大模型 API 免费额度盘点里做过分类，Groq 属于「限量不限额」的典型代表。

顺带说明：Groq 的层级只有两个，Free Plan 和 Developer Plan。本文只谈前者。

免费层的逐模型限速表

先把表原样摆出来。RPM = 每分钟请求数，RPD = 每天请求数，TPM = 每分钟 token 数，TPD = 每天 token 数。

模型	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	—	—

数值以 Groq 官方限速页为准，会变。上表只包含官方文档里出现过的模型，不代表全部可用模型清单。

四个维度是同时生效的

新手最容易犯的错，是只盯着 RPM 那一列。看到 30 就默认「每秒半个请求，够用了」，然后上线第二个小时就开始吃 429。

官方对这套机制的说明只有一句，但很关键：先撞到哪个阈值，哪个就生效。四个维度是四道并联的闸门，任何一道关上，请求就过不去。所以判断自己有没有余量，要四道全看，而且要看的是最先关上的那道。

把表里两行放在一起对照，差别立刻显出来：

llama-3.1-8b-instant：RPM 30、RPD 14.4K、TPM 6K、TPD 500K
llama-3.3-70b-versatile：RPM 30、RPD 1K、TPM 12K、TPD 100K

每分钟请求数完全一样，都是 30。但每天允许的请求数差了 14 倍多，每天允许的 token 数差 5 倍。如果你只比 RPM，会得出「两个模型免费层待遇一样」的结论，这个结论错得离谱。

更有意思的是 TPM 这一列反过来了：8b 每分钟只给 6K token，70b 反而给 12K。这不是笔误式的怪事，而是两种完全不同的使用节奏——70b 允许你在一分钟内吃下更大的一口，但一天很快就见底；8b 单分钟吃得慢，一整天却能摊出五倍的量。换句话说，8b 适合全天均匀铺开的低频后台任务，70b 适合请求稀疏但单次上下文较长的场景。

所以选模型的时候，「哪个模型更聪明」这个问题的优先级，应该排在「哪个模型的配额形状匹配我的流量形状」后面。前者决定效果好不好，后者决定你能不能上线。

还有两行值得单独点名。两个 orpheus-* 语音模型，RPM 只有 10、RPD 只有 100、TPD 只有 3.6K，这是明明白白的「只够试」档位——够你在开发机上验证一遍链路通不通，够不上任何形式的对外服务。看到这种量级不要幻想优化，直接按「验证完就换方案」来规划。

whisper-large-v3 那一行的 TPM/TPD 是空的，只有 RPM 20 和 RPD 2K。这说明它的约束落在请求数上，你要控的是「一天最多转写多少段音频」，而不是 token。

限速是组织级的，不是用户级的

官方原文里另一句被忽略得更彻底：速率限制适用于组织级别，不适用于个别用户。

这句话翻译成日常场景就是——你的本地开发、CI 流水线、预发环境、线上生产，只要共用同一个组织，就是在抢同一个池子。

这种事故的形态特别难查。CI 上有人推了一次提交，集成测试跑起来密集打了几十个请求，与此同时线上用户开始收到 429。你去翻生产日志，看到的是「毫无征兆的限流」；你去翻 CI 日志，看到的是「测试全绿」。两边的时间线要人工对齐才能发现关系，而多数人第一反应是怀疑 Groq 侧抖动。我见过团队为此花两天排查网络，最后发现罪魁祸首是一个每十分钟触发一次的定时任务。

几条我认为必须做的隔离动作：

环境拆组织，而不是拆 key。 同一组织下签发多把 key 是没用的，配额算在组织头上。要真正隔开，就得让 CI 和生产落在不同的组织下。

给 CI 加闸。 集成测试里对模型的调用要串行化或者限流，最好直接给测试打上开关，默认走 mock，只在需要时才真打上游。测试的价值在于验证调用链路的形状，不在于反复消耗真实配额。

在自己这一侧打环境标签。 Groq 的 OpenAI 兼容实现明确不支持 messages[].name 这个字段，所以别指望靠请求体里塞标识来事后归因。可行的做法是在自己的客户端封装里记录每次调用的环境、模型、请求 token 估算和响应状态码，429 发生时至少能立刻回答「这一分钟里，谁在打」。

盘一遍隐性调用方。 定时任务、健康检查、预热脚本、他人本地跑的调试脚本，这些平时没人算进流量模型，但它们照样占配额。

用除法反推「能撑什么样的应用」

这张表最实用的用法，是拿它做一次除法，把速率配额换算成「每天能服务多少次调用」。

方法很简单：用 TPD 除以单次请求的平均 token 数（输入加输出合计），得到每天大致能发多少次；再用 TPM 除以同一个数，得到每分钟大致能发多少次。然后把这两个结果分别和 RPD、RPM 比较，取更小的那个，那就是真正卡住你的闸门。

举个纯算术的例子。假设你测下来平均每次请求输入加输出合计约 2500 token（这个数只是演算用的假设，你必须换成自己实测的值）：

llama-3.3-70b-versatile：TPD 100K ÷ 2500 ≈ 40 次/天；TPM 12K ÷ 2500 ≈ 4.8 次/分钟。RPD 是 1K、RPM 是 30，都远在这两个数之上，所以卡你的是 token 维度，不是请求数维度。结论：一天大约四十次这种规格的对话。
llama-3.1-8b-instant：TPD 500K ÷ 2500 = 200 次/天；TPM 6K ÷ 2500 = 2.4 次/分钟。RPD 14.4K 在这里基本是摆设。
gpt-oss-120b / gpt-oss-20b / qwen3.6-27b：TPD 200K ÷ 2500 = 80 次/天。

还可以反过来算一个「交叉点」，看看请求数配额什么时候才有可能先撞上。对 70b，TPD 100K ÷ RPD 1K = 100，意味着只有当平均每次请求不到 100 token 时，RPD 才会成为先撞的那道闸；对 8b，500K ÷ 14.4K ≈ 35 token。真实的对话请求几乎不可能这么短，所以对这几个模型来说，TPD 才是你要天天盯的那个数，RPD 只是个安全带。

两点提醒，别把这个除法用歪了。

第一，算出来的是上限，不是保证。它假设你的流量完美均匀，而真实流量永远是尖的。一个白天八小时集中使用的应用，哪怕日总量只用掉配额的一半，也完全可能在某几分钟内把 TPM 顶穿。做容量规划时，我习惯按峰值分钟去校验 TPM，按日总量去校验 TPD，两条线分开看。

第二，平均 token 数这个输入值必须实测。凭感觉估的 token 数误差可以到两三倍，算出来的结论就毫无意义。怎么把 token 用量估准，我在大模型 API 成本估算方法里写过更细的做法，那套方法用在这里同样成立——只不过这次除的不是钱，是配额。

撞限之后：429 的正确读法

撞到任何一道闸门，你收到的都是 429 Too Many Requests。响应体是 JSON，里面有个 error 对象，包含 message（描述文本）和 type（分类）两个字段。

429 本身不是故障，它是这套机制正常工作的表现。真正的故障是你对 429 的处理方式。

最常见的错误是失败即立刻重试。 你已经撞上闸门了，立刻再发一次只会再撞一次，而这次重试本身也在计数。请求密集的服务里，这会迅速演变成一个自我加速的死循环：越限流越重试，越重试越限流，直到把整个窗口都填满失败请求。

正确做法是指数退避加抖动：第一次失败等一个基础间隔，之后每次把间隔翻倍，并且在间隔上叠加一个随机扰动。抖动这一步很多人会省，但它恰恰是关键——没有抖动的话，多个并发 worker 会同时醒来、同时重发，第二轮照样集体撞墙。同时必须设最大重试次数和总耗时上限，超了就干脆失败并向上抛，别让一个请求在重试链里挂几分钟。关于 429 的完整处理姿势，429 报错的排查与处理讲得更全。另外提醒一句，重试和超时是一对，别只设了重试次数却没设单次请求超时，否则退避链条会被一个卡死的连接整个拖住。

另外分清楚 429 和别的错误码。5xx 是服务端问题，Groq 明确说明 5xx 响应不计费，这类错误重试是合理的；400、422 这种是你的请求本身有问题，重试一百次也还是错，应该直接失败。把这两类混在同一套重试逻辑里，是我在代码审查里见得最多的问题之一。

什么时候该考虑升级到 Developer Plan？ 我的判断标准是三条里中了任意一条：一是你的峰值分钟已经稳定顶到 TPM，靠排队削峰会让用户等到不可接受；二是日用量已经逼近 TPD，而业务还在增长；三是你需要多个环境真正互不干扰，而免费层的组织级配额让隔离成本变得比升级还高。反过来，如果只是偶发撞限、退避后能自然消化，那说明配额够用，缺的是流量整形——先把并发控制做好，往往比升级更划算，这块可以参考并发控制与限流实践。

免费层规划自查清单

上线前我会拿这几条过一遍：

实测平均 token 数，别用估的。输入输出分开统计，长尾请求单独看。
对目标模型做完四个维度的除法，明确写下来「我的瓶颈是 TPM 还是 TPD」，团队里每个人都要知道这个答案。
按峰值分钟校验 TPM，按日总量校验 TPD，两条线分开算，不要用日均去推分钟。
确认开发、CI、生产是不是同一个组织。如果是，要么拆开，要么给 CI 加闸并接受相互影响。
清点所有隐性调用方：定时任务、健康检查、预热脚本、本地调试，一个都别漏。
重试逻辑必须有指数退避、抖动、最大次数和总超时，并且区分「该重试的错误」和「重试也没用的错误」。
给 429 打点，至少记录时间、模型、环境。撞限时能立刻回答「谁在打」，比任何事后分析都有价值。

最后强调一次：表里的数字会变，Groq 随时可能调整免费层配额，一切以官方限速页为准。真正长期有效的不是这几个数，而是「四道闸门同时生效、取最先撞上的那道」这个读表方法，以及那条从 TPD 出发的除法。数字换了，方法照用。