这类问题我又碰上了一次。用 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 一并算进预算再估才准。线上能稳定复现的问题都不算难,难的是只在大流量下才出现的那种。
