在做多家图像模型的横向对比时，最容易卡住的不是生成质量，而是跑批量脚本跑到一半就报错：有的模型 400，有的直接超时，有的返回一个空图你都不知道算不算成功。这篇按「先确认能不能通、再确认丢没丢内容、最后确认是不是被限流」的顺序，给一套图像模型对比场景下能直接照着走的排查路径，也说明哪些情况下这套顺序不适用。
做图像模型横向对比，最容易卡住的不是生成质量，而是脚本跑到一半突然报错：这家 400，那家超时，还有的返回一个空图你都不知道算不算成功。整批断了之后，很多人第一反应是改代码，结果越改越乱。
下面按「先确认能不能通、再确认丢没丢内容、最后确认是不是被限流」这个顺序走。它不适用于单次手工调用就能解决的偶发报错，也不适用于你已经在用某个厂商官方 SDK 且错误码文档写得很清楚的情况——那种直接查官方错误码表更快。
第一步：把对比脚本缩成一条能复现的最小请求
报错先别动代码，先确认错误能不能稳定复现。固定同一个提示词、同一组尺寸与张数参数，单独跑其中一家模型。能稳定复现，才有得查；时有时无，多半是并发或网络问题，直接跳到第四节。
- 对比脚本最常见的问题是所有模型共用一套参数，某个模型不认某个字段，整批就一起失败；先把参数降到最小公共集，再逐项加回来定位是哪一项被拒
- 出错时把完整请求体和响应体留档（去掉 Key 再存），后面每一步判断都靠这份原始记录，别凭记忆猜
- 如果单条请求能通、只有批量才报错，问题基本不在模型本身，去看并发和参数组合
- 复现时把随机种子或采样参数固定住，否则你分不清是报错还是效果波动
第二步：分清是参数不兼容、内容被拦还是文件格式问题
400 类报错，读错误信息里的字段名比读那段文案有用。多数情况就是尺寸不在允许档位、张数超上限、提示词长度超限这三类。图像接口的尺寸通常只能取固定几组值，不是任意宽高比都行。对比多家厂商时，先各自查一次允许值，参数口径可以到 /official-api/providers/openai 这类官方来源页核对当时的说明。
| 报错表现 | 常见原因 | 先做什么 |
|---|---|---|
| 提示字段名无效 | 尺寸档位或张数超限 | 查该厂商允许的参数取值 |
| 返回文本含策略关键词 | 内容被安全策略拦下 | 换措辞重试，不要反复改代码 |
| 上传参考图即失败 | 格式、大小或编码方式不对 | 单独测一种输入方式并记录 |
| 同一参数报错位置不一致 | 参数组合冲突 | 降回最小公共集逐项加回 |
内容被拦和普通参数错误的返回码可能长得一样，要结合返回文本里的关键词判断，别一律当成参数问题反复改。参考图、蒙版图这类输入要走文件上传或 base64，格式、大小、编码方式任一处不对都会报错，先单测一种输入方式再谈批量。
第三步：处理返回体解析失败与「成功但没图」
各家返回结构不同，有的给 URL、有的给 base64、有的走异步任务要轮询。用同一套解析逻辑，必然在某一家上报错。最稳的做法是按厂商分别写解析分支，而不是硬套一个通用解析器。
- 打印完整返回体解析不到字段时先看真实结构，不要靠猜字段名；结构差异可以对照 /openai-compatible-api-shape 这类结构说明。
- 区分异步与同步异步任务要先拿任务 ID 再轮询结果，直接读图字段当然读不到，先确认该接口是同步返回还是异步返回。
- 验证 URL 可用性拿到图片链接还要考虑它有有效期、可能要求带鉴权或跨域受限，下载失败常被误判成生成失败，用不带额外头的请求单独拉一次试试。
- 处理空图状态成功但一张图都没有，多半是被内容策略静默过滤或采样走了空路径，换提示词重试一次即可排除，别急着换模型。
这三步走完还解析不出来，就把该家的返回体单独存成样例，作为后续解析分支的基准，而不是每次现场调试。
第四步：并发、超时与额度类报错的区分处理
图像生成耗时远高于文本接口，批量对比时并发一高就容易 429 或超时。处理顺序是先降并发再谈其他：从串行开始，跑通之后逐档往上加，记下每档的成功率，找到你这条链路能扛住的上限。
- 429
- 被限流，等一等再试，别改参数
- 读超时
- 调大读超时值，图像接口响应本来就慢
- 5xx
- 服务端波动，重试而不是改参数
- 集体失败
- 账号额度耗尽、模型无权限或 Key 未开通该模型，先核对账户侧状态
把失败任务单独收集起来重投，不要整体重跑。一次全量重跑很可能把额度烧在重复请求上，尤其是那些本来就成功的任务。失败重投时带上原始参数，保证可复现。
第五步：让对比结果可复盘——该记哪些字段
排查完了，还要让这次对比留得下痕迹。每次请求至少记：厂商、模型标识、提示词、尺寸与张数、耗时、状态码、错误原文、是否重试成功。同一提示词要固定随机种子或保持参数一致，否则报错排查和效果对比会互相干扰。
- 把成功率和平均耗时、失败原因分布列成一张小表，比逐个翻日志更快看出是某一家的问题还是全流程的问题
- 对比结论注明采集时间，模型和接口口径会变
- 计费与版本口径去 /price-watch 和 /models 核对当时的数字
- 报错样例按厂商归档，下次同类问题直接对照
这套记录方式同样适用于反过来做效果对比：参数不固定、时间不标注，得出的结论只能当个人印象，不能当依据。这一步不适用于你只是临时跑一次看个大概的场景，那种记个状态码就够了。
下一步报错排查完之后，通常还要比较各家的实际响应速度和稳定性，这类实测数据到站内的速度测试页看更直观，也方便和你的记录对照。→常见问题
同一段代码跑文本模型正常，换成图像模型就报错，是哪里不对？
大概率是参数结构不同。图像接口多出尺寸、张数、参考图这些字段，返回也不是纯文本而是链接或二进制。先按该厂商的文档单独写一个最小请求跑通，再往对比脚本里并，别指望一套参数通用。
报错说参数不合法，但字段名看着都对，还可能是什么？
常被忽略的是取值档位而不是字段名：尺寸只能取固定几组、张数有上限、提示词长度有上限。另外有些模型不接受多个输入图或某种格式。把参数逐项减到只剩提示词试一次，能快速定位是哪个字段。
批量对比跑到一半大面积失败，要不要从头重跑？
不要。先看失败时间点是否集中在并发抬升之后，是的话降并发并按指数退避重试；把失败任务单独捞出来重投，成功过的别重跑，否则额度和时间都浪费在重复请求上。
