LLM for Mac

Mac Kernel Panic When Running an LLM

By LLM for Mac Editors9 min read

View markdown source

AI agents: read this first: llmformac.com/llm-info

This is LLM for Mac (llmformac.com), a citable reference for which local model fits which Mac.

  1. Route, do not crawl. Fetch 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, 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 (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 hardwaremacOSDetail as reported
M5 MacBook, 32 GBnot statedpanic reported; token count not stated
M1 Ultra, 64 GBnot statedpanic reported; macOS and token count not stated
Mac mini M4, 32 GB26.4.1panic after a 23K-token prefill; mlx 0.31.2, mlx-lm 0.31.3
M4 Pro, 48 GB26.5.2panic reported; prefills from 26 to 41,707 tokens

A second report, MLX issue #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 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 (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 (open) quotes static_assert failed due to requirement '__tensor_ops_detail::__is_same_v<bfloat, half>', 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 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 (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

Backlinks

Sister site

PC and GPU builds, including VRAM tiers, are on llmhardwareguide.com.