Z-Image Turbo GGUF: Quant Sizes, VRAM and ComfyUI Setup (2026 Guide)

The mistake I made with Z-Image Turbo was picking the quant by reputation. Q8_0 is "the good one", so I downloaded it, loaded it, and watched ComfyUI spend forty seconds shuffling weights between system RAM and GPU before producing a single image. My card had 12GB. The 7.22GB UNET fit. The 4B text encoder and the activations did not fit alongside it.

Z-Image Turbo is a 6B-parameter model from Alibaba's Tongyi team, and GGUF quants take it from "needs a 24GB card" to "runs on a 3060" — but only if you do the VRAM arithmetic before you download. The difference between Q4_K_M and Q8_0 is 2.2GB of weights, which is exactly the difference between a model that generates in 20 seconds and one that thrashes.

This guide is the arithmetic, the quant table with real file sizes, and the ComfyUI setup that works.

TL;DR

• Q4_K_M (4.98GB) is the right default for a 12GB card. It leaves room for the Qwen3-4B text encoder, the VAE and the activations at 1024×1024.
• Q8_0 (7.22GB) is for 16GB and up. On 12GB it technically loads and then offloads, which is slower than a smaller quant that stays resident.
• The UNET is not the whole model. Budget for the text encoder (~2.9GB at Q5), the VAE (~0.3GB) and roughly 2GB of runtime overhead at 1024². That is why a 5GB UNET needs a 12GB card.
• 9 steps, guidance 0. Z-Image Turbo is distilled; above ~12 steps you are paying time for nothing, and a positive guidance scale is what produces the washed-out look people blame on the quant.
• GGUF is the compatibility route, not the quality route. On a 40-series card with 16GB, an FP8 checkpoint is a better trade than any K-quant.
• The lowest useful floor is about 4GB, via stable-diffusion.cpp with Q4_K_M — not through ComfyUI. On ROCm that combination can output black frames; Vulkan works.

The Quant Table, With Real File Sizes

These are the published GGUF sizes for the Z-Image Turbo UNET, six-bit architecture, 5-bit quantisation groups:

Quant	File size	Fits a 8GB card?	Fits a 12GB card?	Sensible for
Q3_K_S	3.79GB	With tight headroom	Easily	6–8GB cards, draft work
Q3_K_M	4.12GB	Yes	Easily	8GB, better than K_S at almost no cost
Q4_K_S	4.66GB	Marginal	Yes	8GB cards that must stay resident
Q4_K_M	4.98GB	No	Yes — the default	12GB, best size/quality point
Q5_K_S	5.19GB	No	Yes, with less room for 1536²	12GB, quality-focused
Q5_K_M	5.52GB	No	Yes at 1024², tight at 1536²	12GB, if you keep resolution at 1024
Q6_K	5.91GB	No	Tight — expect offload	16GB
Q8_0	7.22GB	No	No, not without offload	16GB+, or quality benchmarking

The sizes come from the quantiser's own repository, and they explain a pattern you will see in forum reports: people on 12GB cards saying Q8_0 "works but is unusably slow". It does work. It just does not fit, so ComfyUI streams weights across the PCIe bus on every step.

The Arithmetic Nobody Puts in the Install Guide

A GGUF UNET is one of four memory consumers. Before picking a quant, add all four up:

Component	Size at the recommended quant	Notes
UNET (diffusion transformer)	Q4_K_M: 4.98GB · Q8_0: 7.22GB	The number in every table
Text encoder (Qwen3-4B, GGUF)	~2.9GB at Q5_K_XL · ~2.5GB at Q4_K_M	A 4B LLM — it is not small
VAE	~0.3GB	ae.safetensors, loaded once
Runtime (latents, attention workspace at 1024²)	~1.5–2.5GB	Scales with resolution

Add it up for 1024×1024 on a 12GB card:

• Q4_K_M: 4.98 + 2.91 + 0.3 + ~2.0 = ~10.2GB — fits, with roughly 1.8GB of slack.
• Q8_0: 7.22 + 2.91 + 0.3 + ~2.0 = ~12.4GB — does not fit. Every step pays for it.

At 1536×1536, the activation term roughly doubles, which pushes Q5_K_M over the line on 12GB and makes Q4_K_M the only quant that stays comfortable. This is the single most useful planning rule for the model: compute the sum, not the UNET size.

If you want output today, start here: Launch Z-Image Now →

What You Actually Notice Between Quants

Quantisation damage is not uniform. It shows up in a predictable order, which tells you whether you can get away with Q3.

What degrades first	Q3_K_M	Q4_K_M	Q6_K / Q8_0
Fine texture (skin pores, fabric weave, film grain)	Soft, slightly plastic	Mostly intact	Intact
Small text in the frame	Breaks up	Usually legible	Legible
Hands and fingers	More failures	Occasional failures	Fewest failures
Dense detail (foliage, crowds, hair strands)	Mushes together	Resolves at normal viewing size	Resolves
Overall colour and composition	Unaffected	Unaffected	Unaffected

The pattern that matters: composition, lighting and colour survive aggressive quantisation; texture and text do not. If you are generating thumbnails, social images or product mockups that will be viewed at 1024px on a phone, Q4_K_M is indistinguishable from Q8_0 in a blind comparison. If you are generating a poster with typography, or a portrait that will be cropped to the eyes, the extra bits are visible.

This is also why the "which quant is best" threads go in circles: everyone is evaluating different content. Post a face close-up and Q8_0 wins. Post a wide landscape and nobody can tell.

Installing It in ComfyUI

The path that works, in order:

1. Install the GGUF loader nodes. ComfyUI-GGUF by city96 is the reference implementation — install it like any custom node, then restart ComfyUI so the loaders register.

2. Place the three files.

ComfyUI/models/unet/z_image_turbo-Q4_K_M.gguf          (or models/diffusion_models/)
ComfyUI/models/text_encoders/Qwen3-4B-UD-Q5_K_XL.gguf   (older builds: models/clip/)
ComfyUI/models/vae/ae.safetensors

Directory names have moved between ComfyUI versions. If the loader does not see your file, the folder is wrong, not the file — check whether your build uses unet or diffusion_models, clip or text_encoders.

3. Build the graph. UnetLoaderGGUF (point at the Q4_K_M file) → a GGUF-capable text encoder loader for the Qwen3-4B file → VAELoader for ae.safetensors → model/conditioning/latent/sampler chain. Do not use the standard UNETLoader; it cannot read GGUF.

4. Set the sampler for a Turbo model.

Setting	Value	Why
Steps	9 (8 DiT forwards)	The reference implementation counts 9 including the final step
Guidance / CFG	0	Turbo models are distilled; classifier-free guidance is not used
Resolution	1024×1024	The training-native size
Sampler	A simple/euler-family sampler with a basic scheduler	Anything adaptive fights the distilled schedule

If your output looks flat, grey and over-smoothed, check guidance before you blame the quant. A CFG of 3–7 on a Turbo checkpoint produces exactly that look, and it is the most common setup error I see in shared workflows.

5. Test with one prompt at one resolution before you tune anything. Change one variable at a time: quant, then steps, then resolution. Rebuilding the graph between tests is where people lose an afternoon.

The Speed Reality on a 12GB Card

On a 12GB card with Q8_0, the reference GGUF workflow reports 15 to 30 seconds per image — and that number comes with a 32GB system RAM recommendation, because the model is expected to offload. On a smaller quant that stays resident, you should land at or below that range rather than above it.

Three things move the number more than the quant choice:

1. Whether the text encoder is offloaded. A 4B LLM held on the GPU alongside the UNET is what forces the UNET itself to swap. Some workflows deliberately offload the text encoder after encoding — the prompt is encoded once, so this costs nothing per step and buys back gigabytes.
2. Attention backend. ComfyUI defaults to SDPA. Flash-Attention or Sage-Attention backends cut step time noticeably on Ampere and newer, and the diffusers path exposes the same switch.
3. Resolution. 1536² is 2.25× the pixels of 1024². It is not 2.25× the time, because attention scales worse than linearly — expect closer to 3×.

Getting Under 12GB: The 4GB Route

If your card is small, ComfyUI is not the right container. stable-diffusion.cpp runs Z-Image Turbo GGUF with Q4_K_M on a 4GB GPU, per a documented test in that project's discussions.

Two caveats from the same thread, both worth knowing before you spend an evening on it:

• On ROCm, Q4_K_M produced black images. The same quant worked correctly on the Vulkan backend.
• 4GB is an experiment, not a workflow. Expect single-digit minutes per image and no room for a second model in memory.

Below 4GB, the honest answer is that Z-Image Turbo is not your model. Use a hosted generator for the heavy work and keep the local card for smaller models. For a closer look at how it stacks up against other models, see Krea 2 vs Qwen Image Edit vs Z.

When GGUF Is the Wrong Choice

GGUF is a compatibility format. If you have the VRAM, it is not the best format.

Your situation	Use	Why
8GB card, must run locally	Q4_K_S or Q3_K_M GGUF	Only path that fits
12GB card	Q4_K_M GGUF	Best fit-to-quality point
16GB 40-series card	FP8 checkpoint	Better quality per byte than a K-quant, native tensor-core path
24GB card	BF16 safetensors	No quantisation loss at all
Just need an image	Hosted generator	Zero setup, no driver debugging
Batch of 500 images tonight	Hosted or API	A single local card is the wrong shape for a batch

The FP8 point deserves emphasis: on Ada-generation cards, FP8 is hardware-supported and a 6B model in FP8 is roughly 6GB. That beats Q6_K on both quality and speed at the same memory cost. GGUF exists to serve cards that predate that hardware support.

The Z-Image Turbo FP8 local guide covers that route in detail, including the checkpoint naming that trips people up.

Troubleshooting the Setup

Symptom	Cause	Fix
Black images	ROCm backend with a K-quant	Switch to Vulkan, or to a different quant
Loader does not list the file	Wrong models subfolder for your build	Move between unet / diffusion_models
Extremely slow steps	UNET offloading every step	Drop to Q4_K_M, or offload the text encoder
Out of memory at load	Text encoder + UNET + activations exceed VRAM	Smaller quant, or --lowvram
Scrambled / noisy output	Wrong text encoder type or mismatched VAE	Recheck the clip type and the ae.safetensors file
Looks washed out and flat	Guidance above 0 on a Turbo model	Set guidance to 0
Detail mushy at 1536²	Activation spill on 12GB	Stay at 1024², or upscale after generation

The Bottom Line

Pick the quant by arithmetic, not by reputation. UNET size plus a ~2.9GB text encoder plus a ~0.3GB VAE plus 2GB of runtime overhead is the number that has to fit, and on a 12GB card that means Q4_K_M.

Then set 9 steps and guidance 0, and stop tuning the quant. Most of what people attribute to quantisation damage is a misconfigured Turbo sampler or a text encoder that was quietly offloaded mid-generation. Sort those two out and even Q3_K_M looks better than expected.

If you want to know whether the model suits your work before spending an evening on drivers, the hosted Z-Image generator runs the same model with no download, and the Z-Image prompt guide covers the prompting style it responds to. Once you have a still you like, the free image-to-video generator animates it without a second local install.

FAQ

Which GGUF quant of Z-Image Turbo should I download? Q4_K_M (4.98GB) for a 12GB card, Q4_K_S or Q3_K_M for 8GB, Q8_0 only if you have 16GB or more. The deciding factor is total memory use — UNET plus text encoder plus VAE plus runtime — not the UNET file size on its own.

How much VRAM does Z-Image Turbo GGUF need? About 10GB all-in at 1024×1024 with Q4_K_M: 4.98GB UNET, ~2.9GB Qwen3-4B text encoder, ~0.3GB VAE and ~2GB runtime. A 12GB card is the comfortable floor for ComfyUI. stable-diffusion.cpp can run Q4_K_M on 4GB, slowly.

Is Q8_0 visibly better than Q4_K_M? For texture-heavy content, tight crops and in-frame text, yes. For wide shots, thumbnails and social images viewed at 1024px, most people cannot pick it out. Composition and colour are unaffected at either quant.

Why is my Z-Image Turbo output washed out? Almost always guidance. Turbo models use a guidance scale of 0; anything in the 3–7 range produces the flat, over-smoothed look that gets blamed on the GGUF quant.

How many steps should I use? Nine, which the reference implementation counts as 8 transformer forwards. Going to 20 or 30 steps adds time and changes almost nothing, because the model is distilled for a short schedule.

Can I use LoRAs with a GGUF checkpoint? Yes, through the GGUF loader's LoRA path, but not every LoRA was trained on the Turbo variant — base-model LoRAs applied to Turbo often underperform. The Z-Image image-to-image guide covers which companion models and adapters are worth pairing.

Does Z-Image Turbo GGUF work without a GPU? It runs on CPU, but slowly enough that it is not a workflow. For anything beyond a single test image, use a hosted generator.

Related guides

• Z-Image Turbo FP8 local guide — the better trade on 16GB Ada cards.
• Z-Image Turbo fast generation guide — sampler settings and step counts in depth.
• Z-Image Turbo reference images and consistency — keeping a character stable across a set.
• Z-Image vs Qwen Image comparison — whether this is even the right model for your job.

References

• Hugging Face: jayn7/Z-Image-Turbo-GGUF — quant sizes and diffusers usage
• Hugging Face: z-image-turbo GGUF for ComfyUI — file layout, VRAM and generation time
• Hugging Face: Tongyi-MAI/Z-Image-Turbo model card
• GitHub: city96/ComfyUI-GGUF
• GitHub: stable-diffusion.cpp — running Z-Image on a 4GB GPU
• Reddit r/StableDiffusion: Z-Image Turbo low-VRAM GGUF workflow