TL;DR: Kimi K3 is the largest open-weight model ever released — 2.8 trillion parameters under an MIT-style license that leaves home labbers and internal business use completely unrestricted. The catch is physics: even Unsloth’s 1-bit GGUF is 594GB, so “self-hosting” means a 610GB+ RAM server, a multi-GPU datacenter node, or waiting. Most readers should use the API and watch mainline llama.cpp support land.

	Unsloth 1-bit GGUF	vLLM (native MXFP4)	Kimi API
Best for	Privacy-first labs with huge RAM	Teams with datacenter GPUs	Everyone else
Memory needed	~610GB RAM+VRAM (594GB file)	~1.56TB of weights across nodes	None
Cost	$6–10k+ server, or ~$2k/mo cloud RAM box	Five figures/month in GPU rental	Metered per token
The catch	Mainline llama.cpp can’t load it yet — Unsloth’s fork only	Multi-node H200/B300-class deployment	Your prompts leave your network

Honest take: The license is genuinely home-lab-friendly and the weights are real — but at 2.8T parameters, Kimi K3 is the first open model where the license isn’t the barrier, the hardware is. Use the API today, bookmark the GGUF repo, and self-host K2.7 or DeepSeek V4-Flash instead if you need frontier-class local inference this month.

Moonshot AI shipped the full Kimi K3 weights on July 27, 2026, making good on the “open frontier” promise from the model’s announcement two weeks earlier. It is the first open 3T-class release: 2.8 trillion total parameters, 104B active per token, native vision, and a 1,048,576-token context window. This guide covers the three questions that matter for self-hosters: what the license really permits, what hardware each path requires, and what to do while the tooling catches up.

The license: MIT-style with two big-company clauses

Kimi K3 does not ship under plain MIT or Apache 2.0. It uses the Kimi K3 License, a short MIT-derived text you can read in full in the MoonshotAI/Kimi-K3 repository. The grant is broad — use, copy, modify, distribute, sublicense, sell, fine-tune, and create derivatives — with two conditions layered on top:

1. Model-as-a-Service revenue clause. If you operate a “Model as a Service” business (selling third parties meaningful control over inference or fine-tuning, e.g., via API) and your aggregate revenue exceeds $20M over any consecutive 12 months, you need a separate agreement with Moonshot AI before commercial use.
2. Attribution clause. If a commercial product built on K3 (or derivatives) exceeds 100 million monthly active users or $20M in monthly revenue, “Kimi K3” must be prominently displayed in the product’s UI.

Critically, Section 4 exempts internal use — defined as any use that doesn’t expose the model, its outputs, or its capabilities to third parties — from both clauses. A home lab, an internal company deployment, a research cluster: all unrestricted. This mirrors the Modified MIT terms of Kimi K2.7 Code, with a tightened MaaS definition. It is not OSI-approved open source, but for the self-hosting audience the practical answer is: you can run it, fine-tune it, and quantize it without asking anyone.

The architecture, briefly

K3 is not a scaled-up K2. The model card lists 93 layers combining Kimi Delta Attention (KDA) with 24 Gated MLA layers, Attention Residuals, and a Stable LatentMoE design that activates 16 of 896 experts (plus 2 shared) per token — Moonshot claims roughly 2.5× the scaling efficiency of Kimi K2. The vision side is a 401M-parameter MoonViT-V2 encoder in the same checkpoint. The weights were trained quantization-aware in MXFP4 (with MXFP8 activations), so the native checkpoint is already “4-bit” — there is no BF16 version to fetch, and the full download is about 1.56TB.

That KDA architecture is also why your existing tooling doesn’t work yet, which brings us to the hardware section.

Path 1: Unsloth GGUF on a big-RAM server

Unsloth published Kimi-K3-GGUF on July 29 with six quantization tiers. The three that matter:

Quant	File size	Memory floor (RAM+VRAM)	Notes
UD-IQ1_S (1-bit dynamic)	594GB	~610GB	Unsloth’s recommended starting point
UD-Q2_K_XL	861GB	~880GB	Noticeably closer to full quality
UD-Q8_K_XL	~1.56TB	~1.6TB	Effectively lossless — matches native MXFP4/BF16 layout

Unsloth reports the 1-bit build handles tool calls reliably and one-shots real tasks, but those are the quantizer’s own tests — treat accuracy claims as vendor-reported until independent benchmarks land. The rule of thumb from our GGUF quantization guide holds: your combined RAM + VRAM must exceed the file size, and MoE expert offload to CPU is what makes this class of model usable at all.

The blocker: mainline llama.cpp cannot load Kimi K3 as of late August 2026. The KDA + Gated MLA architecture is new, and while an upstream pull request is active, today you must build Unsloth’s llama.cpp fork (linked from their Kimi K3 guide) or run through Unsloth Studio. The download pattern is the standard one:

huggingface-cli download unsloth/Kimi-K3-GGUF \
  --include "UD-IQ1_S/*" --local-dir ./kimi-k3

Then serve with the fork’s llama-server, offloading experts to system RAM if you have a GPU in the box:

./llama-server -m ./kimi-k3/UD-IQ1_S/Kimi-K3-UD-IQ1_S-00001-of-00013.gguf \
  -ot ".ffn_.*_exps.=CPU" --ctx-size 32768 --temp 1.0

Check Unsloth’s guide for the current fork branch and exact shard names before you commit to a 594GB download — this is a fast-moving target, and the flags above follow the same expert-offload pattern we used for DeepSeek V4-Flash. Realistic hardware: a used EPYC or Xeon server with 768GB of DDR5 (or 1TB of DDR4 if you accept slower decode), ideally with one RTX 4090 holding the attention layers and KV cache. Expect single-digit tokens per second. A 512GB Mac Studio does not fit even the 1-bit file — this is the first open model to outgrow Apple’s unified-memory ceiling on a single machine.

One more practical note: a 594GB model wants fast storage. Loading from a Samsung 990 Pro 4TB NVMe takes minutes; from a hard drive, closer to an hour per load.

Path 2: vLLM or SGLang at native precision

Moonshot’s official deployment story is vLLM, SGLang, and TokenSpeed, with day-one KDA support merged into vLLM. At ~1.56TB of native MXFP4 weights plus KV cache for a 1M-token context, this is a multi-node deployment — think 16× H200-class or 8× B300-class GPUs, which is rental territory for everyone outside a datacenter. Unsloth cites roughly 20 tok/s per user on B200 hardware. If you want to experiment at this scale without owning it, RunPod rents multi-GPU nodes by the second; our Qwen3-Coder 480B guide walks through the honest cost math for that pattern, and the numbers only get steeper here.

Path 3: The API, with self-hoster-relevant quirks

If you use the hosted model at platform.kimi.ai (OpenAI- and Anthropic-compatible endpoints) while waiting for tooling to mature, two behaviors matter because they differ from every other model you’ve wired into Open WebUI or LibreChat:

• Thinking is always on. K3 returns reasoning_content on every response, with a top-level reasoning_effort field (low, high, max — default max). Budget output tokens accordingly.
• Preserved thinking history. K3 was trained expecting the complete assistant message — including reasoning_content and tool_calls — passed back verbatim in multi-turn conversations. Clients that strip reasoning before resending history will silently degrade multi-turn and agentic performance. Check whether your frontend preserves it before blaming the model.

Moonshot’s benchmark table puts K3 at the frontier — 93.5 GPQA Diamond, 88.3 Terminal-Bench 2.1, 81.2 FrontierSWE, trading wins with Claude Fable 5 and GPT-5.6 Sol — but all published numbers are vendor-run at max effort. No independent replication exists yet; the pattern from every 2026 flagship applies.

When NOT to self-host Kimi K3

• You have less than ~610GB of combined memory. Nothing fits. Kimi K2.7 Code runs its 1.8-bit quant on a 24GB GPU with 256GB RAM and remains the practical Moonshot model for home labs.
• You need it for production this quarter. The Unsloth fork works, but mainline llama.cpp, Ollama, and LM Studio support don’t exist yet. Architecture support has historically landed 2–6 weeks after release; KDA is unusual enough that it may take longer.
• Your workload doesn’t need 1M context or vision. DeepSeek V4-Flash at ~160GB delivers most of the coding capability at a tenth of the memory.

The right frame: K3’s release is the moment “open weights” and “self-hostable” fully decoupled. The license says yes; the hardware, for now, mostly says rent it or wait. For GPU and big-RAM server picks to run what does fit locally, see the hardware guides at runaihome.com, and for using K3 as a coding backend in editor agents, aicoderscope.com covers the cloud side.

FAQ

Is Kimi K3 open source? Not by OSI definition — the Kimi K3 License adds a $20M MaaS revenue clause and a 100M-MAU attribution clause. For personal, research, and internal commercial use it behaves exactly like MIT: no restrictions, no attribution required.

Can I run Kimi K3 with Ollama or LM Studio? Not as of late August 2026. The KDA architecture isn’t supported in mainline llama.cpp yet (an upstream PR is in progress), which both tools depend on. The only local path today is Unsloth’s llama.cpp fork or Unsloth Studio with their GGUF builds.

What is the absolute minimum hardware for local Kimi K3? About 610GB of combined RAM + VRAM for the 594GB UD-IQ1_S quant — realistically a 768GB-RAM server. There is no consumer-GPU path, and a single 512GB Mac Studio falls short. If that’s out of budget, rent a node on RunPod or use the API.

Recommended Gear

• RTX 4090 — holds attention layers and KV cache while experts run from system RAM
• Samsung 990 Pro 4TB — fast NVMe storage for 600GB-class model files

Sources

• MoonshotAI/Kimi-K3 — official repository, LICENSE and model card
• unsloth/Kimi-K3-GGUF on Hugging Face
• Unsloth documentation: Kimi K3 — How to Run Locally
• vLLM recipes: Kimi K3 deployment
• Kimi K3 GGUF: running the largest open-weight model locally (community guide)