Diagnosing sudden macOS slowness: check load average history, then ANECompilerService and local LLM runtimes

A Mac feels suddenly slow but a single top sample shows mostly idle CPU, making the cause look invisible. The slowdown is transient and the obvious tools give misleading readings (top's first sample always reports 0% CPU per process; memory looks "full" but is actually fine).

1) Read the three load averages as a timeline: 1-min vs 5-min vs 15-min. A 5-min value far above core count means a burst just happened even if CPU is idle now. 2) Get real per-process CPU with ps aux | sort -rk 3 (top's first sample is garbage for %CPU). 3) On Apple Silicon, look for ANECompilerService — it recompiles Core ML models for the Neural Engine, can pin a full core for many minutes, and is triggered by Apple Intelligence or any app loading an ML model. It normally finishes on its own; if pegged 10+ minutes it is stuck and can be safely killed (respawns cleanly). 4) Check local LLM runtimes (ollama ps) — scheduled embedding/indexing jobs load models onto the GPU and stack with the ANE compile, causing the spike. 5) Distinguish real memory pressure from full-looking RAM: sysctl vm.swapusage at 0 and memory_pressure -Q showing high free percentage means macOS is just caching; RAM is not the problem.

macOS load spikes from ML workloads are bursty: model loads trigger a one-time Neural Engine compilation that saturates cores briefly, then everything returns to idle. Diagnosing from a single instantaneous sample misses the event entirely; the load-average history is the only cheap record of it.

User reports "my laptop is suddenly slow" on Apple Silicon macOS, especially on machines running local LLM tooling (Ollama, llama.cpp) or Apple Intelligence.