Kimi K3's weights are live: why hosting them yourself matters more than the model

In our round-up two weeks ago we covered the Kimi K3 announcement: benchmarks published, the leaderboard shaken up, but weights not yet downloadable. As of today, July 27, 2026, that phase is over: Moonshot has published the full model weights on Hugging Face — around 594 GB in MXFP4 format — making Kimi K3 the largest open-weight release ever made publicly available. But the story that actually matters for a company deciding on an AI architecture isn't the parameter count: it's what changes, concretely, between using Moonshot's API and running those same weights on your own infrastructure.

The difference is no longer theoretical: it's downloadable today

As long as a model exists only as an API, the distinction between "where it was trained" and "where it runs" stays a consultant's talking point. As of today, with K3's weights publicly available, that distinction becomes an operational choice every company can actually make: download the model and run it on your own infrastructure, or on a Swiss sovereign cloud, instead of sending your prompts to a Chinese provider's servers.

Why self-hosting isn't a technical footnote

China's regulatory framework isn't ambiguous on this point: the 2017 National Intelligence Law requires every Chinese organization to cooperate with intelligence requests, and the Data Security Law (2021) and Cybersecurity Law (2017) add data localization obligations. These obligations fall on the company providing the service, not on the physical jurisdiction of its servers — which is why relying on a Chinese provider's API, regardless of where its datacenters are technically located, exposes you to a risk no contract fully removes. China's own National Cyber Security Information Centre had already flagged Kimi in 2025 for collecting data irrelevant to the service, and one documented case saw the chatbot disclose another user's full résumé — name, phone number, work history — to an unrelated user.

When you instead download the weights and run them on your own infrastructure, your prompts never leave your perimeter: that regulatory framework, however real, becomes irrelevant to your data flow, because there is no longer any Moonshot server in the path. It's exactly the distinction between a model's origin and where it runs that we wrote about in our previous round-up — except that today, for the first time on a model at this scale, it's a choice you can actually act on.

The license: same structure as K2, still worth reading line by line

K3 is expected to inherit the Modified MIT License already seen on K2.7 Code, with the attribution clause triggering above 100 million monthly active users or $20 million in monthly revenue — a threshold irrelevant to most companies. But the exact license text published alongside K3's weights should be read in full before adoption, not assumed identical to the previous release: labs change terms between versions more often than you'd expect.

One thing worth checking before production

Independent tests cited in the days before the release found a hallucination rate around 51% on some benchmarks — a figure that didn't appear in Moonshot's official charts. That's not a reason to rule the model out, but it is a reason to test it against your specific use case before any production adoption — especially on regulated content, where a hallucination isn't a nuisance but a compliance risk.

Meanwhile, Mistral takes the opposite route: all Apache 2.0

In the same week, Mistral AI confirmed that its entire Mistral 3 family — the 3B, 8B and 14B dense models plus the flagship Large 3 — ships under the Apache 2.0 license, with no user or revenue thresholds and no conditional attribution clauses. It's a European lab, with a compliance posture already closer to a Swiss company's, and a license that doesn't demand the same line-by-line scrutiny Kimi K3 requires. It doesn't compete at the same parameter scale, but for many use cases it's today the easier choice to justify in a compliance audit.

What to actually do if you're evaluating an open model today

• If you adopt Kimi K3, host it yourself — on your own infrastructure or a Swiss sovereign cloud — instead of using Moonshot's API: it's the only way to make the jurisdiction of whoever trained it irrelevant.
• Read the license file published alongside K3's weights; don't trust a summary based on the previous release — labs change terms more often than it seems.
• Test the hallucination rate against your specific use case before any production adoption, especially on regulated or customer-facing content.
• If a clean license with no thresholds to monitor over time is the priority, Mistral 3 (Apache 2.0) is today a serious alternative, even at a smaller parameter scale.

This is exactly the work we do every week with our clients: check the license before it becomes a problem, bring the weights inside your own perimeter instead of sending your data out, and build an architecture where the model runs where it should — regardless of who trained it, or where.