Sawn timber sorted by length on a tall workshop rack, lit by afternoon light through a high window

Organising model files

By the end of this guide you will have one place for every model file you own, a naming scheme that tells you what each file is without opening it, and a sense of how much disk space to set aside. It is for anyone whose downloads folder has become a pile of large files with cryptic names, and for anyone setting up a new machine who would rather not get there. It is one of the how-tos on the guides page.

What this assumes

Model files are large, and you will end up with more of them than you expect, because the same model exists in several sizes and several levels of quantization.

Useful to know first:

  • That a weights file in a format such as GGUF is self contained, while other formats arrive as a folder of several files that must stay together.
  • That LoRA adapters and other fine-tuning outputs are small files that are useless without the base model they were trained against.
  • Roughly how big each file is relative to your VRAM or system memory, which will this model fit in memory? covers.
  • Where each app expects models to live, since most tools have a default directory and some can be pointed elsewhere. See LLM runtimes and image runtimes.

Steps

  1. Pick one root directory for all model files, on the drive with the most free space, and put everything under it. Scattering models across tool specific default folders is the root cause of duplicate downloads.
  2. Split the root by kind first: text, image, video and audio. These are different file types with different sizes and you rarely browse across them.
  3. Inside each, make a folder per model family rather than per file, for example one folder for a Llama family model and another for a Mistral one. See LLM models and image models for how families are usually named.
  4. Keep every quantization of the same model together in that folder. When you want to swap to a smaller variant because something did not fit, you want them side by side rather than scattered by download date.
  5. Name files so the family, the parameter size and the quantization are all visible in the filename, in that order. Most published files already do this. If you rename, keep the published name intact and add to it rather than replacing it, so you can still match the file against its model card. See reading a model card.
  6. Give adapters their own subfolder inside the base model's folder, so a LoRA never drifts away from the weights it needs. Keep multi file model formats in their own folder and never split them up.
  7. Point every app at the shared root instead of copying files into each tool's directory. Where a tool insists on its own location, use a link rather than a second copy.
  8. Do a sweep every so often. Delete the quantizations you tried once and rejected, delete anything superseded by a model you now prefer, and keep a plain text note of what you deliberately removed so you do not re-download it out of curiosity.

Planning disk space

Budget by counting variants, not models. A single model you are actually using often means two or three files on disk while you work out which quantization suits your machine, and image work adds adapters and supporting files on top of the base weights.

Two habits keep this under control: keep model storage on a drive you can expand or replace without rebuilding the machine, and treat the download folder as a staging area that gets emptied into the root the same day. If you run disconnected, storage planning matters more, because re-fetching is not a quick fix. See keeping everything offline.

Common mistakes

  • Letting each tool keep its own copy of the same weights. Nothing warns you, and the duplicates are the largest files on the disk.
  • Renaming files to something short and friendly. Six months later there is no way to tell which quantization you are holding.
  • Storing quantizations of one model in separate places by download date, so comparing them means hunting.
  • Separating a LoRA or other adapter from its base model, leaving a small file nobody can use.
  • Filling the system drive with weights. Performance suffers across the whole machine long before the disk is actually full.

Related