minimax_h3_fl2va_int8_convrot.safetensors 是什么文件、该放哪个目录

先把结论放最前面，省得你往下翻。

minimax_h3_fl2va_int8_convrot.safetensors 是 Hugging Face 上 Comfy-Org/MiniMax-H3 仓库里的一个扩散模型权重文件，在仓库内的路径是 diffusion_models/minimax_h3_fl2va_int8_convrot.safetensors。下到本地之后，它应该放进：

ComfyUI/models/diffusion_models/

不是 checkpoints/，不是 unet/，也不要在里面再套一层文件夹。文件名一个字符都别改。

这篇写出来是因为有不少人是直接把这串文件名粘进搜索框的——说明看到它的场景多半是下载列表、别人发的工作流截图，或者某个教程里一闪而过的一行，手里只有名字，不知道它是干什么的、跟旁边那几个长得很像的文件差在哪。下面就按仓库的实际文件清单把这件事说清楚。

仓库里到底有哪些同族文件

调 Hugging Face 的模型 API（https://huggingface.co/api/models/Comfy-Org/MiniMax-H3?full=true）能拿到完整文件清单，再用 tree 接口能拿到每个文件的字节数。下面这张表是 2026-08-24 拉取的快照，仓库那一刻的 lastModified 是 2026-08-23T21:41:17.000Z。体积会随仓库更新变化，这里给的是那一次快照的值，不是什么恒定参数。

diffusion_models/ 目录下一共十个文件，fl2va 与 ref2va 各五个，命名规则完全对称：

文件名	字节数	约合
minimax_h3_fl2va_bf16.safetensors	66280487368	61.7 GiB
minimax_h3_fl2va_int8_convrot.safetensors	34038892334	31.7 GiB
minimax_h3_fl2va_pruned_bf16.safetensors	40225724176	37.5 GiB
minimax_h3_fl2va_pruned_int8_convrot.safetensors	20970379616	19.5 GiB
minimax_h3_fl2va_pruned_fp8_scaled.safetensors	20958205608	19.5 GiB

ref2va 那五个名字把中间的 fl2va 换成 ref2va，其余部分一模一样，体积也基本一致（ref2va_int8_convrot 是 34038894550 字节，跟 fl2va 那个差了两千多字节，这种量级的差别不用当回事）。

所以你搜的这个文件，和你可能同时搜到的 minimax_h3_fl2va_pruned_int8_convrot.safetensors，是同一族里的两个不同档位：一个带 pruned，一个不带。这是它们唯一的区别，也正是最容易看串行的地方——两个名字只差六个字符，扫一眼很难分清。

顺带把另外几个文件也列一下，因为光有扩散模型跑不起来：text_encoders/ 下有三个 Qwen3-VL-32B 的文件（bf16 51506295256 字节、int8_convrot 27141342152 字节、nvfp4_awq 15687142551 字节），vae/ 下有两个（minimax_h3_video_vae_fp16.safetensors 5207808496 字节、minimax_h3_audio_vae_fp32.safetensors 605254808 字节）。此外仓库里还有 loras/ 三个 turbo 加速 LoRA 和 embeddings/ 十个 .safetensors。完整的五个文件与目录对应关系，另一篇讲得更细。

文件名的每一段在说什么

这类文件名不是随手起的，每一段都对应一个可核实的事实。

minimax_h3 —— 模型是 MiniMax H3。这个仓库的 README 第一行就写明它是 “Repackaged model files for ComfyUI”，原始模型仓库是 MiniMaxAI/MiniMax-H3。两个仓库名很像，但里面的东西不是一回事，别下错。

fl2va —— 任务族。ComfyUI 源码里 comfy_extras/nodes_minimax_h3.py 的 MiniMaxH3ImageToVideo 节点，类注释写的是 “t2va and fl2va: prompt (+ optional first/last keyframes) -> conditioning + AV latent”。也就是说这套权重覆盖两类活：纯文本生成（t2va），以及给了首帧、尾帧或两者都给的情况（fl2va）。对应的另一套是 ref2va，走参考图 / 参考视频 / 参考音频那条路，节点是 MiniMaxH3ReferenceToVideo。两套权重不通用，只下一个就打开另一类模板，加载器下拉框里会是空的。

pruned —— 有它和没它是两个不同的文件。但要老实说：Comfy-Org/MiniMax-H3 的 README 并没有解释 pruned 具体裁掉了什么，我们也没有在 ComfyUI 源码或 MiniMax 官方仓库里找到对应说明。能确认的只有体积差——同为 bf16，不带 pruned 的是 66280487368 字节，带 pruned 的是 40225724176 字节。这个差距不小，但差在哪，官方没写，我们就不替它编一套解释。

int8 —— 权重以 8 位整数存放。在 ComfyUI 的 comfy/quant_ops.py 里，int8_tensorwise 这个量化格式的 storage_t 就是 torch.int8。

convrot —— 跟 int8 是一组的。ComfyUI 加载权重时（comfy/ops.py），当量化格式是 int8_tensorwise 且配置里带 convrot 时，会额外读一个 convrot_groupsize，默认值 256。至于 convrot 本身在解决什么问题，ComfyUI 源码在另一处（comfy/ldm/wan/model_animate2.py）留了一句注释，说 convrot 是让低比特扛住那种极端的逐通道离群值的东西。这句注释写在 Wan 的模型文件里，不是专门针对 H3 说的，但用的是同一套量化实现。

.safetensors —— 权重容器格式，跟内容无关。

fp8_scaled —— 另一档量化。README 对这一档给的建议很直白：fp8_scaled 只在你没法用 int8_convrot 的时候才用。

有个前提：int8_convrot 挑 PyTorch 版本

这条在 README 里写得很明确：对扩散模型来说，如果你的 PyTorch 是 cu130 或更高，优先选 int8_convrot。

这不是一句可有可无的推荐。ComfyUI 的 comfy/quant_ops.py 在初始化时会检查 torch.version.cuda，如果主版本低于 13，就直接把加速后端的 CUDA 部分关掉，并打一条大写的 WARNING，说你需要 cu130 或更高才能用上优化过的 CUDA 算子。也就是说，int8_convrot 这一档是奔着那条路径去的；PyTorch 版本不够，README 让你退到 fp8_scaled。

所以在纠结「下哪个」之前，先去确认自己那套环境的 PyTorch 是什么 CUDA 版本。这一步比纠结文件名省事得多。

带 pruned 和不带 pruned，怎么选

先说一个能直接拿来用的事实：ComfyUI 三个官方工作流模板里，UNETLoader 填的都是带 pruned 的那一个。

• T2V 与 I2V 模板的模型链接和目录树里给的是 minimax_h3_fl2va_pruned_int8_convrot.safetensors
• R2V 模板给的是 minimax_h3_ref2va_pruned_int8_convrot.safetensors，模板 JSON 里 UNETLoader 的取值就是这一串

这意味着：如果你的目标只是「把官方模板跑起来」，那你要下的其实是带 pruned 的那个，而不是你搜的这一个。下载完直接打开模板，加载器里能对上名字，不用改任何东西。

反过来，如果你确实想用不带 pruned 的 minimax_h3_fl2va_int8_convrot.safetensors，要注意两件事：

第一，模板不会自动指向它。加载模板之后得手动把 UNETLoader 的下拉项换成这个文件名。文件在目录里但没被选中，是个很安静的坑——工作流照跑，跑的是另一个模型。

第二，它比 pruned 版大了一截（快照口径下 31.7 GiB 对 19.5 GiB）。这个差距对下载、磁盘和加载都是实打实的。至于对显存的影响、以及两者产出的差别，README 没有给任何对比数据，我们也没有在本机跑过这些模型，所以这里不给任何效果层面的说法。想知道差多少，只能自己在自己那台机器上比。

一句话的决策路径：照官方模板走 → 下 pruned 版；明确知道自己为什么要更大的那一档 → 下不带 pruned 的，并且记得手动改 UNETLoader。

放错目录会怎样、怎么验收

放错目录不会报错，这才是它烦人的地方。ComfyUI 不会跳出来说「你这个文件放错了」，它只是在加载器节点的下拉框里不显示这个文件。等你打开工作流、点开 UNETLoader 的下拉、发现里面空空如也，才知道出事了。

验收方式就一条：去节点的下拉框里找文件名。

• UNETLoader 里应该能选到 minimax_h3_fl2va_int8_convrot.safetensors（或你下的那个 pruned 版）
• CLIPLoader 里选文本编码器文件，并且它的 type 那一项要是 minimax——这是个跟文件名相互独立的字段，选错了文件照样能加载，肉眼扫一遍很容易漏
• 两个 VAELoader 分别是 minimax_h3_video_vae_fp16.safetensors 和 minimax_h3_audio_vae_fp32.safetensors，两个都在同一个 vae/ 目录下、下拉框里挨着，选重了一眼看不出来

选不到的时候，先按 R 刷新一次图再看。还是没有，就去查目录层级：最常见的是把下载文件夹连同它自己的名字一起搬进了 models/，多套了一层；其次是落进了 models/checkpoints/。

关于两个 VAE 为什么是两个、以及采样器出来那一根 LATENT 线为什么要分叉接进两个解码节点，这条链路单独有一篇；音频那一路的原理在音频 VAE 那篇。ComfyUI 侧这套量化权重和 MiniMax 官方 BF16 权重的关系，也有一篇专门讲，简单说就是：两边不是同一套东西，评估的时候别混着算。

关于 pt_h3concatavlatent：我们没能核实

有人在搜 pt_h3concatavlatent。这一串我们查了，但没能核实到它在官方仓库里的存在，所以下面只说查了哪些地方、查到了什么，不做推断。

查过的地方：Comfy-Org/MiniMax-H3 仓库 API 返回的完整文件清单（三十来个文件，没有任何一个叫这个名字，也没有任何 .pt 文件）；MiniMaxAI/MiniMax-H3 的 GitHub 仓库文件树与 Hugging Face 仓库的两百多个文件名；ComfyUI 主仓库的全量源码，逐字搜 pt_h3 和 h3concat 都是零命中；三个官方工作流模板 JSON 里的全部节点类型。

所以它不是 Comfy-Org/MiniMax-H3 里的一个模型文件——这一点可以确定，因为那个仓库的文件清单我们是完整拿到的。

能补充的只有一条旁证：ComfyUI 里确实存在一个叫 LTXVConcatAVLatent 的节点（显示名 “Concat AV Latent”），它的作用是把一个视频 latent 和一个音频 latent 合并成联合的 AV latent，节点描述里明确写了适用于任何 AV 模型、并把 MiniMax H3 举为例子之一。名字上跟 h3concatavlatent 有几分像。但这只是名字相近，我们没有依据断言搜索这串的人要找的就是它，也不知道 pt_ 这个前缀从哪来。如果你手上有出处（某个截图、某个报错、某个工作流文件），以那个出处为准，别拿这段当答案。

另外提醒一句：.pt 这个后缀在 H3 语境里确实出现过一次——Comfy-Org/MiniMax-H3 的 README 讲 embeddings 用法时，写的是在 CLIPTextEncode 节点里用 embedding:embedding_filename.pt 这样的形式调用，并注明可以省略 .pt 扩展名。这是提示词里的调用语法，不是磁盘上的文件名。两件事别混。

什么情况下这篇帮不上你

你要走 MiniMax 官方推理栈。 本文讲的全是 ComfyUI 侧重打包的权重。官方那条路用的是 MiniMaxAI/MiniMax-H3 里的原始 checkpoint，文件组织方式、加载方式都不一样，这里的目录结论套不过去。怎么下、--include 在挡什么，另有一篇。

你想知道跑起来要多少显存。 官方没给，我们也没在本机跑过，所以本文一个显存数字都不写。文件体积不等于显存占用，别拿上面那张表去倒推。

你在配多机共享模型目录。 上面说的是单机默认路径，共享目录涉及 ComfyUI 的额外模型路径配置，是另一个话题。

你手上的仓库快照比 2026-08-24 新。 文件清单和体积都随仓库更新变化，以你打开 Hugging Face Files 页面时看到的为准。

延伸阅读

• MiniMax H3 的五个模型文件分别放哪
• ComfyUI 里的 H3 和官方权重不是同一套
• 音视频联合 latent 是怎么解码成一个 MP4 的
• 在 ComfyUI 里跑 MiniMax H3：版本门槛、模型放置与 R2V 模板节点链拆解

---

本文的文件名、仓库内路径与字节数来自 Hugging Face 模型 API（Comfy-Org/MiniMax-H3 的模型信息与 tree 接口）在 2026-08-24 的返回，以及该仓库 README 原文；节点名、量化格式与加载逻辑来自 ComfyUI 官方仓库（github.com/comfyanonymous/ComfyUI）的 comfy_extras/nodes_minimax_h3.py、comfy/quant_ops.py、comfy/ops.py；模板取值来自 Comfy-Org/workflow_templates 的三个 H3 模板 JSON。本文内容为仓库文件清单与源码口径，非本机实测，未下载或运行过上述任何模型文件。文件清单、体积与推荐档位随仓库更新变动，请以 Hugging Face 仓库页面的实际内容为准。