In meiner Windows-Workstation steckt eine RTX 3090, die demnächst ausgebaut und als Proxmox-AI-Host neu aufgesetzt wird. Vorher wollte ich für jedes Modell, das ich darauf halte, eine ehrliche Zahl haben — keinen Bauchtest, keinen Screenshot aus einer Bestenliste, sondern eine Messung, die ich später auf anderer Hardware wiederholen und tatsächlich vergleichen kann.
Also liefen über Nacht 26 Modelle durch. Rund 600 Anfragen, null Fehler, danach 5,3 Stunden Dauerlast. Was dabei herauskam — einschließlich der Stellen, an denen meine eigene Methode falsch war.
Die Regeln, die ich mir gesetzt habe
Jede Aufgabe brauchte eine Lösung, die ein Skript prüfen kann. Kein „diese Antwort wirkt besser“. Elf Aufgaben je Modell:
- Fünf Denkfallen — die klassischen. Drei Maschinen, die in drei Minuten drei Teile fertigen; Schläger und Ball für 1,10, wobei der Schläger einen Dollar mehr kostet. Bewertet wird die letzte Zahl der Antwort.
- Drei Programmieraufgaben — Palindrom, Fibonacci, überlappende Intervalle zusammenfassen. Der Code wird extrahiert, auf die Platte geschrieben und von Python tatsächlich ausgeführt, geprüft gegen einen Assert-Block. Er läuft durch oder er läuft nicht durch.
- Eine JSON-Extraktion — geparst, jedes Feld auf seinen Wert geprüft.
- Zwei Bildaufgaben für die Vision-Modelle — auf selbst erzeugten Bildern, damit die Lösung eindeutig ist statt „was ich zufällig als Screenshot herumliegen hatte“.
Temperatur 0, fester Seed, damit sich das Ganze wiederholen lässt.
Denken ist keine Kosmetik
Jede Denkaufgabe lief zweimal — einmal mit abgeschalteter Gedankenkette, einmal mit. Über alle 19 Textmodelle stieg die Trefferquote von 74/95 auf 88/95. Einzelne Modelle sprangen drastisch: eines von 1/5 auf 5/5.
Der Preis schwankt enorm. qwen3-coder erreicht die volle Punktzahl mit etwa 65 Denk-Tokens. qwen3.5:27b verbraucht 2.435 und schafft trotzdem nur 3/5 — das schlechteste Verhältnis im Feld und der Grund, warum es gelöscht wurde.
Eine Aufgabe ist die Ausnahme, die die Regel erst brauchbar macht: Das Maschinen-Problem gewinnt durch Denken nichts. 18/22 in beiden Modi. Ein Modell, das diese Falle falsch versteht, versteht sie mit Gedankenkette genauso falsch — es begründet den Fehler nur ausführlicher.
24 GB tragen 64k Kontext — fast überall
Ich habe acht Modelle über 4k, 16k, 32k und 64k Kontext gemessen und dabei verfolgt, was Ollama an VRAM gegenüber der Gesamtgröße meldet. Sobald ein Teil des Modells auf der CPU landet, bricht der Durchsatz ein.
Sieben von acht hielten 64k vollständig im VRAM — auch die 35B-Modelle mit rund 20 GB — und verloren dabei nur 11 bis 39 Prozent Durchsatz. Eines nicht: qwq:32b lagerte 11 Prozent auf die CPU aus und fiel auf 2,9 tok/s, ein Einbruch um 91 Prozent.
Das sah nach einer sauberen VRAM-Geschichte aus, bis ich Tage später die Modell-Metadaten prüfte. qwq:32b hat eine architektonische Grenze von 40.960 Tokens. Ich hatte es bei 32k und 64k getestet — an und jenseits seiner eigenen Spezifikation. Der Einbruch könnte ebenso sehr am Überschreiten dieser Grenze liegen wie am Speicherdruck, und meiner ursprünglichen Deutung traue ich nicht mehr.
Die Größe sagt fast nichts über das Tempo
ornith:35b läuft mit 116 tok/s. qwen3.6:27b schafft 42 — und ist die kleinere Datei. Der Unterschied ist die Architektur: Mixture-of-Experts-Modelle aktivieren nur wenige Milliarden Parameter je Token, dichte Modelle alle, und die Dekodiergeschwindigkeit hängt auf dieser Karte an der Speicherbandbreite.
Es gibt eine harte Obergrenze, die man sich merken sollte. Ein dichtes 35B-Modell in Q4 kann auf einer 3090 rund 47 tok/s nicht überschreiten — 936 GB/s geteilt durch 19,7 GB. Jeder dreistellige Durchsatzwert bei einem „35B“-Modell bedeutet also wenige aktive Parameter, niemals einfach „gutes Modell“. Wer zwei Modelle nach Tempo vergleicht, ohne das zu prüfen, vergleicht Architekturen und nennt es Qualität.
5,3 Stunden Dauerlast
53 Runden im Wechsel mit den fünf größten Modellen. Durchsatzdrift über alle fünf: ±1,3 Prozent. Thermische Drosselung trat in 2 von 7.432 Messpunkten auf — 0,03 Prozent. Die Karte hält das aus.
Der nützlichere Befund ist eine Warnung davor, Hardware für KI überhaupt so zu prüfen. Dieselbe Karte, dieselben 350 Watt, zwei verschiedene Lasten:
| Sensor | LLM-Inferenz | 3DMark Steel Nomad |
|---|---|---|
| Kern | 78,6 °C | 77,7 °C |
| Hot Spot | 93,7 °C | 91,8 °C |
| Memory Junction | 104,0 °C | 92,0 °C |
Kern und Hot Spot sind nahezu identisch. Der Speicher läuft unter LLM-Last 12 °C heißer, weil Inferenz bandbreitenbegrenzt ist und die Speicherchips durchgehend belastet, wie es ein Grafikbenchmark nicht tut. Der Grafiktest zeigte 18 °C Abstand zur 110-°C-Drossel. Die reale Arbeitslast zeigte sechs.
3DMark kann einen Inferenz-Host nicht abnehmen. Es meldet, dass alles in Ordnung ist — genau bis zu dem Punkt, an dem es das nicht mehr ist.
Wo ich danebenlag
Zwei Modelle schnitten schlecht ab, und ich hatte sie zunächst abgeschrieben. Dann habe ich statt der Zusammenfassung die Rohdaten je Anfrage angesehen.
qwq:32b kam auf 1/5 beim direkten Reasoning und 0/3 beim Code. Das liest sich wie „kann nicht programmieren“. Ist es nicht. Alle vier gescheiterten Denkversuche endeten exakt am Tokenlimit, und die Programmierfehler sahen im Python-Interpreter alle so aus:
File "_pruef_C1.py", line 1
Okay, I need to write a Python function called is_palindrome...
^^^^^ SyntaxErrorDas Modell ignoriert die Bitte, das Denken abzuschalten, und gibt seine Überlegungen als normalen Text aus, bis das Budget aufgebraucht ist. Einen Code-Block liefert es nie. Das ist ein völlig anderer Defekt als „schreibt schlechte Algorithmen“, und er verlangt eine andere Reaktion.
Die Lehre lässt sich verallgemeinern: Scheitern hat drei Ausgänge, nicht zwei. Gelöst, falsch beantwortet, nie fertig geworden. Wer die letzten beiden zusammenwirft, veröffentlicht selbstbewussten Unsinn. Neun meiner Zellen entpuppten sich als erschöpftes Budget statt als Unvermögen.
Ein dritter Fall ging allein auf meine Kappe. Ein Modell kam bei JSON auf 0/3. Es hatte völlig korrektes JSON erzeugt — und es dann endlos wiederholt. Mein regulärer Ausdruck war gierig und spannte über alle Wiederholungen, also scheiterte das Parsen. Das Modell war in Ordnung, mein Parser nicht.
Was ich behalten habe
| Rolle | Modell | Begründung |
|---|---|---|
| Allrounder | gemma4:26b | Volle Punktzahl überall bei 96 tok/s, dazu der flachste Abfall bis 64k Kontext im Feld |
| Code und Werkzeuge | qwen3-coder | 154 tok/s, alles gelöst, rund 65 Denk-Tokens Vorlauf |
| Schneller Alltag | qwen3:8b | 120 tok/s bei 9 GB — zwei passen auf eine Karte |
| Harte Denkaufgaben | ornith:35b | Volle Punktzahl in beiden Modi bei 116 tok/s, kein Kontextüberlauf |
| Bilder | qwen2.5vl:7b | Beide Bildaufgaben gelöst bei 9,2 GB |
| Ausgemustert | qwq:32b, llama3.2:1b, qwen3.5:27b | Siehe oben — und qwen3.5 wird von qwen3.6 bei identischer Größe geschlagen |
Der Teil, den man mitnehmen sollte
Wenn du eine Sache mitnimmst, dann die Methode und nicht die Zahlen — meine Zahlen gelten für eine Karte und eine Modellauswahl.
- Den Code ausführen. Die Ausgabe eines Modells zu lesen und plausibel zu finden, ist keine Messung.
- Rohdaten je Anfrage protokollieren, nicht nur eine Zusammenfassung. Jede Korrektur in diesem Beitrag stammt daher. Eine Zusammenfassung ist eine Projektion unter einer Metrikdefinition — ändert man die Metrik, ist sie wertlos, während die Rohdaten überleben.
- „Falsch“ von „nie fertig geworden“ trennen. Diese eine Unterscheidung war mehr wert als jede andere Entwurfsentscheidung.
- Prüfen, ob das Abschalten des Denkens überhaupt wirkt — je Modell. Es kostet zwei Anfragen: dieselbe Frage in beiden Modi stellen und die Tokenzahlen vergleichen. Bei manchen Modellen tut der Schalter gar nichts, und man misst eine Achse, die es dort nicht gibt.
Als Nächstes: dieselben zwölf Modelle auf einem neueren Ollama, und danach dieselben zwölf auf einer zweiten RTX 3090, die per Thunderbolt an einem Linux-Rechner hängt — gleiche Karte, völlig anderer Aufbau.