The smallest Kimi K3 is 589 GB

Every open-weights release now arrives with the same question attached, usually within the hour: can I run it on my machine. Kimi K3 landed with open weights on 27 July and community quantisations followed within two days, which is fast enough that the answer is worth working out rather than assuming. Moonshot’s release itself, 2.78 trillion parameters in 1,561 GB, is set out further down this page, with its benchmarks and licence. We summed every shard of every published GGUF build. The smallest complete one is 589.5 GB, which is 12.3 times the memory of the machine we would have run it on.

That part is unsurprising. The part worth writing down is that two builds carrying the same quantisation label differ in size by 58 GB, which is more than the entire memory of that machine. For a team weighing Kimi K3 local hardware against Moonshot’s API, those sizes settle the hardware side before price comes into it.

Can you run Kimi K3 locally?

Not on anything you are likely to own.

We measured rather than quoted. Rather than trusting a size printed in a blog post, we requested the headers of every shard of every published build and added them up. That distinction turned out to matter, and we will come back to why.

The smallest complete build is 589.5 GB of weights. That is before the key-value cache, before any runtime overhead, and before the context window that makes the model interesting in the first place.

Against our test stack with 48 GB of unified memory, the smallest build is 12.3 times the available memory. There is no quantisation trick, no offloading strategy and no clever loader that closes a gap of that shape on that hardware. This is the same conclusion we reached about a different trillion-scale model earlier this month, and the arithmetic is not close enough to argue about. The official weights, at about 1,561 GB, are about 32.5 times that memory (1,561 divided by 48), and the model card recommends the vLLM, SGLang and TokenSpeed inference engines.

How big are the Kimi K3 GGUF builds really?

The figure in circulation is that the 1-bit builds run from about 594 GB to about 620 GB. Half of that is right. Our measurement puts unsloth’s UD-IQ1_S at 594.0 GB, which matches the low end exactly.

The upper figure does not match anything we found. The family runs from 589.5 GB to 769.1 GB, and the spread comes from the 2-bit builds, which nobody seems to have added up. If you are budgeting disk or bandwidth from the quoted range, you are short by up to 150 GB.

Why two 2-bit builds differ by 58 GB

unsloth’s UD-IQ2_XXS is 711.1 GB. AtomicChat’s IQ2_XXS is 769.1 GB. Same base model, same nominal quantisation, 58 GB apart.

That is the same phenomenon we found when we read the tensor tables of eight builds of one model and discovered that a file named UD-Q4_K_XL contained no Q4_K at all. These labels describe an intent, not a recipe. Every quantiser decides independently which tensors to protect at higher precision, and on a mixture-of-experts model where the experts dominate the weight budget, small differences in that policy scale into tens of gigabytes.

For a 27B model that difference is an annoyance. At this scale it is the difference between two machines.

Kimi K3 local or API: what does a team actually pay?

The hardware side ends early. Apple’s Mac Studio specifications list 512GB as the largest unified memory option, on the M5 Ultra (Apple, Mac Studio tech specs, read 17 October 2026). The smallest complete Kimi K3 build we summed is 589.5 GB of weights alone, so it does not fit in any Mac Studio configuration, and the shortfall is 77.5 GB before any context (589.5 minus 512). Running it locally would mean pooling several machines, the approach exo takes to cluster Macs. We have not run Kimi K3 that way, and Apple’s store page showed no prices when we read it, so we give no hardware cost.

The API side is a published price. The vendor’s published price for kimi-k3, on Moonshot’s Kimi API platform as read on 17 October 2026, is $3.00 per million input tokens, $0.30 per million cached input tokens and $15.00 per million output tokens. A team’s monthly bill is its input tokens in millions times $3.00, plus its output tokens in millions times $15.00, less the saving on any input served from cache. One million tokens in and one million out comes to $18.00 at those prices.

That gives a break-even any team can work out. Every $1,000 spent on hardware is the price of about 333 million input tokens or about 67 million output tokens at the published rates ($1,000 divided by $3.00 and by $15.00 per million). A local cluster pays for itself only if it replaces more tokens than that, per $1,000, over its working life, and that sum also has to cover power and the time someone spends keeping it running. Take your team’s real monthly token counts from your current provider’s usage page before doing it. We have not measured any team’s volume and do not assume one here.

We have no measured hardware cost or payback for Kimi K3, because that needs a multi-Mac run of the model, hardware prices Apple’s page did not show, and a real team’s monthly token volume; those are what would settle it, and the run is on our list. A smaller open-weight model that fits one machine is a different quality question, to be tested on the team’s own work before any hardware is bought.

Can a business use Kimi K3 commercially without a Moonshot agreement?

For most businesses the licence says yes, and its conditions are narrow. It opens with a broad grant in the style of the MIT licence, allowing anyone to use, copy, modify, fine-tune and sell the software and weights. Hugging Face labels the licence “other.” We read the Kimi K3 License again on 17 October 2026. The separate agreement in Section 2 applies only to a “Model as a Service” business, which the licence defines as giving a third party access to language model inference or fine-tuning, for example through an API, and only once the licensee and its affiliates pass $20 million in revenue over any consecutive 12 months. The definition excludes end-user products that build the model into specific functions, and the relaying of requests to models hosted by others.

The common cases sort out quickly. A company running Kimi K3 for its own staff is in internal use, which Section 4 exempts from both conditions as long as the model, its outputs and its capabilities are not made available to third parties. A company building Kimi K3 into a feature of its own product is outside the Model as a Service definition, and meets the display rule in Section 3 only above 100 million monthly active users or $20 million in monthly revenue, at which point it must display “Kimi K3” prominently. A hosting company selling Kimi K3 inference is the case the agreement is written for, once it passes the revenue line. Use through Moonshot’s own products or certified inference partners is exempt, and the licence does not list who those partners are.

The licence decides whether a business may run Kimi K3. The hardware decides whether it can. For a business without a multi-GPU server, the realistic route is a hosted provider, and the partner exemption makes that provider’s status worth asking about before signing. A company near either threshold should put the licence in front of its own counsel.

Alibaba’s licence for Qwen3.8-Max, published in August, follows the same structure, with the separate-licence threshold for inference services raised to $50 million in revenue over any 12 months.

What did Moonshot publish in the Kimi K3 release?

Moonshot AI published the weights of Kimi K3 on Hugging Face on July 27, according to the repository’s commit history. Hugging Face counts 2,779,931,837,184 parameters in the safetensors files, matching the 2.8 trillion on the model card, and the weight files total about 1,561 GB. By September 10 the repository showed 2,319,885 downloads and 11,269 likes.

Kimi K3 architecture, from the model card

Moonshot calls Kimi K3 “the world’s first open 3T-class model” and its most capable model to date. It is a mixture-of-experts model with 104 billion parameters active per token, built on two techniques the company calls Kimi Delta Attention and Attention Residuals. Of its 93 layers, 69 use Kimi Delta Attention and 24 use gated multi-head latent attention, and one is dense. The card lists 96 attention heads, a latent MoE dimension of 3,584, an expert hidden size of 3,072, a vocabulary of 160K tokens and a vision encoder, MoonViT-V2, with 401 million parameters. The config lists 896 experts, of which 16 are chosen per token alongside 2 shared experts, and a maximum of 1,048,576 positions.

Moonshot said its Stable LatentMoE framework, which activates 16 of the 896 experts, gives “an approximate 2.5” times improvement in scaling efficiency over Kimi K2. The weights are stored in MXFP4 with MXFP8 activations, which the card says came from quantization-aware training rather than compression after the fact.

The card is inconsistent on one point. Its introduction says the model “understands text, images, and video within the same model,” while its summary table lists the modality as “Text, Image.” Hugging Face files Kimi K3 as an image-text-to-text model. The repository holds 115 files at its root, and the config names the architecture KimiK3ForConditionalGeneration with a hidden size of 7,168.

Kimi K3 benchmarks against GPT-5.6 Sol and Claude Fable 5

These are Moonshot’s own results, not ours. Moonshot reports every Kimi K3 result with reasoning effort set to max and a temperature of 1.0. Against GPT-5.6 Sol, Claude Fable 5, Claude Opus 4.8, GPT-5.5 and GLM-5.2, the picture is mixed. Kimi K3 leads on BrowseComp, 91.2 against 90.4 for GPT-5.6 Sol, and on SWE-Marathon, a long-running coding test, with 42.0 against 39.0 for GPT-5.6 Sol and 35.0 for Fable 5. It scores 94.5 on MCPMark-Verified, against 92.9 for GPT-5.6 Sol and 87.4 for Fable 5. Its 74.7 on AA-LCR, a long-context reasoning test, is the highest in the table.

It trails elsewhere. On DeepSWE coding it scores 67.5 against 73.0 for GPT-5.6 Sol. On GPQA Diamond it scores 93.5 against 94.1 for GPT-5.6 Sol. On HLE-Full it scores 43.5 without tools and 56.0 with them, against 53.3 and 63.0 for Fable 5, and on Agents’ Last Exam it scores 28.3, between Fable 5 at 25.7 and GPT-5.6 Sol at 29.6. On Terminal-Bench 2.1 it scores 88.3 against 88.8. On OSWorld 2.0, a computer-use test, it scores 58.3 against 66.1 for Fable 5 and 62.6 for GPT-5.6 Sol. On FrontierSWE it scores 81.2, behind Fable 5 at 86.6 but ahead of GPT-5.6 Sol at 71.3, and on GDPval-AA, an Elo rating of professional work, it scores 1,686 against 1,747 for Fable 5 and 1,736 for GPT-5.6 Sol.

The table covers 45 benchmarks across reasoning, coding, agentic work and vision. Vision is where Kimi K3 does best against the field: it leads on OmniDocBench with 91.1 and on Video-MME with 90.0. Two of its reasoning scores, CritPt and AA-LCR, are cited from Artificial Analysis as of July 23 rather than run by Moonshot.

How Moonshot ran the tests matters to these numbers. It ran Kimi K3 on DeepSWE with its own Kimi Code agent; on the official leaderboard’s mini-SWE-agent setup, the card says, it scores 67.3. Its SWE-Marathon runs used a version of the tasks recalibrated for Nvidia H20 hardware, taken before the benchmark’s final v1.1 release. Community evaluation results for four benchmarks were added to the repository on the day of release, and a Toolathlon-Verified result followed on September 2. The same afternoon as the first commit, a Hugging Face staff change to enable inference providers was merged into the repository.

What Moonshot has not published

The model card does not state how much data Kimi K3 was trained on or on what hardware. It links to a separate full report, which we have not reviewed. The card also does not reconcile its two statements about video input.

Sources: Kimi K3 model card; Kimi K3 License; config; commit history.

How to check a model’s real size before downloading

Our first pass at this got it wrong twice, in ways worth repeating because they are easy to hit.

We started by reading file sizes from the Hugging Face tree API, which is the obvious approach. It returned 13 shards for a build whose filenames declared 16, and 14 for one that declared 18. That looked like two repositories serving incomplete uploads, which would have been a striking finding: anyone downloading them would get a model that cannot load.

It was wrong. The API paginates and silently truncated the listing. We checked the supposedly missing shards directly and every one returned a redirect to the CDN, meaning the files exist. Had we published the first result, we would have accused two people of shipping broken quantisations on the strength of an artefact in a JSON response.

The same truncation produced a second false finding. With three shards missing from the total, unsloth’s 2-bit build appeared to be smaller than its 1-bit build, which would have been a genuine anomaly worth a paragraph. Complete the sum and the ordering is exactly what it should be: 1-bit builds are smaller than 2-bit ones, every time.

So the method that works is dull and reliable. Request the headers of each shard, read the content length, add them up, and confirm the shard count matches what the filenames declare. It costs a few seconds per build and it is the only way to get a number you can defend. The same discipline applied to reading a model file directly is what tells you what is actually inside rather than what the name suggests.

The wider point is not about Kimi K3, which almost nobody reading this will run. It is that the published numbers for these releases are assembled quickly, from each other, in the days when interest peaks and nobody has the hardware to check. The size of a file is the least ambiguous fact a model has, and the circulating version of it was still wrong by 150 GB a week after release.

There is a practical version of this for anyone tracking releases. The window in which a model is most discussed is the window in which the fewest people can verify anything about it, because the hardware to do so does not exist outside a handful of labs. Sizes, memory floors and quality claims all circulate on trust during that period. A number you can check with a header request is the cheapest possible correction, and it stays wrong for weeks when nobody makes it.