“Runs on the edge” has been stretched until it means almost nothing. Vendors say it about models that need a Raspberry Pi, a phone, or a cloud fallback. Here is a five-point test you can hold any on-device-AI claim to — including ours — so you can tell marketing from engineering in about a minute.
The five questions
- Does it fit the RAM? Not “after streaming from an SD card” — does the model plus its activations and cache fit the chip's SRAM? RAM, not parameter count, is the real limit.
- Does it fit the flash? The packed weights plus the engine code, under the part's flash size.
- Is it heap-free? Runtime malloc on an MCU means fragmentation and mid-inference out-of-memory. Static buffers, or it does not count.
- Is it reproducible? Can you clone a repository and regenerate the numbers, or do they live only in a slide deck?
- Is it measured, not estimated? Real build sizes and parity tests, or hand-waving and round numbers?
Scoring Atome against its own checklist
Fairness means applying the test to ourselves. RAM and flash fit: measured per-configuration in the repository's RAM_TABLE.md, from a real Cortex-M3 build. Heap-free: yes, fixed static buffers, about 2.6 KB of .text. Reproducible: clone the repo, run the 146 tests and the scripts. Measured: bit-exact Python-to-C parity to 3.7×10⁻⁷. Four of five, with receipts.
The one it fails honestly
The fifth box has a caveat we will not paper over: “measured on physical silicon.” Atome's deployment numbers are QEMU Cortex-M3 measurements, not a bench with a power meter on a real board. That is the next box to tick, and we are not going to check it before it is true. Hold every vendor — us included — to the same five questions, and treat a missing answer as a “no” until proven otherwise. The point of the checklist is not to crown a winner; it is to make “runs on a microcontroller” mean something again.
How to apply the checklist in practice
The checklist is most useful as a set of questions you put to a vendor or to your own team, with a simple rule: a missing or hand-wavy answer counts as a no. Ask for the peak RAM and flash on a named part, not a parameter count. Ask whether the engine allocates at runtime, and if so where the bound is. Ask for a repository you can clone and a command that reproduces the headline number. Ask whether the deployment figures came from a real build or an estimate. Each question has a concrete, checkable answer, and the absence of one is itself information. The goal is not to embarrass anyone; it is to convert a vague marketing claim into a small number of verifiable facts.
Why we hold ourselves to it too
It would be easy to write a checklist that conveniently scores ourselves five out of five. We did not, because the point of the exercise is trust, and trust comes from admitting the box you have not ticked. Atome clears RAM fit, flash fit, heap-free, reproducible and measured — four of five with receipts in the repository — and openly fails the fifth, physical-silicon measurement, because the numbers are QEMU Cortex-M3 and we will not present emulation as silicon. Publishing the gap is the whole point: a checklist you always pass is a marketing device, while a checklist that can fail you is a tool. Use it on us, and use it on everyone else.
Red flags that should make you skeptical
A few patterns reliably signal that an edge-AI claim will not survive contact with a real microcontroller. Watch for parameter counts quoted with no memory figure, because parameters without bytes hide the constraint that actually matters. Be wary of demos that turn out to run on a Raspberry Pi or a phone while being described as “on the edge,” since a Linux computer with gigabytes is a different category of machine. Treat “estimated” or suspiciously round numbers with caution, especially when no repository or build output backs them. And be skeptical of any claim of silicon performance that cannot point to a measurement on a named part. None of these red flags proves bad faith — sometimes they are just loose language — but each one is a prompt to ask the specific, checkable question underneath it before you build a roadmap on the answer.
Bottom line
Treat “runs on a microcontroller” as a claim to be tested, not a phrase to be trusted. Ask the five questions — RAM fit, flash fit, heap-free, reproducible, measured — demand a named part and a clonable repository, and read any missing answer as a no. Applied honestly the checklist puts Atome at four of five, with the silicon-measurement box openly unticked. That is the standard the whole field should be held to, ourselves included, because a test you can fail is the only kind worth running.
Frequently asked questions
How do I know if an LLM really runs on a microcontroller?
Check five things: it fits the chip's SRAM, it fits the flash, it is heap-free, the numbers are reproducible from a repository, and they are measured rather than estimated. A missing answer should be read as a no.
Does Atome lm pass its own edge-AI checklist?
On four of five points yes — RAM fit, flash fit, heap-free, reproducible and measured. The fifth, physical-silicon measurement, is not done yet: the numbers are QEMU Cortex-M3, and we say so.