All posts

Kimi K3: 2.8 Trillion Open Parameters and What the Weight Release Actually Changes

Moonshot AI released Kimi K3 on July 16. It's a 2.8-trillion-parameter mixture-of-experts model with native image input, a 1-million-token context win…

A dark honeycomb lattice with 16 cells glowing amber against a charcoal background, representing sparse expert activation

Moonshot AI released Kimi K3 on July 16. It's a 2.8-trillion-parameter mixture-of-experts model with native image input, a 1-million-token context window, and benchmark numbers that sit just below Claude Fable 5 and GPT-5.6 Sol on real-world agentic tasks. Open weights land July 27. That combination is worth paying attention to.

What the Architecture Actually Is

Kimi K3 is a sparse MoE. Of its 896 total experts, 16 are active per token, routed through what Moonshot calls the Stable LatentMoE framework. That sparsity is what makes 2.8T parameters economically viable at inference: you're not running all 2.8T on every forward pass.

Two architectural changes distinguish it from K2. Kimi Delta Attention (KDA) replaces standard full attention with a hybrid linear attention mechanism designed for long-context at scale. Attention Residuals swap the standard residual connection for a depth-spanning retrieval mechanism that the company says delivers consistent scaling gains. Together, Moonshot claims 2.5x overall scaling efficiency over K2.

I haven't independently reproduced the efficiency number. But the benchmark jump from K2 to K3 is large enough that something real happened in training, even if the 2.5x is marketing-rounded. The technical blog walks through the architecture claims in more detail.

Where the Benchmarks Land

Moonshot published these numbers at launch:

  • GPQA Diamond: 93.5 (roughly matching GPT-5.5; Claude Fable 5 Max sits above)
  • Terminal-Bench 2.1: 88.3 (coding agents specifically)
  • BrowseComp: 91.2 (highest published score on this benchmark at release)
  • HLE with tools: 56.0
  • HLE full set, no tools: 43.5
  • MCP Atlas: 84.2
  • GDPval-AA v2: 1,687 (third overall, behind Claude Fable 5 Max at 1,815 and GPT-5.6 Sol Max at 1,747.8, above Claude Opus 4.8 at 1,600)

GDPval-AA measures real-world tasks across 44 occupations and 9 industries. Third place among all frontier models is a real result.

The HLE no-tools score is the honest number to watch: at 43.5 it lags behind closed frontier models noticeably. The with-tools score (56.0) closes the gap. That pattern tells you something useful: K3 was trained to perform in agentic contexts where it has affordances, not to ace pure reasoning tests. That's actually a reasonable design choice if you're targeting coding and long-horizon agents.

These are all self-reported Moonshot numbers benchmarked on the KimiCode harness. Independent community evaluations start once the weights drop.

The API Pricing Right Now

The hosted API is live today. Rates: $3/M for uncached input, $0.30/M for cache hits, $15/M for output.

That output price is roughly in line with Claude Sonnet 5 and below Claude Fable 5 Max. For agentic workloads with long multi-step chains, the $0.30 cache hit rate is what actually determines your cost at scale. If you're generating more than you're reading, $15/M output will dominate your bill quickly.

Compare: GPT-5.6 Sol Max comes in around $20-30/M output depending on tier. If K3 holds up in production, there's a real cost arbitrage here for teams that care about agentic capability per dollar.

The Open Weights Story

This is what makes July 27 a meaningful date. When Moonshot drops the weights to Hugging Face, K3 becomes the largest open-weight model ever released.

The catch is infrastructure. At roughly 1.6 bits per parameter compressed, you need multi-petabyte distributed inference. This isn't a desktop deployment. You need a serious H100 or MI300X cluster, the kind of hardware most startups don't own. Inference serving a 2.8T MoE with 16 active experts per token is a distributed systems problem, not an ML one.

That said, the economics shift at high volume. If you're a company running tens of millions of API calls a month against a frontier model at $15-20/M output, a self-hosted K3 starts looking like a plausible cost optimization, especially if you have the team to manage the infrastructure.

The three contexts where open weights at frontier quality actually change things:

Regulated industries. Healthcare, finance, legal: anywhere you can't send data to a third-party API by policy. K3 is the first open-weight model that makes that a realistic option for agentic workloads rather than a significant quality tradeoff.

Latency control. Running your own inference means controlling batching, context caching, and speculative decoding. You don't get that with an API call.

Fine-tuning headroom. This is the most speculative benefit. Fine-tuning a 2.8T MoE is prohibitively expensive for most teams. But the option exists for the largest players in a way it didn't before K3.

What I'm Actually Watching

The trajectory of the Kimi lineup, from K1 through K2 to K3, has been a consistent upward curve. K3 is the first point on that curve that touches the frontier tier. That's the real change: the open-weight ceiling just moved up.

I haven't run K3 against production workloads. The weights aren't out yet. What I'll be watching when they drop: whether community evals confirm the BrowseComp and Terminal-Bench scores, what serving frameworks emerge for running 2.8T MoE at reasonable latency, and whether fine-tuning recipes emerge that make targeted adaptation feasible at smaller budget.

If the weight release lands on schedule and the scores hold up under independent testing, this becomes the default choice for any team running frontier-quality agents in a regulated environment. That's a specific use case, not a universal one. But it's real.