--- title: "Mac Kernel Panic When Running an LLM" seoTitle: "Mac Kernel Panic Running an LLM: MLX and Metal Errors" slug: "mac-kernel-panic-llm" category: "troubleshooting" tags: ["kernel-panic", "metal", "mlx", "ollama", "errors"] status: "stable" updated: 2026-10-13 last_updated: 2026-10-13 created: 2026-10-13 faqPage: true summary: "A Mac kernel panic while running an LLM has no confirmed fix: MLX reports name Apple's GPU driver, and the cause is unknown. Error strings and workarounds." description: "Mac kernel panic running an LLM? Match your error string to the MLX, llama.cpp and Ollama issue threads, with the chip and macOS version each report names." related: ["[[metal-malloc-resource-limit]]", "[[ollama-out-of-memory-mac]]", "[[local-llm-slow-on-mac]]", "[[mlx-lm-on-mac]]", "[[ollama-on-mac]]", "[[mac-gpu-memory-limit]]", "[[long-context-on-mac]]", "[[methodology]]", "[[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 A Mac kernel panic running an LLM has no confirmed fix, and the cause is unknown: an MLX maintainer wrote "we don't really have a fix" in one thread, merged a second report into an open bug, and no thread states a cause. This page matches the exact error text you see to the public issue thread that contains it, and repeats only what each thread states about chip, macOS version and workaround. Everything below is from user and maintainer comments, read on 2026-10-13. It is not tested by this site, and it gives no speed figures. ## Why does my Mac kernel panic when running an LLM? The reports below describe a panic string from Apple's GPU kernel extension, not an error from the model. [MLX issue #3186](https://github.com/ml-explore/mlx/issues/3186) (open) is titled "Kernel panic (IOGPUMemory.cpp:550) on M4 Max with large context prefill (~173K tokens)". The reporter used an M4 Max with 36 GB on macOS 26.3 with a prefill of about 173,000 tokens, and filed an Apple Feedback report (FB22091885). The maintainer action in the thread is a `bug` label; no cause is stated. The same string was later reported on other hardware in that thread: | Reported hardware | macOS | Detail as reported | | --- | --- | --- | | M5 MacBook, 32 GB | not stated | panic reported; token count not stated | | M1 Ultra, 64 GB | not stated | panic reported; macOS and token count not stated | | Mac mini M4, 32 GB | 26.4.1 | panic after a 23K-token prefill; mlx 0.31.2, mlx-lm 0.31.3 | | M4 Pro, 48 GB | 26.5.2 | panic reported; prefills from 26 to 41,707 tokens | A second report, [MLX issue #3346](https://github.com/ml-explore/mlx/issues/3346) (closed 2026-04-01), describes a Mac Studio M3 Ultra with 96 GB on macOS 26.4 running a roughly 50 GB MLX model, with 9 panics in 6 days. It quotes `"completeMemory() prepare count underflow" @IOGPUMemory.cpp:550` (the same file and line as #3186) and `"Memory object unexpectedly not found in fPendingMemorySet" @IOGPUGroupMemory.cpp:219`. The maintainer merged it into #3186 and noted it was reported on 26.3, so it is "not a new bug in 26.4". A later comment there reports the same panic on a MacBook Air M5 with 24 GB on macOS 26.5.2. Because panics are reported on machines from 24 GB to 96 GB, and at about 23K tokens as well as 173K, installed memory alone does not appear to predict them (one commenter in #3186 argues the bug is not tied to oversized single allocations). Whether a given size or context triggers one is unknown. Context memory itself still follows the KV formula on [[methodology]] and [[long-context-on-mac]]. ## What does kIOGPUCommandBufferCallbackError mean? It is the prefix of a Metal GPU command-buffer failure, followed by a reason name such as Hang, ImpactingInteractivity or InnocentVictim. Apple's meaning for each is unknown here: this site found no Apple page defining them. [llama.cpp issue #20141](https://github.com/ggml-org/llama.cpp/issues/20141) collects the strings: - `kIOGPUCommandBufferCallbackErrorHang`, with `ggml_metal_synchronize: error: command buffer 1 failed with status 5`, reported on an M4 Pro, 48 GB, macOS Tahoe 26.3. - `kIOGPUCommandBufferCallbackErrorImpactingInteractivity`, reported on an M1 Max, macOS 26.4, at around 71,000 tokens of context. - `kIOGPUCommandBufferCallbackErrorInnocentVictim`, followed by `llama_decode: failed to decode, ret = -3`, reported on an M1 Max, 64 GB, macOS 26.4.1. The thread says the original crash happened when layers were offloaded to the GPU (`-ngl > 0`) and CPU-only (`-ngl 0`) worked. The maintainer suggested `AGX_RELAX_CDM_CTXSTORE_TIMEOUT=1`, and the issue was closed on 2026-04-21 by PR #22216 after he wrote "I've forced ggml to override the env variable for now so it should not be needed to be done by the user." No cause is stated. It is not settled: a September 2026 comment reports it again on an M4 Pro, 24 GB, macOS 26.6.2, stable on 26.5 and failing after the 26.6 update, and the reporter used a supervisor that restarts the process as a workaround. That is one user's report. ## What is the AGX_RELAX_CDM_CTXSTORE_TIMEOUT workaround? It is an environment variable that an MLX maintainer suggested as something to try, and its effect is not documented in the thread. In [MLX issue #3267](https://github.com/ml-explore/mlx/issues/3267) (open, labelled `wontfix`) the maintainer wrote "this behavior is controlled by OS" and "we don't really have a fix". The original reporter, on an M2 Pro with 16 GB, said it completely resolved the failure; the crash occurred only with the display active. A later reporter on an M5 Max, 128 GB, macOS 26.5.1 still got a full system reboot with the variable set while the display was active, and the run finished with the display asleep. A "watchdog timeout: no checkins from watchdogd in 93 seconds" panic is quoted there. The same variable was suggested by the llama.cpp maintainer in #20141 and is now set by ggml itself. Treat the variable as a user-reported mitigation, not a fix. In MLX #3186, an M3 Ultra user (96 GB, macOS 27.0 beta) reported no panics over two days with the `set_wired_limit` mitigation, and a Mac mini M4 user reported no panic in 10 runs when `mx.set_wired_limit` was never called. These are user workarounds; the commenter said wiring enabled was not tested on that driver, so they do not show the bug is fixed. ## Why does Ollama fail with a Metal compiler error on an M5? The Ollama threads show a Metal shader build failure on M5 chips, with no maintainer-stated cause. [Ollama issue #14432](https://github.com/ollama/ollama/issues/14432) (open) quotes `static_assert failed due to requirement '__tensor_ops_detail::__is_same_v'`, `ggml_metal_init: error: failed to initialize the Metal library`, starting with Ollama 0.17.0 on M5 hardware. These are Ollama runtime errors, not macOS kernel panics. A contributor (not a maintainer) proposed a diff for a half/bfloat type mismatch, and the thread shows it as not merged. [Issue #15448](https://github.com/ollama/ollama/issues/15448) reports `500 Internal Server Error: llama runner process has terminated` with Metal shader compilation failures in the log, on M5 Macs with macOS 26.3.1 and Ollama 0.20.4, even with CPU-only settings. One commenter suspects a Metal shader (`kernel_rope_multi`) with an uninitialized variable; that is a hypothesis. User-reported workarounds, none confirmed by maintainers: downgrading to Ollama 0.20.3; updating to macOS 26.4.1 with Ollama 0.20.6 or later; installing with the install script from ollama.com instead of Homebrew (#14432). `OLLAMA_LLM_LIBRARY=cpu` did not help, because Metal initialization still runs first. See [[ollama-on-mac]]. ## Why does my local LLM output gibberish on a Mac? One documented case was an outdated MLX. [mlx-lm issue #856](https://github.com/ml-explore/mlx-lm/issues/856) (closed by the reporter 2026-02-09) reported corrupted tokens from Qwen3-Coder-Next-4bit on a Mac Studio (M2) with a 13,465-token prompt, while shorter prompts worked. A maintainer could not reproduce it and said he was "fairly certain" the reporter had an old MLX. Upgrading to mlx 0.30.6 fixed it for the reporter. Other gibberish reports have no stated cause here, and no thread says gibberish and panics share one. ## What should I try first? These steps come from the threads, not from tests on this site: 1. Update mlx and mlx-lm (`python -m pip install -U mlx`), or Ollama and llama.cpp, before anything else. 2. Note your macOS version. Reports span 26.2 through 26.6.2, and one thread reports a regression after 26.6; that is a user report. 3. Shorten the prompt or context and see if the error moves. This is a diagnostic, not a fix. 4. Run CPU-only (`-ngl 0` in llama.cpp) to separate GPU faults from model faults. 5. After a panic, report it with the exact string, chip, RAM, macOS build and tool version. Out-of-memory failures look different; see [[ollama-out-of-memory-mac]] and [[metal-malloc-resource-limit]]. Slowness without a crash is [[local-llm-slow-on-mac]]. The popular Hacker News story about garbage MLX output, item 46849258, concerns an iPhone 16 Pro Max, not a Mac. ## Questions ### Why does my Mac kernel panic when running an LLM? The public reports name Apple's GPU driver strings (`completeMemory() prepare count underflow` in IOGPUMemory.cpp), seen on M1 Ultra, M3 Ultra, M4, M4 Pro, M4 Max and M5 machines with macOS 26.x. The cause is unknown and no maintainer fix is stated in the MLX threads. ### What does kIOGPUCommandBufferCallbackError mean? It prefixes a Metal GPU command-buffer failure such as Hang, ImpactingInteractivity or InnocentVictim. Apple's definition is unknown here. llama.cpp #20141 collects reports of all three and was closed by a change that forces a timeout variable, though later users reported it again. ### Is a Mac kernel panic from an LLM caused by running out of memory? Not established. No maintainer states a cause in MLX #3186, and one commenter there argues the bug is not tied to oversized allocations. Panics were reported on machines from 24 GB to 96 GB. Memory fit still matters; use the formulas on [[methodology]]. ### Why does Ollama fail with a Metal compiler error on an M5? Ollama #15448 reports Metal shader compilation failures on M5 Macs with macOS 26.3.1 and Ollama 0.20.4, with no maintainer-stated cause. Users report downgrading to 0.20.3, or macOS 26.4.1 with Ollama 0.20.6 or later, helped. Those are user reports, not maintainer-confirmed. ### Why does my local LLM output gibberish on a Mac? In mlx-lm #856 an old MLX was the stated cause, and upgrading to 0.30.6 fixed the reporter's output. Other gibberish reports have no stated cause. ### Does macOS Tahoe cause local LLM problems? Most reports in these threads name macOS 26.x, but one maintainer said a panic was "not a new bug in 26.4" since it was reported on 26.3. Whether Tahoe itself is the cause is unknown. ### How fast is it after fixing the crash? Unknown. This site publishes no speed numbers; measure your own Mac with [[measure-tokens-per-second-mac]]. ## Sources read on 2026-10-13 - [ml-explore/mlx #3186](https://github.com/ml-explore/mlx/issues/3186): panic title, string, M4 Max 36 GB report, later hardware reports, Apple Feedback ID, absence of maintainer cause. - [ml-explore/mlx #3346](https://github.com/ml-explore/mlx/issues/3346): M3 Ultra 96 GB report, second error string, maintainer merge comment, M5 Air comment. - [ml-explore/mlx #3267](https://github.com/ml-explore/mlx/issues/3267): AGX_RELAX_CDM_CTXSTORE_TIMEOUT suggestion, wontfix quote, M2 Pro and M5 Max reports. - [ggml-org/llama.cpp #20141](https://github.com/ggml-org/llama.cpp/issues/20141): kIOGPUCommandBufferCallbackError variants, chips and macOS versions, maintainer quotes, PR #22216, September 2026 recurrence. - [ollama/ollama #14432](https://github.com/ollama/ollama/issues/14432) and [#15448](https://github.com/ollama/ollama/issues/15448): Metal error strings, M5 reports, versions, user workarounds. - [ml-explore/mlx-lm #856](https://github.com/ml-explore/mlx-lm/issues/856): gibberish report and the mlx 0.30.6 fix. - [Hacker News item 46849258](https://news.ycombinator.com/item?id=46849258): confirmed to be about an iPhone; no figures used. - [[methodology]]: KV and memory-fit formulas. ## Related - [[metal-malloc-resource-limit]] - [[ollama-out-of-memory-mac]] - [[local-llm-slow-on-mac]] - [[mlx-lm-on-mac]] - [[ollama-on-mac]] - [[mac-gpu-memory-limit]] - [[long-context-on-mac]] - [[methodology]] - [[map-of-content]]