HiDream のぽん出し → Dev に逃げる → VRAM が破綻 → プロンプトで殴って勝った話

著者
#hidream#diffusion#promptengineering#gemini#imagegeneration

この記事は kotonia.ai

TL;DR

  • HiDream-O1-Image 8B Full の "ぽん出し" は、日本語プロンプトだと 指示追従と美的センスが同時崩壊 することがある
  • Dev-2604 (preference-tuned, 3.5× 高速) に乗り換えようとしたが、ユースケースで見ると大差なし、しかも Edit 性能はガクッと落ちる。両モデル常駐は 96GB GPU で物理的に破綻
  • 結局モデル切り替えせず、Full + Gemini Flash Lite 製のプロンプトエンハンサーで美的仕上げを後付けする方針に pivot
  • 道中で HiDream 特有の罠 4 つ (ブランド名の焼き込み / "cute" で幼児体型バイアス / "Wong Kar-wai" で韓国字幕誤発火 / "idol-class" で自動キャプション) を発見、全部エンハンサーの system prompt に焼き込んだ
  • 同じ素朴な日本語プロンプトから photoreal と anime の 2 系統が、1 クリックで出るようになった

Act 1: 「ぽん出し終わってる」

Kotonia Studio には HiDream-O1-Image 8B Full をローカル GPU (RTX PRO 6000 Blackwell Max-Q 96GB) に常駐させて T2I を無料提供している。普段は綺麗に出る。でも、ある日 「チャイナドレスを着た可愛い女性、扇子を持って微笑んでいる」 という素朴な日本語プロンプトを投げたら、こんな出力が返ってきた：

raw-kimono-failure

おかしい：

  • チャイナドレス指定なのに着物。中華 → 和に流れている
  • 顔が可愛くない。idol-class beauty を狙いたかった
  • 構図が冗長：全身 + 京都風中庭。本当は寄りで扇子の質感が欲しかった

HiDream-O1 は Artificial Analysis Arena でも上位の OpenWeight モデルで、英語プロンプトを丁寧に書けば 2048×2048 で雑誌レベルの絵が出るはず。なのに日本語の素朴なリクエストでここまで崩壊する。

これは「モデルがダメ」ではなく 「ユーザー入力と OpenWeight モデルの期待値ギャップ」 の問題。フロンティアなら自然言語の含意を内部で解釈してくれるが、OpenWeight 系は prompt 直球で殴る前提の設計。おそらくはエンコーダー部分の容量の限界。

ぽん出し体験を諦めるか、何か手を打つか。

Act 2: Dev-2604 で逃げ切れるかも？

調べていたら、2026 年 5 月にリリースされたばかりの HiDream-O1-Image-Dev-2604 という新 variant が目に入った。Artificial Analysis T2I Arena で #8 入り、28 steps / no CFG で Full の 3.5 倍速い。

Arena は「人間が好きな絵」を順位付けする benchmark。preference-tuning で 美的センスが改善されているはず。

期待値：

  • Dev のほうが「日本語の曖昧な指示でも雑誌レベルで polish された絵を返す」
  • 速度も 3 倍速いので、/studio の体感も向上（ステップ数が28で最適化）
  • 上手くいけば Full 廃止、Dev 1 本に統合できる

Phase 1 bench で generic cinematic prompt 5 種 (Tokyo izakaya, Bangkok night market, character anime, text-in-image, portrait) を Full vs Dev-2604 で比較：

modeFull (s)Dev-2604 (s)speedup
T2I (avg)33.19.53.5×
Edit (avg)79.022.23.6×
IP84.323.83.5×

generic では確かに Dev が速くて、印象的にも少し綺麗。「これは Dev で行けるな」と思った瞬間が Phase 1 の終わり。

Act 3: でも、ユースケースでは大差ない　あと Edit 性能がガクッと落ちる

危うく単純結論で止まるところだった。Kotonia の主戦略は「コメディ系ショート動画 + 美少女アテンション」。generic cinematic で Dev が勝つことと、コメディキャラ/表情演技/字幕付きフックで Dev が勝つことは別の話。

Grok で生成した参考画像 (cinematic editorial Asian beauty / anime qipao / cinematic hanfu / cosplay maid 系) 8 枚を基準に、縦長 1440×2560 (9:16) のコメディ + 美少女プロンプトを 8 種類作って、Phase 2 を組んだ。

Grok 参考の一部（このくらいの仕上がりが欲しい）：

雑誌調ポートレート中華 cinematic
grok-ref-editorialgrok-ref-hanfu

結果は 追従性において Full のほうがいい！！：

  • editorial portrait: 引き分け、美的センス的には Dev のほうが少しいいかも
  • anime qipao: Full の cell-shading が圧勝。Dev は半リアル寄りに流れて anime 指示を無視。美的センスは◎
  • hanfu brocade: Dev に "SAVE" の文字が画面に焼き込まれる (テキスト幻覚)
  • comedy 驚き顔: Full のほうが漫画的に強い表情 + 読める字幕オーバーレイ
  • comedy deadpan: Full のほうが「呆れ顔」を具体的に描く

Dev-2604 は preference-tuning で雑誌系の仕上がりを獲得した代わりに、anime や character 指示の追従性が落ちている。雑誌に最適化されてるから、雑誌じゃないユースケースでは指示を無視して「雑誌っぽい絵」に引き戻そうとする。

「両方良いけど大差ない」例：editorial portrait

引き分けに評価したやつを並べる。同じ portrait prompt に対する Full と Dev の出力：

Full (寄り、ドラマチック)Dev-2604 (引き、雑誌調)
portrait-fullportrait-dev

Full のほうがコントラスト強めでドラマチック（窓辺のレンブラントライト、暗めの図書室背景）、Dev のほうが柔らかく雑誌調（座位の半身、自然光寄り、磨かれた肌）。どちらも「使える」レベルで、Dev のほうが少し優しい仕上がり ... くらいの差しかない。

この差のために model 切り替えのコスト (VRAM / ロード時間 / アーキテクチャ複雑化) を払うのは割に合わない。これが Phase 2 の結論。

決定打：Edit と IP の性能ダウン

generic な T2I だけならまだ Dev も選択肢だったが、Edit と IP (キャラ一貫) で Full との差がクッキリ出てしまった。これがモデル切り替えを諦める一番の理由になった。

参照画像に「3 人の人物、暗い路地、ランタン」が写った T2I 出力を渡して、Same scene, same characters, same composition. Change the weather to a heavy rainy evening; the characters now wearing translucent rain ponchos という Edit 指示を投げた結果：

Full (シーン保持＋雨に変化)Dev-2604 (元シーンを捨てて別画像)
edit-full-weatheredit-dev-weather

Full は「3 人 + レインポンチョ + 雨の路地」と指示通り。Dev は 着物の女性 1 人 + 雪寺 に完全に置き換わっている。ref の構造を一切引き継いでない（テキスト指示にすら寄ってない）。これは「Edit としては機能していない」レベル。

IP (キャラクター一貫性) でも同じ傾向。事前生成した 2 人の顔写真を渡して「同じ 2 人が秋の京都の参道に並んでいる」と指示：

Full (顔をだいたい保持)Dev-2604 (別人を生成)
ip-full-castip-dev-cast

Full は ref の 2 人の顔がだいたい維持されてる。Dev は 完全に別人。preference-tuning で美的優先になった結果、「綺麗な顔を生成する」ほうが「ref の identity を保つ」より優先された、と推測される。

公式 README にも For editing tasks we recommend using the full model と明記されていて、Phase 1 の bench でこの差は確定した。

「Dev で行ける」とは言えなくなった。でも完全に Full でもない。Dev は cinematic atmosphere や generic shot で活きる場面はあるし、3.5× 速い恩恵も捨てがたい。

両方使い分けるしかないか？

Act 4: VRAM 計算で死亡

「じゃあ両方 GPU に常駐させればいい」と思って、実際の GPU メモリ予算 を引いてみた。96GB GPU 1 枚の現状：

同居プロセスresident VRAMpeak VRAM
E4B (reviewer LLM)19.6 GB19.6 GB
31B Gemma 4 NVFP4 (orchestrator)38.0 GB38.0 GB
TTS server (Irodori + Whisper)9.6 GB9.6 GB
Ditto-TalkingHead3.0 GB3.0 GB
LTX-2 A2V (cold-start, fp8-cast)0.9 GB24.0 GB (推論中)
HiDream Full (resident)16.4 GB17.3 GB
合計87.5 GB111.5 GB ← LTX-2 発火中

LTX-2 動画生成が走った瞬間に 既に 95GB GPU だと OOM ギリギリ。ここに Dev-2604 を resident で足すと +16.4 GB、合計 127GB で完全に破綻する。

選択肢を列挙すると：

  1. 両方 resident: 不可能 (上記 OOM)
  2. 両方 cold-start: per-request 22s ロード追加 (Full inference 33s に対して load 22s は痛い。アイドル 0GB は嬉しいが、初回 UX が壊れる)
  3. Dev 常駐 + Full cold-start: Dev 主流 + edit/IP は Full、しかし Phase 2 結果でこの仮定は崩れた
  4. Full 常駐 + Dev cold-start: T2I で時々 Dev に切り替え、毎回 22s ロード
  5. Dev 諦めて Full 1 本: 現状維持、速度向上は手に入らない

サービス視点で見ると、選択肢 1-4 はどれも「無料ユーザーに 22s 余分に待たせる / VRAM 余裕がなくなって他機能 (LTX-2 / 31B) が動かなくなる」のどちらかを犠牲にする。1 人運用で 1 GPU の枠内で全部走らせている前提では、Dev の存在意義が薄い。

ここで 「model swap で美的を上げる」アプローチを諦めることにした。

Act 5: プロンプトで殴れないか

冷静に考え直す。Dev が Full に勝っていたのは何だった？

「美的な仕上がり」だけ。 指示追従は Full のほうが上。

ということは、Full に対して 「指示追従は維持したまま、美的な仕上がりだけを後付け」 できれば、モデル切り替えの必要がなくなる。

具体策：プロンプトの末尾に aesthetic anchor（魔法の語尾） を足して、Full の生成結果を雑誌調に寄せる。

これなら：

  • ✅ GPU VRAM コスト 0 (Full 1 本のまま)
  • ✅ 推論時間も変わらない (33s/枚)
  • ✅ Edit/IP/skeleton/layout も Full なのでそのまま使える（Act 3 で見た Dev の性能ダウンも回避）
  • ✅ Dev cold-start の 22s ペナルティもない
  • ⚠️ 残るリスクは「anchor が効くかどうか」

Phase 3 として、Full に anchor を 4 種類試した：

  • v1 Lindbergh 系: "Vogue cover composition, Peter Lindbergh editorial photography..."
  • v2 cinematic 系: "Roger Deakins anamorphic, blockbuster color grade..."
  • v3 K-beauty 系: "Vogue Korea / ELLE Korea aesthetic, glass-skin glow..."
  • v4 全部盛り: kitchen-sink

3 base prompt (editorial portrait / anime qipao / comedy 驚き顔) × 5 (baseline + 4 anchor) = 15 生成。ここで HiDream の極めて非自明な挙動 3 つが露呈した。

罠 1: ブランド名はそのままの文字列として焼き込まれる

"Vogue" "ELLE" を anchor に入れた変種の出力には "VOGUE" の文字がそのまま焼き込まれていた。anime 出力ではより顕著で、cell-shading の上に雑誌のロゴが乗っていた。

HiDream-O1 は CVTG-2K (complex visual text generation) でトップクラスのテキスト描画能力を持つ。だから固有名詞をスタイル指示と解釈せず、画面に直接書き込んでしまう。

→ anchor からブランド名は完全排除。 写真家・監督名 (Lindbergh / Deakins) は OK、商標は地雷。

罠 2: anime に photoreal anchor → "雑誌紙面" 混入

anime base prompt に photoreal anchor (v1-v4) を全部つけたら、cell-shading のキャラの上に VOGUE の表紙レイアウト がオーバーレイされた合成物のような出力になった。

スタイル指定が矛盾すると、拡散モデルは両方の要素を物理的に重ねた絵を生成してしまう。

→ anime には anime 専用 anchor (Mihoyo / Kyoto Animation 系) を別系統で持つ。

罠 3: "Wong Kar-wai" → 韓国字幕の誤発火

v5 grok-direction polish anchor に "Wong Kar-wai-style color grade" を入れたら、photoreal scene の画面に "신부의 아안" などのハングル文字 が焼き込まれた。

Wong Kar-wai は香港監督。「Asian arthouse cinema」のモデル内連想が Korean に流れて文字化したと思われる。監督名も A/B しないと地雷リスク。

Act 6: cute → 幼児体型バイアスを潰して完成

Phase 4 で anchor を書き直した：

  • ブランド名完全削除
  • 安全な人物名 (Lindbergh, Deakins, Mihoyo) のみ採用
  • anime 用に専用 anchor 追加 (Mihoyo / Kyoto Animation 系)
  • anime 用 anchor に "mature young-adult character proportions" を含めて cute → 幼児体型バイアス を打ち消す（ユーザーが直観で発見していた挙動）

再 bench：

  • ✅ photoreal portrait: v3 K-beauty clean、VOGUE 焼き込みなし、glass-skin + cinematic light
  • ✅ anime: v7 Mihoyo anchor、雑誌混入なし、成人体型保持
  • ⚠️ comedy 字幕は別途処理 (auto caption を embrace するか post-overlay)

これで「Full + cleaned anchor」が確定。実装に落とす。

実装: /api/studio/enhance (Gemini Flash Lite 製)

backend/src/handlers/studio.rs に enhance endpoint を追加。LLM は local 31B Gemma を使わず、gemini-3.1-flash-lite (cheap API) に投げる。理由：

  • 31B Gemma は 38GB resident。さらに常駐させる余裕は前述の VRAM 計算で消えてる
  • Flash Lite は input $0.075/M + output $0.30/M。1 enhance あたり約 0.02 円 (≒$0.0002)、実質無料
  • VRAM 圧迫もないので、機能追加が「他の機能を犠牲にしない」

system prompt に Phase 1-4 の知見を全部焼き込む：

const ENHANCE_SYSTEM_PROMPT: &str = r#"You are a prompt enhancer for HiDream-O1-Image.

Rules (learned from A/B benchmarking):

1. NEVER include brand names ("Vogue", "ELLE", "Nike") — HiDream renders them
   as literal text overlays.
2. NEVER use "Wong Kar-wai" — triggers Korean text hallucination.

3. For photoreal portraits, append:
   " High-end Korean fashion magazine photoshoot aesthetic, professional
     beauty retouch, glass-skin glow, ..."

4. For anime / cell-shaded / illustration, append:
   " In the visual style of Mihoyo / HoYoverse key art, semi-painterly cel
     shading, ..., mature young-adult character proportions ..."
   ALSO: if the prompt has "cute girl" / "kawaii girl" without age qualifier,
   normalize to "young woman in her early twenties with adult proportions".

5. For cinematic scenes, append cinematic CG realism anchor (no Wong Kar-wai).
6. For text-design prompts, append no suffix.

Output JSON: { "detected_style": "...", "anchor_applied": "...",
              "enhanced_prompt": "..." }
"#;

UI 側は /studio の prompt textarea の上に 「✨ 美的拡張」 ボタンを追加。クリックすると POST /api/studio/enhance → 返ってきた enhanced_prompt で textarea を置換 + 緑バナーで適用 style 表示 + Undo。

Act 7: 勝った

最初に見せた「ぽん出し失敗」と同じ素朴な日本語プロンプトを、enhance ボタン経由で投げ直した結果：

Photoreal anchor 適用後

enhanced-photoreal

ちゃんとチャイナドレス、寄りの構図、idol-class な顔、glass-skin、雑誌調ライティング。

Anime anchor 適用後

enhanced-anime

cell-shading の anime スタイル、中華建築の中庭背景、成人体型保持、扇子の質感もキープ。

同じ素朴な日本語プロンプトから photoreal と anime の 2 系統が、1 クリックで切り替え可能に。Full 1 本のまま、VRAM 増加 0、推論時間そのまま。

持ち帰り

エンジニアリング判断の側で得た学び：

  • 「モデル切り替え」と「プロンプト工学」は同じ予算枠で比較する。フロンティアモデルじゃない以上、VRAM とサービスの成立性の制約がモデル選びを支配する。今回は Dev-2604 が美的に勝つことより、Full 常駐枠を維持することのほうが上位の制約だった
  • A/B bench は 2 段で組む。generic プロンプト → 確信 → ユースケースプロンプトで結論が反転、というのが本記事 Act 2-3 で起きたパターン。1 段で止めるとユースケース外しに気づかない。Edit/IP のような ref を使う mode は generic T2I だけ見てると見落とす要素
  • 固有名詞は地雷。テキスト描画を強化したモデルは、プロンプト内の商標 / 監督名をそのままの文字列として焼き込むリスクがある。A/B で確認する習慣をつける
  • 安価な LLM によるプロンプトエンハンサーは VRAM 制約下の最強手。$0.0002/call で UX が一段上がる。ローカル LLM を増やすと他の機能を殺す可能性がある
  • anime と photoreal は anchor を分ける。スタイルの衝突は物理的なオーバーレイになる

次にやる

  • LoRA: プロンプト工学は anime で限界。HiDream-O1 用の anime LoRA を自前学習して、「美少女キャラ」「コメディ表情」「縦長 9:16 構図」のような特化を切り替えで使えるようにする
  • 構図のバリエーション: 現状の anchor は「室内 magazine shoot」に偏りやすい。outdoor / urban / cinematic location の variant を追加
  • 本番での A/B: /admin/analytics/ で enhance 使用 vs 未使用の retry 率・conversion 差を計測

OpenWeight 拡散モデルでも、プロンプト工学を 1 段噛ませるだけで「ぽん出し失敗」を実用品質に引き上げられる。フロンティアモデルじゃないからと諦める前に、プロンプト側を A/B してみることをおすすめしたい。

実装は kotonia.ai/studio で動いている。「✨ 美的拡張」ボタンがプロンプト入力欄の上にある。無料で試せる。

Kotonia は音声AI、AIチャット、画像生成、チーム共有をひとつにまとめたAIワークスペースです。

試してみる →