这个坑值得记一笔。做界面巡检，把 20 张 1440 宽的 PNG 转成 base64 一次性塞进同一条消息，请求体 18MB，接口返回 413 Request Entity Too Large，同一批图分 20 次单图请求又都能通过。
刚开始盯着「网关层默认 client_max_body_size 只有 8MB，先于模型接口拒绝」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。base64 编码本身让体积涨三分之一，PNG 截图又几乎无法压缩；单条请求的请求体上限按字节算，跟 token 上限是两套限制；多张图没有按 detail 参数降采样，单张图片消耗的视觉 token 也偏高。
量出压缩前后的真实体积
python -c "import base64,os;p=open('shot1.png','rb').read();print(len(p),len(base64.b64encode(p)))"接着把长边压到 1024 并转 JPEG 再比体积
magick mogrify -resize 1024x -quality 80 -format jpg shots/*.png然后改成分批：每批 5 张并串行提交
python check_ui.py --batch-size 5 --serial --dir shots/网关侧同步放开请求体上限
sed -i 's/client_max_body_size 8m;/client_max_body_size 40m;/' /etc/nginx/nginx.conf && nginx -s reload别只看报错消失，验证要多做一步。批量任务全部返回 200，单条请求体稳定在 4MB 以内，返回结果里每张图的描述与单图请求一致。
容易忽略的是，图片体积和视觉 token 是两个口径，压体积不一定省钱，但一定先解决 413；顺序上先过网关再谈模型侧优化。这类问题最好一次改到位，反复小改反而容易把原因搅混。