出图忽快忽慢，先把三个量分开：分辨率（像素总量）、采样步数、排队等待。通常分辨率的边际影响比步数更陡，步数与渲染耗时更接近线性，而“等很久”里最大的不确定性往往来自排队。单看一次快慢无法归因，建议先用统一字段记录若干次，再做两组单变量对照，最后把排队单独拆出来看。
同一提示词出图耗时波动，通常是分辨率、采样步数与排队等待三类因素叠加。建议先按固定字段记录尺寸、步数与各时间戳，再固定步数只改分辨率、固定分辨率只改步数，观察耗时变化的形状，最后用同参数重复提交区分渲染耗时与排队耗时。同参数渲染耗时接近而总耗时差距大，波动多半在排队；渲染耗时随分辨率上升明显快于随步数上升，优先压尺寸。具体结论需结合你的队列与环境确认。
记录每次出图的提示词、分辨率、步数与等待时间
先攒出可比较的数据，再谈归因。记录的时候不必写长，但字段要固定，否则两次数据对不上。下面是可直接照抄的一行样例，第一行是表头。
序号,提交时间,提示词标识,宽,高,步数,采样器,CFG,批量,渲染开始时间,完成时间,渲染耗时(秒),总耗时(秒),备注
1,10:02:11,城市夜景A,768,768,24,,7,1,10:02:19,10:02:34,15,23,- 提示词标识只写前几个词或编号，不需要全文。
- 渲染耗时 = 完成时间 − 渲染开始时间；总耗时 = 完成时间 − 提交时间。
- 备注写换浏览器、换时间段、报错重试这类可能影响结果的动作。
参数字段在页面上的位置：生成表单里通常有宽高输入框或宽高比预设、Steps／采样步数滑块、Sampler（采样器）、Guidance 或 CFG、批量张数、模型选择。如果界面只给宽高比预设，需要自己换算出像素总量（宽×高），因为耗时跟像素总量相关，不只是比例。时间戳可以手工掐表，也可以用浏览器开发者工具的 Network 面板看请求发出与响应返回的时间，作为交叉验证。
固定步数只改分辨率，看耗时变化幅度
这一组只动分辨率：提示词、模型、采样器、CFG、批量数、步数全部保持不变。建议取三档，例如 512×512、768×768、1024×1024，或换成你日常在用的三档。每档连续跑 2 到 3 次取中位数，避免一次抖动误导判断。观察点只看渲染耗时，不看总耗时，因为总耗时里混了排队。
档位,分辨率,像素总量,步数,第1次渲染耗时,第2次渲染耗时,中位数
A,512x512,262144,24,,,
B,768x768,589824,24,,,
C,1024x1024,1048576,24,,,判断方式：三档渲染耗时如果随像素总量明显跳升，分辨率就是主要拖时间的变量，优先压尺寸；如果三档差别不大，说明瓶颈不在这里，把注意力放到步数或排队。像素总量翻几倍，耗时通常不是同比例增长，也不必然成平方，别预设倍数，以你自己的记录为准。
固定分辨率只改采样步数，看耗时是否近似线性增长
这一组反过来：分辨率锁死（建议用上一组里耗时最可接受的那档），其余参数不动，只改采样步数。分档可以取 10、20、30、40，或界面允许的等间距档位，每档跑两轮。
步数,第1次渲染耗时,第2次渲染耗时,中位数,每步耗时(中位数/步数)
10,,,,
20,,,,
30,,,,
40,,,,简单判据：看“每步耗时”这一列。如果各档数值大致接近、只有小幅波动，说明步数与渲染耗时近似线性；如果低步数档的每步耗时明显更高，说明存在与步数无关的固定开销（模型加载、解码、后处理），步数越高这部分被摊得越薄。形状判断出来之后，降步数能省多少时间就有了大致预期。
把等待时间拆成渲染时间和排队等待时间
同参数重复提交是最省事的拆法：分辨率、步数、提示词、批量全部不变，连续提交两次，中间不修改任何设置。如果两次渲染耗时接近，而总耗时差很多，差值基本就是排队等待。
页面上可观察的依据：提交之后先出现排队中／等待提示、过一段时间进度条才开始走动，这段停留就是排队；如果提交后很快进入进度条并且走得平稳，渲染耗时这个数字的参考价值更高。也可以对照开发者工具 Network 面板里请求发出到收到响应的时间，与进度条走动的时长做个对比。
还有一种情况要留意：同参数两次的渲染耗时本身就差很多，说明环境不稳定（对方负载、显存切换、模型重载都有可能），这时改参数也解决不了，建议换个时间段再记录，并把这批数据在表里标注出来。
把常用尺寸和步数写进自己的默认配置
对照做完，把耗时最稳、画质能接受的那组参数固化下来，避免每次重新试。Stableboost 若支持保存预设，直接存成一个预设名；不支持就写进自己的配置文本，下次照着填。
# 我的出图默认参数
resolution: 768x768 # 按你的对照结果替换
steps: 24 # 对照后每步耗时稳定的档位
sampler: 按界面可选项填写
guidance: 7 # CFG，按你的记录填写
batch: 1
# 记录依据：以上组合在记录表中渲染耗时中位数较稳定，画质可接受
# 修改任一字段后，重新跑两轮，确认耗时没有明显跳变再固定验证方式：用这组默认参数连续提交两次，比较两次的渲染耗时看是否接近。接近就固定下来；差很多说明当前环境在波动，先不要改默认值，等记录稳定后再定。分辨率、步数、排队三者只要有一项在变，“忽快忽慢”就会一直存在，把可比较的记录留住，问题才有落点。