# Presence: distributed AI inference across ESP32-class nodes

> Source: <https://discuss.huggingface.co/t/presence-distributed-ai-inference-across-esp32-class-nodes/171823#post_2>
> Published: 2026-11-15 02:34:29+00:00

Loved the honesty of this write-up — and the one number that could change its conclusion is the one not measured yet: joules per completed query.

Here is why it might dominate. Your swarm run took 38.3 s against the baseline’s 10.1 s. On ESP32-class nodes that stay Wi-Fi-awake while waiting, the extra energy is mostly time, not tokens: the coordinator and the waiting nodes burn close to their listening draw for the whole window. The 2,935 extra tokens are the visible overhead; the 28 extra seconds could be the expensive part.

For that to hold, waiting draw must be a large share of active draw — usually true for connected nodes that cannot deep-sleep mid-query, but it is exactly what your setup can settle.

The check: power both runs from a metered supply, log total joules per query, and split the swarm’s energy into busy time versus waiting time using your own timestamps. If waiting comes in under roughly a fifth of the extra energy, this reading is wrong and tokens really are the cost.

If waiting does dominate, the headline result flips into something stronger: report confidence gained per joule, and let nodes sleep between coordination rounds. A swarm that wins on confidence per joule, measured at the battery, is a result nobody can argue with — and in our own small-robot battery work the delivered energy came in well under the pack’s label, so measuring beats trusting the datasheet.
