Needle 2 od Cactus Compute łatwo uznać za kolejną wiadomość o małym modelu językowym. Dla robotyki ważniejsze jest coś innego. Firma opisuje Needle 2 jako otwarty model 45M parametrów do wywoływania narzędzi, użycia urządzeń i ekstrakcji strukturalnej, spakowany w binarium 14 MB z około 28 MB pamięci sesji. Strona uruchomieniowa wskazuje telefony, urządzenia noszone, smart home, Raspberry Pi, nowsze mikrokontrolery i małe roboty. To sprzęt, który może potrzebować zamienić polecenie człowieka na fizyczne działanie bez oczekiwania na chmurę.

Lokalny hub AI koordynuje robota domowego, telefon, urządzenie noszone i narzędzia smart home bez chmury Pytanie nie brzmi, czy model 45M będzie rozmawiał jak największe asystenty. Nie będzie i nie musi. Robot często potrzebuje węższej umiejętności: zamienić “przygaś światło w korytarzu”, “otwórz chwytak do połowy”, “zapisz odczyt czujnika” albo “zapytaj przed otwarciem drzwi” na bezpieczne wywołanie funkcji z parametrami. Needle 2 pokazuje przesunięcie od chatbotów do lokalnych modeli działania. To może dać szybkość, prywatność i niski koszt, ale przenosi błąd z tekstu do świata fizycznego.

Co deklaruje Cactus

Oficjalna strona mówi o tool calling, device use i structured extraction. Model ma używać Simple Attention Network, kompresji Cactus Quants do CQ2-bit i własnego silnika. Liczby są małe: 45 mln parametrów, binarium 14 MB, około 28 MB RAM, około 500 tokenów na sekundę na Raspberry Pi 5, 400–1500 na Meta Quest 3S i Apple Vision Pro oraz 300–700 na części telefonów poniżej 200 dolarów.

Trzeba traktować te wartości jako deklaracje dostawcy, dopóki niezależne testy nie powtórzą ich na różnych urządzeniach i schematach. Kierunek jest jednak istotny. GitHub opisuje cactus-compute/needle jako model 14 MB dla telefonów, wearables, smart home i robotów. cactus-compute/cactus opisuje runtime, kwantyzację i inferencję dla urządzeń mobilnych, noszonych, smart home i robotów. Hugging Face pokazuje Cactus-Compute/needle2 z tagami tool-calling, function-calling, on-device, edge, quantization i WebAssembly oraz związek z arXiv:2607.18363. To nie tylko obietnica, ale model, kod i cel edge.

Po co robotom taka warstwa

Większość robotów nie potrzebuje encyklopedycznego rozmówcy w pętli sterowania. Robot domowy, rover inspekcyjny, asystent noszony czy hub domu potrzebuje kompaktowego tłumacza między ludźmi, czujnikami i aktuatorami. Klasyczne parsery intencji działają przy przewidywalnych poleceniach. Duże modele w chmurze działają, gdy akceptujemy opóźnienie, prywatność, łączność i koszt. Między nimi jest urządzenie codzienne: musi działać szybko, lokalnie i tanio, z większą elastycznością niż menu.

Małe modele wywołań funkcji są tu ciekawe. Mogą tłumaczyć język na komendy strukturalne, wyciągać parametry z niedoskonałych zdań i odmawiać działania, jeśli szkolenie i ograniczenia są dobre. Ramię robota nie musi pisać eseju przed ruchem; musi wybrać dozwoloną akcję, wypełnić obiekt lub odległość i rozpoznać niejednoznaczność. Sterownik domu musi odróżnić temperaturę, światło, bezpieczeństwo, muzykę albo brak działania.

Dyskusja pokazała problem

Wątek Show HN o Needle2 przyciągnął duże zainteresowanie techniczne. To sygnał, nie dowód jakości. Jednocześnie użytkownicy pokazali przypadki, w których demo webowe miało wybierać wątpliwe narzędzia, w tym lock_door przy nieistotnym wejściu i pomyłki wokół poleceń typu “zrób jak najciemniej”. Pojedyncza demo-awaria nie przekreśla modelu; schemat mógł być zabawkowy i bez barier produkcyjnych.

Ostrzeżenie pozostaje trafne. W chatbocie zły wybór narzędzia daje niezręczną odpowiedź lub błąd API. W robocie może poruszyć chwytak, podgrzać pokój, odblokować zamek, uruchomić silnik albo wyciszyć alarm. Tool calling nie jest tylko formatowaniem JSON, gdy narzędzie steruje otoczeniem. Poprawna struktura zaczyna problem bezpieczeństwa.

Struktura nie gwarantuje sensu

Schematy, gramatyki i constrained decoding pomagają: blokują zepsuty JSON, ograniczają typy, wymuszają nazwy narzędzi i ułatwiają walidację. Nie decydują same, czy prośba powinna uruchomić działanie. Przy wejściu nieistotnym, złośliwym, niejednoznacznym lub bez kontekstu bezpieczne może być brak działania, pytanie lub eskalacja.

W robotyce to kluczowe. Gramatyka zmusi tool_name do listy, ale nie wie, czy “jest za jasno” oznacza lampy, rolety, ekran, ruch robota czy nic. Walidator odrzuci niebezpieczną temperaturę, ale nie zna uprawnień dziecka przy głośniku. Lokalny model działania potrzebuje polityk: list dozwolonych narzędzi, klas ryzyka, progów pewności, tożsamości użytkownika, stanu urządzenia, limitów i potwierdzeń dla działań wrażliwych.

Zalety i ryzyka lokalności

Model 14 MB na urządzeniu ma mocne argumenty. Polecenia głosowe i kontekst domu zostają lokalnie. System działa bez sieci. Opóźnienie spada. Tani robot nie płaci za każde zapytanie. Wearable lub asystent domowy obsługuje rutynę prywatnie. Możliwa jest architektura hybrydowa: mały lokalny interpreter dla bezpiecznych czynności, większy model lub człowiek dla sporów.

Ale lokalność przyspiesza błąd. Chmura ma zwykle konta, monitoring, centralne aktualizacje i polityki serwera. Mały model może trafić do tysięcy produktów z różnym firmware i listami narzędzi. Jeśli przypisze hałas lub cudzą mowę do akcji, urządzenie zadziała przed centralną kontrolą. Bezpieczeństwo musi być w produkcie: potwierdzenia, rozdzielenie funkcji bezpieczeństwa i wygody, prawo do “brak działania”, pełne logi, testy z nonsensem, zaprzeczeniami, żartami, dziećmi, wieloma językami, mediami w tle i sprzecznymi czujnikami.

Miejsce Needle 2

Needle 2 nie zastępuje klasycznych systemów intencji, które nadal wygrywają przy małej i krytycznej przestrzeni poleceń. Większe modele lokalne na telefonach lub PC rozumują szerzej, ale potrzebują pamięci i energii. Platformy premium, w tym lokalne modele Apple, idą ku bogatszym możliwościom na mocnym sprzęcie. Inne modele function-calling celują w ten sam punkt większą liczbą parametrów.

Znaczenie Needle 2 polega na nacisku od dołu. Ile routingu działań mieści się w małym binarium? Jeśli wystarczy do bezpiecznej rutyny pod ścisłą polityką, to ważna warstwa robotyki. Jeśli jest szybkie, ale zbyt chętne do narzędzi, także uczy: trzeba mierzyć fałszywe akcje, poprawne odmowy, parametry, niejednoznaczność, zachowanie przy rosnącej liście narzędzi i odporność wielojęzyczną.

Co testować

Potrzebne są testy na docelowym sprzęcie: Raspberry Pi 5, tanich Androidach, hubach smart home, płytkach klasy ESP32 tam, gdzie to realne, Home Assistant, prototypach ROS i obciążeniach wearable. Ważna jest pełna latencja, pamięć, energia i temperatura, nie tylko tokeny na sekundę. Schematy narzędzi powinny zawierać akcje zwykłe i niebezpieczne.

Testy bezpieczeństwa powinny być powtarzalne: wejścia nieistotne, polecenia niejednoznaczne, zaprzeczenia, żarty, konflikt kontekstu i wrogie frazy. Czy model zwraca brak działania? Czy pyta przed zamkiem, ruchem, ogrzewaniem lub ochroną? Czy psuje się po dodaniu narzędzi? Czy inne języki pozostają bezpieczne? W fizycznej maszynie poprawne milczenie bywa ważniejsze niż odważna akcja.

Wniosek

Needle 2 nie jest gotowym mózgiem robota. To kandydat na lokalną warstwę odruchową blisko czujników i aktuatorów: zwykłe polecenia zmienia w ograniczone, sprawdzalne i logowane akcje. Tego brakuje wielu robotom domowym i inteligentnym urządzeniom. Może przyspieszyć asystenta, sprywatyzować wearable i uruchomić małego robota bez GPU.

Cena to dyscyplina. Tool calling w robotyce wymaga polityk, symulacji, logów, potwierdzeń i dobrych odmów. Model 14 MB, który wybiera funkcję, robi wrażenie. Model 14 MB, który wie, kiedy nie wybierać funkcji, byłby ważniejszy. Najbliższy postęp może nie być humanoidem, lecz małym lokalnym modelem z wystarczającymi barierami, by naciskać właściwy przycisk i zostawiać niebezpieczne w spokoju.

Źródła

Strona Cactus Compute Needle 2 i materiały runtime Cactus; GitHub cactus-compute/needle i cactus-compute/cactus; Hugging Face Cactus-Compute/needle2; arXiv 2607.18363 o Simple Attention Networks; Show HN tylko jako sygnał reakcji i trybów awarii.