ComfyUI+MiniMaxH3角色替换工作流全攻略：从单人到分钟级长视频

MiniMaxH3 在 ComfyUI 里做人物替换，最近的讨论热度确实很高。核心卖点不是传统意义上的“换脸”，而是动作迁移和角色替换一起做：给定一段源视频，让目标角色沿用原视频的动作、走位和表演节奏，重新生成一段新画面。整套流程特别适合跳舞视频转绘、打戏翻拍和剧情名场面的角色替换。

先说结论：单人替换，环境配好之后不算难；多人替换和分钟级长视频转绘才是真正卡人的地方。很多人第一次跑通单人物替换后会以为“多人替换就是复制粘贴”，实际上一旦涉及两个以上角色，身份混淆、动作叠加、空间关系不稳都会冒出来。下面按实际落地顺序拆一遍，先从最基础的环境和模型准备说起。

1. 先搞清楚 MiniMaxH3 角色替换工作流到底做了什么

1.1 它解决的是“换角色不换动作”的问题

传统换脸方案通常只处理人脸区域，动作、服装、场景基本不变。MiniMaxH3 这类视频生成模型不一样，它是在视频生成框架里做角色替换：输入一段参考视频，再给一张目标角色的参考图，模型会把目标角色的外貌特征迁移到参考视频的动作骨架和运动轨迹上。

这意味着你可以让一个完全不同的角色，去跳同一支舞、打同一套动作、走同一段剧情。

动作迁移和角色替换是两条线，又经常耦合在一起。单纯动作迁移，可以不用指定角色；单纯角色替换，可以不用参考视频里的具体动作。但实际工作流里往往是两条线一起跑，所以很多人会遇到一个问题：角色是换上了，但动作也跟着变了；或者动作保住了，角色脸又崩了。

这类工作流的实际价值，不只是“换个人这么简单”，而是把“表演”本身保留下来。对想做二创、短视频分镜、游戏角色演示、虚拟主播内容的人来说，这个能力比单张图的局部重绘有用得多。

1.2 为什么这条工作流会在 ComfyUI 里火起来

ComfyUI 的节点式编排，天然适合把“模型加载、视频输入、提示词控制、采样、输出保存”拆成一块块独立组件。 MiniMaxH3 能被社区拿来搭建角色替换工作流，主要原因有三个：

一是节点可复现。别人分享的工作流文件导入后，只要环境一致，结果基本能对齐。二是参数可调整。提示词权重、参考图强度、采样步数、分辨率、时长，都能逐项改，方便针对不同视频素材做调试。三是生态补齐得快。模型文件、自定义节点、示例工作流，社区分享速度很快，不需要从零写代码。

但这也是坑的来源。ComfyUI 本身只是框架，真正决定工作流能不能跑起来的是模型文件、自定义节点和依赖包。很多人导入工作流后看到那句“请安装缺失的包以使用此工作流”，就开始到处找包，却不先确认模型文件有没有放对位置。

2. 跑通之前，先把环境、模型、工作流三件事排干净

2.1 确认你的机器能承载多重的任务

MiniMaxH3 角色替换工作流，最核心的硬件瓶颈是 GPU 显存。

如果你只是处理一段 5 秒到 10 秒的短视频，分辨率控制在 720p 左右，批量数不开太大，那么 8GB 到 12GB 显存有希望跑通，但速度会比较慢。处理 20 秒以上的长视频，或者分辨率拉到 1080p，显存很容易不够用。如果机器显存只有 6GB，建议先把分辨率降到 512 或 640，帧数也砍短，先用小样验证流程。

这里有一个容易被忽略的点：显存占用不只看模型体积，还看“视频长度 × 分辨率 × 批量数”。

视频越长，单次要处理的帧越多，显存压力越大；分辨率越高，特征图越大，同样吃显存；批量数一旦大于 1，显存占用会成倍往上走。我的建议是：第一次跑，先用 2 秒到 3 秒的短片，分辨率不要超过 640，这样能快速暴露环境问题，而不是一上来就被 OOM 卡住。

内存建议 16GB 起步，32GB 更稳。磁盘空间需要预留，模型文件加上 ComfyUI 本身的依赖，几十 GB 是常见的。如果你的磁盘剩余不足 50GB，安装前要先清理。

2.2 安装 ComfyUI：整合包还是手动部署

新手优先考虑整合包，省去很多依赖编译的麻烦。社区流行的秋叶整合包之类，好处是自带 Python 环境、常用节点和启动器，鼠标点几下就能启动。

有经验的人可以手动部署，流程大致是：安装 Python、克隆 ComfyUI 仓库、创建虚拟环境、安装依赖、启动。手动部署的好处是灵活，不会被迫使用整合包预置的固定版本；坏处是依赖冲突比较多，尤其是不同自定义节点对 torch 版本要求不一致的时候。

如果你之前已经装了 ComfyUI，并且导入工作流时报缺失节点，不要急着重装整个 ComfyUI。先看缺失的是哪些节点，再用 ComfyUI Manager 或者命令行补装对应依赖。

有一点要特别提醒：整合包里自带 Python 环境和依赖，如果你同时有系统级 Python 或 Anaconda，进入 ComfyUI 所在虚拟环境后再执行 pip install，避免装错环境。

2.3 模型和自定义节点怎么放

MiniMaxH3 工作流要正常运行，至少需要三类文件：

具体路径会因为工作流作者封装方式不同而有差异，不能一概而论。我建议导入工作流后，先逐个双击节点看它引用的文件名和路径前缀，再对着目录去检查。

这里最容易踩的坑是：模型文件名对不上。明明下载了模型，但工作流里写死了另一个文件名，加载时照样报错。处理方法很简单，把模型文件名改成工作流引用的名字，或者用节点里新的文件选择器重新指定。

如果你下载的是别人打包好的“整合包级”工作流，里面可能自带模型文件路径说明，这时候先按说明放。没有说明的话，不要乱猜目录。

3. 单人替换先从最小样例开始

3.1 最小工作流的完整链路

不要一上来就导入那种十几个甚至几十个节点的大工作流。建议先用最小链路跑通：加载参考视频、加载目标角色参考图、加载 MiniMaxH3 模型、输入提示词、设置采样参数、输出视频。

大致节点顺序如下，具体节点名称因工作流而异：

加载参考视频 -> 拆分/采样视频帧 加载目标角色参考图 -> 编码图像特征 加载 MiniMaxH3 模型 -> 模型加载节点 提示词输入 -> 文本编码 采样器 -> 生成视频帧 VAE 解码 -> 输出视频

这套链路的核心思路是：模型同时接收视频帧、角色参考图和文本提示词，然后在潜在空间里完成动作保留和角色替换。

第一次跑的时候，提示词不要写复杂。

比如：“保留参考视频的动作和镜头运动，将视频中的人物替换为参考图中的角色，保持动作一致。”

像“光影、氛围、服装质感、背景细节”这类描述，可以先不写，等主流程稳定了再加。

如果你下载的工作流里包含了“导演台”“Skill”这类额外节点，不要过分依赖它们。它们通常是帮你管理提示词或角色描述用的，不是核心生成链路的一部分。先跳过这些附加节点，用最小链路拿到输出，再回头看附加节点到底做了什么。

3.2 核心参数怎么看

同样的工作流，参数设置不同，结果差距很大。下面列几个最容易影响的参数，给的是通用判断口径，具体数值以你下载的工作流的默认值为准。

很多人一上来就把分辨率拉满，然后遇到 OOM，以为是模型跑不动。实际上不一定是显存不够，而是“分辨率 × 批量数 × 视频长度”三个因素叠在一起导致的。先把这三个值降到最低，能跑通再逐步往上加。

3.3 跑通之后先验收三件事

输出视频拿到手之后，不要只看“像不像”，要看三点：

第一，动作有没有被保留。原视频里的转身、抬手、步伐、节奏是否一致。如果动作被改得面目全非，说明参考视频的控制力不够，或者提示词里对动作的描述和目标角色参数冲突。

第二，角色是不是一致。角色脸部、发型、服装，在视频不同帧里是否稳定。如果同一个角色在不同帧里长相不一样，说明参考图的约束不够，或者视频长度太长导致时序漂移。

第三，帧间闪烁严不严重。背景和角色的边缘有没有高频抖动。严重闪烁通常不是模型能力不行，而是分辨率太低、视频长度太长，或者参考视频本身画质不稳定。

如果三个标准都能过，再进入动作迁移和多人场景。如果连单人替换都稳不住，先不要急着搞多人，不然翻车之后你都不知道该改哪个参数。

4. 动作迁移：把一个人的动作完整搬给另一个角色

4.1 动作迁移和单人替换的差别

单人替换可以简单理解成“用新角色重新演绎源视频动作”，而动作迁移更强调“动作本身是主角”。同一个角色替换工作流，当你把提示词从“替换人物”改成“保留动作、改变角色”时，其实就已经在做动作迁移了。

两者真正的差别在于控制重点：

替换角色，主要靠参考图的约束力；迁移动作，主要靠参考视频的约束力。

实操里经常出现一种情况：参考视频里的人物动作被弱化了，新角色做出来的动作像“情绪表演”而不是“原动作复现”。这时候优先检查参考视频的处理方式。有些工作流会对视频抽帧，并把每一帧图片传入模型；如果你导入的视频帧率或分辨率太低，模型根本看不清动作细节。

4.2 输入材料的处理：源视频、目标角色参考图、提示词

源视频不是越清晰越好，而是“动作清晰”最好。一段背景乱、人物小、镜头狂抖的视频，模型提取动作特征的难度很高。

我建议准备源视频时，先做一次简单裁剪：

• 把人物放在画面中心偏上的位置，避免频繁出画
• 去掉开头结尾多余的黑场和字幕
• 如果原视频有摄像机大幅运动，考虑先做稳定处理
• 同一段视频不要反复转码，尽量用原始画质

目标角色参考图同样关键。参考图要满足：正脸清晰、五官可见、光线均匀、背景简单。不要用那种脸部被头发遮挡、侧面大角度、分辨率极低、滤镜严重的图。

提示词这块，我建议使用“动作描述 + 角色描述 + 画面风格描述”三段式写法。拿跳舞视频举例：

提示词示例： 保持参考视频中的舞蹈动作和节奏。 角色外貌以参考图为准，脸部特征、发型、服装保持一致。 画面风格自然写实，光线和背景尽量接近原视频。

如果工作流里支持负面提示词，可以写“角色面部扭曲、肢体不自然、闪烁、鬼影、两个角色同时出现”这类描述。但负面提示词权重不要一次拉得太高，不然容易把整个画面细节都压掉。

4.3 动作为什么会崩

动作崩掉有好几种表现，成因不一样。

表现一：动作幅度变小，很多动作被“平滑”掉了。这种通常是因为参考视频的帧率过低，或者采样步数不够，动作轨迹没有完全被编码。

表现二：动作整体保留，但角色像“贴”在动作上，看起来不自然。这可能是因为目标角色参考图和源视频中人物的体型、镜头视角相差太大，模型无法把动作精确映射到新角色上。

表现三：动作做了几秒之后开始漂移，后半段角色偏离原视频中的人物位置。这种大概率是视频太长，超出了模型稳定生成的安全长度。先切短视频，分两段处理。

还有一个非常常见的低级错误：参考视频里的“人物动作”和“镜头运动”被混为一谈。如果原视频镜头快速平移或缩放，模型可能把镜头运动当成动作的一部分，导致新角色也跟着镜头做出一堆奇怪的小动作。遇到这种情况，可以单独写一句“保持镜头运动不变，人物动作与参考视频一致”。

5. 多人场景：第二式的核心难点为什么是“稳住”

5.1 多人替换会翻车的几个典型原因

单人替换的流程可以概括为“一个参考视频 + 一个参考角色图”。到了多人场景，输入就变成“一个参考视频 + 多个不同角色参考图”。问题在于，模型需要同时区分不同人物的外貌特征、空间位置和动作分配，难度不是翻一倍，而是非线性上升。

翻车表现最多的有三种：

第一，身份混淆。两个角色互相“串脸”，A 的脸跑到 B 身上，或者 AB 五官混合在一起。这说明工作流对多个参考角色没有做足够的锚定。

第二，动作叠加。A 的动作和 B 的动作互相“传染”，画面里出现类似双人同步动作的诡异效果。这是因为模型分不清哪段动作属于哪个角色。

第三，空间关系不稳。原视频里 A 站在左边、B 站在右边，替换后两人位置漂移，甚至交错。这种通常需要显式指定空间位置和人物相对关系。

5.2 更稳的做法：逐个锚定

即使工作流支持多人替换，我也不建议一上来就同时替换三个人。

更稳的顺序是：

第一次测试，替换主角，保留其他角色不变，确认主角位置和动作稳定。第二次测试，再加入一个角色，两个角色参考图分开，提示词里分别描述两人的身份和位置。确认双人稳定后，再逐步增加第三人、第四人。

如果工作流支持“角色分节点”的设定，让每个角色单独走一条参考图分支，那就尽量分开。不要把几个角色的参考图拼成一张大图再传进模型，那样模型很难分离不同特征。

提示词也要拆开写，优先级从主角开始降序排列。可以这样组织：

第一角色：参考左侧参考图，位置在画面左侧，负责主要动作。 第二角色：参考右侧参考图，位置在画面右侧，动作保持与源视频一致。 两人始终保持相对位置不变，不互相遮挡。

这里的关键是“把角色的外貌、位置、动作分成三个维度来控”。有些工作流会把位置信息直接写进节点参数里，不需要靠提示词；有些则需要你通过区域控制节点来实现。具体怎么实现，取决于工作流作者如何封装。

5.3 多人替换的验收标准和参数微调方向

多人替换的验收标准，要比单人替换多两条：

• 每个角色各自的身份是否从头到尾一致
• 角色间的相对空间位置是否稳定
• 每个角色是否都保留了自己的动作，有没有发生“动作传染”
• 同一个镜头里是否出现重叠、穿模、鬼影

如果角色互相“串脸”，优先检查参考图分支是否独立，提示词里的角色描述有无歧义。如果动作叠加，先降低提示词总权重，再把各个角色的动作描述写得更具体。如果位置漂移，看看工作流有没有位置参数或区域控制节点，把它显式固定下来。

多人替换里最常见的错误，是一次性把所有角色参考图都塞进同一个“参考图像”输入口。输入口不是不能放多张图，而是模型需要明确区分“哪张图对应哪个角色的什么位置”，如果你的工作流没有这个机制，就等着翻车。

6. 分钟级长视频转绘：跳舞、打戏和剧情名场面的实战思路

6.1 “分钟级”真正的门槛不是模型，而是显存和一致性

标题里提到的“分钟级”转绘，很多人都理解成“让模型直接生成一分钟长视频”。实际上，单次直接生成一分钟视频对显存的要求非常高，大多数普通显卡撑不住。更常见的做法是分段生成，再把片段拼接起来。

但分段生成会带来一个新问题：一致性。

前一段视频里角色穿的是红衣服，下一段生成时可能就变成了蓝衣服。上一段里角色脸型偏瘦，下一段里可能就偏圆了。这是因为每个片段都是独立生成，模型没有“记住”上一段视频里的中间状态。

解决思路有两个层面：

一是工具层面。有些工作流会把前一帧或前几帧作为下一段的输入条件，帮助模型延续上文。你下载的工作流如果带有“首尾帧衔接”或“视频延展”类节点，优先使用这类逻辑。

二是素材层面。把原视频切成片段后，每个片段的首帧画面尽量选在动作变化不大的位置，不要在剧烈动作中间切。片段切换点越平滑，拼接时越不容易出现跳变。

6.2 分段转绘与断点续跑

分段转绘的具体顺序可以这样：

1. 把原视频按 5 秒到 10 秒切成片段，每个片段保留 1 到 2 秒的重叠
2. 对每个片段独立做角色替换或动作迁移
3. 检查每个片段的角色身份、服装、发型是否一致
4. 用剪辑工具把片段按时间顺序拼接
5. 拼接处如果出现跳变，用转场或过渡节点轻微模糊处理

如果你的显卡显存只有 8GB 左右，单段视频建议从 5 秒以内开始尝试。先看单段输出是否稳定，再逐步增加单段时长。

分段处理还有一个潜在好处：便于断点续跑。长视频如果一次性处理，中途 OOM 一次，前面所有结果就全丢了。分段处理时，每段输出单独命名，哪一段失败就重算哪一段，不用整条重跑。

输出文件命名建议用“序号_片段起点_片段终点”的格式。比如clip_01_0000_0005.mp4，这样即使处理到第 8 段，也不会因为文件名混乱不知道哪段是新的。

6.3 跳舞、打戏、剧情名场面三类场景的差异

三类场景看起来都是视频，实际难点的侧重完全不一样。

跳舞视频的主要难点是节奏和韵律。动作是连贯的，一旦某个片段生成结果在拍点上偏了，整个舞蹈看起来就不对。调参时更关注动作连续性，参考视频的帧率和运动轨迹质量比画质更关键。

打戏的难点是大幅度动作、快速位移和遮挡。拳头、腿、刀剑这些运动物体容易出现模糊或残影，角色之间的遮挡关系也可能处理不好。遇到这类素材，不要追求一步到位，先把分辨率降下来跑通，再逐段优化。

剧情名场面的难点是镜头多、景别多、角色多。一个镜头是近景，下个镜头是全景，再下个镜头可能切到背影。不同景别下角色的脸部特征、服装细节要保持一致。处理剧情类素材时，先整理一份“镜头清单”，每个镜头单独跑，而不是把整段长视频丢进去一次性生成。

如果做的是“转绘”而不是“实拍视频角色替换”，还要额外考虑画风一致性。原视频如果是动漫，目标角色也应该是动漫画风；如果是写实视频，就别用二次元参考图。画风差异太大时，模型会试图“融合”两种风格，结果就是既不写实也不二次元。

7. 报错和现象排查：先看日志再改参数

7.1 最常见的一批问题

根据社区里大量工作流分享的反馈，下面几类问题出现频率最高：

缺包缺节点：

导入工作流后提示找不到某个自定义节点或 Python 包。这种问题一般在启动 ComfyUI 时会在控制台打出缺失列表。补装之后重启，再重新加载工作流。

模型文件路径或名称错误：

节点显示红色，提示找不到某个模型文件。双击节点看引用的具体路径，再到对应目录核对文件名。

显存不足 OOM：

采样过程中直接报 CUDA out of memory。先降低分辨率、减少帧数、把批处理数改为 1，再看是否还有问题。

输出黑屏或纯静态帧：

生成出的视频是黑屏，或者只有一帧画面在动。先检查输入视频有没有正确传到模型节点，再检查 VAE 解码和输出节点路径。

速度极慢：

单次生成耗时很长。先看分辨率、步数、批量数，再看是否在同一个工作流里加载了多个大模型，很多工作流会把不必要的模型一起加载。

7.2 排查链路

遇到问题时，我建议按这个顺序排查，不要一上来就改模型参数。

这个顺序的核心逻辑是：先用成本最低的方式排除大概率问题，再进入耗时较高的参数调试。

7.3 输出不理想的调整顺序

如果输出视频能生成，但效果不满意，不建议同时改所有参数。一次只改一个变量，然后对比前后输出。

按个人经验，优先调整顺序是：

第一，先确认输入。原视频动作是否清晰、参考图是否规范。很多效果差是输入材料本身不合格，不是模型参数问题。

第二，再改提示词。把角色外貌、动作、镜头、风格拆成四条，分别调整权重。

第三，改采样步数和分辨率。步数从 20 往 30 加，分辨率从 640 往 768 加，看画质是否有明显提升。

第四，调整视频长度。如果 8 秒以上的片段开始出现漂移，果断切成 5 秒一段。

如果所有参数都试过后还是不理想，就要考虑工作流版本或模型文件是否匹配。有些工作流是针对某个 MiniMaxH3 版本做的，换了模型文件后行为差异很大，这个很难通过调参解决，只能换回匹配版本。

8. 真正落地时，最该盯住的是资源占用和失败重试

跑了几轮之后会发现，MiniMaxH3 角色替换工作流最核心的竞争力确实是“动作迁移 + 角色替换”的组合能力，但真正要做生产化使用，单条跑通只是第一步。

如果你只是个人学习，默认参数、短片段、单人物替换，已经够用。如果你是想处理批量视频，或者想把工作流接到更稳定的流程里，需要额外考虑几件事。

第一，日志要有时间、片段号和输出文件路径。一次批量转绘十几个片段时，没有日志根本不知道哪段卡住了。第二，输出命名必须规则化。不要用默认的 timestamp 文件名，否则失败重试时很难判断新旧文件。第三，任务队列要提前规划。不要用人工盯屏的方式处理长视频，分段任务最好通过队列依次执行，减少显存释放不干净导致的资源浪费。

另外，批量处理时不要把所有任务一次性丢进去跑。之前我试过连续跑 10 段视频，前三段正常，第四段开始帧率变化、角色漂移。不是模型坏了，而是连续高强度计算后显存温度升高、资源没有完全释放。我建议每处理 5 到 6 段后重启一次 ComfyUI，或者至少清空一次模型缓存，再继续下一批。

踩过几次坑之后，我的体感是：很多问题不是 MiniMaxH3 本身能力不够，而是输入材料和前置环境没有处理干净。你给它一段动作不清晰的参考视频，它只能还你一段动作混乱的输出；你给它一张脸部模糊的角色参考图，它能生成的也就只有模糊的角色脸。先把输入质量提上来，参数调试才有意义。

如果你正准备入坑这套工作流，我的建议是：先不要看那些几十个节点、一堆附加功能的“全能大工作流”，从最小可运行链路开始，跑通单人短片段，再加动作迁移，再尝试多人，最后才挑战分钟级长视频。每一步都确认稳定了再往下一层走。这样看起来慢，反而是到最终目标最快的路。