Groq 怎么收费：拿不到官方单价表时，如何把这家的成本算清楚
先说清楚这篇文章不干什么：它不会告诉你 Groq 某个模型每百万 token 多少钱。
不是我懒得查。是查了之后发现官方定价页当下拿不到可靠数字，而网上流传的说法互相打架——同一个模型，不同的对比表能给出差好几倍的价格，还都言之凿凿写着”官方价”。我见过太多团队照着二手表做预算，上线一对账差了一个量级，回头怪平台涨价——平台没涨，是那张表从抄下来的第一天就是错的。
所以这篇只写一件事：在拿不到官方单价的前提下，怎么把这家的成本算到可用的程度。 这件事能做，而且比一张价格表更耐用，因为数字每季度都在动，机制很少动：计费按 token 还是按请求、哪些响应不收钱、限速卡在哪一层，一旦定下来几年不变；而单价花三十秒去官网一查就有。真正需要提前想明白的从来不是单价，是”我这套业务一天要吃掉多少 token”。
一、能确证的计费机制，就这么几条
以下每一条都来自 Groq 官方文档，没有一条是推断的。
按 token 计费。 不是按请求次数，不是按时长。这意味着控制成本的抓手在上下文长度和输出长度上，不在调用频次上——把 100 次请求合并成 10 次批量请求，token 总量不会变少，账单基本不动。输入和输出为什么要分开计价讲过这两段 token 的性质差异，这里不重复。
层级只有两档：Free Plan 和 Developer Plan。 没有企业版、专业版这种五花八门的分层。这对决策是好事——不需要研究一张五列的套餐对比表，只需回答一个问题：免费层够不够，不够就升。
5xx 响应不计费。 官方明确写了：500 Internal Server Error、502 Bad Gateway、503 Service Unavailable 这些服务端故障，不产生费用。这条直接改写你的重试策略，值得单独展开。
二、“5xx 不计费”如何改写你的重试逻辑
大部分团队的重试代码是一刀切的：捕获异常、退避、重试三次。在计费口径不同的错误码面前，这种写法要么在赔钱，要么在白白放弃可用性。
把 Groq 官方错误码清单按”重试划不划算”重新分组：
| 错误码 | 官方含义 | 重试有没有意义 | 计费口径 |
|---|---|---|---|
| 500 / 502 / 503 | 服务端错误、网关错误、维护或过载 | 有，值得积极重试 | 官方明确不计费 |
| 429 | Too Many Requests | 有，但必须退避 | 官方未作不计费声明 |
| 498 | Flex Tier 容量超限（自定义码） | 有，但要换策略而非硬重试 | 官方未作不计费声明 |
| 400 | 语法非法 | 没有，重试一万次还是错 | 官方未作不计费声明 |
| 422 | 格式合法但语义错误 | 没有，属于代码 bug | 官方未作不计费声明 |
| 401 / 403 | 凭据缺失无效 / 权限不足 | 没有，属于配置问题 | 官方未作不计费声明 |
| 413 | 请求体过大 | 没有，得先裁上下文 | 官方未作不计费声明 |
| 499 | 调用方取消请求（自定义码） | 看你为什么取消 | 官方未作说明 |
注意第四列的措辞。 官方只对 5xx 明确写了”不计费”，对其余各类都没有同样的表述。这不等于它们一定计费，但做成本模型时你不能默认它们免费，最终以自己的账单为准。这种地方我宁可保守：把不确定的都当成会花钱，算出来偏悲观，总比乐观完了超支强。
由此得到几条实操结论：
对 5xx 可以放心加大重试力度，它只花时间和连接数，不花钱。以前担心”重试会不会把成本翻倍”而把 5xx 重试次数压得很低的，可以放开一些——仍然要带指数退避，别把已经过载的服务端再踩一脚。
对 400/422 这类语法语义错误，一次都不要重试。 这是你自己代码的问题，重试是纯粹的浪费：每次都可能算钱，结果永远不变。正确做法是直接扔进死信队列并附上原始请求体。我见过一个把 422 混进通用重试分支的项目，一个字段名拼错，靠重试机制在夜里安静地烧了一整晚。
对 429 要退避，不能靠加重试次数硬扛。 429 到底该怎么处理讲了退避与并发控制的写法，这里只强调成本视角：每一次重试都是一次可能计费的调用，重试次数是成本模型里一个真实的乘数，别估算时把它当零。
499 要特别小心。 它表示调用方取消了请求，通常是客户端超时或用户关掉页面。而取消发生时服务端可能已经生成了一部分内容，这部分算不算用量官方没有说明。如果你的前端做了”随时中止”的流式交互，别默认取消等于免费。
三、Flex Tier：只能确认它存在
官方错误码清单里有一个 498，含义写得很明确：Flex Tier 容量超限。
一个平台不会为不存在的东西定义专属错误码。所以可以确证：Groq 存在一个叫 Flex Tier 的服务档位，它有容量上限，超了返回 498。
能确证的到此为止。它的价格、配额怎么算、和 Free/Developer 两档什么关系、要不要单独开通——这些我一个都没核实到，一个字都不写，以 Groq 官网和控制台为准。
单独列出来是因为它在工程上有直接用处：如果你的代码没有 498 分支，一旦触发就会掉进”未知 4xx”兜底逻辑里，而大多数人对未知 4xx 的处理是”不重试、直接失败”——对一个容量类临时错误来说这是错的，它的性质更接近 429。至少先给 498 加一个分支，哪怕里面只打一条明确的日志。 不知道它是什么不要紧，知道它出现了、能被认出来，就比一片空白强很多。
四、用限速表反推：免费层的成本天花板是多少
这是本文最有用的一节。
Groq 免费层的逐模型限速是公开的，官方原表如下（以官方限速页为准，这些数字会变）：
| 模型 | 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 | — | — |
先看一个几乎所有人都会忽略的推论：TPD 是一天能吃掉的 token 上限。既然计费按 token，那么免费层的成本天花板是可以精确算出来的——它等于零。
这句话听着像废话，其实是个很硬的工程结论：只要用量压在这张表里面，你的成本风险是零——不是”很小”，是零。不需要设预算告警，不需要担心某个死循环把账单打穿。所以对内部工具、演示环境、低频后台任务这类场景，“把用量压进免费层”是一个比”找便宜单价”回报高得多的优化方向。
第二个推论：这张表上真正卡住你的往往不是 RPM，而是 TPM。
拿 llama-3.3-70b-versatile 算一下。假设每次请求平均消耗 2900 token（输入加输出，后面讲这个数怎么来）：
- 名义 RPM 是 30，但 TPM 只有 12K。12000 ÷ 2900 ≈ 4.1，你实际每分钟只能发约 4 次请求，名义 RPM 的 30 你根本摸不到。
- 名义 RPD 是 1K，但 TPD 只有 100K。100000 ÷ 2900 ≈ 34，你一天实际只能发约 34 次请求，离 1000 次差得远。
llama-3.1-8b-instant 更夸张：RPD 标着 14.4K 看起来很慷慨，但 TPD 是 500K，500000 ÷ 2900 ≈ 172——一天约 172 次。RPM 标 30，TPM 只有 6K，6000 ÷ 2900 ≈ 2.1，每分钟约 2 次。
这就是官方那句”先撞到哪个阈值，哪个就生效”的实际后果。很多人看限速表只看 RPM/RPD，觉得额度充裕，一跑就狂吃 429，还以为是平台不稳。不是平台的问题，是你拿请求数当限速单位，而平台拿 token 当单位。
顺带一句：whisper-large-v3 那行的 TPM/TPD 是”—“。这不等于没有限制，只是这张表在这个口径上没给数——音频类接口的计量方式和文本不同，具体限制以官方文档为准，别当成无限用。
五、超出免费层之后：完整的算术模板
免费层压不住，就要算真金白银了。算法只有四步，最后一步才需要单价——而单价你去官网查一次就有。
第一步：估算单次请求的平均输入/输出 token。 把一次业务操作拆开数：
输入 token = 系统提示 + few-shot 示例 + 检索上下文 + 对话历史 + 用户本轮输入
输出 token = 模型本轮生成的长度
第二步：单次总量 = 平均输入 + 平均输出。
第三步：日 token 量 = 单次总量 × 日调用次数；月量 = 日量 × 30。
第四步：月费用 = (月输入 token ÷ 1,000,000) × 输入单价 + (月输出 token ÷ 1,000,000) × 输出单价。
单价这格留空，填你在 Groq 官方定价页查到的当次单价，并在成本文档里记下查询日期，下季度复核。
下面是填了假设数字的示例。这些数字全部是为演示编的假设值，不是任何平台的实测值。 假设一个内部知识库问答，每次请求：
| 组成 | 假设 token |
|---|---|
| 系统提示 | 600 |
| 检索召回的上下文 | 1800 |
| 用户本轮问题 | 100 |
| 输入小计 | 2500 |
| 模型回答 | 400 |
| 单次总计 | 2900 |
日调用量假设 4000 次：
- 日输入 = 2500 × 4000 = 10,000,000 token（1000 万）
- 日输出 = 400 × 4000 = 1,600,000 token（160 万）
- 日合计 = 11,600,000 token（1160 万）
- 月输入 = 10,000,000 × 30 = 300,000,000 token（3 亿）
- 月输出 = 1,600,000 × 30 = 48,000,000 token（4800 万）
换算成计价单位（每百万 token）：
- 月输入 = 300,000,000 ÷ 1,000,000 = 300 个计价单位
- 月输出 = 48,000,000 ÷ 1,000,000 = 48 个计价单位
于是：
月费用 = 300 × (官网查到的输入单价) + 48 × (官网查到的输出单价)
去官网抄两个数填进去，五秒钟的事。难的从来不是这一步，是前面那个 2900。
回头对一下免费层：这个场景日需 1160 万 token，而 llama-3.3-70b-versatile 的 TPD 是 100K（10 万），差了两个数量级，免费层完全不可能覆盖，这类场景一开始就该按付费层做预算。反过来，若算出日用量是几万 token 级别，就值得花力气压一压，压进免费层就是彻底的零成本。上线前怎么估算月成本有更完整的场景拆分方式。
六、组织级限速：一个被严重低估的成本变量
官方原文写得很清楚：速率限制适用于组织级别，不适用于个别用户。
实际含义是：开发环境、CI 流水线、预发环境、线上服务，只要挂在同一个组织下就是在抢同一个池子。叠加上”先撞哪个阈值哪个生效”，后果就是——CI 跑一轮集成测试把当天 TPD 吃掉大半，线上服务下午开始持续 429，而看监控的人只会看到”线上突然不稳定了”，完全联想不到是早上那次流水线干的。这类事故排查成本极高，因为限速是组织级的，你在单个服务的指标里看不出任何异常。
成本侧的连锁反应更隐蔽：撞限 → 重试 → 重试的调用也可能计费。除了 5xx 明确不计费，其余重试都要按会花钱来算。一个没做退避、只会死循环重试的批处理任务，能在不产出任何业务价值的情况下持续消耗额度。
几条能落地的做法：
环境隔离优先做在账号/组织层面。 如果平台支持开多个组织或项目来隔离额度，那是最干净的方案——是否支持、怎么开以控制台为准。开不了就退而求其次在客户端侧做配额分配：给 CI 一个本地令牌桶，硬性限制它每天最多发多少 token，用完跳过而不是排队。
批处理挪到业务低谷。 TPD 按天算，而线上流量有明显波峰波谷，把离线任务放到夜里，本质是在同一个 TPD 额度里做时间错峰。
调用方标记只能打在自己这边。 一个坑：Groq 官方明确列出 messages[].name 是不支持的参数。你如果习惯用 name 字段标记”这条请求来自哪个服务”，这里行不通，标记必须打在自己的日志和网关层——请求发出前记一条带服务名、环境名、trace id 的日志，出问题时靠日志聚合定位是谁吃掉了额度。顺带记住另外几个官方明示不支持的：logprobs、logit_bias、top_logprobs，以及 N 传值必须等于 1。还有一个容易翻车的隐式行为：temperature 传 0 会被转换成 1e-8，如果你的复现逻辑依赖”温度严格为 0”，实际行为和预期不一样。
给限速加监控，而不只是给账单加监控。 429 的数量是先行指标，账单是滞后指标，等账单异常再查已经烧了一个月。
七、真正该建的资产：你自己的单位成本
前面那个 2900，是整篇文章里唯一需要你自己动手的数字，也是唯一换平台时不会失效的数字。
价格表会过期，限速表会调整，模型会下架。但”我这个业务每完成一次操作平均要烧多少 token”是你自己业务的属性，跟平台无关。有了这个数，换到任何一家平台都只需查两个单价做一次乘法；没有这个数，你在每家平台面前都要重新抓瞎一遍。
怎么建，一个下午就够：
选一批真实任务，不要用测试样本。 测试样本几乎总是偏短、偏规整、偏理想，用它算出的单位成本系统性偏低。去线上日志里捞真实请求，或找几个真实用户的会话记录，样本量不少于 100~200 次——少于这个数，上下文特别长的长尾请求不会出现在样本里，而恰恰是长尾在推高均值。
逐次记录实际用量。 优先读响应体里返回的用量统计字段（字段名以官方文档为准），这是平台自己的计量口径，和账单一致，最可信。拿不到再退回本地估算，但要清楚本地 tokenizer 和平台口径可能不一致，偏差在长文本上会被放大。关于 token 怎么切出来的，token 是什么讲得比较细。
别只看均值，看分布。 记下 P50、P90、P99：P50 做常态预算，P90 做容量规划，P99 判断会不会撞 413（请求体过大）。只看均值的成本模型，在有长尾的业务上一定偏乐观。
按业务操作归一，不是按 API 调用归一。 如果”一次问答”实际触发了三次模型调用（改写 query、召回重排、最终生成），单位成本要算这三次的总和。按 API 调用算的数好看，但和业务量对不上，做预算没法用。最后把它写进文档并标上测算日期和样本来源——它会随提示词和检索策略变，是需要定期复核的活数字。
建好之后优化就有了标尺：系统提示压缩 200 token，能直接换算成月度省下多少个计价单位；召回从 5 段减到 3 段，效果掉多少、成本省多少可以放在同一张表上比。没有单位成本时，这类优化只能靠感觉。
成本自查清单
- 确认没有在用任何二手价格表——单价一律去官方定价页现查，文档里记下查询日期。
- 重试逻辑按错误码分组：5xx 积极重试（官方明确不计费）；429/498 退避后重试；400/422/401/403/413 一次都不重试，直接进死信队列。
- 给 498（Flex Tier 容量超限）单独加处理分支，别让它掉进”未知 4xx 直接失败”的兜底里。
- 算一遍免费层能不能覆盖用量——用 TPM/TPD 除以单次 token 量，而不是看 RPM/RPD，两者常常差一到两个数量级。
- 检查开发、CI、预发、线上是否共用一个组织的额度；能隔离就隔离，不能就在客户端侧给非线上环境设硬性配额。
- 跑 100~200 次真实任务算出”每次业务操作的平均 token”，记录 P50/P90/P99，写进文档定期复核。
- 把 429 计数做成监控告警项——它是成本异常的先行指标，账单是滞后指标。
最后重复开头那句：这篇没给你单价，是故意的。机制给全了，算术模板给全了，剩下最后一格数字你花三十秒去官网填上，这个成本模型就是准的；下季度改价时也只需要改那一格。