H3-VisualVAE：f16t4d24 是什么意思

2026-08-09

第一次翻 MiniMax H3 的 README，看到 H3-VisualVAE 那一段写着 f16t4d24，很容易直接划过去——看着像个内部编号。但它其实是一串压缩过的事实，把它拆开，你就能顺手回答好几个后面必然会遇到的问题：为什么 transformer/config.json 里 in_channels 偏偏是 24、为什么 README 一会儿说空间压缩 16 倍一会儿又说有效下采样 32 倍、以及 patch size 这个看起来不起眼的 [1, 2, 2] 到底改了什么。

这篇只讲 H3-VisualVAE 这一块，依据是截至 2026-08-09 的官方仓库 README「Model Architecture」章节和仓库内的 config 文件。

一、三个字母各对应一个压缩维度

按 README 的说法，H3-VisualVAE 是一个时间因果（temporally causal）的视频自编码器，它的规格是：空间压缩因子 16×、时间压缩因子 4×、24 个 latent 通道，官方把这三个数缩写成 f16t4d24。

这三个数和记号里的三段一一对应（README 只给了「f16t4d24」这个缩写本身和上面三个规格，字母各代表哪个词是按顺序对应上去的，不是官方逐字解释过的）：

记号	对应的官方规格	官方给的值
`f16`	空间压缩因子	16×
`t4`	时间压缩因子	4×
`d24`	latent 通道数	24

也就是说，一段视频进 encoder，宽高各被压掉 16 倍，帧方向被压掉 4 倍，换来的是每个 latent 位置上 24 个通道的表示。这三个数不是三种可选配置，是同一个模型的三个固定属性，看到别处写成别的数字的，那是别的模型的记号，别混着记。

「时间因果」这个词 README 只给了名字，没有展开描述实现细节。所以这里能确定的只有一点：官方把 H3-VisualVAE 归类为时间因果的视频自编码器，这是一个结构性描述。至于它在 H3 这一侧具体怎么实现、对时间维度的切分意味着什么，官方没有给出描述，我们也没有部署过，所以不往下推。读到别人把「时间因果」展开成一大段实现细节时，先回头确认那段是不是有出处。

二、`1 × 2 × 2` 才是 16 变 32 的那一步

这是整段里最容易读岔的地方。README 先说空间压缩 16×，过两句又说进入 Transformer 的视觉 token「有效空间下采样因子为 32×」。看起来自相矛盾，其实是两个阶段：

VAE 编码阶段：视频 → latent，空间 16×，时间 4×，通道 24。
patchify 阶段：latent 在送进 H3-Omni-Transformer 之前还要再切一刀，patch size 在 (time, height, width) 三个维度上是 1 × 2 × 2。

第二步的 2 × 2 又在高和宽上各合并了一次，于是：

空间：16（VAE）× 2（patch）= 32×
时间：4（VAE）× 1（patch）= 4×

时间维度上的 patch 是 1，等于没切，所以时间下采样一路停在 4×，没有跟着变成 8×。这条推导链值得记住，因为它是后面所有「token 数怎么变」讨论的起点：空间方向真正生效的是 32，时间方向真正生效的是 4，两个方向的粒度并不对称。

顺手提醒一下这个算术的边界。「有效空间下采样 32×」是官方对 token 化粒度的描述，它只说明了高宽两个方向各被压掉多少，属于结构参数，不是性能结论。**官方没有给显存占用、推理速度、每秒 token 数中的任何一个，我们也没有跑过，所以到这里为止，不要接着往「所以需要几张卡」上推。**这条边界后面还会再提一次，因为它是这类架构文章最容易被读者自行外推的地方。

三、拿 config.json 交叉验证一遍

只信 README 一处说法容易读错，好在仓库里有 config 文件可以对。transformer/config.json 是 diffusers 格式（_class_name: MiniMaxH3Transformer3DModel，_diffusers_version: 0.36.0.dev0），里面有两个键正好和上面这段对得上：

键	值	对应 README 的哪句话
`in_channels`	24	H3-VisualVAE 的「24 latent channels」
`patch_size`	`[1, 2, 2]`	「patchified with a patch size of 1 × 2 × 2」
`audio_in_channels`	32	音频侧的 latent 维度，与视觉无关

in_channels: 24 的意思是 Transformer 输入端接的就是 VisualVAE 吐出来的 24 通道 latent，两边严丝合缝。patch_size 的三个数与 (time, height, width) 的顺序一致，第一位是 1，再次印证时间方向没有额外切分。

仓库里还并存着另一份原始 checkpoint 格式的 FL2VA/transformer/config.json（_class_name: MiniMaxH3DiTModel，_diffusers_version: 0.32.2），键名不一样但数值一致，其中 latents_dim / audio_latents_dim 是 24 / 32——和 diffusers 那份的 in_channels / audio_in_channels 对上了。两份 config 的 _diffusers_version 不同，说明仓库里本来就并存两套格式，这不是谁写错了。

这个交叉验证的实际用处是给你一个便宜的判断依据：官方这两份 config 里视觉侧的 latent 维度都是 24，那么在第三方转换脚本、社区分支或者某份「改好的」配置里看到别的数字时，先别当成调参，而要先确认它接的还是不是原版 VisualVAE 的输出。 in_channels 描述的是两个组件之间的接口宽度，改动它意味着接口对不上了，这跟调一个采样步数不是一类事。同理，看到 32 别下意识往视觉上套，那是 H3-AudioVAE 那条链路上的数。

四、为什么 decoder 是后来单独训的，而且是 ViT

README 里还有一句容易被跳过的话：官方在训练完 encoder 之后，额外训练了一个基于 ViT 的 decoder，目的是降低解码成本并进一步提升重建质量。

这句话里有三条能站住的事实，值得逐条拆开：

decoder 是在 encoder 训练完成之后额外训练的，也就是说它是一个独立的训练阶段，不是 encoder 训练的副产品。
它的结构基于 ViT，与 encoder 侧不必是同一套对称结构。README 把它单独点出来，说明这是一次有意的结构选择。
官方给这次改动写了两个目标：降低解码成本、进一步提升重建质量。这两个目标是并列写的，不是先后关系。

第三条是最值得留意的。降本和提质通常被当成一对要权衡的目标，官方在这里把它们并列成同一个改动的两个结果，这是 README 的原话口径。至于这两个目标各自达成到什么程度、拿什么指标衡量，README 没有给数据，我们也没跑过，所以不写。

顺带说一句读文档的姿势：看到「额外训练」四个字，就该意识到这块内容在官方叙述里是被单独拎出来的一段，而不是顺手带过的实现细节。至于这个 ViT decoder 具体有多少层、跑得多快、重建质量比原来提升多少——同样是官方没给的数据，任何一个具体数字如果没标出处，多半是别人替官方补的。

五、「同时优化重建质量与可学习性」这句话在说什么

README 提到官方对 latent 空间做了若干优化，目标是同时改善重建质量和「可被生成模型学习的难易度」。这句话在论文语境里很常见，但它其实点出了一个真实的张力，值得展开一下（下面这段是对这句表述的解读，不是官方原文）：

只追求重建质量，最省事的做法是让 latent 尽量多带信息、结构尽量自由。但这样的 latent 空间对下游生成模型来说往往更难拟合。
只追求好学，可以让 latent 分布规整、维度压得更狠，但下游模型学得再好，最终也要经过 decoder 还原这一步，重建这一环的表现仍然取决于 VAE 本身。

所以「同时优化」这个措辞不是废话，它意味着这一块的设计是个折中，f16t4d24 这组数字就是折中的落点。旁证是 H3-AudioVAE 那一侧：README 明确说音频这一侧的 latent 空间优化受 VA-VAE 启发，目标同样是「保留重建质量的同时让生成模型更容易学习」。注意这句「受 VA-VAE 启发」官方只写在音频侧，别顺手搬到视觉侧去——README 对 VisualVAE 的说法就是「做了若干优化」，没有点名任何一个具体来源。能确定的只是两个模态在目标表述上是一致的：重建质量与可学习性一起看。

对使用者来说，这里可以拿走的判断是：VisualVAE 与 Omni-Transformer 是两个各自独立的环节，不该混在一起评价。 config 里 num_layers 写着 50，那是 Transformer 这一环的规模；而进出这一环的表示宽度是 24 通道，那是 VisualVAE 这一环定下来的接口。看到关于 H3 视觉侧的任何说法，先问一句它讲的是哪一环——是 latent 表示本身的问题，还是 Transformer 在这个表示上怎么工作的问题。这两类问题的证据来源不一样，笼统归给「模型」就没法往下查了。

六、几个容易读错的点，集中列一下

f16 不等于最终下采样率。 最终进 Transformer 的是 32×，中间隔着 patchify。看到有人拿 16 直接当有效下采样算，多半是漏了 patch_size。
时间方向不要跟着乘 2。 patch 的第一位是 1，时间下采样自始至终是 4×。
24 是视觉，32 是音频。 in_channels 与 audio_in_channels 是两条链路，不要互相印证成一个数。
num_attention_heads × attention_head_dim = 56 × 128 = 7168，而 hidden_size = 5376，二者不相等是 config 里的事实，但 config 只给了数值，不要据此反推内部实现怎么写的。
H3 原生支持稀疏注意力的训练与推理，属于模型能力；而首次开源发布只提供 full attention 的推理，稀疏注意力实现要等后续更新。这两件事必须分开说，别写成「开源版支持稀疏注意力」。

七、下一步该去查哪里

如果你的目标是搞清楚一段特定分辨率、特定时长的视频在这条链路上会变成什么形状的张量，那么 f16t4d24 加上 patch_size [1,2,2] 已经给全了下采样这一侧的公开依据；再往下就得以官方仓库里配置文件的实际字段为准，而不是继续从 README 的文字推。

如果你的目标是部署，那这篇给不了答案——下采样因子推不出资源需求。部署侧只能看官方 README 给出的部署命令与参数本身：命令行里带的 --num-gpus 4 是可以原样引用的官方参数，但它是官方示例给出的取值，不等于「必须四张卡」，更不等于你可以从 32× 和 24 通道自己算出一个显存数字来。这两件事之间没有官方给过的换算关系，任何看起来很像公式的东西都是别人补的。

如果你的目标是判断某个第三方权重是不是真的接的原版 VisualVAE，in_channels / latents_dim 是不是 24 是一个成本极低的检查点，值得在下载完先看一眼 config。

延伸阅读

本文依据 MiniMax H3 官方仓库（github.com/MiniMax-AI/MiniMax-H3）的 README、模型配置文件与官方 h3-prompt-writing skill 文档整理，核对日 2026-08-09。本文内容为官方仓库口径，未在本机部署或调用过 H3。模型、部署方式与许可条款以官方最新说明为准。