Open Source vs Proprietary LLMs: The Real Tradeoffs

Open source vs proprietary LLMs is a production question, not a philosophy. Open-weight models such as Llama, Qwen, DeepSeek, and Mistral win on cost, control, and data residency once you can operate them well. Proprietary APIs from Anthropic, OpenAI, and Google win on quality ceiling and operational simplicity. The right call depends on your volume, your compliance exposure, and whether you are willing to hire the team that keeps a self-hosted model running at 3am.

I have watched both choices go wrong. One team self-hosted DeepSeek to dodge API bills, then spent four months building the guardrails, monitoring, and failover the API vendor had already shipped for free. Another team paid frontier-API prices for a routine classification task that a fine-tuned 8B open model would have handled for a tenth of the cost. Neither team ran the arithmetic before they committed, and both discovered the real cost only after they shipped.

Deployment fit, open weights or a proprietary API, was one of five factors in my broader framework for choosing an LLM. This piece goes deep on that single factor, because it decides your cost structure and your compliance posture for years, not just your next invoice.

Key takeaways

If you read nothing else, read these.

• The capability gap has narrowed but not closed. Open-weight models trail the closed frontier by about four months and roughly eight points on Epoch AI's capability index as of 2026, with the narrowest gaps in coding and the widest in hard multi-step reasoning.
• Self-hosting rarely wins on hardware cost alone. It wins when volume is high, the task is narrow, and you already carry MLOps capacity. Otherwise the "free" model costs more than the API once you count engineer-hours.
• Licenses vary by checkpoint, not by lab. Llama 4 caps free commercial use at 700 million monthly active users, DeepSeek's weights carry PRC governing law even though its code repo is MIT, and a lab's flagship checkpoint can ship more restrictive terms than its smaller sibling in the same release.
• Data residency is where open weights win outright. Self-hosting keeps every prompt inside infrastructure you control, something no hosted API can promise the same way, regardless of which country the lab is based in.
• The decision is per-workload, not per-company. Most production stacks in 2026 run a mix: a proprietary API for the ambiguous, high-stakes calls, and a self-hosted open model for the high-volume, well-defined ones.

What "open source" actually means for an LLM in 2026

Almost none of the models called "open source" meet the Open Source Initiative's actual definition, which requires open training data and a reproducible training pipeline, not just downloadable weights. Llama, Qwen, DeepSeek, and Mistral all release weights and inference code. None of them release the full training corpus. The accurate term is open weight, and the distinction is not pedantic. It determines what you can audit and what you cannot.

You can inspect an open-weight model's architecture, fine-tune it, quantize it, and run it fully offline. You cannot trace a specific bad output back to a specific training example, because you do not have the data. For most production use cases that trade-off is fine; you care about behavior, not provenance. For regulated or safety-critical use cases, it is a real gap worth naming before you commit.

The license, not the "open" label, governs what you can actually do. Some checkpoints ship Apache 2.0, the closest thing to no-strings-attached in this market. Others ship a custom commercial license with usage-based conditions that only bite once you scale. The short version: read the specific license file for the specific checkpoint you plan to deploy. Do not assume a lab's whole model family shares one set of terms.

Open weights vs proprietary APIs: how big is the 2026 capability gap

Since January 2026, the strongest open-weight models have trailed the closed frontier by about four months and roughly eight points on Epoch AI's Epoch Capability Index, a composite score built from many benchmarks rather than one leaderboard snapshot (Epoch AI). Eight points sounds small. In practice it is comparable to the gap between two consecutive generations of a closed model, which is a real difference on genuinely hard tasks.

The gap is not uniform. Open models have closed in fastest on coding and agentic tool use, where several 2026 open releases now match or beat closed models on SWE-bench-style benchmarks. The gap stays widest on multi-step reasoning and safety-critical judgment calls, where the top closed models still hold a consistent edge. If your workload looks like code generation, structured extraction, or summarization, the practical gap you will feel in production is close to zero. If it looks like open-ended reasoning under ambiguity, the gap is still real money.

Why does the frontier keep pulling ahead at all, given how fast open labs ship? Mostly compute, not cleverness. The labs training the closed frontier are spending more on the training run itself, and scale keeps beating architectural tricks more often than the field likes to admit. I go deeper on why that pattern holds across model generations in The Bitter Lesson, Revisited. The short version for this piece: do not expect a clever open fine-tune to close a compute gap. It can close a task-fit gap instead, which is usually the gap that matters for your product.

The real cost math: self-hosting open weights vs a proprietary API

Start with the sticker prices, because they set the baseline. Anthropic's current published rates put Claude Sonnet 5 at $2 per million input tokens and $10 per million output tokens, and Claude Opus 5 at $5 in and $25 out (Anthropic pricing). On-demand H100 GPU rental, the workhorse for self-hosting a large open-weight model, ranges roughly $1.49 to $6.98 per GPU-hour depending on provider and commitment term. Neither number tells you the answer by itself.

The GPU line is the easy part to model. The line teams skip is engineering headcount: someone has to patch weights, watch for drift, manage the serving stack, and own the pager when the endpoint goes down at 3am. Budget one to two senior engineers, full time, for that work if you self-host anything customer-facing. That is real payroll, not a rounding error, and it belongs in the same spreadsheet as the GPU-hour line.

I have written the full lever stack for cutting inference cost, including where quantization, caching, and routing fit before you ever touch a self-hosting decision, in my guide to reducing LLM inference cost. The order matters: most teams should exhaust the cheap levers on a proprietary API before they take on the fixed cost of running their own weights.

Licensing gotchas: read the license per checkpoint, not per brand

The license is the part teams skip until legal asks about it in a deal review. Four gotchas show up most often.

Llama's user-count cap. The Llama 4 Community License lets you use, modify, and distribute the model freely, unless your product had more than 700 million monthly active users as of the release date, in which case you need a separate license Meta can grant or deny at its sole discretion. You must also display "Built with Llama" on your product and name any derivative model starting with "Llama" (Meta's license page). Almost no team hits 700 million users. The naming and attribution clauses apply to everyone.

DeepSeek's split license. DeepSeek-V3's code repository is MIT licensed, and that fact gets reported as "DeepSeek is MIT licensed," full stop. The model weights themselves ship under a separate DeepSeek License Agreement, governed by PRC law, with its own use restrictions (DeepSeek's model license). It is still a genuinely permissive commercial license with no user cap. It is just not the same license as the code, and "MIT" is the wrong word for it.

Qwen's checkpoint inconsistency. The Qwen3.8-27B checkpoint ships clean Apache 2.0, no strings attached. Alibaba's largest Qwen checkpoints have historically shipped more restrictive terms than their smaller siblings in the same release, including commercial thresholds similar to Llama's. Do not assume every model in a family inherits the same license as the one you tested first.

Mistral's split business model. Mistral 7B and the Mixtral models are Apache 2.0, no restrictions. Mistral's top-tier "Large" model is proprietary and API-only. Picking "Mistral" as your open-weight vendor still requires picking the specific checkpoint, because the flagship is not one of the open ones.

Data residency: the one place open weights win outright

This is the argument that gets missed in most build-vs-buy debates, and it has nothing to do with benchmark scores. When you self-host an open-weight model, every prompt and every output stays on infrastructure you control. No third party sees it. No provider's terms of service govern what happens to it. No cross-border transfer question exists, because there is no transfer.

DeepSeek is the clearest case study, and it is instructive precisely because it cuts against the usual "foreign lab, so avoid it" instinct. Italy's data protection authority ordered an immediate halt to DeepSeek's processing of Italian users' data and had the app pulled from Italian app stores in early 2025, after DeepSeek could not answer basic questions about how it handled EU personal data (Euronews). That action targeted the hosted app and API, where your data transits DeepSeek's servers. It does not touch the open weights at all. A team running DeepSeek's model entirely on its own infrastructure never sends a prompt to DeepSeek, and the regulatory objection does not apply.

That distinction generalizes past DeepSeek. Any hosted API, regardless of which country the lab sits in, asks you to trust its infrastructure, its subpoena exposure, and its subprocessor list. Self-hosting an open-weight model removes that question entirely, at the cost of you now owning security, patching, and uptime yourself. For healthcare, financial services, and any regulated data type, that trade is frequently worth making even when the model itself is a step behind the frontier.

When self-hosting open weights actually pays off

Self-hosting earns its cost under a specific, checkable set of conditions. If most of these are true for your workload, run the real numbers. If two or fewer are true, skip it.

• Volume is genuinely high. You are processing tens of millions of tokens a day, sustained, not in a burst.
• The task is narrow. A fine-tuned, right-sized open model on a specific job usually beats a general frontier model on cost per successful output; I cover the technique that makes this affordable in my guide to LLM quantization.
• You already carry MLOps capacity. The team that will patch, monitor, and page on this model already exists, or you have already budgeted to build it.
• Data cannot leave your infrastructure. A compliance, contractual, or sovereignty requirement makes third-party API calls a non-starter regardless of cost.
• You need deterministic control. You are pinning a specific model version indefinitely, and a vendor's silent model swap would break your product.

When self-hosting is a trap

The trap looks almost identical to the win from the outside, which is why teams fall into it. Volume is moderate, not high, and the GPU sits underutilized most of the day while you pay for it anyway. The task is broad and ambiguous, so the open model needs constant babysitting to hit the quality bar a proprietary API would have cleared out of the box.

The clearest tell is headcount. If nobody on the team wants to own model-serving infrastructure as their primary job, you do not have the capacity to self-host safely, whatever the cost spreadsheet says. I have seen a team spend more in incident response for a self-hosted model's outage than they would have spent on a full year of API calls. The API vendor's uptime and on-call rotation is a feature you are paying for, even when it is invisible on the pricing page.

The honest trade-off: self-hosting trades a variable, predictable API bill for a fixed cost plus an operational tail risk you now own. That trade is a good one for a narrow set of teams. For most teams under real deadline pressure, it is not, and "we'll save money on tokens" alone should not be the reason you take it on.

Frequently asked questions

Is DeepSeek actually open source, or just open weight?

Open weight. DeepSeek releases the model weights and inference code, and its code repository is MIT licensed, but the training data and full pipeline are not published. The weights themselves carry a separate license governed by PRC law. You can self-host and modify the model freely; you cannot audit what it was trained on.

Can I use Llama 4 for a commercial product for free?

Yes, for nearly every company. The Llama 4 Community License is free for commercial use unless your product had more than 700 million monthly active users as of the release date. You do need to display "Built with Llama" and follow the naming rule for any derivative model you distribute.

Is self-hosting an open-weight LLM actually cheaper than using an API?

Only past a volume threshold, and only if you already have the team to run it. Below tens of millions of tokens a day, most teams find a proprietary API cheaper once engineer-hours are counted. Above that threshold, with high utilization, self-hosting can win clearly on unit economics.

Do open-weight models solve data residency problems that proprietary APIs can't?

Self-hosting solves the specific problem of data leaving your infrastructure, which no hosted API, foreign or domestic, can fully replicate. It does not solve every compliance question on its own; you still need to secure and audit the infrastructure you now own.

None of this is a one-time decision. The right model for a given workload changes as volume grows, as licenses get updated, and as the frontier moves. If you are weighing open weights against a proprietary API for a real workload and want a second, unbiased set of eyes on the cost and compliance math, ViitorCloud's technology consulting team works through exactly this kind of build-vs-buy call with engineering teams before they commit.