Needle 2 von Cactus Compute wirkt zunächst wie eine weitere Meldung über ein sehr kleines Sprachmodell. Für Robotik ist der Punkt konkreter. Cactus beschreibt Needle 2 als offenes Modell mit 45 Millionen Parametern für Tool-Aufrufe, Gerätesteuerung und strukturierte Extraktion, verpackt in eine 14-MB-Binärdatei mit etwa 28 MB Sitzungs-RAM. Die Startseite nennt ausdrücklich Telefone, Wearables, Smart-Home-Geräte, Raspberry Pi, neuere Mikrocontroller und kleine Roboter. Gemeint sind also Maschinen, die menschliche Befehle lokal in physische Aktionen übersetzen sollen.

Lokaler KI-Hub koordiniert einen Heimroboter, ein Telefon, ein Wearable und Smart-Home-Werkzeuge ohne Cloud-Zugriff Die wichtige Frage lautet nicht, ob 45M Parameter wie ein großer Assistent plaudern können. Das ist nicht der Zweck. Ein Roboter braucht oft eine engere Fähigkeit: “dimme das Flurlicht”, “öffne den Greifer halb”, “speichere diesen Sensorwert” oder “frage vor dem Entriegeln nach” in einen sicheren Funktionsaufruf mit passenden Parametern zu übersetzen. Needle 2 steht für einen Wechsel von allgemeinen Chatbots zu lokalen Aktionsmodellen. Das kann Roboter schneller, günstiger und privater machen, verschiebt Fehler aber aus Text in die physische Welt.

Was Cactus verspricht

Die offizielle Seite nennt Tool Calling, Device Use und Structured Extraction. Needle 2 soll auf einem Simple Attention Network beruhen, mit Cactus Quants auf CQ2-bit komprimiert und mit eigener Engine ausgeliefert werden. Die Zahlen sind klein: 45 Millionen Parameter, 14 MB Binärdatei, rund 28 MB RAM, etwa 500 Tokens pro Sekunde auf Raspberry Pi 5, 400 bis 1.500 auf Meta Quest 3S und Apple Vision Pro sowie 300 bis 700 auf manchen Telefonen unter 200 Dollar.

Diese Werte bleiben Anbieterangaben, bis unabhängige Tests sie auf Geräten, Schemata und echten Lasten bestätigen. Dennoch ist die Zielrichtung wichtig. GitHub beschreibt cactus-compute/needle als 14-MB-Modell für Telefone, Wearables, Smart Home und Roboter. cactus-compute/cactus beschreibt Laufzeit, Quantisierung und Inferenz für mobile Geräte, Wearables, Smart Home und Roboter. Hugging Face führt Cactus-Compute/needle2 mit Tags für tool-calling, function-calling, on-device, edge, quantization und WebAssembly sowie arXiv:2607.18363. Es gibt also Modell, Code und Edge-Positionierung.

Warum Roboter diese Schicht brauchen

Die meisten Roboter brauchen keinen enzyklopädischen Gesprächspartner im Steuerkreis. Ein Heimroboter, Inspektionsrover, Wearable-Assistent oder Smart-Home-Hub braucht einen kompakten Übersetzer zwischen Menschen, Sensoren und Aktoren. Klassische Intent-Parser sind gut bei vorhersehbaren Befehlen. Große Cloud-Modelle sind gut, wenn Latenz, Datenschutz, Verbindung und Kosten passen. Dazwischen liegt das Alltagsgerät, das schnell, lokal und billig handeln muss, aber mehr Flexibilität braucht als ein festes Menü.

Kleine Modelle für Funktionsaufrufe werden dort interessant. Sie übersetzen natürliche Sprache in strukturierte Befehle, ziehen Parameter aus unordentlicher Sprache und können irrelevante Wünsche ablehnen, wenn Training und Grenzen stimmen. Ein Roboterarm muss vor einer Bewegung keinen Aufsatz schreiben; er muss die erlaubte Aktion wählen, Objekt oder Distanz füllen und Mehrdeutigkeit erkennen. Ein Heimcontroller muss Temperatur, Licht, Sicherheit, Musik oder keine Aktion unterscheiden.

Die Entwicklerdiskussion zeigt den wunden Punkt

Der Show-HN-Beitrag zu Needle2 zog viel technische Aufmerksamkeit an. Das ist ein Signal, kein Leistungsnachweis. Gleichzeitig tauchten Beispiele auf, in denen die Webdemo fragwürdige Werkzeuge wählte, darunter Diskussionen um lock_door bei irrelevanter Eingabe und Missverständnisse rund um Formulierungen wie einen Raum möglichst dunkel zu machen. Eine Demo mit Spielzeugschema beweist keine Untauglichkeit.

Die Warnung trifft trotzdem. Bei einem Chatbot führt ein falsches Werkzeug zu einer schlechten Antwort oder einem API-Fehler. Bei einem Roboter kann es einen Greifer bewegen, einen Raum heizen, ein Schloss öffnen, einen Motor starten oder einen Alarm stummschalten. Tool Calling ist nicht nur JSON, sobald das Werkzeug die Umgebung steuert. Gültige Struktur ist der Anfang der Sicherheitsfrage.

Struktur löst Semantik nicht

Schemata, Grammatiken und constrained decoding helfen: Sie verhindern kaputtes JSON, begrenzen Typen, listen Werkzeugnamen auf und erleichtern Validierung. Sie entscheiden nicht allein, ob eine Anfrage überhaupt handeln darf. Bei irrelevanten, böswilligen, mehrdeutigen oder kontextarmen Befehlen ist keine Aktion, eine Rückfrage oder Eskalation oft sicherer.

Für Robotik ist das zentral. Eine Grammatik zwingt tool_name in eine Liste, weiß aber nicht, ob “hier ist es zu hell” Lampen, Jalousien, Displayhelligkeit, Roboterbewegung oder gar nichts bedeutet. Ein Validator lehnt gefährliche Temperaturwerte ab, kennt aber nicht die Berechtigung eines Kindes am Lautsprecher. Ein lokales Aktionsmodell braucht Richtlinien: erlaubte Werkzeuge, Risikoklassen, Vertrauensschwellen, Nutzeridentität, Gerätezustand, Ratenlimits und Bestätigung für kritische Aktionen.

Lokale Inferenz hilft und gefährdet

Ein 14-MB-Modell auf dem Gerät hat echte Vorteile. Sprache und Haushaltskontext bleiben lokal. Das System funktioniert ohne Netz. Latenz sinkt. Ein günstiger Roboter entsteht ohne Kosten pro Anfrage. Wearables und Heimassistenten bearbeiten Routinen privat. Eine hybride Architektur ist plausibel: kleine lokale Befehle für sichere Routinen, großes Modell oder Mensch für Zweifelsfälle.

Gleichzeitig wird der Fehler unmittelbarer. Cloud-Dienste haben oft Konten, Monitoring, zentrale Updates und Serverregeln. Ein kleines Modell kann in tausenden Geräten mit verschiedenen Firmwares und Werkzeuglisten landen. Ordnet es Geräusch oder Hintergrundsprache einer Aktion zu, handelt das Produkt vor jeder zentralen Kontrolle. Sicherheit muss daher im Produkt sitzen: Bestätigungen, Trennung von Sicherheits- und Komfortfunktionen, erlaubtes “keine Aktion”, vollständige Protokolle und Tests mit Unsinn, Verneinungen, Witzen, Kindern, mehreren Sprachen, Medien im Hintergrund und widersprüchlichen Sensoren.

Needle 2 im Vergleich

Needle 2 ersetzt klassische Intent-Systeme nicht; bei kleinem, kritischem Befehlsraum bleiben sie stark. Größere lokale Modelle auf Telefonen oder PCs können breiter denken, brauchen aber mehr Speicher und Energie. Plattformen wie Apples lokale Foundation-Modelle bringen reichere Fähigkeiten auf Premium-Hardware. Andere kompakte Function-Calling-Modelle nähern sich demselben Problem mit mehr Parametern.

Needle 2 ist interessant, weil es von unten drückt. Wie viel Aktionsrouting passt in eine winzige Binärdatei? Reicht es für sichere Routinen unter strenger Policy, ist es eine wichtige Robotikschicht. Ist es schnell, aber zu eifrig beim Werkzeugaufruf, ist die Lehre ebenfalls wertvoll: Gemessen werden müssen falsche Aktionen, korrekte Ablehnung, Parameterpräzision, Mehrdeutigkeit, Verhalten bei wachsender Werkzeugliste und mehrsprachige Robustheit.

Was jetzt getestet werden sollte

Nützlich sind Praxisversuche auf Raspberry Pi 5, billigen Android-Geräten, Smart-Home-Hubs, ESP32-ähnlichen Boards soweit realistisch, Home-Assistant-Brücken, ROS-Prototypen und Wearable-Lasten. Wichtig sind Ende-zu-Ende-Latenz, Speichermaximum, Energie, Wärme und nicht nur Tokens pro Sekunde. Werkzeugschemata müssen harmlose und gefährliche Aktionen enthalten.

Sicherheitstests sollten wiederholbar sein: irrelevante Eingaben, Mehrdeutigkeit, Verneinungen, Scherze, widersprüchlicher Kontext und feindliche Formulierungen. Gibt das Modell keine Aktion zurück? Fordert es Bestätigung vor Schloss, Heizung, Bewegung oder Sicherheitsfunktion? Wird die Auswahl schlechter, wenn weitere Werkzeuge hinzukommen? Bleiben nicht englische Befehle sicher? Bei physischen Geräten kann korrektes Schweigen wichtiger sein als mutiges Handeln.

Fazit

Needle 2 ist kein fertiges Robotergehirn. Besser ist die Sicht als lokale Reflexschicht nahe bei Sensoren und Aktoren: normale Befehle werden in begrenzte, überprüfbare und protokollierte Aktionen übersetzt. Genau diese Schicht fehlt vielen Heimrobotern und intelligenten Geräten. Sie kann Assistenten sofortiger, Wearables privater und kleine Roboter ohne GPU brauchbarer machen.

Der Preis ist Disziplin. Tool Calling in der Robotik verlangt Richtlinien, Simulation, Protokolle, Bestätigungen und zuverlässige Ablehnung. Ein 14-MB-Modell, das eine Funktion wählen kann, ist eindrucksvoll. Ein 14-MB-Modell, das weiß, wann es keine Funktion wählen darf, wäre wichtiger. Der nächste Fortschritt könnte kein humanoider Körper sein, sondern ein winziges lokales Modell mit genug technischen Leitplanken, um den richtigen Knopf zu drücken und gefährliche Knöpfe in Ruhe zu lassen.

Quellen

Cactus-Compute-Startseite zu Needle 2 und Cactus-Runtime-Material; GitHub cactus-compute/needle und cactus-compute/cactus; Hugging Face Cactus-Compute/needle2; arXiv 2607.18363 zu Simple Attention Networks; Show-HN-Diskussion nur als Entwickler- und Fehlermodus-Signal.