JournalDAY 21 / X

FIELD NOTE / X

Kimi K3 is not going on your Mac mini.

The complete written thought and the evidence behind it. The video edition will follow its public release.

Journal September 25, 2026 · X target October 18, 2026

Kimi K3 is not going on your Mac mini.

Video caption

Kimi K3 is not going on your Mac mini. Only some experts activate; all weights still exist. Use a compact local model where it actually passes. #EricFieldNotes

Full written post / accessibility read

Kimi's official card lists two point eight trillion parameters and native four-bit weights. Four bits times that parameter count is roughly one point four terabytes of raw weights before metadata and runtime state. Apple's Mac mini tops out at sixty-four gigabytes.

K3 activates a subset of experts per token, which reduces compute. The complete expert set still needs a serving strategy, memory and bandwidth. Offloading weights to storage may make a process start; it does not make the full model a useful interactive service on a mini.

Moonshot recommends a supernode with at least sixty-four accelerators for efficient K3 inference. That recommendation is about its full model at scale, not proof that no experimental partial or offloaded run exists. Compare first-token delay, sustained throughput and concurrency on real hardware.

A smaller open model may be excellent for a bounded private task. Use K3 through hosted or clustered infrastructure when its full capability matters. Do this because owning model files and serving frontier-scale work at useful speed are different engineering problems.

#EricFieldNotes

Four-beat scene transcript

1. Kimi K3 is not going on your Mac mini.

Kimi's official card lists two point eight trillion parameters and native four-bit weights. Four bits times that parameter count is roughly one point four terabytes of raw weights before metadata and runtime state. Apple's Mac mini tops out at sixty-four gigabytes.

Visual: Open weights do not shrink the full model into local memory.

2. Sparse compute does not erase storage.

K3 activates a subset of experts per token, which reduces compute. The complete expert set still needs a serving strategy, memory and bandwidth. Offloading weights to storage may make a process start; it does not make the full model a useful interactive service on a mini.

Visual: Only some experts activate; all weights still exist.

3. The vendor recommends a supernode.

Moonshot recommends a supernode with at least sixty-four accelerators for efficient K3 inference. That recommendation is about its full model at scale, not proof that no experimental partial or offloaded run exists. Compare first-token delay, sustained throughput and concurrency on real hardware.

Visual: Moonshot says 64 or more accelerators for efficient serving.

4. Choose by accepted work, not logo.

A smaller open model may be excellent for a bounded private task. Use K3 through hosted or clustered infrastructure when its full capability matters. Do this because owning model files and serving frontier-scale work at useful speed are different engineering problems.

Visual: Use a compact local model where it actually passes.

Research and claim limits

The examples identified as illustrative or simulated are design probes, not reported incidents. Vendor specifications do not establish workload performance.

More notes from the work ↗