5 月 8 日，HiDream-ai 以 MIT 许可开源了 HiDream-O1-Image——一个 8B 参数的像素级统一 Transformer（UiT）。5 月 14 日，团队又开源了蒸馏变体 Dev-2604 及配套的 Prompt Refine。这个模型做了件业内没人做过的事：把传统扩散模型的 VAE + 独立文本编码器 + DiT 三件套全扔了，换成在原始像素空间跑扩散的单个 Transformer。结果？8B 参数在 Artificial Analysis Text-to-Image Arena 排到第 8——开源模型最高，而它前面的全是 50B+ 的大家伙。

3 分钟看懂版

是什么： 一个 8B 的文生图模型，不用 VAE、不用独立文本编码器，一个 checkpoint 搞定文生图 + 图像编辑 + 角色个性化 + 故事板生成。

为什么重要： 8B 参数做到 56B FLUX.2 Dev 级别的效果，自托管推理成本大约降 7 倍。MIT 许可，商用无门槛。

对谁有用： 想自建生图管线的创业团队、不想付闭源 API 费的独立创作者、需要本地部署保障数据安全的企业、在 ComfyUI 里搭工作流的玩家。

一句话判断： 如果你之前用 FLUX.2 Dev 或 SD 3.5 Large 做文生图，HiDream-O1-Image-Dev 值得立刻试——同级别效果，参数量只有七分之一。

---

架构革命：为什么"不用 VAE"这件事很重要

几乎所有主流开源文生图模型——FLUX、Stable Diffusion XL、SD 3.5——都走同一条路：

1. VAE 压缩：把 1024×1024 的 RGB 图像压成约 64×64 的 latent token
2. 独立文本编码器：用 T5-XXL 或 CLIP 把 prompt 编码成向量
3. DiT 去噪：在 latent 空间做扩散，通过交叉注意力参考文本向量

这个三件套很高效——扩散在 1/64 分辨率下跑，计算量小。但它有三个系统性问题：

• VAE 压缩丢细节：高分辨率下的细纹理、文字边缘、颜色过渡在 latent 空间被模糊掉，解码回来就糊了
• 文本编码器和图像空间不对齐：CLIP 和 T5 是为检索和分类训练的，不是为生成训练的。它们编码的文本语义和图像生成需要的空间布局信息之间存在鸿沟
• 交叉注意力是文字渲染崩的主因：两个不同模态的 embedding 空间通过交叉注意力桥接，文字在图里的位置、大小、拼写——全靠模型在接缝处"猜"

HiDream-O1-Image 的 UiT 架构把这三件套合成一个东西：像素块（pixel patch）、文本 token 和任务条件 token 都在同一个序列里，共享同一个 transformer 的注意力。没有 VAE——直接在原始 RGB patch 上做扩散。没有独立文本编码器——文字 token 直接流进同一个 transformer。

代价是显而易见的：像素空间计算量大（不能 64 倍降采样），团队的解法是稀疏注意力 + Flash 调度——技术报告描述了一种预定义时间步的调度器，让 Dev 变体在 28 步、CFG=0 的条件下收敛。

架构声明需要说明的是："不用 VAE、不用独立文本编码器"的说法来自 HiDream 官方文档和技术报告，截至发稿时未经独立同行评审。但模型的实际生成效果——在 Arena 排行榜和公开基准上的表现——是可验证的。

---

两个 Checkpoint，怎么选

| 变体 | 推理步数 | CFG | 适合任务 | 特点 |

|------|---------|-----|---------|------|

| HiDream-O1-Image（完整版） | 50 步 | 5.0 | 图像编辑、角色个性化、故事板 | 质量最高，多任务通用 |

| HiDream-O1-Image-Dev（蒸馏版） | 28 步 | 0.0 | 文生图 | 速度快一倍，Guidance Distillation 免去双倍计算 |

| Dev-2604（5 月 14 日新增） | 28 步 | 0.0 | 文生图 + Prompt Refine | 专为文生图优化的蒸馏变体，搭配 Prompt Refine 使用 |

Dev 的蒸馏做了什么： 把原本需要 Classifier-Free Guidance（每次推理跑两遍——一遍有 prompt 一遍没有）的过程蒸馏成单次前向。CFG 从 5.0 降到 0.0 意味着不需要双倍计算，再配合步数从 50 降到 28，总推理时间大约减少 3-4 倍。

5 月 14 日更新的重点：

• Dev-2604 变体开源：针对文生图场景进一步优化的蒸馏 checkpoint
• Prompt Refine 模型开源：内置的"推理驱动提示词代理"，在生成前自动解析隐含知识、布局和文字渲染需求
• 推理管线更新：IP 管线支持 layout 和 skeleton 条件控制；编辑调度器优化

---

实际能力拆解

文生图：2K 原生 + 长文本渲染

最高支持 2048×2048 原生分辨率输出——不是超分，是直接生成。长文本渲染是 HiDream 的一大亮点：图中出现多区域、多语言的文字时，模型能准确控制文字的位置、大小和拼写。官方展示的示例包括复杂的海报排版和多语言混排场景。

图像编辑：指令驱动，推荐用完整版

HiDream-O1-Image 支持用自然语言指令做图像编辑——"把背景换成海边""给人物加上帽子"。编辑任务推荐用完整版（50 步），因为蒸馏过程主要针对文生图场景优化，编辑质量在 Dev 版上会打折。

角色一致性（IP 个性化）

多张参考图输入后，模型能在新场景中保持角色身份。5 月 13 日的更新让 IP 管线新增了 layout 和 skeleton 条件控制——你可以指定角色在新场景中的位置和姿态。

故事板生成

同一个角色在连续场景中出现，适合漫画、分镜、连续叙事内容。

---

基准数据与竞品对比

HiDream-ai 的技术报告给出了在 GenEval（文本-图像对齐）、DPG（密集预测对齐）、HPSv3（人类偏好）三个基准上的对比数据：

| 模型 | 参数量 | GenEval | DPG | HPSv3 |

|------|--------|---------|-----|-------|

| HiDream-O1-Image-Dev | 8B | 与 FLUX.2 Dev 持平 | 超越 | 超越 |

| FLUX.2 Dev | 56B | 基准线 | 基准线 | 基准线 |

| Qwen-Image | — | 略低 | 略低 | 略低 |

| SD 3.5 Large | 8B | 明显低于 HiDream | 明显低于 | 明显低于 |

在 Artificial Analysis Text-to-Image Arena 中，HiDream-O1-Image-Dev 目前排第 8，是所有开源模型中排名最高的。排在前 7 位的都是 50B+ 参数的闭源模型。

注意： 基准数据来自 HiDream 官方技术报告。Arena 排名会随时间变化。架构描述（"不用 VAE"等）来自官方声明，机制层面尚未有独立研究复现。

---

怎么用

在线体验

• HuggingFace Spaces：[HiDream-O1-Image](https://huggingface.co/spaces/HiDream-ai/HiDream-O1-Image)、[HiDream-O1-Image-Dev](https://huggingface.co/spaces/HiDream-ai/HiDream-O1-Image-Dev)

本地部署

```bash

git clone https://github.com/HiDream-ai/HiDream-O1-Image.git

cd HiDream-O1-Image

pip install -r requirements.txt

python inference.py

```

推荐硬件： 24GB+ VRAM（如 RTX 4090、A100、H100）。8B 参数在 fp16 下约需 16GB 显存，加上 KV cache 和中间激活，24GB 是舒适区。

重要提醒： 避免 PyTorch 2.9.x——GitHub README 明确标注存在兼容性问题（与 Qwen3-VL 共享的已知 issue）。推荐使用 PyTorch 2.6-2.8。

Prompt Refine

5 月 14 日开源的 Prompt Refine 模型可以在生成前自动优化你的 prompt——补全隐含的布局描述、细化文字渲染需求。对中文 prompt 也有一定改善作用。

---

适用场景与不适用场景

✅ 适合用 HiDream-O1-Image 的情况：

• 自托管文生图，不想付闭源 API 的持续费用
• 需要图像编辑 + 角色个性化 + 故事板，想用一个模型搞定
• MIT 许可商用无顾虑
• 在 ComfyUI 中搭建自定义工作流
• 需要高质量中文/多语言文字渲染入图

❌ 不太适合的情况：

• 显存不到 16GB 的设备（8B 虽小但像素空间扩散需要更多显存）
• 需要极致速度的实时交互场景（Dev 28 步仍需数秒）
• 需要极致写实风格（目前 Arena 前几名的闭源模型在超写实人像上仍有优势）
• 需要 inpainting/outpainting Canvas 式交互（HiDream 目前主打通图生成和指令编辑，Canvas 交互非强项）

---

行业意义：开源生图从"追赶"到"局部超越"

HiDream-O1-Image 的意义不只在"8B 打平 56B"这个数字。

架构层面： 如果 UiT 的"无 VAE"路线被验证成立，它可能改变后续文生图模型的设计方向。过去两年，整个行业都在 latent diffusion 的框架里卷——更大的 VAE、更好的文本编码器、更深的 DiT。HiDream 证明了一条完全不同的路：把所有模态压进同一个 token 空间，用像素空间直接做扩散。

开源层面： MIT 许可 + Arena #8 开源第一，意味着中小团队第一次有一个在质量上可替代 FLUX.2 Dev、同时在许可和成本上远优的选择。对创业公司来说，8B 意味着单卡部署；对个人创作者来说，MIT 意味着商用零门槛。

社区层面： HuggingFace Spaces 上线 + ComfyUI 适配 + Prompt Refine 开源，HiDream 在可用性上做足了功课。5 月 8 日到 14 日一周内连续放出完整版、蒸馏版、Dev-2604 和 Prompt Refine，迭代速度很快。

需要冷静看的是： 技术报告中的架构描述尚未经独立复现；"无 VAE"带来的显存开销目前限制了低配用户的使用；编辑和个性化任务的 Dev 版表现不如完整版——用户需要明确自己的使用场景再选 checkpoint。

---

*基于多家媒体转述整理。主要来源：HiDream-ai GitHub 官方仓库、WaveSpeed Blog 技术分析、AI Tech Connect 报道。HiDream-O1-Image 首次开源日期为 2026 年 5 月 8 日，Dev-2604 开源日期为 2026 年 5 月 14 日。*

参考来源

• https://github.com/HiDream-ai/HiDream-O1-Image
• https://wavespeed.ai/blog/posts/hidream-o1-image-dev-pixel-unified-transformer/

说明：该页面由基础模板稳定生成，后续可继续局部润色样式或补充模块，再进入发布检查。