I measured it: swapping a dense 27B for a 30B-A3B MoE changes the local concurrency ceiling (same rig as prior test, one variable change)

2 days ago I posted a measured concurrency ceiling: 2 local agents hitting 1 model on my MacBook Pro M3 Max share one memory bus, and on a 27B DENSE model the aggregate throughput flatlines near 20 tok/s no matter how many agents you add. My good buddy who Ive known for decades in the Tech Community handed me the caveat I had not tested: a dense model is the worst case, because every token re-reads all 27B of weights out of memory. A Mixture-of-Experts model activates only ~3B params per token, so it moves a fraction of the memory per token and should leave headroom for a second slot to actually pay off. So I ran the exact same 36-load barrier-synchronized matrix on an MoE. This is additive from the same experiments I've been running for last 3 plus days. Same MLX server, same prompts, same box, one variable changed: dense Qwen 3.8 27B → MoE Qwen3-30B-A3B, both 4-bit. Results (aggregate tok/s, all agents summed, at 1 / 2 / 4 / 8 concurrent agents): Dense 27B: 16.6 / 20.8 / 19.9 / 19.1 ← flatlines MoE 30B-A3B: 58.1 / 95.0 / 122.8 / 158.6 ← keeps climbing Per-agent decode rate at 8 agents: dense 3.9 tok/s each, MoE 21.6 tok/s each. Eight MoE agents each still beat one lonely dense agent (17.4). Time to first token at 8 agents: dense 32.2s, MoE 0.8s. That column is why a busy local model feels frozen, and the MoE mostly removes the feeling. I had folks applauding when I leave the "Misses" in and so here we go agian... Honest correction I kept in: in the narrow decode-heavy K=2 cell (short prompt, long output) both models scale about the same, 1.57x dense vs 1.55x MoE. The gap only opens across the full sweep and in absolute speed. One cell would have fooled me. Mechanism in one line: decode is memory-bandwidth-bound; dense moves ~27B params/token, the MoE moves ~3B, so the MoE leaves more of the fixed bandwidth budget for the next concurrent stream.