Kimi K3 Open Weights Are Live: What Actually Shipped

Moonshot AI made the Kimi K3 weights public on July 27, 2026, and the largest open-weight model anyone has shipped is now a download. The repo is moonshotai/Kimi-K3: 114 files, 1,561 GB, one custom license. That last part matters, because most of what got published about this release before it happened was wrong, including the repository name, the license, the file size, and the hardware you need. We read the actual repo. Here is what shipped.

TL;DR

• What it is: a 2.8-trillion-parameter Mixture-of-Experts model with 104B active parameters, 93 layers, a 1,048,576-token context window, and native text, image and video input. Quantization-aware trained in MXFP4.
• Why it matters: the first open 3T-class model, and on Moonshot's own numbers it trades the lead with Claude Fable 5 and GPT-5.6 Sol across coding and agentic suites. You can audit it, fine-tune it, and serve it yourself.
• The catch: 1,561 GB of weights. That is roughly 19 H100s just to hold the model, before you allocate a single token of KV cache. And the license is not Apache 2.0.

What actually landed

One repository, not the family of base, instruct and quantized variants that usually accompanies a release. Everything is in moonshotai/Kimi-K3, and the weights are already quantized: there is no separate FP16 checkpoint to download.

The license is custom, and clause 2 has teeth

It is not Apache 2.0, despite that being reported widely in the days before the drop. It is a bespoke "Kimi K3 License", MIT-shaped at the core with two commercial conditions bolted on. Read it yourself, it is short, but here is the shape of it.

Clause 2 targets Model-as-a-Service specifically. If you give third parties access to inference or fine-tuning in a way that lets them control inputs, parameters or training data, and you or your affiliates clear 20 million US dollars in aggregate revenue over any consecutive 12 months, you must sign a separate agreement with Moonshot before any commercial use. Note the trigger is total company revenue, not revenue from the model.

Clause 3 is an attribution rule. Ship a product with more than 100 million monthly active users or more than 20 million US dollars in monthly revenue, and "Kimi K3" has to appear prominently in your user interface.

Clause 4 is the escape hatch most readers will land in: neither condition applies to internal use, defined as use that does not expose the model, its outputs, or its capabilities to third parties. Run it inside your own company and you are clear. Resell inference at scale and you are negotiating.

The numbers everyone published before the file listing existed

This is worth your attention as a builder, because it is now a pattern. In the week before the drop, a wave of posts appeared with hardware tables, vLLM commands, and download instructions for a file that did not exist yet. We checked the Hugging Face API repeatedly across that window: the moonshotai org held 18 models, newest Kimi K2.7 Code from June 15, and the K3 page was a countdown placeholder with a notify button.

Now that the real repo is up, we can score the claims.

None of these were malicious. They were written ahead of a traffic event and nobody checked, because there was nothing to check against. The practical lesson for anyone about to pull a terabyte and a half: ask the API, not a blog. It takes one command. We went through the same exercise when Wan 2.7 was widely reported as open-weights and was not, and the method there works for any release claim.

# What has a lab actually published? No repo, no download,
# regardless of what any article says.
curl -s "https://huggingface.co/api/models?author=moonshotai" \
  | python3 -c "import sys,json;[print(m['modelId'], m.get('lastModified')) for m in json.load(sys.stdin)]"

# Real file list, real byte total, real license field:
curl -s "https://huggingface.co/api/models/moonshotai/Kimi-K3?blobs=true" \
  | python3 -c "import sys,json;d=json.load(sys.stdin);s=d.get('siblings',[]);\
print('license:', d.get('cardData',{}).get('license_name'));\
print('files:', len(s));\
print('total GB:', round(sum(f.get('size') or 0 for f in s)/1e9, 1))"

The architecture, and why 1M context is affordable here

K3 runs 93 layers, and the attention is split: 69 layers use Kimi Delta Attention (KDA), Moonshot's linear attention variant, and only 24 use Gated MLA, the full-attention path. That ratio is the interesting part. Linear attention carries a fixed-size recurrent state instead of a KV cache that grows with sequence length, so at a 1M-token context only those 24 layers accumulate a conventional cache. That is roughly a quarter of the model paying full freight for long context, which is how a 1M window becomes tractable at all.

The MoE side is unusually sparse: 896 routed experts with 16 selected per token, plus 2 shared experts that run every time, routed by a sigmoid gate. Moonshot claims about 2.5x better overall scaling efficiency than K2 from this combination. Activated parameters land at 104B, so you store 2.8T and compute roughly 104B per token.

The tech report published alongside the weights adds a detail worth flagging: K3 uses no explicit positional embedding at all. There is no RoPE, and therefore no RoPE rescaling or interpolation to reach long context. Position is encoded implicitly through KDA's recurrent gating and decay, which is why the model extrapolates to 1M tokens without the usual positional surgery. Training grew the window in four stages, 8K to 64K during pre-training and 256K to 1M during cooldown, which keeps the expensive long-sequence compute inside a small slice of the budget.

Here is the part almost nobody covering the drop mentioned: both headline architecture pieces have been open on GitHub for months. FlashKDA, the KDA kernels, went up April 20, 2026 under MIT and sits at 473 stars. Attention-Residuals has been public since March 15, 2026, now past 3,390 stars. You could read and benchmark K3's attention design roughly four months before you could download K3. If you build your own long-context stack, those repos are worth more to you than the checkpoint.

What MXFP4 actually covers

Moonshot applied quantization-aware training from the supervised fine-tuning stage onward, using MXFP4 weights with MXFP8 activations. This is not a post-training squeeze, so the usual "the quant broke it" caveat does not apply the same way.

But the 4-bit format does not cover the whole model. The config's ignore list keeps self-attention, the shared experts, the dense MLP projections, the LM head, the vision tower and the multimodal projector out of MXFP4. Only the routed expert Linear layers are packed to 4 bits, at group size 32. That is exactly why 2.8T parameters still weigh 1,561 GB rather than the ~1.4 TB a naive 4-bit calculation gives you.

What it takes to run

Blunt version: this is a multi-node deployment or nothing. The weights alone need 1,453.8 GiB resident before you allocate KV cache, activations, or any headroom for fragmentation.

So a single 8x H100 node does not load this model, and the widely repeated "8x H100 minimum" figure is short by more than a factor of two. On B200s you can technically fit the weights across eight cards, but you are leaving almost nothing for a 1M-token KV cache, so plan for two nodes.

Moonshot lists three supported inference engines in the model card: vLLM, SGLang, and TokenSpeed, each with a published K3 recipe. Day one there are no community GGUF, AWQ or Unsloth conversions, which is unsurprising: requantizing a QAT MXFP4 MoE of this size is not a weekend job, and anything that appears in the next few days deserves scrutiny before you trust it.

For scale, here is how much the previous open Kimi models actually get pulled, straight from the Hugging Face API. These are 30-day counts, and most of them are quantization pipelines, mirrors and eval harnesses rather than production deployments, which is worth remembering whenever a release gets called widely deployed. K3 is too fresh to compare: its counter had not meaningfully moved at the time of writing, and Hugging Face updates these on a lag.

Benchmarks, with the usual asterisk

Every number below comes from Moonshot's own model card, run on their harness. We have not reproduced any of it, and K3 is far beyond what we can bench locally. Treat this as a vendor claim until third parties replicate it. The pattern across all 46 reported benchmarks is that K3 and Fable 5 trade wins, with GPT-5.6 Sol close behind.

Credit where it is due: Moonshot says so itself. The tech report's abstract states that K3's overall performance "still trails the most powerful proprietary models, namely Claude Fable 5 and GPT-5.6 Sol", while beating every other model in their suite. A lab publishing that sentence in its own launch paper is worth more than any leaderboard screenshot, and it is a useful corrective to the week's louder claims that K3 simply beats everything.

K3 leads on SWE-Marathon by 7 points, on MCPMark-Verified by 7.1, and on BrowseComp by 3.2. It trails on FrontierSWE, GDPval and AA-Briefcase. Long-horizon agentic work is where it looks strongest, which lines up with what it was built for. For the launch-week pricing and arena context, see our Kimi K3 model breakdown.

What it actually built

The most concrete evidence in the report is not a benchmark, it is two artifacts you can go read. Both are Apache 2.0 on GitHub, published July 23.

nano-kpu is an inference-chip prototype that K3 designed, optimized and verified in a single 48-hour autonomous run driving open-source EDA tools. Inside a 4 mm2 area budget it closes timing at 100 MHz and simulates decode throughput above 8,700 tokens per second, with 1.46M standard cells and an INT4 MAC array. MiniTriton is a compact Triton-like GPU compiler K3 wrote end to end, from a tile-level Python frontend through MLIR passes to PTX code generation, with autograd and distributed primitives on top.

On kernel optimization, Moonshot reports K3 cutting AttnRes latency from 283.6 ms to 114.4 ms and reducing KDA runtime by 73.6 percent, and says an early K3 checkpoint was already doing most of their kernel work during late development. These are still first-party claims, but unlike a benchmark score the output is sitting in a public repo where you can judge it yourself.

Limitations and gotchas

• Read the LICENSE before you build a business on it. The 20 million dollar Model-as-a-Service threshold is aggregate company revenue, not model revenue, and it is easy to misread as the latter.
• Benchmarks are entirely first-party at this point, produced on Moonshot's own agent harness. Nothing has been independently replicated yet.
• Size is the wall, not a temporary inconvenience. There is no path where this runs on one GPU, and MXFP4 is already applied, so there is no easy 2x saving left on the table.
• No community quants on day one. Early conversions of a QAT MXFP4 MoE this large are likely to be broken. Check the repo discussions before trusting one.
• The vision tower and multimodal projector are unquantized, so multimodal serving carries more memory than the headline 4-bit number suggests.
• Using the hosted API instead means sending your code to a China-hosted endpoint. Self-hosting is the entire point of this release for anyone with a data residency constraint.

Who should use it

Pull the weights if you already run multi-node inference, you need frontier-class agentic coding you fully control, and license terms or data residency matter more than convenience. Pull them too if you research architectures, because a 69/24 linear-to-full attention split at 2.8T scale is the most interesting thing in this release regardless of the benchmark table.

Skip it if you have one GPU, or one node. That is arithmetic, not a judgment. For open coding models you can actually run this week, Kimi K2.7 Code and GLM-5.2 remain the sane picks, and our June 2026 open-weight roundup covers the smaller end of the field.

Get started in under 10 minutes

If you have the hardware, start the download and read the model card while it runs. Check the license and the layer split first, both are small files.

pip install -U "huggingface_hub[cli]"

# Read the license and architecture before committing 1.5 TB of disk.
hf download moonshotai/Kimi-K3 LICENSE config.json --local-dir ./kimi-k3
python3 -c "import json;c=json.load(open('./kimi-k3/config.json'))['text_config'];\
la=c['linear_attn_config'];\
print('layers:', c['num_hidden_layers']);\
print('KDA:', len(la['kda_layers']), 'full attention:', len(la['full_attn_layers']));\
print('experts:', c['num_experts'], 'active:', c['num_experts_per_token'])"

# Then the weights. Budget the disk and the time.
hf download moonshotai/Kimi-K3 --local-dir ./kimi-k3

No cluster? The API is OpenAI-compatible, so you can point an agent you already run at K3 by changing two lines.

# Any OpenAI-style SDK works; change base_url and model, keep the rest.
from openai import OpenAI

client = OpenAI(
    api_key="sk-...",                      # key from platform.kimi.ai
    base_url="https://api.moonshot.ai/v1",
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user",
               "content": "Refactor this repo's auth module and add tests."}],
)
print(resp.choices[0].message.content)

Long single-shot builds are where a 1M-token context earns its keep. Hand it an entire spec, let it run, and compare the result against whatever you pay for now.

Sources and further reading

• moonshotai/Kimi-K3 on Hugging Face (weights, model card, config)
• The Kimi K3 License, full text
• Kimi K3 technical report (PDF): architecture, training recipe, infrastructure, case studies
• Moonshot: official Kimi K3 tech blog
• MoonshotAI/nano-kpu: the inference chip K3 designed autonomously and MoonshotAI/minitriton: the GPU compiler it wrote
• MoonshotAI/FlashKDA: Kimi Delta Attention kernels (MIT)
• MoonshotAI/Attention-Residuals
• vLLM and SGLang, the two supported open inference engines
• SingularityByte: Kimi K3 model breakdown (launch week)

Tested on: not independently benchmarked. Kimi K3 is a 2.8T-parameter MoE requiring multi-node inference, which is beyond our local bench, so every benchmark figure here is Moonshot-reported. Repository contents, file count, byte total, license text, architecture parameters, quantization config and download counts were read directly from the Hugging Face and GitHub APIs, not from secondary reporting. Hardware figures are computed from the measured 1,453.8 GiB weight total.
Date checked: 2026-07-27