Kimi K3’s open weights arrive July 27. The catch is 1.4TB

Article Brief

Key Takeaways

5 Points30s Read

1. 01Open date set–Moonshot AI plans to publish Kimi K3’s full 2.8-trillion-parameter weights by July 27, 2026; the model has served its API since July 16.
2. 02Sparse by design–Only 16 of 896 experts fire per token — about 50 billion active parameters — so per-token compute resembles a mid-size model, not a 2.8T one.
3. 031.4 TB is the real gate–In MXFP4 four-bit precision the weights still need roughly 1.4 terabytes of fast memory, versus about 5.6 TB at 16-bit, before any context loads.
4. 04Open is not local–At this size the practical operators are clouds and inference providers on Blackwell or MI400 silicon, not workstations.
5. 05License still unwritten–Commercial usability stays unconfirmed until Moonshot publishes the license alongside the weights.

Moonshot AI has finally put a date on the part of Kimi K3 that the rest of the industry has been waiting for. The model has been answering API calls since July 16. The weights — all 2.8 trillion parameters of them — are scheduled to go public by July 27, which would make Kimi K3 the largest open-weight model anyone has shipped. That headline more or less writes itself. The invoice underneath it is the harder thing to read, and it is where the release actually lands for anyone deciding what to build on.

A trillion-parameter label on a fifty-billion-parameter engine

Start with the number everyone is repeating, because it is quietly doing two jobs at once. Kimi K3 is a 2.8-trillion-parameter model, but it is a mixture-of-experts design that activates only 16 of its 896 experts on any given token — roughly 50 billion parameters of live compute per step. The trillions describe how much the model can hold, not how much arithmetic it does to answer you.

Moonshot pairs that routing with an attention scheme it calls Kimi Delta Attention, a hybrid linear-attention mechanism, alongside what the company labels Attention Residuals. The plumbing is less important than what it produces: per-token cost behaves closer to a well-run mid-size dense model, while capacity behaves like something an order of magnitude larger. The company also claims a roughly 2.5-times improvement in scaling efficiency over Kimi K2, its previous flagship. Keep the capacity number and the compute number separate, and most of the noise around this release settles down. Conflate them — which the “2.8 trillion” framing invites — and you will badly misjudge both what it costs to serve and what it can do.

The spec that decides everything is 1.4 terabytes

The numbers that will actually determine who runs Kimi K3 are not on the benchmark card. The full model needs about 1.4 terabytes of storage for its weights, and it reaches that figure only because Moonshot ships them in MXFP4 — a four-bit floating-point format with per-block scaling factors. In sixteen-bit precision the same weights would run to roughly 5.6 terabytes. So 1.4 terabytes is the compressed number, not the raw one. It still has to sit in fast memory before the model reads a single token of a prompt, and the one-million-token context window pushes the memory bill up from there.

MXFP4 is not a neutral packaging choice. It runs natively on Nvidia’s Blackwell generation and AMD’s MI400 accelerators, which sets a quiet floor under what hardware makes these open weights worth having. Do the rough arithmetic and the problem takes shape quickly. Holding 1.4 terabytes of weights implies something on the order of eighteen 80-gigabyte accelerators just to load the model, before reserving anything for context or serving more than one request at a time. A single node of the newest silicon — eight cards at 192 gigabytes each, about 1.5 terabytes — can barely fit the weights with almost nothing to spare.

That is why the mixture-of-experts design matters commercially and not just academically. Once the model is resident, it is comparatively cheap to run per token, because only about 50 billion parameters fire on each step. But it is expensive to host, because all 2.8 trillion have to stay loaded. The binding constraint is memory capacity and bandwidth, not floating-point throughput — the same inversion that keeps surfacing as the industry splits inference into memory-bound and compute-bound halves. It is also why the cost of frontier inference is now measured in tokens per megawatt rather than in raw chip counts. For Kimi K3, the megawatts go mostly toward keeping 1.4 terabytes warm.

Downloadable is not the same as runnable

This is where the word “open” needs a second reading. A license that lets you download weights is not the same as an operation you can stand up. The teams that benefit first from Kimi K3’s release are not solo developers pulling weights onto a workstation. That path — the one that made smaller open models genuinely portable, and that keeps improving as local runtimes get faster and leaner — simply does not reach a 1.4-terabyte model.

The teams that benefit are the ones already operating racks of Blackwell or MI400 silicon: inference providers, a handful of large enterprises, and the clouds. Open weights, in this size class, do not push capability out to the edge. They move it to whoever can afford to keep 1.4 terabytes loaded and busy. The license democratizes ownership on paper while the hardware recentralizes who can actually exercise it. That is not a criticism of Moonshot’s engineering, which is genuinely impressive. It is a caution about reading “open” as a synonym for “accessible,” when at this scale the two have quietly come apart.

What changes for a buyer choosing open over closed

For a company weighing an open model against a closed one, that distinction reorders the whole decision. The theoretical case for open weights is control: no per-token price set by a single vendor, no capability deprecated out from under a shipping product, the option to run the model inside your own security boundary. Kimi K3 supplies the weights that make that case possible, and it arrives with credible standing — third-party trackers this month placed it second on one intelligence index and behind only Claude Fable and GPT-5.6 Sol Max on another, with a first-place result in a frontend-coding arena. On capability, it is not a compromise pick.

The operational reality is narrower. Most buyers who “adopt” Kimi K3 will rent it — through Moonshot’s own pay-as-you-go API, or a cloud that hosts the weights for them — and inherit a version of the same provider dependency they were trying to leave behind, only with more suppliers to shop between. That is still worth something; portability across providers is real leverage, and it is exactly the leverage that middleware is now being built to standardize across model vendors. But renting an open model through someone else’s infrastructure is not the same as holding your own, and the two keep getting folded together in the pitch decks.

There is also a commercial caveat the countdown has not resolved. Moonshot has committed to releasing the weights, but the license terms have not been published, and by the company’s own framing they will land with the release itself. Until that text exists, no one can say cleanly whether Kimi K3 is usable in a commercial product, under what attribution, or with what limits on downstream training. “Open weights” has meant everything from a permissive MIT-style grant to a research-only license with commercial carve-outs, and that difference is the entire question for a business. Anyone slotting Kimi K3 into a roadmap this week is planning against a document that does not yet exist — which is a reason to prototype now and commit later, not the reverse.

Read it as an escalation, not a product launch

The release makes more sense as strategy than as a straightforward product drop. Putting the full weights of a frontier-class model into public hands, at a moment when the strongest American systems remain closed and metered, is a deliberate move in a widening contest over whether the most capable models are things you rent or things you hold. Publishing 2.8 trillion parameters is a way of forcing that question — of making “open” mean something at the very top of the capability curve, not only in the tier of models small enough to run on modest hardware.

It also raises the stakes for how buyers evaluate the growing field of platforms built on top of these models, because an open model at the frontier changes the negotiating position of every layer above it. Whether that pressure actually reshapes behavior depends less on the benchmark scores than on whether the surrounding economics line up: hardware a buyer can get, a license they can sign, and an inference bill they can defend to finance. Those are the parts July 27 begins to test, and none of them are settled by the parameter count.

What still has to be true by July 27

A few things should temper the enthusiasm until the weights are actually in the open. The date is a commitment, not a shipped artifact, and open-weight timelines have slipped before. The benchmark standings are third-party snapshots from a single month, and they will move as independent evaluations accumulate. The efficiency and active-parameter figures are Moonshot’s own until outside labs reproduce them on hardware the company does not control. And the line that will travel farthest — “largest open model ever” — measures parameter count, which is a capacity figure rather than a promise about output; on the indexes that try to measure quality, Kimi K3 currently sits third, not first.

The most useful number in the entire release is still the unglamorous one: 1.4 terabytes, resident, warm, and waiting. Whoever can afford to keep it that way is who “open” is really for. If Moonshot ships the weights on schedule and pairs them with a license a business can actually sign, that group gets meaningfully larger. If either piece slips, the largest open model ever will belong, in practice, to the same short list of operators that already run everything else at this scale.