Own Your Weights: Sovereignty at the Model Layer

A model you call through someone else’s API is a capability you rent. A model whose checkpoint sits in your object storage is a capability you own. Everything downstream — pricing changes, deprecations, provider decisions, jurisdiction questions — lands differently on the two.

Ownership in the AI sense is simpler than in the software sense: there is no license key, no activation server. A checkpoint is a file, and whoever holds the file can serve it. The entire question is whether training runs end in a file that is yours, or in a table row in someone else’s account.

An endpoint is a promise with a renewal date. You can negotiate with it, monitor it, and migrate away from it — but the capability itself stays on the other side of the wire. Every integration you write deepens the dependency: the longer the endpoint has served you, the more expensive the exit.

A checkpoint is the capability itself. Serve it on a dedicated endpoint today, move it to your own infrastructure tomorrow, re-tune it next quarter — the asset follows you because you hold it. Endpoints solve today’s traffic; weights solve the next five years of it.

Fine-tuning is the practical door. The base models are open weights — public artifacts nobody can revoke — and the training run that adapts one to your domain produces a new artifact. Train on your data, on dedicated GPUs billed by the second, and the run ends in a file you can pick up.

That is the model layer of sovereignty secured by construction: open foundation below, your adaptation above, and no proprietary dependency holding either.

Concretely: the checkpoint, exported as files — portable, servable anywhere, on dedicated endpoints or entirely elsewhere. Not a service credit, not a hosted model you can call but never touch, not a weights download gated behind a renewed contract.

The platform treats the checkpoint as the customer’s property, and says so in the product copy rather than the fine print. Whatever vendor you train with, demand the same sentence — and treat any phrasing short of “the files are yours” as a no.

Fine-tuning is billed per second of GPU time — you pay for the run, not for a perpetual relationship. This post deliberately quotes no savings figure, because ownership is not a discount; it is a different kind of return. The arithmetic to care about is not price-per-run versus price-per-token, it is what a provider dependency costs the year you most want to leave.

And on this platform the answer is legible: dedicated GPUs by the second, published rates, a file at the end.

Ownership has carrying costs, and the honest case for renting is when you have not earned the right to train. If there is no evaluation harness — no way to tell whether a fine-tuned model beats a catalog model on your workload — then a training run is a bet without a scoreboard, and renting while you build the harness is the cheaper form of discipline.

Small workloads with shifting needs also rent well: a team calling a model a few million tokens a month, with no domain data worth absorbing, gets the frontier’s full capability for the price of a subscription, and should keep it.

When the data cannot support it. A model is only as owned as it is useful; a checkpoint trained on a few hundred sloppy examples is a liability with a file extension — it sits in storage, costs nothing, and gets deployed anyway by someone who forgot why it was made. Ownership without a dataset worth learning from is decoration.

When the organisation cannot operate a model. Serving, monitoring, versioning — the operational surface is real even when the vendor serves the checkpoint for you, and doubles if the plan is to serve it yourself. A team without the operational muscle to run what it trained has bought a capability it cannot use.

And when the failure mode is solved better by routing. If the workload’s actual problem is “pick the right model per request” rather than “teach a model our domain”, then ownership is the expensive solution to the wrong problem — a router is the answer, and a checkpoint is the bill for not noticing.

Three habits. First, hold the files yourself — the checkpoint in your storage is the ground truth of ownership, whatever the platform’s dashboard says. Second, keep the training data and the run configuration versioned, so the asset is reproducible, not just portable. Third, re-evaluate on your own harness every quarter — an owned model that drifts behind the catalog is a cost centre, and the fix is another run, which ownership makes possible.

None of this requires a data centre. It requires the file, the data, and the harness — and the discipline to treat the model like an asset with a maintenance schedule.

The residency checklist’s fourth question — can you take your models with you — is the one that converts the whole exercise from compliance to capability. Jurisdiction, residency, and infrastructure secure the present; the weights layer compounds the future: every run adds to a portfolio that is yours, portable, and re-servable under whatever conditions the next decade brings.

Score the vendor on the layer as harshly as on the rest. Printed, specific, checkable — the same standard as the other three. The checklist and the definition it came from apply the standard to this platform too, gaps included.