MiniMax-H3 Prompt Rewriter 8B (sees frames)

The big 27B rewriter is the reference, but it needs ~16 GB of VRAM and a 52 GB download to get there. This node is the same idea on Qwen3-VL-8B-Instruct with LightX2V's second LoRA - and the difference is more than size. Where the 27B has to be told what your first frame contains in words, this model is multimodal. You plug the actual picture in, and it writes the alignment line from what it sees.

That unlocks something the 27B simply can't do: real I2VA, L2VA and FL2VA. The 27B's LoRA is text-only and covers T2VA. The 8B's adapter was trained on four tasks - text-to-video, image-to-video, first+last-frame, last-frame - and it looks at the images itself. So if your job is "make a video that starts from this frame," this is the node. About 9 GB of VRAM on a Q4_K_M base, versus 16+ for the 27B, and the output format is byte-for-byte the same shape, so it swaps straight into a workflow built around the big one.

How it works

Two ways to hold the base model, and the node takes either:

• GGUF - the model plus its mmproj projector, two files from one conversion. Needs nothing installed: it runs through the official llama.cpp binaries (llama-mtmd-cli for the frame tasks), fetched automatically if you don't have them.
• safetensors - the official Qwen3-VL-8B-Instruct folder the adapter was published against. Loaded via Transformers/peft at nf4 (~8 GB), int8 (~13 GB) or bfloat16 (~20 GB). This is the route that keeps the model resident for every task; the GGUF route can only honour keep_model_loaded on T2VA, because the frame tasks run in a fresh subprocess that takes the model with it.

Only the 8B fits this adapter. A Qwen3-VL of any other size is refused by name and number before anything is downloaded, which saves you from a confusing failure later.

Inputs that matter

• task - T2VA, I2VA, FL2VA, L2VA (the model's own names are T2AV/I2AV/FL2AV/L2AV; same four things).
• first_frame / last_frame - IMAGE inputs. I2VA reads first_frame, L2VA reads last_frame, FL2VA reads both, T2VA reads neither. Connect the wrong one and the node says which is missing before it loads anything - which end of the clip a picture belongs to is part of what the model is told.
• model / quantization - your base and how to load it. quantization is ignored for GGUF, which carries its own.
• greedy - keep on; deterministic output.

Outputs are the same four as the 27B node (rewritten_prompt, integrated_multimodal_description, overall_soundscape, non_diegetic_music), so the two are interchangeable downstream. The options input takes the same Rewriter Options node as everything else in the pack; its adapter dropdown lists both LoRAs and the first entry auto-picks whichever matches your base, so you don't have to think about it.

Install and cost

Same pack, same install - clone into custom_nodes or grab it from ComfyUI Manager, and on the Transformers route pip install -r requirements.txt. The GGUF route installs nothing.

| Setup | Download | VRAM | |---|---|---| | Q4_K_M base + projector + Q8_0 adapter | ~6.1 GB | ~9 GB | | Q8_0 base + projector + F16 adapter | ~10.1 GB | ~13 GB | | safetensors base, nf4 | ~20 GB | ~8 GB |

The GGUF route is the smaller download and the one to start on; reach for safetensors if you already have the checkpoint or need the model resident across every task.

What to expect of it

It's an 8B, and it shows in one place: the alignment line's timestamp sometimes comes back with three decimals instead of two, and on FL2VA the final picture occasionally gets credited to Shot 1 rather than the last shot. Nothing downstream parses that line, so it costs correctness nowhere - but give the output a glance before you paste it into H3. Worth noting: with the LoRA switched off (use_lora in the options node), the same model still fills the three fields because the format contract lives in the system prompt - it just stops writing [Shot 2] cut markers and the answer comes back about a third as long. The LoRA is the difference between "structured" and "properly shot-by-shot."