Lesezeit ca. 11 Minuten
Ein Petaflop auf dem Schreibtisch. Der Engpass war trotzdem nie die Rechenleistung.
Was Sie merken, ist etwas anderes: dass eine Antwort zehn Sekunden braucht, für einen Satz.
Seit vier Wochen läuft bei mir ein lokaler KI-Stack auf eigener Hardware. Kein Pilot, kein Wochenendversuch, sondern täglicher Betrieb mit Agenten, die Code prüfen, recherchieren und Berichte schreiben. Was dabei entstanden ist, sind Messwerte. Die interessantesten davon widersprechen dem, was ich vorher erwartet hätte.
Dieser Beitrag zeigt sie. Nicht als Kaufberatung, sondern als das, was in keinem Datenblatt steht.
Der Aufbau
Zwei Geräte, klare Rollen. Eines ist für Workflows und Automatisierung vorgesehen, eines läuft für Inferenz und Agenten. Beide ohne Bildschirm, Zugriff nur über das eigene Netz. Auf dem Inferenzgerät läuft ein Modellserver, davor ein Agentensystem in Containern mit zwölf Rollenprofilen und einem gemeinsamen Aufgabenboard.
Der Grund für lokale Hardware ist nicht Kostenersparnis. Er ist Datenhoheit. Bestimmte Unterlagen verlassen das Haus nicht, und für diese Fälle braucht es ein Modell, das im eigenen Netz antwortet.
So weit die Absicht. Jetzt die Zahlen.
Was das Datenblatt verspricht
Der Chip ist ein NVIDIA GB10 Grace Blackwell Superchip. Bis zu einem Petaflop bei FP4. 128 GB unified LPDDR5X, davon im Betriebssystem 121 GiB sichtbar und rund 117,9 GiB für Inferenz nutzbar. Das reicht, um mehrere große Modelle gleichzeitig geladen zu halten.
Das klingt nach viel. Es ist auch viel. Nur begrenzt es nicht.
Was tatsächlich begrenzt
Die Speicherbandbreite liegt bei rund 273 GB/s. Das ist die Zahl, die zählt.
Bei der Textgenerierung muss für jedes einzelne Token ein Teil der Modellgewichte durch den Speicher gelesen werden. Wie schnell das geht, bestimmt nicht die Rechenleistung, sondern wie viele Gewichte pro Token bewegt werden müssen. Vier Modelle, alle auf demselben Gerät, Kontext 65.536, jeweils warm gemessen:
| Modell | Architektur | Generierung |
|---|---|---|
| gemma4:26b | MoE, 4B aktiv | 94 Tok/s |
| qwen3-coder:30b | MoE, 3,3B aktiv | 89 Tok/s |
| qwen3.8:27b | dicht 27B, Q8 | 20 Tok/s |
| devstral:24b | dicht 24B, Q4 | 14 Tok/s |
Die beiden ersten sind Mixture-of-Experts-Modelle. Von 26 beziehungsweise 30 Milliarden Parametern sind pro Token nur rund vier aktiv. Die beiden unteren sind dichte Modelle: Jedes Token bewegt alle Gewichte.
Der Faktor zwischen oben und unten ist knapp sieben. Zwischen Modellen ähnlicher Größe, auf derselben Maschine.
Und jetzt die Stelle, an der die verbreitete Faustregel ins Wanken gerät. Das Modell devstral ist mit Q4 stärker quantisiert als qwen3.8 mit Q8, also kleiner pro Parameter. Es ist trotzdem langsamer. Für einen Beweis reicht dieser eine Paarvergleich nicht, dazu unterscheiden sich die beiden in zu vielem auf einmal: Quantisierung, Größe und Modell selbst. Als Warnung reicht er. Wer erwartet, dass stärkere Quantisierung ein dichtes Modell in die Nähe eines MoE-Modells bringt, sollte das auf dieser Hardware nachmessen, bevor er darauf plant.
Wer also plant, welches Modell auf so ein Gerät passt, sollte nicht auf die Parameterzahl schauen und auch nicht zuerst auf die Quantisierung, sondern auf die Zahl der aktiven Parameter.
Die Kennzahl, die in die Irre führt
Bis hierher ist alles noch das erwartbare Bild: schnelle Modelle, langsame Modelle, eine Rangfolge. Dann habe ich etwas anderes gemessen, und die Rangfolge hat sich umgedreht.
Die Frage lautete: „Antworte in einem Satz: was ist ein Failover?" Alle Modelle vorgewärmt, Aufruf über die OpenAI-kompatible Schnittstelle, weil das der Weg ist, den gängige Bibliotheken nehmen.
| Modell | Zeit bis zur Antwort | erzeugte Token | Denkteil, in Zeichen | gemessene Tok/s |
|---|---|---|---|---|
| qwen3-coder:30b | 0,67 s | 40 | keiner | 59,9 |
| gemma4:26b | 4,58 s | 396 | 1.408 | 86,4 |
| qwen3.8:27b | 10,12 s | 136 | 347 | 13,4 |
Lesen Sie die erste und die letzte Spalte zusammen.
Das Modell gemma4 hat mit 86,4 Tok/s den höchsten gemessenen Durchsatz. Bis zur nutzbaren Antwort ist es trotzdem 6,8-mal langsamer als qwen3-coder, das nur 59,9 Tok/s zeigt. Der größte Abstand in dieser Tabelle liegt zwischen qwen3-coder und qwen3.8: Faktor fünfzehn.
Der Grund steht in der Mitte. Für denselben Einzeiler erzeugt gemma4 396 Token, qwen3-coder 40. Fast zehnmal weniger Arbeit schlägt 44 Prozent mehr Tempo pro Token deutlich. Bei gemma4 war der Denkteil dabei rund zehnmal so lang wie der Antwortsatz, gemessen in Zeichen. Er landet in einem eigenen Feld neben der Antwort, und niemand liest ihn. Bezahlt wird die Zeit trotzdem.
Alle drei Antworten waren übrigens fachlich korrekt und in sauberem Deutsch. Es ging hier nicht um Qualität. Es ging um die Frage, wann der Satz da ist.
Vier Einschränkungen, damit die Tabelle nicht mehr behauptet, als sie zeigt. Erstens: eine einzige Zeitmessung je Modell, ohne Wiederholung und ohne Angabe zur Streuung. Zweitens: Bei kurzen Antworten bestimmt die Länge der Antwort die Wartezeit, nicht die Geschwindigkeit pro Token. Drittens: Die Denkzeit hängt an der Frage. Ein Einzeiler ist der Extremfall, viel Nachdenken für wenig Ausgabe, und bei einer komplexen Aufgabe kann sich derselbe Aufwand auszahlen. Viertens: Die Tok/s-Spalte für qwen3-coder ist nach unten verzerrt, weil bei 40 Token die Fixkosten der Anfrage voll durchschlagen. Belastbar ist die Spalte mit der Zeit.
Was bleibt, ist der Befund, und der ist unangenehm für jede Modellübersicht im Netz: Token pro Sekunde misst den Durchsatz, nicht die Wartezeit. Wer ein Modell für eine Aufgabe auswählt, bei der kurze Antworten anfallen, wählt nach der falschen Zahl aus.
Der Zielkonflikt, den niemand gern zeigt
Bleibt die Frage, ob das schnelle Modell dann nicht einfach das bessere ist. Auch dazu gibt es eine Messung, und sie fällt anders aus.
Zwei Modelle bekamen denselben Prüfauftrag, dieselben Dateien, dieselbe Aufgabenstellung: ein Skript auf Fehler durchsehen.
| qwen3.8:27b | gemma4:26b | |
|---|---|---|
| Dauer | rund 40 Minuten | unter 2 Minuten |
| Länge des Berichts | 20.317 Byte | 5.834 Byte |
| Fand den Fehler im Wiederholungsintervall | ja | nein |
| Fand den fehlenden Schnellabbruch | ja | nein |
| Urteil | „vor Produktivbetrieb nachziehen" | „bereit für den Einsatz" |
Das schnelle Modell gab ein Skript frei, das das gründliche mit Vorbehalten versah. Es übersah dabei einen Wiederholungsmechanismus, der mit null Sekunden Wartezeit konfiguriert war, also faktisch keiner ist. Und es machte einen Sachfehler: Es verortete einen Hinweis im Codekommentar und behauptete, die Dokumentation sei nicht ergänzt worden. Das gründliche Modell belegte, dass der Hinweis an anderer Stelle sehr wohl steht.
Bei einem Prüfbericht mit Rechtsfolgen wäre das der teurere Fehler.
Die Konsequenz ist unbequem, aber sie ist die ehrliche: Von den beiden Modellen, die denselben Prüfauftrag bekommen haben, liefert keines Tempo und Prüftiefe zugleich. Beide liegen in der 20- bis 30-GB-Klasse. Ob es dort ein Modell gibt, das beides kann, weiß ich nicht. Ich habe qwen3-coder nie auf Prüftiefe gemessen und devstral gar nicht. Man wählt also aus, welche Eigenschaft die Aufgabe braucht. Für einen Prüfauftrag ist Gründlichkeit die richtige Wahl, auch wenn sie vierzig Minuten kostet. Für eine Rückfallstufe, die antworten soll, wenn nichts anderes mehr antwortet, ist es das Gegenteil.
Was mehr bringt als neue Hardware
Der interessanteste Teil der vier Wochen hat mit dem Gerät nichts zu tun.
Erstens: der Denkaufwand. Die Agentensoftware kennt einen Regler für die Tiefe der Zwischenschritte. Derselbe Auftrag, einmal auf „mittel", einmal auf „niedrig":
| Einstellung | Laufzeit | Ergebnis |
|---|---|---|
| mittel | 56 Minuten, dann abgebrochen | keine Datei |
| niedrig | unter 5 Minuten | vollständiger Bericht, 10.676 Byte |
Auf „mittel" sammelte der Agent Zwischenergebnisse, bis der Kontext überlief, komprimierte seine eigene Historie und begann von vorn. Auf „niedrig" arbeitete er die Punkte ab und schrieb.
Das ist keine Feineinstellung. Das ist der Unterschied zwischen Ergebnis und kein Ergebnis.
Zweitens: Werkzeuge wegnehmen. Jedes Werkzeug, das ein Agent haben kann, kostet Platz im Vorspann jeder Anfrage. Ich habe die Ausstattung von zwanzig auf sieben Werkzeuggruppen gekürzt:
| vorher | nachher | |
|---|---|---|
| Werkzeuggruppen | 20 | 7 |
| Größe der Werkzeugbeschreibungen | 37,7 KB | 20,5 KB |
| Eingabe beim ersten Aufruf | 26.412 Token | 17.904 Token |
| abgelehnte Werkzeugaufrufe | 4 | 0 |
Die Ersparnis ist nett. Wichtiger ist, was sich am Verhalten änderte. Mit Terminal- und Codeausführung im Werkzeugkasten versuchte der Prüf-Agent, eine Datenbank aufzurufen und ein Python-Skript zu schreiben, statt die Datei zu lesen, die er prüfen sollte. Ohne diese Werkzeuge ging er direkt an die Datei.
Ein Agent nimmt, was da ist. Auch wenn es der Umweg ist.
Drittens: der Zuschnitt der Aufgabe. Derselbe Prüfauftrag, einmal mit sechs Punkten formuliert, einmal mit drei. Sechs Punkte: siebzehn Aufrufe, Kontextkompression, kein Bericht. Drei Punkte: ein vollständiger Bericht mit 5.148 Byte, alle Punkte belegt.
Nicht das Modell war der Unterschied. Die Aufgabe war es.
Wer über lokale KI nachdenkt, rechnet meist in Hardware. In der Praxis liegen die größten Hebel davor: wie tief das Modell denken darf, wie viel Werkzeug es sieht, und wie klein die Aufgabe geschnitten ist.
Was man vorher wissen sollte
Drei Dinge, die in keiner Produktvorstellung vorkommen und die im Betrieb Zeit kosten.
Kein ECC. Der unified-Speicher hat keine Fehlerkorrektur. Für Inferenz ist das vertretbar, für Aufgaben mit Nachweispflicht sollte man es wenigstens bewusst entschieden haben.
Die Compute Capability ist neuer als vieles im Ökosystem. Der Chip meldet sm_121. Viele fertige Container und Bibliotheken sind nur bis 12.0 übersetzt und starten schlicht nicht. Das kostet Bauzeit, und zwar mehrfach.
Nicht jedes Modell verträgt jede Einstellung. Zwei der eingesetzten Modelle lehnen die Aufforderung zu Zwischenschritten mit einem Fehler ab, wörtlich: „does not support thinking". Wer das nicht vorher prüft, sieht nur, dass der Agent scheitert, bevor er irgendetwas getan hat. Die Fähigkeiten eines Modells lassen sich am Server abfragen. Das ist ein Zweizeiler und spart einen Abend.
Für wen das nichts ist
Wer gelegentlich einen Chatbot braucht, ist mit einem Cloud-Abo günstiger und schneller dran. Lokale Hardware trägt sich nicht über den Preis pro Antwort, sondern über zwei andere Dinge: Daten, die das Haus nicht verlassen dürfen, und Dauerlast, die konstant anliegt.
Fehlt beides, ist ein Gerät im Serverschrank die teurere Variante von etwas, das es fertig gibt.
Wie ich damit arbeite
Ich betreibe diesen Aufbau nicht, um Modelle zu vergleichen. Ich betreibe ihn, weil ein Teil meiner Arbeit an Daten hängt, die nicht in fremde Rechenzentren gehören, und weil ich wissen will, was solche Aussagen im Alltag kosten.
Was ich dabei gelernt habe, gilt unabhängig von der Marke auf dem Gehäuse: Die Zahl auf dem Datenblatt beschreibt die Obergrenze. Was Sie erleben, entsteht drei Ebenen tiefer, bei der Speicherbandbreite, beim Antwortverhalten des Modells und beim Zuschnitt der Aufgabe. Alle drei lassen sich messen, bevor Sie Hardware kaufen.
Und die Frage, die vor allen technischen steht, ist keine technische: Welche Ihrer Daten dürfen das Haus nicht verlassen, und was ist Ihnen diese Grenze an Wartezeit wert?
