Something has changed in wearables over the past two years, and it gets discussed surprisingly little given how much it reshapes the engineering. Single-sensor devices are becoming multi-sensor devices.
The first generation of fitness bands carried one accelerometer. Optical heart rate came next, then blood oxygen, temperature, ECG. Today it’s no longer unusual for one product line to run an ECG channel and a PPG channel at the same time. On the surface that reads as “a few more components”. Its effect on AI architecture is much bigger than most teams expect, because once the number of sensing dimensions goes up, where the data gets processed stops being an implementation detail and becomes the central architectural decision.
This piece is about one question inside that shift: in this class of device, why does a small specialised model beat a general large one? The answer isn’t in a FLOPS comparison table. It’s in the shape of the task.
The first constraint that breaks is latency
Start with the hardest limit: feedback delay.
The single-sensor era ran on a simple loop: collect, upload, analyse, review. You finish a run, the data syncs to a cloud endpoint, and you read a report the next morning. That pipeline is perfectly adequate for retrospective analysis, because a delay of several hours doesn’t change the conclusion.
It breaks the moment a device has to produce a judgement inside the event that produced the input. Take a concrete case: someone is partway through a training set, and the system needs to prompt an adjustment once they reach a fatigued state. If that judgement has to round-trip to a server, then even at two seconds the feedback lands after the set has ended. Feedback that arrives past the point of usefulness isn’t feedback at all.
That’s why the first layer of inference on a multi-sensor device has to run locally. Not because the cloud isn’t capable enough, but because physics says it can’t get there in time.
The second constraint is bandwidth, and it’s tighter than intuition suggests
Even where latency could be tolerated, transport itself becomes the bottleneck.
Here’s a fact that gets overlooked a lot: most wearables run over Bluetooth LE, whose real throughput is far below what the word “wireless” suggests. Sampling several physiological streams at once (ECG at several hundred hertz, PPG at tens of hertz) produces a lot of raw waveform. Sustaining that backhaul costs more power and more bandwidth than the link has to give.
That leaves two engineering options. Compress the signal into features on the device and send those, or run inference on the device and send only the result. The second is orders of magnitude smaller in payload. And note what’s driving the choice: not that the edge is more elegant, but that the data can’t be moved.
The third constraint is privacy, and it’s turning into a commercial variable
Physiological data is more sensitive than behavioural data. A heart rate trace doesn’t only say “someone is exercising”; it also reflects sleep, stress state and cardiac rhythm characteristics. Once that data leaves the device, it enters regulated territory.
For an enterprise this cuts two ways. First, where data sits directly affects compliance cost: cross-border transfer, storage liability, user consent, each with a real price attached. Second, “data never leaves the device” is becoming a sellable attribute in its own right, not just a technical choice. Consumer sensitivity to it is rising, and the regulatory direction is clear.
So on-device inference here isn’t purely a technical win. It’s a compliance strategy and a brand asset at the same time.
Which is why the specialised small model wins
With the constraints established, back to the question in the title. In this class of deployment, why does a small specialised model beat a general large one?
The answer is mildly counter-intuitive: not because the small model is more capable, but because the problem it has to solve is smaller.
A frontier model is built to cover a broad, open-ended range of tasks, and its capability comes from parameter count and training breadth. But in the wearable case the task boundary is narrow. The inputs are a fixed set of physiological signals. The outputs are a small, finite set of judgements: which phase the session is in, which mode to propose, roughly what it cost. That’s a closed problem with defined inputs, a limited output space, and a reference standard for the right answer.
On a problem of that shape, a small model trained against those signal characteristics will match a general model on accuracy while being orders of magnitude better on power, latency and memory footprint. Pointing a general model at a tightly bounded small task isn’t surplus capability. It’s misallocated resource.
There’s a decision criterion here worth flagging for anyone allocating budget: define the task boundary before you size the model. If the task can be specified cleanly (fixed input dimensions, limited output space), a specialised model returns more per unit of investment. If the task is genuinely open, say understanding a user’s free-text question, that’s when a larger model enters the conversation.
How this lands in a real architecture
To make that less abstract, here’s a shipping product that sits at the severe end of these constraints.
UniShape is a connected EMS training system whose hardware splits in two. The output side is a 30-gram generator driving the electrodes in the garment. The sensing side is a 4.2-gram ring carrying both ECG and PPG channels, measuring heart rate, ECG, blood oxygen, blood pressure trends, sleep and temperature. The point worth registering is that the ring is the only sensing device in the system. The generator and the garment measure nothing at all, and every physiological reading comes from that one ring. Both halves connect to the phone app directly over Bluetooth LE, in a star topology rather than a chain.
Its inference placement follows straight from the constraints above. The ring reads heart rate continuously through a session, and the app-side algorithm works out which phase the session is in. Then it proposes a matching stimulation mode. And here’s the decision that matters: having proposed it, the system waits for the user to confirm. It doesn’t change settings on its own. The reason is that optical heart rate is significantly noisier while you move than when you’re still, and letting an algorithm quietly shift output on a noisy signal is neither honest nor safe.
Three things follow from that example:
- Where inference sits depends on timing sensitivity. Judgements that need to land inside the event run on the device. Analysis you can review later stays in the cloud.
- The task boundary determines model size. “Which phase is this” is a finite classification problem. It doesn’t need a frontier model.
- Uncertainty should be surfaced to the user. When the input signal is noisy, handing the decision back to the person beats pretending the algorithm is confident.
A second mechanism runs alongside the first, and keeping the two apart is the whole point. Session modes step through three phases on their own (warm-up, working, cool-down), each with a different stimulation pattern. But the progression runs on a fixed timer and doesn’t read heart rate at all. So recommendations wait for a person, while schedules run on a clock. The benefit: even when the heart rate signal is unreliable mid-session, the rhythm of progression stays predictable.
Heart rate also drives a third job: estimating what the session cost in energy terms, including an estimate of excess post-exercise oxygen consumption. Both of those are estimates derived from heart rate, not measured values, and neither should be read as a clinical or therapeutic conclusion. The system is a fitness and wellness product, not a medical device: it holds no FDA clearance or approval, and nothing here is a claim about diagnosing or treating anything.
One further detail worth noting, because it generalises: the sensing side and the output side are separated by responsibility: the ring senses and doesn’t control, the generator delivers and doesn’t measure. That separation lets each half iterate independently, and it keeps “where did this data come from” answerable for the user.
Three questions for anyone allocating budget
If your organisation is evaluating an edge investment, these three are worth answering before the technical selection starts.
First, in your feedback loop, what counts as “in time”? If the answer is “same day”, the cloud is entirely sufficient. If it’s “right now”, the device is the only option. That answer determines the architecture, and it shouldn’t be discovered by an engineer halfway through.
Second, can you write your task boundary on one page? If you can, go specialised. If you can’t, spend the time defining the problem before spending money enlarging the model.
Third, is data staying on the device a cost or a selling point for you? If you only count it as cost, you’re probably undervaluing it commercially. If you only treat it as a selling point, you’re probably undervaluing the engineering.
The takeaway
Multi-sensor wearables haven’t made AI simpler. They’ve moved where AI has to sit.
For a decade the default answer was “data to the cloud, compute centralised”, and for retrospective analysis that answer still holds. But when a device has to respond inside the event that produced its input, inference has to follow the sensing, down to the place closest to the signal. That isn’t a rejection of cloud AI. It’s a correction to how we read the task: establish the boundary first, then decide where the compute goes.
And for tasks that are cleanly bounded, time-sensitive and data-sensitive, the answer is already clear: a specialised model, running on the device.
