Overview
The Mac GPU memory limit is not a number Apple publishes for each Mac: Apple’s Metal documentation gives each GPU a “recommended” working set and states no percentage of installed memory, so the exact share of unified memory a local LLM can use on your Mac is unknown until you read it from your own machine. Reporters in public bug trackers see about three quarters of installed memory, and one project README states “~75%”, but none of those is an Apple statement. This page lists each claim with its source, shows one worked example, and shows where to read the real value. Fit math elsewhere on this site uses the formulas on methodology and compares totals to installed memory, with the macOS reserve marked unknown.
What is the Mac GPU memory limit?
It is the amount of memory Metal reports as safe for the GPU to use, and it is a property of the device, not a fixed fraction.
Apple documents it as recommendedMaxWorkingSetSize: “An approximation of how much memory, in bytes, this GPU device can allocate without affecting its runtime performance.” The discussion adds: “You can help the GPU maintain its performance by keeping the total memory footprint of its resources and heaps less than this threshold value.” (Apple Developer Documentation, read 2026-10-13.) The page does not say what share of unified memory this is on any Mac, and it calls the value a recommendation for performance. Whether macOS refuses allocations above it, or merely slows down, is unknown from that page.
How much unified memory can the GPU use on a Mac?
Reported values are about 75% of installed memory on the Macs below, but the figure is reporter data and the general rule is unknown.
| Source | Mac and memory | Reported GPU figure | Fraction (arithmetic) |
|---|---|---|---|
| LM Studio issue 271, llama.cpp log | MacBook Pro, 48 GiB | recommendedMaxWorkingSetSize = 38654.71 MB; “36863 MiB free”; reporter says the app shows 36.00 GB | 36864 / 49152 = 0.75 |
| Same issue, a commenter | MacBook M4 Max, 64 GB | ”only 48 GB is detected for VRAM” | 48 / 64 = 0.75 |
| devnote README | 32 GB | ”~21-24 GB” default | 21 / 32 = 0.66; 24 / 32 = 0.75 |
| Same README | 64 GB and 128 GB | ”~48 GB” and “~96 GB” default | 0.75 and 0.75 |
How the first row is worked: 48 GiB is 48 × 1024 = 49152 MiB, and 0.75 × 49152 = 36864 MiB, which matches the “36863 MiB free” in the log. The same number in decimal is 36864 × 1.048576 = 38654.7 MB, which matches the logged 38654.71 MB. So on that one Mac the value is 75% of installed memory, as the reporter’s log shows.
What this does not show: that every Mac, chip or macOS version gives 75%. The README’s own 32 GB row gives a range that includes a figure below 75%, and it names no measurement behind it. The README says “~75% of unified RAM” and credits a third-party blog post, which this page did not read, so the claim is unverified here. The honest status is: observed on some Macs, not documented by Apple.
How do I read the real limit on my own Mac?
Read the value your software reports, because that is the number it will actually act on.
- llama.cpp and LM Studio. The log in the LM Studio issue above comes from llama.cpp and prints a line with
recommendedMaxWorkingSetSizeand a “free” MiB figure for the Metal device. Run your model and read that line in the log. Whether Ollama prints the same line is unknown here. - MLX. The MLX source file device_info.cpp builds a device info dictionary that includes
max_recommended_working_set_size(taken from Metal’srecommendedMaxWorkingSetSize) andmemory_size. In Python,mx.device_info()returns that dictionary, per the source and the MLX issue 3849 thread, which saysmx.device_info()["resource_limit"]reports a value in use. Divide the first number by the second to get your Mac’s own fraction. - The kernel setting. The devnote README names a kernel key,
iogpu.wired_limit_mb, and says a value of 0 means the system default (it says “~75%”). Reading a value does nothing to your system, but what the key does on your macOS version is documented by no Apple page this site has read. This page does not give a command to change it. The README itself says such changes are “unsupported” by Apple, that “future macOS updates may alter behavior”, and that if memory pressure turns yellow or red you should lower the cap. Treat any raise as an experiment at your own risk.
Do MLX and llama.cpp apply extra limits on top?
MLX does: it derives its own allocator limits from the Apple-reported figure.
In MLX’s allocator.cpp (main branch, read 2026-10-13), the allocator sets block_limit_ = std::min(1.5 * max_rec_size, 0.95 * memsize) and gc_limit_ = std::min(static_cast<size_t>(0.95 * max_rec_size), block_limit_), where max_rec_size is max_recommended_working_set_size. So MLX’s own limit can exceed the recommended size, capped at 95% of installed memory, and its cache clean-up point sits at 95% of the recommended size. Those are MLX implementation choices at that commit and can change. What happens on a Mac when a load goes past either number is unknown here; the symptoms people report are collected on ollama-out-of-memory-mac and mac-kernel-panic-llm.
Is the “499000” Metal error the same limit?
No. The error [metal::malloc] Resource limit (499000) exceeded counts Metal resources, not bytes. MLX issue 3849 is about that count (the key iogpu.rsrc_limit), not about a memory fraction. See metal-malloc-resource-limit.
How should I size a model if the limit is unknown?
Compare the model total against your own reported figure, not against installed memory.
Use total_GB = weights_GB + kv_GB + overhead_GB, with weights_GB = params × bits / 8 / 1e9 and the 2 GB overhead assumption from methodology. Then compare total_GB with your reported max_recommended_working_set_size converted to decimal GB (bytes / 1e9). Worked example: Qwen2.5-7B-Instruct at 4.0 bits and context 4096 totals 6.040 GB on how-much-ram-for-local-llm. On the 48 GiB log above the reported limit is 38654.71 MB, or 38.65 GB, so the total is below it. The table on what-fits-my-ram compares to installed memory, so a row close to installed memory can still fail. The CPU-versus-GPU memory view is on unified-memory-vs-vram, and the discrete-GPU version is VRAM requirements on the sister site. Speed is not covered here and is unknown; measure your own Mac with measure-tokens-per-second-mac.
Questions
How much unified memory can the GPU use on a Mac?
Apple does not state a figure. Metal reports a “recommended” working set per device, and reporters on 48 GiB and 64 GB Macs saw 0.75 of installed memory. For your own Mac the value is unknown until you read it from llama.cpp’s log or MLX’s mx.device_info().
What is iogpu.wired_limit_mb?
It is a kernel key that a third-party README says controls how much memory the GPU may wire, with 0 meaning the system default. No Apple page read for this site documents it, so its effect is unverified. This page does not recommend changing it.
Is only 75% of unified memory usable for an LLM?
On two reported Macs the GPU figure was 0.75 of installed memory, and a README states “~75%“. It is not documented by Apple, and it describes the GPU’s recommended working set, not everything the system can allocate. Treat 75% as an observation, not a rule.
How much of my Mac’s RAM can a local LLM use?
Unknown as a general number. Read recommendedMaxWorkingSetSize from your tool’s log or max_recommended_working_set_size from mx.device_info(), and keep the model total below it with room for macOS and your apps.
What is recommendedMaxWorkingSetSize?
A Metal device property that Apple describes as “an approximation of how much memory, in bytes, this GPU device can allocate without affecting its runtime performance.” It is a performance recommendation, and Apple’s page gives no percentage.
Is the Metal resource limit error the same as running out of GPU memory?
No. The 499000 figure in [metal::malloc] Resource limit (499000) exceeded is a count of resources, not bytes, as covered on metal-malloc-resource-limit.
Is it safe to raise the GPU memory limit?
Unknown. The README that describes raising it calls the change unsupported, says future macOS updates may alter behavior, and tells readers to leave 8 to 16 GB for macOS. This site has not tested it and gives no command.
Sources read on 2026-10-13
- Apple: recommendedMaxWorkingSetSize: the definition quoted above; no fraction stated.
- LM Studio bug tracker issue 271: llama.cpp log values for a 48 GiB MacBook Pro and a 64 GB report (reporter data).
- MLX issue 3849: about the resource count limit; mention of
mx.device_info(). - MLX device_info.cpp: the device info keys and the
iogpu.rsrc_limitread. - MLX allocator.cpp: the 1.5, 0.95 and 0.95 factors in the allocator.
- devnote-override-macos-metal-vram-cap README: the “~75%” claim, the example table, the
iogpu.wired_limit_mbkey and the stated risks. An unverified third-party source. - methodology and how-much-ram-for-local-llm: the fit formulas and the 7B example total.