LM Studio and Ollama run the same models on the same hardware through much the same engine, and they will give you different experiences on an identical machine.
The reason is a single design decision. Ollama decides how much of a model to put on your GPU and does not tell you. LM Studio hands you the slider. That makes LM Studio harder to get wrong invisibly, and easier to get wrong visibly — which is a better trade than it sounds.
The requirements, in brief
The memory arithmetic is the same as for any local model, because it is a property of the model rather than the application. The full reasoning is in How Much VRAM Do You Need for Local AI?; the summary:
| Model size | VRAM for full GPU offload | System RAM if running on CPU |
|---|---|---|
| 1B–3B | 4 GB | 8 GB |
| 7B–8B | 8 GB | 16 GB |
| 14B | 12 GB | 24 GB |
| 32B | 24 GB | 32 GB |
| 70B | 48 GB | 64 GB |
LM Studio itself is a desktop application and adds very little. The models have the requirements.
The one platform requirement that catches people
On Windows and Linux, LM Studio requires a processor supporting AVX2. That covers essentially everything made since around 2013, and it excludes older hardware people frequently try to repurpose as a model server. If you are installing on an ageing machine and it refuses to run, this is usually why.
The GPU offload slider
This is the mechanical difference between LM Studio and everything else, and understanding it is most of what you need.
A language model is a stack of layers. Every layer can live on the GPU or on the CPU, and the slider sets how many go on the GPU. Ollama calculates this for you; LM Studio makes it a number you choose.
Why exposing it is better
Ollama’s automatic behaviour is genuinely convenient and it fails silently. Ask it for a model slightly too large and it will quietly put a third of the layers on your processor, and the only symptom is that generation is slow. Plenty of people conclude their GPU is not being used at all.
LM Studio shows you an estimate of memory use before you load, and lets you set the split deliberately. When it is slow, you can see why.
Setting it correctly
The rule is simple: all layers on the GPU, or reconsider the model.
- Start at maximum. If the model loads and stays within VRAM, you are done — this is the configuration you want.
- If it fails to load, do not simply reduce the slider. Partial offload costs five to fifteen times the speed, because the CPU layers run across the PCIe bus. Reducing the context length or dropping a quantisation level usually gets you back to full offload, and full offload of a smaller model beats partial offload of a larger one almost every time.
- Leave a margin. Aim to use perhaps 90% of your VRAM rather than 99%. Your desktop, your browser and the runtime all want some, and a model that loads with nothing spare will fail when you open something else.
- Watch the estimate, then verify. The in-app estimate is good and it is an estimate. Check actual allocation with
nvidia-smi,rocm-smior Activity Monitor once it is running.
Context length, and the setting most people never touch
LM Studio exposes context length directly, and it is the lever that most often turns “does not fit” into “fits”.
Every token in the conversation is stored in the KV cache, which lives in VRAM alongside the weights and grows linearly with context. On a 14B model that is roughly 0.19 MB per token — so 32,768 tokens of context costs around 6 GB, which on a 16 GB card is most of your remaining headroom.
Two things follow:
- Do not set context higher than you use. A model advertising 128K context does not mean your hardware can hold 128K, and the default in most tools is more generous than most conversations need.
- Quantise the KV cache. Recent LM Studio versions expose this, and moving the cache to 8-bit roughly halves it for a quality difference that is very hard to notice. It is the single most effective way to reclaim VRAM without changing model or quantisation.
Model formats: GGUF and MLX
LM Studio handles two, and which you want depends on your hardware.
GGUF is the llama.cpp format, and it runs everywhere — NVIDIA, AMD, Apple silicon, and CPU. It is the default and the right choice on any PC.
MLX is Apple’s own framework, and LM Studio supports it natively on Apple silicon. For supported models it is frequently faster than GGUF on the same Mac, because it is designed around unified memory rather than adapted to it.
On a Mac, try both. The same model in both formats can differ noticeably, and which wins varies by model and by release. This is a real advantage LM Studio has over tools that only speak one format.
Apple silicon specifics
Worth its own note, because the memory model is different.
Unified memory means the GPU can address most of system RAM, so memory capacity is the whole story — there is no separate VRAM to run out of. Roughly 70–75% of total memory is available to the GPU by default, which means:
| Mac memory | Roughly available | Comfortable model size |
|---|---|---|
| 16 GB | ~11 GB | 8B |
| 32 GB | ~22 GB | 14B, or 32B at a squeeze |
| 64 GB | ~45 GB | 32B comfortably |
| 128 GB | ~96 GB | 70B |
That allocation is adjustable through the iogpu.wired_limit_mb kernel parameter if you need more, though leave the system a genuine working margin — a Mac that swaps performs far worse than one running a slightly smaller model.
The local server
An underused feature and a genuine reason to prefer LM Studio for development work.
LM Studio can expose a loaded model through an OpenAI-compatible HTTP API. Anything written against the OpenAI SDK — an agent framework, a script, an editor extension — points at the local address instead and works unchanged.
For hardware, this changes one thing: a model serving requests from other applications should stay resident. Size for the model staying loaded rather than for it being loaded on demand, and leave headroom for whatever else is on the machine.
LM Studio or Ollama?
Both are good, and they suit different people.
LM Studio suits you if you want a graphical interface, you want to see and control the GPU split, you are on a Mac and want MLX, or you like browsing and comparing models before downloading them. It is the better tool for understanding what your hardware is doing.
Ollama suits you if you want a command line and a background service, you are scripting against it, or you want a model server that starts with the machine and needs no attention. Its automatic offload is genuinely convenient when the model comfortably fits.
They are not mutually exclusive — both read GGUF files, and plenty of people use LM Studio to explore and Ollama to serve. See Ollama Hardware Requirements for the other side.
Common questions
What are LM Studio's minimum requirements?
The application itself is light. On Windows and Linux it requires a processor with AVX2 support, which covers essentially everything since about 2013 and excludes older machines people try to repurpose. Beyond that, the requirements belong to the model: 8 GB of VRAM for a 7B, 12 GB for a 14B, 24 GB for a 32B.
What should I set the GPU offload slider to?
Maximum, if the model fits. Partial offload puts some layers on the CPU, and those run across the PCIe bus at a fraction of the speed — typically five to fifteen times slower. If the model will not fit at maximum, reduce the context length or drop a quantisation level rather than sliding the offload down.
Is LM Studio faster than Ollama?
On the same model and the same offload configuration, no meaningfully — both use llama.cpp for GGUF. LM Studio can be faster on Apple silicon because it also supports MLX, which is often quicker than GGUF there. The larger practical difference is that LM Studio shows you when part of the model is on the CPU, and Ollama does not.
Why does my model load but run slowly?
Almost always partial offload. Check the GPU offload setting and the memory estimate before loading. If layers are on the CPU, reduce the context length — that is usually the cheapest way back to full GPU offload — or drop a quantisation level.
How much context can I use?
Depends on how much VRAM is left after the weights. On a 14B model, context costs roughly 0.19 MB per token, so 32K is about 6 GB. Quantising the KV cache to 8 bits roughly halves that for a quality difference most people cannot detect, and it is the most effective single setting for reclaiming memory.
Should I use GGUF or MLX?
GGUF on any PC — it runs on NVIDIA, AMD and CPU. On Apple silicon, try both: MLX is designed around unified memory rather than adapted to it, and for supported models it is frequently faster. Which wins varies by model, so it is worth a direct comparison.
How much memory should a Mac have for LM Studio?
Roughly 70–75% of total memory is available to the GPU, so 16 GB comfortably runs 8B models, 32 GB reaches 14B, 64 GB handles 32B, and 128 GB reaches 70B. Memory is soldered on every Apple machine, so this decision is permanent.
Can I use LM Studio as a server?
Yes — it exposes a loaded model through an OpenAI-compatible HTTP API, so anything written against the OpenAI SDK works unchanged against a local address. Size your hardware for the model staying resident rather than loading on demand, and leave headroom for whatever else runs on the machine.
Continue your research
- Ollama Hardware Requirements — the same question for the other runtime
- How Much VRAM Do You Need for Local AI? — the memory arithmetic in full
- Best GPUs for Local AI — cards ranked by what they let you run
- Mac Studio vs AI PC — if the MLX advantage interests you