Flux Dev vs Flux Schnell VRAM: Same Memory, Fewer Steps

For flux dev vs flux schnell vram, the answer is that they need the same memory. Both are 12-billion-parameter transformers shipped as a 23.8 GB bf16 file, a 17.2 GB fp8 checkpoint and a 12.7 GB Q8_0 GGUF. On a small card pick schnell, because four steps make offloading tolerable; pick dev when image quality matters more.

The failure this prevents is a familiar one. A dev graph runs out of CUDA memory on a 12 GB card, someone swaps in schnell because it is “the light one,” and the run dies at the same loader. Schnell is light on compute, not on memory. If you are already reading a traceback, ComfyUI out of memory errors finds the stage that overflowed. This post is about choosing the variant and the format before that happens.

Does Flux schnell use less VRAM than Flux dev?

No. Black Forest Labs describes both the dev model and the schnell model as a “12 billion parameter rectified flow transformer,” word for word. Same parameter count at the same precision means the same resident weight bytes, and the published files agree to within a rounding error at every format.

Sizes come from the Comfy-Org flux1-dev and flux1-schnell repositories and city96’s dev and schnell GGUF repositories. The fp8 files are single checkpoints that load through ComfyUI’s standard checkpoint loader, per the ComfyUI Flux examples.

Everything around the transformer is shared too. The examples wire both variants to the same CLIP-L and T5-XXL encoder files and the same VAE. T5-XXL is the heavy one: 9.79 GB as t5xxl_fp16 and 4.89 GB as t5xxl_fp8_e4m3fn in the flux_text_encoders repository.

The only forward-pass difference that touches memory is the text cap. The Diffusers Flux documentation says schnell’s max_sequence_length “cannot be more than 256,” while dev has no such limit and defaults to 512. Text tokens share the attention sequence with image tokens, so the cap trims a sliver of activation memory, but at 1024 px the image tokens far outnumber the text. Resolution and batch size move your peak; the variant does not.

The metric that matters: bytes streamed per image

Peak allocated VRAM is a tie, so stop comparing it. When the transformer does not fit, what separates dev from schnell is weight traffic: every denoising step pulls the non-resident layers across PCIe again.

streamed_bytes_per_image ≈ steps × non_resident_weight_bytes

Schnell was trained with latent adversarial diffusion distillation, the method Sauer et al. describe in LADD (arXiv:2403.12015), where the distilled SD3 model generates “using only four unguided sampling steps.” Its model card puts schnell at 1 to 4 steps. The Diffusers docs say dev “takes about 50 sampling steps for good-quality generation.”

Worked arithmetic: if 10 GB of the bf16 transformer will not fit, dev at 50 steps streams about 500 GB of weights per image and schnell at 4 steps streams about 40 GB. Same VRAM ceiling, 12.5 times the bus traffic. That ratio is why schnell feels usable on a small card while dev feels broken. Plenty of ComfyUI dev graphs run fewer than 50 steps; plug in your own count.

Dev does not double its work for guidance either. It is guidance-distilled, so guidance strength is a model input rather than a second, unconditional pass. Keep it that way: sampling_function in comfy/samplers.py skips the negative pass only when cond_scale is 1.0, so a KSampler CFG above 1.0 evaluates the model twice per step. The ComfyUI examples are blunt about the fp8 dev checkpoint: “Make sure you set CFG to 1.0 when using it.”

Which Flux file fits which card?

Run GGUF at 8 to 12 GB, Q8_0 or fp8 weights at 16 GB, fp8 at 24 GB, and the bf16 transformer only at 32 GB; the answer is identical for dev and schnell. These tiers are inferred from published file sizes, not measured, and assume ComfyUI’s default of unloading models to CPU memory after use, per the --highvram help text in cli_args.py, so T5 is evicted before sampling.

The fp8 rows use the weight_dtype setting on the Load Diffusion Model node, which the examples say “will lower the memory usage by half but might reduce quality a tiny bit.” GGUF files need the ComfyUI-GGUF custom node, which adds Unet Loader (GGUF) and reads from ComfyUI/models/unet; ComfyUI Manager is the easy install path.

The official sources disagree on the encoder. The docs.comfy.org Flux tutorial recommends t5xxl_fp16 “when your VRAM is greater than 32GB,” the examples page “if you have more than 32GB ram.” Because the encoder is unloaded to system memory after use, read it as a RAM requirement on any card that offloads. The full-stack budget, activations and decode included, is in ComfyUI GPU requirements.

Wiring it up: measure both on your own card

Skip nvidia-smi for this comparison. The PyTorch CUDA notes explain that memory held by the caching allocator “will still show as if used in nvidia-smi.” Read max_memory_allocated() for tensors and max_memory_reserved() for what the allocator holds, and reset peak stats between runs. The script runs both variants with their model-card settings at matched resolution and offload mode. Dev is gated on Hugging Face, so accept its license and log in first.

import gc
import time

import torch
from diffusers import FluxPipeline

# Model-card inference settings per variant
VARIANTS = {
    "black-forest-labs/FLUX.1-schnell": {
        "num_inference_steps": 4,
        "guidance_scale": 0.0,
        "max_sequence_length": 256,
    },
    "black-forest-labs/FLUX.1-dev": {
        "num_inference_steps": 50,
        "guidance_scale": 3.5,
        "max_sequence_length": 512,
    },
}
GIB = 2**30


def profile(repo: str, settings: dict, offload: str = "sequential") -> dict:
    pipe = FluxPipeline.from_pretrained(repo, torch_dtype=torch.bfloat16)
    if offload == "sequential":
        pipe.enable_sequential_cpu_offload()
    elif offload == "model":
        pipe.enable_model_cpu_offload()
    else:
        pipe.to("cuda")

    torch.cuda.empty_cache()
    torch.cuda.reset_peak_memory_stats()
    start = time.perf_counter()
    pipe(
        "a rack of GPUs in a dim server room, cable labels legible",
        height=1024,
        width=1024,
        generator=torch.Generator("cpu").manual_seed(0),
        **settings,
    )
    torch.cuda.synchronize()
    stats = {
        "repo": repo,
        "steps": settings["num_inference_steps"],
        "peak_allocated_gib": round(torch.cuda.max_memory_allocated() / GIB, 2),
        "peak_reserved_gib": round(torch.cuda.max_memory_reserved() / GIB, 2),
        "wall_seconds": round(time.perf_counter() - start, 1),
    }
    del pipe
    gc.collect()
    torch.cuda.empty_cache()
    return stats


for repo, settings in VARIANTS.items():
    print(profile(repo, settings))

Sequential offload stands in for a small card; Diffusers suggests it “to run on low vram GPUs (i.e. between 4 and 32 GB VRAM).” It still needs system RAM for the whole pipeline. Pass offload="model" or offload="none" for the resident case.

In ComfyUI the knobs are launch flags. Builds running dynamic VRAM ignore --lowvram, whose help text reads “Doesn’t do anything if dynamic vram is enabled,” so these are the levers that still matter:

# Keep 1.5 GB free for the desktop, store T5 weights in fp8
python main.py --reserve-vram 1.5 --fp8_e4m3fn-text-enc

# A/B against the older estimate-based loader
python main.py --disable-dynamic-vram --reserve-vram 1.5 --fp8_e4m3fn-text-enc

What you’ll see

Healthy: at matched resolution and offload mode, peak allocated memory for dev and schnell lands close together, schnell marginally lower from its 256-token cap. Wall-clock is where they split. Fully resident, sampling time tracks step count, because per-step cost is essentially the same model call. Under sequential offload, weight transfer dominates every step, so the 50-versus-4 gap gets more painful, not less.

Unhealthy: dev peaking well above schnell at matched settings means something other than the model differs. The usual suspects are a KSampler CFG above 1.0, a larger batch, or a LoRA stack present only in the dev graph. A run that samples cleanly and then fails at the end is the VAE decode spike, covered in how ComfyUI graphs execute and where VRAM goes. Reserved memory far above allocated points at allocator caching or fragmentation, not model size.

Caveats

• Quantization costs quality on both. The ComfyUI examples note “fp8 degrades the quality a bit.” The saving is identical for either variant, so judge quality at the format you will actually ship.
• LoRAs add weights and are trained per base. Each LoRA is resident memory on top of the tables above, and one trained against dev is not guaranteed to behave the same on schnell. Re-check strengths with the LoRA loader node before swapping variants.
• System RAM is the hidden floor. Diffusers says Flux “requires ~50GB of RAM/VRAM to load all the modeling components.” Offloading moves that requirement into system memory; it does not delete it.

Which one should you run?

Choose by step budget and license, not by VRAM. On 8 to 12 GB cards, run schnell as GGUF: the memory floor matches dev’s, but four steps keep offload traffic and wall-clock bearable. On 16 GB and up, both run resident in fp8 or Q8_0, so pick dev for quality where its non-commercial license fits, and schnell for throughput.

FAQ

how much vram does flux dev need

Flux dev needs a 32 GB card to keep its bf16 transformer fully resident, since that file alone is 23.8 GB before activations. The fp8 checkpoint is 17.2 GB including text encoders, and GGUF quantizations run from 12.7 GB at Q8_0 down to about 4 GB at Q2_K, bringing 8 to 16 GB cards into range.

can flux schnell run on 8gb vram

Yes, Flux schnell fits an 8 GB card with a GGUF quantization such as Q4_K_S at 6.78 GB, the fp8 T5 encoder, and ComfyUI’s default model unloading. Dev fits the same way, but schnell’s four steps keep offload traffic low, which makes it the more practical pick when the card is that small.

is flux schnell faster than flux dev

Yes, Flux schnell is faster per image because it is distilled to run in 1 to 4 steps, while the Diffusers docs put good-quality dev generation at about 50 steps. Per-step cost is essentially the same since the architecture is shared, so sampling time scales with step count, and offloading widens the gap.

can i use flux schnell commercially

Yes, Flux schnell is released under the Apache 2.0 license, which its model card says covers personal, scientific and commercial use. Flux dev ships under the FLUX.1 dev Non-Commercial License, so a commercial deployment usually settles the dev versus schnell question before VRAM does. Read the license text before shipping either.

Related across the network

• How Much VRAM for a 7B Model? Quantization and Context — lmstudioguide.com
• Ollama Not Using GPU: How to Diagnose and Fix It — ollamalab.com