Needle 14MB Tiny LLM: Der komplette Leitfaden

Ein offizieller Projektüberblick beschreibt Needle mit 14 MB, 26 Millionen Parametern und einem Zielbereich von 1.000 bis 6.000 Tokens pro Sekunde auf mobilen Geräten und Wearables. Das bedeutet nicht, dass Needle ein vollwertiger Chatbot in Miniatur ist. Die richtige Entscheidung lautet: Nutzen Sie Needle für Tool-Aufrufe, Befehlsrouting und strukturierte Ausgaben mit begrenztem Vokabular. Für offene Gespräche, allgemeine Wissensfragen und komplexes Schlussfolgern wählen Sie ein größeres Modell. (Projektübersicht von Cactus)

Für wen ist dieser Leitfaden gedacht? Für Entwickler, die Smartphone-, Wearable- oder Smart-Home-Funktionen mit lokaler Tool-Steuerung bauen. Ebenso für Forschungsteams, die Tiny LLM, Modell-Destillation und lokale Agenten untersuchen, sowie für unabhängige Entwickler, die Needle auf einem Mac testen oder feinabstimmen möchten.

Letzte Aktualisierung: 14.08.2026. Daten geprüft anhand des offiziellen Needle-Repositories, der Modellkarte, der Cactus-Dokumentation und der veröffentlichten Versionshinweise.

14 MB bedeuten kleines Modell, nicht 14 MB Laufzeitspeicher

Der wichtigste Denkfehler entsteht bereits bei der Größenangabe. Die 14 MB beziehen sich auf eine kompakte beziehungsweise quantisierte Modellbereitstellung, nicht automatisch auf den gesamten Speicherbedarf während der Ausführung. Zusätzlich benötigt die Laufzeit Speicher für Tokenizer, Eingabepuffer, Zwischenwerte, Ausgabepuffer, Tool-Schemata und gegebenenfalls den Gesprächskontext.

Die offizielle Modellkarte führt Needle als Modell mit 26 Millionen Parametern. Sie beschreibt eine Encoder-Decoder-Architektur mit reinen Attention-Blöcken, acht Decoder-Schichten, zwölf Encoder-Schichten und einem Vokabular von 8.192 SentencePiece-Einheiten. Die Modellkarte nennt außerdem einen Kontext von 1.024 Tokens für eine veröffentlichte Fine-Tuning-Konfiguration. (offizielle Needle-Modellkarte)

Für Ihre Geräteplanung sind deshalb mindestens vier getrennte Größen relevant:

Dateigröße: Wie viel Speicher müssen Sie herunterladen und dauerhaft vorhalten?
Arbeitsspeicher: Wie viel RAM benötigt die Inferenz mit temporären Tensoren?
Kontextbedarf: Wie viele Tool-Definitionen und Eingabetokens werden gleichzeitig verarbeitet?
Laufzeit-Overhead: Welche Komponenten bringt die lokale Engine zusätzlich mit?

Ein kleines Gewichtspaket hilft bei Download, Installation und Aktualisierung. Es beseitigt aber nicht automatisch die Grenzen eines Geräts mit wenig Arbeitsspeicher. Auf einer Smartwatch kann bereits die Zahl der gleichzeitig übergebenen Tools entscheidend sein. Auf einem Smartphone ist zusätzlich die thermische Drosselung relevant. Bei einem batteriebetriebenen Gerät zählt nicht nur die Antwortgeschwindigkeit, sondern auch, wie lange die Inferenz den Prozessor belastet.

Die veröffentlichte Geschwindigkeit von bis zu 6.000 Tokens pro Sekunde beim Prefill und 1.200 Tokens pro Sekunde beim Decoding stammt aus den Projektangaben für die Cactus-Laufzeit. Diese Werte sind keine allgemeine Zusicherung für jedes Smartphone, jedes Wearable oder jede Betriebssystemversion. Sie hängen unter anderem von Backend, Quantisierung, Eingabelänge, Tool-Anzahl und Gerät ab. (Needle-Ankündigung)

Tool-Aufrufe statt allgemeiner Chatfähigkeit

Needle ist als Werkzeugaufruf-Modell positioniert. Das Modell erhält eine natürliche Anfrage und eine definierte Liste von Tools. Anschließend soll es den passenden Tool-Namen und die erforderlichen Argumente in einer strukturierten Form ausgeben.

Beispiel:

json

{
  "name": "licht_einschalten",
  "arguments": {
    "raum": "Küche"
  }
}

Das ist eine andere Aufgabe als die freie Erstellung eines längeren Textes. Das Modell muss vor allem drei Dinge zuverlässig erledigen:

die passende Funktion aus einer begrenzten Liste auswählen,
Werte aus der Anfrage extrahieren,
ein gültiges strukturiertes Ergebnis ausgeben.

Diese Begrenzung ist kein Nachteil, sondern der Grund für die kleine Bauform. Laut Projektbeschreibung wurde Needle speziell auf Function-Calling-Daten nachtrainiert. Das veröffentlichte Material nennt 2 Milliarden Tokens synthetischer Tool-Daten und 15 Tool-Kategorien, darunter Timer, Nachrichten, Navigation und Smart-Home-Aufgaben. Diese Angaben stammen aus den offiziellen Projektmaterialien und sind keine allgemeine Garantie für Ihre eigenen Tools. (offizielle Projektbeschreibung)

Die zentrale Grenze lautet: Ein Modell, das gute Tool-Aufrufe erzeugt, besitzt dadurch nicht automatisch breites Weltwissen. Needle kann beispielsweise einen Wetterdienst aufrufen, wenn ein passendes Tool mit einem geeigneten Schema bereitgestellt wird. Es ist damit aber nicht automatisch ein verlässlicher Wetterberater, Reiseführer oder Rechercheassistent.

Für einen stabilen Einsatz sollten Sie daher:

Tool-Namen kurz und eindeutig formulieren.
Pflichtargumente klar definieren.
Einheiten und erlaubte Werte festlegen.
Mehrdeutige Anfragen ablehnen oder zur Rückfrage weiterleiten.
Die Tool-Ausgabe serverseitig validieren.
Keine Modellantwort direkt als Gerätebefehl ausführen.

Gerade bei physischen Geräten ist die letzte Regel wichtig. Ein gültiges JSON-Dokument ist noch kein sicherer Befehl. Die Anwendung muss prüfen, ob der Nutzer berechtigt ist, ob der Zielzustand zulässig ist und ob die Aktion eine Bestätigung verlangt.

Offline-Betrieb auf dem Smartphone

Kann Needle offline auf einem Smartphone laufen? Die Projektmaterialien zielen ausdrücklich auf mobile Geräte, Wearables, Smart-Home-Systeme und kleine Roboter. Die Cactus-Laufzeit bietet dafür lokale Inferenz und Bindings unter anderem für Swift, Kotlin, Flutter, React Native, Python und Rust. Das ist eine offizielle Zielsetzung des Projekts, aber keine vollständige Kompatibilitätsliste für jedes konkrete Endgerät. (Cactus-Repository)

Ein lokaler Betrieb bringt drei praktische Vorteile:

Netzwerkunabhängigkeit: Ein Tool-Aufruf kann auch bei schlechter Verbindung oder im Flugmodus vorbereitet werden.
Kürzerer Antwortweg: Die Anfrage muss nicht erst an einen entfernten Dienst übertragen werden.
Datenschutz: Sensible Eingaben können auf dem Gerät bleiben, sofern Ihre Anwendung keine Daten zu einem Cloud-Dienst weiterleitet.

DSGVO-Konformität entsteht trotzdem nicht automatisch. Sie müssen weiterhin prüfen, welche Daten gespeichert werden, wie Telemetrie funktioniert, wann Modelle aktualisiert werden und welche Berechtigungen die App besitzt. Ein lokales Modell kann außerdem durch manipulierte Eingaben zu unerwünschten Tool-Aufrufen verleitet werden. Offline bedeutet nicht automatisch sicher.

Ein robustes Muster ist eine lokale Entscheidungskette:

Eingabe lokal normalisieren.
Verfügbare Tools anhand von Kontext oder Tool-RAG begrenzen.
Needle den Aufruf erzeugen lassen.
Schema, Datentypen und Berechtigungen prüfen.
Sensible Aktionen bestätigen lassen.
Erst danach die Geräte-API ausführen.
Ergebnis lokal protokollieren oder bewusst verwerfen.

Die Cactus-Dokumentation beschreibt neben Tool-Aufrufen auch OpenAI-kompatible Schnittstellen, Streaming, Transkription, Embeddings, RAG und eine Cloud-Übergabe. Das spricht für einen hybriden Aufbau: einfache, klar definierte Befehle bleiben lokal; Aufgaben mit höherem Risiko oder hoher sprachlicher Komplexität werden an ein größeres Modell weitergegeben. (Cactus-Dokumentation und Befehlsübersicht)

Achtung: „Offline verfügbar“ beschreibt die Inferenz. Modell-Updates, neue Tool-Schemata, Zertifikate, Berechtigungslisten und Sicherheitsregeln benötigen weiterhin einen kontrollierten Update-Prozess.

Geräteklassen und realistische Aufgaben

Die Frage nach den unterstützten Geräten sollte nicht nur mit „Smartphone“ oder „Wearable“ beantwortet werden. Entscheidend ist, welche Eingabe vorliegt, wie viele Tools verfügbar sind und wie streng die Antwort validiert werden kann.

Geräteklasse	Geeignete Needle-Aufgaben	Kritische Grenze	Sinnvolle Ausgabe
Smartphone	App-Befehle, Kalenderaktionen, Smart-Home-Steuerung, kurze strukturierte Extraktion	Akku, Berechtigungen, viele konkurrierende Tools	JSON-Tool-Aufruf
Smartwatch	Timer, Erinnerungen, einfache Gerätezustände, kurze Sprachbefehle	Wenig Speicher, begrenzte Anzeige, kleine Eingabelänge	Ein einzelner lokaler Befehl
Brille oder Wearable	Kontextbezogene Kurzbefehle, Navigationstools, Gerätesteuerung	Privatsphäre, Audio-Mehrdeutigkeit, laufende Sensorlast	Tool-Name plus wenige Argumente
Smart Home	Licht, Temperatur, Szenen und Gerätestatus	Sicherheits- und Rollenmodell, missverständliche Befehle	Validierter Gerätebefehl
Kleiner Roboter	Begrenzte Bewegungs- oder Sensorfunktionen	Physische Risiken, Echtzeitregeln, Not-Aus	Stark eingeschränkte Aktionsklasse
Mac als Entwicklungsgerät	Datengenerierung, Fine-Tuning, Regressionstests, lokale Validierung	Mac-Ergebnis ist nicht automatisch Geräteergebnis	Testprotokoll und Modellpaket

Die offiziellen Quellen nennen Telefone, Uhren, Brillen, Smart-Home-Geräte und Roboter als Zielumgebungen. Eine konkrete Aussage wie „läuft auf jedem iPhone“, „unterstützt jede Smartwatch“ oder „funktioniert auf jedem Mikrocontroller“ wäre daraus nicht zulässig. Auch Community-Demonstrationen ersetzen keine offizielle Supportliste und keine eigene Validierung.

Für Wearables sollten Sie die Tool-Menge besonders klein halten. Ein Modell muss nicht aus 100 Funktionen auswählen, wenn die Uhr nur Timer, Musiksteuerung und zwei Geräteszenen benötigt. Weniger Tools reduzieren Verwechslungen, Kontextverbrauch und Fehlermöglichkeiten.

Bei Robotern kommt eine zusätzliche Sicherheitsstufe hinzu. Needle darf höchstens eine freigegebene Aktionsklasse auswählen. Geschwindigkeit, Wegbegrenzung, Kollisionsschutz und Not-Aus gehören in deterministische Steuerlogik, nicht in die Sprachmodellentscheidung.

Needle 14MB Tiny LLM und eigene Tool-Vokabulare

Wie lässt sich Needle auf eigene Tools abstimmen? Das offizielle Repository stellt eine Playground-Oberfläche und ein CLI-Fine-Tuning bereit. Die Modellkarte nennt unter anderem needle playground für eine Web-Oberfläche sowie needle finetune data.jsonl für eine Trainingsdatei. (offizielles Needle-Repository)

Der grundsätzliche Ablauf sieht so aus:

Tool-Inventar erstellen: Listen Sie jede Funktion mit Name, Zweck, Pflichtfeldern und erlaubten Werten auf.
Beispielanfragen sammeln: Formulieren Sie kurze, realistische Nutzeranfragen für korrekte und unvollständige Fälle.
Fehlerfälle ergänzen: Fügen Sie falsche Einheiten, fehlende Pflichtangaben, Synonyme und mehrdeutige Formulierungen hinzu.
JSONL-Datensatz erzeugen: Halten Sie Eingabe, Tool-Auswahl und Argumente in einem reproduzierbaren Format fest.
Playground oder CLI ausführen: Nutzen Sie die vom Projekt dokumentierten Fine-Tuning-Wege.
Auf dem Zielgerät testen: Ein Mac-Test prüft Daten und Modelllogik, aber nicht automatisch Wärme, Akku und Laufzeit auf dem Endgerät.
Regressionstest festlegen: Jede Änderung am Tool-Schema muss gegen alte und neue Beispiele geprüft werden.

Die Projektbeschreibung berichtet, dass die Datenpipeline synthetische Tool-Aufrufe erzeugen kann. Das ist hilfreich, ersetzt aber keine echten Nutzereingaben. Synthetische Beispiele decken häufig die erwartete Sprache ab, während reale Nutzer unvollständige, umgangssprachliche oder widersprüchliche Befehle eingeben.

Ein einheitlicher Fine-Tuning-Zeitwert wäre deshalb unseriös. Die Dauer hängt von Datenmenge, Hardware, Konfiguration, Ausgangsmodell und Evaluationsschritten ab. Der offizielle Playground soll Datengenerierung, Training, Auswertung und das Bündeln des Ergebnisses verbinden; prüfen Sie vor der produktiven Nutzung dennoch die jeweils aktuelle Repository-Version. (Modellkarte mit Fine-Tuning-Anleitung)

Wenn Sie auf dem Mac Trainingsdaten vorbereiten, sollten Sie die Arbeit in zwei Ebenen trennen: Zuerst prüfen Sie die semantische Zuordnung „Anfrage zu Tool“. Danach testen Sie das fertige Paket in der Zielumgebung. Eine Anleitung zur Auswahl zwischen lokaler Hardware und Cloud-Rechenleistung finden Sie im Vergleich von lokalem High-End-PC und Cloud-Umgebung. Für die Modellarbeit selbst ist außerdem der Beitrag über lokale AI-Entwicklung auf dem Mac eine passende Ergänzung.

Entscheidung zwischen Needle und größerem Modell

Needle passt, wenn Ihre Aufgabe eng definiert ist. Ein größeres Modell passt, wenn Sprache, Wissen oder Planung den Hauptanteil der Arbeit ausmachen.

Needle ist die bessere Wahl, wenn:

der Nutzer aus einer begrenzten Menge von Aktionen auswählt,
die Ausgabe ein überprüfbares Schema besitzt,
die Funktion offline verfügbar sein soll,
Netzwerkzugriff oder Datenschutz gegen eine Cloud-Verbindung sprechen,
Speicher, Akku und Latenz wichtiger sind als offene Gesprächsqualität,
Sie ein eigenes Tool-Vokabular kontrollieren können.

Ein größeres Modell ist die bessere Wahl, wenn:

der Nutzer ausführliche Erklärungen erwartet,
aktuelle Informationen recherchiert werden müssen,
mehrere Schritte geplant und neu bewertet werden,
lange Dokumente verarbeitet werden,
die Anfrage stark mehrdeutig ist,
allgemeine Wissensfragen den Kern des Produkts bilden.

Für eine Chat-Anwendung können Sie beide Ansätze kombinieren. Needle übernimmt die klar erkennbaren Gerätebefehle. Ein größeres Modell bearbeitet offene Fragen. Ein Router entscheidet anhand von Tool-Menge, Konfidenz, Datenschutzklasse und Fehlerrisiko. Dieses Muster entspricht auch der von Cactus beschriebenen Kombination aus lokaler Verarbeitung und Cloud-Fallback. (Cactus-Hybrid-Konzept)

Prüfliste vor dem Produktiveinsatz

[ ] Sind alle Tool-Namen eindeutig und frei von unnötigen Synonymen?
[ ] Werden Pflichtargumente, Datentypen und erlaubte Werte serverseitig geprüft?
[ ] Gibt es eine sichere Antwort auf fehlende oder mehrdeutige Angaben?
[ ] Wird jeder kritische Gerätebefehl vor der Ausführung autorisiert?
[ ] Ist dokumentiert, welche Daten das Gerät verlassen dürfen?
[ ] Wurde der Unterschied zwischen Modell-Dateigröße und Laufzeitspeicher gemessen?
[ ] Wurde mit der tatsächlichen Tool-Liste und nicht nur mit Demo-Tools getestet?
[ ] Gibt es Tests für falsche Einheiten, Tippfehler und unvollständige Anfragen?
[ ] Wurde die Inferenz auf dem Zielgerät und nicht nur auf dem Mac validiert?
[ ] Können Modell, Tool-Schemas und Sicherheitsregeln getrennt aktualisiert werden?
[ ] Ist für komplexe Aufgaben ein klarer Fallback definiert?
[ ] Werden Fehlversuche protokolliert, ohne unnötige personenbezogene Daten zu speichern?

Praktische Empfehlung für die Woche ab 14.08.2026

Beginnen Sie nicht mit einem offenen Chatbot. Wählen Sie eine einzelne Gerätekategorie und höchstens wenige Werkzeuge. Ein gutes erstes Projekt ist ein lokaler Befehl wie „Timer setzen“, „Licht ausschalten“ oder „Gerätestatus abfragen“. Definieren Sie dafür ein Schema, erstellen Sie reale Beispiele und prüfen Sie die Ausgabe auf dem Zielgerät.

Wenn Needle bei Ihren Daten häufig falsche Tools auswählt, reduzieren Sie zuerst die gleichzeitig sichtbare Tool-Liste. Erst danach sollten Sie ein Fine-Tuning versuchen. So erkennen Sie, ob das Problem im Modell, im Schema oder in der Anwendungslogik liegt.

Für die Abnahme von On-device AI sollten Sie außerdem eine feste Testmatrix mit korrekten, unvollständigen und bösartig formulierten Eingaben erstellen. Der Leitfaden zu Agent-Entwicklungsmodi hilft bei der Einordnung, wann ein lokaler Agent genügt und wann ein hybrider Ablauf sinnvoller ist.

Aktuelle Lösung und Mac-Umgebung

Wenn Sie Needle ausschließlich auf einem lokalen Notebook vorbereiten, entstehen drei typische Nachteile: Die verfügbare Hardware ist möglicherweise nicht konstant, längere Fine-Tuning- oder Evaluationsläufe blockieren Ihr Arbeitsgerät, und reproduzierbare Umgebungen müssen Sie selbst pflegen. Für Teams kommen zusätzlich wechselnde Python-Versionen, Abhängigkeiten und fehlende Testknoten hinzu.

Ein Mac eignet sich gut für die lokale Vorbereitung und schnelle Validierung. Für wiederholbare Trainingsläufe, parallele Datengenerierung oder getrennte Testumgebungen kann eine gemietete Mac-Umgebung von Hashvps angenehmer sein. Sie behalten dabei die Kontrolle über Repository, Daten und Testskripte, ohne Ihren Hauptrechner für jeden Lauf umzubauen. Das ist besonders sinnvoll, wenn Sie nur vorübergehend Fine-Tuning, Geräteintegration oder Regressionstests benötigen. Für dauerhaft hohe Rechenlast oder Projekte mit zwingendem physischem Gerätezugriff bleibt eigene Hardware die bessere Wahl.