MIT Just Found a Hard Limit in LLM Scaling, and Money Won't Fix It

0:00 Watch a model answer a question it should get right. It's summarizing a short function and it says with complete confidence that the code retries three times when a request fails. Now look at

0:10 the function. There's no retry anywhere in it. This isn't a hard prompt and it isn't a weak model. It's a capable one describing a detail the function doesn't contain. And when that happens, the fix

0:21 we reach for is usually the same. Get a bigger model. How much does a bigger model actually fix? It's a sharper question than it sounds. and there's a second one hiding behind it. Is size

0:31 even the best lever you've got? A result out of MIT gives the first half a surprisingly exact answer. Bigger really does help in a way you can put a number on. But that same number shows why it

0:42 helps a little less every time you pay for it. And it points straight at a lever most developers rarely reach for. Start with why bigger works at all. Because it really does. Since about

0:52 2020, labs have planned around scaling laws. Feed a model more parameters and more data. and its error drops on a smooth predictable curve. That error has a name, the loss, which just measures

1:04 how wrong the model's predictions are on average. Lower loss, better model. This one curve is why companies raised billions to build something bigger. It has paid off for years, but a smooth

1:14 curve isn't an explanation. For years, the scaling laws were basically an observation. We could measure that loss falls as models grow without really knowing why it falls so cleanly. That's

1:25 the gap a team at MIT set out to close. Their paper first went up in May 2025. So, this isn't breaking news. Think of it as a lens on the curve all those billions are chasing. Their answer has a

1:36 name, superposition, and it comes with a built-in ceiling. I'll define it properly in a moment. The short version, a model represents far more ideas than it has room for, and that crowding

1:46 leaves a floor of noise it can't fully remove. Making the model wider lowers the floor, but slowly on a curve you can write down. One caveat up front. This is about the loss, not hallucinations

1:58 directly and not a hard cap on intelligence. So superposition start with how a model stores anything at all. It turns each word into a list of numbers, a vector that points somewhere

2:08 in an internal space. That space has a fixed number of directions. And that count is basically the model's width. A small model might have a few thousand of them. Every idea the model knows has to

2:19 live as some direction in that space. Now the squeeze. A model needs to represent far more distinct features than it has directions to spare. Not a few thousand ideas, but many times more

2:30 than the few thousand directions it's working with. It's like having a few thousand shelves and tens of thousands of labeled boxes to store. You can't give each box its own shelf. There

2:39 simply isn't the room. So, the model does something clever. It stores several features along the same shared directions as vectors that don't quite line up. That trick has a name,

2:49 superposition, which just means packing in more things than you have room for. The idea traces back to Anthropic's toy models work from 2022. Two features sharing space aren't perfectly separate,

3:00 so they bleed into each other a little. That bleed is called overlap. And that overlap is the whole story. Every time two features share space, reading one back picks up a faint smear of the

3:10 other. across thousands of packed features. Those smears add up to a steady hum of noise on everything the model represents. That hum is a floor under the loss. Even a perfectly trained

3:21 model keeps a little error purely from the crowding. It's working through a low hum of interference the whole time. Now the payoff and it's the useful part. Give the model more directions to work

3:31 with a wider model and the packed vectors have more room to spread apart. As they spread, their overlap shrink the math in the paper is clean. The noise falls as roughly one over the width.

3:42 Double the width and you roughly have the error that comes from crowding. That right there is the scaling law falling straight out of geometry. And this isn't just a toy. The team checked real open

3:52 models families like OPT, Quinn 2.5, and Pythia spanning about 100 million up to 70 billion parameters. The overlaps really do shrink as one over the width. The loss really does track it. When they

4:05 fit the exponent, they get about 0.91 close to the clean value of one. The theory predicts the geometry holds in real language models. One knob controls all of this weight decay, the training

4:16 setting that pushes weights towards zero. Turn it up and the model gets picky. It stores the common features cleanly and drops the rare ones. Turn it down and the model cra with heavy

4:27 overlap. Real models run in that crammed regime. So that's why bigger works. Now, the part that should change how you spend money. Look closely at that curve, though, because one over the width is a

4:38 slow road. To cut the crowding error in half, you double the width. To have it again, you double it again. But doubling a model's width more than doubles what it costs to train and to run. So, each

4:49 real step down in error cost you more than the last one did. You're paying more and more for less and less. This is where the title needs a caveat because the careful version matters more. The

4:59 paper measures loss, the model's average prediction error. Loss tracks quality, but it isn't the same thing as a hallucination rate. The work also doesn't prove a hard ceiling on how

5:08 smart models can get. It explains one specific cost that grows as you scale using a toy model and a check on real ones. That's a strong result. It just isn't the end of intelligence. So, does

5:19 money fix it? Partly, and that's the fair answer. A bigger model really is a better model, and the loss really does fall. But you're buying linear gains at exponential prices and that trade gets

5:30 worse the higher you climb. Brute scale is the most expensive lever in the room which raises the obvious question. What are the cheaper ones? Consider a different move. Instead of pouring money

5:41 into a wider model, spend it while the model is answering. The width is locked in once training ends, but how hard the model works on your specific question is up to you. That answer time compute is a

5:52 lever most people leave sitting on the table. This one is called test time compute. And the idea is simple. Give the model room to work before it commits to an answer. Let it draft several

6:01 attempts instead of one. Let it check those attempts and revise them. You're trading a bit more time and money per question for a better answer without touching the model size at all. There

6:11 are two main ways to spend it. One, generate several candidate answers, then score them with a separate checker, a verifier, and keep the best. Two, let the model read its own answer and

6:22 rewrite it in passes, fixing what's weak. Search and pick or revise and improve. Both spend compute at answer time instead of in the parameters. How well does that actually work? A 2024

6:34 study from Berkeley and Google DeepMind put numbers on it. Spent well testime compute beat the naive approach by more than four times for the same budget. And on easier problems, a small model given

6:45 room to think matched a model 14 times its size at the same total compute. Same hardware bill. Very different answer. But the same study is careful and so am I. This edge shows up on easy and medium

6:57 problems where the small model already had a real shot. On the hardest questions, the ones the small model just can't touch. More thinking doesn't rescue it. There, the bigger model still

7:07 wins. Test time. Compute is a lever, not a magic wand. So, put both levers on the same bench. This is a test any developer can run, and it's the practical heart of it. Take one real coding task against a

7:19 library the model doesn't know. Cold. Config. A is the reflex. Hand the whole thing to a big frontier model. One shot, no help. Config B uses a smaller, cheaper model, but you give it the

7:30 library's real docs and the output from the failing tests, and you let it iterate. Look at what config B actually is. The docs are context, the right information in front of the model at the

7:40 moment it needs it. The failing tests are a verifier, a cheap automatic check on whether the code is correct. Read, try, check against the tests, fix, repeat. That's test time compute applied

7:52 by hand on a laptop. So which one wins? That's the experiment and it gets reported straight on correctness, on dollars, and on wall clock time. Config B reads the docs, runs the tests,

8:03 watches them fail, and edits until they pass or until it gives up. The comparison is logged and shown on screen. Whichever way it lands, the measured result belongs right here from

8:13 the actual run with no thumb on the scale. And this part holds no matter who wins. If the big model wins outright, then some problems really are worth the premium, and now you know which ones. If

8:25 the small setup keeps pace, you just matched a far bigger model for a fraction of the cost using context and a test loop you already had. Either way, the cheaper lever earned its place next

8:35 to raw size. So, where does this leave you the next time a model gets something wrong? Take a side. For most everyday coding and writing tasks, before you pay for a bigger model, spend the compute

8:46 you already control. Give the model the right context. Let it check its own work against something real. That path is cheaper. It's faster to try and often it closes the gap on its own. Now steelman

8:58 the other side because it's real. Some problems are truly hard and new. The kind where a small model had no real chance. Those still reward the bigger model and the research agrees. And the

9:08 MIT limit we started with is about loss, not a wall on what models can eventually do. Bigger still matters. It just isn't the only move anymore or the first one. Come back to that invented retry line

9:20 from the very start. A bigger model gets that kind of thing wrong less often and it charges you every single time it answers. But a smaller model that can open the real file and check its own

9:30 claim against the code catches the same mistake for far less. The crowding the MID team measured doesn't fully go away. What changes is how cleverly you work around it. So that's the shift worth

9:40 keeping. Size still buys quality, but on a curve that charges more for every step for a reason we can finally see. The bigger lever most days is how you use the model, not how large it is. If

9:52 breakdowns like this are useful to you, subscribe. One clear explainer like this every week.