In der Prompt-Messung dieser Serie steht ein Modell mit 35 Prozent ganz unten. Die Zahl ist echt gemessen. Der Schluss, den man daraus zieht, wäre trotzdem falsch gewesen — und zwar in beide Richtungen zugleich.
Es geht um laguna-xs-2.1, ein 33,4-Milliarden-Modell in 4-Bit-Quantisierung. Im großen Prompt-Vergleich habe ich seine Spalte gesondert ausgewiesen statt sie mitzumitteln, mit der Begründung: Es läuft in nahezu jeder Zelle ins Token-Limit, gemessen wird dort das Limit und nicht der Prompt. Diese Begründung war richtig. Sie war nur nicht das Ende der Geschichte, sondern der Anfang.
Nicht nahezu jede Zelle. Jede.
48 von 48 Zellen am Anschlag. Auf beiden Maschinen. Und zwar nicht ungefähr gleich, sondern identisch: 117 von 336 Punkten, 15 von 48 formtreu, je Aufgabe 88, 88, 0 und 30 Prozent — auf der Windows-Workstation und auf dem Linux-Container dieselben Zahlen, Ziffer für Ziffer. Zwei Rechner, die sich außer dem GPU-Modell fast nichts teilen — nicht einmal den Platinenhersteller, hier eine EVGA und dort eine Zotac. Sie kommen unabhängig voneinander zum selben Ergebnis. Das ist kein Zufall einer Maschine. Das ist eine Eigenschaft.
Also habe ich getan, was auf der Seite Wie ich messe als Regel steht: die Ausgaben gelesen, nicht nur die Punktzahlen. Was dort steht, ist unmissverständlich.
ERGEBNIS: {"rechnungsnummer": "RG-2026-0417", ... "faellig_am": "2026-03-13"}</assistant>ERGEBNIS: {"rechnungsnummer": "RG-2026-0417", ...Das Modell löst die Aufgabe. Vollständig, mit korrektem Datum über die Monatsgrenze hinweg. Dann setzt es </assistant> — sein Zeichen für „ich bin fertig“ — und fängt von vorne an. Und nochmal. Und nochmal, bis nach 4000 Token die Reißleine greift. In den 48 Ausgaben steht dieses Zeichen 684-mal. Es ist der einzige Marker dieser Art; es gibt keinen zweiten Kandidaten, über den man rätseln müsste.
Der Grund ist beschämend banal. Die Ollama-Verpackung dieses Modells enthält keine einzige Stopp-Angabe. Ihr Template ist eine Zeile, {{ .Prompt }}, ohne Rollen-Markierungen. Das Modell sagt „fertig“, und niemand hört zu. Es lag nicht am Denkmodus — der war ohnehin abgeschaltet, und das Feld für Denkschritte blieb in allen Läufen leer.
Korrigiert am 02.08.2026: Der think-Schalter steuert nicht zuverlässig, ob gedacht wird — bei qwq:32b und deepseek-r1:14b ist er nachweislich wirkungslos. „Abgeschaltet“ trifft hier also nicht auf jedes Modell zu. Einzelheiten unter Wie ich messe.
Zwei Zeilen
FROM laguna-xs-2.1:latest
PARAMETER stop "</assistant>"Mehr ist es nicht. Das abgeleitete Modell teilt sich die Gewichte mit dem Original, kostet also keinen zusätzlichen Plattenplatz, und lässt das Original unangetastet — wichtig, denn das Original ist der Beleg und muss nachprüfbar bleiben. Auf ein schlichtes „Hallo“ antwortete es vorher mit 2000 Token und 80 Wiederholungen. Danach mit zehn Token: Hello! How can I assist you today? Schluss.
Was die Korrektur ändert
| Original | mit Stopp-Angabe | |
|---|---|---|
| Zellen am Token-Limit | 48 von 48 | 3 von 48 |
| Formtreue | 31 % | 83 % |
| Punkte | 117 / 336 | 215 / 336 |
| erzeugte Token gesamt | 192 000 | 45 775 |
| Rechenzeit | 1594 s | 326 s |
Ein Viertel der Token, ein Fünftel der Zeit, fast das Doppelte an Punkten. So weit die erwartbare Hälfte der Geschichte.
Die unerwartete Hälfte
Der Defekt hat nicht nur nach unten verfälscht. Er hat auch nach oben verfälscht, in derselben Messung, bei einer anderen Aufgabe.
| Aufgabe | Punkte vorher | Punkte nachher | Formtreue |
|---|---|---|---|
| rechnung | 88 % | 75 % ↓ | 25 % → 100 % |
| plan | 88 % | 88 % | 0 % → 100 % |
| extrakt | 0 % | 100 % ↑ | 100 % → 100 % |
| raetsel | 30 % | 39 % | 0 % → 33 % |
Bei rechnung war das Modell vorher besser. Der Grund liegt in meiner eigenen Prüfroutine: Sie nimmt den letzten ERGEBNIS-Marker im Text. Bei einer einmaligen Antwort ist das vernünftig — Modelle korrigieren sich manchmal, und die letzte Fassung ist die gemeinte. Bei achtzig Wiederholungen ist es etwas anderes: Das Modell bekommt faktisch achtzig Versuche, und benotet wird der letzte. Das ist keine Messung mehr, das ist eine Lotterie mit vielen Losen.
Bei extrakt schlug dieselbe Regel in die Gegenrichtung aus. Dort wurde die letzte Wiederholung von der Token-Grenze mitten im JSON gekappt. Unlesbar, also null Punkte — für ein Modell, das die Aufgabe in Wahrheit in jeder einzelnen Zelle vollständig löst. Von 0 auf 100 Prozent, ohne dass sich am Modell etwas geändert hätte.
Daraus folgt eine Regel, die jetzt auf der Methodikseite steht: „Der letzte Marker gilt“ setzt voraus, dass genau einmal geantwortet wird. Wo ein Modell durchläuft, muss die Prüfroutine das melden und die Zelle sperren, statt eine von vielen Wiederholungen zu benoten. Ich hatte die Endlosgenerierung erkannt und gekennzeichnet — aber ich hatte nicht gesehen, dass sie meiner Auswertungsregel den Boden entzieht.
Was hier nicht behauptet wird
- Drei Zellen laufen weiterhin ins Limit, alle drei bei der Rätselaufgabe mit der Schritt-für-Schritt-Variante, über alle Seeds. Das ist kein Verpackungsfehler mehr, sondern ein Modell, das sich an der schwersten Aufgabe festredet — 2202 Token im Median, gegenüber 97 bei der leichtesten. Das bleibt so stehen und wird nicht wegerklärt.
- Das angebotene Update behebt es nicht. Der Vergleich der Manifeste zeigt: Der Template-Layer ist lokal und entfernt identisch, die Gewichte unterscheiden sich. Das Update tauscht also das Modell aus, nicht die Verpackung. Ich habe die neuen Gewichte nicht geprüft — ich sage nur, dass es keinen Grund gibt, von ihnen die Lösung dieses Problems zu erwarten, und dass ein Austausch mitten in einer laufenden Messreihe deren Vergleichbarkeit zerstört.
- Das ist keine Aussage darüber, ob laguna ein gutes Modell ist. Es ist eine Aussage über vier Aufgaben, bei abgeschaltetem Denkmodus, in einer bestimmten Verpackung. 64 Prozent sind die ehrlichere Zahl als 35 — die wahre Zahl sind sie deshalb noch lange nicht.
Warum das hier steht
Weil der bequeme Weg offen gelegen hätte. Die Spalte war bereits gesondert ausgewiesen, mit einer sachlich zutreffenden Begründung. Niemand hätte nachgefragt. Ein Modell mit 35 Prozent am Tabellenende ist eine völlig unauffällige Zeile.
Das Unangenehme daran ist nicht der Fehler des Modells. Es ist, dass meine eigene Auswertungsregel unter ihm zusammengebrochen ist, ohne dass irgendetwas nach einem Fehler ausgesehen hätte. Die Zahl war plausibel, die Begründung war korrekt, das Protokoll war sauber. Gefunden habe ich es nur, weil ich die erzeugten Ausgaben gelesen habe — dieselbe Regel, die in dieser Serie schon einmal verhindert hat, dass eine korrekt antwortende Maschine mit null Prozent bewertet wird.
Zur Sicherheit habe ich die korrigierte Messung auf der zweiten Maschine wiederholt. Wieder 215 von 336 Punkten, wieder 40 von 48 formtreu, wieder dieselben drei Zellen am Limit — und exakt dieselben 45 775 erzeugten Token. Nicht ungefähr dieselben: alle 48 Ausgaben sind zwischen den beiden Rechnern zeichenweise identisch. Verschiedene Prozessoren, verschiedene Betriebssysteme, gleiches GPU-Modell auf Platinen zweier verschiedener Hersteller. Unterschieden hat sich einzig die Wanduhr, 326 gegen 338 Sekunden — also genau das, was sich zwischen zwei Maschinen unterscheiden darf.
Das gilt für den kaputten Zustand genauso: dort kamen beide Hosts unabhängig voneinander auf dieselben 117 von 336 Punkten. Was hier gemessen wurde, ist in beiden Fällen keine Eigenart einer Kiste. Es ist das Modell.
Mir ist eine kleinere Aussage lieber, die ich verteidigen kann, als eine größere, die ich zurücknehmen muss. Hier war es beides gleichzeitig: eine Zahl, die zu klein war, und in ihr eine zweite, die zu groß war.