How much storage do local AI models need on a Mac?

How much storage for a local LLM comes down to one number: the size of the model's file. A model takes the same space on your disk as its download, from under 1 GB for the smallest to several hundred gigabytes for the largest.

Popular models with 8 billion parameters are about 5 GB each in their usual 4-bit form; models with 70 billion are about 43 GB.

You can work the size out before you download anything. Multiply the number of parameters by the bits stored for each one, divide by eight, and you have the size in bytes, usually within a few percent. This post shows that arithmetic and checks it against real sizes from model libraries.

Two more things decide how much disk you really need. Collections grow, because most people try several models, often in more than one app, and nothing is removed until they remove it. And memory, not storage, decides which models your Mac can run, so a bigger disk never makes a bigger model usable.

As a first sketch: a handful of small models fits in 10 to 20 GB. Add a couple of models around 30 billion parameters and you're past 50 GB. A single 70B model adds 43 GB on its own.

How much storage for a local LLM, by model size

Model libraries group models by their parameter count, the number in their name, and that number predicts the file size better than anything else. A 4-bit build takes a little over half a gigabyte for each billion parameters.

What do the numbers in a model's name mean?

Names pack in most of what decides the size:

• 8b, 70b, 120b: the parameter count, in billions. This is the main driver of size.
• a3b, a22b: the active parameters of a mixture-of-experts model, used for each word it writes. They decide speed, not storage.
• q4_K_M, Q8_0, fp16: how precisely each parameter is stored, in llama.cpp's GGUF format. The number is roughly the bits per parameter.
• 4bit, 8bit, bf16: the same idea in Apple's MLX format and in original releases.

A quick reference by size class

Size class	Examples	4-bit download	16-bit original
1B to 4B	Llama 3.2 3B, Gemma 3 4B	2.0 to 3.4 GB	Gemma 3 4B: 8.6 GB
7B to 9B	Llama 3.1 8B, Qwen3 8B	4.9 to 5.2 GB	16 GB
12B to 14B	Gemma 3 12B, Qwen3 14B	8.2 to 9.3 GB	Gemma 3 12B: 24 GB
20B to 32B	gpt-oss 20B, Gemma 3 27B, DeepSeek-R1 32B	14 to 20 GB	Gemma 3 27B: 55 GB
70B	Llama 3.1 70B, DeepSeek-R1 70B	43 GB	141 GB
100B to 250B	gpt-oss 120B, Qwen3 235B	65 to 142 GB	Rarely run locally
400B and up	Llama 3.1 405B, DeepSeek-R1 671B	243 to 404 GB	812 GB for Llama 3.1 405B

All the sizes come from Ollama's library, which lists each build's size before you download it. LM Studio and Hugging Face show the same kinds of numbers for the same models.

• Qwen3 0.6B0.5 GB
• Llama 3.2 3B2 GB
• Llama 3.1 8B4.9 GB
• Qwen3 14B9.3 GB
• gpt-oss 20B14 GB
• Gemma 3 27B17 GB
• DeepSeek-R1 32B20 GB
• Llama 3.1 70B43 GB
• gpt-oss 120B65 GB
• Qwen3 235B142 GB

Sizes Ollama's library lists for each model's default tag in October 2026, mostly 4-bit builds. Other quantizations of the same models are separate downloads, larger or smaller.

Why does the curve look so steep?

Because size grows in step with parameters. Ten times the parameters means about ten times the file, at the same precision. The jump from an 8B model to a 70B one is a jump from 5 GB to 43 GB, and every step beyond that adds tens or hundreds of gigabytes.

The arithmetic: parameters, bits and file size

A model file is, almost entirely, a long list of numbers. Once you know how many numbers there are and how many bits each one takes, the size follows.

What is a parameter?

A parameter is one of the numbers a model learned in training. A model with 8 billion parameters stores 8 billion of them, and each one has to be on your disk, then in memory, for the model to answer anything.

The formula

Size in bytes equals the number of parameters, times the bits per parameter, divided by eight, because there are eight bits in a byte. So a billion parameters at 8 bits each is 1 GB. At 16 bits it's 2 GB, and at 4 bits half a gigabyte.

A worked example: Llama 3.1 8B

Ollama's page for this model lists 8.03 billion parameters. llama.cpp's documentation lists the bits per weight its formats really use for this model, and the sums land on Ollama's own sizes:

1. 16-bit original: 8.03 billion × 16 ÷ 8 = 16.1 GB. Ollama lists the fp16 build at 16 GB.
2. Q8_0, at 8.50 bits per weight: 8.03 billion × 8.5 ÷ 8 = 8.5 GB. Ollama lists 8.5 GB.
3. Q4_K_M, at 4.89 bits per weight: 8.03 billion × 4.89 ÷ 8 = 4.9 GB. Ollama lists 4.9 GB, and that's its default build.

The same sum for a 70B model

Ollama lists Llama 3.1 70B at 70.6 billion parameters. The same three sums give 141 GB at 16 bits, 75 GB at Q8_0 and 43.2 GB at Q4_K_M. Ollama lists 141 GB, 75 GB and 43 GB.

Llama 3.1	Parameters	Q4_K_M, 4.89 bits	Q8_0, 8.50 bits	16-bit
8B	8.03 billion	4.9 GB	8.5 GB	16 GB
70B	70.6 billion	43 GB	75 GB	141 GB
405B	About 406 billion	243 GB	431 GB	812 GB

The 405B row uses Ollama's listed sizes. Ollama doesn't show its exact count on the tags page, but its 16-bit build of 812 GB implies about 406 billion parameters.

Why aren't bits per weight whole numbers?

Because quantized formats store a little extra. Weights are grouped in small blocks, and each block keeps a scale, so the values can be stored in fewer bits and stretched back when the model runs. Those scales add a fraction of a bit for every weight.

Apple's MLX shows the cost plainly. Its default 4-bit setting groups 64 weights and keeps a scale and a bias for each group, in the same type as the original weights, usually 16 bits. That's 32 extra bits for 64 weights, half a bit each, so a 4-bit MLX model stores about 4.5 bits per weight.

Why real files differ by a few percent

Not every part of a model is stored at the same precision. Formats such as Q4_K_M keep some layers at higher precision than others, and some models add parts that aren't counted in the headline parameters, such as an image encoder.

So treat the sum as a close estimate. For Llama 3.1 405B at Q4_K_M, it gives about 248 GB; Ollama lists 243 GB, and llama.cpp's own documentation lists 249.1 GB. Both are within a few percent of the sum.

Gigabytes and gibibytes

Finder and Ollama count a gigabyte as a billion bytes, as Apple's note on measuring storage explains. Some tools, including llama.cpp's tables, count in gibibytes of 1,073,741,824 bytes. The 4.58 GiB llama.cpp lists for Llama 3.1 8B at Q4_K_M is the same file as Ollama's 4.9 GB.

Quantization: how much space it saves, and what it costs

Quantization stores each parameter in fewer bits than the original release. It's the reason a model trained at 16 bits can fit on a laptop, and the main choice you make about size, apart from the model itself.

Common levels side by side

Here is Llama 3.1 at each level Ollama offers, with the bits per weight from llama.cpp's documentation:

Build	Bits per weight	8B size	70B size
Q2_K	3.16	3.2 GB	26 GB
Q3_K_M	4.00	4.0 GB	34 GB
Q4_K_M	4.89	4.9 GB	43 GB
Q5_K_M	5.70	5.7 GB	50 GB
Q6_K	6.56	6.6 GB	58 GB
Q8_0	8.50	8.5 GB	75 GB
fp16	16.00	16 GB	141 GB

The 16-bit original is more than three times the default 4-bit build. Even the smallest build of the 70B model, at 26 GB, is five times the default 8B one.

What do you give up with fewer bits?

Accuracy, gradually. Each step down rounds the parameters more coarsely, and the smallest builds lose the most. That's why libraries default to a middle level: Ollama's default tag for Llama 3.1 is the Q4_K_M build.

Speed doesn't follow size simply, either. llama.cpp's own measurements for Llama 3.1 8B show some smaller builds running slower than larger ones, depending on the format and the hardware.

Is a smaller build of a big model better than a bigger build of a small one?

It depends on the models and the task, and no library gives a rule for it. What the sizes do show is that the choice is close in disk terms: Qwen3 14B at its default build is 9.3 GB, while Llama 3.1 8B at Q8_0 is 8.5 GB. Try both, then keep one.

MLX and GGUF at the same precision

At 4 bits, the two formats come out close. MLX's 4-bit setting stores about 4.5 bits per weight and Q4_K_M about 4.9, so an MLX model is usually a little smaller. LM Studio offers both formats for many models, which makes it easy to download both and keep both.

Sizes beyond the parameter count

A few kinds of model break the simple rule, or seem to. Knowing them avoids surprises in both directions.

Mixture-of-experts models: total versus active

A mixture-of-experts model has many parameters but uses only some of them for each word. OpenAI's model card for gpt-oss-120b lists 117 billion parameters with 5.1 billion active, and gpt-oss-20b 21 billion with 3.6 billion active.

Storage follows the total, because every expert has to be on disk. Ollama lists gpt-oss 120B at 65 GB, Qwen3 30B-A3B at 19 GB and Qwen3 235B-A22B at 142 GB. The small active count makes them faster than their size suggests, not smaller.

Why is gpt-oss 120B only 65 GB?

Because most of it is stored in a 4-bit format. Ollama's page says the mixture-of-experts weights, over 90% of the parameters, use MXFP4 at 4.25 bits each. 117 billion × 4.25 ÷ 8 is about 62 GB, and the rest of the model makes up the difference.

Embedding models and vision parts

Embedding models, used to search documents rather than to chat, are small. Ollama lists nomic-embed-text at 274 MB. Models that read images carry an extra part for vision, which in llama.cpp's format is a separate projector file next to the model.

Does a longer context window make the file bigger?

No. Every build of Llama 3.1 in Ollama's library supports the same 128K context, and the sizes differ only by quantization. Context costs memory while the model runs, not disk space.

Original releases on Hugging Face

Publishers usually release models at 16 bits, two bytes per parameter. An 8B original is about 16 GB, a 70B original about 141 GB. Libraries such as Hugging Face's download those originals into a cache, and programs that quantize or convert a model start from them.

Memory versus storage: what decides what you can run

Storage decides how many models you can keep. Memory decides which one you can run. They're easy to confuse, because the same number, the model's size, governs both.

The file sets the memory floor

To answer, a model's weights are loaded into memory. llama.cpp's documentation puts it plainly: models are fully loaded, so you need the disk space to store them and the memory to load them, and the two requirements are the same.

On a Mac with Apple silicon, memory is shared between the processor and the graphics, so the model has to fit in that one pool alongside macOS and your apps. The post on memory vs storage explains the difference in full.

The conversation adds memory, not storage

A conversation's context takes memory on top of the model. LM Studio recommends 16 GB of memory or more on a Mac, and says 8 GB Macs may still work with smaller models and modest context sizes.

None of that touches the disk. A long chat with a 5 GB model still keeps a 5 GB file on the disk.

A rough check against your Mac's memory

Choose Apple menu › About This Mac to see your Mac's memory, then compare it with the file size. The file must fit with room left for macOS, your apps and the conversation:

Memory	Models that leave room to spare	Why
8 GB	1B to 4B models, up to about 3 GB	LM Studio advises smaller models on 8 GB Macs
16 GB	7B to 9B models, about 5 GB	LM Studio's recommended minimum
32 GB	Up to about 20 GB, such as Gemma 3 27B	The file plus macOS and context
64 GB	70B models at 4 bits, 43 GB	The file alone is 43 GB
128 GB	gpt-oss 120B, 65 GB	OpenAI designed it for an 80 GB GPU

This table is arithmetic, not a guarantee. OpenAI says gpt-oss-20b runs within 16 GB of memory, for example, which is tight on a 16 GB Mac that's also running other apps.

What happens when a model doesn't fit?

Some apps warn you first, as LM Studio does when you download. If a model loads anyway, macOS moves other data into swap files on the startup disk, and everything slows down.

That's the one place memory spills into storage. Swap files go away after a restart, but a nearly full disk leaves less room for them.

Does a loaded model use disk space while it's idle?

No. Ollama, for example, keeps a model in memory for five minutes after you use it, so the next answer starts faster, then unloads it. That memory comes back when the model unloads, and the file on the disk never changes size.

Does a bigger disk let you run bigger models?

No. A 2 TB Mac with 16 GB of memory can store a 43 GB model but can't run it well. When you plan, decide the largest model you want to run first, which sets the memory, then decide how many to keep, which sets the storage.

How many models people keep, and why it adds up

Few people download one model and stop. Trying models is how you find the one that suits you, and every one you try stays on your disk until you remove it.

The same model in several apps

Each tool keeps its own copy, in its own format and folder. Ollama, LM Studio and Hugging Face's libraries don't share files, so trying one model in all three stores it three times.

The posts on deleting Ollama models, the LM Studio models folder and the Hugging Face cache show where each copy lives and how to remove it.

Several builds of one model

Comparing builds is a common reason for doubles. Keep Llama 3.1 8B at Q4_K_M and Q8_0 and you hold 13.4 GB for one model. The builds share nothing, because every weight is stored differently.

Revisions in the Hugging Face cache

When a publisher updates a model, Hugging Face's libraries download the new files next to the old ones, and remove nothing by themselves. A model you've used for months can be in the cache more than once.

What a collection looks like

On Macs where someone uses local models regularly, totals of 20 GB to 150 GB or more are typical. Here's how a collection gets there, with sizes from Ollama's library:

Collection	Models	Total
One everyday model	Llama 3.1 8B and nomic-embed-text	About 5.2 GB
A few to compare	Llama 3.2 3B, Llama 3.1 8B, Qwen3 14B, Gemma 3 27B	About 33 GB
An experimenter's	The four above, plus Llama 3.1 70B and an 8-bit 8B	About 85 GB
Large mixture-of-experts	gpt-oss 120B and Qwen3 235B	About 207 GB
The same model in three apps	Llama 3.1 8B in Ollama, LM Studio and Hugging Face	15 GB or more

The last row is the easiest to miss. The 8B model is about 5 GB in each tool's 4-bit format, and the Hugging Face copy is often the 16 GB original.

Checking sizes before and after you download

The arithmetic is a good check, but every library shows the real size before you commit. Look there first, then keep an eye on what's already on your disk.

On Ollama's library pages

Each model's page lists its main tags with their sizes, and the tags page lists every build: each quantization, each text or instruct version, each size class. Llama 3.1 alone has 93 tags, from 3.2 GB to 812 GB.

The default tag usually points to a 4-bit build, Q4_K_M for Llama 3.1. A longer tag is a deliberate choice of a different build, and a separate download of its full size.

In LM Studio's Discover tab

Select a model, and each download option lists its size, with the Download button repeating it. The same screen says whether the model fits in your Mac's graphics memory, which answers the memory question before the storage one.

On Hugging Face

A model's page has a Files and versions tab that lists every file with its size. A repository of GGUF files often holds a dozen quantizations side by side, so the repository's total isn't what you'd download: tools such as LM Studio and llama.cpp fetch one build.

Original releases are different. All their weight files together make up one model, at about 2 GB for every billion parameters.

What's already on your Mac

In Finder, choose Go › Go to Folder, type a model folder's path and press Return, then choose File › Get Info to see its total. Do it for each tool you've used:

Tool	Default models folder	What you'll find
Ollama	~/.ollama/models	Shared layers named by hash
LM Studio	~/.lmstudio/models	A folder for each publisher and model
Hugging Face libraries	~/.cache/huggingface/hub	A folder for each repository, with its revisions
llama.cpp	~/Library/Caches/llama.cpp	Files it downloaded from a web address

Add the totals together for your collection's real size. If a total is larger than you expected, the posts linked above show what's inside each folder.

Free space you need beyond the models

A model's size isn't the only space it needs. Downloading, converting and backing up all take more, at least for a while.

Downloading needs the whole size free

A download writes the full file to your disk, so you need its size free before it starts. A download that stops part-way leaves a partial file behind until the tool finishes it or clears it away, which Ollama does by itself after a while.

Converting a model needs room for every step

llama.cpp's documentation warns that larger models need enough disk space for all the intermediate files. Making your own 4-bit build of an 8B model means holding the 16 GB original, a converted 16-bit file of about the same size and the 4.9 GB result, about 37 GB at once.

Once the result works, the original and the intermediate file are the parts to remove.

Time Machine backs models up

Time Machine copies model folders like any other files, so a 100 GB collection adds 100 GB to your backup disk. Models can be downloaded again, so they're good candidates to leave out:

1. Choose Apple menu › System Settings, click General, then Time Machine.
2. Click Options, then click the Add button and choose the folders to exclude. You can also drag folders into the list.
3. Click Done.

Apple notes that excluded items still appear in Time Machine's local snapshots on your Mac. Models you made or imported yourself are the exception: back those up, because nothing can download them again.

Leave room for everything else

macOS updates, Apple Intelligence's own models of up to 8 or 14 GB, and swap files all need free space too. A disk filled with models leaves none for them, and a macOS update can fail for want of a few gigabytes.

Planning a disk for local models

Put the pieces together and the plan follows: choose the largest model you'll run, add the others you'll keep, then leave room to download, convert and update.

On a 256 GB Mac

macOS, your apps and your files usually take a large share of a 256 GB disk already. One or two models of up to about 5 GB each fit comfortably. A 43 GB 70B model is about a sixth of the whole disk.

Keep one everyday model and remove experiments as soon as you've decided, or keep models on an external drive.

On a 512 GB Mac

There's room for several small and medium models, roughly the "few to compare" collection of 33 GB, with space left for everything else. A 70B model fits too, but an experimenter's 85 GB collection takes a sixth of the disk.

On 1 TB and up

A 1 TB disk can hold a large collection, including a 70B model in two builds, without crowding your files. The limit then is usually memory, not storage: the models you can store outnumber the ones you can run.

A worked plan, step by step

Here's the whole method on one example, a Mac with 32 GB of memory:

1. Pick the largest model you'll run. With 32 GB of memory, a file of about 20 GB leaves room for macOS and the conversation. Gemma 3 27B, at 17 GB, fits.
2. Add the others you'll keep. Say an 8B model for quick questions and a 14B model for code: 4.9 GB and 9.3 GB.
3. Add room for trying new ones. One more download of the largest size, 17 GB, covers trying a model before you remove another.
4. Add room for any conversions. If you make your own builds, allow twice the model's 16-bit size while you work: the original plus a converted copy. For an 8B model, that's about 32 GB.
5. Total it. Without conversions, 17 + 4.9 + 9.3 + 17 comes to about 48 GB of space to set aside for local models.

On a 512 GB Mac that's under a tenth of the disk. On a 256 GB Mac it's nearly a fifth, which is when an external drive or a smaller collection starts to make sense.

Keeping models on an external drive

Models are read from the disk only when they load, then they run from memory. A slower drive makes loading slower, not answers. Each tool has its own way to move its folder:

Tool	Where to change the folder	Notes
Ollama	Model location in Ollama's settings	Existing models don't move by themselves
LM Studio	Models Directory in My Models	Copy the publisher folders first
Hugging Face libraries	An environment variable; no settings window	Every program that uses the cache must see it
MLX apps built on the Hugging Face cache	Follow the Hugging Face setting	Same cache, same rules

Keep the drive connected. Ollama, for one, falls back to its default folder on your startup disk when the drive is missing at startup, and new downloads then land there.

Mistakes to avoid when planning

• Buying storage to run larger models. Memory decides that. Storage decides how many you keep.
• Counting only the 4-bit size. Originals are more than three times larger, and a second build of the same model is another full copy.
• Forgetting the copies in other apps. The same model in three tools is three downloads.
• Filling the disk to the last gigabyte. Swap, updates and the next download all need room.
• Pasting cleanup commands from a web page. Each tool removes models in its own app, as the posts linked above explain.

How the app does it

Select a model folder in the map, the app's home screen, and the inspector says what it is, which tool made it and how that tool removes it. The explanations come from the catalog, written and checked by hand, with its sources.

• ~/.ollama/models

  Ollama models

  Language models you've pulled or created with Ollama, stored as shared layers.

  Review first · Explained only: never removed

• ~/.lmstudio/models

  LM Studio models

  Language models downloaded or imported in LM Studio, in a folder for each publisher and model.

  Review first · Moves it to the Trash

• ~/.cache/huggingface/hub

  Hugging Face cache

  Models and datasets downloaded from Hugging Face, shared by every library and tool that uses them.

  Review first · Moves it to the Trash

• ~/Library/Caches/llama.cpp

  llama.cpp model cache

  Model files llama.cpp downloaded from a web address or Docker Hub, and Hugging Face models saved by older versions.

  Usually safe · Moves it to the Trash

Ollama's, LM Studio's and Hugging Face's model folders are Review first: they never start checked and never count toward the safe-to-remove total, because each is a large download and some may hold models you made or imported.

llama.cpp's download cache is Usually safe, since what's in it can be downloaded again. Ollama's models are explained but never removed by the app, because only Ollama knows which layers each model still needs.

Hard links and APFS clones count once, so a model shared between folders isn't counted twice.

What Changed shows which places grew each day, and an alert can tell you when something grows by 10 GB or more in a day, such as a new large model. Both are PRO, along with moving the folders the catalog allows to the Trash. Seeing what your models take, and where, is free.