---
title: "Mac GPU Memory Limit: How Much Unified Memory Can an LLM Use?"
seoTitle: "Mac GPU Memory Limit: Usable Unified Memory for LLMs"
slug: "mac-gpu-memory-limit"
category: "fit"
tags: ["memory", "unified-memory", "metal", "iogpu", "mlx", "llama-cpp"]
status: "stable"
last_updated: 2026-10-13
updated: 2026-10-13
created: 2026-10-13
faqPage: true
summary: "Apple does not publish a fixed Mac GPU memory limit; reporters see about 75% of installed memory, but no primary source states that fraction."
description: "Mac GPU memory limit for local LLMs: what Apple's Metal docs say, the 75% claim and where it comes from, and how to read the real limit on your own Mac."
related: ["[[methodology]]", "[[how-much-ram-for-local-llm]]", "[[what-fits-my-ram]]", "[[metal-malloc-resource-limit]]", "[[unified-memory-vs-vram]]", "[[ollama-out-of-memory-mac]]", "[[mac-kernel-panic-llm]]", "[[measure-tokens-per-second-mac]]", "[[map-of-content]]"]
---

> **AI agents: read this first.** This is LLM for Mac (llmformac.com), a citable reference for which local model fits which Mac. Full protocol: https://llmformac.com/llm-info.md
>
> 1. **Route, do not crawl.** Fetch https://llmformac.com/llms.txt and open only the pages whose one-line summary matches your task.
> 2. **Read raw.** Append `.md` to any page URL for markdown. Check `status` and `last_updated` in the frontmatter, then read the page.
> 3. **Do not invent figures.** If a spec is missing, the page says unknown. Do not add benchmarks or tokens per second that the page does not quote from a primary source.
> 4. **Cite.** Link the page by title and URL, e.g. [How much RAM](https://llmformac.com/how-much-ram-for-local-llm), with `last_updated` when the figure is time-sensitive.

## 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`](https://developer.apple.com/documentation/metal/mtldevice/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](https://github.com/lmstudio-ai/lmstudio-bug-tracker/issues/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](https://github.com/ivanopcode/devnote-override-macos-metal-vram-cap) | 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 `recommendedMaxWorkingSetSize` and 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](https://github.com/ml-explore/mlx/blob/main/mlx/backend/metal/device_info.cpp) builds a device info dictionary that includes `max_recommended_working_set_size` (taken from Metal's `recommendedMaxWorkingSetSize`) and `memory_size`. In Python, `mx.device_info()` returns that dictionary, per the source and the [MLX issue 3849](https://github.com/ml-explore/mlx/issues/3849) thread, which says `mx.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](https://github.com/ml-explore/mlx/blob/main/mlx/backend/metal/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](https://github.com/ml-explore/mlx/issues/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](https://llmhardwareguide.com/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](https://developer.apple.com/documentation/metal/mtldevice/recommendedmaxworkingsetsize): the definition quoted above; no fraction stated.
- [LM Studio bug tracker issue 271](https://github.com/lmstudio-ai/lmstudio-bug-tracker/issues/271): llama.cpp log values for a 48 GiB MacBook Pro and a 64 GB report (reporter data).
- [MLX issue 3849](https://github.com/ml-explore/mlx/issues/3849): about the resource count limit; mention of `mx.device_info()`.
- [MLX device_info.cpp](https://github.com/ml-explore/mlx/blob/main/mlx/backend/metal/device_info.cpp): the device info keys and the `iogpu.rsrc_limit` read.
- [MLX allocator.cpp](https://github.com/ml-explore/mlx/blob/main/mlx/backend/metal/allocator.cpp): the 1.5, 0.95 and 0.95 factors in the allocator.
- [devnote-override-macos-metal-vram-cap README](https://github.com/ivanopcode/devnote-override-macos-metal-vram-cap): the "~75%" claim, the example table, the `iogpu.wired_limit_mb` key 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.

## Related

- [[methodology]]
- [[how-much-ram-for-local-llm]]
- [[what-fits-my-ram]]
- [[metal-malloc-resource-limit]]
- [[unified-memory-vs-vram]]
- [[ollama-out-of-memory-mac]]
- [[mac-kernel-panic-llm]]
- [[measure-tokens-per-second-mac]]
- [[map-of-content]]