Kimi K3’s checkpoint is 1,560.9 GB, which is 121 GB more than a B200 node holds

Kimi K3’s weights ship natively as MXFP4. Four bits per parameter, half a byte, quantization-aware trained rather than squeezed after the fact. Multiply that by the 2.8 trillion parameters on the model card and you get 1,400 GB.

The checkpoint Moonshot actually uploaded is 1,560.9 GB.

The 96 safetensors shards in the repository’s file listing sum to 1,560,936,091,448 bytes: 1,560.9 GB, or 1,453.7 GiB. Hugging Face’s dtype census for the same repository lands 75.8 MB below that, which is the safetensors JSON headers. Both counts are 161 GB above the multiplication, and the reason is one field in config.json.

A 4-bit release is not uniformly four bits

quantization_config targets Linear layers at num_bits: 4, and then exempts six patterns:

"ignore": [
  "re:.*self_attn.*",
  "re:.*shared_experts.*",
  "re:.*mlp\\.(gate|up|gate_up|down)_proj.*",
  "re:.*lm_head.*",
  "re:.*vision_tower.*",
  "re:.*mm_projector.*"
]

Attention, the shared experts, the dense MLP projections, the output head, the vision tower and the multimodal projector never get quantised. They stay BF16. That is 57.18 billion parameters, 2.06% of the model, and on their own they cost 114.4 GB. The parts left in higher precision are exactly the parts that would break first if you crushed them: the router-independent path every token takes.

The second missing term is the format’s own bookkeeping. group_size is 32 and scale_dtype is torch.uint8, so every 32 quantised values carry a one-byte shared scale. Across 2.72 trillion quantised parameters that is another 85.1 GB of scales that are not weights and still occupy memory.

Table: Kimi K3’s published checkpoint by dtype, from Hugging Face’s parameter census for moonshotai/Kimi-K3 and the group size in config.json, accessed 6 August 2026.

Half a byte each against the exact parameter count gives 1,390.0 GB. The real file is 170.9 GB larger, and that overshoot splits almost evenly in two: 85.1 GB of group scales, 85.8 GB of extra precision on the 2% that was never quantised. The checkpoint averages 4.49 bits per parameter, not four.

Subtract

NVIDIA’s DGX B200 page states “8x NVIDIA Blackwell GPUs” and “GPU Memory 1,440 GB total, 64 TB/s HBM3e bandwidth”. It does not print a per-accelerator figure; 180 GB is 1,440 divided by eight, and that division is mine, not NVIDIA’s.

1,560.9 GB  Kimi K3 checkpoint (96 safetensors shards)
1,440.0 GB  node memory (8 x B200)
----------
 -120.9 GB  short

The weights do not fit. Not tightly, not with tuning: an eight-GPU B200 node is 121 GB short of holding the checkpoint at rest, before one byte of KV cache, activations, the 401M-parameter MoonViT-V2 vision encoder or CUDA graphs. Which is what vLLM’s day-0 post says in plain words: “The entire model can barely fit in a single NVIDIA DGX B300 and requires a minimum of 16 NVIDIA B200/GB200 GPUs to serve on that hardware generation.”

The first version of this page said 1,400 GB and put 40 GB of headroom on that node. It reached that by multiplying the headline parameter count by four bits, which is the shortcut the model card invites and the checkpoint refuses. The error was 161 GB, it inverted the conclusion from a tight fit to an impossible one, and it made vLLM’s sixteen-GPU floor look like caution rather than arithmetic. The file listing is public and the shard sizes are on it. Add up the 96 numbers yourself. That is the check, and it is the one I should have run before I ran the multiplication.

What I published on 17 July, and what the sources say

I posted a summary of K3 on 17 July 2026, about 22 hours after Moonshot’s launch thread. Four of its claims do not survive the primary sources.

It said K3 has “faster inference”. It does not. It said Moonshot “introduced two new architectural improvements”. Both were published months earlier, with their own papers. It said the open weights were coming “later this month”, which was true for ten more days and is now simply out of date. And it said K3 “consistently ranks among the strongest models” rather than “dominating a single category”, which is the exact inverse of what happened.

Those are four instances of one mechanism. A launch thread is a compression of a technical report, written by the vendor, optimised for a specific effect. Summarising it inherits every framing decision while dropping every qualifier underneath, because the qualifiers live in the papers, the licence file and the config JSON. So I went and read those instead.

KDA and AttnRes were not new, and the real claim is better

Kimi Delta Attention was introduced in Kimi Linear (arXiv 2510.26692, submitted 30 October 2025) as “an expressive linear attention module that extends Gated DeltaNet with a finer-grained gating mechanism”. Attention Residuals got its own paper, Attention Residuals (arXiv 2603.15031, Kimi Team, led by Guangyu Chen), submitted 16 March 2026. The weights shipped on 27 July 2026, which is 270 days after the first paper and 133 days after the second.

They also do different jobs, and welding them into one sentence about long context gets one of them wrong. KDA is the context mechanism: linear-attention layers holding a fixed-size recurrent state, interspersed with periodic full-attention layers so global recall survives. AttnRes is a depth mechanism. It “replaces fixed accumulation with softmax attention over preceding layer outputs”, because uniform residual aggregation causes “uncontrolled hidden-state growth with depth, progressively diluting each layer’s contribution”. Nothing to do with context length.

The Kimi Linear paper reports up to 6x decoding throughput at 1M context and a 75% KV cache reduction. If you see either quoted as a K3 result, it is not one. Both were measured on a 48B-total, 3B-activated model in October 2025.

Which is what makes K3 the more interesting story once you stop calling it an invention. It is the scaling event for a recipe that was already validated small. Kimi Linear ran a 3:1 hybrid, one full attention layer for every three linear ones, 25.0%. K3’s config is 93 layers: 69 KDA plus 24 Gated MLA, so 25.8%, at roughly 58 times the parameter count. The cadence is not uniform, and the config is worth reading rather than averaging: full_attn_layers is [4, 8, ... 88, 92, 93], every fourth layer plus a second full-attention layer stacked directly on top of the first at 92 and 93.

That ratio transferring across a 58x scale-up is my own reading of two config files, and I want to be careful not to hang Moonshot’s headline number on it. The technical report claims “an approximately 2.5x improvement in overall scaling efficiency” over Kimi K2, and its abstract credits that to a bundle, not to the layer ratio: KDA and AttnRes, “together with Stable LatentMoE, which effectively activates 16 of 896 routed experts per token, and refined training and data recipes”.

While you are in the config, note that 1.8% and 3.7% are both true sparsity figures for this model and they measure different things.

Table: Two distinct sparsity quantities for Kimi K3, derived from the Hugging Face model card, accessed 6 August 2026.

Expert-count sparsity is about half the parameter-activation fraction, because the shared experts, all attention parameters, the embeddings and the vision encoder are active on every token no matter how the router votes. Those are the same tensors the quantiser skipped. If you quote a sparsity figure, say which one it is.

The speed claim is the one that is simply false

Artificial Analysis, accessed 6 August 2026, measures K3 (max) at 38.7 output tokens per second, #54 of the 101 models on that page, against a median of 62.8 for open-weight models of similar size, with a time to first token of 3.11 seconds against a 1.82 second median. Their own summary calls it “particularly expensive when comparing to other open weight models of similar size” and “notably slow and very verbose”. On price it sits at #96 of 101. Moonshot’s pricing page lists $3.00 per million input tokens, $0.30 cached, $15.00 output, flat, with no context-length tiering.

vLLM reports 111 to 118 tokens per second single-user, rising to 331 to 370 with DSpark speculative decoding. Those are self-hosted, single-user, at batch size 1 on GB300 NVL72, and not comparable to a third party measuring the hosted API under production load. Do not put them in the same column.

A 2.8 trillion parameter model being slow was predictable from its own headline number before anyone measured anything, which is exactly why writing “faster inference” in the first ten lines was avoidable.

It dominated one board and sits thirteenth on another

LMArena put K3 at #1 in the Frontend Code Arena with 1679 points, past Claude Fable 5, a 17-place jump from Kimi K2.6 at #18, and #1 in six of seven frontend domains, second in Gaming. On LMArena’s main text leaderboard, read on 6 August 2026, kimi-k3-max sits at rank 13 with a score of 1485 (±10), on 3,556 votes, flagged Preliminary, with a rank spread of 4 to 31. Same model, same organisation, two boards, two verdicts, and the second one comes with an uncertainty band 27 places wide that the first one never shows you.

Moonshot is more modest about this than the coverage is. Its own technical report abstract says K3 “achieves frontier-level performance across long-horizon coding, agentic, knowledge, reasoning, and vision tasks” and then, in the same paragraph, that it “trails the most powerful proprietary models, namely Claude Fable 5 and GPT-5.6 Sol”. The comparison chart on Artificial Analysis’s own K3 page, on 6 August 2026, runs Claude Opus 5 (max) at 60.69, Claude Fable 5 (with fallback) at 59.86, GPT-5.6 Sol (max) at 58.89, and then Kimi K3 (max) at 57.11. Fourth, not sandwiched between two Claudes. I wrote the sandwich version first, by picking the two comparators that flattered the argument, which is the same error this article is about one level up.

One more thing worth reading off the repository README: every K3 result in those benchmark tables was produced at reasoning effort “max”, temperature 1.0. Forty-five lines later the same file records that the reasoning_effort field accepts "low", "high" and "max", with "max" as the default. So the benchmark setting is also the setting a caller gets by not choosing one, and the point is not that the tables are rigged. It is that the most expensive configuration is the one you get by not choosing, which is what the $15 per million output tokens and the 38.7 tokens per second are describing.

The two demos, with the qualifiers put back

The kernel result is real and the framing matters. Moonshot’s own post states the configuration: FLA Triton AttnRes at production scale, 96 layers, 8192-dim model, 8192 tokens, over 15 hours of iteration, cutting forward and backward pass combined from 283.6 ms to 114.4 ms while preserving the same numerics. That is a training-side number, not inference latency, on Moonshot’s own architecture. Neither the vendor nor most coverage states the multiple, so: 283.6 / 114.4 = 2.479x, a 169.2 ms absolute reduction, 59.7% cut.

The chip demo has a single source and it is Moonshot’s own write-up, which is more careful than the number that travelled from it:

As an early proof of concept, Kimi K3 designed a chip to serve a nano model built on its own architecture. In a single 48-hour autonomous run, K3 built, optimized, and verified the chip using open-source EDA tools on the Nangate 45nm library. Within 4 mm², the chip closes timing at 100 MHz and sustains over 8,700 tokens/s decode throughput in simulation, packing 1.46M standard cells, 0.277 MB of SRAM, and an INT4 MAC array with fused dequantization.

Three qualifiers are inside that sentence and none of them survived the coverage. Nangate 45nm is an open academic standard-cell library, not a foundry process. “In simulation” governs the throughput figure. And the part serves “a nano model built on its own architecture”, so 8,700 tokens per second describes a small model on a design that has never been fabricated, at 100 MHz. Nothing was taped out. No silicon exists.

My own post hedged this with “these results should be interpreted carefully until they’re independently replicated”, which points at the wrong risk. The limits were not waiting on replication. They were in Moonshot’s own sentence, and I kept the headline and dropped them.

Open-weight, and the licence has numbers in it

The weights are released. The training data and training code are not. That makes this an open-weight release, and “open source” describes a different thing.

The licence is not a different family from K2’s, which is how I first read it. The Kimi K3 License is textually MIT-derived: “Permission is hereby granted, free of charge”, to “use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software”. Its clause 3, requiring any product with more than 100M monthly active users or $20M monthly revenue to display “Kimi K3” prominently in its UI, is the same attribution clause K2’s Modified MIT already carried. The genuinely new restriction is clause 2: a Model-as-a-Service operator whose aggregate revenue exceeds $20M over any consecutive 12 months must sign a separate agreement with Moonshot before any commercial use. Clause 4 exempts purely internal use, and use through Moonshot’s own products or certified inference partners.

So the sentence I wrote about developers who can “inspect, customize, fine-tune, and deploy on their own infrastructure” holds up on one verb out of four. Inspection is weights only. Customisation and fine-tuning are permitted under those two thresholds rather than unconditionally. And deployment on your own infrastructure means at least sixteen B200s, which for almost everyone means renting the same hardware from the same handful of clouds you were already renting the closed model from.

The gap thesis, and the error bars nobody quotes

My post said three times, in three phrasings, that the gap between open and closed models is shrinking. The only organisation that measures it publishes numbers pointing the other way, and publishes intervals that are more informative than either point estimate.

Table: Epoch AI’s published estimates of how far open-weight models lag closed-weight models, with the 90% confidence intervals stated on each page.

The point estimate moved from 3.5 months to four. That movement sits well inside the older interval of 1.1 to 5.3 months, so on its own it establishes nothing.

The interval is where the argument actually turns, and it is not the one I would have quoted from memory. Epoch’s November page puts the vertical gap at 7 ECI points with a 90% interval of 0 to 14, and says the gap “varies considerably over time, sometimes even closing completely”. Its May 2026 page puts it at 8 points with a 90% interval of 7 to 11, roughly a third as wide, and that interval excludes zero. Over the window Epoch measured, 1 January to 28 May 2026, “sometimes closing completely” is no longer in the data. So the claim that fails is mine, not theirs. The four-month figure is still soft in the other direction, because Epoch says the same estimate “would grow to six months” under a stricter catch-up criterion, and softness in that direction does not help me either.

Two more things about that data. Epoch’s May 2026 publication has Kimi K2.6 at ECI 151.60 as its leading open model. It predates K3 entirely, so it says nothing about K3. And the defensible version of my argument is the one I did not make: holding a roughly constant three-to-four-month lag while the frontier itself accelerated is a harder result than closing a gap against a stationary target. That framing survives the data. The one I used does not.

How to detect this before you publish it

Every error above is findable in under an hour, and each one has a tell.

1. A round number that came out of a multiplication. 1,400 GB is 2.8T times four bits and nothing else. If a figure is the product of two headline numbers, the artifact it describes will have a real size, and the real size is the one to publish. Read the file listing.
2. A precision label applied to a whole model. “4-bit”, “FP8”, “INT4”. Open config.json and read quantization_config.ignore before you believe it covers everything.
3. An adjective attached to a mechanism. “New”, “novel”, “first”. Search arXiv for the mechanism name before repeating it. Both of K3’s had papers with submission dates.
4. A performance number without its measured configuration. The 6x throughput figure is true of a 48B model in October 2025 and false attached to K3. Ask what model, what hardware, what date.
5. A point estimate with no interval. Epoch publishes both. The interval is what decided whether my thesis was wrong, and it never appears in a summary.
6. A claim with a shelf life. “Later this month” was accurate for ten days. If a sentence expires, date it inside the sentence or do not write it.

The rule underneath all six is narrow enough to follow: no vendor claim ships without its primary artifact open in a second tab, and the artifact is the paper, the licence, the config JSON, the file listing or the pricing page, never the announcement. All four errors in my post, and the one at the top of the first version of this page, sat in that gap.

The weights shipped on 27 July 2026 at 1,560.9 GB across 96 files. That number came off a directory listing rather than out of a multiplication, which is the only reason I am willing to put it in a title.