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 工作流要正常运行至少需要三类文件文件类型常见放置位置作用MiniMaxH3 模型文件ComfyUI/models/checkpoints 或指定子目录生成视频时真正调用的核心模型文本编码器/辅助模型ComfyUI/models/text_encoders 等处理提示词和参考图语义自定义节点ComfyUI/custom_nodes提供加载、采样、输出等节点能力具体路径会因为工作流作者封装方式不同而有差异不能一概而论。我建议导入工作流后先逐个双击节点看它引用的文件名和路径前缀再对着目录去检查。这里最容易踩的坑是模型文件名对不上。明明下载了模型但工作流里写死了另一个文件名加载时照样报错。处理方法很简单把模型文件名改成工作流引用的名字或者用节点里新的文件选择器重新指定。如果你下载的是别人打包好的“整合包级”工作流里面可能自带模型文件路径说明这时候先按说明放。没有说明的话不要乱猜目录。3. 单人替换先从最小样例开始3.1 最小工作流的完整链路不要一上来就导入那种十几个甚至几十个节点的大工作流。建议先用最小链路跑通加载参考视频、加载目标角色参考图、加载 MiniMaxH3 模型、输入提示词、设置采样参数、输出视频。大致节点顺序如下具体节点名称因工作流而异加载参考视频 - 拆分/采样视频帧 加载目标角色参考图 - 编码图像特征 加载 MiniMaxH3 模型 - 模型加载节点 提示词输入 - 文本编码 采样器 - 生成视频帧 VAE 解码 - 输出视频这套链路的核心思路是模型同时接收视频帧、角色参考图和文本提示词然后在潜在空间里完成动作保留和角色替换。第一次跑的时候提示词不要写复杂。比如“保留参考视频的动作和镜头运动将视频中的人物替换为参考图中的角色保持动作一致。”像“光影、氛围、服装质感、背景细节”这类描述可以先不写等主流程稳定了再加。如果你下载的工作流里包含了“导演台”“Skill”这类额外节点不要过分依赖它们。它们通常是帮你管理提示词或角色描述用的不是核心生成链路的一部分。先跳过这些附加节点用最小链路拿到输出再回头看附加节点到底做了什么。3.2 核心参数怎么看同样的工作流参数设置不同结果差距很大。下面列几个最容易影响的参数给的是通用判断口径具体数值以你下载的工作流的默认值为准。参数影响建议分辨率越高质量越好但显存占用直线上升第一次用 512 或 640别直接上 1080视频长度/帧数越长越难保持时序一致第一次控制在 2 到 3 秒批量数影响并行生成的片段数量默认 1先不要开大采样步数越高细节越充分但速度越慢一般 20 到 30 步比较常见提示词权重控制文本对生成结果的影响强度权重过高容易压制参考视频动作随机种子控制生成随机性固定种子便于复现和排错很多人一上来就把分辨率拉满然后遇到 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 分段转绘与断点续跑分段转绘的具体顺序可以这样把原视频按 5 秒到 10 秒切成片段每个片段保留 1 到 2 秒的重叠对每个片段独立做角色替换或动作迁移检查每个片段的角色身份、服装、发型是否一致用剪辑工具把片段按时间顺序拼接拼接处如果出现跳变用转场或过渡节点轻微模糊处理如果你的显卡显存只有 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 排查链路遇到问题时我建议按这个顺序排查不要一上来就改模型参数。顺序检查对象看什么1现象是报错、卡住、输出黑屏还是输出质量差2输入视频帧率、分辨率、格式、路径参考图是否清晰3环境依赖版本、模型文件是否齐全、显存和内存占用4参数分辨率、批量数、视频长度、采样步数、提示词权重5工作流本身节点连线是否正确、是否有冗余节点、版本是否匹配这个顺序的核心逻辑是先用成本最低的方式排除大概率问题再进入耗时较高的参数调试。7.3 输出不理想的调整顺序如果输出视频能生成但效果不满意不建议同时改所有参数。一次只改一个变量然后对比前后输出。按个人经验优先调整顺序是第一先确认输入。原视频动作是否清晰、参考图是否规范。很多效果差是输入材料本身不合格不是模型参数问题。第二再改提示词。把角色外貌、动作、镜头、风格拆成四条分别调整权重。第三改采样步数和分辨率。步数从 20 往 30 加分辨率从 640 往 768 加看画质是否有明显提升。第四调整视频长度。如果 8 秒以上的片段开始出现漂移果断切成 5 秒一段。如果所有参数都试过后还是不理想就要考虑工作流版本或模型文件是否匹配。有些工作流是针对某个 MiniMaxH3 版本做的换了模型文件后行为差异很大这个很难通过调参解决只能换回匹配版本。8. 真正落地时最该盯住的是资源占用和失败重试跑了几轮之后会发现MiniMaxH3 角色替换工作流最核心的竞争力确实是“动作迁移 角色替换”的组合能力但真正要做生产化使用单条跑通只是第一步。如果你只是个人学习默认参数、短片段、单人物替换已经够用。如果你是想处理批量视频或者想把工作流接到更稳定的流程里需要额外考虑几件事。第一日志要有时间、片段号和输出文件路径。一次批量转绘十几个片段时没有日志根本不知道哪段卡住了。第二输出命名必须规则化。不要用默认的 timestamp 文件名否则失败重试时很难判断新旧文件。第三任务队列要提前规划。不要用人工盯屏的方式处理长视频分段任务最好通过队列依次执行减少显存释放不干净导致的资源浪费。另外批量处理时不要把所有任务一次性丢进去跑。之前我试过连续跑 10 段视频前三段正常第四段开始帧率变化、角色漂移。不是模型坏了而是连续高强度计算后显存温度升高、资源没有完全释放。我建议每处理 5 到 6 段后重启一次 ComfyUI或者至少清空一次模型缓存再继续下一批。踩过几次坑之后我的体感是很多问题不是 MiniMaxH3 本身能力不够而是输入材料和前置环境没有处理干净。你给它一段动作不清晰的参考视频它只能还你一段动作混乱的输出你给它一张脸部模糊的角色参考图它能生成的也就只有模糊的角色脸。先把输入质量提上来参数调试才有意义。如果你正准备入坑这套工作流我的建议是先不要看那些几十个节点、一堆附加功能的“全能大工作流”从最小可运行链路开始跑通单人短片段再加动作迁移再尝试多人最后才挑战分钟级长视频。每一步都确认稳定了再往下一层走。这样看起来慢反而是到最终目标最快的路。
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 工作流要正常运行至少需要三类文件文件类型常见放置位置作用MiniMaxH3 模型文件ComfyUI/models/checkpoints 或指定子目录生成视频时真正调用的核心模型文本编码器/辅助模型ComfyUI/models/text_encoders 等处理提示词和参考图语义自定义节点ComfyUI/custom_nodes提供加载、采样、输出等节点能力具体路径会因为工作流作者封装方式不同而有差异不能一概而论。我建议导入工作流后先逐个双击节点看它引用的文件名和路径前缀再对着目录去检查。这里最容易踩的坑是模型文件名对不上。明明下载了模型但工作流里写死了另一个文件名加载时照样报错。处理方法很简单把模型文件名改成工作流引用的名字或者用节点里新的文件选择器重新指定。如果你下载的是别人打包好的“整合包级”工作流里面可能自带模型文件路径说明这时候先按说明放。没有说明的话不要乱猜目录。3. 单人替换先从最小样例开始3.1 最小工作流的完整链路不要一上来就导入那种十几个甚至几十个节点的大工作流。建议先用最小链路跑通加载参考视频、加载目标角色参考图、加载 MiniMaxH3 模型、输入提示词、设置采样参数、输出视频。大致节点顺序如下具体节点名称因工作流而异加载参考视频 - 拆分/采样视频帧 加载目标角色参考图 - 编码图像特征 加载 MiniMaxH3 模型 - 模型加载节点 提示词输入 - 文本编码 采样器 - 生成视频帧 VAE 解码 - 输出视频这套链路的核心思路是模型同时接收视频帧、角色参考图和文本提示词然后在潜在空间里完成动作保留和角色替换。第一次跑的时候提示词不要写复杂。比如“保留参考视频的动作和镜头运动将视频中的人物替换为参考图中的角色保持动作一致。”像“光影、氛围、服装质感、背景细节”这类描述可以先不写等主流程稳定了再加。如果你下载的工作流里包含了“导演台”“Skill”这类额外节点不要过分依赖它们。它们通常是帮你管理提示词或角色描述用的不是核心生成链路的一部分。先跳过这些附加节点用最小链路拿到输出再回头看附加节点到底做了什么。3.2 核心参数怎么看同样的工作流参数设置不同结果差距很大。下面列几个最容易影响的参数给的是通用判断口径具体数值以你下载的工作流的默认值为准。参数影响建议分辨率越高质量越好但显存占用直线上升第一次用 512 或 640别直接上 1080视频长度/帧数越长越难保持时序一致第一次控制在 2 到 3 秒批量数影响并行生成的片段数量默认 1先不要开大采样步数越高细节越充分但速度越慢一般 20 到 30 步比较常见提示词权重控制文本对生成结果的影响强度权重过高容易压制参考视频动作随机种子控制生成随机性固定种子便于复现和排错很多人一上来就把分辨率拉满然后遇到 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 分段转绘与断点续跑分段转绘的具体顺序可以这样把原视频按 5 秒到 10 秒切成片段每个片段保留 1 到 2 秒的重叠对每个片段独立做角色替换或动作迁移检查每个片段的角色身份、服装、发型是否一致用剪辑工具把片段按时间顺序拼接拼接处如果出现跳变用转场或过渡节点轻微模糊处理如果你的显卡显存只有 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 排查链路遇到问题时我建议按这个顺序排查不要一上来就改模型参数。顺序检查对象看什么1现象是报错、卡住、输出黑屏还是输出质量差2输入视频帧率、分辨率、格式、路径参考图是否清晰3环境依赖版本、模型文件是否齐全、显存和内存占用4参数分辨率、批量数、视频长度、采样步数、提示词权重5工作流本身节点连线是否正确、是否有冗余节点、版本是否匹配这个顺序的核心逻辑是先用成本最低的方式排除大概率问题再进入耗时较高的参数调试。7.3 输出不理想的调整顺序如果输出视频能生成但效果不满意不建议同时改所有参数。一次只改一个变量然后对比前后输出。按个人经验优先调整顺序是第一先确认输入。原视频动作是否清晰、参考图是否规范。很多效果差是输入材料本身不合格不是模型参数问题。第二再改提示词。把角色外貌、动作、镜头、风格拆成四条分别调整权重。第三改采样步数和分辨率。步数从 20 往 30 加分辨率从 640 往 768 加看画质是否有明显提升。第四调整视频长度。如果 8 秒以上的片段开始出现漂移果断切成 5 秒一段。如果所有参数都试过后还是不理想就要考虑工作流版本或模型文件是否匹配。有些工作流是针对某个 MiniMaxH3 版本做的换了模型文件后行为差异很大这个很难通过调参解决只能换回匹配版本。8. 真正落地时最该盯住的是资源占用和失败重试跑了几轮之后会发现MiniMaxH3 角色替换工作流最核心的竞争力确实是“动作迁移 角色替换”的组合能力但真正要做生产化使用单条跑通只是第一步。如果你只是个人学习默认参数、短片段、单人物替换已经够用。如果你是想处理批量视频或者想把工作流接到更稳定的流程里需要额外考虑几件事。第一日志要有时间、片段号和输出文件路径。一次批量转绘十几个片段时没有日志根本不知道哪段卡住了。第二输出命名必须规则化。不要用默认的 timestamp 文件名否则失败重试时很难判断新旧文件。第三任务队列要提前规划。不要用人工盯屏的方式处理长视频分段任务最好通过队列依次执行减少显存释放不干净导致的资源浪费。另外批量处理时不要把所有任务一次性丢进去跑。之前我试过连续跑 10 段视频前三段正常第四段开始帧率变化、角色漂移。不是模型坏了而是连续高强度计算后显存温度升高、资源没有完全释放。我建议每处理 5 到 6 段后重启一次 ComfyUI或者至少清空一次模型缓存再继续下一批。踩过几次坑之后我的体感是很多问题不是 MiniMaxH3 本身能力不够而是输入材料和前置环境没有处理干净。你给它一段动作不清晰的参考视频它只能还你一段动作混乱的输出你给它一张脸部模糊的角色参考图它能生成的也就只有模糊的角色脸。先把输入质量提上来参数调试才有意义。如果你正准备入坑这套工作流我的建议是先不要看那些几十个节点、一堆附加功能的“全能大工作流”从最小可运行链路开始跑通单人短片段再加动作迁移再尝试多人最后才挑战分钟级长视频。每一步都确认稳定了再往下一层走。这样看起来慢反而是到最终目标最快的路。