TL;DR:

  • Neural processing units (NPUs) are now shipping in mainstream IoT microcontrollers at the same price points as equivalent MCUs without AI acceleration — the Nordic nRF54L series, updated TI and Renesas parts, and NXP’s i.MX 9 line are leading examples
  • On-device inference at 2–10 TOPS is sufficient for audio keyword spotting, anomaly detection, image classification at low resolution, and predictive maintenance models — the common industrial and consumer IoT inference workloads
  • The toolchain question is now the main constraint: model compression, quantisation, and deployment to multiple vendor NPU architectures require more engineering effort than the hardware itself

The reference SoC list for IoT products has been shifting. A year ago, NPU integration was a differentiating spec in higher-cost modules — something you looked for in industrial gateways or vision-capable edge systems, not in the Bluetooth Low Energy microcontrollers that go into sensors, wearables, and connected appliances. In 2026, that assumption no longer holds.

NPU blocks are appearing in mainstream BLE and ultra-wideband IoT SoCs at price points that make on-device AI inference a baseline option rather than a deliberate architectural choice. The engineering question has moved from “should we use a chip with an NPU?” to “how do we deploy models to the NPU we’re already using?”

Nordic nRF54L: BLE + Axon NPU

The nRF54L series added the Axon neural network accelerator to Nordic’s established BLE microcontroller line. This is significant because Nordic chips are embedded in an enormous installed base of IoT products — fitness trackers, asset trackers, industrial sensors, building automation nodes. The design ecosystem (SDK, evaluation boards, production board layouts) is mature. Adding an NPU to this family means developers already comfortable with Nordic’s toolchain can add inference capabilities without switching architectures.

The Axon NPU in the nRF54L is designed for INT8 quantised inference at 2–4 TOPS — enough for:

  • Keyword spotting (always-on wake word detection from the microphone, processing on-chip without streaming audio off-device)
  • IMU-based gesture and motion classification (running inference on accelerometer/gyroscope data at low power)
  • Simple anomaly detection on sensor time series (temperature, vibration, current draw patterns)
  • BLE beacon data classification

The key power story is that the Axon NPU can run inference at substantially lower current draw than running equivalent workloads on the ARM Cortex-M33 core. For battery-powered devices where always-on sensing is required, this matters directly for battery life — you can run a keyword spotter or anomaly detector continuously without the MCU core waking for every sample.

TI MCUs with TinyEngine Integration

Texas Instruments has taken a different approach: rather than integrating a discrete NPU, TI’s updated MCU families support the MIT TinyEngine inference framework running on the main ARM cores, with hardware acceleration via the DSP and SIMD instruction extensions present in their Cortex-M33 and Cortex-A series parts.

This approach trades peak TOPS for flexibility. TinyEngine models can target any TI part with an appropriate core, and the memory and flash requirements are explicitly minimised to fit within the resource constraints of embedded MCUs. The tradeoff is power efficiency: DSP-accelerated inference on the main core draws more current than a dedicated NPU, making this less suitable for always-on battery use cases.

For mains-powered industrial IoT — PLCs, sensor nodes powered from the machinery they monitor, gateway devices — this works well. You get capable inference (predictive maintenance models, quality inspection, process parameter optimisation) without the NPU hardware cost premium.

Renesas RA8 and NXP i.MX 9

At the higher end of the IoT MCU market, Renesas’s RA8 series and NXP’s i.MX 9 line both include Arm Ethos-U series NPUs (Ethos-U65 and Ethos-U85 respectively), targeting 4–10 TOPS for edge vision and more complex inference workloads.

These are appropriate for:

  • Low-resolution image classification and object detection (manufacturing defect detection, people counting, occupancy sensing)
  • More complex audio processing (speaker identification, environment classification)
  • Multi-modal inference combining vision and sensor data

The price points for these parts are higher — typically in the $4–10 range in volume — but they sit in industrial module and gateway positions where the cost is justified by the workload.

The Toolchain Reality

The hardware is shipping. The toolchain for deploying to it is more complex than the vendor documentation implies.

Model compression requirements: Even at 4–10 TOPS, these NPUs run quantised INT8 or INT4 models. Full-precision float32 models from TensorFlow or PyTorch don’t run directly on the NPU. Quantisation-aware training or post-training quantisation is required, and the accuracy implications need validation for each use case. Audio and time-series models generally quantise well; image classification models lose more accuracy and need careful validation.

Vendor SDK fragmentation: Nordic’s Axon NPU uses Nordic’s nRF AI SDK (built on TensorFlow Lite for Microcontrollers). Renesas’s Ethos-U uses the Arm CMSIS-NN library and Vela compiler. NXP’s i.MX 9 has its own ML SDK. Models optimised for one NPU architecture don’t run on another without recompilation and often retraining. If you’re targeting multiple silicon vendors, this is real engineering effort.

Memory constraints: Even at the upper end, these MCUs have KBs to low MBs of RAM. Model size, activation memory, and input buffers all compete for this space. Model architecture choices (MobileNet variants, depthwise-separable convolutions, temporal convolutional networks for time series) matter as much as the NPU spec.

Deployment tooling: Edge Impulse, NanoEdge AI Studio (STMicroelectronics), and SynaptiCS’ model tooling are the main managed deployment platforms that abstract some of this complexity. They handle quantisation, vendor SDK targeting, and memory optimisation within a UI-based workflow. For teams without embedded ML expertise, starting here and working backwards to custom deployment as needed is a reasonable approach.

What This Means for IoT Product Design

For IoT product teams evaluating silicon in 2026:

NPU is now a tie-breaker, not a showstopper: If your two shortlisted parts are otherwise equivalent and one has an NPU, choose the one with the NPU. The incremental cost is small; the design space it opens — keyword spotting, anomaly detection, predictive maintenance — is meaningful.

Design your inference workload before choosing your model: Determine what on-device inference you actually need first. Keyword spotting from audio? IMU gesture classification? Temperature anomaly detection? The model requirements determine the TOPS and memory requirements, which determine which silicon tier is appropriate. Don’t specify a 10-TOPS NPU to run a 50-parameter decision tree.

Plan for toolchain time: NPU integration adds embedded ML toolchain work that many firmware teams haven’t done before. Budget for model compression, quantisation validation, and SDK integration — typically 2–6 weeks for a first deployment on a new NPU architecture.

Consider power budgets explicitly: NPU inference power draw varies significantly across vendors and use cases. Request vendor characterisation data for your specific model architecture at your target inference rate, and validate it on hardware before committing to a battery specification.

The Bigger Pattern

The shift from “optional AI accelerator” to “standard NPU in mainstream IoT silicon” has happened. What used to require a dedicated vision processor or ML accelerator module — keyword detection, vibration anomaly classification, gesture recognition — now runs on the same BLE microcontroller that handles connectivity and sensor interfacing.

The engineering effort is now mostly in software: models, toolchains, and deployment. That’s a much more manageable constraint than the hardware availability issue it replaces. But it’s still effort — teams treating the NPU as free capability they can add at the end of a project will be disappointed. Build the model pipeline alongside the hardware design, not after it.