如果你最近在关注 AI 视频，DreamID-Omni 这次值得看，不只是因为它又多了一个“能生成视频”的名字，而是因为它想把一件更麻烦的事一次做好：让人物外观、声音和视频里的动作表达尽量落在同一条生成链路里。对已经在玩 ComfyUI、本地视频工作流或数字人口播内容的人来说，这比单纯多一个视频模型更有意义。

更实际的一点是，这个项目刚开源不久，社区侧已经很快给出了 ComfyUI 节点封装。也就是说，你不一定要从论文代码和推理脚本硬啃起步，而是可以更直接地把它接进现有工作流里。对普通创作者来说，这往往比论文里多几个指标更重要。

DreamID-Omni 到底是什么

根据官方 GitHub 仓库的定义，DreamID-Omni 是一个 “Unified Framework for Controllable Human-Centric Audio-Video Generation”，也就是“以人为中心的可控音视频生成统一框架”。项目作者来自清华大学相关团队，并与字节跳动团队有关联，论文已经发布在 arXiv，代码在 3 月中旬放出。

这句话看起来很学术，翻成更容易理解的话，大概就是：

• 你给它人物参考图
• 再给它参考音频
• 然后用提示词描述场景、动作和说话内容
• 它尝试生成一个人物身份、声音风格和画面表达相互配合的视频

和很多只强调“图生视频”或“语音驱动口播”的方案不同，DreamID-Omni 想解决的是更完整的人物驱动问题。尤其是在角色内容、数字人短视频、对话式视频这些场景里，大家最怕的往往不是视频生成不出来，而是脸不像、声音不稳、说话和角色对应不上。这恰恰是它试图统一处理的方向。

它能做什么，为什么会让创作者在意

从官方仓库和 ComfyUI 节点说明来看，DreamID-Omni 目前至少有几个很直接的卖点。

1. 支持人物身份尽量保持一致

项目强调 identity-preserving，也就是身份保留。简单说，你提供的参考人物图像不只是“风格参考”，而是尽量作为生成中角色身份的锚点。对于做虚拟角色、固定 IP 账号、人物口播内容的人来说，这一点非常关键。

因为很多视频模型能出动态，但不一定能守住人物；能守住人物的，又未必能把语音和动作一起接好。DreamID-Omni 的吸引力就在于，它不是只补一个单点能力，而是在尝试把这些关键能力打通。

2. 不只是单人，还支持双人场景

官方示例和 RunningHub 的 ComfyUI 节点都提到，DreamID-Omni 不仅支持单人模式，也支持双人模式。也就是说，你可以给两个人物分别提供参考图和参考音频，去生成对话、互动类画面。

这比普通 talking-head 更进一步。单人口播大家已经见得很多了，但双人互动一旦能稳定下来，适用场景会明显扩大，比如：

• AI 角色对谈
• 知识类双人讲解
• 剧情短片的简化制作
• 虚拟主播之间的互动内容

当然，支持双人不等于所有情况下都很稳，但至少说明这个项目从一开始就不是只瞄准最基础的“一个人对口型讲话”。

3. 提示词里可以直接控制“谁在说话”

DreamID-Omni 的一个重要设计，是通过特殊标签在提示词里标记角色身份和 speech 内容。官方说明里提到，提示词中可以用角色标记去指定谁在行动、谁在说话，文本里的 speech 标签会转成对应角色的语音表达。

这件事听起来技术味很重，但对创作者很有价值，因为它把“人物绑定”和“台词绑定”放进了同一套提示结构里。换句话说，生成不只是“给一个音频配一张嘴”，而是试图把角色、场景、动作和说话关系写进同一个生成描述里。

这次最实用的变化：已经能接进 ComfyUI

如果只有论文和原始代码，这类项目对很多人来说仍然偏远。真正让它更有讨论价值的，是 HM-RunningHub 已经放出了对应的 ComfyUI 插件仓库。

从节点仓库的介绍看，这个插件的核心价值很明确：把 DreamID-Omni 封装成 ComfyUI 可调用的节点，并且输出标准 VIDEO 类型，能更自然地接入现有视频工作流。对习惯用 ComfyUI 拼节点的人来说，这比单独维护一套 Python 推理环境友好多了。

节点说明里还给出了比较清晰的输入结构：

• prompt
• 采样步数
• seed
• 分辨率
• 参考人脸图
• 第二人物参考图（可选）
• 参考音频
• 第二人物参考音频（可选）

这意味着它已经不是“只能看论文复现思路”的阶段，而是开始进入“创作者可以直接摸工作流、调参数、看结果”的阶段。对于开源项目来说，这种生态跟进速度往往很重要。模型本身强不强是一回事，能不能快速进入工具链是另一回事。

但它不是低门槛玩具，硬件和部署成本要先想清楚

如果你看到“ComfyUI 节点已上线”就以为能随手在普通电脑上开跑，那大概率会失望。

RunningHub 节点仓库写得很直接：默认的 992×512 分辨率，是按 24GB 显存 GPU 做了相对优化的。仓库还提到 BF16 精度与动态 FP8 量化，以便降低显存压力。这些信息已经足够说明，DreamID-Omni 不是轻量化小工具，而是一个依赖比较重、模型组合也比较复杂的系统。

从模型结构说明看，你不仅要处理 DreamID-Omni 本体，还要配套文本编码器、VAE，以及 MMAudio 相关权重。对没有本地部署经验的人来说，光是把目录结构和依赖摆对，就已经是一轮筛选。

所以更准确的预期应该是：

• 它适合已经有 ComfyUI 使用经验的人
• 适合愿意折腾模型和依赖的人
• 适合本地显卡条件还不错的玩家或工作室
• 不太适合把它当成“零门槛一键神器”的新手

哪些场景适合它，哪些场景别抱太高期待

适合的场景

角色口播与数字人短视频。

如果你本来就在做固定人设账号，或者需要让某个角色稳定出镜，DreamID-Omni 这种“参考脸 + 参考音频 + 提示词”的组合会比普通视频模型更对路。

双人对话和角色互动。

当一个框架同时支持两个人物的图像和音频绑定时，它天然就更适合访谈、对话、剧情切片这种内容结构。

ComfyUI 进阶工作流实验。

对已经在 ComfyUI 里做视频生成、放大、修复、后处理的人来说，这类节点最容易被接进现有链路里继续放大价值，而不是孤立地跑一次演示。

不太适合的场景

低配电脑直接试玩。

如果你的硬件本来就比较吃紧，或者不想为一个项目处理多套模型权重和依赖，这条路不会轻松。

追求极稳定商业生产。

新开源项目最吸引人的地方是新能力，但也意味着工作流还在快速变化。要拿它直接撑高强度生产线，通常还需要更长时间验证。

超长、复杂叙事视频。

它更像是人物驱动生成能力的一次增强，而不是已经把复杂剧情长视频的连续稳定性问题全部解决了。

如果你想试，最省时间的路径是什么

对于大多数人，比较省时间的顺序不是先下全套模型，而是先做三步判断。

第一步，先看原视频演示，确认它展示出来的效果是不是你真正需要的方向。很多人看到“统一框架”会很兴奋，但真正关心的可能只是固定角色口播，或者只是双人对话，这时先看演示比盲目部署更省时间。

第二步，直接看官方 GitHub 仓库。这里能最快确认三件事：项目是不是刚发布、依赖有多重、推理入口是什么。官方仓库目前已经明确给出了下载权重、环境安装、推理命令，以及与 vLLM-omni 的衔接说明。

第三步，再决定是否走 ComfyUI 节点。对于已经有 ComfyUI 工作流的人，这通常是最自然的入口；对于完全没接触过节点工作流的人，先理解官方原始结构反而更不容易踩坑。

该怎么看 DreamID-Omni 这次开源

DreamID-Omni 的价值，不只是“又来一个 AI 视频项目”，而是它把人物身份、语音和视频生成这些过去经常分散处理的能力，往统一框架方向推了一步。更关键的是，社区很快补上了 ComfyUI 节点，这让它从“论文级项目”更快变成“创作者可试用的工具”。

现阶段当然还不能把它神化。它依然有硬件门槛，也依然需要时间验证在更多人物、更多场景、更多时长下的稳定性。但如果你本来就关注角色一致性、数字人口播、双人互动视频，或者你是长期折腾 ComfyUI 的用户，那 DreamID-Omni 确实值得放进最近的跟进清单里。

参考来源

• B站原视频：https://www.bilibili.com/video/BV14VwezbEVW
• DreamID-Omni GitHub：https://github.com/Guoxu1233/DreamID-Omni
• DreamID-Omni 论文：https://arxiv.org/abs/2602.12160
• ComfyUI 节点：https://github.com/HM-RunningHub/ComfyUI_RH_Dreamid-Omni

参考来源

• https://www.bilibili.com/video/BV14VwezbEVW
• https://github.com/Guoxu1233/DreamID-Omni

说明：该页面由基础模板稳定生成，后续可继续局部润色样式或补充模块，再进入发布检查。