feat(minimax-h3): replace the t2va Flow-GRPO recipe with the measured configuration

[celve]

Replaces the H3 t2va Flow-GRPO recipe with the configuration that was actually run, and deletes the sibling I first proposed adding.

Why replace rather than add

The values currently on main have never been run by anyone: 768x768, sde_indices: [0, 3, 6], samples_per_prompt: 4, learning_rate: 3e-4, num_updates_per_batch: 2. They arrived in 9e3e4b13, and the author of the branch that commit landed on states those four knobs match none of theirs and that they have no measurements behind them. The nearest thing anyone did run at 768 — a larger group and a different reward — produced four null arms.

So I cannot say the old configuration fails; I can say nobody has tried it, and that at 768 only 3 of 10 SDE steps fit in replay. Shipping it beside a measured recipe invites running the unrun one, which is why this replaces instead of adding a variant. The route back to 768 stays in the header.

	on main	this PR
canvas	768x768	256x384
reward	videopickscore + clap	imagebind + clap
SDE steps trained	3 of 10	all 10
group	4	16
learning rate	3e-4	1e-4
updates per batch	2	1

Two fields this drops

Upstream's file carries master_dtype: fp32 and cast_forward_inputs: false, and neither appears here, because neither was present in the runs below. fsdp_wrap casts params only when master_dtype is set, so its absence leaves the trainable LoRA adapters at bf16 rather than fp32 masters — a real difference, and I am not claiming bf16 is better, only that it is what was measured. Flipping it blind would recreate the problem this PR is about, so it is in the test plan.

The measurement

Two pods, 1x8 H20, same commit and recipe, differing only in seed. Pooled fit with per-seed intercepts and one shared slope, pre-registered before either seed reached the read point:

+0.00234 reward/step, t=+6.67, p<0.0001, 45 rollouts per seed, seeds agreeing at p=0.598. OLS and Newey-West HAC both p<0.0001. Levels move 0.205→0.288 and 0.173→0.313.

The canvas is what pays for the rest: 3966 packed rows against ~22k means every SDE step is replayable and the group can be 16 wide. All four knobs move together and no run separates them, so the result belongs to the bundle.

What this does not establish

• The rate. It decelerates within 1-45 (halves +0.00427 vs +0.00047, p=0.007 on the disjoint windows, and the plateau appears on each seed separately), then seed 42 resumes: rollouts 35-69 fit +0.00243. Non-monotonic, so do not extrapolate in either direction.
• That the video improves. See the warning below. This is the one I would push on hardest as a reviewer.
• Which knob matters. Canvas and reward are perfectly collinear across every run anyone has done. On 8x80GB the canvas cannot be varied alone, since ten replayed steps at 22k rows need >100 GB/rank — any 768 arm also changes the step count. The separable comparison is the reward at this canvas, and it is in the test plan.

⚠️ The reward has no prompt→video term

ImageBindSpec.mode defaults to "audio_video", and T2AVCompositeScorer builds inner specs with inner_spec_cls() while propagating only ("device", "batch_size", "frame_selection") — so mode is unreachable from a recipe and imagebind is exactly cos(audio_emb, video_emb). clap sees text but never a pixel. Nothing in this objective connects the prompt to the video.

That is not hypothetical. minimax_h3_t2va_nft.yaml on the same reward and canvas collapsed at rollout 100 to luma 2.01 / 2.14 of 255, 99.4% of pixels below 16, audio RMS down 9x and 28x — while imagebind rose 0.158 → 0.316. Not a clamp artifact: of nonzero pixels p90=8, p99=16, max=47, so a tensor merely shifted out of the writer's clamp(0, 1) window would have left a broad tail.

Scoring those clips back through ImageBindRewardScorer, both collapsed clips outscore both real ones (0.215 / 0.262 against 0.038 / 0.203), and constant black with silence scores 0.153 while constant gray with silence scores −0.0265. Direction established; magnitude not, at n=2 per condition.

#404 fixes the reachability. This recipe does not set mode — it cannot until #404 lands — so merging both still ships a reward with no prompt→video term. It also cannot simply be flipped afterwards: mode: "all" changes the reward, so the numbers above would stop describing the file. That needs its own run, and there is a note beside the weights saying so.

Test plan

• Every _target_ resolves against main, including imagebind in the reward registry; YAML parses
• All 10 SDE steps replay — cuda_alloc_gb 25.24, stable to ±0.02
• Advantages healthy — advantage_std 0.62–0.90, zero_std_group_ratio 0 throughout
• Host RAM flat at 154 GB of 2265; zero errors on either run
• Two-seed pooled verdict, seeds agreeing, OLS and HAC both p<0.0001
• Config values identical to what was measured, asserted by diffing the parsed YAML
• Frames through a run — the assumption everything else rests on. Neither component scores artifacts, and the sibling arm shows what that permits
• 256x384 + videopickscore 1.0 / clap 0.0 — the only clean de-confound available, and a mechanism test: videopickscore is a weak but real prompt→video anchor, so if anchoring is what separates flat from degenerate it should not collapse
• master_dtype: fp32 restored — plausibly right, but it changes the trainable master dtype and no run here had it
• eta 0.7 against 0.25 within Flow-GRPO — the only comparison that isolates eta; 0.25 has in-repo precedent in the hunyuan_video15 recipes

Also corrected

The old header claimed H3 "was released for a 768px SHORT EDGE only" and that 768x768 is "the FLOOR". No such floor exists — MiniMaxH3Geometry.resolve enforces multiple-of-32, aspect ratio, an area cap and the frame round-trip, and nothing else. num_frames: 124 is a real floor: legal counts are 17n+5 and the 5 s minimum at 24 fps makes 124 the smallest, so frames cannot be traded for row budget the way resolution can.

[Copilot]

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