A model is four kinds of file, and mixing them up wastes an evening

The inventory on disk

People say “I downloaded the model” as if a model were one thing. Locally it is a small family of files, and knowing which is which saves you the evening where everything loads and every image comes out as grey porridge.

The checkpoint is the model proper: the denoising network plus, usually, the text encoder and VAE bundled in. It is the big file.

• SD 1.5 checkpoint: 2 to 4 GB
• SDXL checkpoint: about 6.6 GB
• FLUX dev in bf16: about 23 GB; the fp8 version about 11 GB; a GGUF Q4 version about 6.5 GB

The VAE is the decoder that turns the small latent image into pixels. Around 160 to 330 MB. Most checkpoints have one baked in. You only need a separate one when a checkpoint shipped with a broken or “pruned” VAE, and the symptom is unmistakable: correct composition, correct colours in the thumbnail preview, and a final image that is washed out, purple-tinged or covered in noise. Swap the VAE and it is fixed. This is the single most common “the model is broken” that is not.

A LoRA is a small set of weight adjustments layered onto a checkpoint: a character, a style, a concept. 20 to 250 MB. A LoRA is built for a specific base: an SD 1.5 LoRA on an SDXL checkpoint either errors or does nothing useful. The mismatch is the second most common wasted evening.

A textual inversion or embedding is smaller still, often 4 to 80 KB. It teaches the text encoder one new word rather than changing the model. Mostly used now for negative-prompt bundles.

There are also ControlNet models (1.4 GB each for SD 1.5, up to 2.5 GB for SDXL) and IP-Adapter files. These are conditioning modules, again base-specific.

safetensors, not ckpt

You will see two extensions. A .ckpt file is a Python pickle, which means loading it executes code contained in the file. That is not a theoretical risk; malicious checkpoints have been distributed. A .safetensors file is a plain tensor container that cannot execute anything.

The rule is simple: download safetensors. If only a .ckpt exists and you need it, convert it in an isolated environment, or find another copy. No workflow is worth handing a stranger a shell on your machine.

Where they go

Folder layouts differ between interfaces, but the shape is the same everywhere, and this is roughly what a Forge or A1111 install looks like:

models/
  Stable-diffusion/    <- checkpoints (.safetensors)
  VAE/                 <- standalone VAE files
  Lora/                <- LoRAs
  embeddings/          <- textual inversions
  ControlNet/          <- control models

ComfyUI uses models/checkpoints, models/loras and so on, and has an extra_model_paths.yaml that lets a second interface read the same folders. Set that up on day one if you plan to use more than one front end. Storing a 6.6 GB checkpoint twice is how a disk fills.

The limitation worth stating

A LoRA is trained against a specific checkpoint, but it is usually used on a different one: someone trains a character on base SDXL and you apply it to a heavily fine-tuned photographic checkpoint. It often works, which is why people do it. It also frequently degrades: colours shift, contrast rises, the face drifts toward the training checkpoint’s house style.

The mechanism is that a LoRA encodes a difference from a particular set of weights. Applied to weights that have already moved, the difference lands somewhere else. This is why the same LoRA at strength 0.8 looks right on one checkpoint and plasticky on another, and why the answer is to lower the strength to 0.5–0.6 rather than to conclude the LoRA is bad.

Merges, and why your favourite checkpoint has no history

A large share of the checkpoints people actually use are merges: two or more models averaged together, sometimes with a LoRA baked in, often by somebody who did it by feel in an afternoon. Merging is legitimate and some merges are excellent. It has three consequences you should hold in mind.

The first is that a merge inherits every licence in its ancestry, and the upload page frequently does not say what those were. If you are working commercially, a merge with an unclear lineage is a risk you are carrying without knowing its size.

The second is that merges drift toward a house look. Average several photographic checkpoints and you get the same glossy, slightly over-lit, slightly symmetrical face that everybody’s images have. If your output looks generically “AI”, the checkpoint is often more responsible than the prompt.

The third is practical: merges frequently ship a broken or non-standard VAE, which is why the grey-porridge and purple-cast problems cluster on community downloads rather than on official base models.

What to actually download first

Start with one official base model and one well-documented fine-tune, and nothing else. A first shelf that works:

• One base checkpoint appropriate to your VRAM.
• Its matching official VAE, kept separately so you can swap it in when a merge misbehaves.
• One upscaler model, a few tens of megabytes.

Add a LoRA only when you have a specific job for it. The usual failure of a new setup is fifteen checkpoints, ninety LoRAs, a full disk and no finished images.