报错是这么冒出来的。把 5 万条 jsonl 合成一个 480MB 文件提交 Batch，接口返回 400 file too large，文档写单文件上限 512MB，实际 480MB 就被挡，拆成两半后能过。
中间走过弯路，把「压缩前体积与传输体积不是同一个口径」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。上限同时受请求条数约束，5 万条已经到顶。也可能是单行超长把总体积顶到边界。
少数情况下是组织剩余配额不足也会回同一个文案。
先统计行数、体积和最长一行
python -c "import os;ls=open('all.jsonl','rb').readlines();print(len(ls),os.path.getsize('all.jsonl'),max(map(len,ls)))"接着按两万行切片并保持 jsonl 完整
python split_jsonl.py --in all.jsonl --lines 20000 --out-dir parts/然后逐批提交并记录 batch id
curl -s -X POST https://api.openai.com/v1/batches -H "Authorization: Bearer $KEY" -F purpose=batch -F "file=@parts/part_01.jsonl" | jq -r '.id'汇总各批次状态与行数
python batch_status.py --ids ids.txt --expect-lines 50000别只看报错消失，验证要多做一步。每个切片都提交成功并返回 batch id，所有批次的行数加起来等于 5 万，没有一条被静默丢弃。
这里还有个坑。报 file too large 时先看条数再看体积，很多接口按请求行数卡人，压体积并不能过。报错文案容易误导，真正的原因往往在相邻那一层的日志里。