What can a large model do that a small one cannot?

What breadth actually buys

A model's parameters are where both its knowledge and its habits are stored. Fewer parameters means less room, and what goes first is whatever appeared least often in training. That loss is real. Four kinds of capability thin out together, and they are the four worth naming before anyone decides a small model is fine. Smaller models may be more likely to guess on some tasks, but error patterns depend on training, prompting, and evaluation; size alone does not determine calibration.

• Obscure knowledge. A fact seen a handful of times in training needs spare capacity to survive. Common facts do not.
• Rare languages. Training text is dominated by a few widely written languages, so low-resource ones degrade first and degrade furthest.
• Long chains of reasoning. Carrying a dozen constraints and intermediate results without dropping one takes room.
• Tolerance for vagueness. Working out what an under-specified request meant is itself a hard task, done before the real one starts.

Long chains are the hardest thing to shrink

Reasoning over many steps is where the gap is most visible, because errors compound rather than average out. A step that comes out right nine times in ten, chained ten times, is right about a third of the time. Raising per-step reliability a little raises whole-chain reliability a lot, and that is most of what breadth buys on hard problems.

This is also why the gap looks wider on difficult test sets than in daily use. Many everyday requests are short, but task complexity varies and errors can compound in short as well as long workflows. Splitting a long task into short steps that are each checked recovers much of the difference, but that is engineering around the model, not a property of the model.

Vague instructions are the difference you feel first

A large model is forgiving. You can ask sideways, leave out the format, change your mind mid-sentence, and it will usually infer the intent. A small model is more literal. It does better when the task is stated plainly and the shape of the answer is given, and worse when it has to guess what you had in mind.

In practice this moves the work rather than removing it. What a large model absorbs at request time, a small model needs supplied in advance: a clearer instruction, a fixed output shape, a narrower job. That is a fair trade when the job is known ahead of time and a poor one when it is not.

Size is not the only variable

Parameter count is the headline number, but it is not the only thing that moves the line. How much data a model saw, and how good that data was, matters as much: published scaling work found that many models had been trained on too little data for their size, and that a smaller model trained longer can match a larger one trained briefly. Training a model for one narrow job moves the line further still.

Two things do not follow size at all. Every model's knowledge stops at the end of its training data, so a larger model is not a more current one. And how a model is compressed to fit on a device changes what it can do for reasons that have nothing to do with how many parameters it nominally has. None of this decides whether a small model is enough for your own work — that depends on the job, not the size, and is a question of its own.