Intelligence that runs on the device, not on a subscription.

Why put a model on the device at all

Sending everything to a server is simpler to build and often the right answer. But there are situations where it is the wrong one, and they are common enough to matter.

• Latency. The response has to happen in milliseconds, and a round trip does not fit.
• Connectivity. The device is somewhere with poor, intermittent or expensive coverage.
• Data volume. A vibration or audio stream is far too large to transmit continuously, but the conclusion drawn from it is tiny.
• Power. On battery devices the radio is usually the largest consumer. Deciding locally and transmitting rarely can extend life dramatically.
• Data residency. The raw data should not leave the site, for commercial or regulatory reasons.

What actually constrains the work

A microcontroller has kilobytes where a server has gigabytes. That single fact reshapes everything.

• Memory. Model weights and the working buffers have to fit in available flash and RAM alongside the rest of the firmware.
• Inference time. The model must finish well inside the sampling interval, leaving room for everything else the device does.
• Numerical precision. Quantising to integer arithmetic is usually required and always changes accuracy. How much has to be measured, not assumed.
• Power per inference. On a battery device, how often inference runs is a design parameter, not an afterthought.
• Preprocessing cost. Feature extraction, filtering and windowing often consume more cycles than the model itself.

These constraints tend to reshape the model rather than the other way round, which is why the hardware, firmware and model work belong in the same conversation from the beginning.

How we help

• Feasibility on your data. Before any hardware commitment, we establish on recorded data whether the signal supports the goal, and what accuracy is realistic.
• Hardware selection or design. Choosing a part with the memory, compute and power profile the application needs, or designing the board when nothing off the shelf fits.
• Model development and compression. Building or adapting a model, then quantising and pruning it to fit, with the accuracy cost measured at each step.
• Firmware integration. Acquisition, preprocessing, inference scheduling and the rest of the device’s behaviour, built as one system. See embedded firmware development.
• On-device measurement. Inference time, memory headroom and current draw measured on the real hardware, not estimated from a datasheet.
• Update path. Models change. Deployed devices need a safe way to receive new ones. See device security and OTA updates.

Where the honest answer is no

If the task needs a large model, edge deployment on a microcontroller may simply not be possible, and a more capable edge processor or a cloud split is the right architecture. If you have no recorded examples of what you want to detect, the first project is data collection, whatever it gets called. And if a well-chosen threshold or a filter solves the problem, that is a better engineering answer than a model: cheaper, explainable and far easier to justify to an auditor.

What you receive

The trained and compressed model, the firmware integrating it, measured performance on the target hardware covering accuracy, timing, memory and power, and the documentation needed to retrain and redeploy without us.

Related

AI-enabled IoT development for the system view. Battery and power engineering where inference cost meets battery life. Sensor selection, because the model can only be as good as the signal.