The AI layer inside physical products
Everyone is looking up.
The opening is underneath.
The AI everyone is watching lives in data centres. The AI that has to live inside a product — the chip in a car, in an oven, in a factory sensor — is a different problem, and almost nobody serious is solving it. That is the layer MicroQuant builds for.
Built for
Vehicles
Appliances
Industrial sensors
Consumer devices
↑everyone is looking up
This is the layer MicroQuant works in.
No cloudthe model runs inside the product, with no network
Same answerevery output matched the reference result bit for bit
Real siliconmeasured on the board, not estimated or simulated
Open evidenceevery measured cell is published and downloadable
Why now
The top is crowded.
The bottom is wide open.
Investors, the press and companies are all looking in the same direction: ChatGPT, Copilot, the large models, the agents. That is where the noise is. While everyone fights over that layer, the one underneath is practically empty of serious competition — and it is where the margin is still intact.
Where the noise is
Large models, copilots and agents. Enormous capital, enormous competition, and a cost per answer that somebody still has to pay.
Where the products are
Every physical product is getting a chip that has to decide for itself: a car, an oven, a factory sensor. It cannot call a data centre for every decision, and often it has no connection at all.
Where the competition is not
That layer has no crowd. The tooling is fragmented, most of it is locked to a single chip vendor, and the margin has not been competed away. MicroQuant is not locked to anyone: the same compiler already produces firmware for Espressif and Arm Cortex-M parts from the same model file.
There is a race down there, and it can be led. Not in five years. Now.
What MicroQuant demonstrates is that the technology to lead it already exists. It runs today, on real silicon, measured side by side with the industry standard runtime on the same board.
In plain terms
Your model.
On the chip you already ship.
A model that would normally need a server has to fit into a few hundred kilobytes and answer in milliseconds, with no network behind it. MicroQuant compiles that model into plain C that drops straight into the firmware: smaller, quicker, and giving the same answer as the model you tested.
It stays in the product
No cloud round trip and no data leaving the device, so it keeps working with no connection. Privacy and response time stop being a trade-off.
It fits, and it is quicker
The same model takes less flash and less memory, and each inference takes less time than the industry standard runtime measured beside it on the same board. On an Arm Cortex-M part the whole firmware links about four times smaller than the same model on the standard runtime.
It gives the same answer
Accuracy is measured on the complete official test set, not a sample, and every output matched the reference result bit for bit.
You can check all of it
Every figure we publish is downloadable cell by cell, with the campaign that measured it and the evidence tier behind it.
If a product has a microcontroller in it, this is the layer that lets it decide for itself — and it is the layer we build for.
Customer-specific GA · available on demand
Technical detail
Everything below is the engineering record.
The rest of this page is written for engineers, and for anyone who would rather check the claims above than take them. It is not a summary: it is the measured evidence, the exact support boundary, how a delivery is contracted, and how a model becomes firmware.
MicroQuant v1 turns bounded, statically shaped integer graphs into deterministic ABI-v6 C. The promoted schemes are W8 and W4: per-channel int8 and int4 weights, explicit limits, caller-owned workspace, and no runtime model parser.
MicroQuant compilerMQ-V1
ABI
6/6
compiler / runtime
W8promoted scheme
No heapruntime execution
- Measured resultsBoard measurements against the industry standard runtime, and every model family we measured.→
- What is supportedThe operators, formats and limits inside the contract, and what happens to anything outside it.→
- How delivery worksWhat a customer-specific engagement binds, and what each delivery profile is allowed to carry.→
- Integration pathFrom a model file to generated C, with every boundary testable on its own.→
256maximum graph operators
1–4graph inputs
1–4graph outputs
256 KiBmaximum caller workspace
Current-source result — measured on the admitted board
Smaller firmware.
Faster inference.
MLPerf Tiny Speech Commands v2 DS-CNN measured on an ESP32-S3 at 240 MHz. Every MicroQuant cell is measured beside LiteRT for Microcontrollers, portable and with ESP-NN, built from the same model file in the same campaign.
Keyword-spotting model and task from the MLPerf Tiny suite by MLCommons, measured by MicroQuant. Result not verified by MLCommons Association.
Both sides of every comparison are measured here, in one campaign on one admitted board. These are development results, not a customer acceptance record.
Speech recognition benchmark
Accuracy over all 4,890 test clips, speed measured on the board itself, and the exact memory the finished firmware uses.
| Configuration | Backend | Top-1 | p50 latency | p99 latency | Product flash | Firmware flash | Peak SRAM | Source disposition |
|---|---|---|---|---|---|---|---|---|
| LiteRT for Microcontrollers | ESP-NN | 91.80% | 17.782 ms | 17.801 ms | 138,978 B | 324,960 B | 123,180 B | industry standard control |
| MicroQuant W8 | ESP32-S3 PIE | 91.86% | 11.295 ms | 11.301 ms | 42,171 B | 213,920 B | 89,420 B | tuned for this chip |
Accuracy is the complete official test set. Speed is one clean run per configuration, with the board reset first. Every MicroQuant answer matched the reference result exactly.
Download the machine-readable benchmark →Three models, four runtimes, one board
Every family in which a vendor runtime was measured beside MicroQuant on the same already-integer model, in the same campaign, over the same endpoints. Only the physical rows are shown, so every number in a row was measured the same way as every number beside it.
Keyword spotting dense int4 runtime control
| Runtime | Backend | Quality | p50 latency | Product flash | Peak SRAM |
|---|---|---|---|---|---|
| LiteRT for Microcontrollers | ESP-NN | 80.12% | 38.751 ms | 340,010 B | 270,396 B |
| MicroQuant W4 | Portable C11 | 80.10% | 55.107 ms | 264,043 B | 73,756 B |
Keyword spotting dense runtime control
| Runtime | Backend | Quality | p50 latency | Product flash | Peak SRAM |
|---|---|---|---|---|---|
| LiteRT for Microcontrollers | ESP-NN | 82.35% | 58.201 ms | 587,314 B | 106,556 B |
| MicroQuant W8 | ESP32-S3 PIE | 82.39% | 34.501 ms | 525,545 B | 74,460 B |
Keyword spotting runtime control
| Runtime | Backend | Quality | p50 latency | Product flash | Peak SRAM |
|---|---|---|---|---|---|
| LiteRT for Microcontrollers | ESP-NN | 91.80% | 17.782 ms | 138,978 B | 123,180 B |
| MicroQuant W8 | ESP32-S3 PIE | 91.86% | 11.295 ms | 42,171 B | 89,420 B |
Wake Vision runtime control
| Runtime | Backend | Quality | p50 latency | Product flash | Peak SRAM |
|---|---|---|---|---|---|
| LiteRT for Microcontrollers | ESP-NN | 76.50% | 72.802 ms | 418,334 B | 232,252 B |
| MicroQuant W8 | ESP32-S3 PIE | 76.80% | 46.493 ms | 65,953 B | 156,732 B |
Both sides are built from the same model file and measured in the same campaign on the same board. Only one row in each pair is ours.
Download every measured cell →Three models, four runtimes, one Cortex-M4
Every runtime that fits the part, measured beside MicroQuant in the same campaign, on the same board, at the same clock, from the same model file.
Keyword spotting
| Runtime | Backend | Quality | p50 latency | Product flash | Peak SRAM |
|---|---|---|---|---|---|
| LiteRT for Microcontrollers | CMSIS-NN | 91.80% | 99.848 ms | 198,494 B | 61,472 B |
| ST Edge AI | ST's own kernels | 91.86% | 80.365 ms | 55,358 B | 28,356 B |
| MicroQuant W8 | Arm DSP | 91.86% | 67.799 ms | 59,080 B | 34,844 B |
Wake Vision
| Runtime | Backend | Quality | p50 latency | Product flash | Peak SRAM |
|---|---|---|---|---|---|
| LiteRT for Microcontrollers | CMSIS-NN | 76.50% | 322.704 ms | 477,846 B | 114,720 B |
| ST Edge AI | ST's own kernels | 76.80% | 137.781 ms | 78,803 B | 51,252 B |
| MicroQuant W8 | Arm DSP | 76.80% | 133.924 ms | 78,370 B | 128,432 B |
Keyword spotting, dense: the model that does not fit at eight bits
| Runtime | Backend | Quality | p50 latency | Product flash | Peak SRAM |
|---|---|---|---|---|---|
| LiteRT for Microcontrollers | CMSIS-NN, int4 model | 80.12% | 30.855 ms | 399,526 B | 114,720 B |
| ST Edge AI | cannot compile a four-bit model | N/A | N/A | N/A | N/A |
| MicroQuant W4 | Arm DSP, the same int4 model | 80.10% | 13.888 ms | 268,310 B | 11,772 B |
| MicroQuant W4 | Arm DSP, the int8 model recompressed | 80.55% | 13.889 ms | 268,310 B | 11,772 B |
CMSIS-NN is the kernel library Arm ships for this core, LiteRT for Microcontrollers is the runtime most products use, and ST Edge AI is the chip maker's own compiler. All three were built here and measured on this board, from the same model file as ours. Where a quality figure is missing, that runtime was too slow to score the whole test set on the chip, so we show nothing rather than a score from fewer samples.
Download every measured figure →Every measured model family
The headline comparison is one workload. These are every model family the current code measured in the two sealed campaigns, how strong the evidence is for each, and whether the industry-standard runtime was measured beside it.
| Family | Workload class | Measured cells | Evidence tiers | Control measured beside it |
|---|---|---|---|---|
| Anomaly detection: owned dense autoencoder | anomaly-detection | 5 | compiled_c, host, physical_hil | no |
| Customer template: a package a customer copies and re-points | customer-supplied | 2 | compiled_c, host | no |
| Graph stress: multiple inputs, multiple outputs, overlapping lifetimes | graph-stress | 2 | compiled_c, host | no |
| Image classification: owned residual CNN | image-classification | 3 | compiled_c, host | no |
| Keyword spotting from float source: the public float DS-CNN compiled by MicroQuant | keyword-spotting | 5 | compiled_c, host, physical_hil | no |
| Keyword spotting dense int4 runtime control: the same four-layer network at four-bit weights, four runtimes, one board | keyword-spotting | 5 | compiled_c, host, physical_hil | yes |
| Keyword spotting dense recompression: the published int8 network re-encoded to four-bit weights by MicroQuant | keyword-spotting | 3 | compiled_c, host, physical_hil | no |
| Keyword spotting dense runtime control: one int8 four-layer network, four runtimes, one board | keyword-spotting | 6 | compiled_c, host, physical_hil | yes |
| Keyword spotting: owned depthwise-separable CNN | keyword-spotting | 5 | compiled_c, host, physical_hil | no |
| Keyword spotting runtime control: one int8 DS-CNN, four runtimes, one board | keyword-spotting | 6 | compiled_c, host, physical_hil | yes |
| Operator microbenchmark: conv-row-64 | operator-microbenchmark | 2 | compiled_c, host | no |
| Operator microbenchmark: conv-row-9 | operator-microbenchmark | 2 | compiled_c, host | no |
| Operator microbenchmark: dense-row-64 | operator-microbenchmark | 2 | compiled_c, host | no |
| Operator microbenchmark: dense-row-65 | operator-microbenchmark | 2 | compiled_c, host | no |
| Streaming wake word: stateless inference under a debounced application rule | streaming-wake-word | 3 | compiled_c, host | no |
| Visual wake words: owned depthwise/pointwise mobile network | visual-wake-words | 5 | compiled_c, host, physical_hil | no |
| Wake Vision runtime control: one int8 MobileNetV1, four runtimes, one board | visual-wake-words | 6 | compiled_c, host, physical_hil | yes |
Every number says how many samples it came from and where it was measured: on a development computer, or on the board itself.
Download the machine-readable suite →Promoted v1 coverage
A narrow contract.
A complete failure boundary.
Every accepted model is validated before output is committed. Unsupported shapes, operators, quantization, targets, and malformed inputs fail with structured diagnostics.
Coverage is published as three scopes, because they are genuinely different questions: what the ABI supports, what a standard model file can reach, and what runs accelerated on the two boards we measured, the ESP32-S3 and the STM32F411. We publish all three so you can check the one that matters to you.
Reachable from a standard model file
Dense
Conv2D
Depthwise Conv2D
Add
Sub
Mul
Average Pool
Global Average Pool
Max Pool
Identity
Flatten
Reshape
Squeeze
Unsqueeze
Pad
Concatenate
Split
ReLU
Clamp
Softmax
ArgMax
Sigmoid
Tanh
Reachable from prepared ABI-v6 JSON
Dense
Conv2D
Depthwise Conv2D
Add
Sub
Mul
Average Pool
Global Average Pool
Max Pool
Identity
Flatten
Reshape
Squeeze
Unsqueeze
Pad
Concatenate
Split
Requantize
ReLU
Clamp
Softmax
ArgMax
Sigmoid
Tanh
Admitted on the ESP32-S3 engineering target
Dense
Conv2D
Depthwise Conv2D
Global Average Pool
Identity
Flatten
Reshape
ReLU
Clamp
Bounded ingestion
Seven explicit source formats.
Canonical ABI-v6 JSON, source-authorized JSON, int8 and float32 TFLite, and ONNX in QDQ int8, QOperator int8, and float32 enter the same typed compiler path. An already-quantized container keeps its declared scales; a float one is quantized by deterministic post-training calibration from a split you supply and never leaves your machine.
Download machine-readable status →Customer-specific GA delivery
A production path
qualified for your exact product.
MicroQuant v1 is available through customer-specific GA engagements. We bind the model, generated artifacts, firmware, target toolchain, verification, and support to the exact implementation instead of offering a one-size-fits-all generic binary.
Delivery modelGAcustomer-specific
Compiler + runtime
ABI-v6 production foundationDeterministic generated C, strict C/C++ integration, lifecycle checks, and numerical proof replay form the common v1 foundation.
Target integration
ESP32-S3 measured on the boardThe portable C11 backend and the ESP32-S3 PIE backend both build, link, and execute on the admitted board. A PIE kernel is admitted for one operation against a capability key and never substitutes itself silently; additional microcontrollers are evaluated on demand.
Implementation validation
Bound to your productBoard measurements, received-byte parity, resource budgets, and integration tests are produced for the customer's exact model and firmware.
GA delivery
Available on demandEach engagement completes the production signing, commercial terms, acceptance, support, and lifecycle package for that customer-specific release.
A kit ships under the delivery profile its contents allow: generated source, restricted-source SDK, exact-host binary runtime, or managed build. Ask for an accelerated build under a profile that cannot carry kernel source and the compiler refuses it and names the profiles that can.
Integration path
Model to generated C.
No hidden runtime.
The development workflow separates admission, compilation, received-byte verification, and firmware ownership so each boundary can be tested independently.
Every step is a command, and every command is an operation on one local service. The optional macOS Workbench is a client over that same service — it shows the envelope, the evidence tier behind every number, and what a kit contains. Nothing you receive depends on it.
- 01
Preflight
Validate the model format, graph envelope, quantization, limits, target, and proof prerequisites without writing output.
- 02
Compile atomically
Create deterministic generated C, manifests, integrity identities, and an explicit manual source list.
- 03
Verify and integrate
Verify the received kit, compile the declared files, provide caller-owned buffers, and retain target acceptance as a separate activity.
Second target, measured on the part
A second architecture, and the industry standard beaten on it.
Every figure here was read from a board.
The same compiler, pointed at an STM32F411, produces firmware that runs the MLPerf Tiny workloads faster than the runtime almost every product ships, in a fraction of the flash, with every answer checked against the compiler's own reference on the device. The chip maker's own compiler is measured beside it, on the same board from the same model file, and where it wins we print that too.
Keyword spotting, on the part
—× faster than CMSIS-NNThe reference keyword graph at 96 MHz: MicroQuant against LiteRT for Microcontrollers with CMSIS-NN, the same model file, the same board, the same clock. And thirty-nine times faster than that runtime's own kernels, in a quarter of the flash.
Wake Vision, on the part
—× faster than CMSIS-NNA MobileNet, measured the same way. Against the runtime most products ship we are well ahead, in far less flash. Against ST's own compiler we are not: on this workload it is 1.76x faster than us, at exactly the same accuracy. We print that beside our own number rather than leaving it out, and the roadmap says what we are doing about it.
Bit-exact, on the device
Every output matched the oracleEvery answer the chip gave was identical to the answer the same model gives on a computer, across every test we ran. Not close, identical, byte for byte. That is the property a safety reviewer asks about first.
Your chip is not on this list
— lines for a second instruction setAdding a second instruction set was one small header file, with no change to any of the maths. A third chip family needed no new hand-written code at all. The porting guide walks through what adding your own chip involves.
The flash it takes
— BModel, runtime and kernels together for the keyword graph on the STM32F411, read from the link map of the measured image. Product flash is what ships; the harness is not counted. Peak static SRAM, workspace, stack high-water and heap growth are in the registry beside it.
The model that did not fit
—× faster than CMSIS-NN at four bitsA dense keyword model that overflows the part's application region at eight bits, for MicroQuant and for the vendor stack alike. At four-bit weights it fits, runs fully accelerated, and every output matched the compiler's oracle on the device; the vendor runtime's own int4 path, on the same int4 model file, is the control beside it, and the row from the original int8 file recompressed by the compiler says what its own search buys. The DS-CNN and Wake Vision models stay at eight bits, because four bits costs them accuracy their cells do not tolerate.
Technical evaluation
Does your graph fit the v1 envelope?
Share the model format, graph shape, target, and constraints. We will qualify the fit and scope a customer-specific GA implementation for your product.
First stepContract-bound model review
✓
Request received.
We will follow up at .