📟 mcufit

Know if your AI model fits your microcontroller - before you flash it.

🌐 Try it in your browser - drop a model, get a verdict, nothing to install

Runs entirely client-side. Your model never leaves your device.

Deploying ML to a microcontroller today works like this: train, convert, flash, watch it crash with Arena size is too small, guess a bigger number, re-flash, repeat. The official TFLite Micro docs literally say the memory size "may need to be determined by experimentation."

mcufit replaces the experimentation with an answer in one second.

pip install mcufit
mcufit check model.tflite --board esp32-s3

Features

• ⚡ Instant fit verdict - RAM & flash bars, headroom, and the exact layer where memory peaks
• 🎯 Exact mode - runs your model through the real TFLite Micro runtime compiled for your machine: activations measured exactly, interpreter overhead an upper bound, zero hardware
• 🌐 Browser version - same engine via WebAssembly, fully private, no install
• 🔌 31 boards - ESP32 family, Pico, STM32, Teensy, Arduino, and more
• 🤖 CI guard - a GitHub Action that fails the PR when your model outgrows the chip
• 💡 Actionable suggestions - int8 quantization preview (simulated, not guessed) and which boards do fit
• ⏱️ Speed, measured - ms/inference on the boards actually benchmarked on hardware, and silence on the rest
• 📦 ONNX support - pip install 'mcufit[onnx]' for the PyTorch world

Commands

Exact mode

Static analysis is instant but approximate - real runtimes allocate per-operator working memory no file analysis can see. Exact mode runs your model through the actual TFLite Micro interpreter and reads its recorded allocations:

mcufit check model.tflite -b esp32-s3 --exact   # needs node, nothing to build

The interpreter ships in the wheel, compiled to wasm32 and run under node. There is no setup step and no compiler. On the person-detection reference model: estimate ~74 KB → measured 84,428 bytes.

How close it gets

Activation tensors come straight from the model, so their size is identical everywhere and that half of the number is exact. The interpreter's own bookkeeping is full of pointers, so its size follows the pointer width of whatever the interpreter was compiled for.

Measured against a real ESP32-D0WDQ6 at 240 MHz, person_detect (mcufit-bench, 2026-08-16):

wasm32 is 32-bit like the chip, which is why --exact uses it. What is left is struct padding that differs from Xtensa. It reads high rather than low, which is the safe direction for a fit check, but it is not the device's exact number and the tool says so in its output.

mcufit setup-exact still builds the native 64-bit interpreter, for machines without node. It is the less accurate path and the CLI warns when it uses it.

Speed

Only esp32 and nano33ble have been measured on hardware. Every other board returns no speed number.

Speed is not derivable from a datasheet. Which operators run fast depends on which kernels the vendor wrote, and that is not documented anywhere. Measured per operator, in MACs/cycle:

Each chip is slow at a different operator. On the ESP32 fully-connected costs 3.2x more than convolution, because esp-nn ships no kernel for it and it falls back to reference C. On the nRF52840 fully-connected is fine and depthwise is the slow one, at 3.3x.

Before this, every board carried a hand-written macs_per_cycle. Those were wrong by up to 3.2x and ranked the two chips the wrong way round. They are gone. Numbers come from mcufit-bench.

Guard your model in CI

- uses: avionicharshit-byte/mcufit@main
  with:
    model: models/wake_word.tflite
    board: esp32-s3

A model that grows past the board's RAM now fails the pull request instead of the field deployment.

Why this exists

Pre-deployment memory estimation has been requested in the TensorFlow repos since 2019 - never shipped. A TFLite Micro maintainer, March 2024:

"We don't have a python based tool for determining arena size…"

Vendor tools (STM32Cube.AI, eIQ) answer only for their own silicon. mcufit is the neutral, open version.

License

MIT