Short answer: Kimi K3 is genuinely downloadable as an open-weight model. Its official repository is about 1.56TB, its sparse architecture contains 2.8T total parameters with 104B active, and the practical serving recipes still use datacenter GPU clusters. Colibri v1.4.0 now adds a technically local, text-only path that streams roughly 1.45TB of experts from NVMe, but measured output remains in seconds per token. K3 is locally researchable on a workstation; it is still not a practical personal-computer assistant.
What is Kimi K3?
Moonshot AI introduced Kimi K3 on July 16, 2026 as its largest and most capable model, then published the full weights on Hugging Face. The headline number is 2.8 trillion total parameters, but the architecture is a sparse Mixture-of-Experts system. Each token selects 16 experts from a pool of 896, resulting in 104B activated parameters per token rather than dense use of the whole network.
K3 is designed for long-running agentic work rather than short chat alone. It combines native image understanding, a one-million-token context window, tool use, coding and document workflows. Moonshot says the model can operate Kimi Code, Kimi Work and general multi-step agents from the same foundation.
Web, API and Kimi tools
K3 is available through kimi.com, the Kimi API, Kimi Code and Kimi Work. For almost every individual and most companies, hosted access is the practical route.
Full downloadable weights
The official repository contains 96 weight shards and totals about 1.56TB. The weights and code use the custom Kimi K3 License.
Kimi K3 on Arena: what #1 actually means
The live Arena leaderboard placed Kimi K3 first in Frontend Code Arena during its launch window, ahead of Claude Fable 5 and GPT-5.6 Sol. Arena rankings are based on blind human preferences, so this is strong evidence that users preferred K3's frontend output. It is not proof that K3 is the best model for every task, and live ranks can move as votes accumulate.
This distinction matters. A specialized frontend Arena win says K3 can produce extremely convincing web interfaces. It does not automatically make it the best model for scientific reasoning, factual research, backend reliability or your own private codebase. The most useful view combines Arena preference with task benchmarks and the constraints of the deployment.
Official coding benchmarks
The following scores come from Moonshot's Kimi K3 launch report. They are useful, but they are vendor-published results, not a LocalClaw reproduction. K3 was run at maximum effort with temperature 1 and top-p 1, and many coding tests used Moonshot's Kimi Code harness. Harness choices can materially change results.
| Benchmark | Kimi K3 | Claude Fable 5 | GPT-5.6 Sol | Claude Opus 4.8 | GLM-5.2 |
|---|---|---|---|---|---|
| DeepSWE | 67.5 | 70.0 | 73.0 | 59.0 | 46.2 |
| Program Bench | 77.8 | 76.8 | 77.6 | 71.9 | 63.7 |
| Terminal Bench 2.1 | 88.3 | 88.0 | 88.8 | 84.6 | 82.7 |
K3 wins this comparison on Program Bench and comes within half a point of GPT-5.6 Sol on Terminal Bench 2.1. It does not win DeepSWE, where GPT-5.6 Sol leads. Moonshot's own conclusion is appropriately measured: K3 is competitive with the frontier, but still trails the strongest proprietary systems overall.
There is also a small but important DeepSWE reporting detail. The main launch table shows 67.5, while an official footnote reports 67.3 with the benchmark's mini-SWE-agent harness. That difference is tiny, but it demonstrates why benchmark names without harness details can mislead.
Search, agents and reasoning
These results explain why K3 feels bigger than a coding release. Search and tool-use scores are central to Moonshot's pitch. The model is meant to collect information, manipulate software and stay coherent across long tasks. For agent builders, that may matter more than a small difference on a single reasoning benchmark.
How to read the benchmark claims
Kimi K3 is clearly frontier-class, but a score is not a neutral fact without its harness. Moonshot reports all K3 results at maximum reasoning effort. Kimi Code is used for several coding evaluations, Claude Code or Codex is used for competing models on other rows, and some results come from public leaderboards while others are vendor-run. The official report documents these differences, which is good practice, but they still prevent a perfectly controlled model-to-model comparison.
The launch-week 1,679 Frontend Code Arena result is also historical rather than permanent. Arena is a live human-preference leaderboard, so ranks and confidence intervals can move as votes accumulate. Treat it as strong evidence of excellent frontend output, not a universal declaration that K3 is best at every form of software engineering.
Why the architecture is a big deal
| Component | Kimi K3 design | Why it matters |
|---|---|---|
| Scale | 2.8T total parameters | An enormous knowledge and capacity envelope. |
| Sparse MoE | 16 of 896 experts selected per token | Avoids activating the entire network for every generated token. |
| Long context | 1,048,576 tokens | Designed for large repositories, documents and persistent agent state. |
| Vision | Native image input | Lets the same model reason over screenshots, interfaces and documents. |
| Attention | KDA plus Attention Residuals | Moonshot's efficiency path for extreme context and deep networks. |
| Numerics | MXFP4 weights, MXFP8 activations | Quantization-aware training reduces serving cost without a post-hoc conversion step. |
Kimi Delta Attention, Attention Residuals and Stable LatentMoE are not merely branding terms. Together they target the three problems that appear at this scale: attention cost over long contexts, stable signal flow through a deep network and efficient expert routing.
Is Kimi K3 actually open source?
The precise answer is: open weight under a custom license.
Moonshot publishes the model weights, configuration and inference code, and the Kimi K3 License broadly allows use, modification, distribution, fine-tuning and commercial products. That is materially more open than API-only access.
However, it is not an OSI-approved software license. Model-as-a-Service businesses above $20 million in aggregate revenue over a consecutive 12-month period need a separate agreement for commercial use. Commercial products above 100 million monthly active users or $20 million in monthly revenue must prominently display the Kimi K3 name. For individuals, researchers and most internal enterprise deployments, those thresholds are unlikely to apply, but legal review still belongs in a serious deployment plan.
Calling K3 "open source" is understandable shorthand, but "open weight" is the more accurate term. You can inspect and host the model, yet your rights are governed by a model-specific license with scale-dependent conditions.
Can you run Kimi K3 locally?
Technically yes. Practically, not as a normal personal assistant.
The official Hugging Face repository is 1.56TB before you reserve working space for caches, containers, logs and model updates. A 512GB Mac Studio cannot hold the full checkpoint in unified memory, and a 32GB RTX 5090 provides less than 3% of the memory needed for the weight files alone.
For conventional high-throughput serving, Moonshot recommends supernodes with 64 or more accelerators. That is a scale-out recommendation, not an absolute minimum to execute a token. Published SGLang recipes show smaller configurations, but even the smallest is an eight-GPU datacenter server.
The new exception is storage-streamed research inference. Colibri can keep a reduced dense set resident while loading routed experts from NVMe. This avoids requiring the full checkpoint in RAM or VRAM, but trades that capacity requirement for a very large storage footprint and severe latency.
The Colibri experimental path
Colibri v1.4.0 documents a Kimi K3 runtime that streams the checkpoint's QAT-trained MXFP4 experts directly from the original shards. The routed expert bank is approximately 1.45TB, while the dense resident set is about 35GB at 4-bit or 57GB at int8. This runtime is text-only and does not load K3's vision tower.
In the project's measured 93-layer run, direct I/O reduced output time from roughly 21 seconds per token to about 9.4 seconds per token. That is a significant systems result, but it is still far from conversational speed. It proves that K3 can be studied without a GPU supernode; it does not turn K3 into an Ollama-style daily driver.
LocalClaw classification: conventional Kimi K3 serving remains datacenter-class. Colibri is an experimental advanced runtime, not a reason to recommend K3 to ordinary 32GB or 64GB machines. See the full Colibri architecture and performance guide.
Published Kimi K3 serving shapes
| Accelerator | SGLang topology | Infrastructure reality |
|---|---|---|
| NVIDIA B300 | 1 node x 8 GPUs | Smallest published NVIDIA recipe; still a dedicated datacenter server. |
| NVIDIA B200 | 2 nodes x 8 GPUs | 16 GPUs with high-speed inter-node communication. |
| NVIDIA H200 | 2 nodes x 8 GPUs | TP16/EP16 serving with NCCL and network-interface configuration. |
| NVIDIA H100 | 4 nodes x 8 GPUs | 32 GPUs; SGLang calls this the platform with the least post-weight headroom. |
| AMD MI350X / MI355X | 1 node x 8 GPUs | ROCm/AITER path with its own kernels and operational stack. |
SGLang also publishes large-scale presets for 16, 32 and 64 Blackwell GPUs. Its documentation warns that final-weight serving rounds and workload-specific re-measurement remain important. In other words, even with the right cluster, the recipe is a starting point rather than a one-click production guarantee.
The hidden costs beyond GPU memory
- Download and storage: 1.56TB takes roughly 3.5 hours at a perfect 1Gbps before protocol overhead. A production host should reserve several terabytes for the model, containers and update headroom.
- Networking: tensor and expert parallelism depend on fast GPU-to-GPU and node-to-node communication. Ordinary office Ethernet is not suitable.
- Context memory: a one-million-token maximum does not mean every deployment can serve that context at useful concurrency. KV cache and KDA state pools must be sized for the actual workload.
- Software maturity: vLLM, SGLang and TokenSpeed are the recommended engines. Drivers, CUDA or ROCm versions, kernels and parsers must all match the selected recipe.
- Operations: monitoring, failover, load testing, access control and cost management remain your responsibility.
"Open weights" and "consumer local" are different categories. Publishing K3 is significant for research, reproducibility and private hosting. It does not make the full model practical on everyday hardware, and even well-funded enterprises should compare self-hosting against the API before buying a cluster.
Kimi K3 versus the current frontier
| Model | Best reason to choose it | Access | Personal local fit |
|---|---|---|---|
| Kimi K3 | Frontend coding, deep search, long-running agents, 1M context | API, official 1.56TB weights, experimental Colibri runtime | Research only |
| Claude Fable 5 | Stronger overall proprietary frontier performance in Moonshot's comparison | Hosted/API | No |
| GPT-5.6 Sol | Leading DeepSWE and slightly leading Terminal Bench in Kimi's table | Hosted/API | No |
| GLM-5.2 | Published open-weight path and Unsloth quantizations | Downloadable, server-grade | Extreme hardware only |
| Qwen 3.6 27B | Strong dense local model for coding and reasoning | Downloadable GGUF | Yes, 32GB class |
| Kimi K2.5 32B | A practical Kimi-family local experience | Downloadable GGUF | Yes, 32GB class |
What should local AI users run instead?
If you want the Kimi style without a datacenter, the correct move is not to pretend K3 fits. Choose a model with a real GGUF or MLX artifact and a memory footprint your machine can sustain.
Kimi K2.5 32B
The closest practical Kimi-family option for a 32GB-class local setup.
Qwen 3.6 27B
A strong balance of coding, reasoning and broad local runtime support.
Qwen 3.6 35B-A3B
A sparse model that demonstrates how MoE can become genuinely practical locally.
Kimi K3 API price
Moonshot's official pricing is $0.30 per million cache-hit input tokens, $3 per million cache-miss input tokens and $15 per million output tokens. K3 uses flat token pricing across its 1,048,576-token window. The tenfold gap between cached and uncached input makes prompt caching important for long-context agents.
Price alone does not determine agent cost. A proactive model can call more tools and generate more output than expected. Track complete task cost, latency and success rate rather than comparing only the input-token headline.
Known limitations
- Thinking history must be preserved: Moonshot warns that dropping prior reasoning context or switching models mid-session can destabilize behavior.
- The model can be too proactive: K3 may take extra actions when a narrower answer would be enough.
- User experience still matters: Moonshot acknowledges a product-experience gap versus the strongest proprietary systems.
- Open serving is still young: the weights are public, but engine recipes, optimized kernels and final-weight performance measurements are still evolving.
- Open-weight video support is not equivalent to the hosted product: Kimi's product materials discuss video understanding, while the current SGLang open serving contract accepts image input, not video or audio.
- Benchmarks are not your workload: test repository constraints, tool reliability, latency and cost before production use.
LocalClaw verdict
Kimi K3 deserves attention. Its #1 Frontend Code Arena launch, 88.3 Terminal Bench score, 95.0 DeepSearchQA result and one-million-token context make it a serious frontier system. Its architecture also shows where large open-weight AI is heading: sparse experts, native low-precision training, extreme context and one model coordinating many tools.
But the honest local answer remains simple. K3 is not a practical personal-computer model. Colibri makes text-only experimentation possible by streaming experts from NVMe, yet documented latency remains measured in seconds per token and the storage requirement stays around 1.5TB. For a Mac or consumer NVIDIA machine, use Kimi K2.5 32B, Qwen 3.6 27B or another verified local model today.
For an enterprise, the decision is economic as much as technical. Self-host K3 only when data locality, control, sustained utilization or custom research justifies a multi-node accelerator cluster and an experienced inference team. Otherwise, the official API is dramatically simpler.
Frequently asked questions
Is Kimi K3 open source?
Kimi K3 is open weight under the custom Kimi K3 License. The full 1.56TB repository is downloadable and the license permits broad use, modification and distribution, with additional conditions for very large Model-as-a-Service and commercial businesses. It is not an OSI-approved open-source software license.
Can Kimi K3 run on a Mac Studio?
Not as a practical interactive deployment. Colibri can technically stream the text model from roughly 1.45TB of NVMe data with a much smaller resident set, but documented output remains measured in seconds per token. Conventional serving recipes still start with eight datacenter GPUs.
How many GPUs does Kimi K3 need?
There is no single universal minimum. Current SGLang recipes use 8 B300 or MI350X-class GPUs, 16 B200 or H200 GPUs, or 32 H100 GPUs. Moonshot recommends supernodes with 64 or more accelerators for efficient large-scale serving.
Is Kimi K3 really #1 on Arena?
Kimi K3 reached #1 on Frontend Code Arena with a score of 1,679 during launch week. This is a specialized, live human-preference leaderboard. It does not mean K3 ranks first on every Arena category or every benchmark.
What is the best local alternative to Kimi K3?
For 32GB-class machines, start with Kimi K2.5 32B or Qwen 3.6 27B. Qwen 3.6 35B-A3B is another efficient MoE option. All have real local artifacts and far more practical memory requirements.
Sources
- Moonshot AI: official Kimi K3 repository, architecture, benchmark table and runtime guidance
- Moonshot AI on Hugging Face: official 1.56TB model repository and weight files
- Official Kimi K3 License
- Moonshot AI: launch article, architecture, pricing and 64-accelerator deployment recommendation
- SGLang: Kimi K3 deployment topologies and serving configuration
- Colibri: experimental storage-streamed Kimi K3 runtime and measurements
- Colibri v1.4.0 release notes
- Kimi API: official pricing documentation
- Arena: live model leaderboards
- Arena: leaderboard and voting policy