[ci, tests] test: add MiniMax H3 T2VA FlowGRPO GPU smoke

[NancyFyong]

Summary

Add a self-contained TinyRandom MiniMax H3 FlowGRPO runner supporting targeted
T2VA, FL2VA, and Ref2VA one-step actor-update validation.

The registered four-GPU ci-e2e-diffusion test explicitly invokes
--task t2va, so CI exercises only T2VA and stays within its time budget.
FL2VA, Ref2VA, and --task all remain available for targeted manual validation
without adding CI runtime.

The runner exercises:

• vLLM-Omni reverse-SDE rollout with CPS;
• trajectory and rollout log-probability capture;
• reward and FlowGRPO advantage calculation;
• LoRA actor replay and update; and
• rollout video/JSONL export.

The format-v5 checkpoint builder creates self-contained FL2VA/ and Ref2VA/
rollout partitions plus the shared Diffusers actor transformer. It requires
neither a production MiniMax checkpoint nor external reward-model weights.

Tiny text interface

The builder reads Qwen3-VL dimensions from the pinned TinyRandom source config
instead of expanding the text interface to the production width. The generated
checkpoint uses a 32-wide, 4-attention-head, 2-KV-head, one-layer text model,
and both rollout and actor DiTs use text_dim=32. This reduces the generated
checkpoint from about 24 MB to 2.7 MB.

Pinned vLLM-Omni currently validates MiniMax H3 text output against a fixed
production width of 5120. The runner therefore injects a test-local
sitecustomize import hook into only its trainer and inherited Ray worker
processes. The hook reads the expected width from the generated checkpoint
config and changes that validation constant at module load. It does not modify
or install files into vLLM-Omni. The encoder's attention shapes already come
from the Qwen3-VL config.

Compatibility and dependencies

This work relies on merged MiniMax H3 support, including:

• [diffusion, rollout, reward, recipe] feat: add MiniMax H3 FlowGRPO support on GPU and Ascend NPU #368: MiniMax H3 T2VA FlowGRPO;
• [diffusion, rollout, tests, recipe] feat: add MiniMax H3 FL2VA FlowGRPO #448/[diffusion, rollout, trainer, data, cfg, recipe, tests] feat: add MiniMax H3 Ref2VA FlowGRPO #485: FL2VA and Ref2VA FlowGRPO support;
• [diffusion, tests] fix: track fused MiniMax H3 weights #477: fused QKV/GEGLU weight-load bookkeeping; and
• [diffusion] fix: restore nested condition rows in FlowGRPO actor replay #534: nested condition-row restoration in FlowGRPO actor replay.

The PR contains only TinyRandom checkpoint/data/reward helpers, the multi-task
manual runner, and T2VA-only GPU-smoke registration. It does not duplicate
production adapter code. An open-PR search found no duplicate MiniMax H3
TinyRandom FlowGRPO GPU smoke.

The tiny source snapshot is pinned to
9018dbdcdb02a427905537035e8431c4a738d7c0 and fetched from the canonical
Hugging Face endpoint, independently of the workflow-wide mirror setting.

CI time budget

The registered command remains T2VA-only:

python3 tests/special_e2e/run_flowgrpo_minimax_h3_tiny.py --task t2va

A prior GitHub TinyRandom T2VA run, including first-time checkpoint
construction, took about 158 seconds. FL2VA and Ref2VA are intentionally not
added to the registered CI command.

Tests

TORCH_COMPILE_DISABLE=1 TORCHINDUCTOR_DISABLE=1 \
  PYTHONPATH=$PWD python -m pytest \
  tests/pipelines/test_minimax_h3_flow_grpo_on_cpu.py \
  tests/pipelines/test_minimax_h3_ref2va_flow_grpo_on_cpu.py -q
# 29 passed

pre-commit run --files \
  tests/gpu_smoke/select_gpu_smoke_groups.py \
  tests/special_e2e/build_minimax_h3_tiny_random.py \
  tests/special_e2e/run_flowgrpo_minimax_h3_tiny.py \
  tests/special_e2e/minimax_h3_tiny_patch/sitecustomize.py
# Passed

Fresh four-GPU manual E2E validation with --task all, one training step per
task:

• T2VA: training/global_step=1, 16 MP4s and 16 JSONL rows;
• FL2VA: training/global_step=1, 16 MP4s and 16 JSONL rows;
• Ref2VA: training/global_step=1, 4 MP4s and 4 JSONL rows;
• final result: MiniMax-H3 tiny FlowGRPO T2VA + FL2VA + REF2VA smoke PASSED.

Additional validation:

• offline reproducible format-v5 checkpoint builds with 47 matching file hashes;
• native vLLM-Omni text encoder load and (3, 32) output;
• Diffusers actor load with text_dim=32;
• native video/audio VAE decode contracts;
• consolidated T2VA/FL2VA/Ref2VA dummy-data contracts;
• all special-E2E helper paths route only to ci-e2e-diffusion;
• shell syntax, Python compilation, and git diff --check passed.

The current head still requires the normal labeled GPU CI run.

AI assistance and review

AI assistance (pi coding agent) was used for this change.

The human submitter is responsible for reviewing every changed line before
merge; final review remains pending confirmation.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[NancyFyong]

@wtomin

While validating the TinyRandom builder, I confirmed that this is required by the MiniMax H3 integration in the currently pinned vLLM-Omni commit (444485650b19b792403b12976f1b0eeb2ac1451c), rather than by generic Qwen3-VL configuration:

• encoder.py hard-codes the selected language-model layer to 50 and the hidden dimension to 5120.
• The same encoder rejects any output whose shape is not [sequence_length, 5120].
• pipeline_minimax_h3.py assumes 64 attention heads and 8 KV heads when validating text-encoder TP size.
• The H3 DiT architecture defaults text_dim to 5120, and its conditioning projection consumes arch.text_dim in minimax_h3_transformer.py. Although that field can be overridden by component config, the encoder's explicit shape check makes 5120 the effective end-to-end contract.

The encoder's actual layer construction remains config-driven and uses:

self.num_layers = min(config.num_hidden_layers, selected_layer)

Therefore this PR preserves the required interface (hidden_size=5120, 64/8 heads, and DiT text_dim=5120) while minimizing the expensive dimensions: one decoder layer, a 64-wide MLP, a 512-token vocabulary, and an 8-wide attention head. This is why the checkpoint can remain small while being accepted by vLLM-Omni without carrying a compatibility patch to vLLM-Omni itself.

[NancyFyong]

Hi,@wtomin , can you check this pr when you have time? Thank you!

[wtomin]

Nice job! It takes much less time now.