How much disk space do Stable Diffusion models use?

There is no single Stable Diffusion model size. Official model files range across several gigabytes, and a working library grows beyond the main checkpoint through alternate precisions, fine-tunes, VAEs, text encoders, ControlNets, LoRAs and outputs. Measure the files your runtime actually loads; do not plan capacity from a generic number.

Exact examples, checked 09 August 2026

These file sizes come from the official Hugging Face repository metadata on the date above. They are examples, not a universal range:

The two SD 1.5 files already show why “the model is about four gigabytes” can be misleading. They are different published artifacts with different contents. Repository contents can also change, so retain the filename, revision and checksum beside any capacity record that matters.

The checkpoint is not the whole library

A practical image-generation setup may include several categories:

• base checkpoints and full fine-tunes;
• separate diffusion models, text encoders and VAEs;
• ControlNets, IP-Adapter models and upscalers;
• LoRA adapters, embeddings and other small specialisations;
• duplicate copies across ComfyUI, another UI and a download cache;
• training checkpoints, previews and generated outputs.

Each category grows differently. One additional base can cost gigabytes immediately; hundreds of adapters accumulate gradually; output directories expand with every session. A disk-space plan that measures only models/checkpoints misses the library that supports it.

Measure logical size and physical use

Start with the active paths rather than searching the whole disk for .safetensors. In ComfyUI, inventory native and extra model paths. In other runtimes, check their configured stores and caches. Then measure each type folder and note whether links or filesystem deduplication affect physical space.

# macOS or Linux examples
du -sh /path/to/models/*
du -sh /path/to/outputs

# Show apparent size when sparse files or links matter
du -sh --apparent-size /path/to/models/*

Finder, Explorer, du and cloud dashboards may report decimal GB, binary GiB, logical size or allocated size. For planning, record which one you used. For identity, rely on exact byte counts and checksums.

Why duplicate detection beats format conversion first

Before quantizing or deleting, find byte-identical copies across runtimes. Removing a proven redundant working copy preserves the model exactly. Converting a checkpoint to lower precision creates a different artifact and may save more space, but it changes the recovery question.

A SafeTensors file is already a structured tensor container; putting it in ZIP often yields disappointing savings for the effort. Quantization can reduce a derived inference copy, but it does not provide byte-exact recovery of the higher-precision source. See SafeTensors storage vs. quantization for that boundary.

A practical order for reclaiming space

1. Outputs you intentionally exported elsewhere: confirm the copy, then clear local duplicates.
2. Byte-identical model copies: redirect runtimes to one working library before removing duplicates.
3. Abandoned training intermediates: keep the final, selected milestones and resume state you truly need.
4. Unused derived variants: retain source plus reproducible recipe, or keep the exact deployment artifact when conversion is expensive.
5. Rare or private originals: archive and test restore before they become cleanup candidates.

How much headroom should you leave?

Plan for temporary overlap. A safe migration or restore may require the source, archive and restored copy to coexist. Training creates additional checkpoints; model downloads may use temporary files; application updates and filesystem behaviour need room too. A disk that is “exactly large enough” for today’s visible library is already undersized for a verified recovery workflow.

Review the library by model family rather than waiting for the operating system’s low-space warning. The retention checklist turns that review into explicit keep, reproduce, archive and discard decisions.

Keep the model family; make redundant copies optional

Tensor Archive is for selected local tensor families you want to retain exactly. Archive, verify and restore one family before reclaiming a duplicate working copy. It does not quantize the model, alter its weights or promise that every surrounding runtime dependency has been captured.

Apply this to your runtime

For ComfyUI, follow the full model-library backup and restore workflow. If adapters dominate the clutter, use the LoRA disk-space guide and keep the exact base relationships intact.