在 MiniMax H3 上跑 DiffusionNFT：音视频联合生成的开源 RL 训练方案

VeRL-Omni 团队公开了一套完整的开源流水线，用于给 MiniMax H3 做在线强化学习后训练 —— 这是一个 330 亿参数的模型，用单个 transformer 联合生成视频与立体声音频，也是目前唯一一个同类的开放权重视频生成系统。这次发布在 VeRL-Omni 的多模态训练框架中实现，背后是入选 ICLR 2026 Oral 的 DiffusionNFT 算法，覆盖文本到音视频、以及图像条件生成两种模式。它在技术上的分量不在奖励曲线 —— 那些还很早期 —— 而在于它详细编录了那些「让 RL 训练看上去在成功、实则朝着错误方向跑」的静默集成故障。

这项工作的核心教训适用范围远超 MiniMax H3：任何一个在时间步约定、权重排布或潜空间打包方式上偏离标准框架假设的联合多模态扩散模型，当开发者试图套用标准 RL 训练流水线时，都会产生类似的失效模式。训练指标动起来了，并不等于训练在正确地进行。

MiniMax H3，以及音视频联合生成为什么让 RL 训练变复杂

MiniMax H3 在架构上有几处不寻常之处，而它们恰恰对后训练至关重要。它的 H3-Omni-Transformer 是一个 330 亿参数的稠密单流 transformer，从一条统一打包的序列中联合预测视频与音频潜变量。视觉模态经过 H3-VisualVAE 处理 —— 一个时间上因果的自编码器，空间压缩 16 倍、时间压缩 4 倍、潜通道数 24 —— 进入 transformer 前还会以 1×2×2 的 patch 尺寸再做一次分块，最终形成 32 倍的有效空间下采样。音频模态则走另一条 H3-AudioVAE，把 32kHz 立体声压缩成每声道 40Hz 的潜 token，左右声道先独立处理再重新合并。

该 transformer 在时间、高度、宽度三个维度上使用三维多模态旋转位置编码，并采用按模态区分的 AdaLN 分支 —— 而不是按模态区分的注意力层或前馈层。这个设计选择带来一个推理上的后果：AdaLN 的调制输出可以预先计算并缓存，因此在仅做推理的部署中，模型约 130 亿参数无需加载，尽管它们包含在已发布的权重里。文本编码器是 Qwen3-VL-32B，从其第 50 层抽取隐状态送入 Omni Transformer。

另有两个设计决定把 H3 与标准流匹配模型区分开来。第一，H3 发布的是一个经过 CFG 蒸馏的检查点 —— 推理时不需要负向提示词，也不需要无分类器引导系数。第二，H3 的去噪时间步定义为「数据占比」（从干净数据到纯噪声的插值比例），而不是多数公开流匹配框架所用的 sigma 约定。H3 期望的速度向量相对标准约定还是反号的。这两处差异在对不上时都不会触发运行时错误 —— 它们只会静默地把梯度流反转或扭曲。

DiffusionNFT：干脆绕开逆向链

扩散模型 RL 微调的标准做法 —— DDPO、FlowGRPO 及类似方法 —— 是把逆向去噪链离散化，再估计生成结果在当前策略下的对数概率，类比于语言模型 RL 在 token 序列上算 log-prob。这给流匹配模型带来三个结构性问题：算法被绑死在某个特定的 ODE/SDE 求解器上；前向与逆向过程在训练中可能变得不一致；而且无分类器引导必须被塞进训练循环，显著增加复杂度。

DiffusionNFT（Diffusion Negative-aware FineTuning，负样本感知的扩散微调）走的是另一条路。它不去在逆向去噪轨迹上估计似然，而是通过流匹配监督，把奖励信号注入**前向**扩散过程 —— 也就是从干净数据走向噪声的那个方向。其机制是对比正负生成样本，从而定义出一个隐式的策略改进方向。高奖励输出被拉向常规的正向流匹配目标；低奖励输出则收到一个负向约束。训练目标于是成为一个改造过的流匹配损失，既不需要估计对数概率，也能配合任意黑盒采样器工作。

按论文中的正面对比，这一设计的实际后果是效率最高可达 FlowGRPO 的 25 倍。在 Stable Diffusion 3.5-Medium 上跑 GenEval 基准，DiffusionNFT 在 1000 个训练步内把分数从 0.24 提到 0.98；FlowGRPO 则要跑 5000 步以上、且全程开启 CFG 才达到 0.95。这些数字对应的是另一个模型（SD3.5-Medium）和另一个基准，与这里描述的 H3 实验不同，不应被当作对 H3 性能的预测 —— 但它们确立了「为什么选 DiffusionNFT 来做 H3 集成」的基本理由。VeRL-Omni 团队首先选中它，是因为它的训练信号链更短 —— 只需要干净潜变量、提示词嵌入和一个训练时间步，不必存下每一个中间去噪步 —— 这让集成时的失效模式更容易被逐个隔离和验证。

VeRL-Omni 的适配器架构如何把 H3 专有逻辑圈起来

VeRL-Omni 中的实现遵循三层分离。vLLM-Omni 负责 rollout 生成，保留 H3 原生的去噪循环，在返回联合视频与音频输出的同时，一并给出干净潜变量、提示词嵌入和时间步。FSDP2 配合 Diffusers 负责 actor 训练。VeRL-Omni 本身负责编排数据搬运、奖励收集、DiffusionNFT 损失计算，以及把 LoRA 同步回 rollout 策略。而 H3 专用适配器 —— 一个独立模块 —— 承担所有与该模型相关的翻译工作：把打包的潜变量拆成视频段与音频段、在时间步约定之间转换、修正速度符号，以及把 Diffusers 的 LoRA 层名映射到 vLLM-Omni 在 rollout 时所用的融合注意力与前馈结构上。

这种圈定在工程上很重要。没有它，H3 那些非标准约定就得在训练器、奖励管理器、rollout 系统和同步代码里各处分别处理。其中任何一处都可能悄悄把约定失配吸收掉，而不抛出一个可恢复的错误。把翻译层隔离在适配器里，团队至少确保了故障会在适配器边界上显现 —— 依然是静默的，但至少发生在单一且可预期的位置。

LoRA 配置使用 rank 64、alpha 128，目标模块被显式指定为 to_q、to_k、to_v、to_out.0、ff.net.0.proj 和 ff.net.2。这种显式指定不是风格选择，而是硬性要求。H3 的 rollout transformer 在 vLLM-Omni 的暴露方式下，把注意力投影和前馈权重按与 Diffusers 表示训练检查点时不同的方式做了融合。如果不把每个投影显式映射到 rollout 网络中对应的融合切片上，LoRA 适配器会注册成功，但在 rollout 时命中的实际层数为零 —— 也就是说 actor 的更新根本传不到采样策略上。训练损失在动，奖励曲线在变，而生成结果毫无变化。

延伸阅读：LAION 开放 8000 万条视频档案，冲击多模态训练数据的瓶颈

六种静默故障：一份系统性编目

VeRL-Omni 团队指认出 H3 集成过程中遇到的六种不同失效模式，每一种都有同一个特征：训练照常进行，损失保持有限，奖励曲线呈现出看似合理的动态，但模型实际上并没有朝着预期方向被训练。

第一种是时间步约定失配。H3 的 DiT 接受的是从 0（干净）到 1（含噪）的数据占比时间步，速度向量相对标准流匹配约定是反号的。一个不做转换就直接传入标准 sigma 值的框架，会让每一次参数更新的梯度方向都反过来。没有任何断言失败；训练日志里看不出任何异常。

第二种是 rollout 与 actor 之间的权重失配。训练侧检查点（Diffusers 格式）和 rollout 侧检查点（vLLM-Omni 的融合 DiT 格式）是同一个模型的两种结构不同的表示。从 rollout 侧抓取干净潜变量是简单的，但要验证「施加在 Diffusers 训练检查点上的 LoRA 更新确实回传到了融合的 rollout 检查点」，就需要逐投影的显式映射。没有它，适配器在训练侧注册成功，同步步骤无错完成，而 rollout 行为纹丝不动 —— 因为实际被更新的层数是零。

第三种是奖励流水线里的音频丢失。标准视频训练框架处理的是单模态潜空间。H3 输出的是一个同时含视频段与音频段的打包联合潜变量。一条不显式拆包、不把音频段路由给 CLAP 和 ImageBind 音视频打分器的奖励流水线，会只用视频算出奖励。而随着视频质量变化，合并后的奖励值照样会动，于是看上去音频正在被优化，其实根本没有。

第四种是张量并行下的 LoRA 跳过。在张量并行度为 2 时，第一个前馈投影层（ff.net.0.proj）在设备间的分片方式，会导致该层的 LoRA 更新被静默跳过。修法是把该层的 LoRA 显式切分以匹配张量并行的分片。这个故障只在 TP=2 或更高时出现 —— 也就是说单卡冒烟测试能过，而多卡生产运行却在静默地少施加更新。

第五种是分词器重编码引起的提示词漂移。H3 的文本编码器接受来自其原生分词器的预分词输入。有些框架会把 token ID 解码成字符串、再用另一个分词器重新分词，这可能引入细微的 token 序列差异，从而让条件信号发生偏移。vLLM-Omni 里 H3 专用的 agent 循环直接把 token ID 送进文本编码器，以避开这条路径。

第六种是 LoRA rollout 注册的假阳性。一个针对训练侧模型注册成功的适配器，并不保证它能映射到 rollout 侧模型，因为 Diffusers 表示与融合 DiT 表示的层命名约定不同。H3 适配器内置了一道预检，把目标模块列表与实际的融合结构核对，并在对不上时抛出明确错误，而不是任由它静默地错误注册。

为一个「覆盖面超出奖励模型量程」的模型做奖励设计

T2VA 与 FL2VA 训练都使用同一套双组件奖励：CLAP（laion/larger_clap_general）负责文本到音频的语义对齐，以及 ImageBind（imagebind_huge）负责音频到视频的对齐。CLAP 分数回答的是：生成出来的声音是否与提示词所描述的相符。ImageBind 的音视频分数回答的是：音频与视频是否属于同一个场景。

这两个打分器是刻意互补的。只按 CLAP 优化的模型，可以在满足文本—音频关系的同时，生成一段与音轨完全对不上的视频。只按 ImageBind 优化的模型，可以生成彼此自洽、却与提示词毫无语义关系的音视频。两者并用，才能同时在两个维度上约束生成。

对 H3 这样能力已经很强的模型来说，奖励钻空子的风险很大。团队指出，H3 的基础生成质量已经高到初始 rollout 就可用 —— 这让 RL 有效，但也让奖励钻空子来得很快。由于 CLAP 和 ImageBind 加起来并不覆盖视觉美感、运动自然度、长上下文时序一致性和细粒度语义细节，一个摸清了奖励模型偏好的模型，完全可以在拉高合并分数的同时，在那些没被测量的维度上退化。这正是团队建议「不要把合并奖励上升当作整体质量提升的证据」的原因 —— 除非同时把拆解开的 CLAP 与 ImageBind 子分数，与固定提示词的视频样本交叉核对。

在 8 卡、TP=2 的 T2VA 运行中，训练奖励从约 0.27 稳步升到 0.4 以上。在 FL2VA 验证中，检查点恢复时的奖励为 0.41（CLAP 0.16，ImageBind 0.25），经过三个或更多训练步升到 0.51，梯度范数落在 0.06–0.12 区间。这些数字均为作者自报，代表在受测硬件配置上的单次训练运行。

FL2VA：共用基础设施的首帧条件生成

FL2VA（首帧/尾帧到音视频）模式沿用与 T2VA 相同的奖励、actor 和 LoRA 同步基础设施，但通过 vLLM-Omni 官方的首帧/尾帧协议加入了图像条件。rollout 的数据契约在携带干净潜变量的同时带上条件帧的段索引；actor 读取这些元数据，在计算 DiffusionNFT 损失之前把条件帧潜变量固定住。优化目标只施加在生成出来的视频与音频潜变量上 —— 给定的关键帧潜变量不被修改。

这条约束对训练任务是承重的。一个连条件帧潜变量也一起优化的 FL2VA 模型，学到的不是「从给定起始图像补全运动与音频」，而是「改写关键帧去迁就自己生成的内容」。这个区别对每一个催生了 FL2VA 的实际用例都要紧：跨镜头保持角色身份、在既定场景端点之间做衔接、从给定的品牌帧延展广告素材。VeRL-Omni 适配器通过在 DiffusionNFT 损失计算中屏蔽条件帧位置，从结构上强制了这条约束。

已发表实验所用的 FL2VA 数据集由 ConsisID-preview-Data 中的 27815 条英文视频描述构成，经 DanceGRPO 过滤，可在该项目仓库获取。参考图像由 FLUX.1-dev 在 400×640 分辨率下生成，每条提示词使用确定性种子，经 seed-42 打乱后得到 27687 个训练样本和 128 个测试样本。用这套流水线产出的数据集，继承了 FLUX.1-dev 许可证中的非商用限制。

FL2VA 的 rollout 张量并行设为 TP=4，而不是 T2VA 默认的 TP=2。提高这个值是必要的，因为 FL2VA 的 rollout 检查点包含条件图像处理，会在 DiT 权重之外占用额外显存；在 TP=2 时，actor 到 rollout 的权重同步步骤在 96GB 显卡上放不下这份合并负载。

当前流水线的局限，以及尚未解决的部分

VeRL-Omni 团队对「这套已发布流水线验证了什么、没验证什么」说得很明确。这些训练运行证明了：为音视频联合生成搭一条可验证的端到端在线 RL 回路是可行的 —— 信号确实从 rollout 经奖励流到 actor 更新、再回到 rollout。它们并没有证明当前这套奖励组合能在任意提示词上带来感知质量的一致提升，也没有证明这条流水线在规模化时能稳健地应对奖励钻空子。

奖励模型的覆盖缺口是最大的未解问题。CLAP 与 ImageBind 合起来覆盖了文本—音频对齐与音视频一致性 —— 这是 H3 输出中要紧的两个维度。而运动一致性、视觉美感、跨完整 121 帧片段的长时序连贯、细粒度提示词遵循、独立于语义对齐的音频质量，以及立体声声场表现，全都在当前奖励范围之外。一个在 CLAP 和 ImageBind 上激进优化的模型，可能在上述任一维度上退化，而训练信号察觉不到这个变化。

训练侧的 rollout 为了吞吐只用 10 个扩散步，而验证用 40 步。这是一个务实的取舍 —— 按 40 步做全质量 rollout 会让训练循环慢大约四倍 —— 但它意味着训练时的潜变量分布与评估时的分布并不相同。团队指出，2 到 4 步只适合用来验证组件之间的数据契约，不适合评估生成质量。

H3 的稀疏注意力实现（模型卡称其在最后一个训练阶段引入）不在开源发布之列。已发布的权重跑的是全注意力。等 MiniMax 放出稀疏注意力实现后，H3-Base 在长序列上的推理成本预计将显著下降，这也会改善 RL rollout 的经济性。

最后，MiniMax H3 社区许可证限制在美国、欧盟、英国和韩国本地部署权重。这些地区想使用已发布的 VeRL-Omni 训练配方的开发者，需要向 MiniMax 单独申请个人许可 —— 该公司表示这条通道是开放的，但没有公布时间表。

H3 在开放权重视频版图中的位置

MiniMax H3「开放权重 + 原生立体声音频生成」的组合，目前没有直接的对等物。字节跳动的 Seedance 2.5 能生成最长 30 秒的片段 —— 是 H3 那 15 秒上限的两倍 —— 并可接受多达 50 个参考素材，但它只通过封闭 API 提供，没有微调通道，也不在生成视频的同时产出原生音频。谷歌的 Veo 3 同样能生成同步音频，但同样只有封闭 API，无法本地部署或做后训练。Wan（阿里）和 CogVideoX 这类开放权重视频模型提供了微调通道，也有活跃的 RL 研究社区，但两者都不生成音频 —— 它们的潜空间是纯视觉的，这意味着这项工作中搭起来的全部音视频联合训练基础设施，都得从零重新设计，而不是拿来适配。

因此，H3 拥有含音频的开放权重，其实际意义有两重。第一，它是唯一一个能让 RL 后训练同时改进「音视频对齐」与「领域特定音频质感」的模型。一次面向广告视频的微调，原则上可以教会模型：某个品牌内容里的声音应当符合某种特定的声学轮廓、音乐节奏应当与产品出现的节奏对齐、音效应当匹配画面中的动作 —— 而这一切都在同一个训练目标下、施加于一个联合优化的潜空间。第二，Hugging Face 上已经收录了数十个适配器变体与微调版本，H3 的社区采用度已经高到：任何一套 RL 微调方法论都能立刻找到现成的受众。

这道竞争护城河并非绝对。MiniMax 与迪士尼、环球和华纳兄弟探索的版权诉讼仍在美国联邦法院进行中，这给建立在 H3 之上的商业工作流带来法律风险。而地域性的许可排除意味着最大的那几个开发者市场 —— 美国、欧盟、英国和韩国 —— 在社区许可证下无法合法自托管 H3-Base，除非另行谈妥个人授权；这把 RL 微调的实践者限制在其他地区，或那些已取得个人许可的人身上。这些约束不影响训练方法论的技术有效性，但确实影响「能合法把微调后的 H3 检查点部署到生产环境」的开发者人群规模。

这套流水线为垂直微调打开了什么

VeRL-Omni 团队出发时要回答的核心问题是：给一个音视频联合扩散模型做在线 RL 后训练，究竟能不能正确地跑起来。在解决了那六类静默故障之后，答案是能 —— 而让这个答案成立的模块化适配器架构，同时也是让这一结果能在未来的模型上被复现的原因。

对实践者而言，最直接的实用价值是一份已验证的起始配置。做 H3 微调（用于广告、游戏素材生产或角色一致的片段生成）的团队，不必再各自独立地把每种失效模式重新踩一遍，而可以从一份已经指认出时间步约定修正、LoRA 映射要求、音频路由约束和张量并行 LoRA 修法的配方出发。截至本文报道时，这份已发布的配方文档尚未在 VeRL-Omni 团队之外被独立复现，因此把它当作起点、而非有保证的结果，是恰当的态度。

更大的意涵在方法论层面。随着视频生成模型越来越多地原生生成音频 —— 以及这个领域正走向那些还会合成 3D 结构、触觉或其他非视觉输出的模型 —— 每一种新模态都会带来它自己那套对框架假设的违背。这项工作留下的失效模式编目提供了一份诊断模板：检查时间步约定；对每一个 LoRA 目标检查 rollout 与 actor 的权重映射；把每一种模态都显式路由到它的奖励打分器；用固定提示词的样本来验证，而不是只看聚合奖励。这份模板在每一种新模型架构上都需要重新套用一遍，因为即便类别是共通的，静默故障本身是因模型而异的。

这条工作线的下一个技术里程碑是扩展奖励范围。音频质量、运动自然度和长上下文时序一致性都可以用现有模型来衡量 —— 只是还没有被集成进来。等它们进来之后，对奖励钻空子的约束就会收紧，面向特定垂直用例的微调也会更可靠。而跑这套扩展奖励回路所需的基础设施，如今已经以开源形式存在了。