先看现象。把 260MB 的批量文件直接传上去，接口返回 413，原文 File too large，压缩成 gz 也没有用，因为格式要求是未压缩的 jsonl。
排查方向其实有限，先把可能性排一排。单文件有体积上限，跑批场景的限制比通用上传更严。另一种情况是上传走 multipart 时前置网关还有自己的体积阈值。
还有一种情况，压缩包不会被自动解压，只会被判成非法格式。
另外，文件接口不支持分片续传，只能切成多个小文件。
先看文件实际大小与行数
ls -lh batch.jsonl; wc -l batch.jsonl然后按行切分成多个小文件
split -l 20000 batch.jsonl part_再往下逐个上传并记下返回的 id
for f in part_*; do curl -s https://api.openai.com/v1/files -H "Authorization: Bearer $OPENAI_API_KEY" -F purpose=batch -F file=@$f | jq -r .id; done末了确认每个分片都落在上限之内
du -h part_* | sort -h | tail -3改完先别撤，确认这几项。每个分片上传都返回 200 且 bytes 与本地一致，用分片 id 创建的批次全部进入 validating，不再出现 413。
切分要按行不能按字节，从一行中间截断会让整片 jsonl 解析失败，报错还会指向下一行，很难查。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。