I loaded a candidate model on my 64 GB Mac Studio to see how it handled one reasoning task. The machine already had two servers resident, a 35B and a 27B, and I did not check the memory pressure before I started. The metrics spiked, the operating system reached for the largest evictable thing to make room, and it killed one of the resident servers, which then cold-reloaded. That eviction was the moment I decided the jobs that must always be up should not live on a machine that can evict them.
A playground and a factory on one machine
The Studio is my interactive box. It holds one large model at a time in the swap slot and loads it behind a router, which is fine when I am at the desk and can wait out a cold load; I wrote up how that scheduling works in scheduling one big model on the 64 GB Studio. It is a bad fit for the work that runs whether I am there or not. A nightly lint pass and a morning brief cannot wait for a server to restart, and they cannot be the thing the machine drops when I overcommit it during a test.
I had been asking one box to be two things at once: a playground I poke at all day and a factory that has to keep running at night. Those want opposite behavior. The playground should change state every time I touch the keyboard. The factory should never change state at all.
The mini: one model it never swaps
So I bought a Mac mini with an M4 chip. It sits on a shelf with a power cable and a network cable, no display and no keyboard. It stays on, and it serves exactly one model that it never swaps: a Qwen3.5 9B with 4-bit MLX weights, about 5.6 GB, thinking disabled and temperature set to 0. It is not behind the Studio's router. The jobs that need it call it directly. It does not load-balance and it does not fail over. It answers.
The mini runs three jobs, all unattended. It is the tertiary fallback summarizer for my wiki ingest: when the Studio's models are busy, the pipeline sends the summary to the mini instead, which is slower but always reachable, and the ingest waits on it without caring about the latency. It runs a semantic lint over my wiki every night at 5:15 AM, scanning the tree for duplicate pages, contradictions, and stale claims. And it narrates the estate status brief that lands in my inbox each morning, turning the previous day's raw signals into prose I read on my phone.
If any of those three lived on the Studio, they would compete for memory with whatever I left running the night before, and the operating system does not know that a 5:15 AM lint pass matters more than an idle terminal. On the mini, the lint pass is the only thing running, so it gets the whole machine and finishes.
Weaker on purpose
The 9B on the mini is smaller and weaker than the 35B on the Studio, and that is deliberate. These are summaries, a lint pass, and a status narration; they do not need frontier reasoning or a long chain of thought. They need to be up at 5:15 AM without me watching. A smaller model holds less memory, less memory means less pressure, and less pressure means nothing gets evicted.
I measure this one by what stops happening: no timeout errors in the ingest logs, no partial lint reports, no missing morning email. For a while I assumed the answer was more power, a faster machine or more RAM on the Studio. More RAM would have raised the ceiling, not removed the competition. The real fix was a second, cheaper machine that does one job and holds still. The two boxes do not talk to each other, share memory, or share fate. I watch the Studio's memory pressure when I test models, and I never watch the mini, because it is a box on a shelf that answers when the pipeline calls it, at 5:15 AM and while I am asleep.