If you are choosing a runtime for a microcontroller model, the honest answer is not "ours". It is "it depends on one property of your problem, and you already know which one it is". This post is the decision, laid out, using the numbers from our full head-to-head.
The question that actually decides it
Does your classification window slide?
That is it. Everything else is a secondary consideration. If your device makes a decision every N samples where N is much smaller than the window length — a wearable classifying activity every 20 ms over a 2.56-second window, a vibration sensor watching a motor, a meter tracking load — your windows overlap heavily, and a stateless runtime is throwing away almost all of its work on every call.
If instead your device wakes up, grabs one window, decides, and goes back to sleep, the overlap is zero and none of that applies.
Where each one wins
| Axis | Winner | Margin |
|---|---|---|
| Total flash for the same network | Atome LM EDGE | 4.64× (15,444 B vs 71,712 B) |
| Runtime RAM | Atome LM EDGE | 2.17× (3,072 B vs 6,656 B) |
| Cost per decision, sliding window | Atome LM EDGE | 27.3× vs CMSIS-NN |
| Accuracy, UCI HAR, leak-free, 5 seeds | neither | tie: 0.9095 vs 0.9097 |
| Latency, one-shot window | CMSIS-NN / TFLM path | 2.89× faster than ours |
| Swapping models without reflashing firmware | TFLite Micro | categorical — we cannot do it at all |
| Ecosystem, tooling, hiring | TFLite Micro | categorical, and not close |
The trade nobody mentions in the marketing
Our engine has no interpreter, which is where most of the 4.64× flash difference comes from. That is not free. A TensorFlow Lite runtime reads a FlatBuffer at boot, so you can ship a new model as data — over the air, per device, per customer. We compile the network shape in, so a new model is a new firmware image. If your product roadmap includes "we will retrain and push new models monthly", that is a real argument against us and you should weigh it above the byte count.
The streaming advantage has a boundary too, and it is sharp. It exists only while windows overlap. At stride 128 — non-overlapping — streaming costs 1.6× more than a single batch call, and it holds about 10 KiB of RAM for the state. On a part with 20 KB of SRAM that trade may simply not be available to you.
A decision table
| If… | Then |
|---|---|
| Flash is the binding constraint and the model is fixed at ship time | Atome LM EDGE |
| Continuous sensing, decisions far more often than once per window | Atome LM EDGE — this is the case it was built for |
| You must prove the deployed model matches the validated one, byte for byte | Atome LM EDGE — see verification |
| You will push new models over the air | TFLite Micro |
| One-shot inference, latency-critical | TFLite Micro over CMSIS-NN |
| Your team already knows the TensorFlow toolchain and the part has room | TFLite Micro. Tooling is a real cost and a 4.64× flash saving does not always pay for it. |
| You are choosing on accuracy | Neither. It is a tie, and picking on a tie is picking on noise. |
How to check this for yourself
Do not take a benchmark from a vendor page, including this one. Run your own, on your own data, with a subject-wise or chronological split, five seeds, and the same training budget for both arms. That is a day of work and it is the only version of this comparison that is about your product. We wrote down how we do it, including the ways we got it wrong first.
Questions
Should I use Atome LM EDGE or TensorFlow Lite for Microcontrollers?
Ask whether your classification window slides. If decisions are needed far more often than once per window, Atome LM EDGE costs 27.3× less per decision and 4.64× less flash. If inference is one-shot, or you need to push new models without reflashing firmware, use TFLite Micro.
Is one of them more accurate?
No. On UCI HAR with a leak-free subject-wise split over 5 seeds they tie: 0.9095 ± 0.0077 against 0.9097 ± 0.0154.
What is the biggest downside of the Atome LM engine?
You cannot swap models without recompiling firmware. The network shape is compiled in, which is where most of the size advantage comes from and also the main thing you give up compared to an interpreter-based runtime.