Show HN: Needle2: 14MB agentic LLM for phones, wearables, smart home and robots
cactuscompute.comHey HN,
Henry from Cactus here!
We previously released Cactus Needle, a 14MB agentic LLM for tool call, device use, and structured extraction for phones, wearables, smart homes, small robots and microcontrollers. We got really great feedback here, and have now incorporated the suggestions to release Needle 2.
The whole model is a single 14MB binary that runs a full session in 28MB of RAM; 45m parameters at 2bit compression. Needle hits 500 tokens/sec decode speed on a Raspberry Pi 5, sits between 400-1,500 tokens/sec on VR devices like Meta Quest 3S and Apple Vision Pro, and ranges 300-700 on sub-$200 phones such as the Samsung A-Series.
On the tool call and mobile device use benchmarks, Needle 2 trades wins with closest small models like LFM2.5 230M and Apple Foundation Model, at 5x to 70x smaller, both at f16 vs Needle 2 at 2bit. Needle is based on Simple Attention Networks from our paper (https://arxiv.org/abs/2607.18363).
Edge AI has lately meant Macs and PCs, but that is just 1.5 billion of over 21 billion connected IoT devices in the world today, and in emerging markets most phones ship under $200, no NPU, cheap GPUs. These include budget phones, Raspberry Pis, microcontrollers, wearables, small robots like Reachy Mini, and connected home devices.
A conventional transformer of Needle's width and depth spends 164 MFLOPs per token, and even one squeezed down to Needle's parameter count spends 87, Needle spends 70. Even on a high-end phone, an always-on assistant lives inside a power budget; every MFLOP is milliwatt-hours, and Needle spends 7x to 85x fewer of them per token than the smallest performant LLMs. More about the architecture in the link.
When we structure intelligence for consumer devices as functions with typed parameters, the only hard part is mapping a messy sentence onto them; which function, with which values. Our research found that when framed that way, the problem needs no world knowledge and no open-ended prose, which is why 45M parameters suffice.
Needle 2 expands to structured extraction where the schema can be passed in-place of tools and the model returns structured output. You can use Needle as a text-classification model with an enum field, as a summarization model by providing a schema that extracts key fields, everything but free-range decode.
Every product has its own tool vocabulary and fine-tuning needle helps it achieve frontier-level performance on custom tasks, so using the python package (https://github.com/cactus-compute/needle), Needle can be fine-tuned Needle on a Mac/PC in minutes to a few hours, with automated data-generation pipeline, just pass a couple samples.
Nonetheless, every response carries a learned confidence score based our Cactus Hybrid technique. If above your threshold, act, below it, escalate to the cloud or bigger model. Combining Needle 2 with a private DeepSeek-v4-Flash deployment works particularly well for enterprise-level tasks at barely any cost, we can help with this setup.
We have put a lot of thoughts into Needle 2 but might still be missing quite a lot, please use the playground in the provided link to test Needle and share your thoughts, always appreciated!
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.
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.
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.
It also seems to have far more tokens per second than needed for general "close the blinds" "tool_call(blinds, CLOSED)".
I do wonder if more smartness could be had by using sparser experts.... And possibly even having some kind of expert switching penalty to try to reduce the amount of data read from read only flash memory by encouraging subsequent tokens to use already loaded experts.
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
It's called a LM :). LLM stands for Large Language Model.
LLM as in Little Language Model
TLM
Ok we'd be adopting Little Language Model officially haha
lLM
basically SLM - Small Language Model
> Like, what does a 28MB binary get you?
For one thing, on beefy-enough recent CPUs, you could keep the weights hot in the L2 cache of a single CPU core. (Which is clearly not the use-case, but might be interesting to those looking for extreme TPS numbers. Or perhaps for efficient training!)
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.
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?
It's not a conversational model. It's meant as a local tool calling model.
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
Yes, and it seems the tool called here was the thermostat, to set the mode literally the opposite of what was requested.
"Make it warmer"
tool that cools room called
Try asking it to set the thermostat to a value. It's a very small model, there's not much reasoning capability
Language models were supposed to be more flexible than Siri.
Otherwise why bother with an LM? 14MB can fit a lot of regexes for fixed sentences.
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.
But this isn’t a query that should need to be forwarded to the cloud for acting on!
I don't know, the back of my napkin says you'll need consensus of at least three servers in order to complete the command.
It is a 14MB model. You don’t need servers to run it. Check your napkin well.
I am sorely dissappointed that the state of the internet has become such that my sarcasm was not only possibly but actually missed.
Mine too! I was not serious. I was just answering your napkin joke. But when I reread now, it is not that obvious. I guess with text you can pass only so much of emotions.
Ah no harm, then. I considered /s, but I really thought it should be plain that I'm not crazy enough to believe one would need any more than a single local device to process such a relatively low complexity command.
Considering this is a 14MB model running almost in a microcontroller, I am fine with such ‘ambigiuous’ queries cannot be handled, as long as the model confidence score is accurate. By the way, I did not test this model thoroughly. I am speculating on the potential of a small model like this. I don’t know if this one is good enough or not.
but wouldn't it need to know the current temp for that to work? my understanding was that the model is best at tool calling
In what world would this make any sense at any temperature?
> 'warmer' implies need for cooling
"It has gotten warmer" could imply a desire to return to homeostasis.
Now you are just making stuff up. The original query was "Make it a little warmer in here". Just because you can come up with some sort of context where the word warmer could mean that you want it cooler does not mean it fits in this scenario which is exactly what people are using LLMs for - to actually understand that context, if it can't do that it's worthless
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.
no, this is the appropriate response to hearing the words "HN" :P
Was that the first message you sent it?
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!
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.
Ah, my bad. I may have misread it.
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.
"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?
yeah I got the same, almost like its biased heavily towards that as the 0 ranking -- my prompt was just the word 'potato'
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?
confidently stating that the confidence is right seems like a big claim
I've got an identical output with the prompt "do not lock the door".
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 }
Cannot unlock, though:
Prompt: "Unlock my doors"
{ "function_calls": [], "reasoning": "No tool for unlocking or locking door exists. lock_door only performs lock/unlock actions, not unlock.", "confidence": 0.9492 }
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?
Technically, you could do that, but we trained this one from the ground up!
That sounds like an enormously expensive exercise.
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
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.
You can train a model of this size on your laptop in a day.
So is the challenge, now, getting the right sort of data?
Training scales pretty badly, so smaller models like this are really not that bad in terms of cost.
At this size, it certainly doesn’t have to be.
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
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.
Specifying units seems to be unreliable; I tried adding a description to the set_thermostat temperature:
Set the living room temperature to 70 degrees Celsius
Set the living room temperature to 70 degrees Fahrenheit
Set the living room temperature to 70 degrees
Trying "in degrees Fahrenheit" for the tool description had similarly counterintuitive confidences.
Edit: to be clear, the counterintuitive behavior is that the confidence ended up higher for the wrong units.
Can you share more about the architectural/design tradeoffs you considered or decided upon? Particularly for me, why is a model that is intended mainly to just make tool calls and marshal the results back focusing on speed? Speed as an inherent result of small size, I get, but speed as a design focus confuses me because it’s simply not going to be dealing with large outputs as a rule, wouldn’t it be better to trade some of that raw speed for better smarts?
For example, I mocked a dumbed down version of what would be a reasonable intermediate tool call prompt:
> It's currently 58 degrees. User asks for house to be 8.5 degrees warmer. What temperature to set thermostat to?
The reply?
Reasoning: “User asks for temperature to set thermostat to 8.5 -> set_thermostat with temperature=8.5.”
Sounds like something Siri would do!
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.
thanks!
agreed, this is where we have the biggest opportunity for innovation.
Nice. I used Needle as a router in https://rcarmo.github.io/projects/memento/, need to take a look at this
Insane!
Why, thank you, I will take that as a compliment
Amazing project. Have you guys thought about running it or adapting it for FPGA-like approaches like this one below that reach Taalas-speed like 20k tok/sec on cheap hardware?
https://www.mikeayles.com/blog/on-chip-llm-kv260/
500 tok/sec is great but this would be 40x and it changes the kind of tasks that it could even be used for if you link it to fast tools too.
Looks incredibly cool, although it ran at ~4 tok/s on my browser (I assume because I've disabled V8). I believe your numbers though. I always wanted to try using something like this to create an AI assistant for my phone. If you try to create something without AI, you'll quickly run into the problem of using NLP to map input to the equivalent of AI tool calls. On the other hand, shelling out to a full-blown LLM for every input is slow, costly and if you want it local, greatly restricts its computing power and the number of devices it can run on. Needle and similar models solve this problem nicely: they're incredibly cheap and handle NLP (not in a predictable way of course, but with great success rates), so you can quickly run predefined actions or shell out to a proper LLM for more complicated tasks. You have the best of two worlds.
You may have inspired me to give it a try!
Please give it a try and let us know!
310 tok/sec on my browser, hm.
Now you can try running the python package directly on your Mac to see proper speedup. WebAssembly has some limitations, running on pure hardware, especially ARM-based to see thousands (which 99% of consumer devices are ARM).
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.
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
I don't quite get what this can be used for.
It cannot be used for direct customer interaction, it's simply too limited.
Nobody wants to say "lock the front door", they would just do it
And even quite direct commands like "tighten security" are not understood by the model
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.
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.
That demo was Needle 1 indeed and we are creating the guide for ESP32 now as we speak.
I tried using it on my x86_64 desktop. Could not use it.
Then I tried using it on a raspberry pi 4. Did not work.
This is specifically for 64 bit arm. I see no reason why you could not enable desktops as well? Just a matter of compilation
When I asked it to call my cable company I got this response. I am wondering how this response comes out… why does it say lights twice and not mention door? LLMs are a mystery to me but I suppose this reasoning is at the heart of the model and it’s only 40% confident in it
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 so cool but for me safety remains my priority first in place. So, if it violates my registered rules, and does what it wasn't supposed too, then what next.
Today AI agents are becoming difficult to safety most especially in critical sectors like banking, a mere mistake may lead to loss of cash or life if it's a hospital
My question is how safe is it for critical sectors
great job! https://github.com/memovai/mimimodel i made it run on esp32s3, and it works!!!
This is great, I have tried a couple different ways to hook up my Home assistant with Openclaw, Maybe my claw is bloated but a custom agent implementation which just has access to HA tool calling performs way better, although it costs money(Claude API). Would love to give this model a try and see how it performs.
> set lights on
{ "function_calls": [ { "name": "set_lights", "arguments": { "room": "bedroom", "state": "on" } } ], "confidence": 0 }
is confidence 0 that its confident?
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.
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
I think they're talking about you making Cactus Needle be an engine to respond to user queries in Home Assistant by making a custom add-on.
https://www.home-assistant.io/voice_control/best_practices/
https://developers.home-assistant.io/docs/core/llm/
https://developers.home-assistant.io/docs/core/entity/conver...
Something like the Ollama integration:
https://www.home-assistant.io/integrations/ollama/
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?
> 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... ?
> 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.
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 :)
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
Users often stack a transcription model on top to get the voice prompt, then decode to actions. Think of Alexa and Siri.
Thank you.
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.
This is a very responsive answer, thank you so much. (I'd assumed maybe Whisper but the wake word "loop" detail there is illuminating.)
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).
Also worth checking out https://github.com/OHF-Voice/linux-voice-assistant
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.
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 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.
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 :(
I see the reasoning is always last, but I have seen models do better if you put the reasoning as the first json fileld
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?
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!
I’d be interested in attempting to run this in a network- enabled 32MiB RAM microVM.
Thanks, how can we help?
For the microcm, take a look at https://shellbox.dev, se3ms like a good fit. Real linux, and very affordable
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.
What’s one of the most impressive usecase or example?
"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.
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.
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
How many languages does it supports in such a small size?
Tested with german and this kinda works, but confidence suffers.
7 for now, English, German, Polish, French, Dutch, Latin, Italin.
It seems to fail. I sent the prompt:
“ 5° warmer”
And it said:
“ setting the temperature to 5°F”
Did you give it a tool to increase temperature, or only one that sets temperature to an absolute value?
Either way, setting temperature to 5° is obviously wrong - even if it knew the current temperature - but models of this size can't reason about relative values very well.
Give it a tool to change temperature by a given amount, and see what happens!
This is so cool! Congrats to the team!
Thanks!
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
Any plan to release on ollama?
Yep
This is awesome. I will take some time to dig in. When I am not working for client(s), I focus entirely on tiny LLMs - I have specific approach to prompting, avoid multi-turn chat and build harness to fit the selected LLM as closely as possible.
My experiments are in https://github.com/brainless/
I will be happy to share what I learn.
Great work! Keep it up
how to use it on laptop or Android?
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.
I don't think some people are aware that "large" has always referred to the training inputs not resulting the size of the model.
LLM is not "we made a language model and it is big" -- it's "we trained this model on a lot of language"
Not aware of that etymology
it stands for Lets-not-be-sarcastic :)
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 :)
Thanks, we shall improve this for the next release.
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.