Skip to content

Question: does a flash-resident tiny language runtime fit the MCUNet view of tiny system-algorithm co-design? #39

Description

@Juemian-Deng

Hi MCUNet folks,

I wanted to share a small MCU language-runtime experiment and ask whether systems like this feel adjacent to the MCUNet view of tiny AI systems.

We built a public demo line called Engram and deployed it on a commodity ESP32-C3.

Current public numbers:

  • Host-side benchmark capability

    • LogiQA = 0.392523
    • IFEval = 0.780037
  • Published board proof

    • LogiQA 642 = 249 / 642 = 0.3878504672897196
    • host_full_match = 642 / 642
    • runtime artifact size = 1,380,771 bytes

Important scope note:

This is not presented as unrestricted open-input native LLM generation on MCU.

The board-side path is closer to a flash-resident, table-driven runtime with:

  • packed token weights
  • hashed lookup structures
  • fixed compiled probe batches
  • streaming fold / checksum style execution over precompiled structures

So this is not a standard tiny dense model with familiar operators. It is closer to a task-specialized language runtime whose behavior has been
pushed into a very compact executable form.

Repo:
https://github.com/Alpha-Guardian/Engram

What makes me curious from the MCUNet perspective is whether systems like this should be viewed as:

  • outside the normal tiny-DNN scope
  • an adjacent form of system-algorithm co-design for language workloads
  • or evidence that some language-task behavior can also be compressed into MCU-scale specialized runtimes

Would be very interested in your thoughts.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions