看着像偶发问题,实际往往有固定触发条件,复现一次比猜十次有用。 一次把 300 条商品评论塞进同一个请求做情感分类,返回 413 Request too large for gpt-4o-mini on tokens per min,按字数粗估输入接近 21 万 token,单条评论大约 400 字。
改动前把原配置备份一份,出问题能马上回滚,这一步比任何技巧都实用。
先分清是哪一类原因
- 单次请求的 token 数超过了账号的每分钟配额
- 请求体体积超过网关的默认上限
- 多个线程同时发大包,瞬时速率被合并计算
- 重试时原样重发,失败请求本身也在消耗配额
按顺序处理
1. 先用 tiktoken 估算这批文本的真实 token
python -c "import tiktoken;e=tiktoken.get_encoding('cl100k_base');print(len(e.encode(open('batch.txt').read())))"
2. 按 token 预算切片,每片控制在一万以内
python split_batch.py --max-tokens 9000 --input batch.txt
3. 串行发送并在每片之间留出间隔
for f in parts/*.txt; do sleep 2; python call_api.py --file "$f"; done
4. 把失败分片单独落盘,稍后补偿
python merge_result.py --failed failed.jsonl --out result.csv
怎么确认已经恢复
每条请求都返回 200,日志里没有 413,整体耗时变长但失败条数为零,最终结果行数与输入一致。
容易忽略的地方
413 说的是速率超限而不是上下文超限,光把单条文本截短没用,得把请求数量和发送节奏一起降下来,否则换个时间点还会复现。 处理过程中建议每改一项就验证一次,避免多个变量同时变化导致判断失真。