企业官网建设流程全解析

选生成模型这件事，应该是一个很让人头疼的环节。SD1.5、SDXL、Flux，再到各种视频生成模型，每一个在官方例图上都特别惊艳，等到自己部署完一跑，又总觉得哪里不对。参数表上不会写画面细节和时序是否合理，单张样张里又充满了偶然性。所以我一直建议团队里用统一评测流程：同一个提示词、同一组随机种子，让多个模型同时生成，并排展示，再投票打分。这个思路后来被我们整理成了一个开源小工具，就是 ImageBench。它解决的核心问题很简单——把“我觉得 A 比 B 好”变成“A 在这 50 条测试提示词里赢了 32 次，两者差距显著”，让模型选型建立在一份可复现的对比结果上。无论你是做 AI 应用研发、AIGC 内容生产，还是刚接触开源生成模型的新人，这套思路都值得认真看一看。

1. 为什么需要 ImageBench：模型选择的核心痛点

1.1 单图对比和排行榜都容易骗人

先说说我最早踩的坑。刚开始给项目选底模时，我的做法很原始：去模型社区看首页展示图，挑几张觉得“有眼缘”的，下载下来，跑同一个 prompt，看哪张好看就选哪个。这个方法今天看很不靠谱。官方展示图基本是创作者反复抽卡几十次之后挑出来的一张，写 Prompt 的人对模型风格理解很深，普通用户复现不出来。而且生成模型有很强的随机性，同一个模型跑十次，效果可能忽上忽下。你拿一次生成的结果去否定一个模型，或者拿一次“神图”去认定一个模型，都是典型的幸存者偏差。

排行榜数据也比想象中难用。传统图像指标如 FID（Fréchet Inception Distance）度量的是生成数据分布和真实数据分布的距离，可以反映整体质量，但没法告诉你“这张图的腿有没有画崩”。CLIP Score 能衡量文本和图像的相关性，可它也会被高饱和度、大色块这类“看起来讨喜但细节很差”的图骗到。视频生成这边指标更复杂，FVD、LPIPS 这些指标只是参考，和人类真实观感的相关性并不算高。等到模型更新迭代，排行榜的数字变了，但你根本不知道变化来自哪些 prompt、哪些随机种子，想复现和追溯都很难。

所以真正需要的，是一个能把“主观感受 + 客观指标 + 可复现配置”放到一起的工具。这就是 ImageBench 出现在我工作流里的原因。它不替代你的判断，它只是把判断的依据变得透明。

1.2 从“感觉驱动”到“证据驱动”

ImageBench 的核心理念，是把选模型这件事从“感觉驱动”变成“证据驱动”。具体落地时，它做了三件很朴素但重要的事。

一是规定输入。所有模型都在同一组测试提示词上跑。这组提示词不是随便挑的，而是覆盖人物、风景、物体、文字排版、复杂语义，甚至负面测试。比如我想知道模型能不能处理“玻璃杯里的透明冰块”，会不会把“宇航员”画成“机器人”，这些都要提前设计好。二是固定变量。随机种子、分辨率、采样步数、CFG 值、负面提示词，这些非模型层面的变量全部会被记录下来。同一个种子在不同模型上的生成结果，差异会更容易归结为模型本身。三是统一展示。所有结果按“同一条 prompt、不同模型”分组，左右并排放在同一个页面里，你可以做盲评、可以点选“左边更好/右边更好/平局”，最后自动汇总胜率和排序。

一开始我听到“主观盲评 + 胜率统计”觉得有点小题大做，但跑完一轮之后才发现，这种方式确实能把很多模糊的“感觉”转化成团队里可以讨论的“数据”。之前争论模型好坏，大家各执一词，谁也说服不了谁；现在大家面对同一组并排图，投票，结果摆在那里，结论自然就清晰了。做技术选型的时候，证据永远比感觉更有力量。

2. 核心设计拆解：ImageBench 怎么让效果“并排说话”

2.1 一条评测管线，图像和视频共用

ImageBench 的架构并不复杂。它把整个评测过程抽象成几个模块：提示词管理、模型适配器、生成执行器、结果展示器、投票模块。提示词管理负责维护测试集；模型适配器把不同的生成模型包装成统一接口；生成执行器负责实际跑推理；展示器把所有结果并排渲染到 Web 界面；投票模块收集人眼判断。

这里最关键的设计，是“统一接口”。图像生成模型和视频生成模型虽然输出形态不同，但在评测流程里都可以抽象成同一个函数：输入一个文本提示词、一组生成参数、一个随机种子，输出一个结果文件。图像模型输出 PNG/JPG，视频模型输出 MP4/GIF。ImageBench 不关心底层是用 Diffusers、ComfyUI 调用，还是直接调用某个 API，只要你能实现这个包装函数，模型就能进入评测列表。

这个设计为什么重要？因为生成模型生态太乱了。有些模型是 Hugging Face 上的 Diffusers 格式，有些只能在 ComfyUI 里跑，还有些封装成了 HTTP 服务。如果没有统一接口，每次对比模型都得写一个专用的评测脚本，换一个模型就重写一次，根本没法沉淀。ImageBench 把差异隔离开，新增模型通常只需要写一个几十行的 adapter，剩下的流程全部复用。

视频生成和图像生成的评测逻辑在多处也不同。图像可以几秒出一张，视频动不动几十秒甚至几分钟。ImageBench 里的生成执行器会为视频任务启用单独的排队策略，避免一次性把显存占满。展示时，视频结果会首帧截图作为封面，点击后播放视频。不仅如此，视频评测还会额外记录帧数、FPS、生成时长，因为视频的一致性比单帧美感更关键，这些记录能帮助你判断模型在运动上的表现。

2.2 打分、排序与报告生成

评测结果展示页面很直接：同一个提示词下，一个模型结果放左侧，另一个放右侧，中间有“左边更好”“右边更好”“平局”三个按钮。默认开启盲评，模型名被隐藏，左右位置也会随机互换，避免你因为习惯“左手边是模型 A”而产生偏差。连续评完一组后，系统会根据结果更新排序。

排序算法借鉴了国际象棋的 ELO 分数思想。每张图都代表一次“对局”，赢得一分的一方，ELO 会往上升；输掉的一方会往下降，升幅和降幅由双方当前分数之差决定。如果强模型打败弱模型，分数上涨很少；如果弱模型意外打败强模型，涨幅会很大。这个机制有一个很好的特性：不需要把每个模型和每个其他模型都做一次完整对比，只要投票量足够，排名也能逐渐稳定下来。对于经常要对比五六个模型的团队来说，比“每对模型都要两两全比”的锦标赛模式省力得多。

在 ELO 之外，ImageBench 也会把投票数据导出成 CSV，并生成一份 Markdown 报告。报告里包含测试提示词集合、每个模型在每个提示词上生成的图片缩略图、胜率矩阵、ELO 变化曲线，以及机器自动计算的辅助指标。机器指标虽然不完美，但可以作为人眼判断的旁证。比如某轮人工投票认为 A 模型大幅领先，可 CLIP Score 显示 B 模型更高，这时候你就要留意：B 是否为了贴合文本而牺牲了画面美感，或者人工投票是否被某种风格倾向带偏了。报告的作用不是代替人下结论，而是给结论留下可供审阅的证据。

2.3 可插拔的模型适配器

让 ImageBench 好用的，还有它的插件化结构。每个模型都可以用一个独立配置文件注册，配置里写清楚模型类型、后端类型、模型权重路径或 model_id、推理参数模板。当某个模型更新了大版本，你不需要动主程序，只需要改配置里的权重路径，重新跑一轮评测即可。

目前社区常用的接入方式大概有三类。第一类是 Diffusers 后端，直接加载 Hugging Face 上的权重，适合快速验证新模型；第二类是 ComfyUI 后端，适合已经在本地工作流里用熟了 ComfyUI 的用户，可以直接复用工作流里的采样器、LoRA、ControlNet 等组合；第三类是 HTTP API 后端，当你不想在本地加载权重，希望调用公司内部已部署的推理服务时，只需要写一个请求包装函数。三类后端互不冲突，同一个模型也可以同时注册多个配置，比如“SDXL 裸模型”和“SDXL + LoRA + 推荐采样器”，对比这两种配置，还能帮你做 Prompt 工程和模型调优。

这套插件化设计让我想起一个很朴素的道理：评测工具最怕“模型生态一变化，工具就废了”。 ImageBench 把“评测逻辑”和“具体模型”解耦，只要模型能被包装成统一的输入输出，就能参加评测。也正因为这个特性，它不仅能测开源的 Stable Diffusion、Flux，也能接入公司内部微调版本。新人接手模型选型项目时，不用理解底层推理细节，只要会写注册配置，就能把一次完整的对比跑起来。

3. 实操演示：从零跑通一次 ImageBench 对比评测

3.1 环境准备与最小安装

我通常把 ImageBench 部署在一台带 NVIDIA 显卡的 Linux 机器上，20GB 以上显存会比较从容。如果你只跑 SD1.5 级别的模型，8GB 显存也能应付，但要做视频生成对比，建议还是预留更多。软件环境方面，Python 3.10 以上、PyTorch 2.x、CUDA 对应驱动是基础，另外还需要 Diffusers、Transformers、Accelerate、Gradio 这些常见依赖。Gradio 用来做展示页面，所以最后可以暴露一个 Web 地址给团队成员投票。

安装本身很常规。我在本地习惯把项目放在~/tools/imagebench，克隆仓库、装依赖：

git clone <ImageBench仓库地址> cd ~/tools/imagebench pip install -r requirements.txt

如果你是照着这个思路自建的，核心依赖其实就几个，不需要完整框架也能跑出一个可用的并排对比页。下面这个命令把最基础的依赖装好：

pip install torch diffusers transformers accelerate gradio pillow

有几点经验：一是安装前先确认 PyTorch 版本和 CUDA 匹配，否则后面推理时可能报“CUDA extension not found”之类的错；二是如果模型文件已经在本地，尽量设置HF_HOME或HUGGINGFACE_HUB_CACHE指向你的模型缓存目录，别每次都重新下载几个 GB 的权重；三是团队多人评测时，别把监听地址绑定到127.0.0.1，用--host 0.0.0.0开放到局域网，方便大家访问。

3.2 注册模型并设计测试提示词

跑评测之前，要先准备一个配置文件。下面是我经常用的一种结构，既注册图像模型，也注册视频模型：

prompts: - "阳光下，一只戴墨镜的柴犬坐在沙滩椅上喝冰咖啡" - "宇航员骑着一匹马在火星表面奔跑，尘土飞扬" - "一张复古电影海报，标题是 THE LAST TRAIN，画面中有蒸汽火车和黄昏" image_models: - key: sdxl_base name: "SDXL Base 1.0" backend: diffusers model_id: "stabilityai/stable-diffusion-xl-base-1.0" params: num_inference_steps: 30 guidance_scale: 7.0 - key: flux_sdev name: "Flux Schnell" backend: diffusers model_id: "black-forest-labs/FLUX.1-schnell" params: num_inference_steps: 4 guidance_scale: 0.0 video_models: - key: demo_t2v name: "示例视频生成模型" backend: diffusers model_id: "example/text-to-video" params: num_frames: 32 num_inference_steps: 30 fps: 8 bench: seed: 42 output_dir: "./runs/run_20250214" device: "cuda:0"

这个文件看着简单，但每个字段都有讲究。prompts是测试集，设计时我会尽量拉开语义难度；image_models和video_models分开，是因为后端适配器不同，展示和打分方式也不同；params里的采样步数和 CFG，应尽量按各模型的推荐配置来填，因为这是你真正在实际使用时会采用的设置。bench.seed固定成 42，是为了保证“同一条 prompt、同一个模型、多次评测”的输出可复现。虽然不同模型内部随机性导致 seed 的作用不完全等同，但至少能让某次生成结果在不改配置时再次出现，这已经比完全随机好很多了。

3.3 启动评测、投票与结果汇总

配置写好后，启动评测通常只需要一行命令：

python run_bench.py --config config.yaml --host 0.0.0.0 --port 7860

启动过程分两步。程序先会遍历所有模型和提示词，依次生成结果；生成完成后会自动打开一个 Gradio 页面，把结果按 prompt 分组并排显示。如果检测到是视频模型，页面会显示视频预览和下载入口。评测者可以一组一组往下看，点选“A 更好”“B 更好”或“平局”。因为默认开启了盲评，左右顺序随机，模型名只在全部投票结束后统一公布。

一轮 50 条 prompt、4 个模型的评测，大约需要多少人投票比较合适？我自己觉得，如果只是团队内部做技术选型，3 到 5 个人的投票结果已经能支持大部分结论；如果是发布到社区、想生成一份可信的公共榜单，样本量建议再放大一个量级。 ImageBench 的 ELO 会随着投票数量增加逐渐收敛，所以无论团队规模大小，先跑起来积累数据，总比没有数据好。

投票结束后，runs/run_20250214目录下会生成 CSV 投票记录和 Markdown 报告。CSV 里每一行是一次投票：prompt、模型 A、模型 B、结果、投票人、时间戳。Markdown 报告则把胜率矩阵、ELO 排名和所有效果图汇总到一页。我们团队有个习惯：把这份 Markdown 直接提交到项目 wiki 里，后面讨论模型选型时直接引用链接，效率比在聊天里刷图高得多。

3.4 一个 200 行的极简自建版本

如果暂时不想引入完整工具，你也可以照着 ImageBench 的核心逻辑写一个极简版。思路并不复杂：固定 seed，调用模型生成，然后把两张图拼在一起保存。下面这个 Python 片段，能帮你理解最核心的“并排说话”是怎么回事：

import torch from diffusers import StableDiffusionPipeline from PIL import Image model_a_id = "stabilityai/stable-diffusion-xl-base-1.0" model_b_id = "stabilityai/sdxl-turbo" def load_pipe(model_id): return StableDiffusionPipeline.from_pretrained( model_id, torch_dtype=torch.float16 ).to("cuda") def gen(pipe, prompt, seed, steps, cfg): generator = torch.Generator(device="cuda").manual_seed(seed) return pipe( prompt, num_inference_steps=steps, guidance_scale=cfg, generator=generator, ).images[0] prompt = "一只戴墨镜的柴犬在沙滩上喝冰咖啡" pipe_a = load_pipe(model_a_id) pipe_b = load_pipe(model_b_id) img_a = gen(pipe_a, prompt, seed=42, steps=30, cfg=7.0) img_b = gen(pipe_b, prompt, seed=42, steps=4, cfg=0.0) canvas = Image.new("RGB", (img_a.width * 2 + 20, img_a.height), "white") canvas.paste(img_a, (0, 0)) canvas.paste(img_b, (img_a.width + 20, 0)) canvas.save("compare.png")

这段代码虽然简陋，但已经包含了 ImageBench 的全部灵魂：同样 prompt、同样 seed、不同模型、并排展示。如果你只需要快速看一眼两个模型的差异，用这种小脚本往往比搭一个完整工具要快得多。当评测规模变大，再迁移到完整的 ImageBench 也不迟。

4. 我在实际对比中踩过的坑

4.1 参数统一导致的“伪公平”

第一次跑对比时，我天真地以为只要把 CFG、步数、分辨率全设成一样的，就是公平对比。结果 SDXL 和 Flux Schnell 用同样的 CFG=7.5 跑下来，Flux 那边图像发灰、过曝，SDXL 反而色彩正常。这不是 Flux 模型差，而是我用了它不支持的参数组合。类似的坑在视频模型上更明显，有些模型擅长 16 帧短片段，有些模型设计上就要 32 帧以上才开始稳定。

所以我现在的做法是：每个模型注册时，在其“推荐参数模板”里写清生产环境最常用的参数组合。评测时先按各自推荐参数跑一轮，结论代表“各模型最佳状态下的效果”；如果还想看“设置完全一致时的模型能力差异”，再单独跑一轮一致参数对比。两轮结果分开记录，不要混在一起。 ImageBench 的模型配置本身就支持这种场景，同一个模型可以注册 multiple 条记录，一条叫“SDXL 默认”，另一条叫“SDXL + 高细节 LoRA”。

4.2 显存不足和执行队列问题

图像模型批量推理还好，视频模型才是显存杀手。我试过同时给三个视频模型分配生成任务，结果没跑几条，CUDA Out of Memory 直接崩了，之前攒下的生成结果全作废。后来我把并发数强制改成 1，也就是同一时间只跑一个生成任务，稳是稳了，但一晚上只能跑完很少的测试样本。

ImageBench 里可以设置执行器参数，例如max_workers: 1和queue_timeout: 300，避免任务并发叠加。视频生成任务本身耗时长，我还会单独给视频任务设置“按条执行，执行完立刻释放显存”。如果你的机器不是专门给评测用的，评测期间最好不要同时跑 ComfyUI 的交互生成，否则两边争显存，谁都不快。一个更稳妥的方法是使用子进程隔离，每个模型跑完就退出，释放所有显存，再进行下一个。

4.3 视频长度不一致带来的偏差

图像很容易并排对比，视频动起来以后，时长和帧率不一致会让观众产生很大的偏差。我最早对比两个视频模型时，一个输出 2 秒，一个输出 4 秒，投票结果一边倒。后来检查报告，发现大家并不是觉得 2 秒的视频画质差，而是片段末尾还没看清内容就结束了，“好像没生成完”。

ImageBench 在视频注册参数里有num_frames和fps，我会强制让所有候选视频模型输出相同的帧数和帧率，比如 32 帧、8fps，即 4 秒。有些模型达不到这个长度也没关系，宁可让它跑性能模式，也不要拿长短不同的片段去比较。另外，视频评测还需要固定首帧场景。我会用同一张种子图做视频生成的起始帧，确保大家比较的是“从同一张图开始之后的运动质量”，而不是偶发的首帧差异。

4.4 人眼投票也会飘

主观评测最大的怀疑点，就是“人本身不稳定”。同一个评测者，今天觉得 A 好，明天可能觉得 B 好，疲劳之后更容易点错。 ImageBench 用了盲评和随机左右位置来削弱已知偏差，但还不够。我自己的经验是：每个评测批次不要超过 30 组，超过之后强制休息；每个测试区间设置几个“校验题”，把之前已经投过的组合混在里面，看看评测者前后是否一致。如果一致率很低，这批数据要么剔除，要么只作参考。

还有一种现象叫“风格偏好掩盖能力差异”。有的模型整体色调浓郁，一眼看上去很“高级”，但细节经不起放大；有的模型画面朴素，但结构稳定、文字不乱。投票者如果只凭第一印象，往往会偏好风格鲜明的那一个。所以我建议在 ImageBench 报告里增加“失败情况统计”，单独标记“模型在所有 prompt 中最好的一次”和“最差的一次”，让你在关注胜率的同时，也关注下限。生成模型真正让人放心的地方不是上限多高，而是下限有没有低到不可接受。

5. 从 ImageBench 延伸：让评测成为团队基建

5.1 从本地评测到模型竞技场

ImageBench 的本地评测跑顺之后，还可以做得更贴近“模型竞技场”。LLM 领域著名的 Chatbot Arena 就是这种思路：随机抽两个模型，生成结果并排展示，用户投票，ELO 排名公开。ImageBench 完全可以照这个模式变成团队的公共评测服务。部署一台带 GPU 的服务器，注册好所有候选模型，开放给团队成员甚至外部测试者。测试者进入页面，随机看到两个模型的结果，投票，排行榜实时变动。

比起一次性评测，这种常态化竞技场好处很明显。模型更新是常态，今天测试的版本，下周就可能发新版。如果每次更新都重新做一轮完整评测，成本太高。做成在线竞技场之后，旧模型的票数慢慢累积，新模型上线后从基准分开始，只需要“挑战”现有模型，就能通过 ELO 赛制快速找到自己在团队里的相对位置。对于反复纠结“要不要升级模型”的团队，这一套流程能省下不少无休止的讨论。

5.2 自动指标与人工偏好结合

纯人工投票成本不低，纯自动指标又不够可靠，所以 ImageBench 通常会把两者结合。人工投票记录主观偏好，自动指标提供可批量计算的辅助信号。最常见的自动指标包括：CLIP Score（文本和图像相关性）、PickScore（基于大量人类偏好训练的评分模型）、LPIPS（图像感知差异）、FVD（视频帧分布距离）。

自动指标最大的价值，不是替代人工，而是做粗筛。候选模型如果连 CLIP Score 都明显偏低，大概率文本跟随能力有问题，可以直接降权。如果自动指标接近，再进入人工投票环节细看。 ImageBench 的展示页面上，每个结果右下方可以显示这些指标数值，评测者在投票前瞟一眼指标，能帮助解释“为什么我觉得这张图更好”。要注意的是，指标计算也有不少雷区，比如不同分辨率下 CLIP Score 不可直接比较，视频指标对帧率和长度很敏感。所以在配置里我会用固定的输出尺寸，避免指标因为非模型因素来回跳。

5.3 与 ComfyUI 等现有工作流联动

最后再聊一点实用的。 ImageBench 不只是评测工具，它还可以变成生产工作流的一部分。比如你在 ComfyUI 里搭了一套包含 LoRA、ControlNet 的完整出图工作流，ImageBench 可以利用 ComfyUI 后端加载同样的工作流文件，逐件替换模型权重，批量测试不同底模在真实业务 prompt 上的表现。这样评测的不再是“裸模型”，而是“模型 + 你的全部调优手段”，结果更贴近上线后真正会遇到的场景。

测试完成后， ImageBench 导出的推荐模型配置就能回填到 ComfyUI 工作流里，直接进入生产。整个过程相当于把“评测”和“部署”之间的代沟填掉了一截。我见过太多团队，评测时用的是一套配置，上线时又换了另一套配置，最后效果不对，还得回头找是哪一步参数不一样。 ImageBench 的配置和产出文件都可以用 git 管理，每一次评测对应一组明确的权重版本和参数，这会让你在回溯时省很多事。

我个人实际跑下来最大的体会是：评测工具本身不高级，高级的是愿意把模型选型变成“可记录、可回放、可争论”的流程。 ImageBench 只是把这种流程固化成了代码和界面，真正让它发挥作用的，是团队里愿意按同一标准评一套效果图的习惯。最后再分享一个小技巧：每次评测完，把 Markdown 报告、投票 CSV 和几张典型对比图放进一个带日期命名的目录，作为选型决策附件。三个月后如果有人问“当初为什么选了 A 而不是 B”，你只要甩出这个目录就行，比任何截图都有说服力。