From 10.4 times to 3.3 times
The energy gap between the same two models narrows from 10.4 times to 3.3 times when the measurement schedule changes. That is the LightGBM–CNN-1D comparison in Ericsson Research's handover-prediction preprint. The first figure comes from continuously repeated inference; the second includes idle intervals. The architectures stay the same. What changes is how time without inference enters the processor's energy accounting.[1]
That difference is particularly visible for the cheaper model. Finishing inference early does not eliminate all processor energy consumption before the next measurement arrives. My purchasing criterion here is to assess completed work and waiting intervals under the same operating schedule. A continuous test describes cost under sustained load; a periodic task's energy budget also includes idle time. Savings per invocation depend on how frequently the job runs. A different idle-power floor or finer energy measurement could also change the magnitude of that ratio.[1]
The other boundary is work performed before the model runs. Feature preparation accounts for approximately 44 percent of LightGBM's median pipeline latency in the study. Timing only model execution leaves out the work preparing its input. The comparison includes preprocessing, model execution and postprocessing in energy and latency. The cheaper-model decision concerns the advantage remaining after preparation is paid for, rather than the size of a model file alone.[1]
The hardware inside the 40 ms boundary
The task's clock is 40 ms, the interval between cellular measurements. Researchers use the 99th-percentile latency rather than an average. All eight models clear that deadline on the tested server. Reported F1 is 0.974 for LightGBM and 0.914 for CNN-1D. The neural model is therefore not excluded for missing its deadline in this experiment: the tree model leads on both reported accuracy and estimated energy. The study does not demonstrate a late inference on a phone.[1]
The hardware boundary is explicit: the experiment uses a 36-core Xeon server CPU. Energy is estimated from CPU utilization sampled every 50 ms rather than read from hardware energy counters. The data also comes from simulation of one urban Santa Clara scene. I would not convert the 3.3-times result directly into phone battery life. Handset silicon, idle behavior and different mobility patterns need not preserve that ratio. The researchers identify the absolute energy values as estimates.[1]
For me, the operating decision carries both boundaries: feature preparation is charged, and idle intervals remain in the energy budget. The study's short sequence and simple handover rule favor the tree model; a longer or different task need not favor the same architecture. Comparing the same task, invocation interval and full pipeline on the target device makes the source of a saving intelligible. The denominator for hardware selection is the job's actual execution schedule.[1]