Open-weight vs closed models — what you actually control

TL;DR. In AI marketing, "open" usually means weights you can download and run. "Closed" usually means you call a vendor API and never hold the full model. The useful question is not which badge is more virtuous — it is what you control, where data goes, how hard ops becomes, and who helps when something breaks.

Two doors, same building

Imagine a kitchen:

Path	Everyday picture	What you hold
Open-weight	You buy the recipe book and cook on your stove	The parameters (weights) on hardware you run
Closed API	You order from a restaurant kitchen	A network call; the kitchen stays theirs

Both can feed your team. They are different control and ops deals.

What "open" usually means (and what it doesn't)

Buyers hear "open source AI" and picture Linux-style freedom. Reality is messier:

• Open-weight — you can download the trained parameters and run inference (and sometimes fine-tune) under a licence that may still restrict commercial use, redistribution, or certain fields.
• Open source (OSI-style) — source, build, and licence terms that meet a community definition of openness. Many popular "open" models are not fully there.
• Open ecosystem — tooling, papers, and community around a model family — useful, but not the same as "you own the binary."

So when a slide says "open," ask: May we download the weights? Under what licence? May we fine-tune and ship? Who patches security?

What "closed" usually means

A closed (proprietary) model is typically:

• Hosted by the vendor (or a small set of approved hosts).
• Reached via API with model IDs that can change — aliases get retired; clients must pin and re-test.
• Strong on vendor ops and support, weaker on inspecting or relocating the exact weights.

Closed is not a slur. For many teams it is the right default — until residency or audit says otherwise.

The real trade-offs (buyer checklist)

Concern	Open-weight / self-host lean	Closed API lean
Data residency	Prompts can stay on your box / VPC	Data leaves to the vendor (unless a private region / contract says otherwise)
Control	Pin weights; choose stack	Vendor chooses release cadence; you pin model IDs and policies
Ops burden	GPUs, upgrades, monitoring, patching — yours	Mostly theirs; you still own integration and eval
Cost shape	Capex / cluster time vs tokens	Usually token / seat bills; predictable ops, variable usage
Support	Community + your team, or a paid product around the weights	Vendor support is part of the product
Licence risk	Read the weight licence carefully	Read the API ToS and data-use clauses carefully

Neither column wins on morality. Fit wins.

A calm way to choose

Use three sentences in the next vendor meeting:

1. Where may our prompts and documents live?
2. Can we pin a model version for audit, and what happens when aliases change?
3. Who is on call when quality or uptime slips — and how do we evaluate on our work before go-live?

If self-host answers those better, open-weight (plus a governed platform) is the path. If a managed API answers them under an acceptable contract, closed can be the grown-up choice. Hybrid is common: closed for some workloads, self-host for sensitive ones — with an explicit model catalogue, not hope.

How this connects to what we build

At AiHPC we care about governance and fit, not preaching one badge. OrchAI lets organisations run AI on their own documents and workflows — Library for cited knowledge, Agents as the controlled front door, Eval for honest quality gates, Portal when you need the full building — whether the underlying model is self-hosted open-weight or a carefully governed API route. The model path is a dial. Control and evidence are the product.

Choosing a path for a regulated or institutional workload? Talk to us or try the demo.

Frequently asked questions

Does "open" mean open source? Often it means downloadable weights, not full OSI open source. Read the licence.

Is a closed API less governable? Not automatically — you can still policy, log, and eval. You usually give up where weights run and how much you can inspect them.

When should we self-host? When residency, pinned weights, or egress rules demand it — and you can staff the ops. Otherwise a managed API may be the clearer buy.