Someone Got an 80B Parameter Model Running on a Mac With 4.3GB of RAM
Normally, running an 80-billion-parameter model means a beefy GPU rig and dozens of gigabytes of memory. A new open-source project called Swiftlet just did it on a Mac with 4.3GB of RAM — and got a 35B version running on an iPhone. Same idea, wildly less hardware.
What Swiftlet Actually Is
Swiftlet is a Swift + Metal runtime built specifically for Apple hardware. It's designed to run Qwen3-Next and the newer Qwen3.5/3.6 mixture-of-experts (MoE) models directly on consumer Apple Silicon — no cloud, no external GPU.
The trick is in how it handles memory. MoE models are made up of a small "dense core" plus a large collection of specialized "expert" sub-networks, only a few of which activate for any given token. Traditionally, you'd still need to load the entire model — core and all experts — into memory, even though most of it sits idle at any moment.
Swiftlet doesn't do that. It keeps only the small dense core resident in memory and streams the relevant expert weights from storage on demand, as the model actually needs them. That's the whole trick: instead of holding tens of gigabytes of mostly-unused weights in RAM, it fetches just what's needed, when it's needed.
Why This Is a Bigger Deal Than It Sounds
MoE architectures already made large models cheaper to run per token, since only a fraction of parameters activate per pass. But they didn't make large models cheaper to host — you still needed enough memory to hold every expert, active or not.
Swiftlet attacks that second problem directly. By treating storage as an extension of memory and streaming experts on demand, it turns "how much RAM do I have" into a much less limiting question than it used to be. That's what makes running an 80B model in 4.3GB — a ratio that would've sounded made up a year ago — actually work.
It also explains the iPhone result. Phones have nowhere near the memory budget of a Mac, but they do have fast local storage. If the bottleneck is memory rather than compute, streaming from storage is exactly the lever that gets you from "impossible on a phone" to "35B parameters, running locally."
The Trade-Off Nobody's Pretending Doesn't Exist
Streaming weights from disk instead of holding them in RAM isn't free — it trades memory footprint for I/O latency. Expect this approach to shine on tasks where you can tolerate some extra time between tokens in exchange for running a model that otherwise wouldn't fit at all. It's not going to out-benchmark a fully-loaded model on a workstation GPU for raw throughput. But that's not really the pitch — the pitch is that this model runs at all, on hardware you already own.
What This Means if You Use OpenClaw
This is part of a trend we keep writing about: the gap between "cloud-only AI" and "AI on your own device" keeps shrinking, and it's shrinking fastest for the models built to be agentic — the ones meant to use tools, take actions, and run tasks rather than just chat.
OpenClaw is built around that same idea from the other direction: your agent shouldn't need a data center to be useful. It runs the tools you give it, keeps track of what it's done, and picks up where it left off — regardless of which model is doing the reasoning underneath. As runtimes like Swiftlet push what's possible on ordinary hardware, the practical cost of running a capable, persistent agent keeps dropping. That's good news whether your agent is running in the cloud or, increasingly, right on the machine in front of you.