Overview
The Metal malloc resource limit exceeded error, RuntimeError: [metal::malloc] Resource limit (499000) exceeded., means MLX tried to allocate another Metal buffer after it had already counted its limit of buffers; it is a count of resources, not a count of bytes of free RAM. The number 499000 is a fallback value in MLX’s source, and no single cause explains every crash: the GitHub reports below each trace it to something different, and for some the root cause is not described. This page lists what each primary source says, separates reported workarounds from confirmed fixes, and marks the rest unknown.
What does “[metal::malloc] Resource limit (499000) exceeded” mean?
It means the allocator’s running count of live Metal resources reached its limit when it needed one more. In MLX’s allocator.cpp, malloc checks num_resources_ >= resource_limit_, first tries to release cached buffers, and if the count is still at the limit it throws std::runtime_error with the text [metal::malloc] Resource limit (...) exceeded. The counter goes up when a buffer is created and down when one is freed or released from the cache.
The number comes from device_info.cpp. It reads the sysctl key iogpu.rsrc_limit (the call’s return value is not checked) and, if the value is 0, sets rsrc_limit = 499000. That file does not scale the value by memory. Which Macs read a value from the kernel and which use the fallback is unknown here. The reporter in MLX issue 3849 says sysctl iogpu.rsrc_limit returns “unknown oid” on their system.
Is it an out-of-memory error?
Not in the usual sense, though memory can be involved. The check is on a number of resources. In mlx-lm issue 1644 the reporter had an M1 Max with 64 GB, iogpu.wired_limit_mb set to 61440 (61440 / 1024 = 60 GiB) and a model of about 22 GB, and saw memory peak near 40.2 GiB of that 60 GiB ceiling before the crash. That is the reporter’s reading, not a profile, but it is why they concluded the failure was a count and not exhaustion. If your Mac instead prints a kill message or freezes, that is a different problem: see ollama-out-of-memory-mac, mac-gpu-memory-limit and mac-kernel-panic-llm. For the byte math, use methodology: weights_GB = params x bits / 8 / 1e9, plus KV cache, plus overhead.
Why does mlx-lm crash with metal malloc?
Several different causes have been reported; none is a general rule.
| Report | Setup (as stated) | Stated cause | Status |
|---|---|---|---|
| mlx-lm #831 | mlx_lm.server run distributed, mlx-community/GLM-4.7-Flash-8bit; others reported it on a 128 GB Mac and on a Mac mini with 64 GB via LM Studio | No confirmed cause. A maintainer (angeloskath) wrote “This points towards leaking some buffers or sth along those lines” | Closed Feb 6, 2026; maintainer: “This is fixed in #839” |
| mlx-lm #1644 | single node mlx_lm server, qwen3_5_moe 4-bit, 40k to 75k token prompts, mlx_lm 0.31.3, mlx 0.31.2, macOS 26.4.1 | Reporter’s guess, not profiled: a large prefill chunk touches many distinct expert buffers | Closed Aug 25, 2026 as completed, noted as closed by #1632 |
| mlx-lm PR 1632 | Decode of long generations | Author: ArraysCache.advance() does lazy subtraction each step and the metadata arrays keep the earlier graph (1,280 graph edges after 256 calls in a minimal repro) | Merged Aug 22, 2026 |
| MLX #3849 | Compiled training with varying sequence lengths | Reporter: cumulative mx.compile variants for distinct input shapes | Closed Aug 5, 2026; maintainer kept current behavior |
Issue 831 is the one most searches land on. PR 839 (“DSV3 MLA”) says “Also closes #831”, but its page does not explain how it stops the error. A later report, 1644, is titled as a case where “#839 does not cover this path”, so a fix for one model path did not fix the error everywhere.
How do I fix resource limit exceeded in MLX?
There is no single confirmed fix, so match your case to the report closest to it and update first.
- Update mlx and mlx-lm. PR 1632 (merged Aug 22, 2026) addressed one cause during decode, and 839 addressed one for GLM-4.7-Flash. Which release first contains each is unknown here; check the release notes of the mlx-lm repository.
- If it happens on very long prompts, the 1644 reporter reported that lowering
--prefill-step-sizefrom 2048 to 512 stopped the crashes. That is one user’s workaround on one model, not a documented fix, and the reporter said prefill got slower. This page gives no speed number; measure yours with measure-tokens-per-second-mac. Long prompts also grow memory, covered in long-context-on-mac. - If you write MLX code with
mx.compileand changing input shapes, the 3849 thread reports the compile cache keeping an entry per input shape andmx.clear_cache()not stopping the growth. A contributor there suggestedmx.compile(..., shapeless=True); that was a comment, not confirmed by a maintainer. A maintainer (zcbenz) also wrote that “exceeding the limit clearly indicates some fatal mistakes like the one you found yourselves.” - Do not rely on changing
iogpu.rsrc_limit. In MLX PR 3512, which proposed scaling the fallback with memory, a maintainer said the referenced code reads the limit and does not set it, and was “not sure if it would work” as a sysctl. The PR was closed without merging. Whether the kernel on your macOS version honors it is unknown.
Does it happen in LM Studio?
At least one report says yes. In issue 831 a user running LM Studio with the 8-bit MLX GLM-4.7-Flash model on a 64 GB Mac mini reported the error, and said a GGUF 8-bit build did not error. That is one user’s claim and the issue thread records no further test of that claim. Which LM Studio versions bundle which MLX version is unknown here; the app is described on lm-studio-on-mac, and the mlx-lm-on-mac page covers the server this error comes from.
What is still unknown?
- The mechanism by which #839 stopped the error in issue 831: the PR page does not say.
- Whether the 499000 limit differs by Mac model or macOS version: unknown.
- A safe way to raise the limit: unknown; none is documented in the sources read.
- Whether slow generation is related: unknown. See local-llm-slow-on-mac for the slowness side.
Questions
What does [metal::malloc] Resource limit (499000) exceeded mean?
MLX’s Metal allocator counted its live resources, reached the limit of 499000 and refused to create another buffer. It counts resources, not bytes of RAM. The limit is a fallback in MLX’s device_info.cpp used when the iogpu.rsrc_limit sysctl reads 0.
Why does mlx-lm crash with metal malloc?
Reported causes differ: issue 831 had no confirmed cause and was closed by PR 839, issue 1644 was on long prompts and was closed by PR 1632, which addressed a growing metadata graph in ArraysCache. Which one applies to you is unknown without your versions and command.
How do I fix resource limit exceeded in MLX?
Update mlx and mlx-lm first. For long prompts, one reporter lowered --prefill-step-size from 2048 to 512 and the crashes stopped; for compiled code with varying shapes, a contributor suggested shapeless=True. Neither is a confirmed universal fix.
Is Resource limit exceeded the same as running out of RAM?
No. It is a count of Metal resources. In issue 1644 memory peaked near 40.2 GiB of a 60 GiB ceiling when it crashed, per the reporter. Check your byte needs with methodology anyway.
Can I raise the resource limit with sysctl?
Not as a documented fix. The key iogpu.rsrc_limit is read by MLX, a maintainer was unsure that setting it would work, and one reporter’s system returned “unknown oid”.
Does LM Studio show this error with MLX models?
One user in issue 831 reported it with an 8-bit MLX GLM-4.7-Flash model on a Mac mini with 64 GB. That is a single unverified report.
Sources read on 2026-10-13
- mlx-lm issue 831: error text, setup, comments, closure by #839.
- mlx-lm PR 839: “Also closes #831”; mechanism not stated.
- mlx-lm issue 1644: environment, prefill-step-size workaround, memory peak, closure.
- mlx-lm PR 1632: stated cause in
ArraysCache, merge date. - MLX issue 3849: compile-variant cause, maintainer comments.
- MLX PR 3512: fallback scaling proposal, closed unmerged.
- MLX allocator.cpp and device_info.cpp: the check, the counter, the 499000 fallback.
- methodology: weight and KV formulas.