Needle - Ein 26-Millionen-Parameter-Modell, das Gemini-Tool-Calling destilliert

• Needle ist ein experimentelles Modell, das aus Gemini 3.1 in ein Simple Attention Network mit 26 Millionen Parametern destilliert wurde; sogar lokales Fine-Tuning auf Mac/PC ist möglich
• Ziel ist es, kleine KI für Consumer-Geräte wie Smartphones, Uhren und Brillen neu zu definieren, mit Fokus auf Single-Execution-Tool-Calling für persönliche KI
• In der Produktion läuft es auf Cactus und erreicht prefill 6000 toks/sec sowie decode 1200
• Die Gewichte sind unter Cactus-Compute/needle vollständig offen verfügbar, ebenso die Datensatzgenerierung
• Das Pretraining lief auf 16 TPU v6e mit 200B Tokens über 27 Stunden, das anschließende Training mit einem Single-Execution-Function-Calling-Datensatz von 2B Tokens dauerte 45 Minuten
• Beim Single-Execution-Function-Calling wird es als besser als FunctionGemma-270m, Qwen-0.6B, Graninte-350m und LFM2.5-350m dargestellt; diese Modelle haben jedoch einen größeren Umfang und mehr Kapazität und sind in dialogorientierten Setups stärker
• Da kleine Modelle schwer zu handhaben sein können, wird empfohlen, den bereitgestellten Web-UI-Workflow zu nutzen: mit eigenen Tools testen und per Klick ein angepasstes Fine-Tuning durchführen
• needle playground öffnet die Web-UI unter http://127.0.0.1:7860; die Gewichte werden automatisch heruntergeladen und können für Tests und Fine-Tuning verwendet werden
• Bei Verwendung von Python können mit SimpleAttentionNetwork, load_checkpoint, generate und get_tokenizer Queries und Tool-Schemata übergeben werden, um Tool-Calling-JSON wie get_weather zu erzeugen
• Die CLI bietet playground, finetune, run, train, pretrain, eval, tokenize, generate-data und tpu für Inferenz, Training, Evaluation, Datengenerierung und TPU-Management
• Die Modellkonfiguration ist d=512, 8H/4KV, BPE=8192 und verwendet 12 Encoder-Schichten sowie 8 Decoder-Schichten, GQA+RoPE, cross attention, gated residual, tied linear und shared embedding

[GN⁺]

Hacker-News-Kommentare

• Ich frage mich, ob es Beispiele oder Daten zur Unterscheidungsfähigkeit von Tool-Use-Modellen gibt.
  Ein Beispiel wäre so etwas wie „Wie ist das Wetter in San Francisco?“, und das übergebene Tool wäre ungefähr tools='[{"name":"get_weather","parameters":{"location":"string"}}]'.
  Vor über zehn Jahren habe ich einmal etwas gebaut, das solche Probleme mit SPARQL und Wissensgraphen verarbeiten konnte[1].
  Was mich wirklich interessiert, ist, wie gut Mehrdeutigkeit behandelt wird.
  Wenn man eine Nachricht wie „Lass uns morgen um 10 bei einem Kaffee treffen“ und einen Befehl wie „Speichere das“ schickt: Kann das Modell dann aus einigen Dutzend möglicher Tools, wenn auch nicht aus Hunderten, die Aktion „Termin hinzufügen“ auswählen?
  [1] https://github.com/nlothian/Acuitra/wiki/About

  • Ich habe es mit dem unten verlinkten Hugging Face getestet und war nicht beeindruckt.
    Der Prompt war „Ich muss meinem Chef Bescheid sagen, dass ich zu spät komme“, und das Ergebnis war 20mins [{"name":"set_timer","arguments":{"time_human":"20 minutes"}}].
    Es hat nicht das E-Mail-Tool verwendet, und auch bei 2–3 anderen Formulierungen war das Ergebnis ähnlich.

• Ich frage mich, ob man sich keine Sorgen über Googles Reaktion macht.
  Berichten zufolge reagiert Google auf Distillationsversuche mit „proaktiven Echtzeit-Abwehrmaßnahmen, die die Leistung des Studentenmodells verschlechtern können“.
  Falls es erkannt wurde, könnte man absichtlich mit einer dümmeren, aber plausiblen Gemini-Variante gefüttert worden sein: https://cloud.google.com/blog/topics/threat-intelligence/dis...
  Allerdings ist dieses Modell klein und nur auf Tool-Use fokussiert, daher verbraucht es bei den Tokens vermutlich nicht einmal annähernd so viel wie Versuche, ein vollständiges Modell zu destillieren.

  • Man könnte auch ein Gemma-Modell lokal laufen lassen und daraus destillieren, ebenso andere Modelle, die Tool-Use beherrschen.
  • Aus Sicht der Trainingsdaten fühlt sich das auch ein bisschen so an, als würde man einen Dieb bestehlen.

• Vielleicht wird es möglich, so etwas wie ein Kommandozeilenprogramm zu bauen, bei dem man Argumente optional in natürlicher Sprache angeben kann.
  Natürlich werden viele dagegen sein, zusätzlich 14 MB und Rechenaufwand für das „Parsing“ einzubauen, und wenn das alle so machen, könnte das ziemlich unerquicklich werden.
  Trotzdem ist es wirklich interessant, dass das jetzt möglich ist.
  Man könnte ein Modell mitliefern, das darauf feinabgestimmt ist, die Nutzung des Programms zu verstehen.
  Zum Beispiel könnte > toolcli what can you do toolcli --help summary ausführen, und toolcli add tom to teamfutz group würde zu toolcli --gadd teamfutz tom werden.

  • Needle wurde für INT4 trainiert, und auch das, was man im Playground sieht, ist INT4, daher ist es nur 14 MB groß.
    Die gleiche Aufgabe bleibt aber weiterhin bestehen.

• Es wäre schön, eine Live-Demo des „needle playground“ öffentlich bereitzustellen.
  Wegen der kleinen Größe dürfte es auch recht günstig sein, das irgendwo auf einem kleinen VPS laufen zu lassen.

  • Mit WebGPU dürfte das ebenfalls schnell und einfach machbar sein.
  • Das Problem ist nur die Skalierung; eine sofort einsatzbereite Infrastruktur gibt es noch nicht.
    Trotzdem kann das grundsätzlich jeder machen, und es lässt sich auch direkt auf einem Laptop leicht ausführen.
    Ich werde auch den VPS-Weg ausprobieren.
  • Ich werde versuchen, das auf chonklm.com bereitzustellen.

• Die Beobachtung „Für Suchaufgaben braucht man kein FFN“ ist interessant.
  Wenn das Wissen im Kontext enthalten ist, kommt das fast der Behauptung gleich, dass FFN-Gewichte für diese Aufgabe redundant sind.
  Ich frage mich, ob sich das auch auf mehrstufige Tool-Aufrufe verallgemeinern lässt, bei denen der Zustand über mehrere Aufrufe hinweg verfolgt werden muss, oder ob es dort auseinanderfällt.
  Ein einzelner Aufruf ist der einfache Fall.

• Interessant, und das passt auch zu einer Beobachtung, die ich bei der frühen Nutzung von Claude Code gemacht habe.
  Sonnet rief oft schnell Tools auf, um mehr Kontext zu sammeln, während Opus länger zu schlussfolgern versuchte, um das Problem mit dem vorhandenen Kontext zu lösen.
  Das führte zu viel redundanter Funktionalität und verlangsamte die Entwicklung, aber bei neuen Modellen wie GPT-5.5 und Opus 4.6 scheint dieses Problem geringer zu sein.
  Mein Fazit ist, dass ein „dümmeres“, also kleineres Modell als Agent-Execution-Shell besser sein könnte oder sich zumindest für viele Probleme realistischer günstig und schnell betreiben lässt.
  Ich hatte nicht den Eindruck, dass Gemini besonders gut in langen Sequenzen von Tool-Aufrufen ist.
  Es wäre interessant, echte Sitzungen wie bei Codex oder Claude Code zu destillieren, in denen zwischen den Nutzeranfragen lange Ketten von Tool-Aufrufen vorkommen.
  Persönlich hätte ich gern ein etwas größeres Modell, das sich auf Geräten wie einem 32-GB-M2-MacBook-Pro leicht ausführen lässt und bei dem Reinforcement Learning für Tool-Use das Hauptziel ist.
  Offen verfügbare Gewichtsmodelle wie Kimi oder Qwen kommen dem näher, aber die Quantisierung, die nötig ist, um sie auf kleine Geräte zu bringen, scheint die Leistung ziemlich stark zu verschlechtern.

  • Der Kernpunkt ist, das LLM nicht in einer Schleife laufen zu lassen.
    Der aktuelle Hype um Agent-Frameworks ist dumm, und ich glaube, er existiert größtenteils, um den Umsatz der LLM-Firmen zu steigern.
    LLMs sind im Allgemeinen nur begrenzt nützlich, aber in Kombination mit einmaliger Tool-Nutzung werden sie viel brauchbarer und verlässlicher.
    Ich baue mir selbst sehr spezifische Tool-Sets für bestimmte Aufgaben auf der openrouter API.
    Man drückt einen Button, und das LLM erledigt eine nützliche Sache – nicht so, dass man einen Button drückt und dann hofft, dass das LLM fünf Minuten lang in einer Tool-Call-Schleife rotiert und die Dinge in der richtigen Reihenfolge erledigt.
    Wenn mehrere Tool-Aufrufe nötig sind, verbinde ich sie im Code deterministisch.
    Dann kann ich die Ausgabe von A prüfen und danach mit B oder C weitermachen; das ist viel verlässlicher und auch bei Zeit und Tokens effizienter.
    Agent-Schleifen kommen mir wie ein riesiger Betrug vor.
  • Ich wünschte, die großen KI-Unternehmen würden ihre Zeit nicht damit verbringen, die Lücken in ihren eigenen „Tools“ unangetastet zu lassen.
    Ich verstehe nicht, warum wir uns abmühen müssen, damit es irgendwie „funktioniert“.
    Google, MS, Meta, OpenAI und andere versuchen inzwischen stillschweigend, ihre Werkzeuge „Intelligence“ zu nennen, obwohl es nicht einmal „Artificial Intelligence“ ist – warum also ist es dann nicht intelligent und warum funktioniert es nicht?
    Es wurden über eine Billion Dollar investiert, und trotzdem müssen wir uns immer noch die besten Zaubersprüche und Einstellungen überlegen, damit Slop-Generatoren halbwegs brauchbare Ausgaben liefern.
    Währenddessen drohen manche Tech-Führungskräfte ganz offen damit, uns ihrer seltsamen Vorstellung von „Zivilisation“ zu unterwerfen.
    Ich finde, wir sollten unsere besseren Gehirne für etwas anderes einsetzen und uns nicht selbst zur hilflosen Assistenz eines magischen Orakels degradieren.

• Das Ergebnis des Cactus-Experiments, dass man „MLPs in Transformer-Netzwerken vollständig entfernen kann, solange das Modell auf externe Wissensquellen angewiesen ist“, ist interessant.
  Zufällig hat heute auch einer meiner Studierenden Forschungsergebnisse vorgestellt, die das bestätigen.
  Nachdem wir MLP aus Qwen entfernt hatten, konnte das Modell zwar weiterhin Transformationsaufgaben auf den Eingaben ausführen, verlor aber sein Wissen.

• Der Unterschied zwischen M und B ist zu subtil.
  Ich würde vorschlagen, 0.026B zu schreiben.

  • Die Schreibweise „M“ gibt es mindestens seit den Zeiten von BERT und T5/FLAN.
    Auch wenn heutige LLM-Entwickler eher an Modelle im Milliardenbereich gewöhnt sind, ist diese Schreibweise weiterhin gültig.
  • Viele Kommentare unter diesem Beitrag waren so verwirrend, dass ich dank dir gemerkt habe, dass manche es als 26B gelesen haben – deshalb ergaben die Kommentare keinen Sinn.

• Ich bin gespannt, großartige Arbeit.
  Die Gemma4-Edge-Modelle wurden als gut für Agent-Nutzung angekündigt, aber in allen Tests, die ich gemacht habe, waren sie wirklich enttäuschend.
  Sie scheiterten sogar in den grundlegendsten Tool-Use-Szenarien.
  Ich frage mich, ob ihr Tool-Use-Benchmarks für Needle durchgeführt habt oder ob ihr das plant.
  Falls ja, wäre es schön, die Ergebnisse dem Repository hinzuzufügen.

• Ich habe gerade versucht, einen Alarm zu stellen und etwas zur Einkaufsliste hinzuzufügen, und es war besser als Siri.