Resource-Efficient Quantized Models On The Edge pronounced “reck mote”
Intelligence that fits.
Edge AI model engineering for semiconductor enablement and embedded teams.
Scope one workload and target, then build the evidence needed to decide what can advance to hardware.
One workload · one supported target · agreed quality, build, and board-evidence gates.
- Application fit
- Build around your application
and its data. - Silicon fit
- Create models engineered for
your target accelerator. - Hardware proof
- Validate the SDK-integrated model
on its physical target.
reqmote by Qurosphere
Model comparison
Recognition quality. Model size. Measured together.
Two models for six spoken commands
Compare a public reference with a compact model developed by reqmote on the same evaluation audio.
Choosing a model means balancing recognition quality and resource requirements.
In our calibration evaluation, the public BC-ResNet-8 INT8 reference achieved the strongest recognition results of the two models: it correctly classified 96.9% of 1,236 isolated command clips and classified 5.0% of 19,973 non-command audio windows as commands. Both results use the same model and classification rule.
The reqmote compact model has a 45.7 KiB model file—about 18× smaller than the 821.6 KiB public reference—but lower recognition quality: 89.2% command-clip accuracy and 6.9% false-command windows on the same audio.
Why explore compact models? Devices have limited space for both the model and the application. The nRF52832 variant with 512 KiB flash and 64 KiB RAM cannot store the 821.6 KiB reference file in its on-chip flash as-is. On the nRF52840, with 1 MiB flash and 256 KiB RAM, the reference file is about 80% of total flash capacity, versus about 4.5% for the reqmote compact model. Firmware also needs flash; audio buffers and inference need separate working RAM. These file-size comparisons explain the storage pressure. Exact compiled storage and peak RAM still require validation for each model and device.
We selected BC-ResNet-8 as the reference for the next stage: evaluating target compatibility and investigating how much its model footprint can be reduced while preserving quality. Deployment memory, speed, and power still require target-board measurements.
How we measured this
The six commands are on, off, stop, go, up, and down; other outputs map to unknown or silence. These are offline development/calibration results, not an independent final acceptance test. The negative audio combines 4,561 non-command speech clips, background sounds, and 80 ESC-10 environmental recordings: 1.39 hours in total, sampled in overlapping one-second windows every 250 ms. The 5.0% figure is a window error rate, not false activations per hour.
Headline results use the highest class score, without a rejection threshold or temporal smoothing. A separate, stricter continuous-listening policy measured 53.1% command-event recall with one false event in 1.39 hours; those are different operating settings. The replay clips below are unchanged illustrative development recordings, scored separately with each model.
reqmote evaluated the Andes ModelZoo reference, based on Qualcomm AI Research's BC-ResNet architecture. Hardware compilation, linked firmware, board latency, and power for these keyword models remain future integration work. The separate A10 vision walkthrough contains physical-board evidence.
Evidence maintained by Qurosphere; reviewed . Inspect results, model identities, and attribution (JSON).
Listen to real audio and inspect the selected model's precomputed prediction. No microphone access is needed.
Choose a recording to inspect the measured prediction.
*Non-command windows incorrectly classified as commands. Lower is better. This is not a false-activations-per-hour measurement.
A separate vision experiment · retained physical evidence
Follow a model all the way to the board.
The A10 object detector runs on a physical Nordic nRF54LM20B board. The walkthrough connects dataset intake, model selection, a pinned SDK build, and signed board results.
- Controlled inference
- 158.6 ms p95
- Ten retained runs on one known image; deterministic outputs in 10/10 runs.
- Model quality
- Failed gate
- Full-integer ReLU model: mAP50 0.0559 · recall 0.088 on 12 validation images, with one generic-object class. See the walkthrough for the separate board-linked artifact.
- Evidence boundary
- Vision only
- These results do not validate the keyword models above. Power and energy remain unmeasured.
Explore the retained results at /demo. Contact us for a guided intake walkthrough; this public review does not launch a new board run.
From real recordings to a target-fit model
Compare recognition and rejection together, then take the selected model through target integration.
-
1
Freeze the data
Evaluate valid commands alongside other speech and environmental sounds using the same audio for every model.
-
2
Choose a target
Compare CPU and NPU paths using hardware-appropriate memory limits.
- Nordic
- Axon
- NXP
- Neutron
- Baseline
- CPU
-
3
Compare and optimize
Benchmark public references and custom-trained candidates, then optimize the chosen model for the target's constraints.
-
4
Review the evidence
Publish measured recognition and false-classification rates with their test conditions and next integration step.
Featured reference96.9% command accuracy
Measured offline. Compiler and board proof follow.
Useful before firmware work gets expensive
The output is a decision, not a pile of experiments.
See how evidence levels work- 01
Embedded and ML teams
See whether the data, model, operators, memory, and runtime agree before integration.
- 02
IoT product teams
Compare the practical tradeoffs between a tiny CPU model and an accelerator-ready candidate.
- 03
Silicon enablement teams
Turn a supported SDK and board into a repeatable customer workflow with evidence.
Evidence, not a green checkmark
Every result says what was measured, what was estimated, and what still needs hardware proof.
Your dataset. Your target.
Let’s scope the next proof.
Start with a scoping conversation for your workload, target board, SDK, and constraints. Together we will agree the quality, build, and board-evidence gates for one bounded project, and the decision each result should support.