这类问题我又碰上了一次。用 groq 0.11 的 Python SDK 调 llama-3.3-70b,控制台里 RPM 只用了 14,接口却一直返回 429,原文 rate_limit_exceeded,响应头 x-ratelimit-remaining-tokens 已经是 0,账号 TPM 档位写着 12000。换过 key、重启过脚本,现象都一样。

第一反应是「本地开了 8 个线程并发发送,瞬时速率被合并计算」,验证下来不成立。

原因不止一个,得分开看。限流按每分钟 token 总量算,两条长 prompt 就能把 TPM 吃满;请求里的 max_tokens 会预占额度,填 4096 等于先扣掉 4096;同组织下另一个项目也在打同一个模型,额度池是共享的。

第一件事是读响应头确认卡的是 rpm 还是 tpm

curl -i https://api.groq.com/openai/v1/chat/completions -H "Authorization: Bearer $GROQ_API_KEY" -H "Content-Type: application/json" -d '{"model":"llama-3.3-70b-versatile","messages":[{"role":"user","content":"hi"}]}'

接着把 max_tokens 从 4096 降到 512 再发同一请求

curl -s -o /dev/null -w '%{http_code}\n' https://api.groq.com/openai/v1/chat/completions -H "Authorization: Bearer $GROQ_API_KEY" -d '{"model":"llama-3.3-70b-versatile","max_tokens":512,"messages":[{"role":"user","content":"hi"}]}'

再往下用 tiktoken 把单请求的输入算清楚

python -c "import tiktoken;e=tiktoken.get_encoding('cl100k_base');print(len(e.encode(open('prompt.txt').read())))"

末了把并发压到 2 并按 6 秒间隔串行重放

for i in 1 2 3; do curl -s -o /dev/null -w '%{http_code} ' https://api.groq.com/openai/v1/models -H "Authorization: Bearer $GROQ_API_KEY"; sleep 6; done

怎么算真的好了,看的是同一批现象。响应头里 x-ratelimit-remaining-tokens 始终大于 0,连续十次请求都返回 200,日志里不再出现 429。

这里还有个坑。RPM 是看得见的那一半,TPM 常常先被打满,把 max_tokens 一并算进预算再估才准。线上能稳定复现的问题都不算难,难的是只在大流量下才出现的那种。

作者 9823189