选图像生成模型最烦什么？不是训练，不是部署，而是选型时的"开盲盒"体验。今天社区都在刷某新权重，明天又有人吹另一个开源模型，每个帖子里的样图都好看得不行，可自己一跑，效果完全不是那么回事。最近我在本地搭了一套开源工具叫 ImageBench，专门干一件事：把不同模型的生成效果拉到同一张图上并排说话。它不替你做价值判断，只解决一个最实在的问题——"同样是这句话，两个模型出来的东西到底差在哪"。同样的提示词、同样的参数设定、同样的运行环境，左边跑模型A，右边跑模型B，一眼就能看出谁在语义跟随上更稳、谁的细节更干净、谁的风格更对味。这篇文章把我折腾这套流程的完整过程写下来，含配置、启动、并发调度、结果导出，以及我踩过的几个坑，给正在做模型选型的人一个能直接抄的作业。

1. 这工具到底解决了什么问题

1.1 选型不是比谁更强，而是比结果可复现

我接触过不少做内容生成和视觉设计的团队，大家聊到模型选型时，普遍有一个口头禅："凭感觉。"今天试用SDXL，明天看看SD3 Medium，后天又试一个视频生成模型，跑出来几张不错的图就拍板。但问题在于，每个人试用时用的提示词不一样、采样器不一样、步数不一样，连分辨率都未必一致。在这种情况下产生的"对比结论"，本质上没有任何对照意义。

我们拿真实场景说：同样一句"一个人站在夕阳下的街角，电影感光效，浅景深"，有人在SDXL上用欧拉采样器跑了40步，有人在SD3 Medium上用DPM++跑了25步，出的图一个偏暖调、一个偏冷调。你很难说清这种差异到底来自模型本身的性格，还是来自参数设置的偏差。这就导致选型变成了一场"样图PK赛"，而样图恰恰是不可复现的。

ImageBench的出发点很朴素：既然要对比，就把变量控住。它把提示词固定成一组测试用例，把步数、CFG、分辨率、采样器这些参数锁成统一配置，唯一允许变化的，就是后端加载的模型权重。然后，所有产出的图片或视频被强制编排到同一张对比图上。这样跑出来的差距，才能被归因到模型本身，而不是环境因素。

1.2 固定变量加并排输出，为什么比"凭感觉"靠谱

人眼对单独一张图的质量判断极不稳定。你单独看一张图，会觉得哪儿都好；可一旦把两张图放到同一屏，高下立判。这是人类视觉系统的特点——并排对比时的"相对判断"远比"绝对判断"可靠。所以ImageBench的核心交互形态就是"并排说话"，它不做打分游戏，也不搞模型排行榜，它只是把每一个测试提示词下多个模型的输出结果排成网格，让你快速定位差异区域。

我自己实测下来的体感是：第一次看到并排网格图时，很多以往的"感觉"会被颠覆。你以为某个模型是全能选手，结果在文字渲染上被另一个模型甩开几条街；你以为另一个模型细节拉满，结果在语义跟随上连"三个人"都能画成"两个人"。这种东西靠记忆和截图对比是发现不了的，必须把图固定放在一起，用同一个区域去逐项看。

这套思路同样适用于视频生成模型。视频比图像多一个时间维度，单独看每个片段似乎都动得挺流畅，但并排播放时，运动幅度、主体形变、帧间一致性、首尾衔接的差别会非常明显。ImageBench在视频对比里会要求统一时长、统一帧率，再输出一个拼接好的对比播放列表，这点对做视频生成选型的人来说价值极大。

2. 核心功能拆解：ImageBench是怎么把对比做起来的

2.1 模型适配层：一个入口接入不同生态

真正做对比时，最头疼的其实是工程问题。图像模型还好说，大家统一走Stable Diffusion生态的检查点。但视频生成模型就乱多了，有的跑在ComfyUI节点里，有的要单独跑推理脚本，有的需要特定的精度格式和显存需求。如果让用户自己去写每个模型的调用代码，光环境配置就能劝退一半人。

ImageBench把这一步做成了"适配层"。它不需要你懂每个模型内部的实现细节，你只需要在配置里告诉它：这个模型叫什么、用哪种后端加载、工作流文件在哪、返回结果的格式是什么。剩下来的事情，比如调用API、读取输出文件、统一分辨率，全由ImageBench兜底。

具体到实现上，我用的后端是ComfyUI，因为它在社区里支持的开源模型最多，包括SDXL、SD3 Medium、Flux，以及LTX-Video、CogVideoX这类视频生成模型。ImageBench和ComfyUI的协作方式是通过API走的：你提供一个JSON格式的workflow，里面预留了提示词、种子、步数这些输入位，ImageBench按任务批量替换参数，提交到ComfyUI的接口，再轮询生成结果。

这种设计让我很舒服的一点是：新增一个模型，不需要改ImageBench本体，只需要把那个模型的工作流JSON写好，注册进去，它就能参与下一轮对比。对团队来讲，这就是一套可以持续扩展的评估资产，而不是跑一次就扔的临时脚本。

2.2 提示词测试集与参数锁定

对比评估的另一半关键，是提示词测试集要覆盖足够多的维度。我自建的测试集目前分了六类：

• 基础物体描述：检验模型对常见名词和属性的还原能力
• 复杂场景与数量关系：比如"五个人在雨中等公交"，检验计数和空间关系
• 风格模仿：如"水墨画风格"、"赛博朋克霓虹灯"，检验风格指令的跟随
• 文字渲染能力：提示词里包含招牌文字、海报标题
• 光影与色彩：强调氛围描写，检验照片级真实感
• 动作与运动：给视频生成模型用的"缓步走过走廊"、"镜头围绕物体旋转"

每类我至少准备十到二十条提示词，存放在独立的txt或JSON文件里。这样做的好处是，跑一次对比，就能密集地暴露模型在不同能力维度上的偏好和短板。

参数锁定是另一层关键。图像的步数、CFG、采样器、分辨率，视频的帧数、帧率、运动幅度，这些参数在配置里必须是"全局统一值"。注意，这里并不是说每个模型在这些参数下都输出最优效果。实际上同一组参数在两个能力差异很大的模型上，未必能把各自的性能都发挥到最佳。但对比的目的本来就不是"各自超水平发挥"，而是在相同条件下看谁的下限更高、谁对参数的容忍度更稳。想测某个模型的最佳状态，那是另一个命题，等选型定下来之后再单独调优即可。

2.3 批量任务的并发管理与失败重试

这条是很多人容易忽略的。当测试提示词有几十条、每个提示词要跑多个模型时，任务量立刻膨胀成几百个生成请求。没有任务管理机制的脚本，跑两三个小时崩掉，前功尽弃。

ImageBench提供了任务队列和并发控制。默认策略是：根据你本地显存大小，决定同时往ComfyUI提交几个任务。显存吃紧时自动退化为串行执行，一个任务完成，下一个才启动；显存充足时，可以开多并发，把一张卡上剩余的显存利用率拉满。

任务在生成过程中出现超时会自动重试，重试次数可以配置，默认我设置的是两次。如果某个模型在某条提示词上反复失败，它会把这个任务标记为failed，然后继续跑剩余任务，而不是整体卡死。所有任务结束后，输出目录里除了最终对比图，还有一份跑批日志，每条任务的耗时、状态、种子、参数全在里面。这一点非常有用，后期复盘时，你能看出是哪一步拖慢了整体进度，而不是只能盯着最终结果瞎猜。

3. 实操记录：十分钟跑通一次双模型同题对比

3.1 本地环境准备

我这边的基础环境是Ubuntu 22.04，一张RTX 4090，装了官方ComfyUI。如果你想复现我这个流程，前置条件有三个：能跑ComfyUI的显卡、装好ComfyUI及其依赖、留出足够的磁盘空间放模型权重。

接着把ImageBench克隆到本地并安装依赖：

git clone https://github.com/example/imagebench.git cd imagebench pip install -r requirements.txt

我这里用的是基于GitHub地址的通用示例，你实际操作时以项目仓库为准。安装很快，依赖主要是requests、pyyaml、opencv-python这些常见库，没有太重的东西。

3.2 写一份可复用的对比配置

配置文件是ImageBench的核心，它决定了这次对比跑哪些模型、用哪些提示词、锁哪些参数。我贴一份自己实际在用的配置，做了简化但结构完整：

benchmark: name: "sdxl_vs_sd3" tasks: - type: image prompts_file: "prompts/image_prompts.txt" params: steps: 30 cfg: 7.0 sampler: "dpmpp_2m" size: [1024, 1024] batch_size: 1 models: - name: "sdxl_base" display_name: "SDXL Base" backend: "comfyui" endpoint: "http://127.0.0.1:8188" workflow: "workflows/sdxl_api.json" - name: "sd3_medium" display_name: "SD3 Medium" backend: "comfyui" endpoint: "http://127.0.0.1:8188" workflow: "workflows/sd3_api.json" output: grid: true grid_layout: [2, 1] # 2行1列：上方SDXL，下方SD3 save_meta: true

这个配置里，几个字段值得展开说明。prompts_file指向存放测试提示词的文件，每行一条；workflow字段是每个模型对应的工作流JSON；grid_layout控制并排图的排列方式。

必须提醒的是，ComfyUI的workflow文件在导出时，会把所有参数固化成字面量。你要用ImageBench动态传入提示词和种子，就必须在workflow里把相应节点改成占位符，比如用字符串格式在节点输入里留出空白，或者写成可以在API请求阶段被替换的变量形式。这个细节我不知道在别的工具里怎么处理，但在ImageBench的模型适配逻辑里，工作流节点参数的一一对应关系是需要仔细核对的。我第一次跑的时候，就是因为workflow里的提示词没有正确挂载到CLIP Text Encode节点上，导致两个模型跑出来的都是同一张图，白白浪费了半小时。

3.3 启动任务并查看并排结果

配置写好之后，启动命令很简单，指定配置文件和输出目录即可：

python main.py --config configs/sdxl_vs_sd3.yaml --out ./results/sdxl_vs_sd3

跑起来之后，ImageBench会逐条读取提示词，逐模型提交生成任务。等待期间，控制台会输出实时任务进度：当前完成数量、总任务数、失败数。跑完一轮之后，输出目录大概长这样：

results/sdxl_vs_sd3/ ├── grid/ │ ├── 001_sunset_street.png │ ├── 002_five_people_bus.png │ └── ... ├── single/ │ ├── sdxl_base/ │ │ ├── 001_sunset_street.png │ │ └── ... │ └── sd3_medium/ │ ├── 001_sunset_street.png │ └── ... ├── meta/ │ ├── benchmark.json │ └── task_log.csv └── summary_report.html

grid目录下是每一组对比的并排图，single目录保留每个模型单独的原始输出，meta目录里存有完整元数据。我最常用的是grid目录加task_log.csv配合使用，grid负责直观观察，task_log负责回查参数和耗时。

3.4 结果导出与人工评测表

ImageBench还提供了结果汇总功能，把每个任务的状态、参数、耗时、文件名汇总成一个CSV和一个简易的HTML报告。但我认为最有价值的环节，是导出一张"人工评测表"。

我的做法是：把grid目录里的对比图按提示词分类，做成一个共享表格，每一行的描述列包含提示词原文、两个模型各自的输出文件地址；评估列则留空，等领域内的同学逐行看，按"语义跟随""构图质量""细节表现""风格贴合"四个维度分别打分。四个维度各占25分，总分100分。最后汇总结论时，我会把每个模型在所有提示词下各维度的均值算出来，得到一张类似下面的表：

这里要强调，人工评测表的价值不在于把分数当成圣旨，而在于它强迫你"逐项看"而不是"整体扫一眼"。人眼很容易被某一张图的强项带偏，比如某模型色彩特别浓郁，你下意识就给高分了。但分维度打分会逼你承认色彩不代表一切，某个模型在数量关系和语义跟随上的失分，可能在单看时完全被忽略了。

4. 常见问题与排查技巧：踩坑攒下来的经验

4.1 显存将将够用，任务跑一半报OOM

这是最容易碰到的坑。我最初在视频生成模型上跑对比时，用的显卡显存是24GB。视频生成模型的显存需求普遍比图像高出一截，两个视频模型排队跑，偶尔还会和本地跑着的其他进程撞车，于是时不时弹出OOM。

排查思路分三步。第一步，把并发限制调到1，强制串行，排除同时加载两个大模型的冲突。第二步，检查ComfyUI侧是否开启了显存优化选项，比如一些低显存模式、自动VAE内存管理，这些能明显压缩峰值占用。第三步，看是否因为输出累积导致磁盘被占满，视频文件动辄几百MB，连续跑几十组之后存储空间会告急。

还有一种很容易误诊的情况：当你按时间线观察OOM出现的位置，发现它总是出现在某个固定提示词附近，那不是显存的问题，而是该提示词生成的视频分辨率或帧数与其他任务不一致，导致瞬时显存需求飙升。ImageBench的task_log.csv能帮你精确定位是哪一条任务炸的，别凭记忆瞎猜。

4.2 同一个提示词，两模型出图效果差异过大

刚上手时，我经常遇到一种情况：配置完全一致，但同一个提示词在SDXL和SD3 Medium上生成的结果，一个明显偏“写实照片感”，一个明显偏“插画感”。这时候要冷静判断，差异多半来自模型本身的训练域，而不是配置错误。

但有一种配置错误会伪装成"模型差异"：工作流里如果对不同模型设置了不同的负向提示词，哪怕只是差一个逗号，结果都会变化很大。图像生成里，负向提示词对最终风格的影响非常显著，比如SDXL常用的"低质量、模糊、噪点"负向串，和SD3 Medium常见的"文字、水印、签名"负向串，它们的语义覆盖完全不同。我在对比配置里会强制执行全局统一的负向提示词，不允许每个工作流写一套。

顺带说一个更隐蔽的坑：种子一致不代表过程一致。不同模型内部使用的随机数生成方式可能不同，你即使把seed锁成同一个数字，初始噪声也可能不一样。所以并排对比时，如果两张图的构图差得离谱，也别急着下结论——多跑几个种子，或者用ImageBench里的“种子扫描”模式，对一个提示词生成多组种子样本后，再做整体评估。固定单一种子得出的结论，随机性太大。

4.3 指标不可全信，盲测才是最后一道关

跑完一轮对比，拿到一堆分数之后，最危险的心态是"用分数拍板"。我踩过的坑告诉我，人工评测打分依然会受到位置偏见影响。比如并排图里固定左边放A模型，右边放B模型，看多了自然会对左边产生习惯性好感。

破解办法是盲测。我会把同一组对比图复制两份，一份左边A右边B，一份反过来，请评估人员在不被告知来源的情况下打分。这个操作在用ImageBench输出单模型结果时特别好实现，你需要做的只是把single目录下的两个同名文件交换位置。另外还有一个技巧：把输出图的文件名统一改成无模型标识的编号，只看图，不看你之前对某个模型抱有的预期。

这么做之后，我发现自己团队的评估结果有过一次明显反转。某个模型在初测时得分高，盲测后分数反而回落了，因为它的优势主要集中在"风格好看"，而"语义跟随"和"细节稳定"被低估，而后者恰恰是生产环境里更看重的。所以我的经验是：把盲测当成选型流程的最后一道关，它能帮你避开很多自欺欺人的好感和恶感。

5. 把ImageBench接进日常工作流

5.1 建立属于自己团队的基准测试集

用顺手之后，我发现ImageBench真正提升的是一种"持续评估"的能力。很多团队做模型选型是一次性的、被动的——哪个模型热度高就去试哪个。但生成模型更新太快，今天你选了A模型，两个月后B模型的升级版出来了，如果不能快速跑一轮同样的测试，你就永远不知道是否该迁移。

所以我把ImageBench用成了"基准平台"。我的建议是：花两三天时间，构建一批能代表你团队真实业务场景的提示词，不要用社区通用那些"美女、城堡、猫"之类的测试题，要使用你们在项目里真正会输入到模型里的表达方式。比如你们做电商图片，就写商品、场景、风格类的提示词；做视频分镜预览，就写动态场景和镜头运动。基于真实生成的提示词做基准，评估结果对选型才有指导意义，否则拿到手的只是一个"通用能力表"，和你的业务不直接相关。

这套基准集沉淀下来之后，就变成了团队资产。每次遇到新模型、新版本，只需要跑一遍固定任务，看输出数分钟就能确认"有没有值得换的亮点"。

5.2 与ComfyUI工作流、版本管理工具的配合

最后说一个日常维护层面的建议。把ImageBench的配置文件和对应的工作流JSON统一纳入Git版本库，每次评估跑完，把结果目录挂到固定的存储路径，并附上模型权重的哈希值。这样做的原因很简单：生成模型不是静止的，同一个模型名在不同日期下载的权重可能版本不同；你的配置和结果如果散落在每人电脑里，后期很难追溯。

我现在的工作流是：发布评估计划 -> 更新配置文件 -> 启动ImageBench批处理 -> 汇总结果并按维度打分 -> 把结论同步到团队Notion页面。整个过程从过去加班跑两三天缩短到半天内完成，而且所有历史对比都有据可查。需要回复"为什么当时选了它"这类问题时，翻出当时的并排图和评分表，就是最有说服力的答案。

我个人在实际操作中还有一个体会：别把ImageBench当成一个跑完就卸载的工具，它能做的事情比你想象的多。比如在业务侧，面对甲方或运营提出"换一个效果更好的模型"这类模糊需求时，不用争论，直接把同一套提示词的对比图放到桌面上，让效果自己说话。这种"让结果来决定"的工作方式，省掉的沟通成本非常可观。