MiniMax H3 的原生立体声是怎么做出来的：H3-AudioVAE 与音视频联合预测

2026-08-09

「带原生立体声的视频」这句话，第一次看到的时候我是有点不以为然的。视频模型配音这件事，过去两年常见的做法是流水线：先出画面，再拿画面去驱动一个音频模型补声音，最后对齐。这样做出来的东西也能叫「有声音的视频」，但它是两段工程拼起来的。

MiniMax H3 的 README（github.com/MiniMax-AI/MiniMax-H3，核对日 2026-08-09）里，「原生」这个词有具体的技术所指，不是市场话术。这篇就顺着官方仓库的架构章节和仓库内的 config 文件，把音频这一路捋清楚——它跟视觉那一路的差别在哪，哪些数字可以拿来互相印证，以及哪些结论我们没有依据、不能推。

「原生」指的是联合预测，不是后期配音

先把最关键的一句话拎出来。README 的 Model Architecture 章节写得很明确：H3-Omni-Transformer 联合预测视频与音频的 latent，然后再分别解码为视频与立体声音频。

注意这里的顺序。不是「先有视频、再生成音频」，而是同一个 Transformer 在同一条序列上，同时把两种模态的 latent 预测出来；音画的对应关系是在 latent 层面就成立的，解码只是把两组 latent 各自还原回波形和像素。这就是「原生」二字的全部含义——出自同一次预测，而非两次串联。

这个设计对应到输入侧也是一致的。H3-Base 用各模态对应的 encoder 或 VAE 把不同模态编码成一条统一的 packed multimodal sequence，进 Transformer 之前用 RoPE 表达 token 之间的空间与时间关系。分工是：文本由 H3-Encoder 编码，视觉输入由 H3-Encoder 与 H3-VisualVAE 共同编码，音频只由 H3-AudioVAE 编码。音频这一路没有走文本编码器，它就是一条独立的 VAE 通道，进了同一条序列。

顺带一提，Omni-Transformer 的注意力层与 FFN 层都不含模态特定结构，模态特定的参数只在输入输出层与 AdaLN 分支里。也就是说，主干的注意力与 FFN 不对模态做区分，两种模态是在同一套注意力里被一起处理的。这一点跟「联合预测」是自洽的。另外官方说明里，位置关系用的是三维多模态旋转位置编码（MM-RoPE），表示的是时间与两个空间维度 (t, h, w) 上的位置。

H3-AudioVAE：两个声道，一套权重，各走各的

现在看音频编码器本身。README 对 H3-AudioVAE 的描述有三条，每条都值得展开。

第一条，左右声道使用同一套 encoder 与 decoder，但每个声道独立处理，解码之后再重新合并。 H3 支持立体声输入与输出，就是靠这个结构实现的。

这个设计初看有点反直觉。既然要出立体声，为什么不直接做一个双通道的编码器，让模型自己去学左右之间的关系？官方没有解释理由，我也不去替它编。下面这段是按「共用一套权重、逐声道独立处理」这条结构描述做的推断，不是官方结论，你可以顺着自己判断：既然 encoder/decoder 只有一套权重，那么声道数就不会改变这部分的参数规模，单声道和立体声走的是同一条路径，区别只在跑一遍还是跑两遍；相应地，左右声道之间的关系就不是由 VAE 内部结构去捕捉的。

对使用者来说，可以据此得出的判断是：立体声的「立体」，落点在 latent 这一层，而不是在解码环节额外加工出来的——毕竟按 README，解码器对两个声道是一视同仁地各跑一遍。

第二条，对每个声道，把 32kHz 的音频压缩成时间速率为 40Hz 的 latent token 序列。 这是整篇里最具体的一个数字，也是最容易被忽略的一个。

拿这两个官方给的速率直接相除：32000 除以 40 等于 800，也就是时间轴上 800 倍的速率压缩，一个 latent token 对应 25 毫秒的音频。这里只做了速率换算，没有把 latent 的通道数算进去，所以它不是「数据量压缩了 800 倍」的意思。这个粒度值得和视觉侧对照着看：H3-VisualVAE 是 f16t4d24——空间压缩 16 倍、时间压缩 4 倍、24 个 latent 通道，视觉 latent 进 Transformer 前还要按 1 × 2 × 2 的 patch size 再 patchify 一次，有效空间下采样因此变成 32 倍，时间下采样仍是 4 倍。

两条路的压缩逻辑完全不同：视觉是在空间和时间两个维度上分摊压缩，音频只有时间一个维度可压，所以单看时间轴，音频的压缩比要激进得多。这也解释了为什么音频那一路能以相对可控的 token 数量塞进同一条多模态序列里。

第三条，README 称 H3-AudioVAE 的 latent 空间优化受 VA-VAE 启发，目标是在保留音频重建质量的同时，让生成模型更容易学习这个 latent 空间。

这个提法和视觉侧是呼应的：官方对 H3-VisualVAE 也说做了 latent 空间优化，同时改善重建质量与「可被生成模型学习的难易度」，并且在 encoder 训练完之后额外训练了一个基于 ViT 的 decoder 来降低解码成本。两边都在强调同一件事——VAE 的目标函数不只是重建得像，还得让下游那个 Transformer 好学。

这里我得停一下划条线：官方只说了「受 VA-VAE 启发」和优化目标，没有给任何重建指标、音质评分或与其它音频 VAE 的对比数据。所以「H3 的音质如何」这个问题，从官方仓库里是得不到答案的，我也没有部署过 H3 去听。任何声称 H3 音质好坏的说法，你都该问一句依据是什么。

config 里的 32：两处独立文件互相印证

架构描述是文字，容易读岔。好在仓库里有两份 config 可以拿来核对。

transformer/config.json 是 diffusers 格式（_class_name 为 MiniMaxH3Transformer3DModel，_diffusers_version 为 0.36.0.dev0），里面与本篇直接相关的是这三行（同一份 config 里还有层数、注意力头数等键，与音频路径无关，这里不搬）：

键	值	对应
`in_channels`	24	视觉 latent 通道数，与 README 的 f16t4d24 里的 d24 一致
`audio_in_channels`	32	音频侧的 latent 维度
`patch_size`	`[1, 2, 2]`	与 README 的 `1 × 2 × 2` patchify 一致

FL2VA/transformer/config.json 是原始 checkpoint 格式（_class_name 为 MiniMaxH3DiTModel，_diffusers_version 为 0.32.2），键名不同但数值一致，其中一行写作 latents_dim / audio_latents_dim = 24 / 32。

怎么读这张表，以及可以据此做什么判断：两份格式不同、版本号不同的配置文件，在视觉 24、音频 32 这两个数上完全对得上。视觉的 24 有三处来源互证——两份 config 加 README 里 H3-VisualVAE 的「24 latent channels」；音频的 32 只有两份 config 互证，README 的 H3-AudioVAE 段落并没有写音频 latent 的维度。所以更稳妥的说法是：32 是 config 里明写的音频侧 latent 维度，而不是「README 说音频 latent 是 32 维」。你在别处看到这两种说法混着用时，可以按这个区别去核。

顺便一提，仓库里并存两套格式这件事本身也是事实——_diffusers_version 一个是 0.36.0.dev0，一个是 0.32.2。你如果按 diffusers 的路子加载，别拿错目录。

需要克制的是：这些数字只能用来互相印证结构，不能用来算显存、算速度、算 token 吞吐。 官方没给显存数字，我们也没跑过。想知道「跑不跑得动」，唯一有依据的参照是 README 部署章节给出的官方示例配置（例如 SGLang 示例使用 4 GPU 配置），而那是示例配置，不是硬性最低要求，更不是你机器上的结论。

落到工程上：为什么 ComfyUI 侧要装两个 VAE

架构说得再清楚，不落地也是空的。ComfyUI 侧的 H3 支持恰好把这套设计暴露得很直白。

按 docs.comfy.org 的官方教程与 Comfy-Org/workflow_templates 仓库里的模板文件，跑 H3 需要往 ComfyUI/models/vae/ 放两个 VAE 文件：minimax_h3_video_vae_fp16.safetensors 和 minimax_h3_audio_vae_fp32.safetensors。工作流里对应两个 VAELoader，下游分别接 VAEDecode（视频）与 VAEDecodeAudio（音频）。

官方模板说明里有一句话，正好是架构那句「联合预测」在节点图上的投影：采样器输出的是音视频联合的 LATENT，同时喂给两个解码节点，每个解码节点会自动从打包的 latent 里取出属于自己的那一半。最后由 CreateVideo 把两路 mux 成一个带同步声音的成片。

所以「为什么要装两个 VAE」这个新手常见疑问，答案不是「ComfyUI 麻烦」，而是模型本来就是这么设计的：一次预测、两路解码。

还有一个细节值得注意：视频 VAE 是 fp16，音频 VAE 是 fp32。官方没有解释为什么音频侧用更高精度，我不做推测，只提醒一句——下载时别按视频 VAE 的命名习惯去猜音频文件名，它们的精度后缀确实不一样。另外，v0.31.0（2026-08-08）的 release notes 里有一条 fix(minimax): cast raw parameters to input device in H3 VAEs，说明 H3 的 VAE 在设备转换上刚修过一个问题，跑 H3 建议至少到这个版本。

顺便还得提醒一句边界：ComfyUI 用的是 Comfy-Org/MiniMax-H3 的量化权重，而 MiniMax 官方发布的 checkpoint 是 BF16。两边不是同一套权重，评估结果时别混着看，我们也没有任何对比数据可以给。

你能从这套设计里推出什么，不能推出什么

能推的：

输出规格是官方给的硬数字——32kHz 立体声、24 FPS、时长 4 到 15 秒。音频侧的 32kHz 和 H3-AudioVAE 描述里的 32kHz 是同一个数，前后一致。
音画的对应关系在 latent 层面就已经确定，不是后期对齐出来的。对应到工程上，ComfyUI 官方 R2V 模板的节点链里也确实没有出现任何音画对齐节点，两个解码节点各自从同一份 latent 里取自己那一半，CreateVideo 直接 mux。
想做只有声音没有画面的东西，H3 不是这个用途。它的输出形态是视频加音频，音频不是独立产物。
在 Ref2VA 模式下，README 明确规定音频参考必须伴随图像或视频输入，不能作为唯一输入；每段 2 到 15 秒，最多 3 段，总时长不超过 15 秒。

不能推的：

不能从 40Hz、32 通道这些数字反推音质、反推显存、反推能不能在你的卡上跑。
不能把「H3 原生支持稀疏注意力的训练与推理」当成「开源版能跑稀疏注意力」。README 写得很清楚：首次开源发布只提供 full attention 的推理，稀疏注意力实现将在未来更新中发布。这是能力与发布状态的区别，是这个项目上最容易被写错的一处。
不能默认拿到开源权重就等于拿到官方效果。开源的是 H3-Base（768p 输出），前面的 H3-Context-IR 与后面的 H3-Regenerate-2K 都未包含在本次开源发布中，只提供 API。而 README 明确强调 H3-Context-IR 对最终输出质量至关重要，强烈建议要么接入它，要么照 Prompting Guidance 自建上下文处理系统。

最后是许可。H3 的许可证全称是 MiniMax H3 Community License Agreement，原文在 Hugging Face 仓库的 LICENSE 文件里。这份正文我没有读过，所以关于商用边界、再分发条件、产出物权属这些问题，这篇不给任何解读，请以官方 LICENSE 原文为准。

延伸阅读

本文依据 MiniMax H3 官方仓库（github.com/MiniMax-AI/MiniMax-H3）的 README、模型配置文件与官方 h3-prompt-writing skill 文档整理，核对日 2026-08-09。本文内容为官方仓库口径，未在本机部署或调用过 H3。模型、部署方式与许可条款以官方最新说明为准。ComfyUI 侧的模型文件与工作流信息来自 docs.comfy.org 的官方教程与 Comfy-Org/workflow_templates 仓库的模板文件。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。