This is cool. I definitely think the "micro" sized LLM space is underappreciated, so it's always good to see work like this. I foresee a paradigm in some contexts where you have a hierarchy of LLMs, with more competent models actively training smaller models to solve specific tasks very efficiently, and something like this could be the smallest layer in that stack.
With that being said, the web demo is not particularly impressive. It really doesn't like anything I throw at it. I'm fine with accepting that fine-tuning is the solution to this, but I wonder if there's anything to gain from a bigger model? I know it's completely counter to the whole point of this, but a 14MB binary using 28MB of RAM seems unnecessarily small and pretty arbitrary.
Like, what does a 28MB binary get you? Or a 140MB binary? Or a 1.4MB binary? I'm guessing the choice of 14MB came from minimizing the size as much as possible while meeting certain requirements/performance expectations, but even a Pi 5 has plenty more room to spare. Curious if there's a good explanation for this (which I may have missed in my skim of the post).
So, its not a general language model, focused on tool call strictly for tiny edge-devices. There are solutions everywhere for high-capacity devices, Needle is for sub-$200 devices.
It seems to me that the model struggles to have enough general intelligence, knowledge, or reasoning capacity for arbitrary prompted tool calling. At this size, not surprising.
I am VERY interested in seeing how it could perform with some fine-tuning for a specific family of tools/tasks. That would be a great addition to the demo.
Well running from QSPI flash (even the internal memory versions use SPI internally) so any inference would be very slow streaming from that compared to RAM. The featured article says: “With a peak session RAM around 28MB, Needle runs on newer microcontrollers like ESP32-S3.” So I don’t see this doing anything useful on a Pico. The Pico 2 (RP2350) for example has 520k of RAM.
I'm quite impressed by the results of the web demo, especially given its size and the precision with which it uses the three available tools (tested with German commands). I could imagine that this LLM would fit well into a setup with multiple micro-sized LLMs for different purposes; so 14 MB for precise tool invocation is a reasonable memory footprint when a number of other local models are running (e.g. STT, TTS + language models).
Tested your example, the confidence is 0. In smart home context, I can think of an application where the low confidence answers can be forwarded to cloud, whereas the vast majority generic queries solved locally, if the confidence is reliable enough. The response is quite fast by the way.
Turning a voice command into a tool call should be self evidently useful, being able to do that on a small embedded device is the novelty here. In this theoretical example, the thermostat is hosting the model on device and would use no external services.
I confused by the dispatch model. Tool calls typically need some reasonability to be deterministic and, more importantly, predictable in response (o/w GIGO). Why would the thermostat need to interpret a voice command that the node capturing the voice command would not interpret instead?
The node capturing the voice command could be the thermostat. From my understanding they are targeting very small devices.
So that could be a master home automation node, but why not also a single purpose device? I can think of more bad examples than I can good ones, but maybe I am doing some soldering and I need my soldering iron turned up a bit; my hands are full, so doing that by voice would be useful enough. Something I would never link up to a big AI model or home automation network, but could be useful to control by voice.
If it's something that can be burnt directly into a chip and shipped with the products for cheap, maybe that's a more pragmatic way to get AI into small devices (see taalas for a much bigger model doing that, althoug not yet cheap).
Oh I agree that's not unreasonable. I wonder about the harnessing heft required to make it feasible though. If I say I'd like it a bit warmer, a tool can deterministically bump a few degrees while an LLM might bump it 10C. So do we limit the tool's range?
It's definitely cool that you can get any reasoning whatsoever out of such a small model. That said, its reasoning is "interesting":
Query: "Make the living room dark"
Agent: "User wants lights on in living room. 'dark' implies dim. Room 'living room', action 'on'." (And on every test I did, it just completely ignored the "brightness" parameter)
It also appears to have no concept of what a door or light actually is, whenever the query diverges from "Lock door X" or "Turn on light X", it tries to shoehorn whatever additional context is given into the device name:
Query: "Lock out the vacuum salesman at the front door"
Agent tries to lock "front door vacuum salesman"
"The way you talk really makes me appreciate silence" is classified as "positive" with 82% confidence.
Funny result from the web demo. I'm well aware that it's an extremely small and, well, stupid, model, but even so:
Query: HN
Result:
{
"function_calls": [
{
"name": "lock_door",
"arguments": {
"door": "front door"
}
}
],
"reasoning": "User wants to lock the door. No specific door mentioned, so use 'front door' as default.",
"confidence": 0
}
I'd expect it to at least ignore (call no tools) for the queries that it doesn't understand. And it seems like it does do that, just not consistently.
The website says the model is for "tool calling, device use, and structured extraction". Your example just doesn't seem to be very relevant. FWIW, it did a pretty good job for tool calling when I tried it, and I think it could be pretty nice to have this running on locally and integrate with Home Assistant.
False positives are definitely relevant and worth measuring - natural language interfaces always have a discoverability problem, i.e., users not knowing what actions the system does and does not support. If the frontend of that system lacks the ability to reject unsupported commands, weird stuff happens.
Nonetheless, this is very cool work! If I can offer a small suggestion to the team at Cactus, it would be to evaluate your releases on some usability criteria (including false positives). Any serious integrator or adopter of these models would want to have that information available.
Right, but that's not the same thing as reporting a benchmark across a test set. It doesn't help me determine how well the model does across a decently-large sample size of commands. It doesn't tell me with what reliability the confidence will be below a given threshold when it should be, above that threshold when it should be, etc.
This is extremely impressive if it works. But on the other hand, if the number of cases where it works as expected is lower than what we could catch with a (old-Siri-style) heuristics based approach, and the rest fails in unpredictable ways, I'd prefer the dumb old "I did not understand that" response.
I think the test above is about tool calling... That's how I read it.
The issue here is known as "out of distribution detection" in the old-timey classification world.
I am not sure how a micro model will fundamentally solve it. Would love to understand what dannyw and team did there?
How did you draw an association between dannyw and Cactus? There are no 'Danny's on the list of GH contributors nor is there one named in the paper. Just curious.
It seems to love locking doors. I was hoping this would dim the lights.
> I'm hungover
{
"function_calls": [
{
"name": "lock_door",
"arguments": {
"door": "front door"
}
}
],
"reasoning": "User wants to lock the door. 'hungover' implies a security door. No specific door named, so use 'front door' as default.",
"confidence": 0
}
This is exactly why the confidence feature was introduced, the model knows when its wrong, we could hide that part and return a placeholder "sorry I only do function calls", would that be better or you prefer to see everything?
Congratulations. 28MB is impressive, I've not played around with actual queries/outputs.
I'm wondering what is the overall thesis/plan here and where exactly the innovation lies? Would love if you can throw light on below,
- If I understand, this is complete stack of a custom architecture (attention only transformers), custom quantisation format and a runtime engine all packaged together?
- How do you differentiate / compete against LiteRT (former TensorFlowLite) and Lite RT LM? Google is heavily investing in this ecosystem because Android is where they have distribution moat. Wouldn't it be easier for me as a developer to build on top of LiteRT since it is relatively open ecosystem and I can pack large number of open models from HF directly?
- What exact challenges you saw with TFLite, TVM etc that prompted this effort ?
- What will be the pricing model like?
That's really cool - I was already thinking of compressing `functiongemma-270m-it` down to 1-2 bits so it would work flawlessly in the browser.
Your `Fine-tuning` feature is even much more convenient.
There's a Manning book on creating your own LLM from scratch which answers your question exactly. There's another book from the same publisher specifically about small language models for specialty purposes.
As someone who's done something similar (https://blog.lukesalamone.com/posts/creating-tiny-semantic-s...) the expensive part wasn't the training itself but the data curation and evaluation post-training. For this, getting a reasonable distribution of tool calls when the tool call can be anything isn't easy.
Once you have that, the model is small enough batch sizes are probably enormous and training can probably be done on a consumer-grade GPU in a week or less. Or even faster on a bigger GPU.
Another option for something this small and narrowly specialized could be to get traditional LLMs to synthesize the training data. Model collapse is probably less of an issue at this size relative to terabyte sized models.
This is a cool idea but I think humans assume more than 14MB of intelligence. This is like the unhelpful guard in the swamp castle of Monty Python's Holy Grail
Haha, its not a generalist model, cheap devices cannot run LLM in production, so we brig on-device intelligence to them in the size they can. Needle is niche, not a Gemma or GPT replacement.
Try the following tool description: "Calculate the sum of two numbers. Use for any arithmetic or math question." instead of "Add two numbers." Let me know how it goes, thanks!
import needle
@needle.tool
def add(a: int, b: int):
"Calculate the sum of two numbers. Use for any arithmetic or math question."
return a + b
agent = needle.Needle(tools=[add])
print(agent.run("what is 5 + 7?")["reasoning"])
>> No calculator or math tool available. Cannot compute numbers.
Ah, another failure point on our end! So a simple "5 + 7" and "add 5 and 7" works. But to handle ambiguity, the python package ships pipelines to synthesize augmentations and fine-tune on your samples for robustness. Just run "needle playground" and use the UI. Apologies.
While most of the industry focuses on the frontier of “intelligence” (function), a release like this represents the frontier of the other end of the spectrum (form).
Both are important if we ever want to see “Opus-level” capability running locally on commodity machines in the future.
I changed it to "call path planner to navigate: a_star(x0, xf, obs)"
Another fail.
My intuition tells me micro llms will/are important for robotics. I just can't grok it. Can someone without control theory experience give me a good example?
Probably at the planning level of the navigation stack. That's where I see reasoning being helpful. Lower than that...idk
Give me an example of a robotics prompt that seems useful and I'll give you an example why we don't need LLMs to be a tracking controller, etc.
A lot of Needle 1 users deployed on microcontrollers, we couldn't just throw them under the bus only t chase benchmarks, so its a price we are willing to pay :(
This is really cool, I'm curious how much knowledge can their be in smaller models? It seems the current trade off is you need sizeably larger models for more performance but I'm curious if in your work how far this is true, as edge ai is really what needs to get better before physical ai can take off (my two cents).
I imagine at such a low parameter count, there would be little to no world knowledge whatsoever, and the entire focus is on getting the structure of tool calling etc. right…?
But yeah, in terms of “physical” AI, robotics definitely comes to mind for me as well, where tool calls/structured “device” use in a “realtime”/edge application are highly beneficial (if you wanted to go with LLMs), but beefy hardware can’t be easily used.
Makes me think of the demo from some time ago where someone got a ~29M parameter model running on an esp32. I wonder what kind of throughput this could get if a handful of esp32s were strung together...
Edit: I have a pile of d1 minis, but not much time.
They mention that this specific model is able to run on an ESP32-S3, or an ESP32-P4 which has 32MB of PSRAM. I'm trying to figure out how to do this now.
What about use case for replacing regex?
I.e "random formatted title.extension" - extract the title or some tag or something for more dynamic string manipulation for pulling structured data out of strings efficiently and more simply than regex provides?
Congrats on this release. The WASM implementation is really cool. This is a surprisingly good fit for a lot of cases, and I totally want to try turning this into a helper assistant for an application.
Please, though, take a pass at humanizing the text on the page. It's Clauded up all over and makes it hard to read.
I wonder if there's any way to get this to plan out a dag of tool calls? i.e. use the results from earlier calls as the parameters to later ones? I tried introducing a stack based system, but gave up pretty quickly.
Yes, though for better results in production, after creating your tool json, use the provided data synthesis and fine-tuning pipeline. It tunes on on your mac.
Was really cool to see yous use Engrams to cut down compute!
Given its basically an O(1) lookup with disk space being the main constraint, I was curious if you've tried ablating engram layers and sizes across your setup?
That will get you a lot further than what you're asking, but if you dig a bit through Home Assistant features, resources, etc., you may find the current "best" answers to your questions.
If you want a quick answer: Whisper is a good open-source speech-to-text model which comes in a variety of sizes (https://huggingface.co/openai/whisper-tiny). You can definitely get something like this running on a Pi 5. There are plenty of other STT models out there, some of which are built specifically for this context (again, see the Home Assistant stuff), but Whisper comes up a lot as a good default choice.
So with something like Whisper, you could just have a simple script which is constantly listening to a rolling window of audio and transcribing it. When the transcription includes a key phrase, you can pass the rest of the transcription to Needle2 (or anything else for that matter). From there, you take the results and execute the necessary tool calls.
There's a bit more to all of this to make it work smoothly, but fundamentally this is all there is to it. All this would work very fast on a Pi 5 (although I wouldn't expect the results to be particularly good without some serious hand-crafted logic, fine-tuning, etc.). If you want to mess around this stuff, handing all of this to Claude, Codex, etc., can get you something spun up and functional very quickly.
The wyoming protocoll seems to be the path for home assistant audio, so you need STT (wyoming-faster-whisper), TTS (wyoming-piper for wide language support) API endpoints and some Ollama or OpenAI API endpoint available for your home assistant server.
That is interesting, thanks. And I see separable wake-word detection there. I'd always assumed that was likely to be closer to the metal (more like recognise a sound than turn sound to word).
{
"function_calls": [
{
"name": "set_thermostat",
"arguments": {
"temperature": 72,
"mode": "cool",
"room": "living room"
}
}
],
"reasoning": "'as dark as possible' -> set_thermostat to warm; 'dark' implies higher temperature; 'cool' mode for darkness.",
"confidence": 0
}
... maybe this counts as dark humor at least.
Since it seems limited to matching a few templates and otherwise falling flat on its face, I wonder how 14MB of regexes would fare in its stead. Normally you wouldn't want to parse arbitrary natural language input with regex because of how tedious and brittle it would be, but for the tedium we have LLMs and this alternative isn't exactly robust either.
SO when confused, it gives you a low confidence score as a signal, in which case its recommended to finetune using th python package, train on your mac/PC
I also wonder how small a LLM trained on catching only subject (e.g. living room) and action (light on) from text input could be compared to needle - the json wrapping could be done afterwards using templates.
This is very interesting! I'm going to spend some time with this. This is really the only class of LLM I'm interested in at all. I sincerely hope on-device takes over and everyone looses their asses on these data centers.
For the longest time, I conceptualized LLM's as Text Input -> Text Output transformers, then later as Text Input -> Video Output transformers. Later still I conceptualized them (if they were general purpose) as Any Format Input -> Any Format Output transformers...
The idea of a smaller parameter model runable on smaller/slower/less complex hardware (computers with no GPU, slower CPU's, less memory, aka "Edge Devices") trained for Text Input -> JSON Output (used for tool calls, etc.) I could honestly not conceptualize before seeing the demo on the web page...
But now that I've seen it and conceptualized it -- I'd have to say: "Yes, there's definitely a huge niche, a huge market for this, directly between the non-LLM driven tools and software and SaaS's of yesteryear, and the latest, cutting edge Frontier AI models of today!"
So, I like Needle a lot!
I like Needle a lot, and I love the idea of any tiny resource-thrifty LLM that can run on older hardware, that outputs only JSON!
The learned confidence gate is the crucial piece for a 14MB action model. On ambiguous requests such as the HN example, what calibration target decides between abstaining locally and escalating to the cloud?
around +60% confidence threshold is cool from experiments, the problem is that you gotta test on your own workload, no existing benchmark could honestly paint the full picture, so we exposed the confidence threshold for everyone.
This is cool. I definitely think the "micro" sized LLM space is underappreciated, so it's always good to see work like this. I foresee a paradigm in some contexts where you have a hierarchy of LLMs, with more competent models actively training smaller models to solve specific tasks very efficiently, and something like this could be the smallest layer in that stack.
With that being said, the web demo is not particularly impressive. It really doesn't like anything I throw at it. I'm fine with accepting that fine-tuning is the solution to this, but I wonder if there's anything to gain from a bigger model? I know it's completely counter to the whole point of this, but a 14MB binary using 28MB of RAM seems unnecessarily small and pretty arbitrary.
Like, what does a 28MB binary get you? Or a 140MB binary? Or a 1.4MB binary? I'm guessing the choice of 14MB came from minimizing the size as much as possible while meeting certain requirements/performance expectations, but even a Pi 5 has plenty more room to spare. Curious if there's a good explanation for this (which I may have missed in my skim of the post).
So, its not a general language model, focused on tool call strictly for tiny edge-devices. There are solutions everywhere for high-capacity devices, Needle is for sub-$200 devices.
It seems to me that the model struggles to have enough general intelligence, knowledge, or reasoning capacity for arbitrary prompted tool calling. At this size, not surprising.
I am VERY interested in seeing how it could perform with some fine-tuning for a specific family of tools/tasks. That would be a great addition to the demo.
i would assume a model this size would require finetuning tbh. even functiongemma recommends that.
14mb? More like sub-$20 devices.
Most pi pico's come with 16mb of flash. I wonder what kind of performance that can eek out.
Well running from QSPI flash (even the internal memory versions use SPI internally) so any inference would be very slow streaming from that compared to RAM. The featured article says: “With a peak session RAM around 28MB, Needle runs on newer microcontrollers like ESP32-S3.” So I don’t see this doing anything useful on a Pico. The Pico 2 (RP2350) for example has 520k of RAM.
An ESP32 has the same amount of SRAM as the Pi Pico. You can hook up PSRAM to the Pi Pico just like ESP32 to get 16MB more RAM.
I'm quite impressed by the results of the web demo, especially given its size and the precision with which it uses the three available tools (tested with German commands). I could imagine that this LLM would fit well into a setup with multiple micro-sized LLMs for different purposes; so 14 MB for precise tool invocation is a reasonable memory footprint when a number of other local models are running (e.g. STT, TTS + language models).
yes, that's what we had in mind while building
My first query:
> Make it a little warmer in here.
The reply:
> "name": "set_thermostat", > "arguments": { > "temperature": 65, > "mode": "cool", > ... > "reasoning": "'warmer' implies need for cooling; set_thermostat with temperature 65 (typical warmth) and mode 'cool'.",
Maybe I'm doing it wrong?
Tested your example, the confidence is 0. In smart home context, I can think of an application where the low confidence answers can be forwarded to cloud, whereas the vast majority generic queries solved locally, if the confidence is reliable enough. The response is quite fast by the way.
It's not a conversational model. It's meant as a local tool calling model.
Yes, and it seems the tool called here was the thermostat, to set the mode literally the opposite of what was requested.
Yes, I think OP understands that. What he and many others in this thread are trying to understand is what makes this model useful.
Turning a voice command into a tool call should be self evidently useful, being able to do that on a small embedded device is the novelty here. In this theoretical example, the thermostat is hosting the model on device and would use no external services.
I confused by the dispatch model. Tool calls typically need some reasonability to be deterministic and, more importantly, predictable in response (o/w GIGO). Why would the thermostat need to interpret a voice command that the node capturing the voice command would not interpret instead?
The node capturing the voice command could be the thermostat. From my understanding they are targeting very small devices.
So that could be a master home automation node, but why not also a single purpose device? I can think of more bad examples than I can good ones, but maybe I am doing some soldering and I need my soldering iron turned up a bit; my hands are full, so doing that by voice would be useful enough. Something I would never link up to a big AI model or home automation network, but could be useful to control by voice.
If it's something that can be burnt directly into a chip and shipped with the products for cheap, maybe that's a more pragmatic way to get AI into small devices (see taalas for a much bigger model doing that, althoug not yet cheap).
Oh I agree that's not unreasonable. I wonder about the harnessing heft required to make it feasible though. If I say I'd like it a bit warmer, a tool can deterministically bump a few degrees while an LLM might bump it 10C. So do we limit the tool's range?
That's exactly what they were testing and what it failed at
Try asking it to set the thermostat to a value. It's a very small model, there's not much reasoning capability
It's definitely cool that you can get any reasoning whatsoever out of such a small model. That said, its reasoning is "interesting":
Query: "Make the living room dark" Agent: "User wants lights on in living room. 'dark' implies dim. Room 'living room', action 'on'." (And on every test I did, it just completely ignored the "brightness" parameter)
It also appears to have no concept of what a door or light actually is, whenever the query diverges from "Lock door X" or "Turn on light X", it tries to shoehorn whatever additional context is given into the device name:
Query: "Lock out the vacuum salesman at the front door" Agent tries to lock "front door vacuum salesman"
"The way you talk really makes me appreciate silence" is classified as "positive" with 82% confidence.
that model is 14MB large what do you expect. but I agree it's funny regardless
Ok, this is genuinely funny, we will fix these as we iterate, thanks lol.
Funny result from the web demo. I'm well aware that it's an extremely small and, well, stupid, model, but even so:
Query: HN
Result:
{ "function_calls": [ { "name": "lock_door", "arguments": { "door": "front door" } } ], "reasoning": "User wants to lock the door. No specific door mentioned, so use 'front door' as default.", "confidence": 0 }
I'd expect it to at least ignore (call no tools) for the queries that it doesn't understand. And it seems like it does do that, just not consistently.
The website says the model is for "tool calling, device use, and structured extraction". Your example just doesn't seem to be very relevant. FWIW, it did a pretty good job for tool calling when I tried it, and I think it could be pretty nice to have this running on locally and integrate with Home Assistant.
False positives are definitely relevant and worth measuring - natural language interfaces always have a discoverability problem, i.e., users not knowing what actions the system does and does not support. If the frontend of that system lacks the ability to reject unsupported commands, weird stuff happens.
Nonetheless, this is very cool work! If I can offer a small suggestion to the team at Cactus, it would be to evaluate your releases on some usability criteria (including false positives). Any serious integrator or adopter of these models would want to have that information available.
> "confidence": 0
OP and the linked page talk about the confidence score and using it as an action threshold, so it looks like an appropriate total response to me.
Right, but that's not the same thing as reporting a benchmark across a test set. It doesn't help me determine how well the model does across a decently-large sample size of commands. It doesn't tell me with what reliability the confidence will be below a given threshold when it should be, above that threshold when it should be, etc.
Thanks, noted!
This is extremely impressive if it works. But on the other hand, if the number of cases where it works as expected is lower than what we could catch with a (old-Siri-style) heuristics based approach, and the rest fails in unpredictable ways, I'd prefer the dumb old "I did not understand that" response.
I think the test above is about tool calling... That's how I read it. The issue here is known as "out of distribution detection" in the old-timey classification world.
I am not sure how a micro model will fundamentally solve it. Would love to understand what dannyw and team did there?
How did you draw an association between dannyw and Cactus? There are no 'Danny's on the list of GH contributors nor is there one named in the paper. Just curious.
It seems to love locking doors. I was hoping this would dim the lights.
> I'm hungover
{ "function_calls": [ { "name": "lock_door", "arguments": { "door": "front door" } } ], "reasoning": "User wants to lock the door. 'hungover' implies a security door. No specific door named, so use 'front door' as default.", "confidence": 0 }
"confidence": 0, so I guess you could threshold it
Only if the confidences are calibrated, and they probably aren't. Any idea how the confidence is derived?
no, this is the appropriate response to hearing the words "HN" :P
I've got an identical output with the prompt "do not lock the door".
yeah I got the same, almost like its biased heavily towards that as the 0 ranking -- my prompt was just the word 'potato'
Was that the first message you sent it?
This is exactly why the confidence feature was introduced, the model knows when its wrong, we could hide that part and return a placeholder "sorry I only do function calls", would that be better or you prefer to see everything?
It seems to fail. I sent the prompt:
“ 5° warmer”
And it said:
“ setting the temperature to 5°F”
Congratulations. 28MB is impressive, I've not played around with actual queries/outputs.
I'm wondering what is the overall thesis/plan here and where exactly the innovation lies? Would love if you can throw light on below,
So TFLite is an inference engine while Needle is a model, which you can port on TFLite btw.
That's really cool - I was already thinking of compressing `functiongemma-270m-it` down to 1-2 bits so it would work flawlessly in the browser. Your `Fine-tuning` feature is even much more convenient.
Thanks, give it a splin!
Could someone please share how such open source micro-LLMs might have been created?
Do the creators take something like DeepSeek, and then delete most of the neurons to whittle down the size?
There's a Manning book on creating your own LLM from scratch which answers your question exactly. There's another book from the same publisher specifically about small language models for specialty purposes.
Technically, you could do that, but we trained this one from the ground up!
That sounds like an enormously expensive exercise.
As someone who's done something similar (https://blog.lukesalamone.com/posts/creating-tiny-semantic-s...) the expensive part wasn't the training itself but the data curation and evaluation post-training. For this, getting a reasonable distribution of tool calls when the tool call can be anything isn't easy.
Once you have that, the model is small enough batch sizes are probably enormous and training can probably be done on a consumer-grade GPU in a week or less. Or even faster on a bigger GPU.
At <50M parameters, training costs are completely trivial. You'll spend a lot more on your rent this month.
Haha, my rent is cheap lol
Training scales pretty badly, so smaller models like this are really not that bad in terms of cost.
You can train a model of this size on your laptop in a day.
Another option for something this small and narrowly specialized could be to get traditional LLMs to synthesize the training data. Model collapse is probably less of an issue at this size relative to terabyte sized models.
Your thinking is correct haha
Nice. I used Needle as a router in https://rcarmo.github.io/projects/memento/, need to take a look at this
Insane!
> Turn the lights down low in the bedroom
Sets lights to 30% but also off
> Turn the lights low in the bedroom
Sets lights to on
This is a cool idea but I think humans assume more than 14MB of intelligence. This is like the unhelpful guard in the swamp castle of Monty Python's Holy Grail
Haha, its not a generalist model, cheap devices cannot run LLM in production, so we brig on-device intelligence to them in the size they can. Needle is niche, not a Gemma or GPT replacement.
Right, but I don't think consumers would consider this "intelligence". It's too dumb.
I tested with
python main.py No calculator or math tool available.conclusion: completly useless
Try the following tool description: "Calculate the sum of two numbers. Use for any arithmetic or math question." instead of "Add two numbers." Let me know how it goes, thanks!
It does better with clearer tool description, but we are taking note of these complaints for future improvements.
works better that way, thanks :)
but still struggle when changing the quesion:
>> No calculator or math tool available. Cannot compute numbers.Ah, another failure point on our end! So a simple "5 + 7" and "add 5 and 7" works. But to handle ambiguity, the python package ships pipelines to synthesize augmentations and fine-tune on your samples for robustness. Just run "needle playground" and use the UI. Apologies.
Thanks, we shall improve this for the next release.
This is cool!
While most of the industry focuses on the frontier of “intelligence” (function), a release like this represents the frontier of the other end of the spectrum (form).
Both are important if we ever want to see “Opus-level” capability running locally on commodity machines in the future.
agreed, this is where we have the biggest opportunity for innovation.
thanks!
Its pretty significant you've got this working locally in wasm. Very cool.
Re: robotics: I'm unsure how this could be helpful.
It fails a pretty simple navigation prompt.
X0: (0.0, 0.0). Object bounding box: [1.0, 1.0, 2.0, 2.0]. navigate to (3.0,3.0)
I changed it to "call path planner to navigate: a_star(x0, xf, obs)"
Another fail.
My intuition tells me micro llms will/are important for robotics. I just can't grok it. Can someone without control theory experience give me a good example?
Probably at the planning level of the navigation stack. That's where I see reasoning being helpful. Lower than that...idk
Give me an example of a robotics prompt that seems useful and I'll give you an example why we don't need LLMs to be a tracking controller, etc.
Curious, why did you go down to 2bit rather than 4 bits? 4bit with folding the layers should arrive at the same size, but with better quality?
A lot of Needle 1 users deployed on microcontrollers, we couldn't just throw them under the bus only t chase benchmarks, so its a price we are willing to pay :(
This is really cool, I'm curious how much knowledge can their be in smaller models? It seems the current trade off is you need sizeably larger models for more performance but I'm curious if in your work how far this is true, as edge ai is really what needs to get better before physical ai can take off (my two cents).
I imagine at such a low parameter count, there would be little to no world knowledge whatsoever, and the entire focus is on getting the structure of tool calling etc. right…?
But yeah, in terms of “physical” AI, robotics definitely comes to mind for me as well, where tool calls/structured “device” use in a “realtime”/edge application are highly beneficial (if you wanted to go with LLMs), but beefy hardware can’t be easily used.
Roman from Cactus here -
yes you're right, there's only so much a 14MB model can do.
Needle excels at in-conext inference, with tightly defined environments. In our experience:
accurate descriptions + narrow tool scope = success
Makes me think of the demo from some time ago where someone got a ~29M parameter model running on an esp32. I wonder what kind of throughput this could get if a handful of esp32s were strung together...
Edit: I have a pile of d1 minis, but not much time.
That demo was Needle 1 indeed and we are creating the guide for ESP32 now as we speak.
They mention that this specific model is able to run on an ESP32-S3, or an ESP32-P4 which has 32MB of PSRAM. I'm trying to figure out how to do this now.
What about use case for replacing regex? I.e "random formatted title.extension" - extract the title or some tag or something for more dynamic string manipulation for pulling structured data out of strings efficiently and more simply than regex provides?
Congrats on this release. The WASM implementation is really cool. This is a surprisingly good fit for a lot of cases, and I totally want to try turning this into a helper assistant for an application.
Please, though, take a pass at humanizing the text on the page. It's Clauded up all over and makes it hard to read.
> turn on the tv
{ "function_calls": [ { "name": "lock_door", "arguments": { "door": "tv" } } ], "confidence": 0.0158 }
Very interesting, seems confidence is 0 when tool calls are right?
You may want to reword that.. what do you think 0 confidence means... ?
I wonder if there's any way to get this to plan out a dag of tool calls? i.e. use the results from earlier calls as the parameters to later ones? I tried introducing a stack based system, but gave up pretty quickly.
Yes, though for better results in production, after creating your tool json, use the provided data synthesis and fine-tuning pipeline. It tunes on on your mac.
Was really cool to see yous use Engrams to cut down compute!
Given its basically an O(1) lookup with disk space being the main constraint, I was curious if you've tried ablating engram layers and sizes across your setup?
Also, why mHC over attention residuals?
Yes, we ablated Engrams rigorously and found that it returned world knowledge like FFN without without compute expenditure.
What about mHC? I'm surprised it helped with such a small compute budget.
Naïve and clumsy question: how would you pair this with speech-text-speech stuff, wake words etc.? Are there good examples of this for a Pi 5?
The demo is super — I'm just having trouble seeing the whole picture for e.g. a screenless device.
ETA: pun not intended
The best entrypoint is Home Assistant: https://www.home-assistant.io/
That will get you a lot further than what you're asking, but if you dig a bit through Home Assistant features, resources, etc., you may find the current "best" answers to your questions.
If you want a quick answer: Whisper is a good open-source speech-to-text model which comes in a variety of sizes (https://huggingface.co/openai/whisper-tiny). You can definitely get something like this running on a Pi 5. There are plenty of other STT models out there, some of which are built specifically for this context (again, see the Home Assistant stuff), but Whisper comes up a lot as a good default choice.
So with something like Whisper, you could just have a simple script which is constantly listening to a rolling window of audio and transcribing it. When the transcription includes a key phrase, you can pass the rest of the transcription to Needle2 (or anything else for that matter). From there, you take the results and execute the necessary tool calls.
There's a bit more to all of this to make it work smoothly, but fundamentally this is all there is to it. All this would work very fast on a Pi 5 (although I wouldn't expect the results to be particularly good without some serious hand-crafted logic, fine-tuning, etc.). If you want to mess around this stuff, handing all of this to Claude, Codex, etc., can get you something spun up and functional very quickly.
The wyoming protocoll seems to be the path for home assistant audio, so you need STT (wyoming-faster-whisper), TTS (wyoming-piper for wide language support) API endpoints and some Ollama or OpenAI API endpoint available for your home assistant server.
That is interesting, thanks. And I see separable wake-word detection there. I'd always assumed that was likely to be closer to the metal (more like recognise a sound than turn sound to word).
This is a very responsive answer, thank you so much. (I'd assumed maybe Whisper but the wake word "loop" detail there is illuminating.)
Users often stack a transcription model on top to get the voice prompt, then decode to actions. Think of Alexa and Siri.
Thank you.
How many languages does it supports in such a small size?
7 for now, English, German, Polish, French, Dutch, Latin, Italin.
Tested with german and this kinda works, but confidence suffers.
Looking forward to npm version of needle-rs supporting v2. I added needle support for tool use in my side project.
thanks, give the playground a go and let us know how to improve!
I tried tweeking for structured extraction, but got issues with token budget. What is the context size?
Any instructions available for running this on an ESP32-S3 or P4 like the site says?
Hey! Roman here from Cactus - yes, we're putting putting together a detailed guide for ESP32.
In the meantime, if you have enough RAM for the current model (≈28MB), our repo will get you up & running:
https://github.com/cactus-compute/needle
I’d be interested in attempting to run this in a network- enabled 32MiB RAM microVM.
Thanks, how can we help?
This is so cool! Congrats to the team!
Thanks!
these micro LLMs could be a game changer for hearing aids
so many interesting lowfi hardware use cases
Exactly the use cases we designed Needle for!
Is there a prebuilt apk somewhere?
there are android binaries you can ship in your own app - https://huggingface.co/Cactus-Compute/needle2/tree/main
but if you're just looking for somewhere to try the model, use our in-browser playground! - https://cactuscompute.com/needle
"make it as dark as possible"
... maybe this counts as dark humor at least.Since it seems limited to matching a few templates and otherwise falling flat on its face, I wonder how 14MB of regexes would fare in its stead. Normally you wouldn't want to parse arbitrary natural language input with regex because of how tedious and brittle it would be, but for the tedium we have LLMs and this alternative isn't exactly robust either.
SO when confused, it gives you a low confidence score as a signal, in which case its recommended to finetune using th python package, train on your mac/PC
I also wonder how small a LLM trained on catching only subject (e.g. living room) and action (light on) from text input could be compared to needle - the json wrapping could be done afterwards using templates.
The problem is the target device, an LLM can't run on an average TV well.
Any plan to release on ollama?
Yep
Great work! Keep it up
If you want Needle2 to rget lots of testing, become well known, etc - make a Home Assistant plugin.
hey Kenny, Roman from Cactus here -
could you say more? What kind of home assistant / what stack
This is very interesting! I'm going to spend some time with this. This is really the only class of LLM I'm interested in at all. I sincerely hope on-device takes over and everyone looses their asses on these data centers.
Thanks! Let us know how it goes :)
What is the difference between this and random sentence generator?
Random sentence is not a function call.
Ask it to lock a door for instance. It seems to convert simple instructions to reasonable tool calls. Check its confidence score.
Utterly Fascinating!
For the longest time, I conceptualized LLM's as Text Input -> Text Output transformers, then later as Text Input -> Video Output transformers. Later still I conceptualized them (if they were general purpose) as Any Format Input -> Any Format Output transformers...
The idea of a smaller parameter model runable on smaller/slower/less complex hardware (computers with no GPU, slower CPU's, less memory, aka "Edge Devices") trained for Text Input -> JSON Output (used for tool calls, etc.) I could honestly not conceptualize before seeing the demo on the web page...
But now that I've seen it and conceptualized it -- I'd have to say: "Yes, there's definitely a huge niche, a huge market for this, directly between the non-LLM driven tools and software and SaaS's of yesteryear, and the latest, cutting edge Frontier AI models of today!"
So, I like Needle a lot!
I like Needle a lot, and I love the idea of any tiny resource-thrifty LLM that can run on older hardware, that outputs only JSON!
I can see a huge market for it!
You explained it better, we've done a bad job at communicating its nice :(
what does the first L mean in LLM?
Fwiw people have told me that GPT2 doesn’t qualify as an LLM at 550MB despite being one of the first LLMs.
So the practical answer to your question is: not much.
it stands for Lets-not-be-sarcastic :)
The learned confidence gate is the crucial piece for a 14MB action model. On ambiguous requests such as the HN example, what calibration target decides between abstaining locally and escalating to the cloud?
around +60% confidence threshold is cool from experiments, the problem is that you gotta test on your own workload, no existing benchmark could honestly paint the full picture, so we exposed the confidence threshold for everyone.