DeepSeek R1 changed what you could run yourself

A reasoning model can solve a difficult problem and still be the wrong choice for your project. Perhaps the data cannot leave your network. Perhaps you need to keep the same model version for a year. A good answer from someone else's API doesn't settle either problem.

DeepSeek R1 made that choice more interesting. Its original January 2025 release paired competitive reasoning results with downloadable weights and smaller distilled models. You could examine the model, adapt it, or run a version under your own control. The useful question is which version gives you enough capability, on hardware you can actually operate. The headline benchmark and the model that fits on your desk are different things. DeepSeek's release repository documents both.

Start with what the benchmark measured

The following numbers come from the original January 2025 R1 report, comparing the full R1 with OpenAI o1-1217. They are a historical release comparison, not a ranking of today's models or measurements from my own deployment.

Benchmark	DeepSeek R1	OpenAI o1-1217
AIME 2024 (Math)	79.8%	79.2%
MATH-500	97.3%	96.4%
Codeforces (Competitive Programming)	96.3 percentile	96.6 percentile
GPQA Diamond (Graduate Science)	71.5%	75.7%
SWE-bench Verified	49.2%	48.9%

Original January 2025 comparison of full DeepSeek R1 and OpenAI o1-1217. Codeforces uses percentile; math and GPQA use percentage scores; SWE-bench Verified reports the percentage of issues resolved. Compare models within each benchmark, not scores across benchmarks. Source: DeepSeek's R1 report, Table 4.

The paper uses a generation limit of 32,768 tokens, temperature 0.6, and top-p 0.95 for its sampled evaluations. It estimates pass@1, the chance of a correct individual answer, from multiple responses per question. The authors took o1-1217 results from official reports because they lacked reliable API access. This is a published comparison with different sources for the two models, not a controlled rerun of both in the same environment.

Even with that qualification, the result deserves attention. R1 was close enough on these tasks to warrant serious evaluation. The 0.6-point AIME lead doesn't establish that R1 is universally better, any more than o1's GPQA lead settles every science workload. And resolving about half the issues in SWE-bench Verified leaves plenty of room for failure. I would use these results to choose what to test next, then judge the model on the actual work.

What the full model is doing

R1 generates extended reasoning text before its final answer. That gives it room to try an approach, reconsider a step, and continue. Ordinary instruction-tuned models can also produce step-by-step answers; the interesting part here is training that encourages useful extended reasoning. A long explanation alone is no guarantee of a correct result.

Underneath sits DeepSeek-V3-Base, a mixture-of-experts model with 671 billion total parameters and about 37 billion active per token. Think of a large workshop where each job uses a subset of the equipment. You save work by activating only what that step needs, but you still have to house the workshop. Active parameter count helps explain computation; total parameter count still matters for storing and serving the model. The V3 technical report describes that architecture.

This distinction matters when someone says R1 runs locally. The full model is a substantial infrastructure commitment. The smaller models described later are separate models trained from R1's examples, with their own capabilities and limits.

How successful attempts become training signal

Group Relative Policy Optimization, or GRPO, makes the basic training idea approachable. Give the model a problem several times, score the attempts, and compare each score with the others in that group. Attempts that score above the group average receive a stronger positive signal.

GRPO was introduced in DeepSeekMath before R1. Its resource-saving distinction is that it estimates the comparison baseline from the group instead of training a separate critic, also called a value model. A critic estimates expected reward; a reward function or reward model supplies the score. Removing the critic doesn't remove the need to judge the answers.

# Simplified GRPO intuition
for problem in training_set:
    # Generate K candidate reasoning chains
    chains = [model.generate(problem) for _ in range(K)]

    # Score each chain: did it reach the correct answer?
    rewards = [score(chain, problem.answer) for chain in chains]

    # Normalize rewards within the group
    normalized = (rewards - mean(rewards)) / std(rewards)

    # Update model: upweight good chains, downweight bad ones
    model.update(chains, normalized)

This is pseudocode, not an executable trainer: the list arithmetic stands in for tensor operations, and a real implementation needs to handle equal rewards, where the standard deviation is zero. It also omits the constraints that keep updates from moving the model too far at once. Its purpose is to show where the learning signal comes from.

A math answer or a program that passes tests gives you a relatively concrete way to score an attempt. Evaluating a persuasive recommendation is harder. The score can reward what is easy to measure while missing what you care about. That is why the training task matters as much as the algorithm.

The R1 report's training recipe also distinguishes two models. R1-Zero applied reinforcement learning directly to the base model and developed reasoning behavior, but struggled with readability and language mixing. R1 added initial supervised examples and further training stages. Rule-based rewards supported verifiable tasks; later training also used learned rewards for broader preferences. Describing the whole release as reinforcement learning without supervised data would confuse R1 with R1-Zero.

Put the $6 million figure on the right invoice

The widely repeated figure belongs to DeepSeek-V3. Its report estimates $5.576 million for the official training run, using 2.788 million H800 GPU-hours at an assumed rental price of $2 per GPU-hour. That includes V3 pretraining, context extension, and post-training, while excluding earlier research and ablation experiments. It is not an all-in bill for developing R1. V3 cost breakdown

The engineering achievement is still meaningful. V3 combined sparse computation, lower-precision training, and work on communication efficiency to use its hardware effectively. But that accounting cannot establish a like-for-like cost advantage over another lab's entire research program. Nor does a training bill tell you what serving a long reasoning answer will cost your application.

The geopolitical interpretation needs the same discipline. An efficient model developed under hardware constraints is interesting evidence about what engineering can accomplish. It doesn't isolate the effect of export restrictions or show that the restrictions caused the innovations. The technical report describes the machinery and training choices; it cannot tell us what the team would have achieved under a different policy. For a practitioner choosing a model, the useful result is the capability available to evaluate.

What owning the weights buys you

DeepSeek released R1's code and weights under MIT terms, with commercial use and modification permitted. Its license notes identify the distilled models' origins: the Qwen variants derive from Apache 2.0 models, while the Llama variants derive from models with their respective Llama licenses. Check the terms for the particular artifact you plan to use.

Having the weights lets you keep a fixed version, inspect behavior under controlled conditions, and fine-tune a model for your task. Researchers can go beyond the experiments an API permits. API access still supports useful evaluations, but it doesn't give you the same control over the model itself. Downloadable weights also don't amount to a complete reproduction of the original training process.

For an organization handling sensitive data, deployment inside its own environment may make an otherwise unsuitable workflow possible. Consider a hypothetical assistant reviewing internal database migration scripts. The team can evaluate it against private schemas and known failures without sending those materials to a hosted model. It still needs access controls and an operational owner. Local deployment changes who carries those responsibilities.

The same control supports community experimentation with quantization, fine-tuning, and derived models. Quantization stores weights at lower precision to reduce their memory footprint. Each variation becomes another candidate to test; the original R1 scores don't automatically transfer to a smaller or modified artifact.

The version that might fit on your machine

DeepSeek-R1-Distill-Qwen-32B and DeepSeek-R1-Distill-Llama-70B are among the smaller models trained on examples generated by R1. Distillation gives a student model useful demonstrations from a larger teacher. It doesn't put all of the teacher into a smaller file, and a student must be evaluated separately. The release's model list and results keep these models distinct from full R1.

For the 32B variant, Ollama lists a Q4_K_M package of about 20 GB. That makes a local trial more approachable, but the file size is only part of the memory requirement. The runtime also needs working memory, including the cache that grows with context. A model file fitting on a GPU doesn't establish that a long conversation will fit comfortably alongside it.

# Running the distilled model locally with Ollama
ollama run deepseek-r1:32b

# Or with llama.cpp for more control
./llama-server -m deepseek-r1-distill-qwen-32b-Q4_K_M.gguf \
    --ctx-size 32768 \
    --n-gpu-layers 99

The second example assumes the llama-server executable and the named GGUF model file are already present. It requests a 32,768-token context and GPU offloading; those are settings to size for your hardware, not a promise that a single consumer GPU has enough memory. The llama.cpp server documentation explains the controls. These commands are starting points for a trial, not results from a measured deployment.

Choose the workload before choosing the winner

R1 expanded the set of credible options for people who need control over a reasoning model. The full release made competitive capability available to inspect and adapt. The distilled family lowered the barrier to trying that approach locally. Neither result needs an inflated training-cost claim to be useful.

For the migration-review example, I would test the exact model and quantization against scripts with known defects, harmless changes, and cases that require asking for missing information. Track which defects it catches, which safe changes it flags incorrectly, and how much time and memory each review consumes. Compare it with the alternative under the same acceptance criteria. A fluent explanation of a broken migration is still a broken review.

If a smaller R1 variant meets that bar, local control becomes a practical option with measurable tradeoffs. If it misses important failures, the full model's benchmark chart won't rescue it. You now have something more useful than a general claim that open reasoning has caught up: a way to decide whether a model you can operate yourself is good enough for the work in front of you.