What open weights actually get you

Every few months a lab publishes the weights for a model with a large number attached, and the number is always larger than the last one. Moonshot AI’s Kimi K3 card lists 2.8 trillion total parameters, 104 billion activated, 16 of 896 experts selected per token, and a context length of 1,048,576 tokens [3]. The reaction that follows is usually one of two things: “I should run this myself” or “this has nothing to do with me”. Both are wrong for the same reason. The parameter count is the least useful fact in the announcement.

This guide is for solo operators, freelancers and small teams who buy model access by the token and want to know whether a release like that one changes anything for them. It is not for anyone deciding whether to buy or rent hardware, which is a cost question with its own arithmetic. The short version is that the licence file matters more than the weights, the size number is a fact about hosting rather than about access, and the durable benefit of open weights for a small business has almost nothing to do with running anything yourself.

Open weights and open source are two different claims

The Open Source Initiative published version 1.0 of its Open Source AI Definition on 28 October 2024 [1]. It asks for four freedoms: use the system for any purpose and without having to ask for permission, study how the system works and inspect its components, modify it for any purpose including to change its output, and share it for others to use with or without modifications [1]. Exercising those freedoms, the definition says, requires three things. Data information, meaning sufficiently detailed information about the data used to train the system so that a skilled person can build a substantially equivalent system. The complete source code used to train and run the system. And the model parameters themselves [1].

A weights release delivers the third component. It makes no claim about the first two, and the definition treats all three as required [1]. That is why a separate phrase exists for what actually ships. “Open weights” describes the parameters plus a licence, it is genuinely useful, and it is a narrower claim than open source. The gap between the two claims is exactly where the licence lives.

Kimi K3’s repository makes the point without intending to. The weights are there, and the licence attached to them is not MIT and not Apache 2.0. It is a document called the Kimi K3 License, written by Moonshot for this model [2]. A licence a vendor wrote for one model is a licence you have to actually read.

The licence is short and it names your business

Start with what K3’s licence permits, because it is representative. The grant is MIT-shaped: permission to deal in the Software without restriction, where the licence defines Software as the model weights, parameters, configuration files, inference and training code, and associated documentation [2]. So the weights are inside the grant, not attached to it as an afterthought.

Then come the numbers. Model as a Service is defined as giving a third party access to language model inference or fine-tuning, for example via an API, in a manner that allows that third party to exercise meaningful control over the inputs, parameters, or training data [2]. The “meaningful control” qualifier is doing work: a finished product with the capability embedded in it is excluded, as is relaying requests to a third-party hosted model [2]. If you do run a Model as a Service business and aggregate revenue exceeds 20 million US dollars over any consecutive 12 months, you need a separate agreement with Moonshot before commercial use [2]. Separately, a product or service with more than 100 million monthly active users, or more than 20 million US dollars in monthly revenue, must display “Kimi K3” prominently on the user interface [2].

Then read the exemptions, because they are the part that decides your case. Those requirements do not apply to internal use, which the licence defines as any use that does not make the Software, its outputs, or its underlying capabilities available to third parties, and they do not apply to use reached through Moonshot’s official products or its certified inference partners [2]. For a two-person consultancy running the model behind its own work, that is a green light with paperwork attached to a future you probably will not have.

That is the normal outcome, and the ten minutes are still worth spending, because not every clause is a threshold. Google’s Gemma terms are the useful counter-example. Anyone distributing Gemma or a model derivative has to give recipients a copy of the whole agreement, include the use restrictions as an enforceable provision in any downstream agreement, cause modified files to carry prominent notices stating that you modified them, and include a notice saying that Gemma is provided under and subject to the Gemma Terms of Use [4]. And Google reserves the right to restrict, remotely or otherwise, usage of any of the Gemma Services that Google reasonably believes are in violation of the agreement [4]. Whatever “remotely” turns out to mean for a file already sitting on a disk, it is not a sentence that appears in Apache 2.0, which is the licence OpenAI used for its gpt-oss models [5].

The method is duller than the topic deserves. Open the LICENSE file itself rather than the one-word licence tag on the model page. Read the clauses that contain both a number and a verb. Thresholds tell you whether the licence is aimed at a company your size. Naming and attribution clauses tell you what has to appear in your product. Definitions tell you whether the thresholds point at you at all. The rest is boilerplate you have read before.

The size number tells you who can host it, not whether you can use it

A parameter count is a hosting fact. Hugging Face’s own guidance gives the arithmetic: loading the weights of a model with X billion parameters takes roughly 4 × X GB of memory in float32 and 2 × X GB in bfloat16 or float16 [7]. Quantisation moves that down. The same page measures a model of just over 15 billion parameters at 29.0 GB in bfloat16, 15.2 GB at 8-bit and 9.5 GB at 4-bit [7]. K3 is trained with MXFP4 weights and MXFP8 activations under quantisation-aware training [3], and four bits is half a byte, so 2.8 trillion weights come to roughly 1.4 terabytes just to hold the model, against about 5.6 terabytes at 16-bit. The key-value cache for a million-token context and the activations sit on top of that.

Now the other end of the same market. OpenAI’s gpt-oss-20b is 21 billion parameters with 3.6 billion active, published under Apache 2.0, and its model card says it runs within 16 GB of memory thanks to MXFP4 quantisation of the mixture-of-experts weights [5]. Sixteen gigabytes is a laptop with a decent graphics card, or a Mac with enough unified memory. Nothing about the phrase “open weights” distinguishes these two cases, and everything about your options does.

So treat the size number as an answer to a question you were not asking. It tells you which companies can serve the model. It tells you nothing about whether you can use it, because for anything at the top of the range you were always going to reach it the same way you reach a closed model: over an API, by the token.

What open weights buy you is suppliers, not hardware

The practical difference shows up in who is willing to sell you the model. OpenRouter lists 18 providers serving Kimi K3. The cheapest input price on that list is $2.50 per million tokens and the cheapest output price is $12.75 per million, the fastest tier charges $6.00 and $22.50, and Moonshot’s own API sits in the middle at $3.00 and $15.00 [6]. Together, Fireworks, DeepInfra, Baseten, Modal, DigitalOcean and Alibaba Cloud’s international arm all appear on that list, serving the same weights [6].

A closed model cannot do that. When one company owns the weights, there is one price, one queue, one set of terms, one privacy policy and one place for the service to fail. When the weights are published under a licence that permits hosting, the same model turns up behind a dozen billing relationships, and the most expensive entry charges more than twice as much per input token as the cheapest [6]. Moving between them is a configuration change rather than a migration, because the model on the other side is the same model.

It also changes what happens when a model is retired. Anthropic publishes the clearest version of the standard policy: models move through active, legacy, deprecated and retired states, customers with active deployments get at least 60 days’ notice before retirement, and requests to models past the retirement date fail [8]. That is a fair policy, honestly documented, and it is still a date on which a prompt you tuned stops working. Published weights have no retirement date. If every host drops the model, the file still exists and someone can serve it, subject to the licence you read earlier.

That is the whole benefit, and it is worth being unromantic about it. Open weights do not make a model cheaper by themselves, and they do not put a frontier model on your desk. They remove single-supplier risk from one part of your stack.

What to do in the week a large open model ships

Do nothing on the day. Until a provider is serving the weights, a model at the top of the size range is not something you can try, so the first signal worth watching is a hosted endpoint appearing on a provider listing [6]. That usually settles within days, and it converts the release from news into something you can price.

Then read the licence, which takes longer than it should only because finding the file takes longer than reading it. Then price the model against what you already pay, using your own monthly volume rather than the vendor’s example. Then run your own real inputs through it, on the provider you would actually use, and read the outputs next to what your current model produced for the same work. A model’s size, its benchmark table and its licence all tell you nothing about whether it is better at your job.

Last, write down the fallback. The reason to care about a model with 18 suppliers is that you can leave one of them in an afternoon. That is only true if you know which two you would move to and have checked that your prompts survive the move.

What still goes wrong

Open weights do not make training data open. Data information, meaning detail about the training data sufficient for a skilled person to build a substantially equivalent system, is the first of the three components the Open Source AI Definition asks for, and a weights release supplies the third [1]. That distinction matters the moment a client asks you to warrant where the material in your deliverable came from. Publishing the parameters lets you inspect the model’s behaviour. It does not let you audit what it learned from, and no amount of open-weight enthusiasm changes that.

Licences attach to models, not to vendors. K3 ships under a document written for K3 [2], and the next release from the same lab can arrive under different terms. A licence you cleared last year is not a licence you have cleared, and the check has to be repeated each time you adopt a new version. The same applies in the other direction: a vendor can publish under Apache 2.0 for one model [5] and terms like Gemma’s, which reserve a right to restrict usage remotely [4], for another.

And identical weights do not mean identical service. Eighteen providers list the same model at input prices that differ by more than double [6], and a price list does not tell you what quantisation, context limit, rate limit or data-retention policy each one applies. Those differences are real and they are yours to discover, which is why the last step is always your own inputs on the endpoint you intend to bill against, rather than a benchmark run by someone with a position in the answer.