Does less computation really mean lower cost?

Calling a model less often looks like good news. We expect fewer operations, less waiting and lower resource consumption.

But the mechanism that reduces those calls also has work to do. It prepares possibilities, evaluates options and decides which to apply. Sometimes the system surrounding the model takes on work the model no longer does.

One part of the computation may shrink while another grows.

An ADL experiment made this distinction visible. The number of model forward passes fell, but no saving in total measured time was established. The result raised a question: when we call a method cheaper, which part of the system are we looking at?

Choosing has a cost too

ADL treats the learning model separately from the mechanism that selects interventions on it. In experiment F2-041, the candidate method evaluated two proposed changes and chose the one that reduced training error more.

This provided more information before making a decision. Preparing and evaluating both proposals also took time.

Compared with the strong baseline, model forward passes fell by approximately 36 per cent. Meanwhile, the time spent by the Controller preparing and managing interventions rose by approximately 10.5 per cent.

We cannot subtract those percentages to calculate a total saving. One describes an operation count, the other the time spent in a particular component. Without knowing their shares of the same budget and how they were measured, they do not become a single rate of improvement.

The experiment established no saving in total measured time. Energy consumption was not measured either. Fewer forward passes therefore do not establish lower energy consumption.

Which task's cost are we comparing?

Considering only the resources a system consumes leaves the calculation incomplete. We also need to know what it achieves with them.

A method that performs fewer operations may produce a poorer result. Another that achieves higher accuracy may need more time to complete the same task. Comparing them requires a success criterion first.

In the ADL experiment, the target was an improvement of at least three percentage points in final accuracy against each of four baselines within the same one-second CPU budget. The observed difference against the strong baseline was approximately 0.09 percentage points. The predefined quality criterion was not met.

Fewer model forward passes did not change that decision. They were an interesting observation about operation count, but not, by themselves, a success in quality or total cost.

“More efficient” therefore needs a qualification: for which result, within which budget and against which comparison?

Work outside the calculation

Other operations may surround a model call: retrieving information, generating options, verification, record keeping or retrying a failed step.

They vary by system, but raise a common measurement question. Does the reported cost cover only the model's execution, or also the other stages needed to complete the task?

Both measurements have uses. Knowing the model's own cost helps improve that component. Knowing the cost of the result delivered to the user helps assess the entire workflow.

The important point is not to substitute one measurement's scope for the other's.

The ADL records did not identify which sub-operation caused the difference in Controller cost. The increase could not therefore be attributed solely to copying, preparing proposals or comparison. Observing the total difference did not mean its cause was known.

Keeping missing measurements visible

It is easy to leave a value out of a report when we cannot measure it. But that missing value is part of the decision too.

If we did not measure energy, we should not conclude that energy was saved. If we did not measure end-to-end cost, we should not extend a reduction in one component to the whole system. If the quality criterion was not met, an improvement in operation count should not replace it.

The approach to resource and cost reporting in the Nage AI OS and SEDIM white paper meets the same need for clarity: state the method, scope and unavailable information alongside the measured value.

Sometimes we begin improving a system by making it perform fewer operations. To continue, we need to see where that reduction makes a difference.

Enough measurement for the next decision

The ADL record does not establish that selection mechanisms are unnecessary. It shows why we also need to assess the cost of acquiring information for a decision.

Choosing a better intervention in one round may be valuable. Yet the time spent preparing that round may limit the progress achieved. Understanding this requires examining gain per intervention alongside gain per unit of time.

That distinction determines the next question:

Do the operations we perform less often actually let us achieve a result of the same quality with fewer total resources?

---

Source note: This essay draws on the F2-041 and F2-042 records used in the earlier ADL essay, within the source scope dated 15 October 2026. It reports no new experiment. The findings are limited to a small synthetic CPU task.

ADL research · The ADL experiment essay · On Nage AI OS and SEDIM