Methods · deployment fit

A small model file is the start of the fit question.

To establish that a model fits a microcontroller, account for the compiled application and its peak working memory—not just the exported model file.

Maintained by reqmote / Qurosphere · Updated

Three quantities to keep separate

Model artifact bytes

The exported file includes model parameters and format metadata. It is useful for comparing storage requirements, but it does not include the full firmware or every runtime allocation.

Compiled flash usage

The linked application includes code, runtime kernels, model data and other application assets. Compiler transformations and model packaging can change the relationship between file size and deployed storage.

Peak RAM usage

Activations, scratch buffers, tensor arenas, stack/heap, preprocessing and application state compete for working memory. The peak may occur during preprocessing or an intermediate layer rather than while loading the model.

Target compatibility

An accelerator also constrains supported operations, shapes, precision and memory placement. A file that is small enough to store can still be unsupported or unsuitable for a latency requirement.

A concrete storage example

In the published keyword comparison, BC-ResNet-8 occupies 841,280 bytes (821.6 KiB) and the reqmote compact model occupies 46,800 bytes (45.7 KiB). KiB means 1,024 bytes.

The nRF52832 variant with 512 KiB flash and 64 KiB RAM cannot hold the reference file in its on-chip flash as-is. On the nRF52840, with 1 MiB flash and 256 KiB RAM, that file is about 80.2% of total flash; the compact file is about 4.5%. Firmware and other assets also need space.

Those percentages are storage arithmetic, not deployment measurements. They do not establish that either keyword model runs within the device’s RAM, latency or power limits. A smaller artifact may still fail quality or compatibility requirements.

What to ask for before claiming fit

  1. Freeze the exact system. Identify the model, preprocessing, compiler/runtime version, target variant and application configuration.
  2. Check target support. Inspect operators, quantization, shapes and any CPU/accelerator partitioning.
  3. Inspect the linked build. Record model placement, code/data sections and actual flash/RAM accounting. Keep estimates distinct from measured allocations.
  4. Exercise the application. Measure peak memory and timing with representative inputs and the intended preprocessing, buffers and runtime policy.
  5. Preserve quality. Re-evaluate the deployed path against the agreed acceptance data; a successful compile does not establish model quality.

Read the evidence at its stated level

Our A10 experiment records a linked firmware build and controlled physical-board inference for a vision model. It also records a failed product-quality gate. Its build and board measurements cannot be transferred to the keyword models or to a different application.

A scoped reqmote project should specify which of these questions it will answer and what remains outside the deliverable.