LM Studio System Requirements: RAM, VRAM, GPU

There are two different questions hiding inside “what are the LM Studio system requirements”. The first is whether the application will install and launch at all, which is a short list of hard floors published by the vendor. The second is whether the machine will run the model you actually want at a speed you will tolerate, which has almost nothing to do with the first list. Most disappointed newcomers cleared the published minimums easily and still ended up with a chatbot that types slower than they read.

This page separates the two, because the buying decision lives entirely in the second question.

The published minimums

LM Studio’s documentation sets different floors per platform.

On macOS, the app requires Apple Silicon, listed as M1, M2, M3, or M4. Intel Macs are not currently supported. The documented OS floor is “macOS 14.0 or newer is required”, and the memory guidance is “16GB+ RAM recommended”, with a note that 8 GB Macs can work with smaller models.

On Windows, the CPU requirement is the sharp one: “AVX2 instruction set support is required (for x64)”. ARM devices built on the Snapdragon X Elite are also supported. Memory guidance is “At least 16GB of RAM is recommended”, and for discrete graphics the documentation says “at least 4GB of dedicated VRAM is recommended”.

On Linux, the app is distributed as an AppImage, and “Ubuntu 20.04 or newer is required”. The x64 build ships with AVX2 support by default, and ARM64 (aarch64) is supported. The documentation notes that Ubuntu releases past 22 have had limited testing, which is worth knowing before you blame the app for an odd failure on a very current distro.

Two of those deserve emphasis because they are absolute rather than advisory. AVX2 is a CPU instruction set, so an older x64 processor without it is not slow, it is incompatible. And the Apple Silicon requirement means an Intel Mac cannot be made to work by adding memory.

One non-hardware requirement is worth clearing up at the same time, because it is the single most common question after “will it run”. As of July 2025 LM Studio removed the separate commercial licence, and the vendor’s announcement states it is “free for use at work” with no form to fill in and nobody to contact. The application itself is not the thing you budget for. The memory is.

Why the minimums do not answer the buying question

Meeting the floor gets the window open. What determines whether the experience is good is whether the model’s weights fit in fast memory with room left over.

A local model is a file of numbers, and every token it generates requires reading a large fraction of those numbers. Single-request local inference is therefore usually limited by memory bandwidth, not by arithmetic throughput. That single fact explains nearly every performance complaint. When the whole model sits in GPU memory or in Apple’s unified memory, generation is fast. When part of it sits in ordinary system RAM, every token waits on the slow part, and the average collapses toward the speed of the slowest tier rather than landing somewhere in the middle.

So the practical requirement is not a spec-sheet number. It is an inequality: model file size, plus context cache, plus operating system overhead, must be smaller than the fast memory you have.

Sizing the memory you actually need

Model file size is the term you control most directly, and you control it through quantization. Weights are normally trained at 16 bits each; quantized GGUF files store them at roughly eight, five, four, or three bits, which scales the file size almost linearly. The rough arithmetic is parameters multiplied by bits-per-weight, divided by eight, giving gigabytes. An 8-billion-parameter model at about four bits per weight lands near 4.5 GB; the same model at eight bits roughly doubles. Picking that level is its own decision with its own tradeoffs, covered in choosing a GGUF quantization level.

The second term is the KV cache, the running memory of the conversation. It grows with context length and with the number of simultaneous conversations, and it is the term people forget. Loading a model that fits with 400 MB to spare, then setting a 32,000-token context window, is a reliable way to turn a working setup into a crawling one.

The third term is everything else the machine is doing. Leave real headroom rather than the last few hundred megabytes.

Because that arithmetic is tedious to redo for every candidate model, this site keeps an interactive VRAM and GGUF sizer that combines parameter count, quantization level, context length, and hardware target into a single footprint figure.

Discrete GPU versus Apple Silicon

These two paths fail in different ways, which matters when you are choosing what to buy.

On a discrete GPU, VRAM is a hard wall. The documented 4 GB recommendation is enough to accelerate a small model, not to hold a useful one entirely. Exceeding VRAM does not stop you: LM Studio exposes GPU offload as a per-model load setting, so you choose how many layers go to the card and the rest stay on the CPU. That flexibility is genuinely useful and also the source of the classic disappointment, because a mostly-offloaded model is not mostly-fast. Sizing a discrete card is really sizing its VRAM, and system RAM beyond a comfortable baseline buys you very little.

On Apple Silicon, CPU and GPU share one pool, so the same 32 GB or 64 GB serves as both. The usable budget for a model is larger than a discrete GPU at similar money, and the failure mode is softer, because there is no sharp cliff between “in VRAM” and “not in VRAM”. The system does reserve a portion of that pool for itself, so treat the headline figure as generous rather than exact. In practice, memory capacity is the specification to buy on, ahead of the chip tier.

Alongside GPU offload, LM Studio’s per-model settings also expose context size and whether to use Flash Attention, both of which move the memory figure. Set them per model rather than globally, since the right context length for a coding assistant and for a long-document summarizer are not the same number.

A short buying heuristic

If you are choosing hardware rather than testing what you own, the ordering is straightforward. Decide the largest model you genuinely want to run. Convert it to a file size at a four-bit k-quant. Add a realistic context cache. Add several gigabytes of headroom. Buy fast memory of at least that total. Everything else, including the compute tier, is secondary.

If you are working with an existing machine instead, the honest move is to start one size below what looks possible. Confirm full GPU offload, confirm the speed is acceptable, and only then try something larger. The failure you are avoiding is subtle: a model that technically loads, leaves no room for context, and quietly performs worse than a smaller one would have.

What to read next

Once the machine is settled, two questions follow immediately. The first is why the model you found on Hugging Face will not load at all, which is almost always a format problem rather than a hardware problem: see GGUF vs safetensors for what LM Studio can and cannot open. The second is whether the machine needs to be your desktop at all, since a headless box with the GPU in it can serve every other device in the house: see running LM Studio on Unraid.