Learn how to use open weight models enterprise workloads with a practical framework for model placement, self hosting, costs, and governance.
Your frontier API bill is growing faster than your usage. Your security team wants to know where the prompts go. Somewhere in that gap sits the real question about open weight models in the enterprise: which workloads should you run yourself, and which should stay on a closed API you do not operate?
Most guidance answers a different question. It argues whether open models are good for the industry. That is a policy debate, and it will not tell you what to do on Monday.
This article gives you the decision tool instead. You get a placement matrix scored on five factors, the cost lines that self hosting adds to your bill, the controls a residency rule needs, and three conditions where running your own model is the wrong call.
An open weight model is an AI model whose trained parameters are published for download, so an enterprise can inspect it, fine-tune it, and run it on hardware it controls. The weights are free to obtain. The licence, the serving stack, and the running cost are separate questions with separate answers.
Open weight is not open source. Two things separate them.
First, the weights are not readable. Open source software ships code an engineer can read and reason about. A model ships billions of floating point numbers. You can run them and change them. You cannot read them.
Second, the licence is usually bespoke. Apache 2.0 and MIT set no revenue thresholds. Model licences often do.
Moonshot AI published the full Kimi K3 weights in July 2026 under its own terms. A firm running a model-as-a-service business must sign a separate commercial deal once group revenue passes 20 million dollars, and the biggest deployments must show the model name in their own product. Meta's Llama community licence works on the same idea, with a threshold at 700 million monthly users.
So read four things in any model licence, before you benchmark rather than after:
None of this is a reason to avoid open weight models. It is a reason to treat the licence as a design input.
The decision you own is narrower than the public argument. It is placement: which workloads run on a model you host, and which stay on a closed API.
Most enterprises will run both. The split gets decided per workload, not per company.
That is roughly where the industry has landed too, once you strip out the politics. An open letter titled Open Weights and American AI Leadership went up on 24 July 2026, signed by more than 70 organisations. NVIDIA, Microsoft, Meta, Google, OpenAI, IBM, Box, Palantir, Hugging Face and The Linux Foundation are all on the list.
Three days later Anthropic set out its own position. It says it has never advocated banning open weight models, calls open models without dangerous capabilities a public good, and disputes two specific safety claims the letter makes. So the two documents argue about policy. Neither argues that an enterprise should pick one kind of model and stop.
The capability gap is real, and it is narrow. Stanford's 2026 AI Index put the leading closed model 3.3 percent ahead of the leading open model as of March 2026, as reported by Forbes. In August 2024 the same measure showed 0.5 percent. A separate Epoch AI figure, on its own index, works out to roughly four months of lag in early 2026, stretching to six under a stricter rule.
Those numbers matter less than what the task tolerates. On a document classifier, three percent is noise. On a novel analysis where a wrong answer creates legal exposure, three percent is the whole argument, because retrieval and human review will not reliably catch what the model got wrong.
There is a commercial reason to run open models as well. Boris Renski, CEO of Apelogic, told Fierce Network that your ability to negotiate with a frontier lab tracks how locked in you are. A second model kept warm is a negotiating position, not just an architecture. He sells tooling in this category, so weigh it as a view rather than a finding. It still matches what we see in AI strategy and engineering work with clients renewing a large model contract.
Placement comes down to five questions. Ask them per workload, and ask them in this order.
Data sensitivity and residency. Where is the data allowed to sit, and who is allowed to see it? The question a security team actually asks is not open or closed. It is whether the data crosses a boundary the enterprise controls.
Volume and latency. What is your p95 latency budget, and does a cold GPU pool meet it? Steady high volume rewards capacity you own. Spiky low volume punishes it.
Cost of a wrong answer. Price the failure first. Then ask whether retrieval, an abstention rule, or a human review queue can catch it before it reaches anyone.
Control and audit evidence. Will you need to state which model version produced a decision, six months later, to someone outside the company? Version pinning is easy on weights you hold. It is harder on an endpoint that moves under you.
Total run cost. Not the token price. The whole bill, which the next section breaks out line by line.
Score your own top ten workloads against those five factors, then place them. The table below shows how seven common workload classes usually land. Use it as a starting point, and argue with any row that does not match your data.
One estimate in circulation puts the split at 20 percent self-hosted and 80 percent frontier services. Kevin Cochrane, CMO at Vultr, gave that figure to Fierce Network, describing sensitive core workloads against everything else. Treat it as a sanity check on your own scoring, not as a target. A bank and a retailer will not land on the same number, and neither should copy his.
The weights are free. The service is not. A download gives you trained parameters, and parameters do not serve traffic.
Real engineering sits between the two. Request batching. A KV cache that holds up under load. Quantization choices you can defend. Autoscaling. A latency target you actually hit. Metering your finance team accepts, and telemetry an auditor can read. Forbes made the same point about the inference market this month: parameters on their own are not a product.
Here are the lines that land on your budget.
Two of those lines fail most often in our delivery work. Evaluation drops out of the business case entirely, because a closed API absorbed it invisibly. And the refresh cycle gets costed once, as though a model choice made in July still holds in January. It does not.
Residency is a design constraint, not a preference. It is the one factor that can settle placement on its own, before cost or quality enters the room.
A model you host keeps the training signal inside your boundary. Tune it on your own claims history or support tickets, and the resulting weights are your asset rather than a vendor's. That is harder to arrange with a closed model, where the vendor builds the tuned version and hands it back to you.
Be honest about the alternative. A closed vendor running in your own cloud region, under a contractual residency commitment, satisfies plenty of requirements. Self hosting is one way to meet a residency rule. It is not the only way, and it is rarely the cheapest.
Either way, the controls look the same. Name each one, name its owner, and name the artifact that proves it.
Regulatory scope stays yours to assess. Rules such as HIPAA, GDPR and DPDP place obligations on the organisation, not on an architecture. Controls give your auditors something to look at. They do not make anyone compliant, and no vendor can hand you that. Teams building the evidence layer often start with security and compliance support before they pick a model.
One healthcare engagement shows why the boundary decision comes first. In a prior authorization automation build, Entrans used OCR and large language models to pull structured data out of unstructured clinical documents. A configurable rule engine then checked that data against medical and payer criteria.
Processing ran 3X faster, manual effort and errors fell 70 percent, and extraction accuracy held above 95 percent as document volumes grew. Model choice mattered on that build. Where the records were allowed to sit mattered more.
The model becomes your responsibility. Three jobs that a closed API used to absorb now need a named owner.
An evaluation harness you run yourself. Your own test sets, your own quality baseline, your own regression suite. Without it you cannot tell whether a model change helped or hurt.
A model registry and a refresh decision. Which version is in production, who approved it, and what triggers a move. Better open models ship every few months, and each one is a decision rather than an upgrade.
Inference operations against a budget. Latency and cost per thousand calls, watched like any other service level. This is where model deployment and monitoring practice earns its keep.
Guardrails move too. Once weights sit on your own infrastructure, safety behaviour is yours to build and yours to keep. Anthropic's position post is blunt about this, quoting the UK AI Security Institute: safeguards can be removed, and released weights cannot be withdrawn. Read that as an argument for owning the control layer, not as a reason to avoid open models.
If you use a managed provider instead of your own GPUs, ask one question early. When you tune a model on their platform, what leaves with you when you go? Four artifacts settle that: the tuned adapter itself, whatever you built to score it, the config that routes traffic between models, and your request logs. Forbes raised the same diligence point for buyers in this market. Name all four in the contract.
Audit evidence shapes architecture more than teams expect. On one lending platform rebuild, Entrans worked alongside underwriting, risk and compliance teams to put rule-based decision engines and full audit trails into a cloud-native platform. Loan processing time fell 45 percent and onboarding ran 50 percent faster.
That audit trail was not a feature bolted on at the end. It set the design. The same thing happens when a model moves in-house.
Three conditions make self hosting the wrong call. Each one has a better answer.
Low and spiky volume. A GPU pool costs the same at 3am as at noon. Serving a few thousand calls a day against reserved capacity loses to a closed API on cost, and it loses badly. Better answer: stay on the closed API, and revisit when steady volume justifies a committed term.
No owner for evaluation. Self hosting moves a quality problem inside your walls, where nobody is watching it. Better answer: build the evaluation harness first, on the API you already pay for. Then move the workload, and you will know whether the move helped.
A model whose supply you cannot rely on. A licence that changes at a revenue threshold is a dependency. So is a model that could face export restriction on downloads while its hosted API keeps running. Shekar Ayyar, CEO of Arrcus, told Fierce Network that a standardisation decision here can repeat the Huawei pattern. Better answer: pick a model with permissive terms and a maintainer you can name, or keep the workload portable across two models and test the switch on a schedule.
One more thing, and this is what we advise clients against. Do not make a customer-facing workload your first self-hosted project. Prove the operating model somewhere a bad answer is cheap. Internal search or document extraction teaches the same lessons at a fraction of the exposure.
Most teams already know which two or three workloads are the candidates. What they do not have is a defensible number for what moving them costs and what it saves.
Book a 20-minute consult with Entrans's AI architects for a rapid assessment and an AI-accelerated roadmap. We score your top workloads against the five factors, put a cost baseline against the two or three that look viable, and tell you plainly which ones should stay exactly where they are.
Open weight models publish the trained parameters, so you can download, inspect, tune and run them yourself. Open source software publishes readable code under a standard licence such as Apache 2.0 or MIT. Model weights are numbers no engineer can read, and most releases carry a bespoke licence with commercial conditions attached.
The practical effect is legal, not technical. Two models can be equally downloadable and still differ completely in what you are allowed to sell on top of them.
Score each workload on five factors: data sensitivity and residency, volume and latency, the cost of a wrong answer, the control and audit evidence you need, and total run cost. Sensitive, high volume, well defined work tends to favour a model you host. Novel or low volume work tends to stay on a closed API.
Run the scoring per workload. A single company-wide answer is almost always wrong in both directions.
Not automatically. The weights are free, the service is not. You pay for GPU capacity whether or not it is busy, plus inference engineering, evaluation, security review, and a refresh cycle each time a better model ships. Self hosting usually wins on steady high volume and loses on spiky low volume.
Model the idle hours before you model the token price. That single line flips more business cases than any other.
Yes. Tuning a model you host lets the training signal and the resulting weights stay inside your own boundary, and you keep them as your own asset. Check the licence first: some releases restrict commercial use above a revenue threshold, and some require you to name the base model inside your product.
Stanford's 2026 AI Index put the leading closed model 3.3 percent ahead of the leading open model as of March 2026, against 0.5 percent in August 2024. Epoch AI's own index points to a lag of about four months over early 2026. Whether that gap matters depends entirely on the task in front of it.
For classification and extraction it rarely does. For novel reasoning with no downstream check, it often decides the answer.
A model you have downloaded does not phone home. Once the weights sit on your hardware there is no link to the lab that trained them, so the exfiltration fear is misplaced. The real exposure is regulatory and commercial. Export controls on either side could cut off downloads or updates, stranding anyone who treated a model as permanently available.
Keep that workload portable across two models, and the risk becomes a migration rather than an outage.
Enterprise open weight models in common use include Llama, Mistral and GPT OSS, served with vLLM or SGLang on GPU capacity the company owns or rents. Weight sizes vary widely. GPT OSS is roughly 240 gigabytes, and the largest 2026 releases reach about 1.5 terabytes, which rules out small deployments.
-1.svg){kind=small}
