Needle Cactus Compute: Ein kleines KI-Function-Calling-Modell

Veröffentlicht

16. August 2026

Autor

Faizan Nadeem

Die Grundlagen

Was Needle tatsächlich abdeckt

Needle löst genau ein Problem: Gegeben eine Anfrage und eine Menge deklarierter Tools, entscheiden, welches Tool aufgerufen werden soll und mit welchen Argumenten — oder explizit ablehnen, wenn nichts Deklariertes passt. Eine Aktion auszuführen und strukturierte Daten aus Text zu extrahieren, sind unter der Haube dieselbe Operation; der einzige Unterschied ist, was als „Tool“ deklariert wird. Das ist absichtlich eng gefasst, und genau diese Enge ist der ganze Punkt. Tool Calling ist im Kern eine Retrieval-und-Assembly-Aufgabe — eine Anfrage einem Tool-Namen zuordnen, Argumentwerte aus der Eingabe herausziehen, gültiges JSON ausgeben — und kein offenes Schlussfolgern. Ein Modell, das speziell für diese Aufgabe gebaut ist, braucht nicht die enorme Allgemeinwissenskapazität, die ein Chatbot benötigt. Genau deshalb können 45 Millionen Parameter, komprimiert in eine 14MB-Binärdatei, sich bei genau dieser Aufgabe gegen Modelle behaupten, die um ein Vielfaches größer sind.

Warum dies ein wertvolles Problem ist, das gut gelöst werden sollte

On-Device-AI hat reale Einschränkungen, die ein Cloud-Modell nie erfüllen muss. RAM im Bereich von einigen Dutzend Megabyte, keine garantierte Netzwerkverbindung und Batterie-Budgets, die ein Modell mit 1B+ Parametern auf einer Uhr oder einer Brille sofort ausschließen.
Latenzkritische Funktionen sollten überhaupt nicht zu einem Cloud-LLM greifen. Ein Roundtrip zu einem gehosteten Modell für „mach das Licht aus“ ist sowohl langsamer als auch weniger privat als ein Modell, das bereits auf dem Client lebt und sofort antwortet.
Strukturelle Garantien sind für diese Aufgabe wichtiger als rohe Fähigkeiten. Ein Tool-Calling-System, das gelegentlich fehlerhaftes JSON ausgibt oder einen Parameter halluziniert, ist nicht nur unpraktisch — es ist eine kaputte Integration. Das gesamte Design von Needle ist darauf ausgelegt, diese Fehlerklasse strukturell unmöglich zu machen, statt sie nur statistisch selten zu halten.

Die vollständige Architektur

Tool schemas ──▶ Grammar compiler (byte-level)
                         │
Query + schemas ──▶ Simple Attention Network ──▶ constrained decode ──▶ structured call
                                                                              │
                                                                       execute locally
                                                                              │
                                                                    result fed back in
                                                                              │
                                                                        next turn / final answer

Das Leitprinzip lautet: Die einzigen Freiheitsgrade des Modells sind die, die die Grammatik erlaubt. Korrektheit wird konstruktiv erzwungen — eine aus den deklarierten Schemas kompilierte Byte-Level-Grammatik beschränkt jedes Token beim Decoding — und nicht dadurch, dass man hofft, ein viel größeres und langsameres Modell werde sich schon korrekt verhalten.

Kernschichten erklärt

1. Die Simple-Attention-Network-Architektur

Was sie ist: Das dichte Small-Model-Rezept von Needle 2, beschrieben in Cactus’ eigenem Paper (arXiv:2607.18363). Anstelle eines Standard-Feed-Forward-Blocks verwendet es ein auf Hadamard-Transformation basierendes MLP, Grouped-Query-Attention, einen „Engram“-Key-Value-Speicher aus gehashten n-Gramm-Tabellen sowie Multi-Lane-Hyper-Connections, die mehrere Residualströme kombinieren. Das Routing zwischen den Komponenten wird über Sinkhorn-Iteration statt über ein einfaches Softmax normalisiert.

Warum sie wichtig ist: Jede dieser Entscheidungen tauscht einen Teil der „allgemeinen Fähigkeit“ ein, für die ein Standard-Transformer normalerweise Parameter aufwendet, gegen auf diese Aufgabe zugeschnittene Effizienz. Das ursprüngliche 26M-Needle ging sogar noch weiter und nutzte reine Attention und Gating ganz ohne Feed-Forward-Layer — in der Annahme, dass Tool Calling nicht die Art von assoziativem „Wissensspeicher“ braucht, den ein FFN typischerweise bereitstellt. Needle 2 führt wieder ein leichtgewichtiges MLP ein, aber absichtlich ein günstiges, das auf einer festen, gewichtslosen Hadamard-Transformation statt auf einer dichten Matrix basiert.

Produktions-Tipp: Erwarten Sie nicht, dass diese Architektur auf offene Chat-Qualität generalisiert — sie ist gezielt auf die Retrieval-und-Assembly-Struktur von Tool Calling optimiert, und genau diese Spezialisierung macht sie klein genug, um in 28MB RAM zu laufen.

2. Byte-Level-Grammar-Constrained-Decoding

Was es ist: Jedes Tool-Schema, das Sie deklarieren, wird in eine Grammatik kompiliert, die einschränkt, welche Tokens das Modell bei jedem Decoding-Schritt überhaupt ausgeben darf. Das Modell kann kein fehlerhaftes JSON, keinen unbekannten Tool-Namen und keinen Wert erzeugen, der gegen eine deklarierte Einschränkung verstößt — nicht, weil es darauf trainiert wurde, es nicht zu tun, sondern weil die ungültigen Tokens beim Decoding schlicht nicht verfügbar sind.

Warum es wichtig ist: Damit wird aus „das Modell sollte gültiges JSON zurückgeben“ keine probabilistische Hoffnung mehr, sondern eine Garantie. Einschränkungen wie Wertebereiche, Regex-Muster, String-Längen und Enums — alles, was im Schema ausdrückbar ist — werden direkt in die Grammatik kompiliert, sodass ein Argument außerhalb Ihrer deklarierten Grenzen buchstäblich nicht erzeugt werden kann.

Produktions-Tipp: Verlagern Sie Validierung nach Möglichkeit in Ihr Schema, statt sie nachträglich im Anwendungscode zu prüfen. Ein Literal["heat", "cool", "auto"] oder ein von Anfang an deklarierter Zahlenbereich bedeutet, dass das Modell überhaupt keinen ungültigen Wert ausgeben kann — es gibt später schlicht nichts mehr abzufangen.

3. Confidence Gating

Was es ist: Jede Antwort trägt einen Confidence-Score, der das Minimum aus zwei unabhängigen Signalen ist: einem kalibrierten Head, der den vollständigen Prompt plus den erzeugten Call bewertet, und der rohen Decoding-Wahrscheinlichkeit der Call-Tokens. Beide müssen übereinstimmen, damit ein hoher Score entsteht.

Warum es wichtig ist: Das gibt Ihnen eine einzelne, fundierte Kennzahl, um eine echte Eskalationsstrategie darauf aufzubauen: lokal ausführen oberhalb Ihres gewählten Schwellwerts, erneut nachfragen oder an ein größeres Cloud-Modell weiterleiten darunter. Der Ausfallmodus, den dieses Design erzeugen soll, ist Eskalation — nicht eine stillschweigend falsche Ausführung.

Produktions-Tipp: Stimmen Sie den Schwellwert pro Anwendungsfall ab, nicht global — ein Smart-Home-Schalter verträgt eine niedrigere Hürde als etwa eine Zahlung oder das Senden einer Nachricht, bei denen ein stillschweigend ausgeführter falscher Low-Confidence-Call deutlich schlimmer ist als eine Rückfrage.

4. Tool Retrieval für große Kataloge

Was es ist: Bei fünf oder weniger deklarierten Tools wird alles direkt in den Kontext gerendert. Darüber hinaus bettet ein eingebauter Retrieval-Head jedes Tool-Schema einmal ein, bettet in jeder Runde die Anfrage ein und reduziert das Feld auf die fünf am höchsten bewerteten Tools — wobei die Decoding-Grammatik nur über genau diese Teilmenge neu aufgebaut wird.

Warum es wichtig ist: Ein nicht ausgewähltes Tool ist nicht nur unwahrscheinlich erreichbar — es ist in dieser Runde tatsächlich unerreichbar, weil die Grammatik selbst nur die abgerufene Teilmenge zulässt. Genau das ermöglicht es einem Gerät, einen großen Tool-Katalog zu deklarieren, ohne entweder das Kontextbudget zu sprengen oder das Decoding zu verlangsamen, weil bei jeder Runde alles berücksichtigt werden müsste.

Produktions-Tipp: Persistieren Sie die Tool-Embeddings auf die Festplatte, statt sie in jeder Session neu zu berechnen. Sie sind über einen Fingerprint auf dem Schema-Set und dem Modell indiziert, sodass ein unveränderter Katalog sofort geladen wird und nur ein tatsächlich geändertes Schema ein erneutes Embedding erzwingt.

5. Begrenzter Speicher unabhängig von der Gesprächslänge

Was es ist: Ein Sliding Window von 256 Tokens verarbeitet die laufende Konversation, während die deklarierten Tools als feste Key-Value-„Sinks“ verankert bleiben, statt aus dem Kontext hinauszugleiten.

Warum es wichtig ist: Der gesamte Speicherverbrauch bleibt nahe bei 28MB, egal wie lange eine Konversation dauert — eine harte Anforderung für alles, was tatsächlich auf einem Wearable oder Embedded Device bereitgestellt wird, wo Speicher, der mit der Nutzung unbegrenzt wächst, schlicht nicht praktikabel ist.

6. System-Fakten, keine System-Instruktionen

Was es ist: Eine optionale System-Runde trägt Umgebungszustand — Datum, Locale, Gerätetyp, Akkustand und ähnlich erkannte Schlüssel — strikt als Fakten, aus denen das Modell schlussfolgern kann, niemals als Instruktionen, die sein Verhalten steuern.

Warum es wichtig ist: Das ist eine bewusste, sicherheitsnahe Designentscheidung. Weil das Modell darauf trainiert ist, dieses Feld als Daten und nicht als Befehle zu behandeln, bekommt dort platzierter Text keine Chance, das tatsächliche Verhalten des Modells zu überschreiben oder umzulenken — damit wird eine Klasse prompt-injection-artiger Manipulationen ausgeschlossen, die ein permissiveres „System Prompt“-Design offenlassen würde.

Produktions-Tipp: Relative Zeitangaben („morgen um 7“) können nur dann aufgelöst werden, wenn tatsächlich ein date:-Fakt mitgeliefert wird — ohne ihn reicht das Modell die Formulierung durch, statt einen absoluten Zeitpunkt zu raten, was für alles Zeitsensitive der sicherere Fehlermodus ist.

7. LoRA-Fine-Tuning auf einer gewichtsagnostischen Engine

Was es ist: Needle führt Fine-Tuning mit LoRA gegen ein eingefrorenes Basismodell durch, merged dann den Adapter und quantisiert das Ergebnis in eine einzelne .cact-Datei — ein in sich geschlossenes Artefakt, das auf exakt derselben Inference-Engine läuft wie das Basismodell, ohne separaten Build-Schritt.

Warum es wichtig ist: Das macht die Spezialisierung des Modells auf den eigenen Tool-Katalog wirklich kostengünstig, und das Ergebnis bleibt genauso einfach bereitzustellen wie das Original: eine Datei, eine Engine, keine Neukompilierung.

Produktions-Tipp: Wenn Sie noch keine gelabelten Beispiele haben, kann die Toolchain Trainingsdaten direkt aus Ihren Tool-Schemas über einen OpenRouter-gestützten Generierungsschritt synthetisieren — ein sinnvoller Weg, ein erstes Fine-Tuning zu bootstrappen, bevor echte Nutzungslogs zum Lernen vorliegen.

End-to-End-Durchlauf

Verfolgen wir eine Anfrage von der Query bis zur ausgeführten Aktion:

Tools werden deklariert, entweder als dekorierte Python-Funktionen oder als rohe JSON-Schemas — zum Beispiel ein set_lights-Tool mit den Parametern room, on und brightness.
Der Grammar Compiler baut aus diesen Schemas eine eingeschränkte Decoding-Grammatik, sobald die Tools registriert werden.
Eine Anfrage trifft ein: „dim the living room to 30.“
Das Modell verarbeitet die Anfrage gegen die deklarierten Tools und erzeugt einen Call, wobei jedes Token durch die kompilierte Grammatik eingeschränkt ist — strukturell ist es unmöglich, einen Call an ein nicht deklariertes Tool oder ein fehlerhaftes Argument auszugeben.
Die Antwort enthält den Call selbst, eine kurze natürlichsprachliche Reasoning-Spur und einen Confidence-Score — etwa set_lights(room="living room", on=true, brightness=30) mit hoher Confidence.
Die Confidence überschreitet den konfigurierten Schwellwert, daher wird der Call lokal ohne Eskalation ausgeführt.
Bei einer mehrstufigen Aufgabe — etwa „message Alex that I’m running late“ — ruft das Modell zunächst ein search_for_contact-Tool auf; das Ergebnis (eine Kontakt-ID) wird in die nächste Runde zurückgeführt, und das Modell ruft dann send_instant_message mit dieser zurückgegebenen ID auf und verkettet so Calls, wie es ein längerer Workflow erfordert.
Eine abschließende Runde kann in Klartext antworten, sobald alle notwendigen Calls abgeschlossen sind; dies wird als eigener „respond“-Typ ohne weitere angehängte Function Calls zurückgegeben.

Sonderfälle

Extraktion ist Tool Calling mit genau einem Tool. Wenn man ein einzelnes Schema deklariert — eine Datensatzform wie eine Rechnung oder ein Beleg — und Text dort übergibt, wo sonst eine Query stünde, erhält man die geparsten Felder als Argumente dieses Schemas zurück. Weil nur ein einziges Tool deklariert ist, lässt die Grammatik genau einen Call dieses Namens zu, sodass Schemakonformität garantiert und nicht nur wahrscheinlich ist.

Themenfremde Anfragen bekommen eine strukturierte Ablehnung, keine Freitextantwort. Wenn keine deklarierte Funktion eine Anfrage bedienen kann, gibt das Modell einen leeren Call zurück. Es gibt keinen Fallback auf Konversationstext — genau das ist der gesamte Vertrag für den Umgang mit allem außerhalb des deklarierten Geltungsbereichs, und genau das hält das Verhalten des Modells in einer Embedded-Integration vorhersagbar.

Optionale Argumente werden weggelassen, nicht erraten. Wenn die Eingabe keine Evidenz für ein optionales Feld liefert, wird es im Call vollständig ausgelassen, statt mit einer plausibel klingenden Vermutung gefüllt zu werden — dieselbe Disziplin, die bei ganzen themenfremden Anfragen gilt, gilt auch für einzelne Argumente.

Skalierungs- und Produktionsherausforderungen

Fine-Tuning im Flottenmaßstab muss dennoch in denselben winzigen Footprint passen. Ein LoRA-Adapter wird zurück in eine einzelne quantisierte .cact-Datei gemerged, was bedeutet, dass die Spezialisierung des Modells pro Kunde, pro Geräteklasse oder pro Tool-Katalog die Deployment-Komplexität nicht vervielfacht — jede Variante läuft weiterhin auf derselben leichtgewichtigen Engine.

Die Abstimmung des Confidence-Schwellwerts ist eine laufende operative Entscheidung, keine einmalige Einstellung. Wenn Ihr Tool-Katalog wächst oder sich Nutzungsmuster verschieben, kann der richtige Eskalationsschwellwert für eine bestimmte Aktion mitwandern — behandeln Sie ihn als Kennzahl, die überwacht werden muss, nicht als Konstante, die einmal gesetzt und dann vergessen wird.

Die Retrieval-Qualität wird wichtiger, je größer Ihr Tool-Katalog wird. Jenseits von fünf Tools hängt die Korrektheit davon ab, dass der Retrieval-Head in jeder Runde tatsächlich die richtigen fünf Kandidaten nach oben bringt — ein Katalog mit vielen Beinahe-Duplikaten oder schlecht beschriebenen Tools wird die Retrieval-Genauigkeit verschlechtern, lange bevor die rohe Kapazität des Modells ausgeschöpft ist.

Dies ist ein schmal spezialisierter Experte, und ihn wie ein allgemeines Modell zu benchmarken, verfehlt den Punkt. Needle tauscht Erfolge mit auf Function Calling fokussierten Modellen, die um ein Vielfaches größer sind, bei der Genauigkeit einzelner Tool-Calls — aber dieser Vergleich bezieht sich ausdrücklich auf Tool Calling, nicht auf allgemeines Schlussfolgern oder Konversation, und starke Function-Calling-Benchmarks als Beleg für breitere Fähigkeiten zu behandeln, wäre ein Fehler.

Codebeispiele

Ein Tool mit einem Decorator deklarieren — Signatur und Docstring allein reichen für einfache Fälle aus:

import needle

@needle.tool
def get_weather(city: str):
    "Get the current weather for a city."
    return {"city": city, "temp_c": 27, "sky": "clear"}

agent = needle.Needle(tools=[get_weather])
print(agent.run("what's it like in Lagos right now?"))

Reale Einschränkungen hinzufügen — Bereiche und Muster, die direkt in die Decoding-Grammatik kompiliert werden:

from typing import Annotated

@needle.tool
def send_money(
    amount: Annotated[float, needle.Field(gt=0, le=10000)],
    to: Annotated[str, needle.Field(pattern=r"^@[a-z0-9_]+$")],
):
    "Send money to a handle."
    return {"sent": amount, "to": to}

Strukturierte Extraktion mit einem typisierten Ergebnis:

from pydantic import BaseModel

class Invoice(BaseModel):
    vendor: str
    total: float
    due_date: str

invoice = needle.extract("Invoice from Acme Corp, $1,200.00, due 2026-09-01", Invoice)

Fine-Tuning auf den eigenen Tools, End-to-End:

needle generate-data --tools my_tools.json --num-samples 500 --output data.jsonl
needle finetune data.jsonl --epochs 3
needle build checkpoints/needle2.pkl --lora checkpoints/needle_lora.pkl --out my_needle.cact

Häufige Fallstricke

Fehler: Needle als kleinen Chatbot behandeln. Es hat absichtlich keinen Freitext-Fallback — jeder Konversationsanwendungsfall außerhalb von Tool Calling oder Extraktion ist die falsche Wahl. Lösung: Leiten Sie offene Konversation an ein General-Purpose-Modell weiter und halten Sie Needle auf strukturierte Aktionen begrenzt.

Fehler: Einen großen Tool-Katalog deklarieren, ohne Retrieval zu berücksichtigen. Jenseits von fünf Tools sind pro Runde nur die Top-5 der abgerufenen Kandidaten erreichbar. Lösung: Schreiben Sie klare, unterscheidbare Tool-Beschreibungen, damit der Retrieval-Head tatsächlich zwischen ihnen unterscheiden kann.

Fehler: Das Confidence-Feld ignorieren. Jeden zurückgegebenen Call zu übernehmen, ohne die Confidence zu prüfen, wirft das eigene Signal des Modells darüber weg, wie sicher es sich ist. Lösung: Setzen Sie einen echten Schwellwert pro Aktion und bauen Sie einen Eskalationspfad für alles darunter.

Fehler: Verhaltensanweisungen in das Feld für System-Fakten schreiben. Das Modell ist darauf trainiert, dieses Feld als Daten und nicht als Befehle zu behandeln, daher steuern dort platzierte Instruktionen es nicht. Lösung: Platzieren Sie Verhaltenshinweise in Tool-Beschreibungen und Schemas, wo das Modell sie tatsächlich als Direktive liest.

Fehler: Bei einer hochspezifischen Tool-Ontologie auf Fine-Tuning zu verzichten. Das Basismodell ist innerhalb von Tool Calling allgemein einsetzbar; ein enger oder ungewöhnlicher Katalog ist möglicherweise out of the box nicht seine stärkste Passform. Lösung: LoRA-Fine-Tuning auf den eigenen Schemas ist günstig genug, um es durchzuführen, bevor man annimmt, dass die Genauigkeit bereits ausgeschöpft ist.

Best Practices für die Produktion

Verlagern Sie Einschränkungen in das Schema, nicht in nachträgliche Validierung. Bereiche, Muster und Enums, die vorab deklariert werden, werden während der Generierung durchgesetzt, nicht erst nachträglich abgefangen.
Bauen Sie einen echten Eskalationspfad rund um den Confidence-Score. Entscheiden Sie pro Aktion, was „unter dem Schwellwert“ bedeuten soll — erneut versuchen, eine klärende Frage stellen oder an ein größeres Modell übergeben.
Halten Sie Tool-Beschreibungen unterscheidbar und spezifisch, insbesondere sobald Sie sich bei einem größeren Katalog auf den Retrieval-Head verlassen.
Behandeln Sie das Feld für System-Fakten ausschließlich als Daten. Verlassen Sie sich nicht darauf, damit Verhalten zu steuern — dafür ist es nicht trainiert.
Führen Sie früh Fine-Tuning durch, wenn Ihr Tool-Katalog ungewöhnlich ist. Ein günstiger LoRA-Durchlauf auf den eigenen Schemas ist ein kleiner Preis im Vergleich zum Risiko, mit einer Basismodell-Genauigkeit auszuliefern, die nicht auf Ihre Domäne abgestimmt ist.

Zum Abschluss

Die eigentliche Geschichte hier ist nicht „ein 26M-Modell kann Function Calling“ — diese Einordnung verkauft sogar unter Wert, was bereits ausgeliefert wurde, denn Needle 2 ist mit einer eigens dafür gebauten Architektur, grammatikgarantierter strukturierter Ausgabe und einem für Produktionseskalation entworfenen Confidence-Vertrag bereits darüber hinaus. Die zugrunde liegende Idee ist die, die man behalten sollte: Nicht jede KI-Aufgabe braucht ein Modell mit Milliarden Parametern, und sobald man präzise weiß, was ein Modell tun muss, ist es besser, sein gesamtes Parameterbudget darauf zu verwenden, genau diese eine Sache gut zu machen, als den Großteil davon für allgemeine Fähigkeiten auszugeben, die man nie nutzen wird.

Beobachten Sie ebenfalls, dass mehr Teams für die engen, strukturierten Teile ihres Agent-Stacks zu spezialisierten winzigen Modellen wie diesem greifen, oder setzt sich in der Praxis weiterhin eher der Drang zu einem einzigen großen General-Purpose-Modell durch?