---
kind: concept
slug: intermittent-computing
title: Intermittent computing
summary: >-
  Running programs or neural networks on devices that lose power repeatedly, such as harvested-energy sensors. Each power-on period has a fixed energy budget, so progress must be saved and resumed after each outage. One paper so far, author-reported on a 2 KB microcontroller. Trade-off: a smaller network and extra saving of progress, with latency and accuracy that depend on the energy budget.
tags: [energy-harvesting, microcontroller, tinyml]
papers: ["2407.14514"]
related: [neural-architecture-search, knowledge-distillation, network-pruning, on-device-inference]
status: draft
updated_at: 2026-10-25
---

## Overview

Some devices take their power from light, vibration or radio waves. The supply
is weak and unstable, so the device runs in short bursts between power
failures. Each burst has a fixed energy budget, and any progress must be saved
to non-volatile memory and recovered after the next outage [arxiv:2407.14514
§2.1] [§2.3].

The invariant all variants share: a computation is cut into pieces that fit
one power-on period, and the state after each piece survives a power loss. The
open design question is how to pick the network and the schedule so that the
pieces fit the energy and the working memory [arxiv:2407.14514 §1].

This page is based on one paper card. Other approaches are not covered yet.

## Variants

### Intermittent-aware neural architecture search (iNAS)

The search baseline. A controller proposes a child network. For each child, a
design explorer picks how progress is preserved and how work is executed, and
a performance model estimates the energy per power cycle and the end-to-end
latency [arxiv:2407.14514 §4.1]. The paper names this method as its baseline
but does not give its own card here, so it is not summarised further.

### Accelerated intermittent NAS

The variant from [Accelerate Intermittent Deep Inference](/papers/2407.14514).
It keeps the iNAS search and changes three things [arxiv:2407.14514 §4.2]:

- **Distil and shrink a teacher first.** The teacher is MCUNetV1-Int2 in
  float16. The student is pruned by more than 80% of its parameters, its
  weights are shared, and its kernel, depth and channel dimensions are shrunk
  before the search [arxiv:2407.14514 §4.2] [§5.3].
- **A stronger controller.** The paper proposes an evolutionary or Bayesian
  controller in place of the RNN. It is not evaluated [arxiv:2407.14514 §4.2].
- **A solution dumper.** After the search, one C file and one header hold the
  weights and the network structure, using TI's DSPLib on the MSP430
  [arxiv:2407.14514 §4.2].

It also adds a **larger batch per power cycle**, called hyper-tile. Fine tiles
mean more data fetches, so the paper uses bigger tiles to do more work in each
power-on period [arxiv:2407.14514 §3.1] [§4.3]. No batch size is given.

The paper also describes a real-time scheduling framework with worst-case
execution time and deadline checks [arxiv:2407.14514 §3.1]. It gives no
schedulability test, so it cannot be implemented from the text alone.

## When to use which

| Situation | Use | Why |
|---|---|---|
| Harvested power with a few KB of SRAM and a network that must fit | Accelerated intermittent NAS | Reported to fit about 2 KB peak runtime memory on an MSP430FR5994 [arxiv:2407.14514 §5.1] [§5.5] |
| Accuracy matters more than latency, and a small latency cost is acceptable | Accelerated intermittent NAS | Author-reported accuracy gains over HW-NAS, and 12% more latency than iNAS on CIFAR-10 [arxiv:2407.14514 §5.4] [§5.6] |
| Smaller networks under intermittent execution | iNAS | The authors say iNAS is better for smaller networks [arxiv:2407.14514 §6] |
| Continuous power supply | Not this concept | The paper says earlier NAS assumed continuous power [arxiv:2407.14514 §1] |
| No large pretrained teacher can be run to distil from | Plan the search without distillation | The distillation step depends on a teacher, here MCUNetV1-Int2 [arxiv:2407.14514 §5.3] |
| Unknown energy budget per power cycle | Measure it first | The paper gives no energy budget, latency requirement or batch size [arxiv:2407.14514 §4.1] [§4.3] |

The paper reports accuracy on a PC and latency on the MSP430, in different
setups. Do not treat the two as one measurement [arxiv:2407.14514 §5.4] [§5.6].

## Implementation sketch

Reconstructed from the paper's description of intermittent execution. The
tile size is a free choice, and the paper gives no value [arxiv:2407.14514
§4.3]. The energy check is an abstraction; the paper does not say how it is
measured.

```pseudocode
# Intermittent execution loop  [arxiv:2407.14514 §2.1] [§2.3]
# Input: list of tiles (layer work pieces); non-volatile store (NVM)

def run_intermittently(tiles, nvm):
    # Resume from the last saved tile after a power loss  [§2.1]
    next_tile = nvm.load_progress()
    while next_tile < len(tiles):
        # Each power-on period has a fixed energy budget  [§2.1]
        if not energy_left_this_cycle():
            wait_for_power()
            continue
        # Compute one tile, then save its result before the next one  [§2.3]
        result = compute(tiles[next_tile])
        nvm.save(next_tile, result)
        next_tile += 1
    return nvm.load_result()
```

Bigger tiles (hyper-tile) do more work per power-on period and fetch less
often, at the cost of more working memory [arxiv:2407.14514 §3.1] [§4.3].

## Contradictions

None known across papers: only one card covers this concept. Within the one
paper, §3.2 describes storing weights as CSV files, while §4.2 writes a single
header file [arxiv:2407.14514 §3.2] [§4.2].

## Papers

- [Accelerate Intermittent Deep Inference](/papers/2407.14514): accelerated intermittent NAS for an MSP430 with about 2 KB of runtime SRAM. Author-reported; no official code.