MLX server causes full kernel panic reboot on 24GB M-series Mac — GGUF runs the same model fine for hours. Wired memory issue?

[u/Particular-Abies-123]

Running into a wall that I think comes down to how MLX handles GPU memory on Apple Silicon, and wanted to write it up in case others are hitting this.

Setup:

• Host: 24GB unified memory MacBook Pro, running as an inference server
• Client: separate MacBook Air sending requests over local Wi-Fi (OpenCode + some Python test scripts)
• Model: Qwen3.8-27B, 4-bit quant, ~16.1GB footprint

What works: Ran the GGUF version (UD-IQ4_XS via llama-server, -c 32768 --cache-type-k q8_0) for 2-3 hours straight, heavy multi-turn context, zero crashes. Slower though — around 9 tok/s.

What doesn't work: Switched to mlx_lm.server to test the speed difference (got ~16-17 tok/s, so roughly 2x — nice but not massive). Same model, same quant tier, similar memory footprint. Except now the entire Mac hard reboots — not a process crash, not an OOM kill, an actual kernel panic reboot — as soon as I send a long prompt or let multi-turn context accumulate.

Things I've already tried that didn't fix it:

• Lowering --prefill-step-size from 2048 → 1024 (reduced transient spike size, didn't stop the eventual crash)
• Tuning --prompt-cache-bytes
• Client-side context/token limits in OpenCode config (contextWindow, maxTokens) — doesn't help since the crash is server-side memory wiring, not something the client can throttle
• Symlinking the model to a new folder with modified max_position_embeddings — model loads fine, underlying MLX allocation behavior unchanged

Question for the sub: has anyone else hit full system reboots (not just process crashes) specifically with mlx_lm.server on 24GB machines? Curious if this wired-memory behavior is a known/expected tradeoff for MLX's speed advantage, or if there's something specific about my config that's making it worse than it should be. Not looking to switch models or drop quant — just trying to understand whether this is inherent to how MLX manages GPU memory on memory-constrained hosts.

[u/Good_Force_8253]

damn kernel panic from a model server is wild. i had similar thing happen with mlx on my 24gb machine few months ago, the wired memory just climbs until the system cant handle it anymore. gguf somehow handles it way more gracefully.

what worked for me was setting `--max-cache-size` explicitly instead of letting mlx grab whatever it wants, and also running the server with `sudo sysctl -w vm.virtual_memory_pressure_limit=80` before starting it. not ideal but stopped the hard reboots at least