Trying to get omnimattezero installed but cant find the models

Cloakfiend · June 4, 2026, 5:22pm

I have the VAE diffusers but this one seems to be nowhere?

LTX-Video-0.9.7-diffusers-Q8_0.gguf

Its the only one missing,

I tried to sign up to we chat but is says i need to wait 3 months!

Please help!

John6666 · June 4, 2026, 11:16pm

Hmm… I found something a little hard to find, but there is a likely substitute. I think it should work if you rename it:

The exact filename from the ComfyUI_OmnimatteZero README:

LTX-Video-0.9.7-diffusers-Q8_0.gguf

does not seem to exist publicly on Hugging Face under that exact name, at least not in the obvious linked repo. However, I think the likely intended GGUF is this one:

ltxv-13b-0.9.7-dev-Q8_0.gguf

from:

wsbagnsv1/ltxv-13b-0.9.7-dev-GGUF

The reason I think this is the right substitute is that the OmnimatteZero README appears to use a simplified / renamed filename, while the actual available GGUF repos use the LTXV 13B naming convention.

Short answer

Try this file:

ltxv-13b-0.9.7-dev-Q8_0.gguf

Put it here:

ComfyUI/models/gguf/ltxv-13b-0.9.7-dev-Q8_0.gguf

Then, if the OmnimatteZero node expects the README-style name or you want to avoid confusion, rename it to:

ComfyUI/models/gguf/LTX-Video-0.9.7-diffusers-Q8_0.gguf

In the node, select the GGUF file from the gguf dropdown and set the dit / diffusion model field to none.

Why this looks like the right file

The OmnimatteZero README lists the model locations like this:

Component	README location	README filename
VAE	`ComfyUI/models/vae`	`LTX-Video-0.9.7-vae-diffusers.safetensors`
DiT / safetensors	`ComfyUI/models/diffusion_models`	`LTX-Video-0.9.7-diffusers.safetensors`
GGUF	`ComfyUI/models/gguf`	`LTX-Video-0.9.7-diffusers-Q8_0.gguf`

Source:

smthemex/ComfyUI_OmnimatteZero README

The README links the DiT/GGUF model line to a Chinese cloud source and to this Hugging Face repo:

smthem/LTX-Video-0.9.7-diffusers-merge

But that smthem repo only appears to contain the safetensors file:

LTX-Video-0.9.7-diffusers.safetensors

I do not see the GGUF file there.

The likely matching GGUF is instead in:

wsbagnsv1/ltxv-13b-0.9.7-dev-GGUF

That model card says it is a direct GGUF conversion of the 13b-0.9.7-dev variant from Lightricks/LTX-Video and that it can be used in ComfyUI with the ComfyUI-GGUF custom node.

Relevant file:

ltxv-13b-0.9.7-dev-Q8_0.gguf

File page:

ltxv-13b-0.9.7-dev-Q8_0.gguf

Suggested download command

From your ComfyUI directory:

huggingface-cli download \
  wsbagnsv1/ltxv-13b-0.9.7-dev-GGUF \
  ltxv-13b-0.9.7-dev-Q8_0.gguf \
  --local-dir ./models/gguf

Or with an explicit ComfyUI path:

huggingface-cli download \
  wsbagnsv1/ltxv-13b-0.9.7-dev-GGUF \
  ltxv-13b-0.9.7-dev-Q8_0.gguf \
  --local-dir <path-to-your-ComfyUI>/models/gguf

Optional rename:

mv \
  <path-to-your-ComfyUI>/models/gguf/ltxv-13b-0.9.7-dev-Q8_0.gguf \
  <path-to-your-ComfyUI>/models/gguf/LTX-Video-0.9.7-diffusers-Q8_0.gguf

On Windows PowerShell:

Rename-Item `
  "<path-to-your-ComfyUI>\models\gguf\ltxv-13b-0.9.7-dev-Q8_0.gguf" `
  "LTX-Video-0.9.7-diffusers-Q8_0.gguf"

Why renaming should be okay

From the OmnimatteZero code, the filename does not appear to be hardcoded. The node registers a gguf folder and then exposes files from that folder in the gguf dropdown.

Relevant code:

OmnimatteZero_node.py

The important part is that it adds:

ComfyUI/models/gguf

as a model folder, and then the node has separate dropdowns for:

dit
gguf
vae

So the practical setup should be:

dit  = none
gguf = ltxv-13b-0.9.7-dev-Q8_0.gguf
vae  = LTX-Video-0.9.7-vae-diffusers.safetensors

or, if renamed:

dit  = none
gguf = LTX-Video-0.9.7-diffusers-Q8_0.gguf
vae  = LTX-Video-0.9.7-vae-diffusers.safetensors

The loader code also has a separate GGUF path. If gguf_path is not None, it loads the transformer from the GGUF file with LTXVideoTransformer3DModel.from_single_file(...) and GGUFQuantizationConfig(...).

Relevant code:

object_removal.py

If Q8_0 is too heavy

Q8_0 is large. The wsbagnsv1 repo also has smaller quantized files:

Quant	File	Approx. size
Q8_0	`ltxv-13b-0.9.7-dev-Q8_0.gguf`	14 GB
Q6_K	`ltxv-13b-0.9.7-dev-Q6_K.gguf`	10.9 GB
Q5_K_M	`ltxv-13b-0.9.7-dev-Q5_K_M.gguf`	9.82 GB
Q4_K_M	`ltxv-13b-0.9.7-dev-Q4_K_M.gguf`	8.82 GB
Q3_K_S	`ltxv-13b-0.9.7-dev-Q3_K_S.gguf`	5.86 GB

Repo file list:

wsbagnsv1/ltxv-13b-0.9.7-dev-GGUF files

For a first test, Q4_K_M may be easier:

huggingface-cli download \
  wsbagnsv1/ltxv-13b-0.9.7-dev-GGUF \
  ltxv-13b-0.9.7-dev-Q4_K_M.gguf \
  --local-dir ./models/gguf

Alternative GGUF repo

There is also another GGUF repo here:

calcuis/ltxv0.9.7-gguf

It contains a similarly named Q8 file:

ltxv-13b-0.9.7-dev-q8_0.gguf

File list:

calcuis/ltxv0.9.7-gguf files

I would try the wsbagnsv1 repo first, because its model card explicitly says it is a direct GGUF conversion of the LTXV 13b-0.9.7-dev variant and mentions ComfyUI / ComfyUI-GGUF usage.

VAE note

For the VAE, the OmnimatteZero README points to:

a-r-r-o-w/LTX-Video-0.9.7-diffusers

The README says to place it as:

ComfyUI/models/vae/LTX-Video-0.9.7-vae-diffusers.safetensors

So if your downloaded VAE has a generic name like:

diffusion_pytorch_model.safetensors

rename it to:

LTX-Video-0.9.7-vae-diffusers.safetensors

My guess

I think the README filename:

LTX-Video-0.9.7-diffusers-Q8_0.gguf

is probably one of these:

a local / renamed copy of ltxv-13b-0.9.7-dev-Q8_0.gguf;
a filename from the Chinese cloud mirror mentioned in the README;
a simplified name written by the OmnimatteZero wrapper author to match the safetensors naming style.

But the actual public HF file that seems to correspond to it is most likely:

ltxv-13b-0.9.7-dev-Q8_0.gguf

from:

wsbagnsv1/ltxv-13b-0.9.7-dev-GGUF

Practical checklist

ComfyUI/models/gguf/
  ltxv-13b-0.9.7-dev-Q8_0.gguf
  # or renamed:
  LTX-Video-0.9.7-diffusers-Q8_0.gguf

ComfyUI/models/vae/
  LTX-Video-0.9.7-vae-diffusers.safetensors

ComfyUI/models/diffusion_models/
  # leave empty / do not use if using GGUF

Then in OmnimatteZero_SM_Model:

dit  = none
gguf = ltxv-13b-0.9.7-dev-Q8_0.gguf
vae  = LTX-Video-0.9.7-vae-diffusers.safetensors

If it runs out of memory, try Q6_K, Q5_K_M, or Q4_K_M instead of Q8_0.

Cloakfiend · June 5, 2026, 1:58pm

You’re a legend mate, much appreciated, Im new to all this but slowly getting there! I’ll give this a try today!

Thanks again!

Mac

Cloakfiend · June 7, 2026, 6:40pm

HI, Not sure if you can help, but I got it working, but it renders a faint grid over everything, i tried to set the block count to zero to avoid tiling but it didnt work, is there any way to prevent this? i know this is for 12GB cards but I have 32GB so maybe I can skip the tiling somehow but it wont let me for some reason?

How can I disable group offloading?

John6666 · June 8, 2026, 12:39am

Nice. Looks like there may be a more suspicious culprit than offloading:

I think the faint grid is probably not caused by the GGUF file itself, and maybe not by block_num either. The first thing I would test is VAE tiling.

In the current ComfyUI_OmnimatteZero code, block_num = 0 does not mean “disable all memory-saving behavior”. It only avoids the apply_group_offloading(...) branch. The fallback branch still calls model.enable_model_cpu_offload().

Relevant file:

OmnimatteZero_node.py

The relevant logic is roughly:

if block_num > 0:
    apply_group_offloading(
        model.transformer,
        onload_device=torch.device("cuda"),
        offload_type="block_level",
        num_blocks_per_group=block_num,
    )
else:
    model.enable_model_cpu_offload()

So the behavior is:

`block_num` value	What happens	What it does not mean
`> 0`	Uses Diffusers group offloading on the transformer	Not image tiling
`0`	Skips group offloading, but still enables model CPU offload	Not “disable all offloading / tiling”

The grid artifact sounds more like a VAE tiling artifact. In object_removal.py, VAE tiling is enabled unconditionally:

pipe.vae.enable_tiling()

There is also another one for the upsample path:

pipe_upsample.vae.enable_tiling()

Diffusers’ own docs describe VAE tiling as a memory-saving method that decodes the image in overlapping tiles, and they note that tile-to-tile tone variation can happen:

Diffusers memory optimization docs: VAE tiling

So if you have a 32GB card, I would test disabling VAE tiling first.

Patch 1: disable VAE tiling

Open:

ComfyUI/custom_nodes/ComfyUI_OmnimatteZero/object_removal.py

Find:

pipe.vae.enable_tiling()

Change it to:

# pipe.vae.enable_tiling()

Also find:

pipe_upsample.vae.enable_tiling()

Change it to:

# pipe_upsample.vae.enable_tiling()

Then fully restart ComfyUI and test the same workflow again.

Patch 2: if you also want to avoid model CPU offload

This is optional. I would only try this after testing VAE tiling first.

Open:

ComfyUI/custom_nodes/ComfyUI_OmnimatteZero/OmnimatteZero_node.py

Find this block:

if block_num > 0:
    apply_group_offloading(
        model.transformer,
        onload_device=torch.device("cuda"),
        offload_type="block_level",
        num_blocks_per_group=block_num,
    )
else:
    model.enable_model_cpu_offload()

For a 32GB card, you can try replacing the else branch with model.to(device):

if block_num > 0:
    apply_group_offloading(
        model.transformer,
        onload_device=torch.device("cuda"),
        offload_type="block_level",
        num_blocks_per_group=block_num,
    )
else:
    model.to(device)

There are two similar blocks in the file, so check both:

the normal inference path;
the compose/background-replacement path.

The second one appears around the compose_video(...) path.

Test order I would use

Step	Change	Reason
1	Comment out `pipe.vae.enable_tiling()`	Most likely source of a visible grid
2	Also comment out `pipe_upsample.vae.enable_tiling()` if using the upsample path	Same reason, but only matters if that path is used
3	Keep `block_num = 0`	Avoid group offloading while testing
4	If the grid remains, replace `model.enable_model_cpu_offload()` with `model.to(device)`	Tests whether CPU/model offload is involved
5	If VRAM runs out, restore offloading or use a smaller GGUF quant	Q8_0 can still be heavy depending on resolution and frame count

Important caveat

Disabling VAE tiling increases VRAM use. A 32GB card has a much better chance of handling it, but it can still OOM depending on:

resolution;
number of frames;
whether Q8_0 / Q6_K / Q5_K_M / Q4_K_M is used;
whether upsampling is enabled;
whether compose mode / background replacement is enabled;
how much VRAM ComfyUI already has occupied.

So I would not change everything at once. First test only this:

# pipe.vae.enable_tiling()
# pipe_upsample.vae.enable_tiling()

If that removes the grid, then the issue was probably VAE tiling rather than group offloading.

Topic		Replies	Views
Running Modern AI Image Models on a GTX 1060 6GB — A Practical Guide Beginners	0	611	May 18, 2026
Need help getting started with image generation Beginners	8	2462	March 6, 2026
Looking for an open source image-to-video to test with Intel ARC GPU Beginners	13	2507	February 26, 2025
A model for converting photos to videos with 8GB of VRAM Models	5	4935	November 8, 2025
"Load Diffusion Model" and "Unet Loader (GGUF)" null/undefined Beginners	8	11661	March 22, 2025

Trying to get omnimattezero installed but cant find the models

Short answer

Why this looks like the right file

Suggested download command

Why renaming should be okay

If Q8_0 is too heavy

Alternative GGUF repo

VAE note

My guess

Practical checklist

Patch 1: disable VAE tiling

Patch 2: if you also want to avoid model CPU offload

Test order I would use

Important caveat

Related topics