Vorstellung von AutoThink zur Verbesserung der Leistung lokaler LLMs durch adaptives Reasoning

• AutoThink kann die Leistung von Large Language Models (LLMs) in lokalen Umgebungen mit adaptivem Reasoning verbessern
• Das Projekt unterstützt den leistungsstarken Einsatz von LLMs auch in Umgebungen mit begrenzten GPU-Ressourcen
• Gegenüber dem herkömmlichen Betrieb von LLMs bietet es Vorteile bei Geschwindigkeit und Antwortqualität
• Im Vergleich zu Cloud-basierten LLM-Lösungen wie der OpenAI API sind Datenschutz und Kosteneinsparungen möglich
• Nützlich für Entwickler und KI-Forscher bei der eigenen Bereitstellung und beim Experimentieren mit LLMs

---

Vorstellung des Open-Source-Projekts AutoThink

AutoThink ist ein Framework für adaptives Reasoning, das entwickelt wurde, um die Leistung von Large Language Models (LLMs), die lokal ausgeführt werden, zu maximieren. Die wichtigsten Merkmale und Wettbewerbsvorteile dieses Projekts sind wie folgt.

Warum AutoThink wichtig ist

• Die meisten Lösungen zur Weiterentwicklung von LLMs sind auf externe Clouds wie die OpenAI API oder HuggingFace Spaces angewiesen
• Cloud-basierte LLM-Dienste bringen Probleme wie Datenschutzrisiken, Kostenbelastung und Netzwerkabhängigkeit mit sich
• AutoThink unterstützt dabei, auch auf schwächerer GPU-Hardware oder PCs durch eine optimierte Inferenzstruktur die bestmögliche Antwortqualität zu erreichen
• Die adaptive Struktur analysiert in Echtzeit die Betriebssituation und den Schwierigkeitsgrad der Aufgabe, um den am besten geeigneten Inferenzpfad und die passende Strategie dynamisch auszuwählen

Hauptfunktionen und Vorteile

• Einführung mehrstufiger Inferenz: Je nach Eingabeproblem werden automatisch mehrere Inferenzstufen angewendet, wodurch sich die Antwortqualität auch bei komplexen Fragen verbessert
• Automatische Leistungsabstimmung: Der Inferenzprozess und die Ressourcen werden an Bedingungen wie vorhandene Hardware, Zeit und Schwierigkeitsgrad angepasst
• Schnelle Experimente: So aufgebaut, dass KI-Forscher und Entwickler LLMs in verschiedensten Infrastrukturumgebungen schnell testen können
• Modulares Design: Unterstützt die Trennung von Inferenzstrategie und LLM-Engine und lässt sich leicht mit verschiedenen Engines integrieren

Vorteile gegenüber Konkurrenzprojekten

• Bisher waren feste Inferenzstrukturen üblich, die von Cloud- oder großskaliger Hardware ausgehen
• AutoThink zeichnet sich durch eine auf lokale Umgebungen zugeschnittene Leichtgewichtigkeit, ein Gleichgewicht zwischen Genauigkeit und Geschwindigkeit sowie eine adaptive Struktur aus
• Hervorragend geeignet zum Schutz eigener Daten und sensibler Informationen

Anwendungsbeispiele

• Effizient bei der Einführung interner LLMs in Umgebungen mit begrenzten GPU-Ressourcen, etwa in kleinen Startups oder Forschungseinrichtungen
• Lässt sich schnell auf wiederholte Experimente und Zyklen der Funktionsverbesserung anwenden

Fazit

AutoThink ist ein innovatives Open-Source-Projekt, das eine leichte und flexible Struktur zur Inferenzoptimierung bietet und Entwicklern sowie KI-Experten dabei hilft, eigene LLM-Modelle lokal effektiv zu betreiben. Es überwindet Kosten- und Datenschutzprobleme Cloud-basierter LLM-Lösungen und ist eine praktische Alternative, die die Eignung für den realen Arbeitseinsatz in unterschiedlichsten Umgebungen erhöht.

[GN⁺]

Hacker-News-Kommentar

• Ich möchte offenlegen, dass die Motivation für AutoThink aus der Erfahrung entstand, zu sehen, wie bestehende Reasoning-Modelle Rechenressourcen verschwenden — die Ineffizienz sprang deutlich ins Auge, weil sie selbst für sehr einfache Fragen wie „Was ist 2+2?“ genauso viel „Denkzeit“ verbrauchen wie für komplexe mathematische Beweise. Überraschend war, dass die Leistungsverbesserung viel größer ausfiel als erwartet, als ich zwei Dinge kombinierte, mit denen ich getrennt experimentiert hatte — adaptive Klassifikation (kann ohne Retraining neue Kategorien lernen) und Pivotal Token Search, das im Microsoft-Paper zu Phi-4 als Open Source veröffentlicht wurde — und darauf noch eine dynamische Zuweisung des Token-Budgets anwandte. Tatsächlich sank die durchschnittlich verwendete Tokenzahl, weil einfache Anfragen wirklich deutlich schneller abgeschlossen wurden und zusätzliche Rechenarbeit nur komplexen Anfragen zugewiesen wurde. Ein paar technische Punkte: Der Steering Vector ist mit weniger als 1 MB pro Muster klein, der Speicher-Overhead also praktisch null; der Klassifikationsprozess fügt nur etwa 10 ms Latenz hinzu, also vernachlässigbar; und die Auswahl des Target-Layers ist wichtig, wobei sich bei den meisten Modellen mittlere Layer im Bereich 15 bis 20 als am besten erwiesen. Feedback hätte ich gern zu folgenden Punkten: Erfahrungen mit ähnlichen adaptiven Ansätzen, Reasoning-Muster, die sich nützlicher steuern lassen, und Ideen zur automatischen Erkennung des optimalen Target-Layers. Fragt mich gern alles zu Implementierung oder Ergebnissen

  • Inzwischen ist das nicht unbedingt mehr so. Hast du Gemini 2.5 Pro ausprobiert? Bei einfachen Fragen „denkt“ es fast gar nicht, bei Coding-Fragen schreibt es Antworten wie lange logische Essays. Bei o3 scheint es ähnlich zu sein

  • Glückwunsch! Jeder Versuch, LLMs effizienter zu machen, ist sehr willkommen. Bisher habe ich eher faul optimiert: einfache Anfragen auf einem Mac Mini M4 mit MLX-Modellen, komplexe Anfragen an eine Nvidia 4090. Die Effizienz des M4 ist im Vergleich zu Nvidia wirklich erstaunlich. Ich denke, Apple ist mit MLX auf dem richtigen Weg. Ich werde mehr über AutoThink lesen und plane, es auch in meinen persönlichen Workflow zu integrieren

  • Ich denke, es wäre einen Versuch wert, hinter den User-Prompt eine „Antwort eines Non-Reasoning-Modells“ einzufügen, zum Beispiel: „Folgendes hat das Non-Reasoning-Modell gedacht: ... Ist das das Ergebnis, das der Nutzer möchte?“ Wenn die Non-Reasoning-Version ausreicht, könnte das auch den Vorteil haben, dass das Reasoning-Modell schneller zu einer Antwort kommt

  • Sogar Claude Sonnet 3.5 — nicht einmal die neueste Version 3.7 oder 4 — zeigt je nach Komplexität der Anfrage klar unterschiedliche Bearbeitungszeiten. Man sieht also bereits eine dynamische Anpassung der Verarbeitungszeit

• Ich frage mich, wie man Fragen als „komplex“ oder „einfach“ klassifizieren kann. Eine äußerlich einfache Frage kann in Wirklichkeit sehr schwierig sein. Zum Beispiel ist eine ganzzahlige Lösung für x³+y³+z³=42 ein Problem, das über 100 Jahre Rechenressourcen verschlungen hat. Oder auch eine Gleichung wie x/(y+z)+y/(z+x)+z/(x+y)=4: Sie wirkt auf den ersten Blick simpel, hat aber Lösungen mit Milliardenwerten, für die Theorie elliptischer Kurven nötig ist. Verweis auf die Lösung

  • Die Schwierigkeit eines Problems zu klassifizieren ist selbst eine eigene Technik — eine Fähigkeit, die getrennt von der eigentlichen Lösung gelernt werden kann. Wenn man zum Beispiel die obige Gleichung sieht, sollte man sofort drei Schwierigkeiten erkennen: ganzzahliger Bereich, drei Variablen, kubische Gleichung. Diese drei Elemente zusammen lassen den Schwierigkeitsgrad stark ansteigen. Mit reellen oder komplexen Zahlen, weniger Variablen oder niedrigerem Grad wäre das deutlich leichter. Das heißt natürlich nicht, dass es zwingend schwer ist, aber es könnte ein ungelöstes Problem sein. Ich selbst kann so etwas nicht wirklich lösen, habe aber genug Übung darin, einzuschätzen, wo man Informationen suchen müsste, und merke deshalb sofort: „Das ist extrem schwer.“ Könnten LLMs nicht auch solche Hinweise lernen und so die Schwierigkeit klassifizieren, ohne das Problem tatsächlich zu lösen? Oder vielleicht haben sie das bereits gelernt

  • Der Schwierigkeitsgrad der Anfrage wird in diesem Kontext danach definiert, wie viele Token das Modell auf Ground-Truth-Datensätzen wie GSM8k verbraucht, um eine korrekte Antwort zu erzeugen. Der adaptive Klassifikator wird auf diesem Datensatz trainiert und dann während der Inferenz für die Klassifikation verwendet

• Als bei Claude 3.7 der Schalter für extended thinking kam, habe ich auch ein ähnliches AutoThink-POC gebaut — sogar mit demselben Namen autothink
  github.com/NiloCK/autothink
  Blog „think-toggles-are-dumb“
  Meine Version macht zuerst einen Pass, in dem das LLM die Schwierigkeit der Anfrage auf einer Skala von 0 bis 100 bewertet, und weist dann entsprechend diesem Wert das Denkbudget linear zu. Im Vergleich zur Arbeit des OP ist das natürlich simpel, aber ich freue mich wirklich, quantitative Ergebnisse zu sehen — starke Arbeit!

• Ich halte das für eine offensichtliche Optimierung und finde es seltsam, dass diese Veränderung nicht schon längst stattgefunden hat. Sehr beeindruckend, wie gut es erklärt und direkt umgesetzt wurde

• Bei Reasoning-Modellen wie QwQ oder Qwen 3 habe ich ehrlich gesagt nicht viel Zeit darauf verwendet, die Ergebnisse selbst zu verbessern, sondern eher ausprobiert, mit verschiedenen Prompts die Ausgabe von Reasoning-Tokens zu begrenzen. Gemma 3 27B QAT ist zwar kein Reasoning-Modell, folgt aber Anweisungen so gut, dass es sich in LLM-Ketten oder Routen sehr gut für Vorklassifikation/Sprachoptimierung einsetzen lässt und in späteren Stufen dann für das eigentliche Reasoning genutzt werden kann. Es ist auch möglich, Zwischenantworten zwischen verschiedenen Thinking-Tags abwechselnd auszugeben. In Experimenten mit solchen Modellen definiere ich „Tokens während des Denkens“ getrennt von der Schlussfolgerung als alle Tokens, die als Trittsteine in den einzelnen Problemlösungsschritten dienen. Ich habe die Erfahrung gemacht, dass sich Ergebnisse im Allgemeinen verbessern, wenn man anweist, bestimmte Tokens oder Formulierungen bevorzugt zu verwenden, und AutoThink könnte als allgemeinere und wirksamere Optimierung dienen, indem es automatisch die im Datensatz am besten performenden Tokens nutzt. Wenn allerdings zu viele Pivot-Tokens verwendet werden, besteht die Gefahr des Overfittings auf Benchmark-Fragen, deshalb würde ich gern noch sehen, wie gut sich dieser Ansatz verallgemeinert. Persönlich halte ich eine sorgfältige Wort-/Tokenwahl für eine kostengünstige Optimierung mit hoher Wirkung auf die Ergebnisqualität, und ich habe hohe Erwartungen an die Generalisierungsfähigkeit von AutoThink

• Es ist großartig, dass kleine Teams und einzelne Forschende dank kleinerer Modelle innovative Ansätze und Experimente inzwischen viel leichter belegen können, ohne große AI-Labs beneiden zu müssen. Je wettbewerbsfähiger SMLs (Small Language Models) werden, desto stärker wächst das, was sich On-Device umsetzen lässt — weit über das hinaus, was man erwarten würde

  • Ich glaube, statt „small language models (SML)“ ist SLM der richtige Begriff

• Wenn man Modelle für andere hostet, ist es sinnvoll, bei sehr einfachen Fragen Rechenressourcen zu sparen. In diesem Fall gibt es zwar den Nachteil, dass das Modell Fragen, die leicht erscheinen, möglicherweise vernachlässigt, aber diese Kosten trage nicht ich. Wenn ich ein Modell dagegen direkt auf meinem eigenen PC nutze, möchte ich, nachdem ich bereits viel Geld in eine GPU investiert habe, die Ressourcen möglichst voll ausnutzen — selbst bei einfachen Anfragen weniger zu rechnen, wäre dann eher nicht mein Ziel

• Interessanter Denkanstoß! Wir wollen intern auch darüber sprechen, ob unser AI-Crawler beim Entwurf dynamisch erkennen sollte, ob er je nach besuchter Website mehr oder weniger Anfragen stellen soll. Zur Einordnung: Wir sind samaritanscout.org, ein Suchmaschinenprojekt, das alle lokalen Freiwilligenangebote aus verschiedenen Non-Profit-Websites an einem Ort zusammenführt

• Ich bin erst seit Kurzem in LLMs und AI eingestiegen, finde dieses Projekt aber enorm spannend. Besonders intuitiv beeindruckt mich, dass AutoThink den Rechenaufwand je nach Schwierigkeit des Problems anpasst, damit AI „klüger denkt“ — ähnlich wie Menschen 2+2 sofort lösen und nur über schwierigere Probleme ernsthaft nachdenken. Ich verstehe technische Elemente wie Token-Budgets oder Steering Vectors noch nicht gut, aber ich finde die Idee faszinierend, gleichzeitig schneller und klüger zu werden. Ich werde das weiter verfolgen

• Ich denke, bei LLMs sollte man lieber nicht die Begriffe „Denken“ oder „Schlussfolgern/Reasoning“ verwenden — beide Wörter haben eine bestimmte Bedeutung und philosophische Vorgeschichte, während LLMs in Wirklichkeit nicht so denken oder schlussfolgern, sondern eher einfach mehr Rechenarbeit (Prozessorzeit) einsetzen, um ein Ergebnis zu erzeugen

  • Das Schiff ist bereits abgefahren. Früher bedeutete das Wort „Computer“ auch einen menschlichen Rechner, heute meint es vollständig die Maschine — hier hat sich die Terminologie genauso verschoben

  • Ich würde es mit „ping“ vergleichen — wenn man eine IP-Adresse „pingt“, schickt man auch nicht wirklich Schallwellen auf einen Metallrumpf, aber als Metapher für das tatsächliche Verhalten wird es sinnvoll verwendet. Wenn eine Metapher nützlich ist, muss sie nicht 1:1 mit der Realität übereinstimmen, um alltäglich gebraucht zu werden

  • Mein Weltbild ist im Prinzip materialistisch und deterministisch. Im Alltag kommt aber Existenzialismus dazu und sogar ein wenig spirituelles Empfinden. Aus praktischer Sicht hilft es, solchen Werkzeugen vorübergehend anthropomorphe Eigenschaften zuzuschreiben, weil dadurch der Gesprächsfluss leichter wird und man das Werkzeug intuitiver versteht. Diese Methode stößt manchmal an ihre Grenzen, aber dann kann man leicht zu einem analytischeren Rahmen wechseln, denke ich