ComfyUI 里的 H3 和官方权重不是同一套
有一类误会很难自己发现：你在 ComfyUI 里打开官方的 MiniMax H3 模板，照着说明把模型下到对应目录，工作流跑通了，于是你觉得自己”用上了 H3”。然后你去翻 MiniMax-AI/MiniMax-H3 的 README，想对一下参数，发现文件名对不上、精度对不上、模块清单也对不上。
不是你哪里配错了。这两边下载的本来就不是同一套权重文件。
这篇文章只做一件事：把两边各自是什么、差在哪几层、以及”我到底该走哪一边”这条决策路径说清楚。它不会告诉你哪边画质更好——原因写在最后一节，那不是我藏着不说，是我们手上根本没有任何可以支撑这种结论的数据。
一、把两边的文件清单摆在一起看
先看 ComfyUI 这边。截至 2026-08-09，docs.comfy.org 的 H3 教程页和 Comfy-Org/workflow_templates 仓库里的模板文件，指向的下载源是 huggingface.co/Comfy-Org/MiniMax-H3，而不是 MiniMaxAI/MiniMax-H3。要下的文件是这五个：
| 类别 | 文件名 | 放置目录 |
|---|---|---|
| diffusion_models（t2v / i2v 用） | minimax_h3_fl2va_pruned_int8_convrot.safetensors | ComfyUI/models/diffusion_models/ |
| diffusion_models（r2v 用） | minimax_h3_ref2va_pruned_int8_convrot.safetensors | ComfyUI/models/diffusion_models/ |
| text_encoders | qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors | ComfyUI/models/text_encoders/ |
| vae（视频） | minimax_h3_video_vae_fp16.safetensors | ComfyUI/models/vae/ |
| vae（音频） | minimax_h3_audio_vae_fp32.safetensors | ComfyUI/models/vae/ |
再看 MiniMax 官方那边。截至 2026-08-09 的仓库 README，开源发布的是两个 checkpoint：MiniMax-H3 Base FL2VA 与 MiniMax-H3 Base Ref2VA，README 的表格里，两者的精度那一栏写的都是 BF16。README 另外注明，发布的 checkpoint 是 CFG-distilled 的 Omni Transformer 权重。
差异就落在文件名的那几个后缀上：ComfyUI 侧的扩散模型文件名里带 pruned_int8_convrot，文本编码器文件名里带 nvfp4_awq。这两串字符串是我从官方模板和教程页的下载清单里原样抄下来的，它们的字面含义指向裁剪与量化处理；至于具体裁了什么、量化到什么程度、参数是怎么校准的，Comfy-Org 那边我没有找到公开说明，我也就不替它编。
能确定的只有一句：ComfyUI 里跑的 H3，和照 MiniMax README 用官方推理栈跑的 H3，权重精度不是一回事。
二、这条路是分几个版本铺出来的
值得注意的是，ComfyUI 对这类量化权重的支持不是随 H3 一起突然出现的，而是提前铺了将近两个月。把 release notes 的相关条目按时间排一下：
- v0.27.0（2026-06-30）：这一版的主要变化，就是新增 int8 convrot 模型支持。
- v0.30.0（2026-08-03）：新增 int8 convrot embedding lookup（关联 PR #15035）；H3 本身的支持也是在这一版落地，官方模板说明里给出的关联 PR 是 ComfyUI#15224。官方教程页写明的版本门槛是 ComfyUI version 0.30.0 or later。
- v0.31.0（2026-08-08）：release notes 里有一条 “fix(minimax): cast raw parameters to input device in H3 VAEs”（PR #15268），即修了 H3 VAE 的一个参数设备转换问题。
这条时间线有两个可以直接用的判断。
第一，“int8 convrot” 不是给 H3 专门造的词，它是 ComfyUI 早在 v0.27.0 就引入的一类模型格式支持，H3 是踩着这条既有轨道进来的。所以你在 ComfyUI 里看到这个后缀，看到的是 ComfyUI 生态的一种权重形态，不是 MiniMax 官方发布物的一部分。
第二，跑 H3 建议至少到 v0.31.0。门槛虽然是 0.30.0，但紧接着的下一个版本就修了 H3 VAE 的问题，卡在 0.30.0 没有好处。另外，按 README 里的 Release Process，ComfyUI 大约每两周发一个 major stable 版本，而 stable release tag 之外的 commit 可能非常不稳定、会弄坏很多自定义节点——这句是官方自己写在 README 里的，跟 master 还是跟 tag，依据就是它。还有一条容易被忽略：官方模板说明提醒，Desktop 与 Cloud 跟随 stable 发布，因此某些”nightly 才支持”的模型在这两个渠道上可能还不可用。
三、fl2va 和 ref2va 是两套权重，不是一个文件的两种模式
这是新手最容易多花一趟下载时间的地方。
在 MiniMax 官方口径里，两个 checkpoint 分工是清楚的：FL2VA 承接 Text-to-Audio-Video（t2va）与 First/Last-Frame-to-Audio-Video（fl2va），输入是文本，可选首帧、尾帧或两者都给；Ref2VA 承接 Reference-to-Audio-Video（ref2va），输入是文本加参考图像、视频和/或音频。
ComfyUI 侧原样保留了这个分家。官方模板说明里有一句强调，ref2va 用的 “is a different set of weights from the fl2va model used by the t2v/i2v templates”。也就是说：
- 你只想跑 T2V 和 I2V 模板 → 下
minimax_h3_fl2va_pruned_int8_convrot.safetensors - 你要跑 R2V 模板 → 下
minimax_h3_ref2va_pruned_int8_convrot.safetensors - 两类都要 → 两个文件都得下，没有”一个文件切模式”这种省事的路
文本编码器和两个 VAE 是共用的，不用重复下。
顺带把架构那一层对上：H3 的 H3-Encoder 使用 Qwen3-VL-32B 的完整预训练权重，把其第 50 层的 hidden states 交给 Omni-Transformer——这解释了 ComfyUI 侧的文本编码器文件名为什么以 qwen3vl_32b 开头。同理，H3-VisualVAE 与 H3-AudioVAE 在 README 里本来就是两个不同的组件（前者是时间因果视频自编码器，后者对每个声道把 32 kHz 音频压成 40 Hz 的 latent 序列），所以 ComfyUI 侧的 vae 目录里也是两个独立文件、一个 fp16 一个 fp32，不是有人下重复了。
四、还有一层差异比精度更容易被忽略
只盯着”int8 对 BF16”，会漏掉一件更要紧的事：H3 这个系统的三个模块，开源出来的只有中间那一个。
README 的 System Overview 把 H3 拆成三块：
| 模块 | 职责 | 开源状态 |
|---|---|---|
| H3-Context-IR | 把复杂的多模态指令理解、精炼成 Context Intermediate Representation 再交给生成 | 未包含在本次开源发布中，官方提供 API，并提供教程让开发者按 Prompting Guidance 自建预处理系统 |
| H3-Base | 基于 Context-IR 的输出生成音视频，产出 768p 结果 | 已开源，两个 checkpoint |
| H3-Regenerate-2K | 把 768p 结果连同原始上下文送回 H3，重新生成 2K 输出 | 尚未开源，README 写因系统复杂度暂未开源、准备好后发布；提供 API 用于验证官方结果 |
README 对第一块有一句很重的话：H3-Context-IR 对最终输出质量至关重要，官方强烈建议要么把它接进你的生成流水线，要么照 Prompting Guidance 自建一套上下文处理系统。
对照到 ComfyUI 这边：模板里没有这两个模块。所以”ComfyUI 里的 H3”和”官方权重的 H3”之间，差的不只是权重形态，还差着前后两层未开源的系统件。顺着这条还有一个必须澄清的点——别把 ComfyUI 里 Resolution Selector 能选到高档位理解成”支持 2K”，H3 的 2K 走的是 H3-Regenerate-2K 这条 in-context 重生成的路，而该模块未开源、只有 API，模板里没有它。
还有一处属于同一类”能力不等于发布状态”的区分，顺手带上：README 写 H3 原生支持稀疏注意力的训练与推理，但首次开源发布只提供 full attention 的推理，稀疏注意力实现留待未来更新。模型能力和当前你能跑到的东西，是两件事。
五、那我该走哪一边
不列参数表，直接给决策路径。你顺着自己的处境往下走：
你能不能联网、愿不愿意把内容交给官方平台过一遍？ 如果不能联网、或者素材不方便出本地，那 Context-IR 与 Regenerate-2K 这两条 API 路你本来就走不了，选择自动收敛到”本地跑 H3-Base”。这时候还要知道一条：README 的 Safety Guardrails 章节写明，用户提交的文本、图像与视频以及增强后的提示词都要经过自动审核，疑似违法、色情或侵犯第三方权利的内容可能被拦截，官方也明说行业标准的过滤措施无法消除误判与漏判。走 API 就意味着过这道审核，走本地则没有这一层——这是选择路径时的一个真实变量，不是我在暗示哪种更好。
你会不会命令行、愿不愿意维护一套 Python 推理环境？ 不愿意，就走 ComfyUI：它给了三个官方模板（T2V / I2V / R2V），节点图点开就能改。愿意，且你后面有微调、改采样逻辑、接进自家服务这类打算，那按 MiniMax 官方 README 的路子走更顺——官方发布的是完整模型权重，README 明说是为了支持包括微调在内的后续开发。这里补一句架构上的相关事实：Omni-Transformer 是 33B 参数的 dense 单流 Transformer，其中约 13B 参数位于 AdaLN 相关分支，而 AdaLN 调制输出可以预先计算并缓存，这些参数在”仅推理”的部署中不需要加载。这条反直觉但重要——不过它只说明”仅推理时不必全部加载”，不能据此换算出需要多少显存或几张卡，官方没给这个数字。
你在意的是不是”复现官方那个效果”？ 如果是，那就得诚实面对第四节：官方效果的链路里有两块没开源。拿到 H3-Base 权重不等于拿到官方成品，这跟你用不用 ComfyUI 无关。
你要不要 2K？ 要，且必须是 H3 那种 in-context 重生成出来的 2K，那目前只有 API 一条路，ComfyUI 和开源权重都给不了。
你在意合规边界吗？ H3 的许可证全称是 MiniMax H3 Community License Agreement，链接在 Hugging Face 仓库的 LICENSE 文件里；ComfyUI 本身是 GPL-3.0。我没有读过任何一份 LICENSE 正文，所以商用边界、二次分发、产出物权属这几件事我一个字都不解读，一律以官方 LICENSE 原文为准。这不是敷衍，是这类问题上”看起来像”和”确实是”之间的距离太大。
六、本文不比的维度，以及唯一的结论
明确写出来，免得你以为我忘了写：
- 画质好坏、量化损失百分比、两边的效果对比——没有任何官方评测数据，我们也没有本机对比过，不比。
- 模型文件体积、显存需求——教程页没给，MiniMax README 也没给，不写。
- 推理速度、生成耗时——同上。教程页提到
Patch Sage Attention KJ为可选优化时说”可加速约两倍”，那是教程页的表述，引用到此为止，不是实测结论。
所以这篇能给出的结论只有方法论那一条，但它是真的有用：
两边不要混着评估。 你在 ComfyUI 里得到的结果，反映的是”量化权重 + 无 Context-IR 预处理 + 模板那一套采样配置”的组合；你按官方 README 跑出来的结果，反映的是 BF16 权重加上你自己那套流程。它们中间隔着至少两层变量，把其中一边的观感搬去评判另一边，得到的结论是无效的。
换一边就要重新校准预期。 从 ComfyUI 转到官方推理栈，或者反过来，提示词写法、参数手感、失败模式都可能要重新摸一遍，别指望经验能平移。尤其是提示词——官方模板说明明确提醒，ref2va 的输出对提示词措辞非常敏感，要按连接顺序用 <Picture 1>、<Video 1>、<Audio 1> 这类标签精确引用参考输入，并说清哪个参考驱动画面的哪一部分。这类标签在两边都要原样写，不能改成中文。
记录你用的是哪一套。 这听起来像废话，但当你手里同时有 fl2va 和 ref2va 两个文件、又在另一台机器上放着官方 BF16 checkpoint 时，三个月后回看自己的产出，如果没记下当时用的是哪套权重、ComfyUI 是哪个版本，那些经验基本等于作废。版本号写进你的记录里，v0.31.0 这样写，别写”最新版”。
延伸阅读
- ComfyUI 里 H3 的分辨率与帧数是怎么定的
- 音视频联合 latent 是怎么解码成一个 MP4 的
- SGLang / vLLM / diffusers / ComfyUI：H3 四种跑法怎么选
本文依据 MiniMax H3 官方仓库（github.com/MiniMax-AI/MiniMax-H3）的 README 与模型配置文件，以及 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README 与 release notes 整理，核对日 2026-08-09，ComfyUI 对应版本 v0.31.0。ComfyUI 侧的模型文件与工作流信息来自 docs.comfy.org 的官方教程与 Comfy-Org/workflow_templates 仓库的模板文件。本文内容为官方文档与仓库口径，非本机实测，未在本机部署或调用过 H3，也未在 ComfyUI 中运行过相关工作流。模型、部署方式、参数默认值与功能随版本变动，请以官方文档与官方最新说明为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。