Kimi K3 — What's Different About the 2.8T Open-Weight Frontier Model

"How could open source ever catch up to commercial frontier models?" — that line just got harder to say again. Kimi K3, released by Moonshot AI in July 2026, is a 2.8-trillion-parameter (2.8T) open-weight model — the largest open-weight model shipped to date. On independent evaluation it lands fourth among frontier models, trailing only Claude Fable 5 and GPT-5.6 Sol while edging past Opus 4.8. And crucially, its weights are open. "The intelligence that used to live only behind a commercial API can now run on our own infrastructure" — that carries real weight for a data platform.

What you'll learn

• Kimi K3's positioning and specs — why it's a big deal and when to consider it
• Why MoE (16/896), Kimi Delta Attention, and Attention Residuals matter
• API differences — always-on thinking, effort tiers, multimodal input
• The reality of self-hosting 2.8T — VRAM, quantization, serving cost
• When to use it (and when not to) for agent and data workloads

⚠️ The specs, pricing, and benchmarks below reflect Moonshot's public announcements, and this space moves very fast. Reconfirm the latest values against official docs before adopting. New to the terms? See the AI glossary; for open models broadly, see the 2026 AI model landscape.

1. Overview and Positioning

Kimi K3 is Moonshot AI's flagship, aimed at long-horizon coding and agent workloads. The core specs first:

• Parameters: 2.8 trillion (2.8T), Mixture-of-Experts (MoE)
• Active experts: 16 of 896 per token (only ~1.8% active)
• Context window: 1M tokens
• Multimodal: native visual understanding built in
• Reasoning: always-on thinking (reasons by default, no separate reasoning variant)
• Pricing (API): $3 input / $15 output (per 1M tokens)
• Release: announced 2026-07-16, open weights expected 2026-07-27

There's a point that's easy to miss here: 2.8T is the total parameter count, and only a small fraction actually runs per token. Being MoE, just 16 of 896 experts fire for each token. So the intelligence ceiling is at the 2.8T tier, but the inference compute (FLOPs) is far smaller — measured against the active parameters. This distinction is the crux of the "so how many GPUs do I actually need" question we'll get to later.

In one sentence: Kimi K3 aims to deliver commercial-frontier-grade intelligence and be self-hostable open weights at the same time.

2. Lineup and Competitors

Placing it alongside the other trillion-scale open MoE models and the closed frontier makes its position clear.

Check each vendor's official announcement for the exact parameters and pricing of DeepSeek V4 Pro and GLM-5.2. The table above is meant to show the context: several options now exist in the same "open trillion-scale MoE" weight class.

Kimi K3 comes in two variants:

• K3 Max — for general chat/agent and tool-use workloads.
• K3 Swarm Max — optimized for large-scale parallel processing. Aimed at high-concurrency work like batch and bulk pipelines.

3. What's Architecturally Different

Kimi K3 isn't "just a bigger MoE" because of two structural innovations. Let's look at each through the lens of which practical problem it solves.

Kimi Delta Attention (KDA) — long context, cheaply

Standard attention makes decoding (token generation) cost balloon as context grows — especially painful when you've loaded 1M tokens and are pulling out an answer. KDA is a hybrid linear attention that eases this; per Moonshot, it delivers ~6.3× faster decoding at 1M context. "Supports 1M context" and "is actually usable at 1M context" are two different claims — KDA targets the latter.

Attention Residuals (AttnRes) — training efficiency

Attention Residuals add residual connections along the attention path; in Moonshot's framing, this lifts training efficiency by ~25% at ~2% additional compute. We rarely train these ourselves, but it feeds into the output quality of "a better-trained 2.8T for the same budget."

Stable LatentMoE — 16/896 routing

As noted, each token selects only 16 of 896 experts via quantile-based routing. With just ~1.8% active, the per-token compute is far lighter even though the total is 2.8T. Memory pressure (you must load all the weights) and compute pressure (only the active ones run) are decoupled — that's the defining trait of MoE serving.

4. API Behavior for Developers

The first wall you hit porting existing chat code isn't intelligence — it's the request/response contract.

Thinking is always on

Kimi K3 has no separate "reasoning model." Instead, thinking is on by default: it reasons through the problem before answering. You control reasoning depth via documented effort tiers (e.g., standard, high) — you tune "how deeply to think" as a parameter. Deeper reasoning raises quality but also output tokens (= cost) and latency, so matching the tier to the workload is an operational lever.

# Conceptual example — control reasoning depth via effort tier
# (Confirm the actual SDK/parameter names against the Kimi platform docs)
client.chat.completions.create(
    model="kimi-k3-max",
    messages=[...],
    extra_body={"reasoning_effort": "high"},  # standard | high ...
)

Multimodal input

Visual understanding is native, so you can feed images (charts, screenshots, document scans) alongside text. In a data-platform context, that opens the door to pipelines like dashboard-capture interpretation or document-scan extraction.

Re-estimate cost

A model that reasons by default produces noticeably more output tokens. Thinking tokens are billed as output, so don't reuse the max_tokens and monthly-cost estimates from a non-reasoning model — re-measure per effort tier.

5. What It Means to Self-Host 2.8T

This is the part that matters most for Data Dynamics readers. "Open weights" sounds great, but actually loading 2.8T of weights is no small thing.

The core formula is the same one from our small-LLM sizing post:

Weight VRAM ≈ parameter count × precision (bytes). FP16 is ~2GB per 1B, 8-bit ~1GB, 4-bit ~0.5GB.

Applying it to 2.8T makes the scale real:

In other words, this is not a model you run on a workstation or a GPU or two. Kimi K3 is being discussed in an MXFP4-quantized form aimed at community serving, but even at 4-bit the weights alone are well over 1TB — plus the KV cache for 1M context on top. The saving grace is MoE: the compute is measured against active parameters, so "memory is large but per-token compute is relatively light" is what makes serving feasible at all.

Realistically the choice splits like this:

• Just use the API — at $3/$15, it's dramatically cheaper and simpler than self-serving for most teams. Even for open weights, the default remains the managed API.
• Self-host — justified for regulated/air-gapped environments where data must never leave, or at inference volumes so large that API cost exceeds your own infrastructure. That presupposes a multi-node GPU cluster + quantization + a tensor/expert-parallel serving stack (vLLM-class).

In one sentence: "the weights are open" ≠ "we can easily run it." Even as open weights, 2.8T has a high serving bar.

6. Fit for Agent and Data Workloads

So where does it actually fit well?

• Long-horizon agents — 1M context + KDA's long-context efficiency + always-on reasoning suit multi-step tool use and planning. Think large-codebase exploration or multi-stage data-pipeline orchestration.
• Large-scale parallel batch — the K3 Swarm Max variant targets high-concurrency bulk processing, a fit for batch jobs like classifying/extracting from tens of thousands of documents.
• Multimodal extraction — pipelines mixing document images and charts.

The reconsider cases are just as clear:

• For simple, high-volume, low-latency work (classification, short summaries), always-on reasoning is overkill. A smaller, faster model wins on both cost and latency.
• For paths needing real-time (tens of ms) responses, reasoning latency can be a burden.
• "It's open weights, so self-host everything" is, as Section 5 showed, irrational for most teams.

7. Wrap-up — How to Decide

Kimi K3's significance is less in any single spec and more in the trend it marks: frontier-grade intelligence has come down to open weights. The decision criteria, summarized:

The question is always the same: do we really need this intelligence, does it fit our infrastructure (or budget), and what is it for? Kimi K3 widens the menu by one more option — and, notably, an open-weight one.

For the broader context, continue with the 2026 AI model landscape and the open-source LLM comparison. If you're evaluating an on-prem LLM rollout, get in touch.

Glossary

The terms used in this post, in one place. For broader AI terminology, see the AI glossary.