The right model and workflow beat a larger checkpoint that spends every iteration crossing PCIe.
Eight gigabytes of VRAM is still enough for useful local image generation. It is not enough to treat every new image model as one checkpoint that should remain on the GPU at full precision. The difference is not whether a workflow can produce one image. The difference is whether it can produce the tenth while you still care about changing the prompt.
Image pipelines make the memory hierarchy visible. The denoiser or diffusion transformer holds most of the weights, but the text encoder, VAE, conditioning models, intermediate latents, and workspace for attention also need somewhere to live. They do not all peak at the same stage. A pipeline can encode the prompt, move that component aside, run the denoiser repeatedly, then bring in the VAE for the final decode. Eight gigabytes works when the runtime treats those stages as a schedule instead of demanding permanent residency for everything.
The first tier is still SDXL. Stability AI’s official repository carries a 6.94 GB single-file checkpoint and separate text-encoder, UNet, and VAE components (SDXL model repository). File size is not peak VRAM, and the full repository is much larger because it contains several formats and components. The practical advantage comes from maturity: ComfyUI workflows, LoRAs, ControlNets, inpainting paths, and upscalers have had years to settle around a model class that an 8GB card can use without turning every prompt into a memory-placement experiment.
That maturity matters more than a leaderboard when the job is iterative. A fast SDXL-class workflow can generate several candidates, accept a mask edit, and run an upscale before a larger model finishes shuttling its next block of weights. The result may lose to a newer model on instruction following, embedded text, or difficult composition. It can still win the working session by letting the operator inspect more ideas under the same time budget.
FLUX.2 Klein 4B is the next tier, and its published memory numbers show why model names are not enough. Black Forest Labs describes the distilled 4B model as a generation-and-editing model under Apache 2.0 and says it fits in roughly 8GB in the official inference repository (FLUX.2 repository). Its launch article says roughly 13GB, while ComfyUI reports 8.4GB for a distilled 4B workflow and 9.2GB for the base model on an RTX 5090 (BFL launch post, ComfyUI workflow notes). Those are project-reported configurations, not interchangeable guarantees.
An 8GB owner should read that disagreement as a test plan. Start with the distilled four-step model, one image, a modest canvas, and enough free VRAM for activations. Record peak allocation, first and warm generation time, and whether the text encoder and VAE stayed on the card or moved. The base model is a different workload. A model that needs more steps and more transfer can preserve flexibility for fine-tuning while being the worse interactive choice.
Z-Image-Turbo moves further into stretch territory. Its official card describes a 6B distilled model that uses eight model evaluations and fits comfortably within 16GB of consumer VRAM (Z-Image-Turbo model card). That is a strong 16GB claim and no 8GB claim at all. Running it on a smaller card means changing the configuration through lower-precision weights, component offload, or both. The low step count may keep the resulting workflow tolerable, but only an end-to-end measurement can show whether transfers consumed the speed the distillation was supposed to buy.
Qwen Image and Qwen Image Edit belong at the far end of the ladder. Qwen Image Edit is built on a 20B model and adds both semantic and appearance editing paths (Qwen Image Edit model card). ComfyUI’s native Qwen Image guide lists a 40.9 GB BF16 diffusion model, a 20.4 GB FP8 version, a separate Qwen 2.5 VL 7B text encoder, and a VAE. On a 24GB RTX 4090D, its project measurements used 86 percent of VRAM and took about 34 to 94 seconds depending on the variant and whether the run was warm (ComfyUI Qwen Image guide). That is not an 8GB resident workflow waiting for one clever flag.
It can still run as a systems experiment. GGUF shrinks diffusion-transformer weights below FP8, and offload can keep only the active blocks on the GPU. The trade is a larger compatibility surface and repeated dequantization or transfer. ComfyUI-GGUF remains a third-party custom-node project that calls itself work in progress, with experimental LoRA support and model-specific loaders (ComfyUI-GGUF). A successful image proves fit for that prompt, resolution, sampler, and graph revision. It does not prove that edits remain faithful or that the next custom-node update will preserve the path.
FP8 and GGUF also solve different parts of the problem. FP8 can store transformer weights at eight bits while supported kernels still compute efficiently, but hardware and operator support determine whether it saves time or merely disk space. GGUF offers more aggressive quantization for DiT weights and some text encoders, often at the cost of dequantization work and another dependency. Neither format shrinks the VAE’s activation peak, the latent created by a larger canvas, or the memory held by an extra ControlNet.
Offload should follow component boundaries before it falls back to layer-by-layer traffic. Hugging Face documents model offload as keeping the active text encoder, denoiser, or VAE on the GPU until that component finishes, which reduces communication compared with sequential CPU offload. Sequential offload saves more memory and can be extremely slow because submodules move repeatedly between CPU and GPU (Diffusers memory guide). If the denoiser runs twenty or fifty steps, paying that transfer cost inside every step can turn a fit result into a bad workflow.
Resolution is the other honest lever. Generate the composition at the model’s normal working size, choose the result, then upscale or refine the selected image. Starting every candidate at the final delivery resolution multiplies latent and attention work before the idea has earned it. VAE tiling reduces peak decode memory by processing overlapping regions, with a documented risk of tone variation between tiles. It is a way to finish a chosen large image, not a reason to make every preview large.
The useful 8GB test has three verdicts. Fit means the complete graph finishes twice at the intended resolution without exhausting GPU or system memory. Speed means a cold run, warm prompt change, edit, and final upscale stay inside a declared working-session budget. Quality means the chosen precision and acceleration path preserve the details the job needs, including faces, small objects, prompt adherence, and edit locality. Keep the seed and graph fixed while changing one memory decision at a time.
The strongest model is not always the strongest workflow. SDXL remains the default when iteration speed and mature controls matter most. FLUX.2 Klein 4B deserves a direct test near the edge of the card. Z-Image-Turbo becomes a quantized or offloaded stretch. Qwen Image/Edit belongs in the experimental lane unless its editing quality is valuable enough to pay for the transfers.
Eight gigabytes is not dead. Treating it like unlimited memory is what kills the workflow.
If this was useful, forward it to one engineer who needs less noise in their feed.