DeepSeek, Open Source AI, and What It Means for Business Software in 2026
- The famous “$6 million model” figure is $5.576M, it belongs to DeepSeek-V3 rather than R1, and the technical report states plainly that it covers the official training run only — excluding prior research and ablation experiments.
- R1 was measured against OpenAI’s o1, not GPT-4, and it shipped with MIT-licensed weights — the licence, not the benchmark, is what changed the build-versus-buy maths for software teams.
- The R1 you can realistically self-host is usually not R1. The popular small variants are Qwen2.5 and Llama models distilled on R1 outputs, and they inherit their base model’s licence, not MIT.
- Self-hosting is gated by memory before it is gated by budget: R1’s weights alone are roughly 336 GB at 4-bit (671B parameters × 0.5 bytes), before any KV cache.
- The decision is three gates — data residency, sustained volume, and operational capacity — and most teams end up hybrid rather than all-in on either side.
On 27 January 2025, Nvidia fell about 17% and shed roughly $589 billion of market capitalisation in a single session — the largest one-day loss in US market history at the time, and the market’s reaction to DeepSeek R1. The number that drove the story was a training cost of around $6 million. That number is real and it is documented in a primary source — and it is almost always quoted for the wrong model at the wrong scope.
This post corrects three specific things the popular version of the story gets wrong, then gives you the memory arithmetic and the break-even test to decide whether self-hosting an open-weight model belongs anywhere in your stack. Every figure below is traceable to a primary source listed at the end.
- The $5.576M number, in its actual scope
- R1 was measured against o1, not GPT-4
- The model you can run locally is usually not R1
- Your licence comes from the base model
- Memory gates self-hosting before budget does
- Three gates decide the deployment
- The break-even test, with your numbers
- Where the hosted API still wins
- What to do this quarter
The $5.576M number, in its actual scope
The figure comes from the DeepSeek-V3 technical report, which reports 2.788M H800 GPU-hours for full training and converts that to $5.576M at an assumed rental price of $2 per GPU-hour. Two qualifications travel with it and are usually dropped.
First, it describes V3 — the base model — not R1, the reasoning model that caused the market reaction. Second, the report states that the costs “include only the official training of DeepSeek-V3, excluding the costs associated with prior research and ablation experiments on architectures, algorithms, or data.” That is the cost of the final run that worked, not the cost of learning how to do it.
The distinction matters commercially. A final-run cost tells you what it costs to reproduce a known-good recipe. It says nothing about the research programme, the failed runs, the data pipeline, or the cluster you need on standby. Quoting it as the cost of building a frontier lab inverts its meaning — and if you are using it to justify an internal “we could just train our own” proposal, you are budgeting from the wrong line.
How big is the gap between the two? Epoch AI’s analysis of R&D versus training compute estimates that final training runs accounted for roughly 10% of OpenAI’s 2024 R&D compute spending, 22.6% at MiniMax, and 12.3% at Z.ai — a minority share at all three, despite large differences in scale and business model. Read against that pattern, a final-run figure is a fraction of a programme’s cost, not a proxy for it.
The genuine signal is narrower and still important: the compute floor for a frontier-class training run is lower than the industry assumed in 2024. That changes who can enter, not what it costs you to operate.
R1 was measured against o1, not GPT-4
R1 was released on 21 January 2025 and benchmarked against OpenAI’s o1 — specifically o1-1217 — on reasoning suites including AIME 2024, MATH-500 and SWE-Bench Verified, landing within a point or two on several of them. GPT-4 was not the comparison; o1 was, because o1 was the reasoning model of the moment.
The reason to keep this straight is that “reasoning model” and “general chat model” fail differently in production. Reasoning models spend far more tokens per answer on intermediate steps, so a benchmark parity claim on AIME says nothing about your latency budget or your cost per resolved ticket. A model that matches on maths competition problems can still be the wrong choice for classifying 40,000 product descriptions, where instruction-following consistency and per-token cost dominate.
If you are choosing between hosted models for general business workloads rather than reasoning-heavy ones, the trade-offs are laid out in our comparison of which hosted AI model actually suits business work in 2026. Benchmarks pick the shortlist; your own eval set picks the winner.
The model you can run locally is usually not R1
This is the substitution that causes the most wasted engineering time. DeepSeek published R1 itself — 671B parameters, 37B activated per token — and also published a family of much smaller “R1-Distill” models. The distills are not smaller versions of R1. They are Qwen2.5 and Llama models fine-tuned on R1’s reasoning outputs: the Qwen line at 1.5B, 7B, 14B and 32B, and the Llama line built on Llama-3.1-8B and Llama-3.3-70B-Instruct.
Distillation transfers reasoning behaviour; it does not transfer architecture or capability ceiling. When a team reports that “we ran R1 on a workstation and it underperformed,” they almost always ran a 7B or 8B distill. That is a defensible engineering choice — it is simply not the model the benchmarks describe, and comparing its output to published R1 scores produces a conclusion about nothing.
Practical rule: state the exact model identifier in every evaluation you record. DeepSeek-R1, DeepSeek-R1-Distill-Qwen-32B, and DeepSeek-R1-Distill-Llama-70B are three different products with three different hardware profiles and three different licences.
Your licence comes from the base model
R1’s weights are released under the MIT Licence — permissive, commercially usable, few obligations. That is the fact that made the release strategically significant, and it is also the fact most often assumed to cover the whole family.
It does not. The Qwen-based distills derive from the Qwen2.5 series and carry Apache 2.0. The Llama-based distills carry the Llama 3.1 and Llama 3.3 community licences respectively — which are not OSI-approved open source and attach their own conditions on use and redistribution. If your compliance review approved “MIT” and your platform team deployed a Llama-3.3-70B distill, your review approved a licence you are not operating under.
Record the licence per model identifier in the same register you use for other third-party dependencies, and re-check it on every version bump. Weight licences change between releases more often than library licences do.
Memory gates self-hosting before budget does
Before any cost model, check whether the model physically fits. Weight memory is close to deterministic: multiply parameter count by bytes per parameter — 2 bytes at FP16, 1 byte at FP8, roughly 0.5 bytes at 4-bit quantisation. Everything else (KV cache, activations, framework overhead) sits on top and grows with context length and concurrency.
| Model | Weights at FP8 | Weights at 4-bit | Realistic host |
|---|---|---|---|
| DeepSeek-R1 (671B) | ~671 GB | ~336 GB | Multi-GPU server node |
| R1-Distill-Llama-70B | ~70 GB | ~35 GB | Two large GPUs |
| R1-Distill-Qwen-32B | ~32 GB | ~16 GB | One high-VRAM GPU |
| R1-Distill-Llama-8B | ~8 GB | ~4 GB | One consumer GPU |
Verdict: the arithmetic is the point, not the exact totals. Add headroom for KV cache — it scales with concurrent sessions and context length, and it is what turns a model that “fits” in a benchmark into one that runs out of memory under real traffic. The full R1 is a server-room decision. The 32B distill is a single-GPU decision. Those are not the same project, and conflating them is how self-hosting pilots slip a quarter.
Three gates decide the deployment
Three questions, asked in order, resolve almost every deployment argument. Data residency first, because it can force the answer outright; volume second; operational capacity third, because it is the one teams overestimate.
The fourth box is the one most write-ups omit. A managed endpoint serving open weights gives you the licence position and the model choice of self-hosting without the on-call burden — it is the honest middle option, and for teams whose objection is staffing rather than data residency, it is usually the correct one.
The break-even test, with your numbers
Published per-token comparisons age badly and rarely match your workload’s token mix, so compute the crossover yourself. Self-hosting converts a variable cost into a fixed one, and the whole question is where those two lines meet.
Monthly fixed cost of self-hosting is your GPU capacity cost — hourly instance rate × hours held, or amortised hardware — plus the engineering time to operate it. Monthly variable cost of an API is your token volume × the published rate. Set them equal and solve for volume:
break_even_tokens_per_month = monthly_fixed_cost / api_price_per_token
monthly_fixed_cost = (gpu_hourly_rate × hours_held_per_month)
+ (fraction_of_an_engineer × loaded_monthly_salary)Three inputs decide the outcome, and two of them are usually wrong on the first pass. hours_held_per_month is 730 if the endpoint is always warm — scale-to-zero is rarely viable when cold-start means loading hundreds of gigabytes of weights. The engineering fraction is a real, recurring line item, not a one-off setup task; a self-hosted inference service needs patching, capacity planning, and someone reachable when it degrades.
Run the arithmetic before the pilot, not after. If your sustained volume is below the crossover, the pilot will succeed technically and still be the wrong decision — which is the most expensive outcome available, because it ships.
Where the hosted API still wins
Self-hosting buys data residency, licence certainty, and unit economics at volume. It does not buy the surrounding ecosystem, and that gap is wider than benchmark tables suggest.
| Dimension | Self-hosted open weights | Managed open-weight endpoint | Hosted commercial API |
|---|---|---|---|
| Data path | Never leaves your network | Leaves, to a chosen provider | Leaves, to the model vendor |
| Cost shape | Fixed, capacity-based | Variable, lower rate | Variable, highest rate |
| Ops burden | Yours, on call | Provider’s | Provider’s |
| Version control | You pin the weights | You pin the weights | Vendor deprecates on their schedule |
| Tooling maturity | Assemble it yourself | Partial | Most complete |
Verdict: choose the hosted commercial API for general traffic and anything latency-sensitive you have not yet characterised; choose self-hosting for the specific slices where residency or volume justifies the fixed cost. Version control is the underrated row — pinned weights you host cannot be deprecated out from under a workflow you shipped, which matters more for embedded product features than for internal tooling.
Whichever side you land on, the integration surface is the same problem. If you are calling models from inside an ERP workflow, the retry, timeout and idempotency patterns in our guide to calling AI APIs from SuiteScript apply unchanged to a self-hosted endpoint, and the emerging standard for wiring tools to models is covered in our explainer on the Model Context Protocol.
What to do this quarter
A short, executable list. Work down it in order — the first two items frequently end the discussion before anyone provisions a GPU.
- Write down which specific workloads have a data-residency constraint, with the clause or policy that creates it.
- Measure sustained monthly token volume for those workloads from real logs, not from an estimate.
- Compute the break-even volume with your own GPU rate and engineering fraction, holding hours at 730.
- Record the exact model identifier and its licence for every candidate, including distills.
- Check weight memory at your target quantisation, then add headroom for KV cache at peak concurrency.
- Build a task-specific eval set from your own data before comparing any two models.
- Price a managed open-weight endpoint as a third option, not as a fallback.
- Decide per workload, not once for the organisation.
Most teams that complete this list end up hybrid: a commercial API for general traffic, and self-hosted or managed open weights for the sovereign or high-volume slice. That is not a compromise — it is what the three gates produce when applied honestly, workload by workload.
Get the working checklists
The runbooks and decision checklists from these guides, as printable PDFs — free in the SoftXone guide library.
Deciding where a model runs is an architecture decision with a compliance dependency, and it is easier to get right before the first workload ships than after. If you want the three gates applied to your stack — including the integration and data-path questions that follow the decision — see how we scope integration and software work. Broader background on running models alongside commerce systems sits in our AI for commerce teams guide hub.
References
- DeepSeek-V3 Technical Report (arXiv:2412.19437)Primary source for the 2.788M H800 GPU-hour figure, the $5.576M conversion at an assumed $2/GPU-hour, the exclusion of prior research and ablations, and the 671B/37B parameter counts.
- DeepSeek-R1 model cardPrimary source for the MIT licence on R1 weights, the distill lineage from Qwen2.5 and Llama-3.1-8B / Llama-3.3-70B-Instruct, and the licences those distills inherit.
- TechCrunch — DeepSeek’s reasoning model versus o1Contemporaneous reporting on the January 2025 release and the o1 comparison, not a GPT-4 comparison.
- CNBC — Nvidia’s one-day market-cap lossThe 27 January 2025 move: about 17% down, roughly $589 billion of market capitalisation.
- Stratechery — DeepSeek FAQIndependent reading of the cost figure’s scope, including the breakdown into pre-training, context extension and post-training GPU hours.
- DeepSeek-R1-Distill-Qwen-32B model cardReference for one specific distill’s base model and licence, illustrating the per-identifier licence check.
- Epoch AI — final training runs versus total R&D computeEstimates that final training runs are a minority of R&D compute spending at OpenAI, MiniMax and Z.ai — the quantitative case for reading any single-run cost figure narrowly.
Frequently asked questions
Can we fine-tune an open-weight model on our own data and keep it private?
Yes. Fine-tuning runs wherever you run it, so a self-hosted or on-premise setup keeps both the training data and the resulting adapter weights inside your network. Budget for storing and versioning those adapters separately from the base weights — the adapter is the artefact you actually own.
Do we need our own GPUs just to evaluate an open-weight model?
No. Rent an hourly GPU instance or use a managed endpoint serving the same weights for the evaluation phase. What you need is a task-specific eval set built from your own data; where inference runs during testing does not change which model wins.
How often do open-weight licences change between releases?
Often enough to re-check on every version bump. Licences are set per release and per variant, so one model family can carry MIT, Apache 2.0 and vendor community terms simultaneously. Record the licence against the exact model identifier, in the same register as any other third-party dependency.
What happens to a self-hosted model if the publisher stops updating it?
Nothing immediately — you keep serving the weights you already hold, which is the main argument for pinning them. The cost shows up later as drift: inference runtimes and quantisation formats move on, and an unmaintained model gradually pins you to an ageing serving stack.
Is a small distilled model good enough for classification and extraction?
Frequently, yes. Those tasks depend on consistent instruction-following far more than on deep reasoning. Test the smallest variant against your eval set first and step up only where a measured gap appears — the hardware cost curve between an 8B and a 70B model is steep.
Leave a Reply