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.<p>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.<p>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.<p>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.
It also seems to have far more tokens per second than needed for general "close the blinds" "tool_call(blinds, CLOSED)".<p>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 would assume a model this size would require finetuning tbh. even functiongemma recommends that.
14mb? More like sub-$20 devices.
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).
It's called a LM :). LLM stands for Large Language Model.
It's definitely cool that you can get any reasoning whatsoever out of such a small model. That said, its reasoning is "interesting":<p>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)<p>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:<p>Query: "Lock out the vacuum salesman at the front door"
Agent tries to lock "front door vacuum salesman"<p>"The way you talk really makes me appreciate silence" is classified as "positive" with 82% confidence.
Ok, this is genuinely funny, we will fix these as we iterate, thanks lol.
that model is 14MB large what do you expect. but I agree it's funny regardless
Specifying units seems to be unreliable; I tried adding a description to the set_thermostat temperature:<p><pre><code> "temperature": {
"type": "number",
"description": "degrees Fahrenheit"
},
</code></pre>
Set the living room temperature to 70 degrees Celsius<p><pre><code> {
"function_calls": [
{
"name": "set_thermostat",
"arguments": {
"room": "living room",
"temperature": 70,
"mode": "cool"
}
}
],
"confidence": 0.6045
}
</code></pre>
Set the living room temperature to 70 degrees Fahrenheit<p><pre><code> {
"function_calls": [
{
"name": "set_thermostat",
"arguments": {
"room": "living room",
"temperature": 70,
"mode": "heat"
}
}
],
"confidence": 0.4536
}
</code></pre>
Set the living room temperature to 70 degrees<p><pre><code> {
"function_calls": [
{
"name": "set_thermostat",
"arguments": {
"room": "living room",
"temperature": 70
}
}
],
"confidence": 0.8517
}
</code></pre>
Trying "in degrees Fahrenheit" for the tool description had similarly counterintuitive confidences.<p>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?<p>For example, I mocked a dumbed down version of what would be a reasonable intermediate tool call prompt:<p>> It's currently 58 degrees. User asks for house to be 8.5 degrees warmer. What temperature to set thermostat to?<p>The reply?<p>Reasoning: “User asks for temperature to set thermostat to 8.5 -> set_thermostat with temperature=8.5.”<p>Sounds like something Siri would do!
My first query:<p>> Make it a little warmer in here.<p>The reply:<p>> "name": "set_thermostat",
> "arguments": {
> "temperature": 65,
> "mode": "cool",
> ...
> "reasoning": "'warmer' implies need for cooling; set_thermostat with temperature 65 (typical warmth) and mode 'cool'.",<p>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.
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
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.<p>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.<p>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).
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.<p>"Make it warmer"<p><i>tool that cools room called</i>
Try asking it to set the thermostat to a value. It's a very small model, there's not much reasoning capability
Funny result from the web demo. I'm well aware that it's an extremely small and, well, stupid, model, but even so:<p>Query: HN<p>Result:<p>{
"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
}<p>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.<p>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.
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.<p>I am not sure how a micro model will fundamentally solve it. Would love to understand what dannyw and team did there?
"confidence": 0, so I guess you could threshold it
no, this is the appropriate response to hearing the words "HN" :P
It seems to love locking doors. I was hoping this would dim the lights.<p>> I'm hungover<p>{
"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:<p>Prompt: "Unlock my doors"<p>{
"function_calls": [],
"reasoning": "No tool for unlocking or locking door exists. lock_door only performs lock/unlock actions, not unlock.",
"confidence": 0.9492
}
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?
[dead]
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.
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.<p>You may have inspired me to give it a try!
A small on-device model with escalation is compelling. How do you decide when confidence is low enough to hand off to a larger model?
Considering it as a classification problem, you could use a representative set of example queries, feed them to this model, then ask a "smart" language model to assess each query + result for whether the result is actually correct. Then you have a dataset you can compute FPR and FNR for any given threshold, and score based on the context, ex. turning the lights on or off is a lot less important if it is right compared to whether your door is locked. You could even pick it based on the tool call itself: Low threshold for locking the door, high threshold for unlocking the door.
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.
Could someone please share how such open source micro-LLMs might have been created?<p>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!
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.
Congratulations. 28MB is impressive, I've not played around with actual queries/outputs.<p>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,<p><pre><code> - 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?</code></pre>
This is cool!<p>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).<p>Both are important if we ever want to see “Opus-level” capability running locally on commodity machines in the future.
Nice. I used Needle as a router in <a href="https://rcarmo.github.io/projects/memento/" rel="nofollow">https://rcarmo.github.io/projects/memento/</a>, need to take a look at this
Its pretty significant you've got this working locally in wasm. Very cool.<p>Re: robotics: I'm unsure how this could be helpful.<p>It fails a pretty simple navigation prompt.<p>X0: (0.0, 0.0). Object bounding box: [1.0, 1.0, 2.0, 2.0]. navigate to (3.0,3.0)<p>I changed it to "call path planner to navigate: a_star(x0, xf, obs)"<p>Another fail.<p>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?<p>Probably at the planning level of the navigation stack. That's where I see reasoning being helpful. Lower than that...idk<p>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.
I tested with<p><pre><code> import needle
@needle.tool
def add(a: int, b: int):
"Add two numbers."
return a + b
agent = needle.Needle(tools=[add])
print(agent.run("calculate 1 + 1?")["reasoning"])
</code></pre>
python main.py
No calculator or math tool available.<p>conclusion: completly useless
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…?<p>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 -<p>yes you're right, there's only so much a 14MB model can do.<p>Needle excels at in-conext inference, with tightly defined environments. In our experience:<p>accurate descriptions + narrow tool scope = success
> Turn the lights down low in the bedroom<p>Sets lights to 30% but also off<p>> Turn the lights low in the bedroom<p>Sets lights to on<p>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.
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...<p>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.
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?
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.<p>Please, though, take a pass at humanizing the text on the page. It's Clauded up all over and makes it hard to read.
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.<p>My experiments are in <a href="https://github.com/brainless/" rel="nofollow">https://github.com/brainless/</a><p>I will be happy to share what I learn.
> turn on the tv<p>{
"function_calls": [
{
"name": "lock_door",
"arguments": {
"door": "tv"
}
}
],
"confidence": 0.0158
}<p>Very interesting, seems confidence is 0 when tool calls are right?
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.
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?<p>The demo is super — I'm just having trouble seeing the whole picture for e.g. a screenless device.<p>ETA: pun not intended
The best entrypoint is Home Assistant: <a href="https://www.home-assistant.io/" rel="nofollow">https://www.home-assistant.io/</a><p>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.<p>If you want a quick answer: Whisper is a good open-source speech-to-text model which comes in a variety of sizes (<a href="https://huggingface.co/openai/whisper-tiny" rel="nofollow">https://huggingface.co/openai/whisper-tiny</a>). 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.<p>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.<p>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.
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.
[flagged]
Was really cool to see yous use Engrams to cut down compute!<p>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?<p>Also, why mHC over attention residuals?
It seems to fail. I sent the prompt:<p>“ 5° warmer”<p>And it said:<p>“ setting the temperature to 5°F”
Looking forward to npm version of needle-rs supporting v2. I added needle support for tool use in my side project.
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.
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.<p>In the meantime, if you have enough RAM for the current model (≈28MB), our repo will get you up & running:<p><a href="https://github.com/cactus-compute/needle" rel="nofollow">https://github.com/cactus-compute/needle</a>
I’d be interested in attempting to run this in a network- enabled 32MiB RAM microVM.
"make it as dark as possible"<p><pre><code> {
"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
}
</code></pre>
... maybe this counts as dark humor at least.<p>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.
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
This is so cool! Congrats to the team!
these micro LLMs could be a game changer for hearing aids<p>so many interesting lowfi hardware use cases
Is there a prebuilt apk somewhere?
there are android binaries you can ship in your own app - <a href="https://huggingface.co/Cactus-Compute/needle2/tree/main" rel="nofollow">https://huggingface.co/Cactus-Compute/needle2/tree/main</a><p>but if you're just looking for somewhere to try the model, use our in-browser playground! - <a href="https://cactuscompute.com/needle">https://cactuscompute.com/needle</a>
how to use it on laptop or Android?
Any plan to release on ollama?
Great work! Keep it up
If you want Needle2 to rget lots of testing, become well known, etc - make a Home Assistant plugin.
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.
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.<p>So the practical answer to your question is: not much.
it stands for Lets-not-be-sarcastic :)
Utterly Fascinating!<p>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...<p>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...<p>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!"<p>So, I like Needle a lot!<p>I like Needle a lot, and I <i>love</i> the idea of any tiny resource-thrifty LLM that can run on older hardware, that outputs only JSON!<p>I can see a huge market for it!
Rust is a cult
What is the difference between this and random sentence generator?
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
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.