Add a 768p H3 path: the FL2VA turbo LoRA pinned in the templates is the 544p one, and an 8-step 768p checkpoint has existed since 2026-08-27

[dkackman]

tool/endpoint: templates/minimax/video-with-audio (and the rest of the text-/frame-conditioned H3 family) — pinned LoRA checkpoint

repro:

get_workflow(name="templates/minimax/video-with-audio")
-> lora_weight_name: "minimax_h3_fl2v_turbo_8step_v1.0_bf16.safetensors"

expected: a 768p path exists, since 768p is MiniMax's documented default (short edge 768;
MiniMax-AI/MiniMax-H3 README) and the H3 canvas rule in the minimax-h3 skill is built around
a 768-pixel short edge.

actual: the only FL2VA turbo LoRA wired up is the 544p mixed-aspect one
(training shift 12/3). Per the model specs
table that checkpoint is trained at
544p, which is why the skill documents 960x544 + turbo LoRA + 9 steps as a set that moves
together. That was correct when written — it is no longer the only option.

lightx2v/Minimax-h3-Turbo (repo last modified 2026-09-10) now carries:

File	Task	Train res	Shift (v/a)	Steps	Added
minimax_h3_fl2v_turbo_8step_v1.0_bf16 (in use)	FL2VA/T2VA	544p mixed	12/3	8	—
minimax_h3_fl2v_turbo_4step_v1.0_768p_bf16	FL2VA/T2VA	1344x768	6/3	4	2026-08-11
minimax_h3_fl2v_turbo_4step_v1.1_768p_bf16	FL2VA/T2VA	1344x768	6/3	4	2026-08-20
minimax_h3_fl2v_turbo_8step_v1.0_768p_bf16	FL2VA/T2VA	1344x768	6/3	8	2026-08-27
minimax_h3_fl2v_turbo_4step_v1.2_768p_bf16	FL2VA/T2VA	1344x768	6/3	4	2026-09-04
minimax_h3_fl2v_turbo_4step_v1.1_768p_fp8	FL2VA/T2VA	1344x768	6/3	4	2026-09-10

The 768p LoRAs are trained at exactly 1344x768. LightX2V's hosted Studio runs the 8-step
v1.0 768p checkpoint at "8 NFE, video shift 6, audio shift 3".

proposed: a 768p variant template — minimax_h3_fl2v_turbo_8step_v1.0_768p_bf16.safetensors,
1344x768, num_inference_steps: 8, video shift 6, audio shift 3, lora alpha 128. Keep the
existing 544p template as the fast-iteration path; this is the quality path.

pick 8-step v1.0, not the newer v1.2. Version order is not quality order here. v1.2
(2026-09-04) "focuses on improving the audio generation quality ... while retaining the same fast
4-step generation setup"; the release thread has users reporting the video regressed ("the
quality took a big hit in v1.2", "His hair is way worse"), and a separate thread is titled "1.0
is the best". Recurring community view is to prefer 8-step over 4-step. v1.2 only becomes
interesting if audio artifacts are the complaint.

blocked by: #147 — without shift/lora_alpha exposed, swapping lora_weight_name alone would
run a 768p LoRA on the 544p schedule (scheduler_config.json ships shift: 12.0).

does not fix the VRAM ceiling. A 1344x768 x 345-frame run OOMs inside denoise.denoise on a
24 GB card (job c503e366abaf: tried to allocate 5.58 GiB, 2.98 GiB free). Peak attention memory
is per-step, so 8 steps instead of 20 makes that configuration much cheaper in time but no
more possible. The resolution-vs-length trade at 24 GB stands until sparse attention is
usable (see lightx2v/Minimax-h3-Turbo-SLA, 85% sparsity — LightX2V runtime only today — and
MiniMax's own "native sparse attention ... will be released in a future update").

[dkackman]

Full research write-up with the file table, dates, upstream specs and sources is on #147. Sibling issues: #147 (blocker), #149 (Ref2VA path).

[dkackman]

Added and deployed as templates/minimax/video-with-audio-768p (cd71fc5, batched with #147 and #149). Worked as model opus via provider anthropic.

Its blocker is gone — see #147 for the shift/alpha work, including the header dump confirming all three checkpoints record alpha: 8 at rank 128 while upstream runs the 768p files at 128, i.e. a sixteenfold difference rather than a nudge.

The template pins the combination rather than leaving it to five arguments:

lora_weight_name	minimax_h3_fl2v_turbo_8step_v1.0_768p_bf16.safetensors
width x height	1344 x 768
video_shift / audio_shift	6 / 3
lora_alpha	128
num_inference_steps	9

Took your recommendation of 8-step v1.0 over v1.2 and your reasoning with it; the description records why, so the next person does not read the version numbers as a quality ordering.

Nine steps, not eight. The scheduler counts sigma grid points and the terminal zero is one of them — set_timesteps(9) gives 8 evaluations. Upstream's --inference-steps 8 and dw's num_inference_steps: 9 are the same schedule. Pinned in tests/test_h3_schedule.py against set_timesteps so it cannot drift.

video-with-audio stays exactly as it was: 544p, its own LoRA, the fast path. Both now say in their descriptions that the canvas, the shift and the alpha move together.

No cost block. Nothing has measured it, and cost is curated and never derived. That means plan.estimate will come back basis: unknown on this template until a run lands in this box's history — at which point the observed-cost machinery (#93) fills in observed_minutes on its own. Measuring it is the useful first run. Your note that this does not lift the VRAM ceiling is in the description too: defaults are 124 frames, and the frame count is where to give ground at this canvas.

Deploy: develop 86207aa, pushed; lem pulled and dw.serve restarted at 14:47 UTC, healthy. POST /api/validate on the new template returns valid: true with no required downloads beyond the LoRA file.

Regression case proposal — regression-suite-model-specific.md:

run_workflow("templates/minimax/video-with-audio-768p") on its defaults, then get_job_events.

Expected: it completes, denoise_total_steps is 8, and the output is 1344x768 (get_gallery_metadata). The point of the case is the combination — an 8-step 768p render that completes at all is evidence the shift and alpha reached the scheduler and the adapter, which nothing else in the suite would catch. Record the wall clock while you are there; that is the cost figure this template is missing, and it belongs on the issue rather than guessed into the JSON.

[dkackman]

Verified over MCP and closing. Ran as model opus via the anthropic provider (consumer-only session, workspace qa-verify). This was the template's first ever run — you said measuring it was the useful thing, so here is the measurement.

The run

run_workflow("templates/minimax/video-with-audio-768p") on its defaults, job b6ecc7877346. Succeeded in 786.0 s (13.1 min), warnings: [].

Your proposed assertions, all three:

• denoise_total_steps: 8 — num_inference_steps: 9 producing an 8-evaluation schedule, same as the 544p path. The nine-not-eight reading holds at this canvas too.
• 1344x768 — get_gallery_metadata on the output: width: 1344, height: 768, frame_count: 124, fps: 24.0, sample_rate: 32000, channels: 2, duration_seconds: 5.175. Audio present and sane at peak_dbfs: -1.12, mean_dbfs: -17.50.
• It completes at all — which, as you said, is the evidence that the shift and the alpha reached the scheduler and the adapter. A 768p LoRA on a 544p sigma schedule at a sixteenth of its trained strength is not something that announces itself, but it also had every opportunity to fall over here and didn't.

The cost figure this template was missing

13.1 min cold, 124 f, 1344x768, 9 steps (8 evaluations), RTX 3090, model load included.

Phase breakdown from get_job_events, since the shape is more useful than the total:

phase	seconds
load (pipeline + LoRA)	0 -> 137.8
lead-in (text encode, prepare)	137.8 -> 171.4 (33.6)
denoise, 8 steps	171.4 -> ~752 (~580)
decode + save	~752 -> 786.0 (~34)

The first denoise step took ~232 s and steps 2-8 settled to ~40-57 s each. That first-step outlier is the same warm-up I saw on #150's reload, so I'd read the steady-state per-step cost as ~50 s rather than the ~72 s the naive average gives.

Worth putting beside the 544p number. reference-to-video at 960x544 measured 496 s the same day (job b4b5959424d3, ~33 s/step). So 768p costs roughly 1.6x the wall clock for 2.67x the pixels — the fixed floor (137 s of load alone) is what flattens it. At this canvas the load is 18% of the job.

Memory: it fits, but the margin is unchanged, not improved

Closing memory event: host_memory_peak_rss_mb: 61548.90 against host_memory_total_mb: 64208.58 — 95.9% of host RAM, with gpu_memory_allocated_mb only 256.8 (offload). That is within noise of the 544p run's 61487.10 peak.

Which says something useful: at 124 frames the canvas barely moves peak host memory — the weights dominate and the 768p latents don't change that. So the "defaults are 124 frames, and the frame count is where to give ground" note in your description is the right guidance, and the ~4% headroom is a property of the model on this box rather than of this template. Your write-up's conclusion stands: this makes 768p cheap in time, and does nothing for the ceiling.

I did not try to find where it breaks — 345 frames at this canvas is the configuration that OOMed before, and re-confirming a known OOM is not worth 20 minutes and a worker restart.

What I can't tell you

Whether it looks better. That is the entire reason the template exists, and it needs a human eye on this clip against a 544p render of the same prompt and seed. Both templates default to seed: 42 and prompt:minimax/fox_dawn_context_ir, so that A/B is exactly one more run of video-with-audio whenever someone wants it — I have not spent it, since I could not judge the result.

Also untested: lora_alpha as a knob. This run used the template's pinned 128. That an alpha matching no loaded layer raises rather than silently scaling nothing is your stated design and a good one, but I haven't probed it.

Regression case added: regression-suite-model-specific.md M-F008, with a metrics: line and regression-perf/M-F008.jsonl seeded from this run. source: tester, verified in #148.