最近一直在折腾视频高清修复这块，起因是几段早年用手机拍的素材，放到现在的大屏上一看全是噪点和涂抹感，尤其是动态场景，简直就是马赛克开会。市面上的修复方案试了一圈，要么效果一般，要么显存门槛高得离谱，一张卡动不动就要十几二十个G。后来看到有人在讨论MiniMaxH3这个模型，说是6G显存就能跑，还能处理一分钟级别的长视频，我一开始是不太信的，毕竟同类开源模型在低显存下大多只能处理几秒钟的片段。但实际搭好ComfyUI工作流、把MiniMaxH3跑通之后，发现确实能玩，而且画质提升相当明显。这篇就把我完整的搭建过程、参数调教心得和踩坑记录分享出来，给同样被显存卡住的朋友一个可以直接抄作业的参考。
整个过程涉及环境准备、工作流搭建、参数调节、分块修复策略和显存优化几个部分，我尽量讲透为什么这样做，而不是只丢给你一个“照着点就行”的流程。你手头如果是6G显存的卡，比如常见的笔记本或者甜品级桌面卡，只要照着走，跑60秒长视频是可行的。
1. 为什么视频高清修复最容易被卡在显存上
先聊聊痛点。视频修复和单张图片修复完全是两个量级的事。
单张图片，哪怕分辨率是2K，丢进超分模型也就几百兆显存的压力，因为模型一次只处理一张静态图，计算完就释放了。视频不一样，视频本质上是连续图片序列，每秒24到30帧，一分钟就是1440到1800帧。你如果天真地把每一帧都当成单张图片来做超分，模型会反复加载、反复释放权重，这种操作在低显存下几乎是灾难，处理几秒就爆。
更麻烦的是，逐帧独立修复还会带来一个经典问题：闪烁（flicker）。因为每一帧都是“独立”被处理的，修复模型不知道前后帧之间的关系，它的随机性会导致相邻两帧的纹理细节出现跳变，人眼对亮度、噪点的突变非常敏感，结果就是修复完的视频看起来像是老电视信号不稳，一帧亮一帧暗。这问题在动漫番剧修复里尤其常见，真人视频稍微好一点，但放大到细节也一样明显。
MiniMaxH3这条路线的好处在于，它的模型设计本身就考虑到了时序一致性，配合工作流里的双采样器接力修复，能在一个合理的显存占用下，同时解决“清晰度不足”和“帧间闪烁”这两个核心痛点。而不是像很多暴力抽帧方案那样，只提升分辨率，却引入了一堆新问题。
这里还要说清楚一个概念：所谓“6G显存能跑”，不是说让你把整个60秒视频一次性塞进显存，而是通过分块修复和顺序批处理，把每一批次实际需要计算的量控制在一个很小的窗口内。显存需求取决于“模型权重加当前批次数据”的峰值，而不是视频总时长。打个比方，修一座桥不需要把整条河的水全抽干，只需要在施工区域做好围堰就够了。分块修复就是这个“围堰”。
2. 环境准备：ComfyUI整合包、模型文件与显卡驱动一次到位
这套方案我是在Windows环境下跑的，ComfyUI用的是社区整合包，好处是省去了手动装Python依赖和自定义节点的痛苦。如果你之前装过原版ComfyUI，也没必要重新折腾，只要补上对应的自定义节点和模型文件就行。但如果是从零开始，我建议直接下载整合包版本，省时间也少踩坑。
2.1 整合包解压后的关键目录结构
拿到整合包之后，解压路径尽量不要带中文和空格，这是个老生常谈但总有人忽略的问题。ComfyUI的很多自定义节点底层会调用Python脚本，路径一旦出现中文字符，很容易在某些环境下触发编码错误，报错信息还特别迷，大概率是UnicodeDecodeError，但实际上你根本想不到是路径问题。
解压后重点确认这几个目录：
ComfyUI/models/checkpoints/：存放主模型文件，MiniMaxH3需要放到这里ComfyUI/models/loras/：如果有配套的LoRA模型，放这里ComfyUI/custom_nodes/：自定义节点目录，工作流依赖的特殊节点都在这里ComfyUI/input/：输入视频的默认放置目录
整合包一般自带启动脚本，双击就能拉起来。第一次启动需要联网下载一些基础组件，耐心等就行。启动完成后浏览器会自动打开一个地址，默认是127.0.0.1:8188，看到这个页面就说明ComfyUI本体准备好了。
2.2 显卡驱动与依赖检查
在开始之前，建议先确认显卡驱动版本是否够新。MiniMaxH3这类模型对CUDA版本有要求，驱动太旧的话，PyTorch在运行时很容易报CUDA driver version is insufficient。检查方法很简单，命令行输入nvidia-smi，看右上角的CUDA Version，如果是11.8以上基本就没问题。
显存这块简单说下，6G显存是起步线。我在某台6G显存的机器上实测过，工作流按后面章节的配置跑，峰值占用大概在4.2G到5.6G之间浮动，中间有几次差点顶到上限，但用分块修复之后稳定下来了。如果你是8G显存，那会从容很多，甚至可以在分块尺寸上再放开一些。
2.3 自定义节点的安装
这套工作流主要依赖两个关键自定义节点：一个是用于视频抽帧和合成回视频的节点，另一个是用于分块修复的采样相关节点。整合包如果自带，那就省事了；如果没有，需要通过ComfyUI Manager安装。
安装节点时要特别注意版本兼容性。有些节点老版本和ComfyUI新版API不兼容，加载工作流时会出现红色的节点报错，显示cannot find node type之类的信息。这种情况通常是节点没装全，或者版本太老。我遇到过ComfyUI Manager一键安装后节点仍然报错的情况，最后是手动去Git仓库拉的最新分支才解决。
全部装好后，建议先跑一个最简单的文生图流程验证环境，确认ComfyUI能正常调用显卡。这步是为了把“环境问题”和“工作流问题”隔离开，免得后面修视频时混在一起排查。
3. 双采多参工作流的原理拆解：粗修与精修的两次接力
这套工作流的核心是“双采多参”。听起来玄乎，其实展开后就是一次修复过程中跑了两个采样器，用两套不同的参数组合，分阶段完成从“去糊”到“补细节”的过渡。
3.1 为什么要双采样器而不是单采样器一步到位
单采样器修复的问题在于参数是矛盾的。你希望画面细节丰富，就需要比较高的噪音强度来触发模型重建；但你希望画面稳定不漂移，又需要低噪音强度来保持原貌。这两者在同一个采样过程里很难兼顾。
双采样器的思路是把修复拆成两个阶段，类比一下就是修旧照片时先用水洗去污，再用精细笔触补色。第一阶段采样器侧重于“重置”画面，去噪强度偏高，把模糊、压缩痕迹、噪点这些脏东西打散；第二阶段采样器把这些已经“打散”的画面重新“雕刻”出纹理细节，去噪强度回落，确保不破坏第一阶段已经恢复的结构。
我实际测试下来，这种两段式处理相比单步修复，最直观的提升是画面边缘。单步修复的边缘容易出现“晕轮效应”，就是物体边缘有一圈淡淡的亮边，而双采多参工作流处理出来的边缘明显干净很多。
3.2 多参数组合到底怎么配
参数组合是这套工作流的灵魂，我把第一阶段的参数整理成了表格，方便你对着配：
| 参数项 | 第一段采样（粗修） | 第二段采样（精修） |
|---|---|---|
| 去噪强度（denoise） | 0.45~0.55 | 0.2~0.3 |
| 采样步数（steps） | 20 | 15 |
| CFG（提示词引导强度） | 7.5 | 5.5 |
| 采样器（sampler） | euler_ancestral | dpmpp_2m_sde |
| 调度器（scheduler） | normal | karras |
第一段用euler_ancestral配合normal调度器，是为了在粗修阶段引入适当的随机性，让模型有空间去“创造”被压缩丢失的纹理；第二段用dpmpp_2m_sde配合karras，是追求稳定收敛，减少画面漂移。这个搭配不是随手写的，我试过反过来配，第二段用euler结果边缘还是发毛，换了dpmpp_2m_sde之后纹理干净了非常多。
3.3 CFG和步数要不要跟着视频场景变
要。上面表格给的是通用基准，实际使用时需要根据素材类型微调。动漫类视频，线条感强，CFG可以降到6左右，去噪强度也适当降低，因为动漫本身的细节就是大色块加线条，过度重建会画出莫名其妙的纹理；真人视频，皮肤质感复杂，CFG可以提到8左右，让模型更“用力”去补皮肤毛孔和头发丝。
步数方面，20步是第一段的安全值，低于15步会出现明显的块状感，高于25步则边际收益递减，纯属浪费时间。第二段15步在大多数时候够用，如果你发现纹理还是不够锐利，可以尝试加到20，但不要超过25，超过之后反而容易出现油画感。
4. 从导入工作流到导出修复视频：完整实操步骤
环境准备好了，原理也明白了，下面进入实际操作环节。这一节我会按顺序走完整个流程，你在自己机器上照着做就行。
4.1 工作流导入与模型加载
在ComfyUI页面里，把工作流JSON文件直接拖入浏览器画布，会看到完整的节点图。这时候大概率会有节点显示红色，不要慌，逐个点击红色节点，看提示缺什么。最常缺的就是模型节点，需要手动选择MiniMaxH3模型文件。
模型选择节点通常在Load Checkpoint里，下拉框空白说明模型文件没放到正确目录。放到models/checkpoints后，点击节点旁边的刷新按钮就能识别出来了。如果你是第一次用这个模型，加载时间会慢一些，因为需要把模型权重读入显存，6G显存大概需要等待二三十秒，属正常现象。
4.2 视频导入与抽帧参数设置
把待修复的视频文件复制到ComfyUI的input目录，然后在工作流的Load Video节点里刷新并选择该文件。抽帧参数里最关键的是fps设置，修复视频没必要用原始高帧率抽帧，24fps的内容用24抽就行，如果你拍的素材是30帧甚至60帧，建议统一抽到24到30之间。
为什么不要贪高帧率？因为每一帧都要经过两段采样器计算，帧率翻倍等于计算量翻倍，但人眼对超过30fps的细节提升感知很弱。修复老视频不是拍竞技游戏，24fps足够平滑了，省下的时间能让你迭代更多参数组合。
分辨率设置上，如果你的源视频分辨率低于720P，建议抽帧时按源分辨率走，不要先放大。修复流程里超分是模型做的，提前暴力放大反而引入插值模糊，得不偿失。
4.3 第一段采样设置
第一段采样的去噪强度建议从0.5起步。这个值是“模型对画面重绘程度”的度量，0是不动原图，1是完全重新画。0.5意味着画面一半的内容会被模型基于提示词“想象”出来，这是一个风险适中的起点。
视频类素材和图片类素材在这个节点上有明显差异，图片可以放心用高去噪强度，因为单张图就算重绘过度也只是那一张的问题。视频不同，去噪强度一旦超过0.6，模型对提示词的联想空间变大，很容易在连续帧上造出完全不同的纹理，修复出来的视频会有明显的“呼吸感”，就是画面里静止物体的纹理在反复跳动。
4.4 第二段采样衔接与分块开关设置
第一段采样输出后，会进入一个分块重采样节点，这是整个工作流里对显存影响最大的部分。分块尺寸建议设为512，重叠区域（overlap）设为32到64之间。
分块修复的原理是把大画面切成小块分别计算，每块之间保留一定的重叠区域，让模型在拼接时能有参考，避免切块边缘出现断层。512的分块尺寸在6G显存下是比较安全的选择，如果你显存是在8G以上，可以试着调到640甚至768，纹理还原会更好，但速度会明显变慢。
固定随机种子这个操作要重点记一下。种子（seed）决定了模型生成随机纹理的初始状态，第一段和第二段的seed建议都固定下来，这样才能保证同一视频的不同片段之间，修复风格是一致的。我之前没固定seed，结果同一段视频前面部分偏冷色、后面部分偏暖色，就是种子不同导致模型每次“脑补”的色调都跑偏了。
4.5 视频合成与导出参数
所有采样计算完成后，最后一步是把修复好的帧序列合成回视频。合成节点里要指定输出帧率和编码方式。输出帧率必须和抽帧时保持一致，否则视频会变成快速播放的默片。编码建议用H.264，码率设置比默认值稍高一些，比如20Mbps，因为修复后的视频纹理细节变多了，低码率压制会把辛苦修出来的细节又压糊掉。
另外在合成之前还有一个容易忽略的检查项：色彩空间。ComfyUI里图像张量在不同节点间的颜色表示可能不同，如果输出视频看起来灰蒙蒙的，多半是色彩空间没对齐。在工作流的输出节点前挂一个色彩转换节点，把RGB和YCbCr的转换做好，能省掉后面很多麻烦。
5. 6G显存跑60秒长视频：分块修复与显存优化的几个关键细节
前面说过，6G显存跑长视频的核心策略是“不要一次性吃太多”。这节详细说一下我在显存优化方面做的几处关键控制。
5.1 批处理大小必须设为1
ComfyUI里有个batch_size参数，很多人会习惯性把它调大来提升吞吐量，但修复视频时最好乖乖保持为1。batch_size会直接影响模型一次处理几帧，6G显存下batch=2的显存峰值可能直接跳到接近9G，瞬间OOM。
batch=1确实会让速度慢一些，但换来的是流程稳定。我做过的实测对比，batch=1时整段修复过程显存峰值约5.5G，batch=2直接崩了，连中间状态都保不住。速度不是这个场景下的首要追求，稳定交付成片才是。
5.2 自动释放空闲显存与异步加载
ComfyUI里启用显存优化选项后，它会自动释放不再使用的中间激活值，这个策略对低显存卡非常关键。尤其是视频这类节点链长的工作流，中间会产生大量临时张量，如果不及时释放，累积起来很快就把6G吃满。
另外把模型加载方式改为异步加载也能缓解显存紧张。默认情况下ComfyUI会在节点执行前把模型权重全部搬进显存，异步模式下则是按需加载，降低峰值占用。这会导致每个节点执行前有一丁点延迟，但换来的是更大的可用空间，值得。
5.3 分块重叠区域的隐性收益
很多人以为overlap参数只影响拼接质量，其实它还直接影响显存占用和画面稳定性的平衡。重叠区域越大，分块越多，每个分块需要的上下文越丰富，计算量上升，但帧间纹理的一致性会更好，闪烁也明显减少。
这个参数的调整逻辑是：显存吃紧时优先降低分块尺寸，而不是减小overlap。因为overlap一旦小于16，分块之间的过渡会非常生硬，修复完的视频在切换边界时会出现可见的横条纹，那种“修复过”的痕迹比模糊本身更难接受。
5.4 并不是整个视频都在用6G显存
实测60秒视频，24fps，这1440帧被分块处理后，实际每个时刻在显存里活跃的数据其实只有几十帧的临时张量。6G显存的空间大部分被模型权重占据着，真正留给数据的空间很小，但分块的巧妙之处在于把大计算拆成了小计算，每一块算完就清空，再算下一块。
我在任务管理器里观测过整个流程，显存占用曲线是锯齿状的，每一帧修复时冲高到5.5G左右，计算完立刻掉回4G出头。这说明只要你用对了方法，长视频根本不是显存杀手，真正的问题在于显存管理策略而不是容量本身。
5.5 直接尝试更大显存的缓存策略
如果你手头是7G或8G显存，可以额外开一种缓存策略，把中间计算好的张量留在显存里供下一帧复用，这样相邻帧之间共享了一部分计算结果，整体修复速度能提升20%到30%。6G显存开这个会有点危险，建议还是老老实实走释放策略。
我建议你跑通工作流后，逐步从小的分块尺寸往上调，以50为单位递增，每次调整后完整跑5秒素材观察峰值显存，找到一个稳定余量在300M左右的安全配置。这比直接抄别人的参数更靠谱，因为不同素材的复杂度不同，同一配置在不同机子上表现可能差异很大。
6. 实测踩坑记录：从显存爆掉到画面花掉的完整排查过程
任何工作流都不可能一把跑通，这里记录我踩过的几个坑和最终排查思路，希望能帮你省掉一些盲试的时间。
6.1 OOM显存溢出：不是所有节点都吃同样的显存
第一次跑完整视频的时候，我在修复进行到大约15秒处直接碰到OOM报错。报错信息指向了某个采样节点，我当时下意识以为是分块尺寸太大，把512调成了384，结果依然在差不多的位置爆掉。仔细排查后才发现问题出在抽帧节点往采样节点传递的是完整帧的批处理数据，一次性塞了大量的图片张量。
解决方式是在抽帧节点之后加一个序列批处理节点，把连续帧逐批输出而不是一次性全部发出。这逼着抽样节点每次只处理一个batch，显存峰值瞬间降了1.5G左右。这也解释了为什么6G显存能稳定跑长视频，除了分块修复以外，数据流的节奏控制同样重要。
6.2 画面闪烁：最隐蔽的失败模式
第一次跑出成品的时候，单帧看很惊艳，但整体播放就露馅了，背景墙壁的纹路就像水波一样晃。排查方向有两个，一个是检查种子有没有固定，另一个是检查第二段去噪强度有没有超过0.35。我的种子在第一段固定了，但第二段采样器的种子没固定，导致第二段每次都在随机重排细节纹理。
修复方式是让第二段采样器沿用第一段采样器的种子，把去噪强度从0.35压到0.25，闪烁基本就消失了。这里顺带说一句，闪烁问题很难通过后期软件修，因为它是纹理层面的不稳定，不是亮度层面，所以源头控制远比事后补救重要。
6.3 画面花掉与绿边：分块拼接引起的次生故障
有几次修复出来的视频在画面边缘出现绿色色带，尤其是在物体移动较快的位置。排查下来是分块重叠区域的色彩混合没做平滑处理，单个分块独立修复后，相邻块在重叠区的RGB值发生跳变，肉眼看起来就是一圈绿边。
解决方法是调整分块合成节点里的混合模式参数，把硬切改成渐变混合，重叠区域从硬边界改成软过渡。如果你的工作流没有这个选项，可以考虑把重叠区域从32提升到48，也能一定程度缓解，但不能根治，最终还是要在混合算法层面处理。
6.4 音画不同步与音轨丢失
修复流程是纯视频层面的操作，音频不参与计算，但在导出时很多人只接视频流，结果合成出来的视频直接没声音。我在整合包里看到的合成节点默认只导出视频流，需要在后续用额外命令把音轨合并回去。
这里给一个通用处理思路：先保留原视频的音轨文件，待修复视频导出后，用FFmpeg命令把音轨拉回视频文件里。具体命令很简单，大概是ffmpeg -i 修复视频.mp4 -i 原视频.mp4 -c:v copy -c:a aac -map 0:v:0 -map 1:a:0 最终成片.mp4这种格式。如果你就是想要一个完整的最终成片，这步绕不开。
6.5 脸部区域过修的问题
遇到人物特写素材时，脸部经常被过度修复，皮肤纹路被抹得跟塑料一样。这个问题的根源是第二段去噪强度偏高，模型在细节重建时把脸部皮肤误判为“需要大幅重绘的区域”。
处理办法是给脸部区域单独加一个遮罩，遮罩内的去噪强度降低到0.15左右，非脸部区域保持0.25。如果你的素材脸部占比不大，也可以不折腾，毕竟整体0.25的表现已经很克制了。但如果脸部特写多，建议还是加遮罩，差别肉眼可见。
7. 最后的实操建议：参数调优思路与批量处理技巧
整套工作流稳定跑通之后，我逐渐调整出来一套适合自己素材的固定参数模板，这里分享几个核心思路。
7.1 用“短片段测试”代替“整片调试”
视频修复最忌讳一上来就拿全长素材调参。耗时极长不说，遇到参数不合适，中途改参数会导致前后风格不一致。我现在的方法是：每次调整参数，都只用视频最复杂的10秒片段做测试，循环跑3次以上，观察显存曲线和输出画面的稳定性，确认无误后再用正式参数跑全片。
测试片段的选取也有讲究，优先选择画面运动幅度大、包含人物脸部、明暗变化明显的段落。这些是修复最容易出问题的场景，把这10秒搞定，其他相对平缓的片段基本不会翻车。
7.2 多参数模板化，按素材类型一键切换
我给自己整理了三个模板：老电影修复型、AI生成视频增强型、手机实拍降噪型。每个模板对应一套不同的双采参数组合。老电影修复强调去划痕和噪点，去噪强度会稍高；AI生成视频增强强调纹理重建，第二段步数会适当加多；手机实拍降噪强调保真，两段去噪强度都会压低。
这不是说工作流里要弄多复杂的逻辑，只要有多个参数预设节点，在跑不同素材时切换对应节点就行。这样做的好处是非常直接，不用每次调试，选对模板基本就能出不错的效果。
7.3 关于速度的一点预期管理
6G显存跑这套工作流，实际速度大概在每帧1到2秒之间，具体取决于分块尺寸和视频分辨率。按这个速度计算，60秒24fps的素材，完整跑完大概需要40到50分钟。听起来不快，但考虑到画质提升幅度，这个时间成本是可以接受的。
如果你需要处理大量素材且时间有限，建议优先修复画质最差、最关键的片段，而不是把手机上所有视频都过一遍。修复老视频纯粹是个堆时间的活，别贪。
7.4 一个容易被忽略的小细节：素材预处理
在把长视频丢进工作流之前，花一点时间做预处理，效果会好很多。比如把视频裁剪到核心内容段落，去除头尾的晃动画面；再比如如果原视频亮度偏低，适当提亮后再进修复流程，否则模型在暗部区域的修复容易偏色发灰。预处理看起来增加了步骤，实际上能极大提高后续调参的效率和成片的质量上限。
我在实际使用中还有一个体会：固定在同一个种子值跑同一段素材，即便换台机器，修复风格也是可以复现的。这意味着如果你有几段风格接近的素材，完全可以用同一组种子和参数跑完，出来的成片观感会非常统一，像是同一个后期团队做的。种子这个细节在跨机器协作时尤其有用，值得养成习惯保存下来。
