Needle – ein auf 26 Millionen Parameter destilliertes Modell für Gemini Tool Calling

• Ein Open-Source-Modell für Tool-Nutzung mit 26 Millionen Parametern, entwickelt für den Einsatz auf kleinen Consumer-Geräten wie Smartphones, Smartwatches und Brillen
• Ausgangspunkt ist die Beobachtung, dass Tool-Aufrufe keine Inferenz, sondern Suche und Zusammensetzung sind (Abfrage → Abgleich mit dem Tool-Namen → Extraktion der Argumente → JSON-Ausgabe) und daher kein großes Modell benötigen
• Verwendet die Architektur eines Simple Attention Network, sodass das gesamte Modell nur aus Attention und Gating besteht, ganz ohne MLP
  • Encoder mit 12 Schichten + Decoder mit 8 Schichten, verbunden über Cross-Attention
  • d=512, 8H/4KV, BPE=8192
• Durch Distillation von Gemini 3.1 erzeugt; Vortraining mit 200B Token auf 16 TPU v6e (27 Stunden), anschließend weiteres Training mit 2B Token an Daten für Function Calling (45 Minuten)
• Erreicht in Produktion auf der Cactus Inference Engine eine Geschwindigkeit von prefill 6.000 tok/s, decode 1.200 tok/s
• Übertrifft in Benchmarks für Single-Call-Function-Calling FunctionGemma-270M, Qwen-0.6B, Granite-350M, LFM2.5-350M
  • In dialogorientierten Umgebungen besitzen diese Modelle allerdings eine breitere Allgemeintauglichkeit
• Lässt sich auch ohne FFN auf alle Aufgaben verallgemeinern, die auf externes strukturiertes Wissen zugreifen können (RAG, Tool-Nutzung usw.)
  • Wenn faktische Informationen im Input bereitgestellt werden, müssen sie nicht in FFN-Gewichten gespeichert werden
• Mit dem Befehl needle playground lassen sich eigene Tools in einer Web-UI testen und per One-Click feinabstimmen; lokales Fine-Tuning auf Mac/PC wird unterstützt
• Der Trainingsdatensatz wurde mit Gemini synthetisch erzeugt und umfasst 15 Tool-Kategorien wie Timer, Messaging, Navigation und Smart Home
• MIT-Lizenz, Python-basiert; Gewichte und der Prozess zur Erstellung des Datensatzes sind vollständig auf Hugging Face offengelegt

[wedding]

Funktioniert Koreanisch gut..?

[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.