Open Source Series · How Large Models Get Smaller

Why Make Models Smaller: The Motivation Behind Distillation

The last section just finished explaining that capability emerges more readily in larger models. So why is the whole industry working so hard to make models smaller? Because capability is not the only constraint. Cost, latency, and whether your data is allowed to leave the building are three things that rule flagship models out of real projects.

The short answer
Models get smaller because reality forces it. Flagship models are the most capable, but they are expensive, they are slow, and they require sending your data to somebody else's servers. In many scenarios a small model that is good enough is the only option that can actually ship. Distillation is the technique for closing as much of the capability gap as possible.
Three reasons to make models smaller

Costthe gap is orders of magnitude, not percentages

Drop the parameter count by an order of magnitude and the compute per inference usually drops by an order of magnitude too. The common industry figure is that inference on a small model can cost one to two orders of magnitude less than on a flagship. Exactly how much less depends on size, quantization level, batch size, and deployment method. Don't memorize the numbers; remember that this is a difference in magnitude, not a discount.

Speedrunning locally removes the whole network round trip

Calling a remote flagship model means a network round trip, then queueing, then generating token by token. Waiting several seconds is normal. A small model running locally cuts out the network leg entirely, so the first token arrives much faster. Conversational products are especially sensitive to this: waiting three seconds and waiting three tenths of a second are two different experiences.

On-premise and compliancesome data is simply not allowed off the internal network

Medical records, case files, internal code, unreleased financial data — for this kind of content the compliance requirement is that it never leaves the internal network. However capable the model on the other end is, it is unusable, because the first step already fails. A small model deployed locally is the only route. The control described back in the first section becomes a hard constraint here.

What does "one to two orders of magnitude" turn into on the invoice at the end of the month? Drag in your own product's request volume and see.

Drag to your own product's order of magnitude first, then look at the gap between the two bills.
Daily requests
The cost and latency figures above describe orders of magnitude, not benchmark results. The unit prices and latencies used by the calculator are illustrative magnitudes as well and do not represent any vendor's quote. The actual gap depends on model size, quantization level, batch size, and deployment method, so rely on measurements from your own scenario. Verified 2026-08-07.
How small does it have to be to fit on your own machine

"Small" is a relative term, but the test is concrete: does it fit on the GPU you have. There is an interactive tool later in this chapter dedicated to this calculation; here is the formula it uses.

VRAM (GB) ≈ parameter count (B) × precision coefficient
Use 2.6 for FP16 and 0.65 for INT4. The coefficient already includes runtime overhead such as the KV Cache, so don't multiply it in again afterwards.

Here are a few sizes on that basis. The last column is whether it runs on a 24 GB consumer GPU after INT4 quantization.

Qwen3-0.6B
FP16 1.6 GB
INT4 0.4 GB
Easily; even edge devices handle it
Qwen3-8B
FP16 20.8 GB
INT4 5.2 GB
Plenty of room; runs on an 8 GB card
Qwen3-32B
FP16 83.2 GB
INT4 20.8 GB
Barely; a long context will overflow
Qwen3-235B-A22B
FP16 611 GB
INT4 152.8 GB
No; quantization won't fix this
The conversion coefficients match the VRAM calculator in oss-8 of this chapter: 2.6 for FP16 and 0.65 for INT4, with roughly 30% to 50% runtime overhead already included. These are empirical estimates, not vendor-stated figures. VRAM for MoE models is calculated from total parameters; the active parameter count only affects speed. The verdicts leave about 15% headroom, which is why 20.8 GB on a 24 GB card counts as "barely" rather than "fine." Verified 2026-08-07.

The conclusion is blunt. Quantized, the 8B size runs on a gaming GPU from several years ago; flagship sizes will not fit no matter how you quantize them. Which turns the question into a different one: can a small model's capability be brought up to standard.

Distillation: having a large model teach a small one

There are two ways to close the capability gap. One is to have the small model learn from scratch on its own, repeating the whole cycle of data, compute, and trial and error. The other is to find a large model that has already learned and let it teach. The second is knowledge distillation.

The large model is the teacher, the small model is the student. The teacher demonstrates how it judges a problem, and the student learns by following along. The student doesn't have to work it out from nothing, and doesn't have to grow to the teacher's size.

The difference from conventional training lies mainly in how much information gets transferred at a time.

Conventional training: right or wrong, that's all

Training data provides the correct answer. Right earns credit, wrong loses it. What comes back from one item is basically a single "right" or "wrong." Whether it was wildly wrong or off by a hair is invisible in the label. The signal is sparse, which is why it takes enormous data and enormous compute to make up for it.

Distillation: you also see how the teacher thinks

The teacher provides not just the final answer but its leanings across all the candidates. On the same item, the student can see which options the teacher considered close and which were nowhere near. The same piece of data carries far more information, so the student learns much faster.

How that information is actually transferred and how the training math works is what oss-6 takes apart. For this section, just hold on to the motivation: distillation saves money and time; it does not create new capability.

A case you can look up yourself

On 20 January 2025, DeepSeek released R1 and open-sourced a set of distilled small models alongside it. The approach was to generate reasoning data with R1 and then train smaller models on that data. Some of the distilled versions are built on Llama as the base, others on Qwen.

This one is worth noting because it is a publicly verifiable third-party choice. Which bases a company picks when it does distillation says more than any marketing claim. R1 uses the MIT License, and the official announcement states explicitly that training other models through distillation is permitted. Only because that was written down in plain terms did anyone dare take this route seriously.

Source: DeepSeek official announcement, 2025-01-20. R1 uses the MIT License, and the announcement explicitly permits users to train other models through distillation. The distilled models released at the same time span sizes from 1.5B to 70B, built on bases from the Qwen and Llama families respectively, and each version still has to comply with the license terms of its own base model. Verified 2026-08-07.

The naming convention for that batch of models and how it was done in detail come in the next section.

The bad news, stated up front
Distillation is not a cure-all. On tasks that require long reasoning chains, multi-step planning, or weighing options across a lot of context, small models remain clearly weaker than flagships. That gap does not disappear by switching to a stronger teacher. When making a selection, don't expect a 7B model to take over every scenario; break the task apart first and see which steps a small model genuinely fits.
The student picks up the teacher's flaws along with everything else. The teacher's biases, blind spots, and phrasing habits all get inherited, and the student cannot tell them apart. When large numbers of small models learn from the same few teachers, the whole ecosystem drifts in one direction. This side effect is what oss-7 covers specifically.
What to take from this section
1. Models get smaller because of cost, latency, and data compliance — three real-world constraints that have nothing to do with chasing the capability ceiling.
2. Whether something can ship comes down to VRAM first, and the formula is parameter count times the precision coefficient.
3. Distillation has a large model teach a small one, in order to avoid the cost of training from scratch.
4. Small models have a capability ceiling, and they inherit their teacher's defects. Put both on the table before you decide.

The next section covers how distillation actually works: how the teacher sets the questions, how the student checks its answers, and which engineering pitfalls sit in between.