I wanted the answer to be yes. I have a Mac mini, Kimi K3 is free and open, and "run a frontier model on a $1,400 box" is the kind of result I would love to report.
The memory math says no, and it is not close. Here is the arithmetic, and what I run instead.
Kimi K3 is bigger than "big"
Kimi K3 is a mixture-of-experts model with 2.81 trillion parameters, activating 16 of 896 experts per token.
That second number is where people talk themselves into optimism, so let us deal with it first.
The MoE trap
The appeal of MoE is that only a fraction of the network fires for any given token. 16 of 896 experts is under 2 percent. It is tempting to conclude you only need memory for the active slice.
You do not. Every expert has to be resident, because the router can select any of them for the very next token. Sparse activation buys you compute, not memory. You still hold the whole model.
So the memory requirement tracks total parameters, not active ones:
| Precision | Bytes/param | Weights alone |
|---|---|---|
| FP16 | 2 | ~5.6 TB |
| 8-bit | 1 | ~2.8 TB |
| 4-bit | 0.5 | ~1.4 TB |
And that is weights only, before the KV cache, before context, before the OS.
Against real Apple hardware
| Machine | Max unified memory | Short by |
|---|---|---|
| Mac mini M4 | 32 GB | ~44x |
| Mac mini M4 Pro | 64 GB | ~22x |
| Mac Studio M4 Max | 128 GB | ~11x |
| Mac Studio M3 Ultra | 512 GB | ~3x |
The Mac mini M4 Pro tops out at 64 GB and there is no larger configuration to buy. Even the largest Mac Studio, at 512 GB, gets you roughly a third of the way to a 4-bit K3.
So the honest answer is no. Not on a mini, and not on anything else with an Apple logo on it.
The part that surprised me
While checking this, I looked up what Ollama actually serves. There is exactly one tag:
kimi-k3:cloud
That :cloud suffix matters. Pulling it does not run K3 on your machine at all — it routes your requests to Moonshot's servers. You get the model, you do not get local inference, and your prompts leave your machine.
That is a perfectly reasonable way to ship a 2.81T model. It is just not what most people mean by "running it locally," and the command looks identical to the one you would use for a local model.
What actually runs, with real numbers
I benchmarked what does fit, on a MacBook M4 Max with 128 GB, on battery, one model resident at a time, temperature 0, identical prompt, three runs each:
| Model | Disk | Measured |
|---|---|---|
qwen2.5-coder:14b |
9.0 GB | 13.3 tok/s |
qwen2.5-coder:32b |
19 GB | 5.6 tok/s |
The 14B is about 2.4x faster than the 32B, and that gap decides more than benchmark scores do. For anything agentic that runs long chains of steps, throughput is the experience. At 5.6 tok/s the 32B is painful to sit through; the 14B keeps up.
The 14B also fits in 16 GB of unified memory, which means the base $599 Mac mini runs a genuinely useful local coding model.
Worth flagging honestly: those numbers were taken on battery on a working laptop, not a quiet benchmark rig. Apple Silicon throttles the GPU on battery, so treat them as a floor rather than a ceiling. The ratio between the two is the durable part.
The rule I use now
Before pulling anything, multiply total parameters by bytes-per-parameter at your target precision. If that number is larger than your unified memory minus roughly 8 GB for the system, stop. MoE does not exempt you, and quantization only buys you one factor of four.
Then check whether the tag you are pulling actually runs locally, because :cloud looks exactly like everything else on the command line.
