Batteryless intelligence tradeoffs

"They asked me to be smart, cheap, tiny, instant, and immortal. I told them to pick four, and even that was optimistic."

A Pragmatic AI Agent

This section is the synthesis point of the chapter. It assumes the harvesting and storage model of Section 63.1, the intermittent-execution tax of Section 63.2, and the run-time knobs of Section 63.3 and Section 63.4. Where those sections optimized within the batteryless regime, this one draws the boundary of the regime itself. It also connects back to the design economics of Chapter 59, because the decision to go batteryless reshapes every downstream choice about model size, precision, and duty cycle.

The core bargain: perpetuity for everything else

The single thing batteryless operation buys is perpetual, maintenance-free lifetime. A coin cell holds a fixed energy budget; when it drains, someone drives to the device and swaps it, and across a large fleet that truck roll dominates total cost of ownership. Harvesting removes the truck roll. Deployments that were economically impossible, sensors sealed inside concrete, glued to livestock, or scattered by the thousand across a forest, become possible because no one ever has to reach them again.

Everything the design gives up in return can be organized along four axes. Availability: the device is awake and useful only a fraction of the time, its duty cycle set by the harvest, not by the application's wishes. Latency: an event that arrives during a dark spell waits until enough charge accumulates, so worst-case response time is governed by the weather, not the clock. Accuracy: as Section 63.3 showed, the model slides down its energy-quality frontier when energy is scarce, so mean accuracy is a distribution, not a number. Complexity: checkpointing, nonvolatile memory management, brown-out safety, and profiled energy tables add engineering surface that a battery-backed device simply does not carry. The art is knowing which of these your application can absorb.

The tradeoff axes and how they couple

The axes are not independent; the storage capacitor couples them. A larger capacitor buys availability and shortens worst-case latency, because it rides through dark spells and holds enough charge to run the expensive model. But it costs board area, costs money, and, most subtly, costs cold-start time: a big empty capacitor can take minutes or hours of harvesting to first reach the brown-out voltage, during which the device is dead on arrival. Small capacitors wake fast and respond to bursts but brown out constantly, paying the intermittent-execution tax of Section 63.2 on every computation. There is a genuine optimum, and it moves with the harvest source.

A compact way to see the coupling is to write availability as a function of harvested power \(P_h\) and per-inference energy \(e\). If the device must accumulate \(e\) joules before each inference and the useful work rate is harvest-limited, the sustainable inference rate is

$$ r_{\max} = \frac{\eta\,P_h}{e + e_{\text{overhead}}}, $$

where \(\eta\) is end-to-end storage-and-conversion efficiency and \(e_{\text{overhead}}\) folds in checkpointing, leakage, and the sensing front end. The lesson is immediate: halving model energy \(e\) does not halve throughput unless \(e\) dominates the overhead. On many real nodes \(e_{\text{overhead}}\) is the larger term, so aggressive model compression past a point buys almost nothing, and the design effort is better spent shrinking leakage and sensor duty cycle. Knowing which regime you are in is the whole game.

def sustainable_rate(p_harvest_uw, e_infer_mj, e_overhead_mj, eta=0.6):
    """Sustainable inferences/sec given a steady harvest, in microwatts and mJ."""
    p_w = p_harvest_uw * 1e-6
    e_total_j = (e_infer_mj + e_overhead_mj) * 1e-3
    return eta * p_w / e_total_j

# Same 50 uW harvest, two very different overhead regimes:
for e_over in (0.2, 5.0):                       # low vs high fixed overhead
    for e_inf in (5.6, 2.1, 0.8):               # full / mid / tiny model
        r = sustainable_rate(50, e_inf, e_over)
        print(f"overhead={e_over:>3} mJ  model={e_inf:>3} mJ -> {r:6.2f} infer/s")
# When overhead is 5 mJ, shrinking the model from 5.6 to 0.8 mJ barely moves the rate:
# the fixed cost, not the model, sets the ceiling.

A decision framework: when the battery quietly wins

Batteryless is a means, not a virtue. Four conditions, taken together, make it the right choice. First, the deployment lifetime must exceed the practical shelf and service life of a battery, so that maintenance-free operation is the actual requirement rather than a slogan. Second, the ambient harvest must comfortably exceed the time-averaged load, with margin for the worst season, not merely the demo day. Third, the application must tolerate variable availability and latency, degrading gracefully rather than failing a hard deadline. Fourth, the value of the removed battery, across the whole fleet's lifetime including truck rolls and disposal, must outweigh the added engineering and the accuracy you concede. Miss any one and a small primary cell, or a rechargeable buffer topped up by a harvester (a hybrid, not a purist batteryless node), is usually the wiser design.

What you must never trade away

Some quantities look like they sit on the frontier but do not. Correctness of a committed result is one: the intermittent-execution discipline of Section 63.2 exists precisely so that a power failure never produces a silently wrong answer, only a delayed one. Calibrated uncertainty is another. A batteryless model that degrades its accuracy with the light must also degrade its confidence honestly, or a downstream system will trust a dusk-time guess as much as a noon-time measurement. This is why the calibration and conformal tools of Chapter 18 are not optional garnish on a batteryless device but load-bearing structure: the reported uncertainty is what lets the fleet reason correctly about a stream whose quality breathes with the weather. Trade accuracy freely; never trade away the honesty of the number that says how accurate you were.

from eh_sim import Node, HarvestTrace       # illustrative API

node = Node(cap_uf=100, v_min=2.4, v_max=3.6,
            checkpoint_mj=0.5)
node.load_configs(energy_table)             # your profiled frontier
report = node.run(HarvestTrace("indoor_office.csv"),
                  workload=classifier, deadline_ms=200)
print(report.availability, report.p95_latency_ms, report.mean_accuracy)

What's Next

In Section 63.6, we descend from these design tradeoffs to the systems and reliability constraints that make or break a batteryless deployment in the field: nonvolatile memory wear, brown-out and cold-start behavior, clock and timekeeping across power failures, and the failure modes that only appear after a device has died and revived ten thousand times. The tradeoffs of this section set the targets; the next section is about actually hitting them without the device quietly corrupting itself over a decade of intermittency.