
HY
折腾进行时
Hello, I'm HY.








八月我发过一篇 MiniMax H3 工作流分享,那套是直出方案:想要高清,就直接把分辨率拉上去跑,慢。
后来一直在试二阶采样的路子——先用极低分辨率快速出一版,确认构图和动作没问题,二采再把 latent 放大重采样,把细节补回来。
试到现在,H3一二采.json 这个工作流是我用过最好用的一个,性能极其优秀。
Share/Comfyui/Workflow/H3一二采.json at main · hy4962/Share
这不是我自己写的,是 UP 主分享的,配着这个 B 站视频一起看更清楚。
先给数据。我这边是 32G 内存加 12G 显存,单图参考:
| 阶段 | 分辨率 | 视频时长 | 耗时 |
|---|---|---|---|
| 一采 | 0.2 MP(608 × 352) | 15 秒 | 约 200 秒 |
| 二采 | 放大到 720p | 15 秒 | 约 500 秒 |
两次加起来大概 700 秒,十一分多钟能拿到一条 15 秒的 720p 片子。
参考图我基本都是拿 Krea2 出的角色图来喂的,之前写过一篇 Krea2 四视图生成,四个角度和脸型一次交代清楚,现在还在用,单图参考正好吃这一套。
0.2 MP 换算过来就是 608 × 352,肉眼看着确实糊。但一采本来也不是拿去交付的,它的任务是快速定下构图、动作和运镜,真正出片的是二采。
0.2 对动漫基本够用。真人我玩得少,就不乱下结论了——动漫角色线条干净、背景相对简单,一采丢掉的信息二采大多能补回来;真人那些皮肤质感、发丝、细微光影,估计得把一采提到 0.4 甚至 0.6 才稳,这个留给常跑真人的朋友自己试。
上次那套(H3-3.0)是单段的:采样一轮,直接出你想要的尺寸。
这套是两段:
ResolutionSelector 定一个很低的尺寸。15 秒配 0.2 MP,只出 608 × 352。步数上工作流把整条 sigma 表拆成两段——SplitSigmas 在第 8 步切开,前 8 步给一采,后 4 步留给二采;总数 12 是用 a + b 自动算出来喂给 BasicScheduler 的。latent token 少,这一步很快。LTXVSeparateAVLatent 把一采出来的音视频 latent 拆开,交给 MinimaxH3LatentUpscaler3D 在 latent 空间里放大(工作流里给的是 2 倍,608 × 352 翻一倍,差不多就是 720p 这一档),再 LTXVConcatAVLatent 拼回去,最后交给 MMH3UltimateUpscale 按时间分块重采样。关键在第二步没走「解码成像素 → 放大图片 → 再编码回 latent」那条路。H3 的 VAE 有 50 亿参数,解码再编码非常贵,直接在 latent 上放大,省掉的就是这一段。
工作流里还挂了个 VRGDG Video Compare Slider,一采和二采的结果叠在一起,拖滑块就能对比。这个细节挺贴心,能直观看出二采到底补回来了什么。
工作流里一共用到六个模型文件:
| 用途 | 文件名 | 下载 | 存放目录 |
|---|---|---|---|
| UNet | DasiwaMinimaxH3_dasiwaHybridV2_int8.safetensors | Civitai / Tensor.Art 备份 | models/diffusion_models/H3/ |
| 加速 LoRA | TaoMate-H3-3step.safetensors | HuggingFace(ComfyUI 版) | models/loras/H3/ |
| 文本编码器 | qwen3vl_32b_minimax_h3_int8_convrot.safetensors | Comfy-Org/MiniMax-H3 | models/text_encoders/ |
| 视频 VAE | minimax_h3_video_vae_fp16.safetensors | 同上 | models/vae/H3/ |
| 音频 VAE | minimax_h3_audio_vae_fp32.safetensors | 同上 | models/vae/H3/ |
| Latent 放大器 | minimax_h3_latent_upscaler_3d_fp16.safetensors | LBH-123-AI/Minimax_h3_latent_Upscaler | models/latent_upscale_models/ |
| 预览用小 VAE | taeh3.safetensors(约 22 MB) | Share/Comfyui/Model | models/vae_approx/ |
UNet、LoRA、两个 VAE 在工作流里的路径都带 H3\ 前缀,所以要在这几个模型根目录下先建一个叫 H3 的文件夹再往里放,不然加载器的下拉框里根本选不中。
Latent 放大器和 taeh3.safetensors 都没有这个前缀,直接丢进各自的根目录就行。

模型组里还有个 MiniMax H3 Sigma Shift,视频偏移 12、音频偏移 3,工作流已经把值给好了,一般不用动。
这套工作流的自定义节点比上次那套多,缺一个就是一片红。按 ComfyUI Manager 里显示的包名整理了一遍:
| 包名 | 仓库 | 用到的节点 |
|---|---|---|
comfyui-kjnodes | kijai/ComfyUI-KJNodes | MiniMaxH3MemoryEfficientSageAttentionPatch、ModelPreviewOverrideKJ、INTConstant、FloatConstant |
rgthree-comfy | rgthree/rgthree-comfy | Seed (rgthree)、Fast Bypasser、Fast Groups Bypasser、Label |
comfyui-videohelpersuite | Kosinkadink/ComfyUI-VideoHelperSuite | VHS_LoadVideo、VHS_VideoCombine |
comfyui-vrgamedevgirl | vrgamegirl19/comfyui-vrgamedevgirl | VRGDG_VideoCompareSlider |
plaguekind-nodes | PlagueKind/ComfyUI-PlagueKind-Nodes | MMH3UltimateUpscale、MMH3TemporalSplitParams |
| — | LBH-123-AI/Comfyui_Minimax_h3_latent_Upscaler | MinimaxH3LatentUpscaler3D |
Manager 里搜不到后两个,直接 clone:
1cd ComfyUI/custom_nodes2git clone https://github.com/PlagueKind/ComfyUI-PlagueKind-Nodes.git3git clone https://github.com/LBH-123-AI/Comfyui_Minimax_h3_latent_Upscaler.git剩下那批节点——MiniMaxH3ReferenceToVideo、MiniMaxH3SigmaShift、ModelAttentionBackend、ResolutionSelector、ComfyMathExpression、LTXVConcatAVLatent——在工作流 JSON 里记的是 comfy-core,属于 ComfyUI 内置,不用装插件。但这也意味着你的 ComfyUI 得够新:老版本打开,这些节点一样是红的。先把主程序更新到最新再导入工作流。
MiniMax H3 Mem Eff Sage Attention 和注意力后端那一套要走 SageAttention / FlashAttention。缺了也能跑,只是慢一些。
工作流把要调的东西全圈在「设置」那一组里,用 ▼ 标签标出来,照着改就行:
| 标签 | 工作流预置 |
|---|---|
| ▼设置一采尺寸 | 16<9>9>,0.2 MP,32 的倍数 |
| ▼设置秒数 | 15 |
| ▼设置一采步数 | 8 步,推荐 6–8 |
| ▼设置二采倍数 | 2 倍 |
| ▼设置二采步数 | 4 步,推荐 2–4 |
| ▼ 二采时间分块设置 | 153 帧一段 / 重叠 17 帧 / 锚点 0.99 |
| ▼设置提示词 及 参考图片尺寸 | 提示词写在这儿 |
| ▼关了变文生 | 绕过这一段就直接变成纯文生视频 |
一采 6–8 步、二采 2–4 步是我跑下来比较舒服的区间,工作流默认刚好卡在两边上沿(一采 8、二采 4)。
一采步数管构图和动作,压到 6 以下容易动作都没定型,二采放大也救不回来;二采步数管细节,2 步就能看出明显差别,再往上加收益掉得很快。想省时间就直接一采 6、二采 2,画面崩没崩,采样预览一眼就能看出来。
改的时候动「设置」组里那两个整数常量就行——SplitSigmas 的切点是一采步数,另一个是二采步数,总数不用自己算,a + b 会喂给 BasicScheduler。
工作流里塞了一张 Note: Size Settings Reference,我顺手抄下来,改一采尺寸的时候直接查:
| megapixels | 输出(16<9>9>,32 的倍数) |
|---|---|
| 0.2 | 608 × 352 |
| 0.3 | 736 × 416 |
| 0.4 | 864 × 480 |
| 0.5 | 960 × 544 |
| 0.6 | 1056 × 608 |
| 0.7 | 1152 × 640 |
| 0.8 | 1216 × 672 |
| 0.9 | 1280 × 736 |
| 0.98 | 1344 × 768 |
| 1.0 | 1376 × 768 |
| 1.2 | 1504 × 832 |
| 1.5 | 1664 × 928 |
| 1.8 | 1824 × 1024 |
| 2.0 | 1920 × 1088 |
这套工作流还内置了一个可视化节点,KJNodes 的 Model Preview Override(节点上写着「采样预览」)。跑采样的时候它会在旁边实时渲染一版低清画面,能大致看出构图、动作和人脸有没有崩。
这个功能挺关键的。一采加二采跑一趟十几分钟,要是等全部跑完才发现手画成六根指头、或者角色整个人歪了,那十几分钟就白扔了。有预览就能在中途看出来,直接中断,改个种子重开,省下的是整轮的时间。
要让它出画面,得把 taeh3.safetensors 放进 ComfyUI/models/vae_approx/。这个目录 KJNodes 是写死的(源码里就是 folder_paths.get_full_path("vae_approx", name)),放错地方节点里的 tiny_vae 下拉框就选不到它,预览区只会一直显示 waiting for sample…。
节点上这几个值是工作流里给好的:
| 参数 | 值 | 说明 |
|---|---|---|
max_resolution | 480 | 预览画面的分辨率上限,调大更清楚但更吃性能 |
jpeg_quality | 80 | 预览帧的压缩质量 |
preview_frames | 999 | 最多预览多少帧,999 相当于全预览 |
preview_fps | 8 | 预览回放的帧率 |
suppress_default_preview | true | 压掉 ComfyUI 自带的那个预览,只留这一个 |
tiny_vae | taeh3.safetensors | 就是上面那个小 VAE |

节点下半部分还有个曲线区,右边直接给每一步的耗时(step time (ms))。想让整体时间降下来,盯着这个数调步数最直观。
预览走的是小 VAE 快速解一版,糊是正常的。它只用来看构图和动作有没有大问题,画质还得看二采出来的成品。
H3 的帧数要落在 5 + 17n 这个网格上(5、22、39、56……),自己随便填一个数,轻则报错,重则出怪东西。
这个工作流不用你操心。▼设置秒数 后面挂了个 ComfyMathExpression,公式是:
1max(5, round(a * 24)) + (5 - (max(5, round(a * 24)) % 17)) % 17a 就是秒数,乘 24 换成帧,再自动贴到最近的 5 + 17n。填 15 秒算出来是 362 帧。
打开工作流先数红框。红框就是插件没装,右键节点能看到它属于哪个包,对着上面的表格一条条补。
模型缺了更简单:把红框截图甩给 Gemini,让它把文件名和下载地址列全,能整理得明明白白。这一点上它比 GPT 好用。说到底 Google 搜索足够强,别一上来就在群里问「为什么我的是红的」。
我自己的判断:动漫够用,真人不好说。
一采的 0.2 只负责定构图和动作,细节全靠二采补。但如果一采糊到动作都定不准——快速挥手、大幅位移这种——二采放大之后只会跟着糊、跟着抖。这时候把一采提到 0.4 起步,代价是时间跟着涨。
这套工作流我会一直留着用。它把「快」和「清楚」拆成两步:低分辨率那一步不心疼,高清那一步也不用担心一步到位把显存榨干。32G 内存加 12G 显存能跑到 15 秒 720p,对家用机器来说已经很够意思了。
有更好的参数组合或者踩到别的坑,评论区交流。
如果这篇文章对你有帮助,欢迎分享给更多人或打赏支持!
部分内容可能已过时
分享你的想法,与大家交流讨论