先把当时的情况摆出来。对账时发现短请求的成本比按 token 估算的高了两倍多，翻计费说明才注意到输入和输出各自按千 token 向上取整，一次只有二十 token 的分类请求也按一千 token 计费。
这类报错背后常见的原因有几处，逐个排除就行。输入与输出分别按千 token 向上取整。也可能是批量小请求没有合并，单条都被取整放大。
少数情况下是估算脚本按精确 token 数算，没考虑取整。不容易想到的是，缓存命中的部分仍按原输入参与取整。
上来先按取整规则重算一批请求
python -c "import math;t=20;print(math.ceil(t/1000)*1000)"接着把小请求合并成批处理降低取整损耗
python batching.py --max-tokens 3000 --max-items 50 --in short.jsonl随后导出账单与自算结果对账
python reconcile_bill.py --bill bill_1109.csv --calc calc_1109.csv --by model等前面都确认过，再确认缓存命中部分的计费口径
curl -s https://api.openai.com/v1/usage?date=2026-11-09 -H "Authorization: Bearer $KEY" | jq '.data[0]'别只看报错消失，验证要多做一步。合并后同样业务量的自算成本下降一半，与账单差额控制在百分之三以内，短请求条数减少八成。
按千取整对小请求极不友好，能合并就合并，估算成本时要把取整规则算进去，否则永远对不上账。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。