Jeder Benchmark-Beitrag auf dieser Seite steht auf denselben zwei Maschinen, demselben Prüfstand und denselben Regeln. Statt das in jedem Artikel zu wiederholen, steht es hier. Die Artikel verweisen hierher; diese Seite wird nachgeführt, wenn sich der Aufbau ändert.
Wenn Sie nur einen Abschnitt lesen, dann die Regeln. Jede einzelne davon gibt es, weil eine bereits veröffentlichte Messung von mir am Ende etwas anderes gemessen hat als das, was ich behauptet hatte.
Die zwei Maschinen
Beide Läufe verwenden dasselbe GPU-Modell — eine RTX 3090 mit 24 GB — aber nicht dieselbe Platine: die eine Karte ist eine EVGA, die andere eine Zotac. Sonst ist fast nichts gleich — und genau das ist der Punkt. Wenn zwei derart verschiedene Kisten dieselben Bytes erzeugen, ist das Ergebnis kein Artefakt einer bestimmten Maschine.
| Workstation | Container ohne Bildschirm | |
|---|---|---|
| Rolle | Arbeitsplatz, Monitor angeschlossen | LXC auf einem Proxmox-Knoten |
| GPU | RTX 3090, 24 GB | RTX 3090, 24 GB |
| NVIDIA-Treiber | 610.88 | 580.126.09 |
| CPU | i7-7820X, 8 Kerne / 16 Threads | i7-1165G7, 6 Threads sichtbar |
| RAM | 128 GB | 24 GB |
| Betriebssystem | Windows 11 Pro | Ubuntu 24.04 LTS |
| Modellspeicher | SATA-SSD | lokale Platte, nicht NFS |
| Ollama | 0.32.5 | 0.32.5 |
Ein Unterschied wiegt schwerer, als er aussieht: der angeschlossene Monitor kostet rund 1,8 GB VRAM, bevor überhaupt ein Modell geladen ist. Bei jedem Modell, das nicht bequem in 24 GB passt, lagert die Workstation deshalb mehr auf die CPU aus als die Kiste ohne Bildschirm. Das ist keine Fußnote, sondern der häufigste Grund, warum zwei ansonsten gleiche Läufe auseinanderlaufen.
Was gemessen wird
- Durchsatz — erzeugte Token je Sekunde, aus Ollamas eigenen Werten
eval_countundeval_duration. Berichtet als Median, nie als Mittelwert. - Trefferquote — ein Skript prüft, ob die Antwort richtig ist. Nicht, ob sie sich gut liest.
- Formtreue — kam die Antwort in der Form, die verlangt war? Wird getrennt geführt und nie in die Trefferquote gerechnet.
- Preis — erzeugte Token und Wanduhrsekunden. Ein Verfahren, das nichts bringt und nichts kostet, ist eine andere Nachricht als eines, das nichts bringt und die Hälfte obendrauf kostet.
- VRAM und CPU-Auslagerung — aus Ollamas
/api/ps, je Messzelle festgehalten.
Was bewusst nicht gemessen wird
Sprachliche Qualität. Nützlichkeit. Ton. Es gibt hier keine Note für „der Marketingtext ist gut“, weil ich das nicht messen kann — und ein zweites Sprachmodell, das das erste benoten soll, kann es auch nicht. Ein Modell als Richter bringt die Streuung eines zweiten Modells ins Spiel und verkleidet sie als Zahl. Bewertet wird ausschließlich, was ein Skript gegen eine feste Antwort prüfen kann: parst das JSON, zeigt der Anker auf eine ID, die es gibt, sind es exakt 985,77 Euro, trägt jede Wirkaussage einen Belegmarker.
Diese Strenge hat einen Preis: Die Benchmarks belohnen das Befolgen von Anweisungen und können nicht sagen, mit welchem Modell sich angenehmer arbeiten lässt. Mir ist eine schmale, genaue Aussage lieber als eine breite, vage.
Die Regeln — jede aus einem Fehler entstanden
Reservierter Kontext ist nicht gefüllter Kontext
num_ctx auf 128k setzen und dann einen 30-Token-Prompt schicken misst die Reservierung des KV-Caches, nicht seine Nutzung. Ich habe „Kontext ist fast gratis“ auf genau diesem Fehler veröffentlicht und zurücknehmen müssen. Jede Kontextmessung protokolliert jetzt den tatsächlichen Füllgrad aus prompt_eval_count und weist ihn im Ergebnis aus.
Nach jedem Kontextwechsel aufwärmen
Ollama lädt das Modell neu, sobald sich num_ctx ändert; die erste gemessene Bedingung trägt dann die Ladekosten. In einem Rauchtest ließ das einen leeren Kontext langsamer aussehen als einen vollen — 85,7 gegen 139,2 Token/s. Also: nach jedem Wechsel eine verworfene Anfrage, dann messen.
Der Prompt-Cache macht Prefill-Zahlen wertlos
Wiederholt man einen Prompt, bedient der Cache ihn: einmal standen 295 631 Token/s im Prefill — das ist übersprungene Arbeit, keine Geschwindigkeit. Fülltext wird je Wiederholung variiert. Wo Prompts unvermeidlich einen gemeinsamen Anfang haben, wird Prefill schlicht nicht berichtet. Der Generierungsdurchsatz bleibt in beiden Fällen gültig.
Antwortlänge festnageln, sonst ist der Vergleich nicht gepaart
Bei frei laufender Antwortlänge fallen auf jedem Host unterschiedlich viele Anfragen durch einen Filter, und die beiden Seiten sind nicht mehr vergleichbar — ein Lauf war genau daran unbrauchbar, 36 verwertbare Zellen gegen 24. num_predict steht fest, und die Prompt-Token-Zahlen beider Hosts werden gegeneinander geprüft, bevor irgendein Unterschied berichtet wird. Stimmen sie nicht überein, gibt es nichts zu berichten.
Zahlen kommen aus den Rohsätzen
Jede Anfrage wird beim Abschluss in eine JSONL-Datei geschrieben. Alle veröffentlichten Zahlen werden aus diesen Dateien neu gerechnet, nie aus einem Laufprotokoll oder einer Zusammenfassung abgelesen. Zusammenfassungen sind zum Draufschauen, während ein Lauf arbeitet.
Die Ausgaben lesen, nicht nur die Punktzahlen
Eine Prüfroutine ist Software und kann falsch sein. Zwei Beispiele aus diesem Jahr: Eine Prüfung verlangte Aufzählungszeichen, die die Aufgabe nie gefordert hatte, und drückte ein korrekt antwortendes Modell von 100 auf 69 Prozent. Und eine Prüfung suchte eine Ergebniszeile, erkannte sie aber nicht, wenn das Modell sie in eine Markdown-Überschrift packte — Modelle, die die Aufgabe gelöst hatten, standen auf null. Beides kam beim Lesen der tatsächlichen Ausgaben heraus. Jede Prüfroutine wird jetzt gegen echte Antworten gegengelesen, bevor sie einen Lauf bewerten darf, und jede Ausgabe wird vollständig aufbewahrt, damit man der Bewertung widersprechen kann.
Abgeschnitten ist keine schlechte Antwort
Ein Modell, das in die Token-Grenze läuft, hat nicht schlecht geantwortet, sondern nicht zu Ende. Solche Zellen werden gezählt und gesondert gekennzeichnet. Ein Modell, das in jedem einzelnen Lauf an die Decke stößt, bekommt eine eigene Anmerkung statt eines stillen Platzes am Tabellenende.
CPU-Auslagerung bricht die Reproduzierbarkeit
Solange ein Modell vollständig in den VRAM passt, reproduziert ein fester Seed bei Temperature 0 über Maschinen hinweg. Sobald ein Teil auf der CPU läuft, gilt das nicht mehr — und wie viel auf der CPU läuft, hängt davon ab, was sonst noch die Karte belegt, der Desktop eingeschlossen. Jedes Modell, das nicht passt, wird als solches gekennzeichnet und aus Aussagen über Maschinengleichheit herausgehalten.
Zeilenenden sind kein Befund
Die jüngste Regel, und eine billige Lehre. Der Vergleich der Ausgaben zwischen Windows- und Linux-Host meldete, 97 von 99 Dateien seien verschieden — ein spektakuläres Ergebnis, das vollständig aus meinem eigenen Dateischreiben stammte: CRLF auf der einen Seite, LF auf der anderen. Normalisiert lautete die echte Zahl 90 von 99 identisch. Die Prüfstände schreiben jetzt ausdrücklich \n. Wenn eine Messung dramatisch ist, verdächtige zuerst die Messung.
Wie die Zahlen zu lesen sind
- Punktzahlen sind, wo möglich, vollständig gelöste Zellen und keine gemittelten Teilpunkte. Eine halb richtige Rechnungssumme ist eine falsche Rechnungssumme.
- Jeder Lauf umfasst drei Seeds (42, 43, 44) bei Temperature 0, damit kein Modell von einer glücklichen Antwort getragen wird.
- Für alles Zeitbezogene Mediane, keine Mittelwerte.
- Gemessen wird durchgängig mit abgeschaltetem
think. Bei Reasoning-Modellen ist das eine Aussage über das Modell mit ausgeschaltetem Denkmodus, nicht über das Modell. - Hat ein Modell weniger Zellen als die anderen — Zeitbudget aufgebraucht, Lauf abgeschnitten —, steht das in der Tabelle.
Korrekturen
Widerspricht ein späterer Artikel einem früheren, gewinnt der spätere, und beide sagen es dazu. Korrekturen werden im ursprünglichen Artikel vorgenommen und nicht stillschweigend in einem neuen. Zwei veröffentlichte Aussagen wurden auf diesem Weg bereits zurückgenommen; beide sind oben bei den Regeln benannt statt versteckt.
Wenn Sie meinen, eine Zahl hier sei falsch: die Rohausgaben existieren. Fragen Sie danach.