The case for thinking at the edge

A great deal of modern artificial intelligence assumes a data centre. Models are large, compute is abundant, and the network connecting the two is fast and permanently available. Almost none of those assumptions hold on a platform operating in contested space.

This is not a preference or an optimisation. For defence autonomy, running intelligence on the platform is a structural requirement, and it constrains every engineering decision downstream.

Four reasons, in order of severity

• Availability. Links are jammed, saturated, blocked by terrain, or simply out of range. A system that stops thinking when the radio drops is a system nobody can plan a mission around.
• Latency. A control loop that waits for a network round trip is too slow for anything reactive. At the speeds involved, a few hundred milliseconds is the difference between avoiding an obstacle and hitting it.
• Bandwidth. Raw sensor data is enormous. Sending it off-platform for analysis is wasteful when it is possible and impossible when it is not.
• Exposure. Every byte leaving the platform is a byte someone can intercept, and every dependency on a remote service is a dependency an adversary can attack.

The moment a platform is most alone is exactly the moment it most needs to be capable.

What it costs to build

Deciding to run at the edge is easy. Making capable intelligence fit is the hard part, and it is where most of the engineering effort actually goes.

Onboard compute is bounded by weight, heat and power, and those three are linked. More capable compute is heavier and draws more current, which reduces endurance; it also produces heat, which must be removed, which costs weight again. Every watt spent thinking is a watt not spent moving. On a small platform, that trade is brutal and constant.

The disciplines that follow are unglamorous but decisive: designing and compressing models to run usefully in a small envelope; guaranteeing the loop completes on schedule every time rather than usually; sustaining performance without thermal throttling; and shedding non-essential work gracefully under load instead of falling over.

Determinism over peak performance

There is a temptation to optimise for the best-case number — how fast the model runs when nothing else is competing for the hardware. That figure is close to meaningless in a real system, where perception, navigation, control and communications all contend for the same silicon simultaneously.

What matters is the worst case: does the loop still close on time when everything is running at once and the platform is hot? A system that is usually fast and occasionally late is, for control purposes, simply unreliable.

The compounding benefit

Once a system genuinely does not need the link, several things improve at once. It stays useful when isolated. It decides at sensor rate rather than network rate. It exposes far less. And the bandwidth that does exist can carry conclusions rather than raw data — which is a better use of a scarce resource in any case.

This is why we settled the architecture early, in 2021, rather than treating it as something to retrofit. Decisions of this kind are extremely expensive to reverse once an entire stack has been built on the opposite assumption.