I agree. You should make some!

@q5sys I did post an example... it's literally in the header with the title image. I am not going to post a library of examples, though, no. There are 25 checkpoints in this group, only three of which are uploaded so far, this repo is far from complete. If you want examples, you have the technology.

@randombrowser1234 So.. don't? What do you think I lose when you don't use my completely free model, exactly? What is the threat? I genuinely don't understand.

Five minutes, about to flip public.

@DigitalGarbage Yeah, these are meant to generate higher quality renders, and I haven't even tested Turbos LoRAs with them at all - I've yet to test turbo loras on any of my models, to be honest. I generally run my tests at 1280x736 - most of my real content is for social media and vertical aspect ratio.

@QualityControl Thank you! Should be INT8 models in all of the repos as well, unless I missed one somewhere? I try to get up every format I can think of so everyone has something they can use.

@QualityControl Civ is extremely slow to upload, so I get things up on HF first. I am working on those now. Yes, same models - sometimes HF has more because I get annoyed with uploads here ;) Also, I meant to tell you before that I'm a big fan of your Amateur Hour lora - most of my non-demo content is vertical found footage content for socials, and it was one a I used all the time! You should totally make one for LTX2.5 and H3.

It's quite a big heavier, but my Q4 GGUF is 10.68GB for 12-16GB cards. You'll still go over when you throw in the TE, VAE's, etc., but it will work, just kind of slow. LTX is much more forgiving where VRAM and speed is concerned, but H3 beats it in quality all day.

That said, I do have some LTX merges that you might want to check out as well:

Joy-LTX 2.5 Distilled GGUF / INT8 / NVFP4 / W4A8 / MIX4x8 - 16GB | LTX Video Checkpoint | Civitai

@gambikules858 There is a Q3 at that link. I built a Q2, but didn't upload it, because it's awful.

Unfortunately, on a 12GB card, you'll never avoid offloading.

@randombrowser1234 You should be able to just add a GGUF loader. I'd try Q3 or Q4. There's a few GB difference, and if the quality is good with Q3, no reason not to save the VRAM for a little speed boost. I test these at 736x1280 and upscale at 1.5 from there usually and the quality is pretty good, even at Q3.

That said, I have never tested turbo loras on any of these, so I can't account for quality if you do.

@randombrowser1234 Full disclosure on the nvfp4 - I am not a big fan and I'd take the slower renders to get the better quality and still stick with GGUF over it. Or maybe even try the w4x8.

@randombrowser1234 You may need to update your nodes/ComfyUI. It doesn't support Minimax GGUF's natively. You can also add support manually:

Open:
ComfyUI/custom_nodes/ComfyUI-GGUF/loader.py

Search for the error string or locate the architecture check block (around line 90).

Modify the code block to bypass the error for minimax_h3 by adding and arch_str != "minimax_h3": [1, 2]

# Before
elif arch_str not in IMG_ARCH_LIST and not is_text_model:

# After
elif arch_str not in IMG_ARCH_LIST and not is_text_model and arch_str != "minimax_h3":

Yes.

Damn, Civ mislabeled it. I'll upload the real bf16 today.

I'm working on the IN8 upload here today

Uploading now. ;)

You may want to download from my HF repo, uploading to Civ is ridiculously slow:


https://huggingface.co/joeygambino/MiniMax-H3-x-Z-Image-native/blob/main/minimax_h3_fl2va_zs05_int8_convrot.safetensors

@wyxzddsjj919 I was adding HF links for other models and then I forgot and stopped. But I will update with links. I don't only upload on HF, simply because some new kids seem to be confused by it, so I try to keep them in both places.

Nothing is extracted from the Z-Image DiT, and no Z-Image weights run at inference. Z-Image only donates a statistics profile, measured offline: per-block row norms of the fused-QKV q-slice, mean-normalized into a depth curve. That curve rescales H3's own per-block q_norm weights by small factors (roughly ±10% at the shipped dose). So it's a per-depth attention-temperature adjustment of H3, shaped by where Z-Image concentrates its query energy - much closer to a hyperparameter transfer than a weight transplant. (Also, Z-Image Turbo is single-stage - there's no refiner in its pipeline - and either way none of its weights are involved here.)

On "no guarantee of improvement" - which is why the claim is empirical rather than theoretical. These bakes only shipped after same-seed A/Bs (stock vs graft, identical prompt/seed/settings). The dose is deliberately 0.5 for the same reason.

Where the gain lands matters more than that it lands. Early-block boosts produced checkerboard artifacts on H3, which is why the shipped bake is late-block only. That late-only profile is what produced the visible set-dressing and texture differences in tested pairs.

It's there, but Civ likes to name things badly.

https://civitai.com/api/download/models/3256384?fileId=3141163

Added some A/Bs. It's not terribly noticeable for most, but I was getting frustrated with certain missing fine details, especially where foliage is concerned. It's also a much bigger problem on LTX than it is on H3, but I figured while I was building the LTX merges (which you really do notice the difference on), I figured I'd do these as well.

You should do that, yes.

They're better, but you also don't have to use them. We all have free will, different visual processing capabilities, and are allowed to make mistakes. It isn't my job to convince you; I'm not getting paid for this.

Euler/beta57 for faster renders, res_2s for better motion. There are seven models in this repo though - which did you use, and what are your hardware specs?