WaveSpeedAI
← 部落格

HiDream-O1-Image-Dev：以80億參數擊敗560億FLUX.2的原生像素模型

HiDream-O1-Image-Dev是一個80億參數的蒸餾圖像模型，捨棄了VAE與外部文字編碼器，原生生成2K解析度，並在GenEval、DPG和HPSv3基準上超越了7倍體積的模型。

By WaveSpeedAI 3 min read
#hidream #open-source #image-generation #diffusion-transformer #model-release

2026年5月8日，HiDream-ai 以 MIT 授權開源了 HiDream-O1-Image——而架構選擇本身就是最大的新聞。近年來幾乎所有文字轉圖像模型都採用潛在擴散 Transformer（DiT 在 VAE 壓縮的 token 上運作，文字透過凍結的 T5 或 CLIP 路由），而 HiDream-O1 則徹底拋棄了潛在空間堆疊。它讓擴散 Transformer 直接在原始像素上運作，文字與任務條件共享同一個 token 空間。

此次發布了兩個檢查點：完整版 HiDream-O1-Image（50 步，CFG 5.0）與蒸餾版 HiDream-O1-Image-Dev（28 步，CFG 0.0）。兩者均有 80 億參數。截至 2026 年 5 月 5 日，代號為 Peanut 的模型在 Artificial Analysis 文字轉圖像競技場排名第 8，是榜上排名最高的開放權重模型。

本文將深入探討這個架構究竟有何不同、Dev 蒸餾版相較完整模型有何取捨，以及報告的基準測試成績與 FLUX.2、Qwen-Image 和 SD 3.5 Large 相比如何。

像素層級統一 Transformer

現代開放圖像模型幾乎普遍採用同一套配方：

  1. VAE 將 1024×1024 RGB 壓縮為約 64×64 的潛在 token。
  2. 文字編碼器（T5-XXL、CLIP、Gemma）在獨立的向量空間中嵌入提示詞。
  3. DiT 對潛在 token 進行去噪，透過交叉注意力機制與文字嵌入互動。

這種方式很有效率——擴散在 1/64 的空間解析度下進行——但它堆疊了三個獨立訓練的元件，各自有其失效模式。潛在 VAE 在壓縮邊界處會損失細節並導致顏色滲透。為檢索訓練的文字編碼器不一定能編碼生成器所需的空間推理能力。兩個異質嵌入空間之間的交叉注意力，正是文字渲染與小物件精確度通常崩潰的地方。

HiDream-O1 將這個堆疊合而為一。像素層級統一 Transformer（UiT） 將像素塊、文字 token 和任務條件 token 視為同一個共享序列的成員。沒有 VAE——模型直接在原始 RGB 塊上運作。沒有獨立的文字編碼器——文字 token 直接流入同一個 Transformer。擴散直接在像素空間中進行。

代價顯而易見（每個 token 需要更多運算，因為無法做 64× 的降採樣），團隊的解答是稀疏性與排程——已發布的技術報告描述了一個採用預定義時間步的快閃排程器，讓 Dev 變體能以引導比例 0 在 28 步內收斂。如果這個架構奏效，其優勢在於所有模態都存在於同一個表示空間中，這正是當同一個模型需要執行文字轉圖像、指令驅動編輯、多參考個性化和故事板生成而無需切換頭部時所需要的。

HiDream-O1-Image-Dev 的實際作用

Dev 檢查點採用引導蒸餾——它被訓練為在單次前向傳遞中產生 CFG 條件輸出，因此你設定 guidance_scale=0.0 並跳過分類器無引導通常需要的雙倍運算。僅此一點，在任何步數下都大致將實際耗時減半。

相較完整模型，步數從 50 降至 28。加上 CFG 的節省，Dev 明顯更快——團隊自己的表述是「品質與運算需求之間的平衡取捨」，這與一年前 I1 Dev 變體的定位一致。

同一個檢查點支援的功能：

  • 文字轉圖像，原生解析度最高達 2048×2048（管線中無需放大器）
  • 基於指令的編輯（--ref_images input.jpg --prompt "remove the earphones"）
  • 主體驅動個性化——多參考身份保留，接受 2 張以上同一主體的參考圖像並將其置入新情境
  • 長文字渲染——多語言，在英文和中文 LongText-Bench 上報告的分數接近相當
  • 故事板生成——具有一致角色/場景的序列幀

四項任務共享權重。在文字轉圖像與編輯之間切換時，無需進行 LoRA 交換或載入適配器——只需傳入 --ref_images 即可切換模式。

基準測試：80 億參數的主張實際上站得住腳嗎

技術報告與顯而易見的開放權重同類產品（FLUX.2、Qwen-Image、SD 3.5 Large）及人類偏好基準測試中最強的閉源模型進行了比較。報告列出五個測試套件：

基準測試測量內容HiDream-O1（8B）FLUX.2 Dev（56B）Qwen-Image（27B）SD 3.5 Large（13.6B）
GenEval組合精確度（物件、數量、顏色、位置）0.900.870.870.71
DPG-Bench密集提示詞對齊89.8387.5788.3284.08
HPSv3人類偏好（12 個類別）10.379.289.94—
CVTG-2K複雜視覺文字（2–5 個區域）0.91280.89260.82880.6548
LongText-Bench多語言長文字渲染0.979 EN / 0.978 ZH———

有兩點值得注意。首先，HiDream-O1 在所有報告的基準測試中均獲勝，同時比 FLUX.2 Dev 小 7 倍，比 Qwen-Image 小 3.4 倍。一旦架構和資料組成出現分歧，參數數量就不再是衡量品質的簡單指標。其次，文字渲染數字是最值得關注的——CVTG-2K 和 LongText-Bench 專門針對潛在空間模型歷來崩潰的失效模式施壓，而 HiDream-O1 的像素原生設計正是能在此處有所助益的那種改變。0.979 / 0.978 的英/中分數差異表明，這個優勢並非英文 tokenization 的特殊性所致。

HPSv3 分數（10.37/12）在報告的表格中超越了 DALL-E 3 和 GPT Image 2——這種閉源與開源的比較，在十二個月前的這個參數量級是難以想像的。

推理驅動的提示詞代理

隨此版本一起發布的還有一個獨立的提示詞代理——它不是擴散模型的一部分，而是一個包裝器，在生成之前先讓 Gemma-4-31B-it（或任何相容 OpenAI 的 API）處理使用者的指令。代理輸出包含三個欄位的 JSON：推理軌跡、解析出的隱式知識（例如「使用者說了『一位唐代將軍』——這意味著特定的盔甲風格和武器」），以及帶有明確佈局/文字渲染規格的精煉提示詞。

這與 DALL-E 3 的 GPT-4 提示詞改寫器和 Imagen 3 的 Gemini 整合採用相同模式，但作為一個獨立的、可替換的元件發布，你可以在本地運行。對於佈局推理很重要的提示詞——多區域文字、特定的空間關係、文化特殊性——先運行代理正是縮小與閉源系統差距的方式，因為那些系統預設在管線中就有 LLM。

本地運行

程式庫相當簡單：

git clone https://github.com/HiDream-ai/HiDream-O1-Image.git
cd HiDream-O1-Image
pip install -r requirements.txt

使用 Dev 版本進行文字轉圖像：

python inference.py \
    --model_path /path/to/HiDream-O1-Image-Dev \
    --model_type dev \
    --prompt "A dog holds a sign that says 'HiDream-O1-Image release.'" \
    --output_image results/output.png

使用參考圖像進行編輯：

python inference.py \
    --model_path /path/to/HiDream-O1-Image-Dev \
    --model_type dev \
    --prompt "remove the earphones" \
    --ref_images input.jpg \
    --output_image results/edited.png

主體驅動個性化的方式相同——傳入同一主體的多張參考圖像：

python inference.py \
    --model_path /path/to/HiDream-O1-Image-Dev \
    --prompt "A young boy stands on steps wearing light blue jeans..." \
    --ref_images ref1.jpg ref2.jpg ref3.jpg \
    --output_image results/personalized.png

也附帶了一個網頁示範（python app.py --model_path ... --port 7860）。

Flash attention 建議使用但非必須——如果無法使用，models/pipeline.py 中有一個有文件記載的單行修改。VRAM 隨輸出解析度擴展；2K×2K 生成是模型的主打能力，但需要相當大的記憶體。

與 HiDream-I1 的差異

原始的 HiDream-I1 於 2025 年初發布，是一個在潛在空間中運作的 170 億稀疏 MoE DiT——架構上是傳統的，靠品質競爭。O1 則是一次重置：參數數量降至 80 億，VAE 和文字編碼器被移除，架構本身才是貢獻所在。命名慣例也明顯致敬了 OpenAI 的推理模型品牌重塑——「O1」代表整合的提示詞推理代理，儘管擴散模型本身是標準的單次採樣器。

如果你今天需要在兩者之間做選擇：I1 Dev 更老、在各推理平台上得到良好支援且已在生產環境中經過驗證。O1 Dev 更新、更小、在團隊報告的每項基準測試上得分更高，文字渲染也可靠得多——但像素原生架構足夠新穎，第三方工具（ComfyUI 節點、量化、LoRA 訓練腳本）需要時間跟上。

適用場景

HiDream-O1-Image-Dev 是 2026 年迄今為止架構上最具趣味的開放權重圖像模型發布。團隊做了一個逆向押注——去掉潛在空間，去掉外部編碼器，在一個 Transformer 中完成所有事情——而基準測試支持這個押注，尤其是在長尾類別（文字渲染、複雜構圖、多語言）方面，這些正是潛在模型歷來掙扎的地方。

Dev 變體具體來說是大多數人實際會運行的：28 步、無 CFG、MIT 授權、單一檢查點多任務。如果你一直在等待一個能在圖文品質上媲美 GPT Image 2 或 DALL-E 3、又不需要付閉源 API 費用的開放模型，這就是你要找的。

程式庫在 github.com/HiDream-ai/HiDream-O1-Image，Dev 權重在 huggingface.co/HiDream-ai/HiDream-O1-Image-Dev，還有一個託管的 Space 可供無需本地安裝即可試用。

分享