HiDream-O1-Image: A Natively Unified Image Generative Foundation Model with Pixel-level Unified Transformer

原文链接：https://arxiv.org/abs/2605.11061 代码仓库：https://github.com/HiDream-ai/HiDream-O1-Image 作者：Qi Cai、Jingwen Chen、Chengmin Gao、Zijian Gong、Yehao Li、Yingwei Pan、Yi Peng、Zhaofan Qiu、Kai Yu、Yiheng Zhang、Hao Ai、Siying Bai、Yang Chen、Zhihui Chen、Fengbin Gao、Ying Guo、Dong Li、Zhen Shen、Leilei Shi、Jing Wang、Siyu Wang、Yimeng Wang、Rui Zheng、Ting Yao、Tao Mei 机构：HiDream.ai 论文提交日期：2026-05-11 公开仓库更新：README 显示 8B 版于 2026-05-08 开源，技术报告于 2026-05-10 放出，Dev-2604 版于 2026-05-14 开源

速查卡

核心 Insight

HiDream 这篇报告最核心的洞察，不是“我们把参数做到了 200B+”，而是：图像生成模型之所以长期在复杂推理、长文本渲染、多任务统一上磕磕绊绊，很大一部分原因来自架构本身是裂开的。文本编码器负责理解文字，VAE 负责把像素压进 latent，生成 backbone 再在 latent 空间里做扩散。每一层都能工作，但它们不是同一种 token 语言，因此信息在模块边界上会损失、折叠，复杂约束很难完整传过去。

HiDream 的回答是把“文本 token、条件图 token、目标图像 patch token”统一扔进一个共享 token 空间，再用一个 decoder-only Transformer 去同时建模。它想把文生图、编辑、主体一致性生成这些任务，都重写成统一的 in-context 生成问题：给定一段自然语言、若干上下文条件，再让模型在像素空间里逐步恢复目标图像。

这个思路为什么重要？因为它等于否认了过去那条最常见的工程假设：图像生成一定要靠“先压缩再生成”的 latent 路线。HiDream 认为，随着 Transformer backbone 和训练规模上去，直接在像素空间里统一建模，不仅不会一定更差，反而更有机会保留文字细节、布局关系、多区域文本和复杂编辑条件。这也是它为什么特别强调 long-text rendering、instruction-based editing 和 subject-driven personalization：这些能力最容易暴露模块化架构的信息断裂问题。

为什么这个想法可能 work？

第一，统一 token 空间让不同模态不再通过多个独立子系统转译，而是在同一注意力图里直接发生交互。文本说“左上角挂一块写着‘静夜思’的旧墙牌匾”，这类布局、内容、风格和文字渲染约束，不需要经过“文本编码器 → latent 条件映射 → 生成器理解”的长链路，而是由同一 backbone 原生处理。

第二，像素空间避免了 VAE 压缩阶段对细粒度文字、边缘结构和局部几何关系的先天损伤。很多 latent 文生图系统生成长文字、复杂版式时容易糊、错字、漏字，本质上不是后端不会画，而是前端压缩时已经把高频信息弄丢了。

第三，它把图像编辑、IP 一致性、故事板式多面板生成等任务也一并视为“条件 token + 目标 token”的统一问题，这会天然增强多任务迁移。换句话说，统一架构的真正收益不只是一项 benchmark，而是降低“每多一个任务就多一套专门模块”的复杂度。

方法详解

整体架构

论文里的总 pipeline 可以概括成：

输入文字 / 条件图像 / 目标图像噪声化样本 → 统一多模态 token 化 → Unified Transformer (UiT) → 输出 clean image patch 预测 → 通过扩散/flow matching 逐步还原图像

更具体一点：

原始用户指令
  ↓
Reasoning-Driven Prompt Agent（先做推理和提示词重写）
  ↓
文本 token y
条件图像 token c（编辑图、参考图等）
目标图像噪声 patch token x_t
  ↓
拼接到共享 token 空间
  ↓
Hybrid Unified Attention Transformer
  ↓
线性预测头输出 clean patch
  ↓
图像重建

论文 Figure 5/7 要表达的核心是：相比 latent DiT 和“pixel-space 但外挂独立 text encoder”的做法，HiDream 试图做到真正的结构统一，而不是把多个模块并排摆在一起。

关键技术组件

组件 1：Reasoning-Driven Prompt Agent

做什么： 先把人类原始指令转成更明确、更结构化的生成条件。

怎么做： 论文明确写到，这个 agent 建在 Gemma 之上，带“thinking”机制。它不会把用户一句模糊 prompt 直接丢给生成模型，而是先显式推理空间布局、主体属性、物理逻辑、上下文关系，再输出更完整的 prompt。README 里也把它当成独立组成部分，甚至给了本地 Gemma-4-31B-it 和 OpenAI-compatible API 两种后端。

为什么重要： 这其实是在图像生成前面塞了一个“文本规划器”。很多复杂生成任务失败，不是图像模型画不出来，而是输入本身太模糊。HiDream 把这件事体系化了：先让语言模型把意图补全，再交给统一 backbone。

组件 2：Unified Multimodal Tokenization

做什么： 把文本、条件图像、生成目标统一编码进同一 token 空间。

怎么做： 论文把输入拆成三类 token：

1. Text Tokens y：Prompt Agent 输出的 refined prompt，经 backbone 原生词表离散化后映射到共享空间。
2. Condition Tokens c：编辑图或参考主体图先经 SigLip-2 编成语义 token，再通过 learnable projection 对齐到共享空间。
3. Generation Token x_t：目标图像先和高斯噪声混合，形成扩散时刻 t 的 noisy sample，再切成非重叠 patch，映射进共享空间。

关键公式：

其中：

• x 是干净目标图像
• t 是扩散时间步
• \epsilon 是高斯噪声
• x_t 是当前时间步的 noisy image token 表示

直觉解释： 这就是把“要生成的图”先打散成一张带噪图片，然后让模型学会从任意噪声比例往回恢复。关键在于 HiDream 并不是在 latent 网格里恢复，而是在 patch 化后的像素空间里恢复。

数值例子： 如果一张 1024×1024 图像被切成固定 patch，那么每个 patch 都会被看成生成序列中的一个 token；当 t=0.7 时，图里保留更多原图结构；当 t=0.2 时，图像更接近纯噪声，模型需要更依赖文本和条件图来恢复结构。

组件 3：Unified Transformer (UiT) Backbone

做什么： 在同一 backbone 里同时处理文本因果建模和图像扩散建模。

怎么做：

• 采用 decoder-only Transformer 堆栈。
• 8B 版从 Qwen3-VL-8B-Instruct 初始化，借多模态预对齐能力起步。
• 200B+ 版把同一架构放大到 2000 亿级以上。
• 归一化用 RMSNorm，激活函数用 SwiGLU，位置编码用 RoPE。
• diffusion timestep 被编码成额外 specialized token。

组件 4：Hybrid Unified Attention

做什么： 解决语言模型的 causal attention 和图像扩散的 full attention 天生冲突。

怎么做：

• 文本 token 与条件 token 仍遵循 causal masking，只看前文。
• 生成 token 则采用 full attention，可以看见所有 token。

直觉解释： 这相当于把一台 LLM 和一台 DiT 的注意力规则拼成混合版：语言部分仍然保持自回归秩序，图像生成部分则保留全局空间汇聚能力。这样既不破坏 LLM 继承来的语言能力，也不给图像生成套上过于僵硬的因果约束。

组件 5：联合训练目标

做什么： 在像素空间里兼顾局部细节恢复和长程语义一致性。

怎么做： 论文说它把 flow matching 风格的图像预测损失和感知监督绑在一起，用了 LPIPS loss 和 perceptual DINO loss。作者明确承认：像素空间虽然能保细节，但长程语义一致性更难，因此需要额外 perceptual supervision 拉住高层语义。

训练策略

Progressive Generalist Pre-training

论文给的是一个三阶段 progressive strategy：

• Stage I：512×512，联合训练 T2I、LM、MMU，用大规模图文对 + 纯文本语料做 foundational alignment。
• Stage II：1024×1024，加入 in-context generation / editing / subject-driven personalization，把统一架构推向多任务场景。
• Stage III：2048×2048，只在超高分辨率子集上做高保真 refinement。

这套设计很合理：先在低分辨率和大 batch 上打通语言—像素语义对齐，再逐步抬分辨率和任务复杂度，否则 200B+ 像素空间训练成本会直接失控。

Post-training

后训练分两步：

1. SFT：用几十万高质量样本强化构图、美学、真实感和 Prompt Agent 的 reasoning 轨迹；同时把 pre-training 里的 Logit-Normal timestep sampling 改成 uniform sampling，让后期去噪步骤被更均匀覆盖。
2. RLHF：使用 GRPO，把 OCR accuracy、审美、指令遵循、推理质量等多个 reward 聚成 composite advantage function，继续压 artefact、提文本渲染和逻辑一致性。

Fast Inference

论文单列了一节 Adversarial Diffusion Distillation for Fast Inference，README 里也能看到不同 checkpoint 对应不同 inference steps：完整版 50 步、Dev 版 28 步。这说明作者并不只想拿 paper SOTA，还试图补齐真实可部署速度问题。

与现有方法的关键区别

实验结果

主实验：文本生成与复杂对齐

GenEval（组合生成）

更细一点看，HiDream 8B 在 Position 上做到 0.93，已经明显高于 Qwen-Image 的 0.76；200B+ Pro 把 Color、Position、Attr 又往上推了一截。这很说明问题：统一 token 空间确实更利于复杂布局约束落地。

DPG-Bench（dense prompt alignment）

这里最值得注意的是 8B 版已经比 Qwen-Image 高 1.51 分，而 Pro 版继续领先。这说明它不是单靠大参数 brute force，8B 架构本身就已经吃到统一建模红利。

HPSv3（人类偏好）

这意味着它不只是“对 benchmark 更听话”，在人类偏好分上也站得住。

长文本与多区域文本渲染

CVTG-2K

这组结果几乎就是这篇 paper 的“判官”。因为复杂多区域文本生成最能检验 VAE 压缩损失和跨模块信息丢失问题。HiDream 在这里的优势很符合其架构叙事。

LongText-Bench

中文长文本渲染做到 0.980，这对中国团队尤其重要，因为这不是纯英文海报 benchmark，而是直接指向更难的多字形、多结构文字生成问题。

图像编辑与个性化

GEdit

ImgEdit Overall

这里要诚实一点：8B 版在 ImgEdit Overall 上并没有全面压过 GPT Image 2，甚至低于 Qwen-Image-Edit 的一些细项。但 Pro 版显著拉回来，尤其在 Extract、Remove 这类更难编辑子项上提升明显。这反过来说明统一架构路线是成立的，但许多编辑能力仍依赖更大规模和更细后训练才能释放。

SOTA 对照矩阵

复现评估

复现建议： 最现实的路径不是想复刻 200B+，而是先从开源 8B / Dev 版出发，重点验证三件事：

1. 统一 token 空间是否真的在中文长文本和版式任务上比现有开源路线稳；
2. Prompt Agent 对复杂需求解析到底贡献多大；
3. pixel-space 路线在速度、显存和输出质量上的真实 trade-off 是否可接受。

批判性分析

局限性（论文承认的 + 我们看到的）

论文的高光很足，但有几个现实问题不能跳过。

第一，HiDream 把许多结果都写得很漂亮，但对训练成本、tokens、GPU 小时、总算力消耗没有给出足够细的量化口径。对一篇强调“200B+ 可扩展性”的工作来说，这个缺口很大。因为对行业最关键的问题其实是：这个统一路线究竟是“能做出来”，还是“单位成本也划算”。

第二，Prompt Agent 贡献和 backbone 贡献还没有被彻底拆开。论文多次强调 reasoning-driven prompt refinement 很重要，但公开结果里没有足够强的独立消融，告诉我们“去掉 Prompt Agent 会掉多少”“只换统一架构不换前端 agent 会怎样”。这会让人怀疑一部分收益到底来自生成 backbone，还是来自输入工程强化。

第三，8B 版虽然在文本生成和对齐上很亮眼，但在某些编辑 benchmark 上并没有形成全面碾压。这意味着“统一一切”的代价是某些子任务未必天然最优，后训练和专门化数据仍然重要。

第四，200B+ Pro 的 SOTA 叙事很强，但真正落地还取决于推理成本、吞吐和部署工具链。今天它更像一个方向性证明：Unified Transformer 可以放大到这个规模，而不是说明整个市场会马上跟进这条路线。

改进方向

1. 做更干净的消融： 把 Prompt Agent、pixel-space、hybrid attention、GRPO 奖励拆开，分别量化贡献。
2. 补齐成本口径： 给出训练 GPU 小时、推理延迟、显存曲线、不同步数质量曲线，这会比单纯 benchmark 更能说服产业侧。
3. 做更广的真实任务评测： 比如电商海报、UI mockup、故事板、多语种教材图，这些场景比通用 benchmark 更能证明统一路线的商业价值。

独立观察

• 这篇工作和“LLM 一统多模态”的大趋势是同一方向，只不过它把落点放在图像生成，而不是视频理解或 omni chat。
• 它特别值得中国团队关注，因为中文长文本渲染、海报、PPT、营销物料、本地化电商图，恰好是最讨厌 VAE 压缩和模块断裂的场景。
• 从 README 看，团队非常强调 Prompt Agent，这说明图像模型竞争已经不再只是 backbone 竞赛，而是“前端规划 + 后端生成”的系统工程竞赛。

对领域的影响

短期看，HiDream 会逼开源文生图社区重新认真讨论一件事：VAE + 外挂 text encoder 这套经典管线是不是已经接近天花板，尤其是在复杂文本、多区域布局、长文本渲染和统一编辑任务上。

中期看，如果更多结果验证它的单位成本并不过分夸张，那么“像素空间统一 Transformer”会成为一条真正可竞争的主线，而不是论文里的异端路线。尤其当 agent 先行规划、生成模型后执行的工作流成为常态时，HiDream 这种“Prompt Agent + Unified Backbone”的组合会比单纯比图像美感更有产业价值。

长期看，这条路线的真正价值不一定停在图像。它更像在试一件更大的事：把不同模态、不同任务、不同条件都拉回同一种 token 语言，让生成系统从拼装流水线重新变成一个统一智能体。如果这件事成立，它影响的不只是文生图，而是下一代多模态 foundation model 的设计哲学。