On July 16, 2026, Moonshot AI announced Kimi K3, and called it the first open model to cross 2.8 trillion parameters. Independent testers put it near the top of the field, and the press ran with "largest open-source model ever." For a local-LLM site the news is genuine and the timing is awkward: at announcement time the weights were not downloadable. Moonshot promised them by July 27, 2026, and for its first ten days Kimi K3 was an API and a chat window, not a file you could pull.
Update, July 30, 2026: the weights landed on Hugging Face July 26, a day early: 1.56TB in native MXFP4 under a new "Kimi K3 License". The config answers the missing number below: 104B active parameters, more than triple K2's 32B. Unsloth's GGUFs start at 594GB for 1-bit, so the verdict of this piece stands: a single 512GB Mac Studio cannot hold K3 at any quant. Mainline llama.cpp support is still pending, so no credible owner token rates exist yet. Details updated throughout.
So this was written as a preview, not an owner report. Nobody outside Moonshot has run the weights, there is no technical report yet, and there are no community quants. We have not tested it. What we can do is lay out what Moonshot claims, what the one independent eval so far shows, and the part that matters most here: what a 2.8-trillion-parameter model would take to run at home. The short version is that the machine most people would reach for, a maxed-out Mac Studio, cannot hold it at any quant.
What Moonshot says Kimi K3 is
Straight from Moonshot's announcement and its API docs, all of it vendor-stated:
| Spec | Kimi K3 (as stated by Moonshot) |
|---|---|
| Total parameters | ~2.8 trillion (Mixture-of-Experts) |
| Active per token | 104B (16 of 896 experts + 2 shared, "Stable LatentMoE"; confirmed in the released config, July 26) |
| Context window | 1,000,000 tokens |
| Architecture | Kimi Delta Attention (a hybrid linear attention) plus Attention Residuals |
| Modalities | Native vision (text + images + video in), always-on "max thinking" |
| Precision | Quantization-aware training in MXFP4 weights / MXFP8 activations |
| License | Kimi K3 License (its own license, published with the weights; not the Modified MIT of the K2 family) |
| Available now | API + web, and weights on Hugging Face since July 26, 2026 (1.56TB native MXFP4) |
Both of the flags we raised at announcement time have since resolved. The license turned out to be a new "Kimi K3 License", not the K2 family's Modified MIT that aggregators assumed. And the active-parameter count, unpublished for the first ten days, is now confirmed at 104B, the number that decides local speed. More on what it means below.
One detail local runners should note: Moonshot says K3 was trained quantization-aware in MXFP4, the same 4-bit block format OpenAI's gpt-oss models use. If that holds through the weight release, the "native" quant is 4-bit-class, which sets the floor on how small the download can get without extra damage.
The benchmarks: read them as claims
Because the weights are not out, every per-benchmark number Moonshot published is a vendor self-report that no one can reproduce yet. Moonshot's own table leads with agentic and coding results: it claims 91.2 on BrowseComp (which it frames as state-of-the-art at release), 93.5 on GPQA-Diamond, and 88.3 on Terminal-Bench 2.1. Take those as the maker's numbers, not settled facts. Note also there is no SWE-bench Verified score for K3 from any credible source, so any figure you see claiming one is invented.
The number worth trusting is the independent one. Artificial Analysis, which runs its own evals through the API, scored Kimi K3 at 57 on its Intelligence Index and ranked it third to fourth overall: on par with Claude Opus 4.8 and GPT-5.5, a step behind the current leaders (Fable 5 and GPT-5.6 Sol). That directionally backs Moonshot's positioning. Separately, blind human-preference testing on frontend coding (relayed by Axios and Simon Willison) had developers preferring K3 over every leading US model on that one narrow task. Willison also ran his usual "pelican on a bicycle" SVG doodle and got a valid result, while cautioning it is not a real capability test.
The takeaway: a Chinese lab shipping an open-weight model that an independent index rates alongside Opus 4.8 is the actual story here, and it lands whether or not the individual self-reported cells hold up now that the weights are public.
The one spec that decides local speed is missing
For a model you plan to run yourself, two numbers matter, and they do different jobs. Total parameters decide whether it fits in your memory. Active parameters decide how fast it decodes, because token generation is memory-bandwidth-bound: each token only reads the experts that fire, not all 2.8T weights. Our Mixture-of-Experts explainer walks through why.
At announcement Moonshot gave only the routing ("16 of 896 experts"), and the ~50B figures circulating were guesses. The released config settles it: 104B active, against 32B for the 1T-parameter Kimi K2. That is the less friendly direction. Decode speed is bandwidth divided by the bytes each token reads, so per unit of memory bandwidth K3 decodes at roughly a third of K2's pace. On the 4-bit-class native weights, each token reads on the order of 55 to 60GB, which means even a datacenter card at 4.8 TB/s tops out somewhere near 80 tok/s per active stream, and prosumer hardware proportionally lower. Fit was already out of reach; the confirmed active count now also rules out the "huge but nimble" hope.
The hardware reality: nothing you own runs it
Here is where the "largest open model ever" headline collides with a desk. Our pre-release projections (scaled from Kimi K2's measured files) are below, followed by the real numbers now that Unsloth's GGUF ladder is out:
| Quant | Projected K3 weights (2.8T) | For comparison: Kimi K2 (1T) |
|---|---|---|
| Q8 | ~2.8 to 3.0 TB | ~1.09 TB |
| Q4_K_M | ~1.6 to 1.7 TB | ~587 GB |
| Heavy IQ2 | ~0.9 to 1.05 TB | ~330 to 373 GB |
Measured, July 29: UD-IQ1_S 594GB, UD-IQ1_M 649GB, UD-IQ2_XXS 711GB, UD-Q2_K_XL 861GB, UD-Q4_K_XL 1.51TB, UD-Q8_K_XL 1.56TB. Our 2-bit and 4-bit projections landed close; the Q8 row did not, for an interesting reason: because K3 was trained in MXFP4, the native 4-bit-class weights are already the full model, so "8-bit lossless" is only 50GB bigger than Q4. Quantization-aware training collapsed the top of the ladder. Note the floor, though: the smallest usable file is 594GB, and Unsloth pegs the practical requirement at 650GB-plus of combined RAM and VRAM. These GGUFs also need a llama.cpp fork for now; mainline support is still being tracked.
Those are weights only. Add roughly 10 to 15 percent runtime overhead plus KV cache on top. The one mercy is that Kimi Delta Attention is a linear-attention scheme, so the KV/state footprint should stay modest even at long context (on the order of tens of gigabytes at the full 1M window, not hundreds). With K3 the weights are the whole problem.
Run those numbers against real machines and the result is stark:
| Machine (usable memory) | Can it hold K3? |
|---|---|
| RTX 5090, 32GB | No, at any quant (off by ~30x even for IQ2) |
| 2x to 4x RTX 3090 (48 to 96GB) | No, at any quant |
| Strix Halo, 128GB unified | No (the smallest 1-bit file is 594GB, about 5x short) |
| Mac Studio M3 Ultra, 512GB | No, even at 1-bit (measured 594GB > 512GB) |
| 8x H100 (640GB) | No, even for IQ2 |
| 8x H200 (1,128GB) | 2-bit yes with room (711 to 861GB); the 1.51TB Q4 no |
The Mac Studio row is the headline reversal. A single 512GB Mac Studio M3 Ultra runs the current Kimi K2 at Q2 comfortably, around 380GB of weights with room to spare. The same machine cannot hold K3 at any quant. A 2.8x jump in size walked the ceiling right past the biggest single box a prosumer can buy.
The smallest realistic way to self-host K3, once weights ship, is a small cluster: two or three Mac Studio 512GB machines linked with a distributed runtime (EXO or MLX) to reach 1 to 1.5TB of unified memory for an IQ2-to-low-Q3 quant, which is roughly a $20,000 to $30,000-plus proposition, or a single 8x H200 / B200-class server, which is rental-or-datacenter territory. Disk-offloading a 2.8T model through llama.cpp is technically possible and would run at fractions of a token per second, so it does not count as a real answer. For anyone at or below one 512GB Mac, a Strix Halo, a 5090, or a 3090 rig, K3 simply does not fit.
So should you care?
As a local model today, Kimi K3 is not one. It is an API model ($3 per million input tokens, $15 per million output, per Constellation Research) whose weights arrived July 26 as a cluster-only 1.56TB download that a rounding error of readers can host. If you want to use its intelligence now, the practical path is the API or renting a big GPU node by the hour, which is exactly the buy-vs-rent-vs-API question our cost calculator is built for. This is the same wall we hit with GLM-5.2 and Kimi K2.7, only taller.
Why it still matters: an open-weight model that an independent index rates next to Claude Opus 4.8 means the open frontier now touches the closed one, and MXFP4-native training is a signal that these labs are designing for the hardware reality, not ignoring it. Both things we said to watch have now landed: the active count (104B, settling the speed ceiling) and the first community quants (594GB floor). What remains open is mainline llama.cpp support and the first credible owner token rates on Mac clusters and big-RAM rigs; we will fold those in when they exist. A smaller distilled variant remains the only path that ever puts this model on a machine most people own.
Sources and how we researched this
- Announcement, specs, pricing, and self-reported benchmarks: Moonshot AI's Kimi K3 blog and API docs (primary, vendor-stated).
- Independent evaluation: Artificial Analysis (Intelligence Index 57, ranked 3rd to 4th).
- Reporting and context: Constellation Research, Axios, VentureBeat, and Simon Willison.
- Weights release (July 26, 2026), 104B active count, and the Kimi K3 License: the official Hugging Face repo. Measured quant sizes: Unsloth's Kimi-K3-GGUF (July 29). Mainline llama.cpp support tracked in ggml-org/llama.cpp#26185.
- Hardware footprint: pre-release projections from Kimi K2's measured sizes, now cross-checked against Unsloth's measured K3 files. We have not run the model first-hand, and no credible owner token rates exist yet.
Related: Kimi K2.7 Code and the 594GB reality · Mac Studio M3 Ultra for local AI · How much VRAM a 70B needs · GGUF quantization, explained