TL;DR
将 HiDream-O1-Image Full 部署到本地常驻服务器并集成到 Studio UI 中。官方配方对应的 2048x2048 / 50 steps / guidance 5.0 画质很好，但每张耗时约 33 秒。在创意验证阶段每次都跑这个配置太重了。
因此，我在同一 prompt 和同一 seed 下，对 steps、guidance 和分辨率进行了组合测试，找到了一个实用性很强的平衡点。
| 设置 | 实测耗时 | 相对官方配方的加速比 |
|---|---|---|
2048 / 50 steps / g5 | 33.37s | 1.00x |
2048 / 28 steps / g5 | 18.41s | 1.81x |
1536 / 20 steps / g5 | 7.14s | 4.67x |
1024 / 20 steps / g5 | 3.83s | 8.71x |
结论是：先用低分辨率、低 steps 探索方向，最后再用高质量设置出图。特别是 1536x1536 / 28-36 steps 这个组合，在速度和画质之间取得了很好的平衡。
动机
将图像生成集成到 UI 中后，模型的绝对质量反而不如“试错迭代的速度”重要。
相比一次生成最终成品，实际流程通常是这样的：
- 查看构图、氛围、服装、背景的方向
- 稍微调整 prompt
- 改变 seed
- 只对看起来不错的候选进行高质量重绘
如果每次都按官方配方等 30 多秒，这个循环会非常沉重。相反，如果能用 5 到 10 秒看到粗糙的候选，体验会完全不同。
本次的目的不是追求“最高质量的一张图”，而是在不大幅牺牲质量的前提下，将探索成本降到最低。
环境
- GPU: NVIDIA RTX PRO 6000 Blackwell Max-Q (96 GB VRAM)
- 模型: HiDream-O1-Image Full (8B, bf16)
- 推理服务器: 自建 Python HTTP 服务器，模型常驻
- 测量对象: model load 后的
/generate/t2i单次请求 - seed:
42 - prompt:
A cinematic portrait photo of a woman in a rainy neon street,
detailed skin, 85mm lens, realistic lighting, high detail
所有对比图像均固定使用此 prompt 和 seed。仅改变 steps、guidance_scale、分辨率以及是否启用 resolution snapping。
| 项目 | 值 |
|---|---|
| prompt | A cinematic portrait photo of a woman in a rainy neon street, detailed skin, 85mm lens, realistic lighting, high detail |
| seed | 42 |
| mode | t2i |
| dtype | bf16 |
| negative prompt | 无 |
| sampler / scheduler | HiDream pipeline 默认 |
选择人物肖像的原因是头发、皮肤、背景光和细节比较容易观察。不过，年轻女性的脸部本身皱纹和凹凸较少，因此也是不太容易暴露低 steps 缺点的素材。这一点后文会提到。
文章中的图像是生成结果并排显示的 contact sheet。虽然细节比较用原图更清晰，但在 UI 探索场景中，首先重要的是“第一眼是否能作为候选保留”，因此本文优先考虑了一览性。
首先降低 steps
固定 guidance=5.0 和分辨率 2048x2048，仅降低 steps。
| Resolution | Steps | Guidance | Elapsed | Speedup vs 50 steps |
|---|---|---|---|---|
| 2048x2048 | 20 | 5.0 | 13.070s | 2.55x |
| 2048x2048 | 28 | 5.0 | 18.412s | 1.81x |
| 2048x2048 | 36 | 5.0 | 23.854s | 1.40x |
| 2048x2048 | 50 | 5.0 | 33.370s | 1.00x |
几乎与理论值一致。在 HiDream 的这个路径中，当 guidance > 1.0 时，会执行 conditional / unconditional 两次前向传播，因此降低 steps 会直接带来速度提升。
从视觉上看，降到 20 steps 时会略显粗糙。28 steps 虽然细节上能看出一些不足，但第一眼观感相当不错。36 steps 对大多数用途来说已经足够。
guidance=1.0 速度非常快
接下来，我比较了包含 guidance 在内的实用预设候选。
| Preset | Resolution | Steps | Guidance | CFG | Elapsed |
|---|---|---|---|---|---|
| Draft | 2048x2048 | 24 | 1.0 | off | 8.164s |
| Balanced | 2048x2048 | 36 | 3.0 | on | 23.664s |
| Official | 2048x2048 | 50 | 5.0 | on | 32.609s |
guidance=1.0 实际上关闭了 CFG，因此速度比单纯降低 steps 更快。即使只有 24 steps，也能跑到 8 秒级别。
不过，降低 guidance 会改变 prompt adherence 和图像构建。对于创意验证来说很好，但在“文字”、“精细服装指定”、“多个元素的精确布局”等场景下，guidance=3-5 会更可靠。
分辨率指定的陷阱：指定 1024 并不会变快
起初我以为直接传入 width=1024, height=1024 就能变快。但官方 pipeline 并不会直接使用指定的分辨率，而是会将其 snap 到最接近的固定长宽比 bucket 上。
实际测量结果如下：
| Requested | Actual |
|---|---|
| 512x512 | 2048x2048 |
| 1024x1024 | 2048x2048 |
| 2048x2048 | 2048x2048 |
| 1280x720 | 2560x1440 |
| 720x1280 | 1440x2560 |
| 1024x768 | 2304x1728 |
也就是说，仅仅从 UI 发送 1024x1024 并不会变快。如果是正方形，最终还是会以 2048x2048 生成。
代码上，这只是向 models/utils.py 中的 PREDEFINED_RESOLUTIONS 靠拢，我认为这是优先保证画质稳定性的设计。
绕过 Bucket 进行低分辨率生成
为了实验，我添加了 snap_resolution=false 参数，使其能够绕过 pipeline 的 resolution snapping。出于安全考虑，任意分辨率被限制在以下条件：
- width / height 为 32px 对齐
- 不小于 256px
- 总像素不超过 4.3MP
在 20 steps / guidance=5.0 下比较 1024 / 1536 / 2048。
| Resolution | Elapsed | Speedup vs 2048 |
|---|---|---|
| 1024x1024 | 3.831s | 3.47x |
| 1536x1536 | 7.139s | 1.86x |
| 2048x2048 | 13.278s | 1.00x |
这个效果非常显著。考虑到官方配方在 2048 下需要 30 多秒，1536 + 28 steps 的组合预计能降到 10 秒左右。体感上完全是两个世界。
1024 很快，但信息量下降明显。虽然适合方向确认，但作为最终输出，粗糙感可能会在很多场景下成为问题。
落地到 Studio 预设
基于本次结果，我在 Studio UI 中采用了如下设置：
| 用途 | 分辨率 | steps | guidance | 使用方式 |
|---|---|---|---|---|
| 快速预览 | 1024x1024 | 20-24 | 1.0-3.0 | 构图、氛围检查 |
| 标准 | 1536x1536 | 28-36 | 3.0-5.0 | 日常使用 |
| 高质量 | 2048x2048 | 36-50 | 5.0 | 候选方案的最终重绘 |
| 官方 bucket | bucket | 50 | 5.0 | 与上游配方保持一致 |
在 UI 中，steps 和分辨率可以分别选择。这样，在创意验证阶段可以用 1024 / 24 steps 快速迭代，找到好的方向后，再用相同的 prompt 和 seed 以 1536 或 2048 进行最终渲染。
画质劣化易出现的场景
本次的肖像测试中，28 steps 和 50 steps 的差异“对比之下才能看出”。但这也得益于素材本身。
低 steps / 低分辨率的弱点更容易出现在以下场景：
- 老年人的脸部、皱纹、皮肤纹理
- 手、手指、饰品
- 带有精细图案的衣物
- 招牌或书本上的文字
- 多个人物
- 背景杂物较多的室内场景
相反，年轻人物脸部、简单背景、柔和光照下，低成本设置也不容易暴露缺陷。
因此，与其将生产预设固定为一个，不如让用户根据对象选择探索成本。
复现命令
基准测试脚本位于 image_server/bench_quality_speed.py。由于模型是常驻加载后通过 HTTP API 调用的，因此模型加载时间不包含在测量中。
./image_server/start_image_server.sh
steps 对比：
python3 image_server/bench_quality_speed.py \
--prompt "A cinematic portrait photo of a woman in a rainy neon street, detailed skin, 85mm lens, realistic lighting, high detail" \
--seed 42 \
--variant s20_g5,20,5 \
--variant s28_g5,28,5 \
--variant s36_g5,36,5 \
--variant s50_g5,50,5
分辨率对比：
python3 image_server/bench_quality_speed.py \
--prompt "A cinematic portrait photo of a woman in a rainy neon street, detailed skin, 85mm lens, realistic lighting, high detail" \
--seed 42 \
--variant s20_g5,20,5 \
--size 1024x1024 \
--size 1536x1536 \
--size 2048x2048 \
--no-snap-resolution
总结
HiDream-O1-Image Full 按官方配方虽然画质很高，但对于试错迭代来说太重了。但通过分别调整 steps、CFG 和分辨率，可以非常直接地实现加速。
- steps 几乎线性地影响速度
guidance=1.0会关闭 CFG，速度显著提升- 官方 pipeline 会将分辨率 snap 到固定 bucket
- 真正以低分辨率生成时，1024/1536 能带来巨大速度提升
- 实用上，
1536 / 28-36 steps是一个很好的平衡候选
对于图像生成 UI，与其追求“一开始就最高质量”，不如构建一条 低成本探索 → 高质量最终输出 的路径，这样用起来更顺手。通过这次实验，我对这个设计方向有了更强的信心。