Lass dein LLM nicht abschreiben

Wer schon einmal ein Chat-System auf Basis eines Sprachmodells gebaut hat, kennt das Muster. Einfache Anfragen laufen unauffällig: Frage hinein, es dauert einen kurzen Moment und die Antwort ist da. Sobald die Antwort jedoch mehr Substanz braucht – eine Übersicht, eine Auswertung, eine aufwändige Tabelle –, kippt das Bild. Der Nutzer wartet, es gibt keinen sichtbaren Fortschritt, und erst nach längerer Wartezeit erscheint die fertige Antwort.

Die naheliegende Erklärung lautet: Die Anfrage war komplexer, also braucht das Modell länger zum Nachdenken – analog zu einem Menschen, der bei einer schwierigen Frage länger überlegt. Diese Erklärung ist plausibel und führt in unserem Fall heute zuverlässig an die falsche Stelle.

Die Ausgangslage

Der Aufbau ist in solchen Systemen fast immer derselbe. Das Modell verfügt über ein Tool, mit dem es Daten beschafft – eine Katalogsuche, eine Datenbankabfrage, einen API-Call. Dieses Tool liefert eine Ergebnisliste in voller Breite zurück: viele Treffer, pro Treffer viele Felder. Nehmen wir als Beispiel eine strukturierte Tool-Antwort von fünfzig Zeilen mit je zwanzig Feldern.

Dem Nutzer soll das in dieser Form nicht direkt vorgelegt werden. Er hat nach etwas Bestimmtem gefragt, also sind vielleicht vierzig dieser fünfzig Zeilen relevant, und von den zwanzig Feldern sind sieben von Interesse. Diese Reduktion ist die Aufgabe des Modells: Aus einer langen, breiten Liste wird eine kürzere, schmale Tabelle.

Entscheidend ist eine Unterscheidung, die beim Entwickeln leicht untergeht. Diese eine Aufgabe besteht aus zwei Teilaufgaben, die man gedanklich auseinander halten sollte:

Erstens ist zu entscheiden, welche Zeilen in die Antwort gehören. Das erfordert Urteilsvermögen: fünfzig Einträge lesen, mit der Anfrage abgleichen, auswählen.

Zweitens ist die Tabelle zu schreiben. Kopfzeile, Trennlinie, vierzig Zeilen mit je sieben Zellen.

Wie ein Mensch vorgehen würde

Zur Veranschaulichung gehen wir einen Schritt aus der Software heraus. Ein Kollege erhält eine Liste mit fünfzig Zeilen und den Auftrag: die Zeilen heraussuchen, die ein bestimmtes Kriterium erfüllen und das heruntergebrochen auf sieben festgelegte Spalten.

Ihm stehen zwei Wege offen.

1. Weg eins: Er überträgt die passenden Zeilen von Hand auf ein leeres Blatt, Spalte für Spalte. Bei vierzig Zeilen und sieben Spalten sind das 280 Zellen, darunter lange Produktbezeichnungen und Links. Das kostet ihn Stunden, und da Menschen beim Abschreiben Fehler machen, ist die Chance nicht gering, im finalen Ergebnis Zahlendreher oder ähnliche Fehler zu finden.
2. Weg zwei: Er zieht den Computer hinzu. Er öffnet die Liste in einer Tabellenkalkulation, geht sie einmal durch, markiert die passenden Zeilen, blendet die überflüssigen Spalten aus und lässt die neue Tabelle erzeugen. Sein Beitrag ist das Markieren; das Erzeugen übernimmt die Maschine.

Der wesentliche Punkt an diesem Vergleich: Beide Wege erfordern dieselbe Denkleistung. In beiden Fällen muss er fünfzig Zeilen lesen und beurteilen. Diese Arbeit lässt sich weder abkürzen noch delegieren, sie ist der eigentliche Auftrag. Unterschiedlich ist allein, wer anschließend die Tabelle produziert. Die wenigsten Menschen, denen beide Wege offenstehen, würden freiwillig den ersten wählen – nicht weil das Auswählen schwierig wäre, sondern weil das Abschreiben langwierig und ermüdend ist.

Das Modell wählt stets den ersten Weg

Ein Sprachmodell, das eine gefilterte Tabelle ausgibt, geht Weg eins. Ausnahmslos.

Es liest die fünfzig Zeilen, entscheidet, welche vierzig passen – das ist die gewünschte Leistung –, und schreibt diese vierzig Zeilen anschließend Zelle für Zelle neu. Token für Token, obwohl die Werte fertig und korrekt in seinem Kontext vorliegen.

Das Interessante dabei ist, dass auch für das Sprachmodell gilt: Nicht das Denken dauert lange, sondern das Schreiben.

Der technische Grund ist unspektakulär. Den Input verarbeitet ein Modell parallel: Der gesamte Prompt durchläuft das Netz in einem Durchgang, die Prefill-Phase. Ob dort 4.000 oder 15.000 Tokens ankommen, macht kaum einen Unterschied – das skaliert in die Breite. Die Ausgabe funktioniert grundlegend anders. Output-Tokens entstehen autoregressiv, eines nach dem anderen. Für jedes Token läuft ein vollständiger Forward-Pass. Dabei kann Token Nr. 7 nicht berechnet werden, bevor Token Nr. 6 feststeht, da es als Kontext eingeht. Diese Decode-Phase ist inhärent sequentiell und nicht parallelisierbar.

Lesen skaliert in die Breite, Schreiben in die Länge. Diese Aussage lässt sich prüfen.

Aufbau des Experiments

Grundlage ist ein synthetischer Katalog mit fiktiven Produkten: fünfzig Zeilen mit je zwanzig Spalten. Sieben Spalten sind für die Anzeige vorgesehen, darunter ein Deeplink und eine ausführliche Artikelbezeichnung. Eine Zeile zur Veranschaulichung:

| artikelnummer | deeplink                     | bezeichnung_lang                                  | kategorie   | hersteller | groesse   | einheit |
| ------------- | ---------------------------- | ------------------------------------------------- | ----------- | ---------- | --------- | ------- |
| A-10000       | [A-10000](https://…/a-10000) | Stirnlampe Basic Aurox verstärkte Naht, Alu, 12er | Beleuchtung | Aurox      | universal | Set     |

Das Filterkriterium ist bewusst einfach gehalten: gesucht sind alle Artikel, die für den Außeneinsatz geeignet sind. Genau vierzig der fünfzig Zeilen erfüllen es. Das ist der methodische Kern des Aufbaus: Da die korrekte Antwort eindeutig feststeht, ist jede Abweichung ein Buchhaltungsfehler des Modells und keine Ermessensfrage. Unter dieser Bedingung ist das Ergebnis zuverlässig messbar.

Verglichen werden zwei Varianten derselben Aufgabe, mit demselben Modell, sodass die einzige Variable ist, was ausgegeben wird. Als Modell dient zunächst gpt-5.4.

Erster Hebel: auswählen statt ausgeben

Das entspricht Faktor 9,7 bei der Latenz und einer Reduktion der Output-Tokens um 96,5 Prozent – der Input, der einen Großteil der Tokenanzahl ausmacht, bleibt unverändert, die Gesamtkosten sinken also weniger stark. Die etwa zwanzig Sekunden, die das Modell zuvor mit Abschreiben verbracht hat, erledigt Code in einem Zehntel einer Millisekunde.

Wesentlich ist, dass dieser Hebel allein durch die Änderung der Ausgabeform entsteht. Modell und Datengrundlage sind identisch; unterschiedlich ist nur, was verlangt wird.

Nebenbei entfällt damit eine ganze Fehlerklasse. Das Ergebnis des Tools ist deterministisch, und der Code kopiert es unverändert in die Tabelle – kein Wert läuft durch das Sprachmodell. Halluzinierte Artikelnummern oder ins Leere zeigende Deeplinks sind damit nicht seltener, sondern logisch ausgeschlossen.

Naheliegender Einwand: Streaming. Wer die Tabelle Token für Token ausliefert, verkürzt die Zeit bis zum ersten Zeichen – an der Gesamtdauer, den Output-Kosten und der Abschreibarbeit ändert das nichts. Streaming verdeckt die zwanzig Sekunden, es entfernt sie nicht. Variante B entfernt sie und gibt dafür den sichtbaren Fortschritt auf: Die Zeilennummern sind erst am Ende verwertbar, die Tabelle erscheint als Block.

Der Einfluss des Zeilengewichts

Eine erste Fassung des Experiments arbeitete mit kurzen Zellwerten – ohne Links, mit knappen Bezeichnungen, rund 29 Output-Tokens pro Zeile. Der Effekt war vorhanden, aber deutlich kleiner. Erst mit realistisch schwereren Zeilen, also mit Deeplink und langer Bezeichnung, wird das Bild vollständig. Am selben Modell gemessen, hier gpt-5.4-mini:

Zeilengewicht	A: schreiben	B: markieren	Faktor
leicht (29 Tokens/Zeile)	5,2 s	1,54 s	3,4
schwer (64 Tokens/Zeile)	9,7 s	1,61 s	6,0
Veränderung	+87 %	+4,5 %

Die Quelltabelle wuchs dabei um 55 Prozent. Die Laufzeit von Variante A hat sich annähernd verdoppelt, weil sie mehr als doppelt so viel schreiben musste – 1.149 gegen 2.545 Output-Tokens. Variante B legte nur minimal zu: Sie liest die zusätzlichen 2.200 Tokens mit, schreibt aber unverändert 88. Damit ist die Prefill-Decode-Asymmetrie kein theoretisches Argument mehr, sondern ein Messwert – zusätzliche Latenz entsteht praktisch nur durch zusätzlichen Output.

Praktisch bedeutet das: Der Hebel wächst mit dem Tokengewicht der Zeilen. Den größten Einzelposten stellt in dem Beispiel der Deeplink. Eine schwere Zeile wiegt 64 statt 29 Tokens, und der Zuwachs besteht fast vollständig aus URL und Langtext – also aus Kopierarbeit ohne Informationsgehalt. Knapp die Hälfte der Schreibzeit entfällt auf Zeichenketten, die der Code byte-genau kennt.

Zweiter Hebel: ein kleineres Modell

Damit steht eine Frage im Raum, die das Verfahren in Zweifel zieht: Wenn das Auswählen die eigentliche Urteilsleistung ist, müsste sie dann nicht ins stärkere Modell gehören statt ins kleinere?

Die Messung beantwortet das. Die Auswahl, jeweils auf den schweren Zeilen:

Modell	A: schreiben	B: markieren
gpt-5.4	21,7 s	2,24 s
gpt-5.4-mini	9,7 s	1,61 s

Damit sind es zwei getrennte Hebel, die man auch getrennt betrachten sollte:

• Hebel eins – nur auswählen lassen. Bei gpt-5.4 verkürzt das die Antwort um Faktor 9,7, bei gpt-5.4-mini um Faktor 6,0. Er beruht ausschließlich darauf, dass mechanische Ausgabe an Code übergeht, und wirkt bei jedem Modell.
• Hebel zwei – ein kleineres Modell einsetzen. Innerhalb von Variante B bringt der Wechsel Faktor 1,4, vor allem aber deutlich geringere Kosten.

Zusammen führen beide von 21,7 auf 1,61 Sekunden, also Faktor 13,5. Wie sich dieser Gesamtgewinn auf die zwei Hebel verteilt, hängt von der Betrachtungsreihenfolge ab – dominierend ist in jeder Reihenfolge die Ausgabeform, nicht die Modellgröße.

Dass die Auswahl an das kleinere Modell gehen darf, liegt nicht daran, dass sie leicht wäre – sondern daran, wie klein der Schaden ausfallen kann. Das Modell gibt nur Zeilennummern aus, und jede denkbare Ausgabe verweist damit auf eine Zeile, die es wirklich gibt; Nummern außerhalb des Bereichs verwirft der Code, bevor die Tabelle entsteht. Eine erfundene Artikelnummer oder einen ins Leere zeigenden Link kann das Modell in dieser Rolle nicht hervorbringen.

Beim Abschreiben ganzer Zellen ist der Ausgaberaum unbegrenzt. Eine verdrehte Ziffer sieht aus wie eine echte Artikelnummer und fällt nur im Vergleich mit der Quelle auf – wer diesen Vergleich anstellen kann, braucht das Modell dafür nicht. Deshalb übernimmt Code das Übertragen.

Was bleibt, ist die Auswahl selbst: Das Modell kann die falsche Zeile nehmen oder eine übersehen, und das bemerkt zur Laufzeit niemand. Für diese Aufgabe muss also ein Modell gewählt werden, das vorab ausreichend geprüft wurde.

Die Antwort bleibt vollständig

Ein Einwand liegt nahe: Wenn das Modell nur noch Zeilennummern liefert, verliert der Nutzer dann nicht die Antwort auf seine eigentliche Frage? Er hat ja meist nicht „gib mir eine Tabelle“ gefragt, sondern etwas Inhaltliches.

Das ist nicht der Fall, denn das Modell kann beides gleichzeitig ausgeben – die Markierung und einen erläuternden Text:

{"zeilen": [1, 3, 4, 5, 7, 8, 10, 12, ...],
 "antwort": "Für den Außeneinsatz geeignet sind folgende 40 Artikel."}

Der Code baut daraus die Antwort: erst die Prosa, dann die Tabelle. Beides geht ge meinsam an den Nutzer, und die Tabelle stammt weiterhin vollständig aus den Originaldaten.

Diese Erweiterung ist nahezu kostenlos. Gemessen, wieder auf den schweren Zeilen und mit einer inhaltlichen Nutzerfrage zusätzlich zur Auswahl:

Modell	ohne Prosa	mit Prosa	Zuwachs
gpt-5.4-mini	1,61 s / 88 Tokens	1,88 s / 126 Tokens	+0,27 s / +38 Tokens
gpt-5.4	2,24 s / 88 Tokens	2,95 s / 142 Tokens	+0,71 s / +54 Tokens

Die Auswahl leidet darunter kaum: gpt-5.4 traf in allen zehn Läufen genau die vierzig erwarteten Zeilen. gpt-5.4-mini fand ebenfalls in jedem Lauf alle vierzig, wählte aber in einem Lauf eine Zeile zu viel – einen Artikel, der das Kriterium nicht erfüllt. Die Prosa hat den Fehler dabei selbst verraten – sie sprach von 41 Artikeln.

Die untere Grenze

Nach unten ist die Modellwahl begrenzt. Mit einem älteren, kleineren Modell (gpt-4.1-mini) war die Auswahl in keinem von zwanzig Läufen vollständig: Regelmäßig fehlten zwei bis drei der vierzig Zeilen, ohne dass die Antwort dadurch auffällig geworden wäre – eine Tabelle mit siebenunddreißig statt vierzig Zeilen sieht vollständig aus. Der Engpass liegt dabei nicht in der Ausgabemenge, sondern in der Zahl der Zeilen, die ein einzelner Aufruf beurteilen muss.

Abhilfe schafft es, die Bewertung auf mehrere Aufrufe mit jeweils weniger Zeilen zu verteilen. Aufgeteilt in fünf parallele Blöcke à zehn Zeilen und im Code zusammengeführt, waren zwanzig von zwanzig Läufen vollständig – und schneller als der einzelne Aufruf. Bei beiden gpt-5.4-Modellen war eine Aufteilung nicht nötig.

Jenseits von Tabellen

Die zentrale Regel ist einfach:

Gibt ein Modell etwas aus, das strukturiert bereits vorliegt, schreibt es ab.

Abschreiben ist stets eine Fehlerquelle.

Dasselbe Muster findet sich auch außerhalb von Tabellen. Ein Modell, das eine ganze Datei ausgibt, um drei Zeilen zu ändern, verbringt seine Zeit mit Abschreiben; ebenso eines, das einen Textabschnitt wiederholt, nur um sich darauf zu beziehen. Wo solche Stellen merklich Geschwindigkeit kosten und Geschwindigkeit gefordert ist, hilft derselbe Griff: das Modell nicht abschreiben, sondern nur auswählen lassen – ein Diff statt der ganzen Datei, eine Referenz statt der Wiederholung. Die Grenze ist dort erreicht, wo Werte nicht weitergereicht, sondern verändert werden müssen – summiert, umgerechnet, umsortiert. Dann ist die Ausgabe kein Abschreiben mehr, und der Griff greift nicht.

Fazit

Ein Sprachmodell „denkt“ schnell und schreibt langsam. Lässt man es abschreiben, was bereits vorliegt, bezahlt man den Unterschied in Sekunden, in Token-Kosten und irgendwann in falschen Daten. Die Aufgabe besteht nicht darin, das Modell schneller schreiben zu lassen, sondern darin, ihm das Schreiben abzunehmen.