AI / ML Development

TinyML: Bringing AI to the Smallest Devices

Category
AI / ML Development
Read Time
9 min read
Published
August 25, 2025
Status
Published

TinyML runs machine learning on microcontrollers with kilobytes of RAM and milliwatts of power. The constraints are severe enough that most mainstream ML practice simply does not apply.

TinyML is machine learning that runs on microcontrollers — parts with kilobytes of RAM, no operating system, and a power budget measured in milliwatts. It is the smallest end of edge AI, and the constraints are severe enough that most of what works in mainstream machine learning simply does not apply.

The appeal is straightforward. A device that can classify what it is sensing does not need to transmit raw data, which means it can run for years on a coin cell, respond in milliseconds, and keep working with no network at all.

This guide covers what actually fits on a microcontroller, the memory constraint that decides everything, the frameworks worth using, and the applications where TinyML delivers value that no other architecture can.

Definition

What Makes TinyML Different

TinyML is not simply a smaller version of edge AI. The hardware class changes the rules of the problem.

Cloud MLEdge AI (SoC)TinyML (MCU)
Memory for the modelGigabytesHundreds of MBTens to hundreds of KB
PowerHundreds of watts1–30 WMicrowatts to milliwatts
Operating systemFullLinuxNone or a small RTOS
ArithmeticFloat32Float16 or int8Int8, sometimes lower
Typical latencyNetwork-boundMillisecondsMicroseconds to milliseconds
Unit costPer-query billingTens of dollarsA few dollars

The last row is what makes TinyML commercially interesting. It puts inference into products where a Linux-capable module would never be economically or thermally viable — disposable sensors, consumer devices at volume, and anything that must last years on a battery.

The Real Constraint

RAM Decides What Is Possible

The most common misconception in TinyML is that model file size is the limiting factor. It is not. Weights live in flash, which is comparatively plentiful. The binding constraint is peak activation memory — the working RAM needed to hold intermediate results as data flows through the network.

A model that occupies 80 KB of flash may require 200 KB of RAM at its widest layer. On a part with 256 KB total, shared with the application, networking stack, and sensor buffers, that model does not fit regardless of how small the file is.

Design for the widest layer
Peak memory is set by the largest single intermediate tensor, not by the average. Reducing input resolution or adding an early pooling stage often halves peak usage at negligible accuracy cost.
Quantise to int8 as a baseline
Eight-bit integer arithmetic reduces both weights and activations by roughly four times versus float32, and most microcontrollers execute integer operations far more efficiently. This is the single largest win available.
Budget for everything else on the part
The model shares RAM with the application, stack, sensor buffers, and any communications stack. Allocating the whole device memory to inference on paper is how projects discover the problem late.
Prefer good features over deep networks
Well-chosen signal processing — spectral features, statistical windows, filtered envelopes — lets a very small classifier succeed where a larger raw-input model would not fit at all.

In TinyML the question is never how accurate a model can be. It is how accurate it can be inside the memory you actually have left.

Capability

What TinyML Can and Cannot Do

Being realistic about the boundary saves a great deal of wasted effort.

1

Works well: motion and gesture classification

Accelerometer and gyroscope data is low rate and highly structured. Distinguishing walking, running, falling, a machine cycle, or an animal behaviour is a well-solved TinyML problem that runs comfortably in a few tens of kilobytes.

2

Works well: keyword spotting and sound classification

Detecting a wake word, glass breaking, a smoke alarm, or an abnormal machine sound. Audio is converted to a spectrogram first, turning the problem into small-image classification that fits comfortably on modern parts.

3

Works well: anomaly detection on sensor streams

Learning what normal vibration, current, or temperature behaviour looks like and flagging deviation. Because it needs only normal data to train, it avoids the hardest part of most industrial ML projects — collecting examples of failures that are, by definition, rare.

4

Works with care: low-resolution vision

Presence detection, simple object classification, and person counting at small input sizes are achievable on parts with an NPU or generous RAM. Anything requiring fine detail, many classes, or high frame rates belongs on more capable edge AI hardware.

5

Does not work: large models and open-ended tasks

Language models, general object detection across many classes, high-resolution segmentation, and on-device training of anything substantial are outside the class. Attempts to force them produce either a model that does not fit or one whose accuracy is too low to be useful.

Tooling

Frameworks and the Development Workflow

The TinyML toolchain has matured considerably, and the practical workflow is now fairly standard.

  • TensorFlow Lite for Microcontrollers — the most widely supported runtime, with a small interpreter designed for parts without an operating system.
  • Vendor-specific runtimes — silicon suppliers provide optimised libraries that map operators onto their DSP or NPU. These typically outperform generic runtimes substantially on their own hardware.
  • End-to-end TinyML platforms — tools that handle data collection, feature extraction, training, and deployment to a specific board. Excellent for getting to a working prototype quickly.
  • Classical machine learning — decision trees, random forests, and logistic regression remain highly competitive at this scale, run in a fraction of the memory, and are far easier to reason about. They deserve to be tried first rather than treated as a fallback.

The workflow runs: collect representative data from the actual sensor and mounting, extract features, train and evaluate on a workstation, quantise with representative calibration data, convert to the target runtime, then profile on hardware. The final step is the one teams most often skip and most often regret.

Practice

Getting TinyML to Work in a Real Product

1Collect data from the production sensor and mounting
Data gathered from a development board on a desk does not represent a sensor bolted to a machine. Mounting stiffness, orientation, and enclosure all change the signal, and a model trained on the wrong data fails silently in the field.
2Try a classical model first
A gradient-boosted tree on good features frequently matches a neural network at this scale while using a fraction of the memory and being far simpler to validate.
3Cascade cheap detection ahead of inference
Use a threshold or interrupt to wake the classifier rather than running it continuously. This pattern usually saves more energy than any model optimisation, because the processor spends almost all its time asleep.
4Measure real current draw on hardware
Calculate the energy per inference and per duty cycle with an instrument, not a spreadsheet. Battery life estimates built on datasheet averages are consistently optimistic.
5Validate quantised accuracy, not float accuracy
The number that matters is what the int8 model achieves on the target, using representative calibration data. Reporting float accuracy from the training notebook describes a model that will never ship.
6Ship a way to update the model
Field data always differs from training data. Without a working OTA update path, the first model deployed is permanent — and the first model is rarely the right one.

Because the device transmits conclusions rather than raw signals, TinyML is also one of the most effective forms of IoT data reduction available — the bandwidth saving is a direct consequence of the architecture rather than an added optimisation.

FAQ

Frequently Asked Questions

What is TinyML?
Machine learning that runs on microcontrollers with kilobytes of RAM, no operating system, and power measured in milliwatts. It lets a device classify what it senses locally, so it can respond in milliseconds, run for years on a small battery, and work with no network connection.
What limits model size in TinyML?
Peak activation memory rather than model file size. Weights sit in flash, but intermediate results need working RAM, and a model occupying 80 KB of flash can require 200 KB of RAM at its widest layer — shared with the application, stack, and sensor buffers.
What can TinyML actually do?
Motion and gesture classification, keyword spotting and sound classification, anomaly detection on sensor streams, and low-resolution vision on parts with an NPU. It cannot run language models, general multi-class object detection, high-resolution segmentation, or meaningful on-device training.
Does TinyML save battery or consume it?
It saves battery in most designs, because transmitting data costs far more energy than computing on it. The efficient pattern is cascaded: a cheap threshold or interrupt wakes the classifier, so the processor sleeps almost all the time and inference runs only when something has happened.
Do you always need a neural network for TinyML?
No, and often you should not. Decision trees, random forests, and logistic regression on well-chosen features are highly competitive at this scale, run in a fraction of the memory, and are much easier to validate. They are worth trying before a neural network, not after.
Why does a TinyML model perform worse after deployment?
Usually because training data came from a development board rather than the production sensor and mounting. Mounting stiffness, orientation, and the enclosure all change the signal. The second most common cause is validating float accuracy instead of the quantised int8 model that actually ships.
Wrapping Up

Conclusion

TinyML makes intelligence affordable at the smallest scale, which is exactly where connected products are most constrained. A few dollars of silicon, a coin cell, and a well-chosen model produce devices that decide locally, transmit rarely, and last for years.

Success depends on respecting the constraint that governs everything: available RAM at the widest layer. Design for that, engineer good features rather than deeper networks, cascade cheap detection ahead of expensive inference, validate the quantised model on real hardware, and keep a route open to update it. Within those limits, TinyML is remarkably capable — and outside them, no amount of optimisation will help.

About MetaDesk Global

Engineering the Next Generation of Connected Products

MetaDesk Global helps startups and enterprises develop intelligent connected products that combine embedded systems, Industrial IoT, Edge AI, and cloud technologies. Our expertise includes:

Industrial IoT (IIoT) Solutions Embedded Firmware Development Edge AI Development Predictive Maintenance Systems PCB Design IoT Gateway Development Cloud Integration OTA Firmware Updates AIoT Product Development End-to-End Product Engineering

From hardware design to AI-powered industrial platforms, we build scalable solutions for the next generation of connected products.

Start Your Project

Building a Connected Product?

We design IIoT sensor networks, Edge AI pipelines, and secure cloud platforms — from prototype to production.

Request a Free Quote →