Kimi K3 Explained: 2.8 Trillion Parameters, 1M Context, and the Open-Weight Frontier

In July 2026, Moonshot AI released its next flagship model, Kimi K3. It combines 2.8 trillion total parameters, 104 billion active parameters, native vision, and a context window of up to 1,048,576 tokens. The headline is not only that the model is larger. Kimi K3 is designed to make very large models useful for long-running software engineering, knowledge work, multimodal understanding, and agent tasks.

This guide covers:

• what Kimi K3's architecture is trying to solve;
• what the reported benchmarks do and do not prove;
• why a million-token context is an engineering problem, not just a model setting; and
• how to plan GPU, storage, and multi-node infrastructure around Kimi K3.

The Kimi K3 technical report and official Moonshot repository are the primary sources for the specifications below.

Kimi K3's Core Specifications

Kimi K3 uses a mixture-of-experts (MoE) architecture. The model has 896 routed experts, selects 16 experts for each token, and also uses shared experts. That keeps the active compute per token far below the total parameter count, but all experts still need to be stored and made available across the serving cluster.

The distinction between total and active parameters matters. The 2.8T figure describes the complete weight set that must be loaded and stored. The 104B figure is closer to the parameters used in one forward pass. MoE lowers per-token compute, but it does not make Kimi K3 deployable like an ordinary 100B model.

Three Architectural Ideas Behind Kimi K3

Kimi Delta Attention for long context

Standard Transformer attention becomes expensive as sequences grow. KV-cache memory, prefill work, and communication all increase with context length. Kimi K3 introduces Kimi Delta Attention (KDA), a hybrid linear-attention mechanism that processes long sequences through a fixed-size recurrent state while periodically inserting Gated MLA layers for global information exchange.

The 93-layer model contains 69 KDA layers and 24 Gated MLA layers. It does not remove full attention entirely. Instead, it combines long-sequence efficiency with periodic global interaction. A million-token context is therefore a joint design across model structure, cache management, and GPU parallelism.

Reminder: A model that supports 1M tokens does not mean every deployment can serve 1M-token requests cheaply. GPU memory, concurrency, KV-cache settings, prefill time, and the serving engine still determine the usable limit.

Attention Residuals for selective depth

In a conventional Transformer, information is passed mainly from one layer to the next. Attention Residuals (AttnRes) let a layer selectively retrieve useful representations from the embedding layer and earlier blocks. The goal is to keep important information from being diluted across dozens of layers.

AttnRes works alongside KDA, Gated MLA, Stable LatentMoE, and the training recipe to form Kimi K3's backbone. The architectural combination is more important than any single component: the model is built around long-horizon work and efficient sparse execution.

Stable LatentMoE for high sparsity

Selecting 16 of 896 routed experts gives Kimi K3 high total capacity without executing all 2.8T parameters for every token. High sparsity creates a load-balancing problem, because some experts can become overused while others receive little traffic. Moonshot addresses this with Stable LatentMoE and related balancing strategies.

Moonshot reports roughly a 2.5x improvement in overall scaling efficiency compared with Kimi K2. This is an official aggregate assessment, not a promise that every task runs 2.5x faster or costs 2.5x less. Treat it as a model-development claim until an independent, matched benchmark is available. See the official repository for the reported methodology and results.

What Kimi K3 Can Do

Moonshot's published evaluations cover reasoning, coding, tool use, web research, multimodal understanding, and desktop operation.

These numbers point to a model intended for repeated observe, act, check, and revise loops rather than single-turn chat. They are vendor-reported results: some were run by Moonshot, and agent benchmarks depend on the surrounding harness, tools, prompts, and model configuration. The technical report also notes that Kimi K3 does not outperform every leading closed model on every evaluation.

Long-running software engineering

Kimi K3 is trained to inspect large repositories, call terminal tools, write and test code, and continue an engineering task with limited intervention. In one official case study, it analyzed and rewrote GPU kernels. An AttnRes kernel's latency fell from 283.6 ms to 114.4 ms in that test. The result is a Moonshot case study, not a portable guarantee: hardware, compiler, kernel version, and measurement method all matter.

End-to-end knowledge work

The model can combine search, document reading, code execution, data analysis, and visualization into one workflow. Moonshot describes a project that processed decades of AI-chip industry material: 87 quarterly reports, 99 source PDFs, and more than 11,000 pages, with extensive web search and terminal operations. That is closer to a research analyst workflow than a chatbot response.

Vision and tool coordination

Native image input lets the model inspect interfaces, charts, rendered output, documents, and error screens, then choose the next tool action. In an agent system, vision is valuable because it closes the loop between a command and the state that command produced.

Open Weights Do Not Remove the Deployment Barrier

Moonshot recommends vLLM, SGLang, and TokenSpeed for serving Kimi K3 and provides an OpenAI-compatible hosted API through its official channels. The complete model still requires a distributed deployment.

Current public reference topologies include:

• H100: four nodes, eight GPUs per node;
• H200: two nodes, eight GPUs per node;
• B200: two nodes, eight GPUs per node;
• B300: one node, eight GPUs; and
• GB300: two nodes, four GPUs per node.

The vLLM recipe recommends at least eight GB300 GPUs, with production traffic typically requiring more than one node. These recipes are starting points, not universal capacity guarantees. Confirm the exact model revision, runtime version, topology, and current hardware availability before provisioning.

For most individual developers and small teams, three routes are more realistic:

1. Use the official Kimi API.
2. Rent a smaller GPU to build the RAG, data, evaluation, and agent sandbox around the API.
3. Move to a multi-node private deployment only when privacy, control, or sustained volume justifies the cluster.

Kimi K3 is best described as an open-weight model, not as software with no restrictions. The license permits use, modification, deployment, fine-tuning, redistribution, and derivative works, but includes commercial conditions. For example, a Model-as-a-Service business above the stated 12-month, US$20 million revenue threshold must sign an additional agreement with Moonshot AI. Large commercial products may also have interface-labeling requirements. Read the full license before commercial deployment.

Plan the Infrastructure in Layers

The hard part is not only GPU count. A Kimi K3 project also needs high-speed interconnects, tensor/pipeline/expert parallel settings, cross-node weight distribution, million-token KV-cache and KDA-state management, interruption recovery, and the ability to add or release GPUs as the workload changes.

Start with validation GPUs

L40S or RTX PRO 6000 GPUs cannot host the complete Kimi K3, but they are useful for API integration, RAG and vector databases, embedding and reranking, OCR, agent tools and sandboxes, smaller open models, batch data cleaning, and evaluation harnesses. Stabilize code, data, and workflow before renting a large cluster.

Move to H100, H200, or B200 for cluster work

Use high-memory GPUs when the project reaches high-concurrency inference, large-scale data processing, fine-tuning, or multi-node validation. A cluster only works as one serving system when the GPUs share a suitable interconnect and are available in a compatible region. Do not treat dozens of cards scattered across unrelated locations as one model cluster.

Glows.ai provides on-demand access to GPU types including B200, H200, H100, RTX PRO 6000, A100, and L40S, subject to current inventory and checkout terms. Check the Glows.ai dashboard for the exact model, region, price, and availability when you create an instance.

Keep weights and environments persistent

Multi-terabyte weights and runtime dependencies are expensive to download repeatedly. Use Datadrive for persistent models, data, and code, and use a Snapshot for a configured environment. This is especially useful when a team is iterating on vLLM, SGLang, CUDA kernels, and multi-node settings. The multi-machine DeepSeek-R1 SGLang tutorial demonstrates the distributed workflow; the Kimi K3 hardware and cost guide covers the separate sizing decision.

Who Should Pay Attention to Kimi K3?

AI agent teams can use its tool use, web research, long-running execution, and desktop-operation capabilities to test more autonomous workflows.

Large-codebase teams can explore million-token context and long-horizon coding for cross-module refactoring, debugging, and repository understanding.

Research and consulting teams can combine document review, search, analysis, and report generation.

Enterprises considering private inference can evaluate the open weights, but must weigh cluster cost, runtime maturity, licensing, security, and data governance together.

Inference infrastructure researchers have a rich systems problem in KDA, sparse MoE, MXFP4, long-context state, and cross-node expert parallelism.

FAQ

Is Kimi K3 just a bigger chat model?

No. Its architecture and evaluations target long-running coding, knowledge work, multimodal input, and agent loops. Chat remains one interface, not the whole deployment model.

Does 104B active parameters mean it fits on a 104B-class GPU?

No. The full 2.8T weight set must still be stored and distributed. Active parameters describe per-token compute, not total checkpoint memory.

Can a 1M-token context be used at full concurrency?

Not automatically. Context length, KV-cache or KDA-state memory, prefill time, batch size, and network topology determine the practical limit. Measure with the workload you expect to serve.

Should a small team self-host Kimi K3?

Usually start with the API or a smaller verified open-weight model. Self-hosting makes sense when privacy, revision control, or sustained volume can justify multi-node operations and you have a tested recovery plan.

Related Guides

• How to run Kimi K3: hardware, cost, and availability
• How to choose a GPU and quantization level for an open model
• How to deploy vLLM as an OpenAI-compatible API on Glows.ai

Conclusion

Kimi K3's significance is not the 2.8T number by itself. It shows open-weight models moving into a more engineering-heavy phase: native vision, million-token workflows, tool and terminal use, and efficient execution across many GPUs and nodes.

For most readers, the official API is the simplest way to evaluate Kimi K3. For teams building private agents, enterprise knowledge systems, or high-concurrency inference, GPU clusters, persistent storage, and deployment tooling become the real project. On-demand GPU platforms such as Glows.ai let a team validate data pipelines and agent workflows on a smaller instance, then expand to H100, H200, or B200 capacity when the workload justifies it.