The useful answer is not the biggest model your computer can technically load. It is the model that leaves enough room for the operating system, context, documents, and normal work while still responding fast enough to use every day. Enter your hardware in the checker, start with the recommendation it gives you, and move upward only when the first model is not solving the task.
The 60-second answer
| Available memory | Sensible first text-model target | What that usually supports |
|---|---|---|
| 8GB | 1B–4B in a common 4-bit build | Short chat, rewriting, light summarization, basic experimentation |
| 16GB | 7B–8B in a common 4-bit build | Everyday chat, writing, focused coding help, small document workflows |
| 24GB | 8B–14B in a common 4-bit build | Stronger general use, better coding help, moderate document work |
| 32GB | 14B first; selected larger models after testing | More capable local assistants and heavier multitasking |
| 64GB | 14B–32B in a common 4-bit build | Serious local experimentation and larger document workflows |
| 96GB+ | 32B first; larger only for a specific reason | High-memory workstation use, subject to speed and runtime support |
These are starting points, not promises. A discrete GPU uses dedicated GPU memory differently from a CPU-only system, and an Apple Silicon Mac uses one unified-memory pool for the model, context, macOS, and every other application.
First identify which memory you have
System RAM
System RAM holds the operating system, applications, context, document-processing overhead, and model data that is not kept in dedicated GPU memory. A CPU-only setup plans primarily around system RAM, but fitting the model does not guarantee comfortable speed.
Dedicated GPU memory
On a Windows or Linux machine with a discrete NVIDIA or AMD GPU, dedicated GPU memory is usually the most important number for fast inference. Keeping most of the model and its working data on the GPU is generally faster than spilling work into system RAM.
Do not treat “shared GPU memory” in Windows as equivalent to dedicated GPU memory. Shared memory is ordinary system RAM made available to the GPU and is normally much slower for this job.
Apple unified memory
Apple Silicon uses one memory pool shared by the CPU and GPU. That can make a larger portion of total memory available to local inference, but the model competes with macOS, your browser, your editor, document indexes, and every other running process.
A 16GB Apple Silicon Mac is therefore not the same thing as a PC with a 16GB graphics card. The Mac has one flexible pool; the PC has a dedicated 16GB GPU pool plus separate system RAM.
Why the model file is not the whole memory bill
A model download may appear to fit while the real workload does not. The complete memory demand includes:
- model weights;
- runtime and backend overhead;
- the context window and key-value cache;
- attached documents and retrieval results;
- image or audio components for multimodal models;
- the operating system and ordinary applications;
- memory needed while loading, converting, or offloading the model.
That is why a model that barely loads can still be a bad recommendation. It may force swapping, crash when context grows, or make the rest of the computer unusable.
Use this decision sequence
- Identify the real memory pool. Record system RAM, dedicated GPU memory, or Apple unified memory.
- Choose the job. Chat, coding, document retrieval, image generation, and a local API place different demands on the machine.
- Start one model class below the technical ceiling. Leave room for context and normal work.
- Use a common 4-bit build first. It is usually the practical entry point for text-model fit.
- Keep context modest. Long context can consume substantial additional memory even when the model weights fit.
- Get one successful response. Do not add Open WebUI, document tools, agents, or custom integrations before the base runtime works.
- Move larger only for a measured need. Compare whether the larger model materially improves the task you care about.
Worked examples
16GB Apple Silicon Mac
Start with a 7B–8B model in a common 4-bit build. LM Studio is the easier graphical path; Ollama is the cleaner runtime and API path. Keep context modest and close memory-heavy applications if macOS shows sustained memory pressure.
What success looks like: the model loads without prolonged swapping, returns a normal response, and leaves the computer usable for the applications you need beside it.
Windows desktop with 32GB system RAM and an 8GB NVIDIA GPU
Plan around the 8GB of dedicated GPU memory for fast inference, not the 32GB headline alone. Start with a 7B–8B 4-bit model and moderate context. A larger model may use partial CPU offload, but that can reduce speed sharply.
What success looks like: the runtime detects the GPU, most of the intended workload stays within dedicated GPU memory, and generation remains responsive enough for daily use.
Windows laptop with 16GB RAM and integrated graphics
Start with a small 1B–4B model and expect CPU or integrated-graphics limits. The machine may technically load a larger quantized model, but slow generation and memory contention can make it a poor everyday setup.
What success looks like: a small model returns useful answers without exhausting system memory or making the laptop unresponsive.
64GB Apple Silicon Mac
Start with a 14B–32B 4-bit model depending on the task. Do not jump directly to the largest model you can download. Context, multimodal components, and normal applications still use the same unified-memory pool.
What success looks like: the chosen model improves the task enough to justify its slower speed and higher memory use while leaving practical headroom.
The app does not erase hardware limits
LM Studio and Ollama can both run local models, but choosing one does not make an oversized model fit. Use LM Studio when you want a graphical desktop workflow. Use Ollama when you want a lightweight runtime, terminal workflow, or local API. Compare Ollama and LM Studio after you know the model class your hardware can handle.
When the answer is “use a smaller model”
Use a smaller model when:
- the operating system begins swapping heavily;
- the model loads but the first response takes too long to be useful;
- increasing context causes crashes or severe slowdowns;
- document indexing and the model cannot coexist in memory;
- GPU work repeatedly spills into system RAM;
- the rest of the computer becomes unusable during inference.
That is not a failed setup. It is the correct diagnosis. A smaller model that runs smoothly is more useful than a larger model that only proves the machine can open the file.
Next step
Use the RAM and VRAM requirements guide when you need the detailed memory math, or go directly to the RAM/VRAM calculator when you know the model file and context you want to test.