infosave

/

MiniMax-H3-Turbo-cmf

like 10

You already have the next step up, and on the M1/64 GB it is the one to run: mmh3-turbo-fl2va-q4tp.cmf, 23.9 GB — the release's own 32B prompt encoder instead of the 4B + ClipProj stand-in. On 24 GB that file only works because 0.5.79 releases the encoder's pages after the text encode; with 64 GB none of that applies and the whole pipeline stays resident.

The ladder, in one table:

There is no higher quant of the DiT published because four bits on this DiT is not where the quality goes — the encoder is. That is measured, with pictures, in the card under Making it smaller.

On the quants themselves ("not sure how they work"), I wrote the guide you were asking for: huggingface.co/infosave/cmf/blob/main/FORMATS.md — what q4tp, q2tp, q1t and the rest cost, and why the packer picks a different precision for the modulation curve and the token table than for a projection.

For burning in LoRAs, the instructions are in #8 — both the runtime path (new today) and the bake path.

The eight-bit build is packed and uploaded: mmh3-turbo-clipproj4b-fl2va-v2-q8_2f.cmf — 26.90 GB, 26.21 B parameters, cortiq verify clean.

Not plain q8 — q8_2f, the two-field int8: w = q·row[o]·col[i], eight bits with a second scale field along the input axis, which is where an activation-outlier channel shows up from the weight side. Same bits as q8_row, more faithful on this DiT's weights.

One caveat I owe you before you download 27 GB: it renders on the host. Every device path in this engine is q4tp-shaped — the fused qkv/attention/output kernel and the packed FFN both read the four-bit tiled layout — and q8_2f has a matvec but no matmat on either backend yet. On a 5090 the card sits idle and sixteen cores work instead. So: take it to compare codecs or to render overnight on the M1/64 GB; take the q4tp file when you want the GPU. The missing piece is one kernel, and it is next on my list.

The 4B ClipProj encoder is still the one inside it — the rung above is the 32B encoder, which is a separate ~50 GB build.

The latent upscaler is ported — 0.5.93, and it runs rather than being described:

cortiq animate model.cmf --prompt "…" --width 512 --height 288 \
  --upscale minimax_h3_latent_upscaler_3d_fp16.safetensors --upscale-by 2.0

Render small, the net resizes the latent, the VAE decodes once at the larger size — no decode → resize → encode round trip through the 5 B VAE. Parity against the node's own torch module on the same weights: worst 6.7e-6, relative rms 3.9e-7.

Numbers for the caveat, now that it has run rather than been reasoned about — RTX 5090, 512×288, 22 frames, four steps:

mmh3 GPU parity probe: no q4tp qkv tensor — host path
stages: text encode 1.1s · denoise 198.8s · video vae 151.6s · audio vae 4.5s
q82f.avi: … in 357.3s

357.3 s with the card idle, against 60.2 s for the q4tp file on the same class of card. The engine refuses the device arm by name — every kernel here reads the four-bit tiled layout — so this is one missing q8_2f matmat, not a redesign.

The file itself is sound: cortiq verify clean, 26.21 B parameters, and it renders the clip correctly. Just slowly, until that kernel exists.

Correction to my own caveat, and a better outcome than I promised.

I said the eight-bit file needs a missing kernel. It did not — it needed two gates fixed, and 0.5.94 has both:

1. The startup probe matched a qkv weight on Q4TiledP by dtype. Finding no four-bit tensor it declared the host path for the entire render, for a codec that does have a device GEMM: the two-field int8 folds its column field into the activation and what remains is the per-row int8 kernel both backends already ship.
2. The weight-residency budget was the whole card minus a gigabyte. Every container published before this one had weights far under it; 24 GB of eight-bit weights took the heap and the first scratch allocation died with wgpu error: Out of Memory. A quarter is held back now — 32 GB card → 24 GB of weights, 24 → 18, 16 → 12.

Same file, same clip, RTX 5090: 357.3 s → 171.5 s, GPU 0% → 58%, 2 MiB → 29.7 GB resident, and the probe agrees with the CPU arm to 5.77e-3.

Still 2.8× the four-bit file's 60.2 s — that part is kernels: q4tp has the fused qkv → attention → output submission and the packed FFN, q8_2f goes through the generic per-op GEMM. Fusing them for the two-field codec is real work and it is on the list, but the file is usable on a card today. Update to 0.5.94 and it just runs.

The eight-bit file is now the fastest one in this repo. RTX 5090, 512×288, 22 frames, four steps — one machine, one sitting, same container:

So the more faithful codec is also ~2× faster than the four-bit one now. Nothing changed in the file — download it again only if you want the newer pack; the gain is all runtime. Three things were in the way:

1. The fused chains asked for a four-bit weight by name. mapped_q4tp was the door to every fused submission in the DiT and the 3D VAE, so an eight-bit container walked past all of them into per-op GEMMs with a readback between each.
2. int8 never reached the matrix units. The four-bit path unpacks its weight into an f16 plane once and hands that to the cooperative GEMM; int8 ran the scalar kernel. q8_dq_f16 writes the same plane — and folds the two-field codec's column field into it, so the activation is no longer multiplied by that field on the host before every projection.
3. The panels now stay on the card through qkv → attention → output and through the FFN pair.

CMF_Q8_COOP=0 and CMF_FUSED_ANY=0 put the old arms back; every row above is one of those switches, and all of them render the same frame.

One thing I owe you plainly: opening that gate sent int8 weights into the VAE's own fused kernel, which still called the four-bit entry points — it read int8 as four-bit tiles, ran three times too fast, and produced a flat grey frame. Fixed, and the four-bit GEMM now refuses a codec it cannot read rather than returning plausible garbage. If you ever see a uniformly grey render, that is what it looks like.

Correction to the table I posted twenty minutes ago — the q4tp column was wrong, and in my favour.

That container was being read from a network filesystem cold, so its first-touch page faults landed inside the denoise timer. Read from local disk, warm, on the same card and clip:

So the honest statement is not "the eight-bit file is now the fastest here". It is: q8_2f went 171.5 s → 46 s (3.7×), its VAE now matches the four-bit one exactly (9.0 s against 8.7 s), and its denoise is still 1.8× behind four-bit. Everything else I wrote about why it was slow — the gate, the matrix units, the column field, and the grey frame the widened gate caused — stands.

For anyone choosing a file today: q4tp remains the fastest, q8_2f is the more faithful codec at a real but no longer punishing cost, and 27 GB of weights against 15 GB is most of what is left of the gap.

Also measured, since it is the obvious next question: forcing the four-bit path to unpack its weight into an f16 plane at narrower batches (CMF_Q4TP_PLANE_MIN=8) makes it worse — 36 s against 31 s. Its current gate is right.