GLM-52 897
GPT-56SC 873
CL-OP5X 865 -0.9%
GROK-46H 865 -0.9%
GEM-37FH 865 -0.9%
GPT-56T 861
GLM-5 856
MUSE-SPK 841
QWEN-38X 824 -2.3%
GPT-6A 820
KIMI-K3X 810 -1%
CL-FAB5H 787 -0.9%
CL-OP5H 764 -0.9%
CL-OP46H 742 -0.9%
CL-OP47H 733 -1.1%
GEM-38FH 676 -1%
CL-OP47 586 -0.5%
INKL 531
CL-OP46 497
CL-OP48 490 -0.2%
GLM-52 897
GPT-56SC 873
CL-OP5X 865 -0.9%
GROK-46H 865 -0.9%
GEM-37FH 865 -0.9%
GPT-56T 861
GLM-5 856
MUSE-SPK 841
QWEN-38X 824 -2.3%
GPT-6A 820
KIMI-K3X 810 -1%
CL-FAB5H 787 -0.9%
CL-OP5H 764 -0.9%
CL-OP46H 742 -0.9%
CL-OP47H 733 -1.1%
GEM-38FH 676 -1%
CL-OP47 586 -0.5%
INKL 531
CL-OP46 497
CL-OP48 490 -0.2%
← Back to feed

Kimi K3 Runs From NVMe on 29GB RAM: 2.78T Parameters at 0.5 Tokens/Second

Kimi K3 just crossed a strange local-inference threshold. WASTE, a dependency-free C inference engine from sqliteai, runs the full 2.78-trillion-parameter Kimi K3 model on a consumer laptop by streaming activated expert weights directly from NVMe.

The result is slow: roughly 0.49 to 0.54 tokens per second on a 64GB MacBook Pro. It is also full-model execution, not a distilled, pruned, or reduced variant. Kimi K3 is converted from its 1.42 TB published form into a 982 GiB container, then served with a resident trunk in RAM and a bounded cache for active experts.

The Numbers

MetricWASTE Kimi K3 run
Model size2.78T parameters
Converted container982 GiB
Minimum RAM at 4K context29.05 GiB
Tested machine64GB MacBook Pro
Tested speed0.49-0.54 tok/s
Resident trunk27.28 GiB
Expert working set per token17.0 GB

That last number is the whole story. Kimi K3 is a mixture-of-experts model. Most of its weights are idle for any given token. WASTE keeps the trunk resident, places each expert record so that one expert costs one read, and streams only the selected experts for the token being generated.

The architecture converts a memory problem into a storage-throughput problem. On internal NVMe, the engine reports 12.78 GB/s storage reads and can crawl forward at about half a token per second. Over a USB enclosure at 0.94 GB/s, the same token takes around thirteen seconds.

Not Interactive, Still Material

Half a token per second is not competitive with cloud inference. A short response takes tens of seconds. Long-form coding-agent work would be painful without aggressive batching, speculative execution, or a much faster storage path.

But dismissing the result as too slow misses the point. The interesting claim is that the frontier-scale open-weight model is reachable at all on consumer hardware. Not convenient. Not fast. Reachable.

That matters for the parts of the market where the alternative is not “use the cloud,” but “do not run the model.” Highly sensitive data, offline environments, air-gapped research systems, export-control-sensitive deployments, and personal experimentation all sit in that category. A slow local Kimi K3 is still qualitatively different from no local Kimi K3.

Why MoE Changes the Floor

Dense models punish local inference linearly: if the full model does not fit, it does not fit. MoE models create a different failure mode. Kimi K3 activates only a small slice of the parameter set per token, so the inactive weights do not need to be hot in RAM if the engine can fetch active experts quickly enough.

That is what WASTE tests. It is less a product launch than a systems claim: expert placement, aligned disk reads, direct I/O, and cache discipline can make a trillion-scale model operate under a RAM ceiling that would normally be absurd.

The cache behaviour is sharp. Below one token’s 17GB expert working set, the cache effectively does nothing. Above it, hit rates rise, but pushing too close to the machine’s physical RAM can make the OS page out the cache and destroy throughput. The best measured path on the 64GB system is not “use all available memory.” It is a narrow budget window around the point where the expert cache clears one working set without triggering system pressure.

The Open-Weight Implication

Kimi K3’s open-weight release already changed the frontier conversation by putting a 3T-class model outside a closed API. WASTE changes the local-deployment conversation by showing that the bottleneck is not only GPU memory. It is model layout, storage bandwidth, and the economics of moving inactive weights out of the hot path.

The current version is a proof of feasibility, not a replacement for hosted inference. But feasibility tends to be the first expensive step. Once a full Kimi K3 run works at 0.5 tokens per second from disk, the next questions become engineering questions: faster SSDs, better prefetch, larger local memory, smaller active sets, and improved expert-cache policy.

The direction is clear enough. Open weights are no longer just about fine-tuning or cheap API competition. They are pushing inference systems into places where trillion-scale models were supposed to be physically out of range.