LM Studio's 'force MoE weights onto CPU' setting: fit a 30B model on an 8GB GPU

The Amiga had two kinds of memory. Chip RAM was shared with the custom graphics chips. Fast RAM was for the CPU alone. Every Amiga owner learned the same trick: keep what the graphics chips touch in chip RAM, and park the bulky rest in fast RAM. A mixture-of-experts model on a small graphics card wants exactly that treatment.

LM Studio has a setting that does it. It has had two names, and it changed shape in January 2026, which is why the advice you find about it rarely matches the app in front of you. I read LM Studio's release notes, its docs and its open-source settings code on 4 October 2026. I didn't install it or time anything, so there are no speed numbers here that aren't LM Studio's own words.

Where is the MoE offload setting in LM Studio?

It's in the model's load settings, under the advanced options. Look for "Number of layers for which to force MoE weights onto CPU". Older guides call it "Force Model Expert Weights onto CPU", which was the same setting's name until December 2025. You can set it when you load a model, or save it as that model's default.

LM Studio added it in version 0.3.23 on 12 August 2025. The release notes told low-VRAM users to "try to turn on the "Force Model Expert Weights onto CPU" option in the advanced load settings." That version was a simple on/off switch.

The name changed in LM Studio's localization file on 23 December 2025, in a commit titled "Improve title". Then version 0.4.0 shipped on 28 January 2026 with this line in its notes: "Added a slider to control n_cpu_moe". So if you're on any 0.4 release, look for a slider with a layer count, not a toggle.

Two places expose it:

• The model loader. Open it with Cmd + L on a Mac or Ctrl + L on Windows and Linux, pick the model, and open its advanced load settings.
• My Models. LM Studio's docs say to "click on the gear ⚙️ icon to edit the model's default parameters". Settings saved there apply "when the model is loaded anywhere in the app (including through lms load)".

What does it actually do?

It keeps the expert weights of N layers in system RAM and leaves the rest of each layer on the GPU. LM Studio's own description says it "Leaves attention layers on GPU, saving VRAM while keeping inference fairly fast." That is llama.cpp's --n-cpu-moe, wrapped in a slider.

The 0.3.23 release notes said it plainly: "This is utilizing the same underlying technology as llama.cpp's --n-cpu-moe." In llama.cpp, that flag keeps "the Mixture of Experts (MoE) weights of the first N layers in the CPU". Its sibling, --cpu-moe, keeps all of them there. The LM Studio slider covers both: a middle value is --n-cpu-moe, and the far right is all experts.

Why does this work at all? A mixture-of-experts model has many expert blocks per layer, but each token only uses a few of them. The always-used parts, attention and the router, are small. The experts are huge and mostly idle. So the experts can sit in slower system RAM while the busy parts stay on the fast card. Our explainer on what --n-cpu-moe actually does covers the mechanics and the published llama.cpp benchmarks.

LM Studio's SDK shows how it meets the GPU Offload slider. The SDK field, numCpuExpertLayersRatio, runs from 0 to 1. Its code comment says 1 puts all expert layers in CPU memory "regardless of GPU offload configuration", and 0 means "the expert offload will be determined by GPU offload".

When should you turn it on?

Only when the MoE model doesn't fit in your graphics card's memory. LM Studio's 0.3.23 notes say that if the entire model fits, "you're better off sticking with placing expert weights onto the GPU as well". On a dense model the setting has nothing to move.

The current settings text agrees, in fewer words. It says the slider "can be faster than partial GPU offload" and is "Not recommended if the model fits entirely in VRAM." Both halves matter. When something has to leave the card, moving experts can beat moving whole layers. When nothing has to leave, leave it all on the card.

So the order of moves is:

1. If the model fits, leave the slider at zero.
2. If it doesn't fit and it's an MoE model, use the expert slider before you lower GPU Offload.
3. If it still doesn't fit with every expert in RAM, shrink the context or pick a smaller file.

What number should you set, and how much RAM do you need?

Start with the slider value from the table below for your card. It's the number of layers whose experts go to system RAM at LM Studio's default 8K context. The RAM column matters more: if the experts don't fit in system RAM, no setting saves you.

LM Studio's default context is 8K tokens, per its 0.4.16 changelog ("Updated default context length to 8k tokens"). I worked these values out with the same method and GGUF files as our table of the best MoE models for 12GB and 16GB cards, which uses 32K context. The 8GB column is new.

"RAM to have" is the expert weight in RAM plus 8 GB for your operating system and apps, rounded up to a common kit size. The 8 GB is my allowance, not an LM Studio number. Here's one row worked through, so you can redo it for your own card:

Qwen3.6 35B-A3B on an 8GB card, 8K context (GB = 1024^3 bytes)
GPU floor  = non-expert weights 2.38 + cache 0.16 + overhead 0.78 = 3.32
budget     = 0.9 x 8 = 7.2   (our engine's "comfortable" line)
per layer  = 18.22 GB of experts / 40 layers = 0.455
layers kept on GPU = floor((7.2 - 3.32) / 0.455) = 8
slider     = 40 - 8 = 32
RAM        = 32 x 0.455 = 14.6 GB of experts, + 8 GB allowance -> 32 GB kit

At 32K context the numbers climb a little: Qwen3 30B-A3B needs 41 of 48 layers' experts in RAM on an 8GB card, 31 on 12GB and 20 on 16GB. The full 32K table, with GLM-4.5-Air and Qwen3 235B, is in the 12GB and 16GB MoE guide.

These are starting points, not promises. Different GGUF builds of the same model split a few percent differently. Vision models also carry an extra projector file. If the load fails, raise the slider by two. If it loads, try lowering it a step at a time, because every expert layer back on the GPU is one less layer read from slower RAM.

How to set it, step by step

Set it once per model in My Models, so every load path picks it up. Then check that the model loads, and walk the number down while it still does. This is the whole routine:

The GPU Offload pairing in step three is my reading of the settings, not an LM Studio instruction. The SDK comment says that with the expert setting at zero, expert placement follows GPU Offload. The common llama.cpp pattern, including a command posted on the pull request that added the flag, is --n-gpu-layers 99 plus --n-cpu-moe N. Our step-by-step MoE offload guide walks through that setup.

Don't confuse it with Number of Experts

Number of Experts is a different setting with a confusingly close name. It changes how many experts the model uses for each token. It moves no memory at all. Changing it alters the model's behavior, and LM Studio's SDK says it affects "both performance and quality of outputs".

LM Studio's REST API describes num_experts as the "Number of expert to use during inference for MoE (Mixture of Experts) models." That's a model-behavior knob, not a memory one. If you're trying to fit a model, leave Number of Experts at the model's default and use the slider. A model trained to route through eight experts per token was not trained to run on four.

Why MLX models on a Mac don't have it

The expert slider is a llama.cpp setting, so it only appears for GGUF models. LM Studio's SDK attaches it, together with Number of Experts, only to the llama.cpp engine's settings. The MLX engine's settings list has no expert-offload field. On Apple Silicon it would buy you little anyway.

The reason is in Apple's MLX documentation: "Arrays in MLX live in shared memory." On an Apple Silicon Mac, the CPU and GPU draw from one pool. Moving experts "to the CPU" frees no separate graphics memory, because there isn't any. The limit on a Mac is the total memory in the machine.

GGUF files on a Mac run in LM Studio's llama.cpp engine, but the same rule holds: there is no separate pool of VRAM for the slider to save. Our MoE vs dense explainer covers why MoE models are still a good fit for big unified-memory Macs.

The 0.4.0 complaint, and what LM Studio says

One user filed a bug on launch day of 0.4.0, saying the new slider "forces entire layers (including non-expert parts) onto the CPU". LM Studio's own setting text says the opposite: it moves experts and leaves attention on the GPU. The report, issue #1419, is still open with no reply.

I can't settle that without running the app, and I didn't run it. What I can tell you is what LM Studio publishes: the 0.4.0 notes call it "a slider to control n_cpu_moe", and llama.cpp's n_cpu_moe moves expert weights only. The same 0.4.0 release also fixed "a bug where the model loading will get stuck if the cpu moe slider is maxed out". If you're on 0.4.0 itself, update.

Can you set it from lms, the API or code?

Not with a flag. The lms load command takes context length, GPU offload, TTL and an identifier, and the REST load endpoint has no expert-offload field either. The route that works is the model's saved default, which LM Studio applies to every load, including lms load.

The SDKs do expose it. In LM Studio's JavaScript SDK the field is numCpuExpertLayersRatio inside the gpu settings, a fraction from 0 to 1, or "off" and "max". A slider value of 24 on a 48-layer model is 0.5. Version 0.3.24 fixed "setting numCpuExpertLayersRatio via the SDK", so use a current build. The SDK marks the gpu group deprecated while LM Studio works on "an improved way to control split", so expect the name to move.

Since 0.4.24 (9 September 2026), LM Studio also has "advanced llama.cpp argument overrides for GGUF model loading". The SDK marks that experimental and says custom parameters are appended "without validation". If you need llama.cpp's -ot patterns, our llama.cpp MoE offloading guide explains them. If you'd rather drive the flag directly, llama.cpp itself is the cleaner tool, and our Ollama vs LM Studio comparison covers when each app makes sense.

Related guides

• What --n-cpu-moe actually does: the flag behind LM Studio's slider, and published speed tests.
• Best MoE models for a 12GB or 16GB GPU: starting values and RAM at 32K context.
• gpt-oss-20b on an 8GB or 12GB card: one popular model, worked through.
• Ollama vs LM Studio: which app to run.
• Interactive VRAM calculator: check a model and context before you load it.