What is the difference between edge AI and embedded AI?

Edge AI describes where inference happens: on or near the device instead of in a remote data centre. Embedded AI describes how it happens: the model runs inside a resource-constrained embedded system with fixed memory, power and thermal limits. Most of our work is both: embedded AI running at the edge, inside existing equipment.

Which compute platform is suitable for edge AI?

It follows from the workload. Small, simple models with tight power budgets suit microcontrollers; efficient fixed-model inference suits an NPU; heavier or evolving models suit a GPU; fixed, deterministic pipelines suit an FPGA. We profile the workload first and choose from the evidence.

Does quantisation reduce accuracy?

It can. Integer quantisation typically has a small, measurable cost that quantisation-aware methods reduce further. We measure the accuracy impact on representative data and only accept a smaller model if it stays above the accuracy floor set in the workload definition.

Can the model run on the processor already in my system?

Sometimes. If the existing controller has spare compute and the workload is small, yes. More often the controller keeps handling I/O and control while a small added module runs the inference. The assessment establishes which case applies.

Embedded AI Engineering & Edge Inference

What embedded AI engineering covers

A model that performs well on a workstation is the starting point, not the result. Embedded AI engineering closes the gap between that model and a device with fixed memory, a power budget, an enclosure that traps heat and a service life measured in years. The work runs from workload definition to fleet updates, and every step is validated on the target hardware.

Workload definition

We start by writing down what the device must decide, how fast, on what signal, and what an error costs. A false alarm on a production line and a missed event on a security camera have different consequences, so the acceptable false-positive and false-negative rates are set before a model is chosen. This definition also fixes the latency, memory and power envelope the model has to fit.

Model selection and adaptation

Architectures are chosen for the target, not for leaderboard accuracy: a compact detector for an NPU, a small classifier for a microcontroller, a fixed pipeline for an FPGA. Adaptation covers training or fine-tuning on data that resembles the deployment, input resolution and pre-processing matched to the sensor, and removing capability the application does not need.

Quantisation, pruning and model compression

Quantisation to 8-bit or lower integer arithmetic is usually the largest single saving in memory and latency on embedded targets, and the largest source of accuracy loss if done blindly. Pruning and compression reduce model size further. We treat these as hardware-aware optimisation steps with measured accuracy impact, and we keep the trade-off visible: a smaller model that fails the accuracy floor is not an optimisation.

Post-training and quantisation-aware approaches, chosen by the accuracy margin available.
Structured pruning where the runtime can exploit it; unstructured pruning only when it translates into real speed.
Operator support checked against the target runtime before the architecture is fixed.

Latency, memory and power optimisation

End-to-end latency is measured from sensor input to system action, not model execution alone. Memory is measured as the working footprint with the real runtime, and power as continuous and peak draw under the real workload. Optimisation targets all three together, because improving one at the expense of another rarely produces a deployable system.

CPU, GPU, NPU and FPGA deployment

Each target has a different sweet spot. Microcontrollers suit small models with tight power budgets. NPUs give efficient fixed-model inference. GPUs suit heavier or evolving models. FPGAs suit deterministic, fixed pipelines with hard latency limits. Deployment work includes the runtime, driver and operator support each target needs; the hardware side is covered under AI hardware engineering.

Inference benchmarking

Benchmarks are run on the target device, in the target enclosure, with representative data. Results are reported with the firmware and model versions, operating conditions, dataset size, method and known limitations. Numbers measured on a development board with a fan are not used to make deployment decisions.

Computer vision, anomaly detection and sensor intelligence

Typical workloads include on-device object detection and event intelligence for existing cameras, anomaly detection on vibration, current and thermal signals from industrial equipment, and sensor fusion for field machinery. Our current investigations in these areas are described as R&D projects on the Technology page, labelled by maturity.

Offline inference and secure deployment

On-device inference keeps raw data local and works without a cloud round-trip, which matters for privacy, bandwidth and sites with unreliable connectivity. The deployed model is protected at rest and in transit, updates are signed and verified before installation, and the device can roll back to a last-known-good state. These controls are part of embedded and edge cybersecurity.

Fleet updates

Models change more often than hardware. The deployment path includes versioned model packages, staged rollout, telemetry to confirm behaviour in the field, and a recovery path. The firmware side of that path is described under embedded firmware and edge platforms; the full picture of a retrofit programme is under edge AI retrofit.

Related capabilities

Edge AI retrofit · AI hardware and electronics R&D · Embedded firmware and edge platforms · Embedded and edge cybersecurity · High-speed PCB and product engineering · All capabilities · How the edge stack works

Embedded AI Engineering for Real-World Hardware