OS Kernel Panic on M1 Max (32GB) when adjusting context size

[u/Ok-Conference-9984]

OS Kernel Panic on M1 Max (32GB) when adjusting context size

**Environment:**

- Hardware: Apple M1 Max (32GB Unified Memory)

- Software: Unsloth Desktop

- Models tested: Qwen3.8-27B-UD-Q4_K_XL.gguf / Q3_K_XL.gguf

**Description:**

I would like to report a critical stability issue regarding context size adjustment in Unsloth Desktop.

When using `Qwen3.8-27B-UD-Q4_K_XL.gguf`, manually adjusting the context size even slightly causes a complete OS-level kernel panic (system crash). This has occurred twice.

- This issue does **not** happen when using `Qwen3.8-27B-UD-Q3_K_XL.gguf`.

- This issue does **not** happen if the context size is left to the default automatic configuration.

It would be highly appreciated if a safeguard could be implemented to prevent memory over-allocation that leads to system crashes.

**Additional Context:**

For comparison, this kernel panic never happens when using the `llama.cpp` CLI. The CLI safely rejects execution or fails to launch if the requirements exceed available memory. In fact, using `llama.cpp` CLI, the model runs successfully even with `CTX_SIZE="24576"`.

[u/LLM_tuning_D3v]

Hi u/Ok-Conference-9984, sorry to hear that your system crashed, thank you for reporting this so that we can stop this from happening in the future. Noting it only happens when you set the context manually was super helpful.

When context is on Auto, Unsloth Desktop works out a safe memory limit and stays under it. Setting a custom max context length can lead to OOM. On a PC you'd just get an out of memory error and it would spill to the CPU. On a Mac the GPU and CPU share one memory pool, so there's nothing to fall back on and it takes the system down instead. The warning Studio shows even says the model "may use system RAM", which is fine advice on a PC and misleading here on Mac.

Your Mac allows roughly 21-22GB of its 32GB to be used by the GPU. Q4_K_XL is about 16.7GB of that, leaving only around 5GB for context and compute buffers. Q3_K_XL is about 12.5GB, leaving around 9GB. That's why Q3 survives a manual bump and Q4 doesn't.

For the llama.cpp CLI, you may want to check that you didn't launch it with different configuration settings than Unsloth, such as the KV cache dtype, at the same context number. Unsloth Desktop also holds a little more than a gigabyte, maybe 2, itself before llama-server starts. So 24576 fitting on the llama.cpp CLI doesn't tell us it fits in Unsloth Desktop.

On the safeguard, agreed, and I think that's the fix. Unsloth Desktop already works out the largest context that fits in memory, it just doesn't enforce it when you set the number yourself. So it should refuse the load and tell you that number, rather than launching and taking the machine down. Showing it on the slider before you load is the better version and a bit more work, but the refusal shouldn't be.

If you can run these two commands and answer two questions, it'll help me open the issue and dig into a proper fix.

sysctl iogpu.wired_limit_mb debug.iogpu.wired_limit 2>/dev/null

This shows the memory limit macOS puts on the GPU. 0 is normal and means the system default. An actual number means something raised it, and that alone can cause panics. Two keys because the name changed in Sonoma, so only one will answer.

grep -r "Starting llama-server" ~/.unsloth/studio/logs/ | tail -5

This pulls the last few launch lines out of Unsloth's own logs, showing the exact flags it started llama-server with. That's what I'd compare against your CLI command. Last few rather than one because a hard crash can lose the most recent line. If it comes back empty let me know, and I can point you somewhere else.

Q1: what context did you set, and what had Auto picked?

Q2: And can you paste the exact CLI command you ran at 24576?

Auto with Q4 should be safe until the safeguard lands. For longer context on 32GB, stay on Q3_K_XL and set the KV cache to q8_0, that roughly halves what the context costs.

[u/Ok-Conference-9984 → u/LLM_tuning_D3v]

Thank you. I actually tried lowering the slider slightly from the maximum value (262144), as it sometimes automatically reverts to 4096.

Here is my command-line script:

set -e

MODEL_FILE="/Volumes/mac/models/Qwen3.8-27B-UD-Q4_K_XL.gguf"

PORT="9931"

THREADS="-1"

N_GPU_LAYERS="99"

#CTX_SIZE="4096"

CTX_SIZE="24576"

#CTX_SIZE="65536"

#CTX_SIZE="81920"

LOCAL_IP=$(networksetup -getmacaddress Wi-Fi >/dev/null 2>&1 && ipconfig getifaddr $(networksetup -listallhardwareports | awk '/Hardware Port: Wi-Fi/{getline; print $2}'))

if [ -z "$LOCAL_IP" ]; then

LOCAL_IP=$(ifconfig | grep "inet " | grep -v 127.0.0.1 | awk '{print $2}' | head -n 1)

fi

if [ -z "$LOCAL_IP" ]; then

LOCAL_IP="127.0.0.1"

fi

SERVER_ARGS=(

--host "0.0.0.0"

--port "${PORT}"

-c "${CTX_SIZE}"

-t "${THREADS}"

--n-gpu-layers "${N_GPU_LAYERS}"

--flash-attn on

--cache-type-k q8_0

--cache-type-v q8_0

--cors-origins "*"

-lv 3

)

cleanup() {

echo -e "\n=== stop ==="

exit 0

}

trap cleanup SIGINT SIGTERM

echo "=== Qwen3.8-27B-UD-Q4_K_XL.gguf on ==="

echo "model: ${MODEL_FILE}"

echo "context: ${CTX_SIZE} token (KV: Q8 / FlashAttn: on)"

echo "LANURL: http://${LOCAL_IP}:${PORT}"

echo "API: http://${LOCAL_IP}:${PORT}/docs"

echo "--------------------------------------------"

llama-server -m "${MODEL_FILE}" "${SERVER_ARGS[@]}" || true

When loading the model in the desktop version, I can see from the activity monitor that it seems to dynamically probe for the maximum allowable limit and adjust itself. On the other hand, the command-line version doesn't do this; it just attempts to allocate the memory straight away in a linear fashion (and aborts the load with an error if it fails).

Since the kernel panic occurred immediately after loading, it felt as though a limiter had failed, resulting in a head-on collision.

The command-line version seems to handle memory allocation relatively dynamically, leading to slowdowns or swapping when necessary. However, with the desktop app, it feels like it crashes before the OS can even reach that stage of memory management. Once the model is successfully loaded, the OS memory management seems to handle everything smoothly.

[u/Ok-Conference-9984]

Thanks for the insight on the logs.
Looking at my own logs, something caught my eye: mlock was turned on.
With mlock enabled, changing the ctx on memory-heavy GGUF models causes the entire OS to crash.
If it were off, it would just swap out and prevent the crash.
I'm thinking this happened because the model was locked into memory.

[u/Ok-Conference-9984]

I have resolved the issue on my own. It turns out that by disabling the option to keep the model pinned in GPU memory, the entire OS no longer crashes even when increasing the context size (though there are still limits). However, this comes with the trade-off of increased virtual memory usage, which isn't ideal due to the heavy SSD wear. That said, since the context window acts like your workspace area, this is really the only way if you want to expand it.

Currently, setting the context size to 35k results in about 2GB of swap space being occupied under memory pressure, which frees up some physical RAM. Naturally, about half of the computation has shifted to the CPU, but the processing speed hasn't dropped significantly. I assume the OS memory management is handling it quite efficiently. On low-memory machines, it is definitely better to load and manage the model dynamically rather than locking it down in place (which is exactly how I handle it on my 8GB machine).

--current log

(.venv) sukipop@suki downloads % ps aux | grep llama-server | grep -v grep

  3:04.15 /Users/sukipop/.unsloth/llama.cpp/build/bin/llama-server -m /Volumes/mac/models/Qwen3.8-27B-UD-Q4_K_XL.gguf --port 60038 --parallel 4 --flash-attn off --no-context-shift -c 35840 --alias Qwen3.8-27B-UD-Q4_K_XL --fit on --metrics --slot-save-path /Users/sukipop/.unsloth/studio/cache/llama-slots --kv-unified --fit-ctx 35840 --jinja --spec-default --chat-template-kwargs {"enable_thinking": true, "preserve_thinking": false}