Kimi K3 is a bigger Kimi, and a structurally different one. Moonshot’s announcement describes a 2.8 trillion-parameter model with native vision, a 1-million-token context window, and a sparse architecture that routes each token through 16 of 896 experts.Moonshot’s K3 launch material The same post says the full weights will arrive by July 27, 2026. Those details make the release simultaneously important and easy to misread: K3 advances the open-model frontier, but it is not a model most teams will download onto an eight-GPU server next week.
The practical launch story is the gap between model scale and usable compute. Moonshot has published enough architecture and pricing detail to evaluate the hosted API today. It has not yet delivered the full weights, technical report, or reference serving implementation needed to validate self-hosted performance. Moonshot calls K3 an open 3T-class model,Moonshot’s K3 launch material but the release is happening in two stages: hosted access now, inspectable weights later.
What exactly shipped at launch?
Kimi K3 became available through Kimi.com, Kimi Work, Kimi Code, and the Kimi API, according to Moonshot’s launch post.Moonshot’s K3 launch material The API exposes a K3 model endpoint. Moonshot prices it at $3 per million input tokens and $15 per million output tokens,Artificial Analysis with cached input discounted 90 percent to $0.30 per million tokens.Artificial Analysis At those rates, output generation is the dominant metered cost, which makes verbosity and retry behavior part of the routing decision. The Kimi Code release notes also document K3 support, a 1-million-token context tier for eligible memberships, and low, high, and max effort settings.Kimi Code documentation
The downloadable release is not complete yet. Moonshot says the full model weights and additional technical details will be released by July 27, 2026.Moonshot’s K3 launch material As of July 20, there is no public weight package to inspect, no final license text attached to that package, and no reproducible community serving result. Calling K3 open is a statement about the announced distribution model. Calling it self-hostable today would skip a material step in the release.
That timing explains an apparent disagreement across sources. Moonshot’s product documentation says K3 is released and open-sourced, while Artificial Analysis notes that Moonshot has not yet released the weights.Artificial Analysis Both descriptions map to a different point in the rollout. The API exists; the promised weights do not yet.
How can a 2.8T model activate only 16 experts?
K3 is a Mixture of Experts model. Instead of running every parameter for every token, a router selects a small subset of specialized feed-forward networks. Moonshot says K3 uses 896 experts and effectively activates 16 for each tokenMoonshot’s K3 launch material through its Stable LatentMoE design. That is about 1.8 percent of the expert pool by count, although it is not the same as saying 1.8 percent of all 2.8 trillion parameters are active. Shared layers, attention blocks, embeddings, routers, and the size of each expert all affect the real active-parameter total, which Moonshot has not published.
The scale is unusual even against other prominent MoE releases. K3’s 2.8 trillion total makes the serving problem materially different from a conventional single-node model and leaves little room to assume that an existing deployment recipe will transfer unchanged.
The distinction matters for both speed and memory. Sparse routing reduces compute per generated token because most experts stay idle for that token. It does not remove the need to store the full expert set somewhere in the serving cluster. A dense model’s compute and storage scale together. A highly sparse MoE breaks that relationship: compute can be relatively economical while weight storage and cross-device communication remain enormous.
K3 therefore asks the infrastructure to solve a routing problem at unusual scale. Tokens in one batch may select different experts on different accelerators. Activations have to move to the devices holding those experts, be processed, and return before the next layer advances. The more experts and devices involved, the more network topology becomes part of model performance. A server can have enough aggregate VRAM and still perform poorly if its accelerator interconnect cannot sustain the all-to-all traffic.
Avoiding hot experts and idle devices is a first-order serving requirement at this granularity. The launch materials describe training-side changes aimed at balancing expert utilization, but those are vendor descriptions, not yet independently reproduced results.
What do KDA and Attention Residuals change?
Kimi Delta Attention, or KDA, targets the cost of moving through a long sequence. Attention Residuals, or AttnRes, target information flow through model depth. Moonshot frames the two as improving how information flows across sequence length and model depth.Moonshot’s K3 launch material K3 combines them with Gated Multi-head Latent Attention and claims about 2.5 times better overall scaling efficiency than Kimi K2.Moonshot’s K3 launch material
That 2.5 times figure is a vendor-reported scaling result, not a claim that K3 produces tokens 2.5 times faster or costs 60 percent less. Scaling efficiency describes how effectively additional training compute turns into model capability under Moonshot’s recipe. Online serving depends on a different collection of variables: accelerator memory, interconnect bandwidth, batching, prefix reuse, prefill length, decode length, and the implementation quality of the new attention kernels.
The architecture’s serving case depends on implementation quality, not only the research design. AttnRes, KDA, and MLA need optimized kernels, stable batching behavior, and predictable memory use before a self-hosted stack can be compared fairly with the hosted endpoint. Until code and weights ship, those are evaluation questions rather than measured production properties.
The Kimi Code docs warn that switching to K3 invalidates the existing context cacheKimi Code documentation and recommend starting a new session. Until the weights and a reference serving implementation ship, teams cannot verify how the new attention path interacts with prefix caching on their own hardware.
This is why the architecture story is more useful than the parameter headline. K3 is betting that sparse experts lower per-token compute and KDA lowers long-context attention cost. If both hold, a 2.8T model can be commercially served. If the cache or interconnect underperforms, the total parameter count becomes an expensive storage and communication burden.
What does 2.8T imply for self-hosting?
Moonshot has not yet published a reference serving configuration for K3. The package arriving July 27 will have to specify device count, per-device memory, and quantization. The parameter count alone sets the order of magnitude.
A rough lower-bound calculation shows why. At four bits per weight, 2.8 trillion weights occupy about 1.4 terabytes before metadata, scaling factors, shared buffers, runtime workspace, and KV cache. That is multiple high-bandwidth-memory devices worth of storage before any concurrency budget, and real placement is never perfect. The calculation is illustrative because the final package may store different components at different precisions, but it makes one point clear: this is not a workstation-class workload.
Memory capacity is only the first gate. A cluster connected as separate low-bandwidth islands may be cheaper to rent but slower than a smaller number of tightly connected nodes. Expert parallelism turns fabric bandwidth and collective-communication latency into parts of token latency.
For most organizations, that moves K3 self-hosting out of the conventional local-LLM category. It belongs in the same procurement conversation as a shared inference cluster, not a workstation. Even if quantization eventually fits the weights across commodity cards, acceptable throughput and reliability may still require datacenter interconnects, replicas, observability, and an engineer responsible for the pager.
The 1-million-token window raises the serving bar again. Context capacity is shared across concurrent sessions through the KV cache, so a cluster that handles one maximum-length request may support far fewer simultaneous coding agents than its raw token throughput implies. Prefill latency also grows with the material actually sent, even when the architecture makes that growth more efficient. A pilot should sweep context length and concurrency together: 32K, 128K, 256K, and 1M tokens at one, four, and eight parallel sessions reveal much more than a single maximum-context success. Most teams will get better economics from retrieval and disciplined context assembly than from sending an entire repository on every turn.
A deployment gate for the weight release
Treat the hosted API and the downloadable package as separate candidates. Freeze the same task set, acceptance rubric, context sizes, and concurrency levels before the files arrive. Run the API first to establish output quality and task completion. Then run the self-hosted package without changing the harness. That sequence prevents infrastructure tuning from being mistaken for a model-quality difference.
The self-hosted gate should record more than tokens per second. Track time to first token, steady-state decode speed, batch behavior, failed requests, memory headroom, and the effect of long prefills. Repeat the sweep at the context lengths and concurrency levels the production route will actually see. A configuration that wins a single-request benchmark can still lose once several coding agents compete for memory and interconnect bandwidth.
vLLM’s official parallelism guide describes combining data parallel attention with expert or tensor parallel MoE layers for large-scale serving. That documentation does not establish that K3 works in vLLM today. It does identify the evidence a credible K3 serving recipe must supply: supported kernels, an explicit parallel layout, communication requirements, and results that separate prefill-heavy from decode-heavy workloads. Until those details are reproducible, procurement should remain conditional rather than treating the announced weight date as deployment readiness.
Does the independent evidence support the launch claims?
Independent results support K3’s frontier placement without validating every vendor case study. Artificial Analysis scores Kimi K3 at 57Artificial Analysis on its Intelligence Index, behind Claude Fable 5 and GPT-5.6 Sol but ahead of the current open-weight field. It prices the endpoint at the same $3 input and $15 output rates Moonshot publishes.Artificial Analysis Artificial Analysis also reports that K3 used approximately 132 million output tokensArtificial Analysis to complete its nine Intelligence Index evaluations, about 21 percent fewer than the roughly 166 million K2.6 required.Artificial Analysis Token efficiency improved even as capability rose.
The detailed Artificial Analysis report is most useful because it shows that K3’s aggregate result is not uniform across tasks. Its strong agentic-knowledge-work showing is consistent with Moonshot’s long-horizon positioning, but it does not establish universal superiority.
Moonshot’s own benchmark table needs similar care. The cached launch materials describe head-to-head agent evaluations but do not publish the full per-task harness and hardware disclosures needed to call the comparison architecture-neutral. Treat the table as positioning evidence, not a controlled study.
When does the hosted API make more sense?
The hosted API is the rational default until the weights and serving stack can be measured. At Moonshot’s list price,Artificial Analysis a workload with one million uncached input tokens and one million output tokens costs $18.Artificial Analysis If all input qualifies for the cache-hit rate, the same token counts cost $15.30.Artificial Analysis Output dominates in either case, so prompt caching does not rescue an agent that reasons verbosely and generates long traces.
Teams should record cache-hit input, cache-miss input, output tokens, completed tasks, and retries for each model. The same pilot should report cost per accepted task after retries, tool failures, and human rework. That local number is more useful than importing a vendor or benchmark estimate because it reflects the team’s own acceptance threshold and workload mix.
The pilot should also separate prefill-heavy and output-heavy tasks. Repository onboarding, large-document analysis, and repeated agent sessions stress cache behavior, while code generation and long research reports expose output cost and latency. A blended monthly average can hide a route that is economical for one workload and wasteful for another. Keeping those cohorts separate makes the eventual API-versus-self-hosted comparison actionable instead of reducing it to one misleading token total.
Hosted access also avoids four unknowns that matter before self-hosting: the final license, the exact weight formats, stable vLLM support, and throughput on available hardware. A July 27 weight drop can resolve the first three quickly. Throughput will take longer because early benchmark posts often optimize for one prompt length, batch size, or accelerator type. Production agents mix huge prefills, short tool calls, long reasoning traces, and bursty concurrency.
The case for waiting is not an argument against open weights. It is the value of open weights used correctly. Once files are public, teams can audit them, benchmark their own tasks, select a quantization, and compare rented clusters with the API. Before the files exist, a hardware plan is only a projection.
What are the operational limitations?
Moonshot’s launch materials are direct about the headline gap: K3’s overall performance still trails Claude Fable 5 and GPT 5.6 Sol.Moonshot’s K3 launch material K3 is a frontier agent model with unusually ambitious open distribution, not a clean replacement for every closed API.
The launch post also notes K3 ships with maximum thinking effort on by default,Moonshot’s K3 launch material with low- and high-effort modes arriving in later updates. The Kimi Code docs add that switching to K3 mid-session invalidates the existing context cacheKimi Code documentation and recommend starting a fresh session. Treat model and effort selection as a quality decision, not a runtime toggle. A harness that swaps models or drops earlier reasoning content mid-task should expect friction.
K3 takes native multimodal input across text and images and produces text-only output.Artificial Analysis That covers screenshot-driven debugging, frontend and game-dev iteration, and CAD work, which is where Moonshot’s case studies concentrate,Moonshot’s K3 launch material but teams needing image generation still need a separate model.
Systems using write tools, cloud credentials, or production consoles should pair any frontier agent, K3 included, with explicit boundaries, approval gates, scoped credentials, and reversible operations. A team may prefer K3 for long knowledge-work runs and still route concise user-facing interactions elsewhere.
The launch changes the open-model ceiling, but the decisive deployment evidence arrives after the headline. K3’s sparse architecture explains how Moonshot can serve 2.8 trillion parameters at a competitive token price. It does not make 2.8 trillion parameters small. Until the full release proves otherwise, the API is a product and self-hosting is a research project.
Frequently Asked Questions
How does K3’s 2.8T parameter count compare to GPT-5.6 Sol’s architecture?
GPT-5.6 Sol is a dense transformer model with approximately 1.8 trillion total parameters. K3’s 2.8 trillion parameters are distributed across a sparse Mixture of Experts architecture, meaning K3 activates only a fraction of its weights per token while GPT-5.6 Sol activates all 1.8 trillion parameters for every single token.
What is the minimum GPU cluster size required to self-host K3?
Moonshot has not published the final weight formats or precision requirements, making a definitive cluster size impossible to calculate. However, a rough lower-bound estimate suggests that at four bits per weight, the 2.8 trillion parameters would occupy approximately 1.4 terabytes of VRAM, requiring multiple high-bandwidth-memory devices just to store the model before accounting for concurrency or KV cache overhead.
Does K3 support image generation for visual outputs?
No. K3 accepts native multimodal input across text and images but produces text-only output. Teams requiring image generation capabilities must integrate a separate diffusion or autoregressive image model into their workflow, as K3 cannot synthesize visual media.
How does K3’s token efficiency compare to Kimi K2.6?
K3 demonstrated improved token efficiency over its predecessor. Artificial Analysis reported that K3 used approximately 132 million output tokens to complete its nine Intelligence Index evaluations, which is about 21 percent fewer than the roughly 166 million tokens K2.6 required to complete the same tasks.
