On-Device & Embedded
On device and embedded is the most constrained runtime in the stack, and in some ways the most interesting. Inside a sensor or wearable, firmware and tiny models must fit within kilobytes of memory and the smallest sip of power. Working here protects privacy and survives a dead network, but it demands a discipline of efficiency that shapes everything from how data is filtered to which models can run at all. The constraints are the design.
On-Device & Embedded
The constrained runtime
Kilobytes and microwatts
Embedded software runs on chips with a tiny fraction of the resources of a phone, let alone a server. Memory is measured in kilobytes and power in the smallest increments. This is the environment where firmware filters raw signal and, increasingly, where small models interpret it, all within a budget that leaves no room for waste.
Why run here at all
Privacy and independence
Processing on the device keeps raw data from ever leaving it and keeps a feature working without any network. For movement and physiological data, both benefits are substantial. The reward for accepting severe constraint is software that is private by default and reliable in the basement gym or the remote trail.
Designing within limits
Efficiency as a first goal
Embedded work pushes efficiency to the front of the design process. Models are shrunk through quantization and pruning, architectures chosen for how cheaply they run, features weighed against the energy they cost. This is a different discipline from cloud development, where designing within kilobytes is the starting constraint rather than an afterthought.
A moving boundary
What fits keeps growing
As dedicated low power chips grow more capable, the line of what can run on a device keeps moving outward. Tasks that needed a server a few years ago increasingly fit on a wearable. This shifting boundary steadily expands what can be delivered privately and reliably, without the data ever leaving the body.