mlcommons / mlcommons/tiny

Question: should MCU-scale language runtimes have a Tiny benchmark category?

Open
#181 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
479
Forks
116
PR merge metrics
No merged PRs in 30d

Description

Hi MLCommons Tiny folks,

I wanted to share a small but unusual MCU language-runtime experiment and ask whether systems like this suggest a benchmark gap in the current Tiny landscape.

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 vision/KWS/anomaly micro model. 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 I’m genuinely curious about is whether systems like this point to a missing benchmark category in the TinyML / MCU benchmark ecosystem.

Would something like the following make sense as a future benchmark direction?

  • constrained language-task execution
  • auditable board-measured language behavior
  • fixed-memory / fixed-artifact board deployment
  • explicit separation between host benchmark capability and board execution mode

If people here think this is out of scope for MLCommons Tiny, that would also be useful to know.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review the proposed Engram benchmark gap and the linked Alpha-Guardian/Engram repository, starting with the distinction between host benchmark capability and board execution mode described here. Done would be a maintainer decision on whether constrained, auditable MCU language-task execution belongs as a future MLCommons Tiny benchmark category or is out of scope.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
embedded-iot, testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.