TL;DR: Moonshot shipped the full Kimi K3 weights on July 27 — 96 safetensors shards, 1.56TB, under a permissive custom license that costs a home lab nothing. The specs are now confirmed: 2.8T total, 104B active. Serving it takes a Blackwell-class 8-GPU node at minimum, and llama.cpp can’t load it yet.

	Kimi K3 API	Rented multi-node pod	Wait for GGUF support
Best for	Almost everyone	Data-sovereignty workloads, fine-tune experiments	Home labs with terabyte-class RAM plans
Cost	$0.30 cached / $3 in / $15 out per M tokens	~$70/hr for 16× H200 class capacity	$0 today; your patience
The catch	Prompts leave your machine	Weights alone are 1.56TB; 8 GPUs is the floor	No kimi_k3 architecture in llama.cpp yet — nothing loads

Honest take: The weights landing changes the license and the serving stack, not your shopping list. No consumer rig runs a 1.56TB model, period. Use the API or a rented pod if you need K3 itself; if you want trillion-class weights on hardware you own, Kimi K2.7 Code’s 325GB 2-bit build is still the realistic ceiling.

Moonshot AI hit its own deadline. On July 27, 2026, the full Kimi K3 weights appeared on Hugging Face — 120 files, of which 96 are safetensors shards totaling 1,560,936,091,448 bytes. That’s 1.56TB in decimal units, or 1.42 TiB if your filesystem thinks in binary. It is the largest open-weight release ever made, and it arrived with something rarer than the weights themselves: a working day-0 serving stack.

When we published our Kimi K3 hardware guide on July 18, the weights were still a promise and every footprint figure was an estimate scaled from the Kimi K2 family. The weights are real now, the spec sheet is official, and two of our estimates needed correcting. Here’s what actually landed, what the license really says, and what it takes to serve the thing.

What’s actually in the repo

The download is exactly what Moonshot promised: the native MXFP4 weights, quantization-aware trained from the SFT stage onward, with MXFP8 activations. There is no FP16 “full precision” version — 4-bit microscaling floating point is the full-precision release. That’s why a 2.8-trillion-parameter model fits in 1.56TB instead of the 5.6TB that BF16 would demand.

The official spec sheet, from Moonshot’s GitHub README, settles every number the community had been guessing at:

Spec	Confirmed value
Total parameters	2.8T
Activated per token	104B
Layers	93 (1 dense)
Attention	69 KDA layers + 24 Gated MLA layers
Experts	896 total, 16 selected per token + 2 shared
Context window	1,048,576 tokens
Vision encoder	MoonViT-V2, 401M params
Quantization	MXFP4 weights / MXFP8 activations (QAT)
Vocabulary	160K

The one that matters most: 104B active parameters. Our July guide estimated 40–60B active from the 16-of-896 routing, and early coverage guessed the same range. Everyone was low. K3 activates roughly double what we projected — closer to 3.7% of the total than 2% — which means per-token compute (and therefore tokens/sec on a given memory pool) behaves like a ~100B dense model, not a ~50B one. Moonshot claims the Stable LatentMoE design still nets a ~2.5× scaling-efficiency gain over Kimi K2. The capacity bill is unchanged either way: all 2.8T parameters must sit in memory, because the router picks different experts every token.

The license, actually read

The weights ship under a custom “Kimi K3 License,” not MIT or Apache 2.0 — and license-name headlines have burned home labbers before (see the FLUX licensing mess). So we read the full text. It’s an MIT-style grant — use, modify, fine-tune, distribute, even sell — with exactly two strings attached:

1. The Model-as-a-Service clause. If you (plus affiliates) run a business selling K3 inference or fine-tuning access, and your aggregate revenue exceeds $20 million over any 12 months, you need a separate agreement with Moonshot before commercial use.
2. The badge clause. If your product built on K3 has more than 100 million monthly active users or more than $20 million in monthly revenue, you must display “Kimi K3” prominently in the UI.

Internal use — anything that doesn’t expose the model or its outputs to third parties — is explicitly exempt from both. For a home lab, a research group, or any startup smaller than a unicorn, this is functionally a free license: local inference, fine-tunes, quantized re-uploads, and community GGUF conversions are all clearly permitted. That last point matters, because the entire local-AI pipeline (Unsloth quants, GGUF mirrors, Ollama packaging) depends on redistribution being legal. It is.

The benchmark claims: frontier, with an asterisk

Moonshot’s README puts K3 at or above the closed frontier on agentic work, and the numbers deserve both attention and skepticism — they’re vendor-reported, run at maximum reasoning effort, and the harnesses vary by model (K3 uses Moonshot’s own Kimi Code harness on most coding rows, per the README’s own footnotes).

Taking them at face value: Terminal-Bench 2.1: 88.3, within half a point of GPT-5.6 Sol (88.8) and Claude Fable 5 (88.0). SWE-Marathon: 42.0, the top score in the table, ahead of Claude Opus 4.8 (40.0) and GPT-5.6 Sol (39.0), with K3 running the same Claude Code harness as the Anthropic models on that row. BrowseComp: 91.2, the best listed. GPQA Diamond: 93.5. Against GLM-5.2 — the previous open-weight champion on our July leaderboard — K3 leads every coding and agentic row, often by 5–20 points.

Independent verification is trickling in (Artificial Analysis sourced several rows in Moonshot’s own table, dated July 23), but the honest summary is: for the first time, an open-weight model is credibly claiming parity with the closed frontier on long-horizon agentic tasks, not merely closing the gap. If even most of it survives independent testing, the open-vs-closed story we tracked in the gap analysis just ended its final chapter.

Serving it: what vLLM’s day-0 support actually requires

The most consequential part of the release isn’t the shards — it’s that the serving stack worked on day one. K3’s Kimi Delta Attention breaks conventional prefix caching, so Moonshot contributed its own vLLM implementation rather than waiting for the community, and vLLM shipped day-0 support alongside the weights, with two MoE backends (TRT-LLM-Gen for tensor parallel, MegaMoE for expert-parallel deployments) and the MoE path executing natively in MXFP4.

The official vLLM recipe is one line:

vllm serve moonshotai/Kimi-K3 --tensor-parallel-size 8

The hardware behind that one line is the catch. vLLM’s stated minimum is a single node of 8× GB300-class GPUs — that’s 288GB of HBM3e per GPU, 2.3TB pooled, the same silicon in the Dell deskside monster that’s priced for IT departments. On 16× GB300, vLLM reports 118 tok/s per request without speculative decoding and 370 tok/s with DSpark enabled. Those are the first real, published K3 throughput numbers, and they’re excellent — for hardware nobody reading this owns.

Do the arithmetic for one tier down. An H200 has 141GB, so an 8× H200 node pools ~1.13TB — less than the 1.56TB of weights. H200-class serving means two nodes minimum, 16 GPUs, before you budget a single token of the 1M context window’s KV cache. SGLang and Moonshot’s own TokenSpeed engine are the other two officially recommended paths, with the same physics.

The rental math

Nobody’s buying a GB300 node for a hobby, but renting one hour of K3 is genuinely doable. H200s run about $4.39/hr on RunPod secure cloud as of July 2026, so a 16-GPU footprint is roughly $70/hr, or about $1,690 a day. Our cloud GPU pricing guide has the full provider comparison.

Against the API — $0.30 per million cached input tokens, $3.00 uncached, $15.00 output, flat across the full 1M-token window — the pod only wins in three scenarios: your data legally can’t leave your infrastructure, you’re fine-tuning (which the license fully permits), or you’re saturating the node with parallel agentic traffic around the clock. At $70/hr you’d need to consistently burn well over 4M output-equivalent tokens per hour before self-hosting beats the metered price. For everyone else, Moonshot is effectively subsidizing your inference; take the deal.

The llama.cpp situation: don’t download 1.5TB yet

Within hours of release, community GGUF conversions appeared on Hugging Face. None of them load. Mainline llama.cpp has no kimi_k3 architecture, so every one of those files currently dies with the familiar rejection:

llama_model_load: error loading model: error loading model architecture:
unknown model architecture: 'kimi_k3'

That’s the same failure mode we broke down in the unknown-architecture fix guide, and the fix is the same: nothing on your end. No flag, no re-download, no conversion trick makes an unsupported architecture load — support has to land upstream first. The groundwork is underway in llama.cpp discussion #26041, which mapped a correctness-first KDA implementation onto existing ggml primitives before the weights even dropped. The open question is how much custom kernel work the 69 KDA layers need; the 24 Gated MLA layers and the MoE FFNs are closer to known territory.

Until that merges, skip the 1.5TB download unless you’re on an unmetered connection and enjoy watching progress bars. When support does land, expect the Unsloth-style dynamic quants to follow quickly — but temper the size expectations. K3 was trained at 4 bits. The usual “grab the 4-bit GGUF and save 75%” dividend is already spent in the native release; community quants below MXFP4 will be trading real quality for the shrink, and even a hypothetical 2-bit build of a 1.56TB model still lands north of 700GB. That’s four Mac Studio M3 Ultras clustered over Thunderbolt 5, the $38k configuration we costed out for the K2 generation — or one very patient dual-EPYC box with terabyte-class DDR5 grinding out single-digit tokens per second.

What this changes for a home lab (and what it doesn’t)

Nothing about July 27 makes K3 runnable on consumer hardware. A 32GB RTX 5090 holds 2% of the weights. The six-state Shard experiment that ran GLM-5.2’s 744B over WAN pipeline parallelism would need to more than double its pooled memory before K3 fits. If your goal is the best open model your GPU can actually hold, the answer is unchanged from our leaderboard: Qwen3.6 and Gemma 4 for single cards, Qwen3-Coder 480B and the K2 line for big-RAM rigs.

What the release does change:

• The license precedent. The biggest model ever released is also freely fine-tunable and redistributable below $20M revenue. Every future frontier release will be measured against that.
• The serving-stack precedent. A model lab contributing its own vLLM attention implementation before release day should embarrass every vendor that ships weights and lets the community reverse-engineer inference for six weeks.
• The agentic coding option. K3 is built to live inside a coding agent (Moonshot pushes its own Kimi Code CLI; it also runs in Claude Code-compatible harnesses per the README footnotes). If you’re evaluating it against Cursor, Cline, or Copilot-class tooling, our sister site’s agent coverage tracks that side.
• The distillation pipeline. K3’s weights being open means the community can distill it into sizes that do fit consumer cards. That’s the real home-lab payoff, and it starts now, not when someone builds a 2TB rig.

FAQ

Can I run Kimi K3 on my GPU? No. The weights alone are 1.56TB in their smallest official form. The minimum vLLM deployment is an 8× GB300-class node (2.3TB pooled HBM). No consumer card, and no realistic consumer multi-GPU rig, comes within an order of magnitude.

Is the Kimi K3 license safe for personal and small-business use? Yes. The two restrictions trigger at $20M in 12-month revenue (for inference-as-a-service businesses) and 100M MAU or $20M monthly revenue (for the display requirement). Below those thresholds it reads like MIT: use, modify, fine-tune, redistribute, sell.

When will Ollama or LM Studio support K3? Both depend on llama.cpp, which has no kimi_k3 architecture yet. Watch discussion #26041 in the llama.cpp repo. And remember the practical floor: even aggressive sub-native quants will exceed 700GB, so support landing doesn’t mean your hardware qualifies.

How fast is K3 when properly hosted? vLLM’s published day-0 numbers: 118 tok/s per request on 16× GB300 without speculative decoding, 370 tok/s with DSpark. API-side speed will vary with load.

Should I use the API or rent GPUs? API, unless data sovereignty or fine-tuning forces your hand. At $0.30/M cached input, agentic workloads with stable system prompts get most of their input near the cache floor, and a 16× H200 rental (~$70/hr) only breaks even at sustained multi-million-token-per-hour throughput.

Sources

• Kimi K3 README (specs, benchmarks, deployment) — MoonshotAI on GitHub
• Kimi K3 License full text — MoonshotAI on GitHub
• moonshotai/Kimi-K3 weights repository — Hugging Face
• Kimi K3 Is Here: Efficient Day-0 Support on vLLM — vLLM Blog
• moonshotai/Kimi-K3 deployment recipe — vLLM Recipes
• Kimi K3 pre-release analysis and llama.cpp groundwork, discussion #26041 — ggml-org/llama.cpp
• Kimi API pricing — Kimi Help Center
• NVIDIA H200 cloud price comparison, July 2026 — GetDeploying
• Moonshot AI releases Kimi K3 open-weight model for download — Quartz
• Kimi K3 Hugging Face weights coverage (shard count and byte totals) — kimi-k2.org

Last updated July 29, 2026. Prices, specs, and support status change fast; verify current numbers before spending money. Benchmark figures in the “frontier” section are Moonshot’s own reported results pending broader independent verification.

Recommended Gear

• Mac Studio M3 Ultra — the unified-memory building block for terabyte-class local clusters
• RTX 5090 — still the top consumer card for the models that actually fit one GPU