A GGUF conversion of lightx2v/MiniMax-H3-Prompt-Rewriter-LoRA-8B, so the multimodal rewriter runs under llama.cpp against a quantized Qwen3-VL-8B-Instruct.

This repository contains no new training — only a format conversion. The tensor values are unchanged.

The 27B rewriter reads text and covers one task. This adapter's base model has a vision tower, so it looks at the reference frames rather than being told about them in words, and it covers four tasks:

For everything but T2AV the answer opens with an alignment sentence that MiniMax-H3 itself reads, with the timestamps already filled in.

It is also much smaller than the 27B route:

A multimodal model is two files, and the projector has to come from the same conversion as the base. Both are in Qwen/Qwen3-VL-8B-Instruct-GGUF; mmproj-Qwen3VL-8B-Instruct-Q8_0.gguf is the smaller of the two projectors and is what the numbers above assume.

Tensor count and alpha match the source adapter exactly. The adapter touches the text tower only — q/k/v/o and gate/up/down across 36 layers; the vision tower is untouched, which is why 504 tensors cover the whole thing.

Take Q8_0 unless you have a reason not to. Names, order and every metadata field are identical to the F16; only the stored values differ, by a mean of 0.005 relative across all 504 tensors and 0.006 on the worst one. Both produce the trained output shape: the three fields, [Shot 2] At 00:04.500 cut markers, (S1) speaker ids and <d>[English] ...</d> dialogue tags.

There is no Q4_K_M. llama-quantize treats an adapter GGUF as a model and stops at key not found in model: qwen3vl.context_length, so F16 and Q8_0 are the only two formats the tooling offers for a LoRA.

A task with pictures goes through llama-mtmd-cli, and <__media__> is where each one is spliced in. The number of markers must equal the number of --image arguments, or tokenization is refused.

T2AV has no pictures, so it needs no projector and runs under plain llama-completion:

system_prompt.txt must hold the exact system prompt from prompt_template.py in the source repository — the adapter was trained on that wording, and changing it degrades the rewrite. That file also builds the user turn, including which line introduces each picture, which differs per task.

-st on the second command is worth keeping: llama-cli enters chat mode on this model despite -no-cnv and then waits for a second turn, so the run never ends.

MiniMax-H3-Prompt-Rewriter-ComfyUI ships a node for this adapter — MiniMax-H3 Prompt Rewriter 8B (sees frames). Pick a Qwen3-VL base, choose the task, connect first_frame and last_frame where the task wants them, and this adapter is fetched from here on first use. The options node's adapter dropdown lists both precisions.

All four tasks produce the trained shape, and with the adapter off the same base model stops writing [Shot 2] cut markers and answers about a third as long — which is the simplest confirmation that it is attached.

It is an 8B, and that shows in one place: the alignment line's timestamp is sometimes formatted to three decimal places instead of two, and on FL2AV the final picture is occasionally credited to Shot 1 rather than the last shot. The 27B adapter does not do this.

convert_lora_to_gguf.py from llama.cpp, with nothing done to it. Qwen3-VL is an ordinary attention architecture, so the V-head reordering that makes the 27B conversion awkward never comes up here. Both files are separate runs of the converter, not one quantised from the other.

No --base is needed: the adapter's own adapter_config.json names Qwen/Qwen3-VL-8B-Instruct, and the converter reads the base config from the hub. Only the config is fetched — the base weights are not required.

The weights originate from lightx2v/MiniMax-H3-Prompt-Rewriter-LoRA-8B and were converted without modifying their values. Whatever terms that repository carries apply here unchanged; this repository claims nothing additional.

Use of MiniMax-H3 itself is governed by the licence and acceptable-use terms in the official MiniMax-H3 repository.