Research

Kimi K3 Local Hardware Requirements

What it actually takes to run Moonshot Kimi K3 locally. 2.8 trillion parameters, sparse expert routing, MXFP4 quantisation, memory requirements by precision, and why open weights do not mean runnable weights.

By Ramanath, CTO & Co-Founder at Presenc AI · Last updated: July 2026

Moonshot AI released Kimi K3 on July 16, 2026 with 2.8 trillion parameters, making it the largest open-weight model published to date, with weights scheduled for July 27 under a modified MIT licence. Open weights are not the same as runnable weights. This page works through what serving it actually requires.

The Model

PropertyValue
Total parameters2.8 trillion
ArchitectureSparse mixture of experts, approximately 16 of 896 experts active per token
Context window1,000,000 tokens
ModalityText, image, and video understanding
LicenceModified MIT
Notable architectureKimi Delta Attention (KDA), Attention Residuals (AttnRes)
Hosted API pricing$3 / $15 per million input / output tokens

Memory Requirements by Precision

The rule that governs everything here: all 2.8 trillion parameters must be resident in memory, even though only about 16 of 896 experts activate for any given token. Sparse routing buys compute efficiency, not memory efficiency. Approximate weight-only footprints, before key-value cache and runtime overhead:

PrecisionBytes per parameterApproximate weight memory
BF162~5,600 GB
FP81~2,800 GB
MXFP4 / 4-bit0.5~1,400 GB

At MXFP4, the format the community has focused on for K3, you need roughly 1.4 terabytes of memory for weights alone. Add key-value cache for a context window of this size and realistic serving overhead, and the practical figure is higher still.

What That Means in Hardware

ConfigurationMemoryRuns K3 at MXFP4?
RTX 509032GBNo, off by roughly 44x
Mac Studio M5 Max 128GB128GBNo, off by roughly 11x
DGX Spark128GBNo, off by roughly 11x
8x H100 80GB node640GBNo, off by roughly 2x
8x H200 141GB node~1,128GBMarginal, tight with cache
16x H100 or 2x H200 node1,280GB+Yes, with headroom

Serving Kimi K3 is a multi-node data-centre workload. No workstation configuration at any price approaches it. The practical options are the hosted Moonshot API, an inference provider that has stood it up, or a rented multi-GPU cluster.

Why Release It At All

Because the weights being public changes what is possible even for people who cannot run them. Researchers can study the architecture, KDA and AttnRes in particular. Distillation into smaller models becomes possible. Enterprises with real infrastructure can deploy it inside their own perimeter with no vendor dependency. And smaller derivative models trained on K3 outputs will run on hardware ordinary teams own.

The Broader Pattern

Open-weight frontier models are growing faster than the hardware available to run them. GLM-5.2 at 753B and MiniMax M3 at 428B are already beyond workstation range. The gap between what is published and what an individual can serve is widening, and the memory shortage documented in the device price report is widening it further. The counter-trend is models such as Qwen3-Coder-Next at 80B total and 3B active, which deliberately target hardware people own.

Brand Visibility Implications

Kimi K3 will mostly be consumed through hosted endpoints and inside enterprises with serious infrastructure. The second category matters most for measurement: a bank or pharmaceutical company serving K3 privately generates brand-relevant answers with no external observability at all. As frontier open weights get better, private frontier-grade inference becomes normal enterprise practice. See air-gapped deployment statistics and the Kimi K3 release brief.

Methodology

Vendor specifications come from NVIDIA, Apple, and model-card publications. Throughput figures aggregate community benchmark reporting from the llama.cpp discussions, the MLX repository, and published independent test suites. Single-stream decode unless stated otherwise. Ranges rather than point values are used wherever independent runs disagree, which is most of the time: quantisation format, prompt length, thermal state, and runtime version each move these numbers by more than the differences being measured. Treat every figure as an order-of-magnitude guide, not a specification. Updated quarterly.

How Presenc AI Helps

Presenc AI tracks brand representation across frontier open-weight models including hosted Kimi endpoints, so teams can see what these models say about them without provisioning the infrastructure to run them.

Frequently Asked Questions

No. At MXFP4 quantisation the weights alone need roughly 1.4 terabytes of memory, which is about 11 times what a 128GB Mac Studio or DGX Spark provides and 44 times an RTX 5090. Serving Kimi K3 requires a multi-GPU data-centre node such as 16x H100 or equivalent.
Sparse routing selects which experts compute for a given token, but the router can select any expert on any token, so all of them must be resident and ready. Memory footprint tracks total parameters while compute tracks active parameters. Sparsity buys speed, not capacity.
Approximately 5,600GB at BF16, 2,800GB at FP8, and 1,400GB at MXFP4 or 4-bit, counting weights only. Key-value cache for the 1M-token context window and runtime overhead push the practical requirement higher.
Architecture research, distillation into smaller runnable models, and private deployment by enterprises that do have the infrastructure. Derivative models trained on K3 outputs will run on ordinary hardware even though K3 itself will not.

Track Your AI Visibility

See how your brand appears across ChatGPT, Claude, Perplexity, and other AI platforms. Start monitoring today.