Large AI models invite the SUV comparison when a routine job gets far more computing power than it needs. There is comfort in knowing the biggest option is there, even for a job a less demanding system could do well. But the analogy has a technical problem. Parameter count is a poor fuel gauge. A smaller model can use more energy to finish a task, especially if it keeps getting the task wrong. The case for restraint has to survive that fact.
I still think the habit deserves scrutiny. A powerful model should earn its place as the everyday default. Being at the top of a menu is a poor reason to use it for every job.
Model size is a poor energy meter
Fabian Reichwald and his colleagues compared more than 70 small language models across 5 task benchmarks for a paper published at IJCAI 2026. Smaller did not automatically mean more efficient. Spending more energy did not guarantee better performance either. The researchers found tradeoffs that depended on the task and the model.
A buyer who chooses the smallest number on a spec sheet could still end up using more energy.
A model’s total parameters do not tell us how much of it runs for each request. A mixture-of-experts system, for example, uses selected portions of a larger model. Hardware and the way requests are served also matter. Then there is the answer itself. A system that produces a long reasoning process may do far more work than one that reaches an adequate result quickly.
Even within one kind of work, the things that affect energy use can change. A September 27 preprint by Negar Alizadeh, Nishant Saurabh and Fernando Castor examined 25 open models for code completion. The length of the input and the output affected energy use in different ways across the tested jobs. Smaller and compressed models often offered good tradeoffs, but the paper does not name a winner for all code tasks, much less every other use of AI.
Although these findings limit the SUV analogy, a buyer still needs evidence that extra capacity helps with the job at hand. We should be just as wary of claims that a small model must be greener as of claims that a large one must be better.
Count the work that gets finished
The strongest defense of a powerful model is also the most practical: it may get something right that a weaker model cannot.
Suppose a smaller model returns a faulty answer and needs several attempts before the user can use it. A stronger model that gets it right at once could be worth its greater demands per call. That is a hypothetical comparison, not a finding about every model pair. It is enough to show why counting a single request can be the wrong way to judge a completed job.
The full cost includes fixing mistakes and checking whether the answer is usable. A business cannot claim to have saved resources with its model if its staff must spend more time fixing the output. Energy is one part of the decision, and the work still has to meet its purpose.
That leaves plenty of room for simpler systems. Finding a date in a routine document is a different job from tracing the cause of a tough software failure. The question is whether the stronger model gives enough of a better answer to be worth using. An app with a narrow job can test that against samples of the work it receives.
Routing offers one way to make the choice without asking the user to make it every time. In a September 19 preprint, Muhammad Abdur Rab Siddiqui and colleagues trained a system to choose among models using measured energy and performance. Their work addresses both mistakes: spending heavily on easy questions and assigning hard questions to models that cannot answer them adequately.
The paper’s main energy comparisons exclude the controller that selects the answering model. Choosing a model takes computing power too. An improvement in answer energy must therefore be checked against the cost of making the choice before anyone promises the same saving for the complete service.
Both papers are preprints, so these are early findings. They suggest a better way to choose, without settling what every company should use tomorrow. A team can test how much energy a job takes to finish to the right standard, including any extra work caused by a cheaper first attempt.
Price alone cannot settle it either. A low API bill is welcome, but a commercial price is not a direct reading of electricity consumption. A product team claiming to save energy needs proof that it does.
Defaults decide what gets used
The customer should not have to learn all of this to get through a workday. That is part of what software is supposed to do for people.
A product team can:
- Begin with the tasks it sees most often.
- Set a quality requirement.
- Test less demanding alternatives.
- Watch where those alternatives fail and preserve access to stronger models.
Even if a system saves resources on average, it has not found the right default if it repeatedly fails a group of users.
There are also good reasons to leave the choice visible. Someone who uses the tool every day may know when a request will be hard. A setting that favors lower resource use should let that person ask for more power and explain what changes. Restraint becomes easier to accept when it does not trap people in a failing process.
Buying for a rare requirement and using the same capacity for everything can be convenient. Software gives us a choice that the vehicle in the driveway cannot offer: the system can change what it uses from one task to the next.
The test should be the ordinary job that returns all day, not the spectacular demonstration that sold the product. If the default needs a lot of computing power to do that ordinary job well, there should be evidence for it. If less will do, the product should make less easy to use. The difficult request can still have all the help it needs when it arrives.
