Kimi K3 Is Open. You Still Can't Run It.

Moonshot AI shipped the weights for Kimi K3 this weekend, a few hours ahead of its promised July 27 date. At 2.8 trillion parameters, it's the largest open-weight model ever released — the first open model in the 3T class — and by Moonshot's own evals it lands ahead of GPT-5.5 and Claude Opus 4.8 on most tests, behind Claude Fable 5 and sometimes GPT-5.6 Sol. Third-party trackers roughly agree: #2 on the Vals AI index, #3 on Artificial Analysis's Intelligence Index, and #1 on Frontend Code Arena at 1,679 points, edging out Fable 5's 1,631.

That's a genuinely new situation: near-frontier capability you can git clone. But the framing you'll see everywhere — "now you can self-host a frontier model" — deserves a harder look, because at this scale the word "open" has quietly changed meaning.

What Moonshot actually built

K3 is a mixture-of-experts model that activates 16 of 896 experts per token, roughly 50B active parameters out of 2.8T total. The architecture stacks two changes Moonshot has been telegraphing since the K2 line: Kimi Delta Attention and attention residuals, which the company credits (along with a "Stable LatentMoE" training framework) for a claimed 2.5× improvement in scaling efficiency over K2. Treat that number as vendor-reported — nobody outside Moonshot can audit a training run — but the trajectory is consistent with what K2 and the K2.5/K2.6/K2.7-Code releases already showed: Moonshot iterates fast and its evals have mostly held up under community scrutiny.

The rest of the spec sheet reads like a deliberate answer to the agentic-coding moment: a 1-million-token context aimed at repository-scale work, native tool calling and multi-step planning, and text/image/video input. This isn't a chat model with function calling bolted on; it's built for the harness-driven workflows that Claude Code and its clones have made the default way serious developers consume LLMs.

The 1.4-terabyte asterisk

Here's where the self-hosting dream meets a memory wall. The weights ship in MXFP4, a four-bit format that runs natively on NVIDIA Blackwell and AMD MI400-class hardware. Even at four bits, that's about 1.4TB of weights — roughly 5.6TB if you materialized them in FP16. Loading the model takes on the order of eighteen 80GB accelerators, or one node of current-generation 192GB parts. On a 10-gigabit line, the download alone is a twenty-minute commitment; on your home connection, plan your evening around it.

The MoE math makes inference compute surprisingly cheap — 50B active parameters is mid-size-model territory per token — but every one of the 2.8 trillion has to sit in memory waiting to be routed to. The binding constraint is capacity and bandwidth, not FLOPs. There is no quantization trick coming that gets this onto a workstation; four-bit is already the shipped format. The r/LocalLLaMA crowd, which could at least limp through K2's 1T parameters on exotic home rigs, gets nothing directly runnable here.

So who actually deploys K3? Inference providers, clouds with Blackwell fleets, and enterprises that already operate multi-node GPU infrastructure. For everyone else, "open" means something different — and still valuable.

What open buys when you can't run it

First, provider competition. K2 taught this lesson: within days of its release, half a dozen hosts were serving it below Moonshot's own API pricing, and the model's terms weren't hostage to one vendor's rate limits or deprecation schedule. K3 resets that dynamic at near-frontier quality. If your objection to Moonshot is sending data to a Chinese API — a real compliance blocker for plenty of shops — a US or EU inference provider running the open weights dissolves it in a way no DPA ever could.

Second, derivative rights. A 2.8T teacher model with open weights is a distillation feedstock, and the interesting downstream releases over the next six months will be K3-distilled models that do fit on a workstation. Fine-tuning the full model is a multi-node adventure few will attempt, but LoRA-style adaptation through hosting providers, and distillation into 30–70B students, is where most developers will actually touch these weights.

Third, permanence. Whatever Moonshot does next — pivots, gets acquired, gets export-controlled — these weights exist. That's the strategic point Nathan Lambert has been making about the open-weights escalation: releases like this are economically corrosive to closed frontier pricing while accelerating diffusion everywhere else. Every closed lab's mid-tier model now competes with a free near-frontier alternative.

One flashing caveat before you ship anything: as of this writing, the license terms aren't confirmed. K2 used a modified MIT license with an attribution clause that kicked in above 100M monthly users or $20M monthly revenue — mild, but not vanilla MIT. Don't tell your legal team "it's MIT" until you've read the actual LICENSE file in the repo.

The honest scorecard

Is this a genuine shift? Yes — with a precise scope. K3 is the first time the open-weights ceiling has touched the frontier's floor, and it moves the credible open baseline from "a generation behind" to "months behind, sometimes ahead on coding." That's not hype; the third-party numbers back it.

But it also marks the end of the era when open weights implied edge deployment. The winners are inference providers (new near-frontier inventory with no per-token royalty), enterprises with data-residency constraints, and anyone downstream of the distillation pipeline. The losers are closed labs' pricing power below the absolute frontier — and, a little, the local-first crowd, for whom "open" increasingly means "open to whoever owns a Blackwell node." If you're deciding what to do Monday morning: don't provision hardware. Benchmark K3 through a hosted provider against whatever you're paying for now, on your own agentic workloads, and watch the repo for that LICENSE file. The model's real impact will be priced into your inference bill within the quarter.