Kotonia Articles

HiDream 的“随手出图”崩了 → 转投 Dev → VRAM 爆表 → 用提示词工程打赢的实战记录

HiDream-O1-Image 在日语提示词下“随手出图”崩坏，本想换 Dev-2604 却因 VRAM 不足和编辑性能下降而放弃，最终用 Gemini Flash Lite 打造的提示词增强器解决。文中还发现了 HiDream 特有的 4 个陷阱（品牌名嵌入、cute 导致幼体体型、王家卫触发韩文字幕、idol-class 自动加字幕），并通过 A/B 测试验证。

作者清水真二2026-05-286分钟阅读

#HiDream#扩散模型#提示词工程#Gemini#图像生成

其他语言日语英语

TL;DR

HiDream-O1-Image 8B Full 的“随手出图”在日语提示词下，指令跟随和美学品味会同时崩坏
本想换用 Dev-2604（偏好调优版，速度快 3.5 倍），但在具体用例上差别不大，而且编辑性能大幅下降。两个模型常驻需要 96GB GPU，物理上不可行
最终放弃切换模型，改用 Full + Gemini Flash Lite 打造的提示词增强器，在生成后附加美学修饰
过程中发现了 HiDream 特有的 4 个陷阱（品牌名嵌入 / “cute”导致幼体体型偏差 / “Wong Kar-wai”触发韩文字幕 / “idol-class”自动加字幕），全部写入了增强器的系统提示词
现在，从同一个朴素的日语提示词出发，只需一次点击就能生成 photoreal 和 anime 两种风格

Act 1: “随手出图”翻车了

Kotonia Studio 将 HiDream-O1-Image 8B Full 常驻在本地 GPU（RTX PRO 6000 Blackwell Max-Q 96GB）上，免费提供 T2I 服务。平时出图质量不错。但有一天，我用一个朴素的日语提示词 “穿着旗袍的可爱女性，手持扇子微笑” 时，得到了这样的输出：

raw-kimono-failure

问题很明显：

指定了旗袍，却画成了和服。中华风格被带偏成了和风
脸不够可爱。本想追求 idol-class 的美貌
构图冗余：全身 + 京都风格庭院。其实想要近景，突出扇子的质感

HiDream-O1 在 Artificial Analysis Arena 上也是排名靠前的 OpenWeight 模型，只要用英语提示词仔细写，就能在 2048×2048 分辨率下输出杂志级别的图片。但用日语写个简单请求，效果就崩成这样。

这不是“模型不行”，而是 “用户输入与 OpenWeight 模型的期望值之间存在差距” 的问题。前沿模型可以内部理解自然语言的隐含含义，但 OpenWeight 系模型的设计前提是提示词要直白有力。这很可能是因为编码器部分的容量有限。

是放弃“随手出图”的体验，还是采取什么措施？

Act 2: 用 Dev-2604 能逃过一劫吗？

调查时，我注意到了 2026 年 5 月刚发布的 HiDream-O1-Image-Dev-2604 这个新变体。它在 Artificial Analysis T2I Arena 中排名第 8，只需 28 步 / 无 CFG，速度是 Full 的 3.5 倍。

Arena 是一个对“人类喜欢的图片”进行排名的基准测试。偏好调优应该能改善美学品味。

预期：

Dev 版“即使面对模糊的日语指令，也能返回杂志级别的精修图片”
速度快 3 倍，也能提升 /studio 的体验（步数优化为 28 步）
如果顺利，可以淘汰 Full，统一为 Dev 一个版本

Phase 1 基准测试：用 5 种通用电影感提示词（Tokyo izakaya, Bangkok night market, character anime, text-in-image, portrait）对比 Full 和 Dev-2604：

mode	Full (s)	Dev-2604 (s)	speedup
T2I (avg)	33.1	9.5	3.5×
Edit (avg)	79.0	22.2	3.6×
IP	84.3	23.8	3.5×

在通用场景下，Dev 确实更快，而且观感上也稍微更漂亮。Phase 1 结束时，我觉得“Dev 可行”。

Act 3: 但在具体用例上差别不大，而且编辑性能大幅下降

差点就草率下结论了。Kotonia 的主打方向是“喜剧类短视频 + 美少女吸睛”。Dev 在通用电影感场景上胜出，并不代表它在喜剧角色/表情演技/带字幕的钩子场景上也能胜出。

我以 Grok 生成的 8 张参考图片（cinematic editorial Asian beauty / anime qipao / cinematic hanfu / cosplay maid 等）为基准，制作了 8 种竖屏 1440×2560 (9:16) 的喜剧 + 美少女提示词，进行了 Phase 2 测试。

部分 Grok 参考图（希望达到这种效果）：

杂志风肖像	中华电影感

结果是 Full 的指令跟随性更好！！：

editorial portrait: 平手，美学品味上 Dev 可能稍好一点
anime qipao: Full 的赛璐珞风格完胜。Dev 偏向半写实，无视了 anime 指令。美学品味没问题
hanfu brocade: Dev 在画面中嵌入了“SAVE”字样 (文本幻觉)
comedy 惊讶脸: Full 的表情更具漫画感，且字幕覆盖可读
comedy deadpan: Full 更具体地描绘了“呆滞脸”

Dev-2604 通过偏好调优获得了杂志级的成品效果，但代价是 anime 和角色指令的跟随性下降了。因为它针对杂志风格进行了优化，所以对于非杂志的用例，它会无视指令，试图拉回“杂志风格”的图片。

“两者都好但差别不大”的例子：editorial portrait

把评为平手的图放在一起。同一个 portrait 提示词下 Full 和 Dev 的输出：

Full (近景，戏剧感)	Dev-2604 (远景，杂志风)

Full 的对比度更强，更具戏剧感（窗边的伦勃朗光，较暗的图书室背景），Dev 则更柔和，偏向杂志风（坐姿半身，偏自然光，皮肤更光滑）。两者都“可用”，Dev 的成品稍微柔和一些……差别就这么大。

为了这点差别，付出切换模型的成本（VRAM / 加载时间 / 架构复杂化）并不划算。这就是 Phase 2 的结论。

决定性因素：Edit 和 IP 性能下降

如果只是通用 T2I，Dev 还算一个选项，但 Edit 和 IP（角色一致性）方面，与 Full 的差距非常明显。这也是放弃切换模型的最主要原因。

将一张包含“3 个人物、昏暗小巷、灯笼”的 T2I 输出作为参考图，然后输入 Edit 指令 Same scene, same characters, same composition. Change the weather to a heavy rainy evening; the characters now wearing translucent rain ponchos，结果如下：

Full (保持场景 + 变为雨天)	Dev-2604 (丢弃原场景，生成另一张图)

Full 按照指令生成了“3 人 + 雨披 + 雨中小巷”。Dev 则完全替换成了 1 位穿和服的女性 + 雪中寺庙。完全没有继承参考图的结构（甚至没有遵循文本指令）。这已经属于“编辑功能失效”的级别。

IP（角色一致性）也有同样趋势。将预先生成的 2 张人脸照片作为参考，输入指令“同样的 2 人并排站在秋天的京都参道上”：

Full (大致保持人脸)	Dev-2604 (生成了不同的人)

Full 大致保持了参考图中 2 人的脸。Dev 则 完全是不同的人。推测是因为偏好调优优先了美学效果，导致“生成漂亮的脸”比“保持参考图的身份”更重要。

官方 README 中也明确写着 For editing tasks we recommend using the full model，Phase 1 的基准测试已经确认了这种差异。

不能说“Dev 可行”了。但 Full 也并非完美。Dev 在电影感氛围和通用镜头方面仍有其价值，3.5 倍的速度优势也难以舍弃。

难道只能两者都用，根据情况切换？

Act 4: VRAM 计算导致死局

“那就让两个模型都常驻 GPU 吧”——我这么想着，然后算了算 实际的 GPU 内存预算。目前是 1 张 96GB GPU：

共存进程	常驻 VRAM	峰值 VRAM
E4B (reviewer LLM)	19.6 GB	19.6 GB
31B Gemma 4 NVFP4 (orchestrator)	38.0 GB	38.0 GB
TTS server (Irodori + Whisper)	9.6 GB	9.6 GB
Ditto-TalkingHead	3.0 GB	3.0 GB
LTX-2 A2V (cold-start, fp8-cast)	0.9 GB	24.0 GB (推理中)
HiDream Full (resident)	16.4 GB	17.3 GB
总计	87.5 GB	111.5 GB ← LTX-2 触发时

LTX-2 视频生成一启动，95GB GPU 就已经接近 OOM。如果再加上 Dev-2604 常驻，+16.4 GB，总计 127GB，完全不可行。

列举一下选项：

两者都常驻: 不可能 (如上所述 OOM)
两者都冷启动: 每次请求增加 22s 加载时间 (Full 推理 33s，加载 22s 很伤。空闲时 0GB 很好，但首次用户体验会崩溃)
Dev 常驻 + Full 冷启动: Dev 为主，编辑/IP 用 Full，但 Phase 2 结果推翻了这一假设
Full 常驻 + Dev 冷启动: T2I 时偶尔切换到 Dev，每次加载 22s
放弃 Dev，只用 Full: 维持现状，无法获得速度提升

从服务角度看，选项 1-4 都意味着“让免费用户多等 22s”或“VRAM 不足导致其他功能 (LTX-2 / 31B) 无法运行”。在单人运维、1 张 GPU 运行所有服务的前提下，Dev 的存在意义不大。

至此，我决定 放弃“通过切换模型来提升美学效果”的方案。

Act 5: 能不能用提示词来“打”？

冷静下来重新思考。Dev 比 Full 强在哪里？

仅仅是“美学成品效果”。 指令跟随性方面 Full 更强。

那么，如果能在 Full 上 “保持指令跟随性的同时，仅附加美学成品效果”，就不需要切换模型了。

具体方案：在提示词末尾加上 aesthetic anchor（魔法词尾），让 Full 的生成结果偏向杂志风格。

这样做的好处：

✅ GPU VRAM 成本为 0 (保持 Full 一个模型)
✅ 推理时间不变 (33s/张)
✅ 编辑/IP/骨架/布局等功能仍使用 Full，不受影响（避免了 Act 3 中 Dev 的性能下降）
✅ 没有 Dev 冷启动的 22s 惩罚
⚠️ 剩余风险是“anchor 是否有效”

Phase 3 中，我在 Full 上测试了 4 种 anchor：

v1 Lindbergh 系: "Vogue cover composition, Peter Lindbergh editorial photography..."
v2 电影感系: "Roger Deakins anamorphic, blockbuster color grade..."
v3 K-beauty 系: "Vogue Korea / ELLE Korea aesthetic, glass-skin glow..."
v4 大杂烩: kitchen-sink

3 个基础提示词 (editorial portrait / anime qipao / comedy 惊讶脸) × 5 (baseline + 4 anchor) = 15 次生成。这里暴露了 HiDream 三个极其反直觉的行为。

陷阱 1: 品牌名会作为文字直接嵌入

在 anchor 中加入 "Vogue" "ELLE" 的变体输出中，“VOGUE”字样被直接嵌入了画面。在 anime 输出中尤为明显，赛璐珞风格上直接叠加了杂志 logo。

HiDream-O1 在 CVTG-2K (复杂视觉文本生成) 方面拥有顶级的文本绘制能力。因此它不会将专有名词解释为风格指令，而是直接写到画面上。

→ 从 anchor 中完全排除品牌名。 摄影师/导演名 (Lindbergh / Deakins) 没问题，商标是雷区。

陷阱 2: anime 加上 photoreal anchor → 混入“杂志页面”

给 anime 基础提示词加上所有 photoreal anchor (v1-v4) 后，输出变成了类似 VOGUE 封面布局叠加在赛璐珞角色上 的合成物。

当风格指定矛盾时，扩散模型会生成将两种元素物理叠加的图片。

→ 为 anime 准备专用的 anchor (Mihoyo / 京都动画系)，作为独立分支。

陷阱 3: “Wong Kar-wai” → 触发韩文字幕

在 v5 grok-direction polish anchor 中加入 "Wong Kar-wai-style color grade" 后，photoreal 场景的画面上被嵌入了 “신부의 아안” 等韩文字符。

王家卫是香港导演。模型内部将“Asian arthouse cinema”的联想导向了 Korean，从而产生了文字。导演名如果不经过 A/B 测试，也有雷区风险。

Act 6: 消除 cute → 幼体体型偏差，最终完成

Phase 4 中重写了 anchor：

完全删除品牌名
仅采用安全的人物名 (Lindbergh, Deakins, Mihoyo)
为 anime 添加专用 anchor (Mihoyo / 京都动画系)
在 anime 专用 anchor 中加入 "mature young-adult character proportions"，以抵消 cute → 幼体体型偏差（用户凭直觉发现的行为）

重新进行基准测试：

✅ photoreal portrait: v3 K-beauty 干净，无 VOGUE 嵌入，glass-skin + 电影感灯光
✅ anime: v7 Mihoyo anchor，无杂志混入，保持成人比例
⚠️ 喜剧字幕另行处理 (要么接受自动字幕，要么后期叠加)

至此，“Full + 清理后的 anchor”方案确定。进入实现阶段。

实现: `/api/studio/enhance` (基于 Gemini Flash Lite)

在 backend/src/handlers/studio.rs 中添加 enhance endpoint。LLM 不使用本地 31B Gemma，而是调用 gemini-3.1-flash-lite (廉价 API)。原因：

31B Gemma 占用 38GB 常驻内存。根据之前的 VRAM 计算，已经没有余量再常驻它
Flash Lite 的输入 $0.075/M + 输出 $0.30/M。每次 enhance 约 0.02 日元 (≈$0.0002)，几乎免费
不占用 VRAM，因此添加功能不会“牺牲其他功能”

将 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 的提示词输入框上方添加一个 “✨ 美学增强” 按钮。点击后 POST /api/studio/enhance → 用返回的 enhanced_prompt 替换 textarea 内容 + 显示绿色横幅说明应用的风格 + 提供 Undo 功能。

Act 7: 赢了

将最初展示的“随手出图失败”的同一个朴素日语提示词，通过 enhance 按钮重新提交后的结果：

应用 Photoreal anchor 后

enhanced-photoreal

正确生成了旗袍、近景构图、idol-class 的脸、glass-skin、杂志风格灯光。

应用 Anime anchor 后

enhanced-anime

赛璐珞风格的 anime 风格、中式建筑庭院背景、保持成人比例、扇子的质感也得以保留。

从同一个朴素的日语提示词出发，只需一次点击就能在 photoreal 和 anime 两种风格间切换。保持 Full 一个模型，VRAM 零增加，推理时间不变。

经验总结

从工程判断中获得的教训：

“切换模型”和“提示词工程”应在同一预算框架下比较。既然不是前沿模型，VRAM 和服务的可行性约束会主导模型选择。这次，维持 Full 常驻框架比 Dev-2604 在美学上胜出更重要，是更高优先级的约束
A/B 基准测试应分两阶段进行。通用提示词 → 确信 → 用例提示词 → 结论反转，这正是本文 Act 2-3 中发生的模式。只做第一阶段会忽略用例差异。使用参考图的模式（如 Edit/IP）如果只看通用 T2I，很容易遗漏关键要素
专有名词是雷区。文本绘制能力增强的模型，有将提示词中的商标/导演名作为文字直接嵌入的风险。要养成通过 A/B 测试确认的习惯
基于廉价 LLM 的提示词增强器是 VRAM 约束下的最强手段。每次调用 $0.0002 就能显著提升 UX。增加本地 LLM 可能会影响其他功能
anime 和 photoreal 的 anchor 要分开。风格冲突会导致物理层面的叠加

下一步计划

LoRA: 提示词工程在 anime 方面有极限。计划自行训练 HiDream-O1 专用的 anime LoRA，以便通过切换实现“美少女角色”、“喜剧表情”、“竖屏 9:16 构图”等特定功能
构图变体: 目前的 anchor 容易偏向“室内杂志拍摄”。计划添加 outdoor / urban / cinematic location 的变体
线上 A/B 测试: 在 /admin/analytics/ 中测量使用 enhance 与未使用的重试率、转化率差异

即使是 OpenWeight 扩散模型，只需加入一层提示词工程，就能将“随手出图失败”提升到实用品质。在因为不是前沿模型而放弃之前，建议先在提示词侧进行 A/B 测试。

该功能已在 kotonia.ai/studio 上线。提示词输入框上方有一个“✨ 美学增强”按钮。可以免费试用。