--- title: "LM Studio GPU Offload on Mac: What the Slider Actually Does" description: "On Apple Silicon there is no graphics card to offload to. Here is what LM Studio's GPU offload setting really controls, and the memory ceiling you are hitting." date: 2026-08-10 author: "Ben Racicot" tags: ["LM Studio", "Apple Silicon", "Metal", "Local LLM", "macOS", "Troubleshooting"] type: "article" canonical: "https://modelpiper.com/blog/lm-studio-gpu-offload-mac" --- # LM Studio GPU Offload on Mac: What the Slider Actually Does > On Apple Silicon there is no graphics card to offload to. Here is what LM Studio's GPU offload setting really controls, and the memory ceiling you are hitting. ## TL;DR On Apple Silicon the CPU and GPU share one pool of memory, so GPU offload never moves bytes anywhere. The slider only picks how many transformer layers execute on Metal, and on a Mac the right answer is almost always all of them. What stops you is not VRAM, it is the working-set ceiling macOS reports to Metal, which is a fraction of your total RAM. Most GPU offload advice for LM Studio was written for a PC with a discrete graphics card, and on that machine the advice is right: the card has its own memory, moving layers into it costs a bus transfer, and picking how many layers fit is a real optimization problem. None of that is true on a Mac. Apple Silicon has unified memory. The CPU and the GPU address the same physical DRAM. There is no card, no separate pool, and nothing to copy across. So when you drag LM Studio's GPU offload slider on an M-series Mac, you are not deciding where the weights live. They live in the same place either way. ## What does GPU offload actually do on Apple Silicon? It picks how many of the model's transformer layers execute on the Metal backend instead of on the CPU. Because Apple Silicon memory is unified, no data moves when you change it: the weights are already in RAM that both processors can read. Setting it below maximum on a Mac means asking the CPU to do work the GPU would do faster, on exactly the same bytes. That is why the usual PC tuning instinct backfires here. On a desktop with a 12GB card, holding back a few layers is how you avoid an out-of-memory error. On a 32GB Mac, holding back a few layers just makes generation slower for no memory saving at all. The practical rule on Apple Silicon is short: offload everything, unless the model does not fit. If it does not fit, the fix is a smaller quantization or a shorter context, not a partial offload. ## Why does LM Studio still show me a slider then? Because it is one app across macOS, Windows and Linux, and on two of those three the slider is load-bearing. LM Studio exposes GPU offload as a per-model default alongside context size and Flash Attention, and the same control is available from its CLI as `lms load --gpu`. It is not a Mac-specific control that is behaving strangely. It is a cross-platform control that has much less to do on a Mac. ## So why does my Mac still refuse to load the model? Because the limit on Apple Silicon is not VRAM, it is the working-set ceiling macOS reports to Metal. That ceiling is a fraction of installed RAM, not all of it. On our own M2 Max with 32GB, Metal reports a recommended maximum working set of 26,800,603,136 bytes, which is roughly 25GiB of the 32GB installed. The rest is reserved for everything else the machine is doing. This is the number that actually decides whether a model loads, and it is the one nobody talks about, because on a PC the equivalent figure is printed on the box. Three consequences follow, and they explain most of what looks like a bug: **Your usable budget is smaller than your RAM.** A 32GB Mac is not a 32GB inference budget. Size models against roughly three quarters of installed memory and you will be close. **Context length is part of the model's footprint.** The KV cache grows with context and it comes out of the same budget as the weights. A model that loads fine at 4K can fail at 32K without a single byte changing in the model file. **Everything else on the Mac is competing.** Browser tabs, Xcode, a Docker daemon. The ceiling is fixed but the free space under it is not. ## What about raising the limit with iogpu.wired\_limit\_mb? You will find advice telling you to raise the wired-memory limit with a `sysctl` so Metal can claim more of your RAM. It does work, and it is a real knob rather than folklore. The catch is what it is protecting. That headroom is what macOS uses to stay responsive under pressure, and a wired-memory overflow on Apple Silicon is not a recoverable allocation failure that an app can catch and report. It is a kernel-level fault. Raising the limit to squeeze in a model that nearly fits trades an error message you can read for a hang you cannot. We deliberately do not read or set that sysctl in our own engine for exactly this reason. If you want the extra headroom for a specific session, set it, run the session, and set it back. Do not leave it raised as a permanent configuration. ## How to fix it inside LM Studio In order, cheapest first. None of these require leaving the app. ## The alternative: no slider, because the answer never varies Everything above is the reason ToolPiper does not have a GPU offload control. On Apple Silicon the correct value is always maximum, so the engine is launched with full Metal offload every time and there is nothing to tune. We embed upstream llama-server directly, build b10068, and pass all layers to Metal on every load. The number that actually matters is the one we do read. The app queries the live Metal working-set ceiling and your installed memory, and sizes model suggestions against them, so the model list tells you what your Mac can hold before you spend the download. On the MLX side the same reading is a hard admission gate: a load that would not fit is refused before any allocation happens, rather than being attempted and taking the machine down with it. Models arrive as plain, named GGUF files in `~/Library/Application Support/ToolPiper/models/`, so nothing about this locks you in. Same models, same engine lineage, and on inference speed expect parity: our same-bytes benchmark on an M2 Max landed within single digits in both directions with the winner flipping by model. The honest limits: macOS 26 or newer and Apple Silicon only. LM Studio's floor is macOS 14.0, so if you are on an older system it is the one that runs. Worth naming, since an offload ceiling is usually the moment people start comparing: neither app charges you to run a model. LM Studio's local tier is free and its cloud tier is metered per token. Ours puts the whole runner in the free tier, memory handling included. [The free versus paid split, with dated prices](/compare/is-lm-studio-free). ## Steps ### 1. Set GPU offload to maximum Open the model's load settings and push GPU offload all the way up. On Apple Silicon there is no memory saved by holding layers back, so anything below maximum is leaving speed on the table. From the CLI the same thing is `lms load --gpu max`. ### 2. Cut context length before you cut anything else The KV cache scales with context and competes with the weights for the same budget. If a model loads at 4K and fails at 32K, context is your problem, not offload. Drop to the shortest context the task actually needs and try again. ### 3. Drop one quantization step Q4\_K\_M instead of Q5 or Q6 is usually a few hundred megabytes to several gigabytes smaller, for a quality difference most tasks will not notice. This is the lever that reliably works when the model is genuinely too big, and LM Studio's model browser shows the variants side by side. ### 4. Close what is competing for the budget The Metal ceiling is fixed but the free space under it is not. Quit the browser with forty tabs, stop the Docker daemon, and unload any other model still resident. In LM Studio, `lms ps` lists what is currently loaded in memory. ### 5. Only then consider the wired limit If you have done the four above and the model still misses by a little, raising `iogpu.wired_limit_mb` is the remaining option. Set it for the session, run the work, and put it back. Leaving it raised trades a readable error for an unrecoverable one. ## FAQ ### Why is LM Studio not using all my VRAM on a Mac? Because a Mac does not have VRAM in the sense the question assumes. Apple Silicon uses unified memory, so there is no separate pool for the GPU to fill. What you are seeing is the Metal working-set ceiling, which is a fraction of installed RAM rather than all of it. On our M2 Max with 32GB it reports 26,800,603,136 bytes, roughly 25GiB. That is the real budget, and it is working as designed. ### Should GPU offload be at maximum on Apple Silicon? Yes, in almost every case. Because memory is unified, holding layers back on the CPU saves no memory at all and only moves work to the slower processor. The exception is not really an exception: if the model does not fit, the fix is a smaller quantization or a shorter context, not a partial offload. ### What does GPU offload mean in LM Studio? It sets how many of the model's transformer layers run on the GPU backend rather than the CPU. LM Studio exposes it as a per-model default alongside context size and Flash Attention, and as `--gpu` on the `lms load` command. On Windows and Linux with a discrete card it decides what fits in VRAM. On a Mac it only decides which processor does the work. ### Why does my model load at 4K context but fail at 32K? The KV cache grows with context length and comes out of the same memory budget as the weights. At a long context the cache can be a large fraction of total footprint, so a model that fits comfortably at 4K can exceed the Metal ceiling at 32K without the model file changing at all. Shorten the context or quantize the cache. ### Is it safe to raise iogpu.wired_limit_mb? It works, and it carries a real risk. That reserved headroom is what keeps macOS responsive under memory pressure, and a wired-memory overflow on Apple Silicon is a kernel fault rather than a catchable allocation error, so the failure mode you get in exchange is worse than the one you are avoiding. Set it for a session if you need it, then put it back. We do not read or set it in our own engine. ### Does ToolPiper have a GPU offload setting? No, deliberately. On Apple Silicon the correct value is always maximum, so the engine launches with full Metal offload on every load and there is no slider to get wrong. What the app does read is the live Metal working-set ceiling and your installed memory, which it uses to size model suggestions before you download, and on the MLX path as a hard admission gate that refuses an over-budget load rather than attempting it.