Die gängige Annahme lautet: Ein Sprachmodell muss erst seine Antwort fertig formuliert haben, bevor es ein Werkzeug aufruft. Genau diese Annahme stellt ein neuer Ansatz namens Speculative Programmatic Tool Calling infrage. Der Entwickler Alex Zhang zeigt in seinem aktuellen Blogbeitrag, dass ein LLM-Agent Werkzeuge bereits starten kann, während die Token-Generierung noch läuft – und damit spürbar Latenz einspart.
Wenn du schon einmal mit LLM-Agenten gearbeitet hast, kennst du das Muster: Das Modell generiert einen Text, am Ende steht ein Tool-Call, und erst nach dem vollständigen Text wird die Funktion ausgeführt. Bei klassischen JSON-Tool-Calls ist das in Ordnung, weil die Generierung selbst kein Engpass ist. Anders sieht es aus, wenn das Modell in einer Code-REPL arbeitet und Codezeilen als Aktionen nutzt. Dann wartet das System erst auf das komplette Programm, um dann die Tools auszuführen – eine Verschwendung von Rechenzeit, die man vermeiden kann.
Die Grundidee: Speculation statt Warten
sPTC überträgt ein Konzept aus der CPU-Entwicklung auf LLM-Harnesses: spekulative Ausführung. In CPUs werden Befehle vorzeitig ausgeführt, bevor klar ist, ob sie tatsächlich gebraucht werden. Ähnlich schlägt Zhang vor, Tool-Aufrufe aus dem bereits generierten Code vorab zu starten, während das Modell noch weitere Tokens produziert. Wenn der vollständige Code dann tatsächlich diese Tools aufruft, liegen die Ergebnisse bereits im Cache vor.
Das ist besonders relevant für Systeme, die auf Recursive Language Models (RLMs) setzen. Hier ist die zentrale Idee, dass Code in einer REPL das einzige Tool ist, das ein System braucht – alle anderen Tools sind Funktionen in dieser Code-Umgebung. Und weil Sub-Agenten oder Such-APIs in solchen Architekturen oft die teuersten und langsamsten Operationen sind, machen sie den Großteil der Latenz aus.
Die Beobachtung ist simpel: Die Generierung des Hauptkontexts dauert lange, und die darin geplanten Tool-Aufrufe warten derweil. Wenn man sie schon während der Generierung startet, überlappt man zwei latenzintensive Prozesse.
Zwei Hebel, die Zeit sparen
Zhang identifiziert zwei klare Zeitgewinne. Der erste liegt im Overlapping: Statt nach der vollständigen Generierung die Tools auszuführen, startet sPTC die Tool-Calls bereits, während die Tokens gestreamt werden. Das macht besonders viel aus, wenn Modelle lange „denken“ und viele Zwischenschritte generieren.
Der zweite Gewinn ist subtiler und erinnert an einen JIT-Compiler. In einer REPL können Tool-Aufrufe in einer Reihenfolge stehen, die scheinbar sequenziell ist, aber eigentlich voneinander unabhängig. Zwei Sub-Agenten, die nacheinander aufgerufen werden, könnten auch parallel laufen. sPTC erkennt solche Fälle und startet die Aufrufe gleichzeitig – eine primitive, aber effektive Optimierung, die sich über Sprachen und REPL-Designs hinweg verbessern lässt.
Das bedeutet konkret: Das System profitiert doppelt – von der Überlappung mit der Token-Generierung und von der Parallelisierung unabhängiger Calls. Je langsamer die Tools sind, desto größer der Vorteil.
Die Technik dahinter: Schatten-REPL und Promises
Der Implementierungsansatz im Codebase von Zhang ist bemerkenswert einfach. Die zentrale Idee ist ein Hook um spekulierbare Tool-Funktionen. Während die LLM-Ausgabe gestreamt wird, parst ein Schatten-REPL den bereits erzeugten Code und führt potenzielle Tool-Aufrufe vorzeitig aus. Die Ergebnisse werden als Future beziehungsweise Promise in einem globalen Speicher abgelegt.
Wenn der echte Code später ausgeführt wird, greifen die Original-Funktionen auf diesen Speicher zu und holen sich das bereits berechnete Ergebnis. Das funktioniert über eine Umbenennung von Namespaces: Der reale Namensraum enthält die echten Tools, der Schatten-Namensraum die spekulativen Versionen. Während des Streamings arbeitet der Schatten-REPL mit dem partiellen Code; nach der vollständigen Generierung läuft der echte Code und findet die vorab berechneten Werte.
Wichtig ist dabei, dass der Schatten-REPL nicht als echter Ausführungskontext dient. Er ist eine tiefe Kopie der REPL-Umgebung, so dass Nebenwirkungen den Hauptzustand nicht verändern. Externe Funktionen wie `open` gelten als unsicher und werden nicht spekuliert. Der gesamte REPL-Code wird als Einheit betrachtet: Wenn das Modell fehlerhaften Code produziert, bleibt der reale Zustand sauber.
Was sich überhaupt spekulieren lässt
Nicht jeder Tool-Aufruf kann vorzeitig gestartet werden. Zhang unterscheidet mehrere Fälle. Der einfachste Fall sind Literale: Ein Aufruf wie `llm_query(„Gib mir einen Titel für: Die Odyssee“)` kann direkt parst und ausgeführt werden, sobald die Zeile im Stream auftaucht. Auch Abhängigkeiten von Variablen sind möglich, solange die vorgelagerten Berechnungen als sicher gelten – also pur, ohne Seiteneffekte.
Es gibt aber auch Fälle, in denen die Spekulation blockiert ist. Wenn die Eingabe eines Tool-Calls von einer Datei abhängt oder von einer Funktion, die externe Zustände verändert, wird nicht spekuliert. Gleiches gilt für Aufrufe innerhalb von Schleifen oder Bedingungen, deren Laufzeit oder Ergebnis nicht vorhersehbar ist. Hier verhält sich das System konservativ.
Ein weiterer Punkt ist die Eindeutigkeit von Tool-Aufrufen. Zwei identische Aufrufe an denselben Sub-Agenten sollen nicht doppelt ausgeführt werden, es sei denn, sie sind deterministisch. Deshalb werden Instanzen individuell verfolgt. Das ist wichtig für Mehrheitsvoten über mehrere Agenten hinweg.
Benchmarks: Realistische Verbesserungen zwischen 1 und 1,2x
Wie viel bringt das Ganze? Zhang hat mit seinem Team auf OOLONG-Datensätzen (trec-coarse, 132k und OOLONG-Pairs, 32k) gemessen, mit einer vLLM-Server-Instanz auf 8xH100-GPUs und dem Modell Qwen3-30B-A3B-Instruct. Sie testeten sowohl mit temperture 0,7 als auch mit 0,0, um die Varianz der RLM-Trajektorien zu kontrollieren. Jede Konfiguration lief fünfmal.
Die Ergebnisse zeigen Speed-ups im Bereich von 1 bis 1,2x gegenüber einer Basis-Architektur ohne Spekulation. Das klingt bescheiden, ist aber wichtig einzuordnen: Die tatsächliche Verbesserung hängt stark von der Latenz der Tools, der Anzahl der generierten Tokens, der Server-Auslastung und den Entscheidungen der Harness-Komponente ab. Bei langsameren Tool-Aufrufen oder längeren Denk-Phasen fällt der Vorteil deutlich größer aus.
Auch die Parallelisierung unabhängiger Sub-Agenten wurde in der Auswertung berücksichtigt. In der Praxis zeigt sich: Je mehr unabhängige Aufrufe im Code stecken, desto mehr profitiert das System von der „naiven JIT-Compiler“-Rolle. Die vorgestellten Zahlen sind daher als unterer Grenzwert zu verstehen.
Eine Designphilosophie, die offene Fragen lässt
Der Vorschlag von Zhang ist keine ausgereifte Theorie, sondern eine pragmatische Harness-Technik. Er selbst weist darauf hin, dass die Idee in viele Richtungen weiterentwickelt werden könnte – etwa durch bessere Vorhersagen über Bedingungen oder durch detailliertere Analysen des partiellen Codes. Die derzeitige Implementierung priorisiert Sicherheit und Einfachheit.
Für dich als Entwicklerin oder Entwickler bedeutet das: sPTC ist ein konkretes Werkzeug, das du in eigene Systeme einbauen kannst, wenn du mit Code-REPLs und sub-LLM-Calls arbeitest. Der Code ist kurz, lesbar und auf GitHub verfügbar. Die Technik zeigt, dass die größten Latenzgewinne nicht unbedingt aus besseren Modellen kommen, sondern aus klügerem Harness-Design.
Am Ende bleibt eine nüchterne Erkenntnis: Overlapping und Parallelisierung sind keine Zauberei, sondern handwerkliche Optimierung. Genau solche Bausteine werden den Unterschied machen, wenn LLM-Agenten in Echtzeit-Umgebungen eingesetzt werden sollen.
Quelle: alexzhang13.github.io
