WaveSpeedAI
← ブログ

HiDream-O1-Image-Dev：56BのFLUX.2を超えた8Bピクセルネイティブモデル

HiDream-O1-Image-DevはVAEと外部テキストエンコーダーを排除した8Bの蒸留画像モデルで、ネイティブで2K解像度を生成し、GenEval・DPG・HPSv3において自身の7倍のサイズのモデルを凌駕します。

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

2026年5月8日、HiDream-aiはMITライセンスのもとHiDream-O1-Imageをオープンソース化した — そしてアーキテクチャの選択がそのまま見出しになっている。最近のテキスト-to-イメージモデルのほぼすべてがLatent Diffusion Transformer（VAE圧縮トークン上で動作するDiT、テキストは凍結T5またはCLIPを通じてルーティング）であるのに対し、HiDream-O1はlatentスタックを完全に廃棄した。拡散トランスフォーマーを生のピクセル上で直接動作させ、テキストとタスク条件が同一のトークン空間を共有する。

リリースされたチェックポイントは2つ：完全版HiDream-O1-Image（50ステップ、CFG 5.0）と蒸留版HiDream-O1-Image-Dev（28ステップ、CFG 0.0）。どちらも80億パラメータを持つ。2026年5月5日時点で、コードネームPeanutのこのモデルはArtificial Analysis Text-to-Image Arenaで第8位に位置し、ランキング上で最高位のオープンウェイトエントリとなっている。

本稿では、このアーキテクチャが実際に何を変えたのか、Dev蒸留版が完全版と比較して何を犠牲にしているのか、そして報告されたベンチマークがFLUX.2、Qwen-Image、SD 3.5 Largeとどう対比されるかを詳しく見ていく。

ピクセルレベル統合トランスフォーマー

現代のオープン画像モデルは、ほぼ例外なく共通のレシピを持っている：

  1. VAEが1024×1024のRGBを〜64×64のlatentトークンに圧縮する。
  2. テキストエンコーダ（T5-XXL、CLIP、Gemma）がプロンプトを別個のベクトル空間に埋め込む。
  3. DiTがlatentトークンをデノイズし、テキスト埋め込みにクロスアテンションする。

これは効率的だ — 拡散は空間解像度の1/64で行われる — しかしそれぞれ独自の障害モードを持つ3つの独立して訓練されたコンポーネントを積み重ねる。Latent VAEは圧縮境界で微細なディテールを失い、色がにじむ。検索のために訓練されたテキストエンコーダは、生成器が必要とする空間的推論を必ずしも符号化しない。2つの異質な埋め込み空間の間のクロスアテンションは、テキストレンダリングと小物体の精度が典型的に崩壊する箇所だ。

HiDream-O1はこのスタックを崩す。ピクセルレベル統合トランスフォーマー（UiT）は、ピクセルパッチ、テキストトークン、タスク条件トークンを1つの共有シーケンスのメンバーとして扱う。VAEは存在しない — モデルは生のRGBパッチ上で動作する。独立したテキストエンコーダも存在しない — テキストトークンは同じトランスフォーマーに流れ込む。拡散は直接ピクセル空間で行われる。

コストは明らかだ（64×でダウンサンプリングできないため、トークンあたりの計算量が増える）。チームの回答はスパース性とスケジューリングだ — 公開された技術レポートは、事前定義されたタイムステップを持つフラッシュスケジューラを説明しており、Dev変種がガイダンススケール0で28ステップで収束できるようにしている。アーキテクチャが機能すれば得られるメリットは、すべてのモダリティが1つの表現に存在するということであり、それはまさに、ヘッドスワップなしにテキスト-to-イメージ、指示駆動編集、マルチリファレンスパーソナライゼーション、ストーリーボード生成を行う必要があるモデルに求められるものだ。

HiDream-O1-Image-Devが実際に行うこと

Devチェックポイントはガイダンス蒸留されている — CFG条件付き出力を単一のフォワードパスで生成するよう訓練されているため、guidance_scale=0.0を設定し、通常のclassifier-free guidanceが必要とする2倍の計算をスキップする。それだけでも、任意のステップ数でウォールクロック時間がおよそ半分になる。

ステップ数は完全版に比べて50→28に削減される。CFGの節約と組み合わせると、Devは意味のある速度向上をもたらす — チーム自身の表現は「品質と計算需要のバランスの取れたトレードオフ」であり、これは1年前のI1 Dev変種のポジショニングと一致する。

同一チェックポイントがサポートする機能：

  • ネイティブ解像度最大2048×2048でのテキスト-to-イメージ（パイプライン内にアップスケーラーなし）
  • 指示ベースの編集（--ref_images input.jpg --prompt "remove the earphones"）
  • サブジェクト駆動パーソナライゼーション — マルチリファレンスのアイデンティティ保持、同一被写体の2枚以上の参照画像を使って新しいコンテキストに配置
  • 長文レンダリング — 多言語対応、英語と中国語のLongText-Benchでほぼ同等のスコアを報告
  • ストーリーボード生成 — 一貫したキャラクター/設定による連続フレーム

4つのタスクはウェイトを共有する。テキスト-to-イメージと編集の間でLoRAスワップやアダプターのロードは不要 — --ref_imagesを渡すだけでモードが切り替わる。

ベンチマーク：8Bの主張が実際に成立するところ

技術レポートは明らかなオープンウェイトの競合（FLUX.2、Qwen-Image、SD 3.5 Large）および人間選好ベンチマーク上の最強クローズドモデルと比較している。5つのスイートが報告されている：

ベンチマーク測定内容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———

2点が目立つ。まず、HiDream-O1はFLUX.2 Devより7倍小さく、Qwen-Imageより3.4倍小さいにもかかわらず、報告されたすべてのベンチマークで勝利している。アーキテクチャとデータ構成が乖離すると、パラメータ数はもはや品質のクリーンな代理指標ではない。次に、テキストレンダリングの数値が最も興味深い — CVTG-2KとLongText-Benchは特に、latent空間モデルが歴史的に崩壊してきた障害モードをストレステストしており、HiDream-O1のピクセルネイティブ設計はまさにそこで助けになるはずの変更だ。0.979/0.978のEN/ZH分割は、この向上が英語トークナイゼーションの特異性ではないことを示唆している。

HPSv3の数値（10.37/12）はレポートの表でDALL-E 3とGPT Image 2を上回っており — 12ヶ月前にはこのサイズクラスでは考えられなかったクローズド対オープンの比較だ。

推論駆動プロンプトエージェント

リリースには独立したプロンプトエージェントが同梱されている — 拡散モデルの一部ではなく、生成前にユーザーの指示に対してGemma-4-31B-it（またはOpenAI互換API）を実行するラッパーだ。エージェントは3つのフィールドを持つ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でのテキスト-to-イメージ：

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

Webデモ（python app.py --model_path ... --port 7860）も含まれている。

Flash attentionは推奨されるが必須ではない — 利用できない場合はmodels/pipeline.pyでのドキュメント化された1行変更がある。VRAMは出力解像度に応じてスケールする；2K×2K生成はモデルの目玉機能だが、相当なメモリを必要とする。

HiDream-I1との違い

2025年初めにリリースされたオリジナルのHiDream-I1は、latent空間で動作する170億スパースMoE DiTだった — アーキテクチャ的には従来型で、品質で競合するものだった。O1はリセットだ：パラメータ数は8Bに減少し、VAEとテキストエンコーダが取り除かれ、アーキテクチャ自体が貢献となっている。命名規則もOpenAIの推論モデルリブランドへの明確なうなずきだ — 「O1」は統合プロンプト推論エージェントを示唆しているが、拡散モデル自体は標準的なワンショットサンプラーだ。

今日どちらを選ぶかとなれば：I1 Devは古く、推論プラットフォーム全体でよくサポートされ、本番環境で実績がある。O1 Devはより新しく、より小さく、チームが報告したすべてのベンチマークで高いスコアを示し、テキストをはるかに確実にレンダリングする — しかしピクセルネイティブアーキテクチャは十分に新規であるため、サードパーティのツール（ComfyUIノード、量子化、LoRAトレーニングスクリプト）が追いつくには時間がかかるだろう。

位置づけ

HiDream-O1-Image-Devは、2026年でこれまでのところ最もアーキテクチャ的に興味深いオープンウェイト画像モデルリリースだ。チームは逆張りの賭けをした — latent空間を廃棄し、外部エンコーダを廃棄し、すべてを1つのトランスフォーマーで行う — そしてベンチマークがその賭けを裏付けている。特に、latentモデルが歴史的に苦戦してきたロングテールカテゴリ（テキストレンダリング、複雑な構成、多言語）でそれが顕著だ。

Dev変種は特に、実際に多くの人が実行するものだ：28ステップ、CFGなし、MITライセンス、シングルチェックポイントマルチタスク。クローズドAPIの価格なしでGPT Image 2やDALL-E 3に匹敵するテキスト-in-イメージ品質を持つオープンモデルを待っていたなら、これがそれだ。

リポジトリはgithub.com/HiDream-ai/HiDream-O1-Image、Devウェイトはhuggingface.co/HiDream-ai/HiDream-O1-Image-Devにあり、ローカルインストールなしで試すためのホステッドSpaceも公開されている。

共有