引言

MiniMax-H3 是当前开源社区中最受关注的音视频生成模型之一。它是一个通用的多模态生成模型，接收文本、图像、视频、音频等多种输入，直接输出带原生立体声音轨的视频，支持最长 15 秒、最高 2K 分辨率、24 FPS、32 kHz 立体声。

在 Artificial Analysis 的 Text-to-Video Arena 榜单上，MiniMax-H3 以 Elo 1227 位列前三，是榜单前列中唯一开放权重的模型；在 2K 分辨率下，每秒生成成本不到主流模型的三分之一。

MiniMax-H3 权重已经在 Hugging Face 开源了，用 RL 后训练做垂类微调也顺理成章——比如让广告视频更贴品牌文案、游戏 CG 音画更同步、特定风格出得更稳。

不过音视频联合生成模型做 RL 后训练，真正麻烦的不是挑算法或设计 reward，而是怎么确认整条链路确实跑对了。脚本跑得起来、loss 有数、reward 曲线在动，这些都说明不了训练方向没问题。联合音视频场景里，随便哪一环悄悄出了问题，训练曲线照样能稳稳往上走——这才是最坑的地方。

本文记录我们基于 VeRL-Omni，使用 DiffusionNFT 算法跑通 MiniMax-H3 的 T2VA（text-to-audio-video）与 FL2VA (first/last-frame-to-audio-video) 在线 RL 训练闭环的实践：vLLM-Omni 负责 rollout 生成音视频，Diffusers / FSDP2 负责 actor 训练，VeRL-Omni 将数据、reward、NFT loss、LoRA old-policy 同步串联为完整链路。

本文不追求证明 RL 给 H3 带来了多大提升，而是验证这类联合音视频模型已经能在 VeRL-Omni 中快速、稳定地跑通一条可验证的完整链路。路径打通之后，垂类效果是时间问题。

一、MiniMax-H3 与 DiffusionNFT

1.1 MiniMax-H3：联合音视频生成

MiniMax-H3 生成的不是单独的视频张量，而是一组同时包含 video latent 和 audio latent 的联合结果，最终一起解码为带音轨的视频。这一特性决定了 RL 训练的两条基本约束：

• reward 必须同时评估画面和声音，不能只看其中一个模态；
• 训练框架需要保证 audio 与 video 在 rollout、reward、数据落盘、训练 batch 之间不发生任何静默丢失。

H3 的 DiT 主干还有几处与通用约定不同的设计：CFG-distilled（推理时无需 negative prompt）、timestep 使用 data fraction（数据占比，即从数据到噪声的插值比例）而非通用 flow-matching 的 sigma、velocity 符号方向与通用约定相反。这些细节在接入训练框架时会成为隐藏的坑，后文会具体展开。

1.2 DiffusionNFT 算法原理

DiffusionNFT（Diffusion Negative-aware FineTuning）的论文全称是 DiffusionNFT: Online Diffusion Reinforcement with Forward Process。

它是一种面向 diffusion / flow-matching 模型的在线 RL 方法，不在反向采样链上估计 policy gradient，而是把 reward 信号注入前向扩散过程的监督式 flow-matching 目标。

rollout 端只保留最终生成的 clean latent、prompt embedding 与训练 timestep；训练端重新执行前向加噪，将 reward 转换为 reward probability，使高 reward 样本更接近正向目标，低 reward 样本受到反向约束。

第一阶段优先接入 DiffusionNFT，是因为接入 H3 时最需要验证三件基础事实：

• vLLM-Omni rollout 是否真的同时生成了 video 与 audio；
• CLAP / ImageBind reward 是否真的接收到完整音视频；
• actor 更新后的 LoRA 是否真的同步回下一轮 rollout。

DiffusionNFT 无需在 rollout 端记录每一步 transition 的 log-prob，链路更短，这三件事因此可以逐一验证。随着 FL2VA 接入，T2VA 和 FL2VA 已共享 rollout、reward、actor 和 LoRA 同步的主干；二者的差异集中在条件帧输入与训练 loss 的掩码范围。

下图将两条任务路径放到同一张图中：上半部分是 T2VA / FL2VA 的条件输入与 H3 rollout，中间是音画 reward 与训练数据合同，下半部分是 DiffusionNFT 的前向过程优化及 old-policy 刷新。

读图时需要区分两条数据流：用于评分的解码视频/音频流向 CLAP 与 ImageBind；用于 actor 更新的 clean latents、timestep 与条件元数据流向 FSDP2。

图中展示的是系统分层与主数据流。实现上有两处 recipe 细节以正文和启动脚本为准：当前 DiffusionNFT 默认使用全局标准差 reward 归一化；rollout policy 的更新不是无条件硬拷贝，而是按延迟线性衰减的调度、每两个训练步刷新一次。

二、实验设计与配置

2.1 实验目标与范围

本文的实验不追求 benchmark SOTA 的横向比较。第一阶段更基础，也更容易被忽略：我们要确认 H3 的联合音视频数据、reward 信号和策略更新在同一条在线 RL 链路中没有发生静默错配。

因此，实验按四个问题组织：

1、 联合输出是否完整？ rollout 返回的 video 和 audio 是否同时进入落盘、reward 和训练数据合同；

2、 reward 是否真的约束音画？ CLAP 是否看到文本与音频，ImageBind 是否看到同一条样本的音频与视频；

3、 更新是否传回采样策略？ actor 侧 LoRA 更新后，旧的 rollout policy 是否按既定调度刷新；

4、 条件帧是否被正确处理？ FL2VA 中输入关键帧必须保持为条件，而不是被 DiffusionNFT 目标重新优化。

这也决定了结果的解读方式：reward 曲线、子 reward、固定样本视频和训练日志需要一起看。任何单一指标上升都不足以证明生成质量整体提升。

2.2 两类任务：T2VA 与 FL2VA

T2VA 用于检查文本、运动和音画语义对齐。FL2VA 则进一步测试模型能否在关键帧约束下补全中间运动与音轨，适合角色一致性、镜头衔接和广告素材延展等任务。

FL2VA rollout 使用 vLLM-Omni 的官方首/尾帧协议。**条件图像对应的 latent 保持固定，DiffusionNFT 前向过程目标仅施加在生成的视频与音频 latent 上。**这一点直接决定模型是在学习补全，还是在错误地改写给定关键帧。

2.3 数据集与条件图

T2VA 的数据合同是 prompt-only parquet。转换器接受两种输入：每行一个 prompt 的纯文本文件，或每条记录带 prompt 字段的 JSONL；输出训练集与测试集两份 parquet：

python3 examples/diffusionnft_trainer/minimax_h3/prepare_t2va_data.py 
  --input_dir /path/to/raw_prompts 
  --output_dir /path/to/h3_t2va_data

FL2VA 使用 DanceGRPO 发布的 ConsisID prompt 列表构造条件图数据。该列表包含 27,815 条英文视频描述；每条 prompt 用固定的 seed 加索引生成一张 FLUX.1-dev 参考图，再由同一索引配对 prompt 和图像。这不是为了增加复杂度，而是为了保证中断恢复、训练测试划分和条件帧都可复现。

# 1. 固定 seed 生成 FLUX.1-dev 首帧；已存在的图片会被跳过
torchrun --nproc_per_node=8 examples/diffusionnft_trainer/minimax_h3/gen_flux_images.py 
  --prompt_file dancegrpo_consist-id.txt 
  --model_path /path/to/FLUX.1-dev 
  --output_dir data/flux_images 
  --height 400 --width 640

# 2. 按 seed 42 配对图像并划分 train / test JSONL
python3 examples/diffusionnft_trainer/minimax_h3/build_fl2va_jsonl.py 
  --prompt_file dancegrpo_consist-id.txt 
  --image_dir data/flux_images/images 
  --output_dir data/flux_images 
  --test_size 128 --seed 42

# 3. 写出带条件图像 bytes 的 parquet
python3 examples/diffusionnft_trainer/minimax_h3/prepare_fl2va_data.py 
  --input_dir data/flux_images 
  --output_dir data/h3_fl2va 
  --frame_mode first

参考数据使用 FLUX.1-dev 在分辨率 400×640、推理 30 步、guidance 3.5 下生成首帧；seed-42 划分后得到 27,687 条训练样本与 128 条测试样本。rollout pipeline 在运行时以 LANCZOS 将条件图缩放至采样尺寸，因此可直接复用这些条件图。

2.4 Reward 与训练信号：为什么需要两项 reward

Reward 采用多奖励加权，由两项组成：

• CLAP（laion/larger_clap_general）：评估文本与生成音频的语义对齐，回答"声音是否是 prompt 描述的声音"；
• ImageBind audio-video（imagebind_huge）：评估音频与视频是否属于同一场景，回答"这段声音是否属于这段画面"。

只用其中一项都会给模型留下明显的优化空隙：只看 CLAP，画面不受约束；只看 ImageBind，模型可能生成音画一致但与文本无关的内容。两项联合也不能完整评估生成质量，只覆盖当前训练最需要守住的文本-音频与音频-视频关系。

reward 在 DiffusionNFT 中会先被归一化并映射为 reward probability。当前 VeRL-Omni 默认采用全局 reward 标准差归一化，而不是严格的单 prompt 组间归一化。

2.5 可复现训练配置

下表列出当前主分支 recipe 的关键默认值。这些参数已经过端到端验证，可直接作为复现实验的起点。

2.6 评估指标与检查项

训练过程记录四类信息：

• 优化统计量：loss、梯度范数（grad norm）、reward probability、reference KL（ref KL）；
• reward 分解：CLAP、ImageBind 与 weighted reward；
• 固定样本对比：同一 prompt、同一 seed、同一推理配置下，对比 base model 与更新后策略；
• 系统合同检查：audio 是否以 32 kHz 到达 CLAP / ImageBind，导出的 mp4 是否带 AAC 音轨，LoRA 是否命中 rollout 中实际执行的层。

FL2VA 还需要检查条件帧保持情况：首帧身份是否保留、prompt 场景是否成立、完整视频内的时间一致性是否达标。当前 FL2VA 集成验证在 8 GPUs、FSDP2 actor、TP=4 下完成：验证 checkpoint 的 core reward mean 为 0.41（CLAP 0.16，ImageBind 0.25），随后 3+ 个训练 steps 中 reward mean 从 0.41 升至 0.51，grad norm 保持在 0.06–0.12。

三、训练流程

H3 能够较为顺利地接入 VeRL-Omni，得益于仓库中几个核心模块的解耦设计：

• vLLM-Omni 负责生成。 保留 H3 原生 denoise loop，rollout 仍沿用模型自身的生成逻辑，同时将训练所需的 clean latent、prompt embedding、timestep 与 latent metadata 一并返回。这样做的好处是训练侧无需重新复刻 H3 的采样过程，避免训推不一致。
• VeRL-Omni 负责训练编排。 rollout 返回的样本交给 reward manager，取得 CLAP / ImageBind 分数后，由 DiffusionNFT 将 group reward 转换为 reward probability；actor 训练完成后，LoRA 权重同步回 old rollout policy。
• H3 adapter 负责模型专属约定。 包括 packed latent 中 video 与 audio 段的划分；timestep 从 sigma 到 H3 DiT 格式的转换；velocity 符号如何转回通用 flow-matching loss；Diffusers 的 LoRA 命名如何映射到 vLLM-Omni 的 fused DiT。

这样划分的好处是：通用训练循环无需了解 H3 的每一处细节，H3 的特殊逻辑也不散落在 trainer、reward、rollout 各处。模型的特殊性集中在 pipeline adapter 中，reward manager 负责多 reward，vLLM-Omni 负责高吞吐 rollout，VeRL-Omni 负责训练与同步。

3.1 T2VA 数据准备

启动前先将 prompt 转为 parquet：

python3 examples/diffusionnft_trainer/minimax_h3/prepare_t2va_data.py 
  --input_dir /path/to/raw_prompts 
  --output_dir /path/to/h3_t2va_data

3.2 启动 T2VA 训练

export MODEL_PATH=/path/to/MiniMax-H3
export DATA_DIR=/path/to/h3_t2va_data

NUM_GPUS=8 ROLLOUT_TP=2 ROLLOUT_N=16 INFER_STEPS=10 
TOTAL_TRAINING_STEPS=1000 OUTPUT_DIR=/path/to/output 
bash examples/diffusionnft_trainer/minimax_h3/run_minimax_h3_t2va_lora.sh

MODEL_PATH 指向本地 MiniMax-H3 根目录，其中需包含 rollout 使用的 FL2VA/（vLLM-Omni 检查点目录，T2VA 与 FL2VA 共用）和训练使用的 transformer/。默认训练配置为 256x384、121 frames；validation 使用 512x768、121 frames、40 steps。ROLLOUT_N 默认为 16，用于对同一条 prompt 采集多条结果，构造组内 reward 差异。

3.3 启动 FL2VA 训练

FL2VA 使用独立的 image-conditioned rollout adapter 和 agent loop，不能直接套用 T2VA 脚本、只换数据目录。完成 2.3 节的数据转换后，确认 DATA_DIR 下已有 train.parquet 和 test.parquet，并让 MODEL_PATH 指向同时包含 FL2VA/ 与 transformer/ 的 MiniMax-H3 根目录。

首帧条件训练的最短启动命令如下：

export MODEL_PATH=/path/to/MiniMax-H3
export DATA_DIR=/path/to/h3_fl2va

FRAME_INDICES='[0]' 
NUM_GPUS=8 ROLLOUT_TP=4 ROLLOUT_N=16 INFER_STEPS=10 
TOTAL_TRAINING_STEPS=1000 OUTPUT_DIR=/path/to/output 
bash examples/diffusionnft_trainer/minimax_h3/run_minimax_h3_fl2va_lora.sh

FRAME_INDICES 必须与数据转换时的 frame_mode 对应：首帧数据使用 '[0]'，尾帧数据使用 '[-1]'，首尾帧数据使用 '[0,-1]'。更换条件模式时只需重新转换 parquet 并传入对应的 FRAME_INDICES：

# 首尾帧条件：prepare_fl2va_data.py --frame_mode first_last
FRAME_INDICES='[0,-1]' 
MODEL_PATH=/path/to/MiniMax-H3 DATA_DIR=/path/to/h3_fl2va_first_last 
bash examples/diffusionnft_trainer/minimax_h3/run_minimax_h3_fl2va_lora.sh

FL2VA 训练采样使用 288x448，验证使用 576x928；采样边长必须是 32 的倍数，否则 H3 pipeline 会静默向下取整。vLLM-Omni 的视频时长约束为 4–15 秒、24 FPS，launcher 的 NUM_FRAMES=96 会被对齐到合法的 17n+5 边界。训练 rollout 默认 10 个扩散步，validation 使用 40 个；2–4 步仅适合验证数据与接口契约，不能作为判断训练质量的依据。

与 T2VA 一样，FL2VA 使用 rank-64 LoRA、CLAP + ImageBind audio-video 多 reward；验证时除了查看 reward，还需检查首帧身份是否保持、prompt 场景是否成立，以及 107 帧内的时间一致性。

3.4 关键配置

有两处配置值得展开说明。第一处，rollout 端需要将 NFT 训练所需的状态一并返回：

rl = {
    "latents_clean": pack_video_audio_rows(video_rows, audio_rows),
    "train_timesteps": train_timesteps,
    "latent_meta": latent_meta,
}

T2VA 中，latents_clean 是视频与音频 latent 拼接后的结果，latent_meta 负责在训练端指导拆分。FL2VA 中，这一合同还携带条件帧的分段信息与 frame_indices：actor 读取这些元数据后固定条件帧对应的 latent，仅在非条件的视频与音频 latent 上计算 DiffusionNFT 目标。

第二处，启动脚本中的核心参数：

actor_rollout_ref.model.algorithm=diffusion_nft 
actor_rollout_ref.model.model_type=diffusion_nft_model 
algorithm.trainer_type=direct_preference 
algorithm.sample_source=online 
algorithm.old_policy_decay_schedule=delayed_linear_to_0_999 
algorithm.old_policy_update_interval=2 
actor_rollout_ref.model.policy_state_adapters='["default","old"]' 
actor_rollout_ref.rollout.name=vllm_omni 
actor_rollout_ref.rollout.agent.default_agent_loop=minimax_h3_diffusion_single_turn_agent 
actor_rollout_ref.model.lora_rank=64 
actor_rollout_ref.model.lora_alpha=128 
actor_rollout_ref.model.target_modules="['to_q','to_k','to_v','to_out.0','ff.net.0.proj','ff.net.2']"

最后一行至关重要：H3 不能直接使用 all-linear 作为 target modules。 并非所有训练端 LoRA 都能同步到 rollout 端（例如 fused QKV 就必须显式映射）。adapter 会提前校验 target modules，配置错误时直接报错中止，避免静默跑飞。

四、实验结果

下面的曲线来自 T2VA 在线训练 run。首先说明"优化信号和系统路径是否正常"，而非"模型已在所有任务上优于 base model"。FL2VA 的结果单独作为条件帧链路的集成验证报告。

4.1 训练 Reward 曲线

训练端的平均 reward 从约 0.27 稳步上升至 0.4 以上，说明在当前 prompt 分布下，CLAP + ImageBind 的联合信号可以形成可学习的组内偏好。这个指标只能说明 reward model 偏好的方向被优化，不能单独解释为画面美学或长程一致性提升。

actor 动态需要与 reward 同时观察。尤其是梯度范数（grad norm）、reward probability 和 reference KL（ref KL）：如果 reward 在上升，但梯度范数持续异常、reward probability 饱和，或 ref KL 突然失效，曲线仍可能收敛到错误目标。

4.2 验证 Reward 分解

验证集上分别记录 CLAP、ImageBind 与 weighted reward。**只有两个子 reward 的变化方向与固定样本视频一致时，combined reward 才有解释价值。**例如，combined reward 的提升若只来自 CLAP，可能意味着声音更贴近文本，但不能证明音画关系或视觉质量同时改善。

4.3 训练耗时分析

端到端耗时按 rollout、reward、actor update 和 checkpoint 分解。对于联合音视频训练，reward 阶段同时承担音频解码、视频处理以及两个 scorer 的执行；它和 rollout 一样可能成为吞吐瓶颈。因此，优化训练效率时不能只看 actor 的 GPU utilization。

4.4 FL2VA 集成验证：关键帧条件没有在训练中丢失

FL2VA run 的首要目的是验证条件帧链路。8-GPU、FSDP2 actor、TP=4 的端到端 run 中，恢复 checkpoint 后的 validation core reward mean 为 0.41（CLAP 0.16、ImageBind 0.25）；

随后 3+ 个训练 steps 的 reward mean 从 0.41 升至 0.51，grad norm 维持在 0.06–0.12。验证生成中，首帧身份保持、prompt 场景与 107 帧时间一致性均完成了人工检查。

需要说明的是，这是一项集成验证，证明 FL2VA 的数据、条件帧、reward、actor 和 LoRA refresh 可以共同工作；它不是一个覆盖多数据集的条件生成性能 benchmark。

4.5 视频对比：Base Model vs. DiffusionNFT（T2VA）

reward 曲线只能反映数值层面的整体趋势，最终仍需回到生成结果本身。我们从测试集中挑选四条 prompt，在相同 seed、相同推理配置下，分别用 MiniMax-H3 base model 与 DiffusionNFT 微调后的模型生成音视频输出。观察维度集中在三点：

• motion consistency（运动一致性）：物体轨迹是否连贯，是否存在抖动或断裂；
• audio-visual alignment（音画对齐）：音效发生时机与画面动作是否同步；
• 视觉细节稳定性：材质、光照、边缘在整段时长内是否保持连贯。

左列为 base model，右列为 DiffusionNFT 微调后的模型；prompt 列保留原始英文，未经改写。

4.6 视频对比：FL2VA 首帧条件下 Base vs. DiffusionNFT

T2VA 只约束文本与音视频的语义关系，FL2VA 还要求模型服从给定的首帧图像——因此对比的重点不再只是"画面好不好看"，而是在首帧被固定的前提下，模型能否把后续运动与音轨补全得更连贯。

我们从测试集中取两条 prompt，用同一张 FLUX.1-dev 首帧作为条件，在相同 seed、相同推理配置下分别用 base model 与 FL2VA DiffusionNFT 微调后的模型续写音视频。

• 首帧一致性：生成结果是否忠实衔接给定条件图，而不是重绘一张新画面；
• motion consistency（运动一致性）：从首帧展开的动作是否连贯，是否存在抖动或漂移；
• audio-visual alignment（音画对齐）：滴落、水声等音效的发生时机是否与画面动作同步。

第二列为条件首帧，中间两列分别为 base model 与 FL2VA DiffusionNFT 微调后的输出；prompt 保留原始英文并附中文，未经改写。

ID	条件首帧	Prompt	MiniMax H3 (base)	MiniMax H3 + FL2VA DiffusionNFT
23		Shows a close-up of a woman holding a red bottle with a blue substance dripping from it. 一名女子手持红瓶子的特写，蓝色液体正从瓶中滴落。	fl2va-23-bottle-base.mp4	fl2va-23-bottle-DiffusionNFT.mp4
56		Shows a man wearing a white shirt, brown apron, and a white hat standing in a pool filled with water.一名穿白衬衫、棕色围裙、戴白帽的男子站在装满水的池子里。	fl2va-56-pool-base.mp4	fl2va-56-pool-DiffusionNFT.mp4

需要说明的是，这里展示的是 FL2VA 集成验证阶段的定性对比，样本量有限，它说明条件帧链路与后训练更新确实在生成结果上产生了可见差异，但不能作为条件生成质量的完整 benchmark。

五、经验总结

前面的章节按"设计—上手—结果"的顺序展开，但实际耗时最多的是两类不写进流程也能"跑起来"的问题：接入 H3 时不报错的静默错误，以及强 base model 在 RL 下暴露的 reward hacking 倾向。本节集中讨论这两类问题。

5.1 静默错误与 reward hacking

接入 H3 的过程中，最危险的错误不是导致程序报错中断的错误，而是"能跑起来但跑错了"的错误——loss 有数值、曲线在动，但梯度方向反向，或者更新的权重根本没有生效。我们在以下环节逐一做了排查：

其中三条经验尤其重要。

第一，timestep 约定错误不会直接报错。 H3 的扩散时间步定义与通用 flow-matching 不同，训练端若直接按通用约定传入，loss 仍能算出数值，但梯度方向可能相反。这类错误不会报错，只能逐点核对公式与调度器约定。

第二，LoRA 注册成功不等于 rollout 中生效。 训练端看到的是拆开的注意力投影，vLLM-Omni 里的 H3 则把它们融合成了一块。缺少映射时，adapter 能正常注册，实际命中的层数却是 0——下一轮 rollout 仍是 base model 的行为。

第三，audio 最容易在链路中段静默丢失。 许多 diffusion / video 训练框架默认只处理画面，而 H3 输出的是音视频联合结果，需要一路拆包、透传、评分、导出。只有当 audio 真正到达 CLAP / ImageBind、导出的视频也挂上音轨之后，reward 链路才算真正闭合。

链路跑通之后，下一个问题来自模型本身。

本次实验还发现，MiniMax-H3 本身非常适合作为后训练的 base model。它的音视频联合生成能力已经足够强，初始 rollout 质量已经可用；同时模型对 LoRA 更新也较为敏感，短步数训练即可观察到 reward 与生成分布的变化。

这两点对 RL 都至关重要——base model 过弱时，reward 大部分时间只在惩罚无效样本；base model 更新不敏感时，训练更新又难以传导至下一轮 rollout。

这也意味着 H3 更容易出现 reward hacking。 在音视频任务中，reward 通常只能覆盖部分维度——文本与音频、音频与画面的对齐——而画面美学、动作自然性、音频质量、语义细节以及长时间一致性尚未被纳入。

模型一旦摸到某个评分模型的偏好，就可能优先优化容易得分的维度，而非整体生成质量。

因此不能仅凭加权后的总 reward 上升就下结论：必须把 CLAP、ImageBind 等子 reward 拆开单独观察，再配合固定 prompt 的视频对比与人工审查。

对 H3 而言，reward 设计的重点不是"堆更多评分模型"，而是约束一个已经很强的模型不去走捷径。

5.2 总结

回到开头的问题：给 H3 这样的联合音视频模型做 RL 后训练，最难的是确认每一环都跑对了。本次工作回答了四个问题：

1、 RL 训练信号从哪里来？ DiffusionNFT（Online Diffusion Reinforcement with Forward Process）将联合音视频生成的偏好优化，转化为基于最终 clean latent 与 reward probability 的前向过程约束，避免在 rollout 端复现整条去噪轨迹。

2、 FL2VA 如何纳入同一套训练主干？ 通过首/尾帧条件协议固定条件帧对应的 latent，只对生成的视频与音频 latent 计算 DiffusionNFT 目标；T2VA 和 FL2VA 因而可共享 reward、actor 与 LoRA 同步基础设施。

3、 接入时哪些错误最危险？ 不是直接报错，而是不会报错的静默错误——timestep 约定反向、LoRA 注册成功却命中 0 层、audio 在链路中段悄悄丢失。

4、 如何确认训练方向正确？ train / eval reward 之外，将 CLAP、ImageBind 子 reward 拆开单独观察，配合固定样本对比，警惕 reward hacking。

总之，对于MiniMax-H3 的RL 后训练，应该先把 timestep 换算、LoRA 映射、audio 透传这些容易出错的环节逐一验证清楚，再谈效果调优。链路跑通后，针对广告视频、游戏 CG 等垂类场景做针对性微调，效果会更可靠。

MiniMax-H3 DiffusionNFT 训练实践已全部开源，可通过文末参考入口复现。

参考入口

• DiffusionNFT 论文：Online Diffusion Reinforcement with Forward Process
• PR #383：MiniMax H3 DiffusionNFT T2VA training
• PR #401：MiniMax H3 FL2VA DiffusionNFT
• MiniMax-H3 T2VA/FL2VA recipe
• H3 T2VA launch script
• H3 FL2VA launch script
• MiniMax-H3 Model