On-device language models no longer hit a RAM ceiling. They hit an architecture choice.

The size of a language model that fits on a device is set by how many parameters activate per token, not by the parameter count on the spec sheet. Most of the model is dormant most of the time, and a Mixture-of-Experts architecture makes that dormancy cheap to exploit. Keep the dense core resident in RAM, stream the routed experts from storage on demand, and the working set collapses to the active-parameter count, around three billion for a Qwen3-Next-80B.

That is the mechanism behind Leonickson's Swiftlet benchmark. The Swiftlet README reports a 4-bit Qwen3-Next-80B running in 4.3 GB of peak RAM on an M5 Mac at four and a half to five tokens per second, and a 35-billion-parameter Qwen3.6 variant in roughly 2.5 GB on an iPhone 17 at about one token per second. The headline number will read as a hardware story. The pattern underneath is that RAM cost is a function of active parameters, and active parameters are an architectural choice the model designer makes, not a fact the device enforces.

Two honest caveats travel with the read. A model whose working set is three billion parameters will chat and write like a large model but recall facts like a small one. And the present iPhone throughput is dispatch-bound in the Swiftlet kernel, not IO-bound, so one token per second is a software ceiling rather than a device ceiling. Both sharpen the same point: the constraint is now architecture, not hardware.