Two models at once on a 48 GB Mac: an idle second model cut the first from 49.4 tokens a second to 14.5

We loaded two models at once on a 48 GB Mac and asked only one of them to work. With the second model sitting idle beside it, Qwen 3.6 35B-A3B wrote 14.5 tokens a second. With the second model unloaded, the same build on the same prompts wrote 49.4. The two files add up to 40.92 GB, which is under 48 GB, and LM Studio let both load without a warning. The machine paid for it in swap, which reached 26.7 GB during the test.

What happens when you load two models at once on a 48 GB Mac?

Both load, and the one you use gets slow. That is the short answer from one session on 12 October 2026.

The machine is an Apple M4 Pro with 48 GB of memory, running LM Studio 0.4.25 and its llama.cpp engine at version 2.47.0. Gemma 4 31B QAT at Q4_0, an 18.85 GB file, was already loaded at a context length of 8,192. We then loaded Qwen 3.6 35B-A3B at Q4_K_M, a 22.07 GB file, at a context length of 32,768. Before loading, LM Studio’s own estimate for the second model was 22.24 GiB, and its message was that the model “may be loaded” under the resource guardrail setting. The load took 29.4 seconds.

Memory changed at once. Before the second model went in, macOS reported 56 percent of memory free. Afterwards it reported 10 percent, and later 8 percent. Swap in use went from 17.0 GB to 24.1 GB as the model loaded. We should say plainly where that first 17.0 GB came from: both models had been loaded together earlier the same day, and the swap from that had not been released. So the test began on a machine that was already under some strain.

Gemma 4 did nothing during the test. We checked its status before every request and it read idle each time. Every figure below is Qwen 3.6 working alone, with Gemma 4 only occupying memory.

How much slower was the working model with a second one loaded?

Between two and four times slower, depending on the task.

Take the middle run of each set for writing speed. With the second model loaded it is 14.5 tokens a second. Unloaded it is 49.4. That is 3.4 times faster for doing nothing more than removing a model that was not in use.

The long prompt is the one that matters for anyone running a coding agent, because an agent sends a large block of instructions before it does anything. With both models loaded, Qwen 3.6 took 143.6 seconds on the first attempt and 210.7 on the second to begin its reply. Alone it took 73.5 and 76.1. The second attempt under load was slower than the first, which is the opposite of what a warm machine normally does, and swap grew from 23.7 GB to 26.7 GB over the same stretch.

Short steps suffered most in proportion. Once a long prompt is in the cache, a follow-up turn should start almost at once. Alone, Qwen 3.6 started each one in under two seconds and finished the turn in about three. With Gemma 4 loaded, the wait was 5.4 to 9.1 seconds and a turn took 11.9 to 15.7 seconds. A five-step loop that took 15.7 seconds alone took 66.6 with the idle model beside it.

One figure in the right-hand column needs a note. The first run after Gemma 4 was unloaded wrote 39.2 tokens a second and waited 11.8 seconds for its first token. The next two wrote 50.7 and 49.4 and waited under half a second. Our reading is that the machine was still pulling Qwen 3.6 back out of swap during that first request. It recovered within one reply.

Why does an idle second model slow the first one down?

This section is our reading of the figures. We did not trace memory page by page.

A model’s weights have to sit in memory to be used. Two files of 18.85 GB and 22.07 GB come to 40.92 GB before the context for either model, the system and every other open program are counted. On a 48 GB machine that leaves about 7 GB for everything else. When there is not enough, macOS moves pages it judges to be less used into swap on the drive and brings them back when they are needed.

The process sizes show this happening. While Qwen 3.6 worked, its process held 20.4 GB in memory. The idle Gemma 4 process held 14.6 GB, although its file is 18.85 GB, so part of it had been moved out. But the idle model was not the only thing displaced. A model writing a reply touches its weights over and over, and if some of those are in swap, each reply waits on the drive. That would explain why writing speed fell to under a third while nothing else was competing for the processor.

It also explains why the estimate did not help. LM Studio’s check answered the question of whether the second model could load. It could. Whether the first model would still run at its normal speed afterwards is a different question, and nothing in the load step answers it.

How can you tell your Mac is swapping under a local model?

Three commands in Terminal, all of which we ran during this test.

The first shows swap in use:

sysctl vm.swapusage

Ours read 16,986 MB used before the second model loaded and 26,694 MB used at the worst point. A figure that climbs while a model is replying is the sign.

The second gives the share of memory that is free:

memory_pressure

Its last line read 56 percent with one model loaded and 8 percent with two.

The third lists what LM Studio has loaded, with sizes and context lengths:

lms ps

If a model you are not using is in that list, it is costing you. Unload it with lms unload and its name. After we unloaded Gemma 4, free memory went back to 40 percent.

Then measure the speed itself. Our guide to measuring tokens per second in LM Studio shows how to take the figure with a fresh prompt each time, so that a cached prompt does not flatter the result.

Should you keep two models loaded on a 48 GB Mac?

Not two models of this size, on this evidence. Both of ours were around 20 GB. The pair fitted on paper and cost the working model about 70 percent of its writing speed.

A large model with a small one is a different case and we did not test it here. Nor did we test two large models at a short context on a freshly restarted machine, which would be the kindest version of this test. What we can say is narrower. On a 48 GB Mac that has been in use all day, a second 19 GB model left loaded is expensive, even when it is never called.

The practical rule we take from it is to load one large model, check lms ps before a long job, and treat any reading under about 15 tokens a second from Qwen 3.6 35B-A3B on this machine as a memory problem first. The model’s normal figure is far higher. Our index entry for Qwen 3.6 35B-A3B on the M4 Pro records 62.5 tokens a second from the index script, which uses its own prompts and reply lengths, and this test measured 49.4 with a 500-token reply. Either is more than three times what the model managed with company.

The same applies to Gemma 4. Our review of Gemma 4 31B QAT on the M4 Pro and its index entry put it at 11.74 tokens a second with nothing else loaded. That is already a slow model for agent work. Cutting it to a half or a third by leaving another model in memory would make it hard to use at all.

Tools that load models for you make this easy to get wrong. A request that names a model which is not loaded can cause LM Studio to load it. Two agents set to two different models are enough to recreate this test without anyone choosing to.

How did we test this?

One Python script sent every request to LM Studio’s local server on the same machine and read the reply as a stream. It took its own timings from the stream: the wait for the first token, and the tokens written divided by the time spent writing. Temperature was 0. Every fresh prompt began with a new random session line, so no request could be answered from a cached copy of an earlier one.

There were three kinds of request. A short question of about 72 tokens with a 500-token limit on the reply, sent three times. A long prompt of 20,033 tokens, made of reference text, eight tool definitions and one question, sent twice. And five follow-up turns of about 380 tokens each, added to the first long prompt one after another.

The script ran first with both models loaded, then again after Gemma 4 was unloaded. The same script, on the same day, produced the engine comparison in what MLX in LM Studio changes on an M4 Pro. The first run was stopped after the follow-up turns, so its tool calling checks were not completed and are not reported. Swap and free memory were read with sysctl vm.swapusage and memory_pressure before the second model loaded, after it loaded, during the run and at the end. Process sizes were read with ps while the model was working.

This is one session on one machine: an Apple M4 Pro with 48 GB, macOS 27.0.1, LM Studio 0.4.25, llama.cpp engine 2.47.0, on 12 October 2026. Each figure comes from two or three requests. Other programs were open and we did not record how much memory they held, and the session began with 17.0 GB of swap already in use. A restart before the test would probably have made the two-model case less bad. It would not have made 40.92 GB of weights fit comfortably in 48 GB. The data files and the script are in the batch folder for this piece, and the method we use across the site is on how we test.