Wo lasse ich lokale Modelle laufen? Notebook oder Server
Im ersten Teil ging es um die Modellqualität: sieben Aufgaben aus dem .NET- und T-SQL-Alltag, Cloud-Modelle gegen lokale, objektiv verifiziert durch Compile-, Unit- und Runtime-Tests. Das Ergebnis war eindeutig — für Analyse und Review reichen lokale Modelle inzwischen, für Codegenerierung mit subtilen Korrektheitsanforderungen nicht.
Eine Frage blieb dabei offen. Alle Messungen liefen auf einem MacBook Pro und einem Windows-Desktop: Was ändert sich, wenn dasselbe Modell auf professioneller Rechenzentrums-Hardware läuft? Für diesen Nachtrag stand ein Server mit einer RTX 6000 Pro Blackwell zur Verfügung. Gemessen wurden zwei Modelle auf beiden Maschinen — ein dichtes und ein Mixture-of-Experts-Modell —, macht vier unabhängige Messreihen.
Das Ergebnis vorweg, weil es die Reihenfolge der Entscheidungen umdreht: Die Architektur entscheidet stärker als die Maschine. Zwischen dichtem und MoE-Modell liegt auf demselben Notebook Faktor 3 — mehr als zwischen Notebook und Rechenzentrums-Server beim selben Modell.
Warum erst dieser Vergleich sauber ist
Bislang hatte jede Gegenüberstellung zwei Variablen gleichzeitig: eine andere Maschine und ein anderes Modell. Diesmal nicht. Beide Modelle liefen auf beiden Maschinen, mit gleichen Aufgaben, gleichem Sampling und vergleichbarer Quantisierung: Qwen2.5-Coder-32B-Instruct als dichtes und Qwen3.6-35B-A3B als MoE-Modell.
| MacBook Pro M5 Max | Server mit RTX 6000 Pro | |
|---|---|---|
| Speicher | 128 GB Unified Memory, rund 546 GB/s | 96 GB GDDR7, rund 1,79 TB/s |
| Laufzeitumgebung | LM Studio mit llama.cpp (Metal) | vLLM hinter einem Proxy |
| Dichtes Modell | GGUF Q4_K_M, 19,9 GB | AWQ 4 bit |
| MoE-Modell | GGUF Q4_K_M, 22,1 GB | FP8 |
| Belegter Speicher | rund 20 GB | rund 20 GB von 96 GB |
| Betrieb | mobil, keine laufenden Kosten | deutsches Rechenzentrum, Monatsmiete |
Der wichtigste Unterschied steht in der ersten Zeile: Die Speicherbandbreite des Servers ist rund dreimal so hoch. Bei einem dichten Modell ist Inferenz fast reine Bandbreitenarbeit — genau daran hängt am Ende das Tempo.
Was der Modelltyp mit der Maschine macht
Ein dichtes Modell rechnet bei jedem Token sämtliche Parameter durch. Ein Mixture-of-Experts-Modell trägt sehr viele Parameter, aktiviert je Token aber nur einen kleinen Teil davon. Alle Werte auf dem MacBook gemessen:
| Modell | Architektur | aktiv je Token | Speicher | tok/s |
|---|---|---|---|---|
| Qwen3-Coder-Next 80B | MoE | ~2,5 Mrd. | 65,6 GB | 76,8 |
| Qwen3.6-35B-A3B | MoE | ~3 Mrd. | 22,1 GB | 77 |
| gpt-oss-120b | MoE | ~5 Mrd. | 63,4 GB | 37,4 |
| Qwen2.5-Coder-32B | dense | 32 Mrd. | 19,9 GB | 24 → 8 |
Weniger Speicher heißt nicht schneller. Die Aussage steckt in den beiden mittleren Zeilen: Zwei Modelle, die praktisch gleich viel Speicher belegen — 22,1 gegen 19,9 GB —, unterscheiden sich im Tempo um Faktor 3. Es zählt nicht die Größe des Modells, sondern wie viel davon je Token gerechnet wird.
Für einen Hardwarevergleich ist ein dichtes Modell trotzdem die richtige Wahl: Es fordert die Maschine am stärksten und macht Unterschiede sichtbar, die bei einem MoE-Modell verborgen blieben. Wer ausschließlich MoE-Modelle einsetzt, erreicht die Grenzen des Notebooks entsprechend später als hier gezeigt.
Die Qualität ändert sich nicht
Dieselben sieben Aufgaben, je drei Läufe, zwei Modelle, zwei Maschinen:
| Aufgabe | dicht: Mac | dicht: Server | MoE: Mac | MoE: Server |
|---|---|---|---|---|
| A · Nebenläufigkeit | 0 von 3 | 1 von 3 | 0 von 3 | 0 von 3 |
| B · T-SQL-Aggregation | 0 von 3 | 0 von 3 | 1 von 3 | 1 von 3 |
| C · Code-Review | 3 von 3 | 3 von 3 | 3 von 3 | 3 von 3 |
| D · Blazor-Dialog | 0 von 3 | 2 von 3 | 0 von 3 | 2 von 3 |
| E · EF-Core-Abfrage | 0 von 3 | 0 von 3 | 0 von 3 | 0 von 3 |
| F · Regex-Parser | 0 von 3 | 0 von 3 | 0 von 3 | 0 von 3 |
| G · Refactoring | 3 von 3 | 3 von 3 | 2 von 3 | 1 von 3 |
| Gesamt | 6 von 21 | 9 von 21 | 6 von 21 | 7 von 21 |
Bessere Hardware macht ein Modell schneller, nicht klüger. Interessant sind dabei nicht die Differenzen — sechs zu neun beim dichten, sechs zu sieben beim MoE-Modell —, sondern das Muster dahinter: Das Code-Review gelingt in allen vier Reihen vollständig, EF-Core-Abfrage und Regex-Parser scheitern in allen vier am selben Fehler. Bei der Abfrage kompiliert der Code und läuft, liefert aber falsche Werte; beim Parser fehlt jedes Mal derselbe Modifizierer. Das sind Eigenschaften des Modells, nicht der Maschine.
Der einzige nennenswerte Unterschied zwischen den beiden Modellen liegt beim Refactoring: Das spezialisierte Coder-Modell löst es vollständig, das neuere MoE-Modell fällt dort ab. Es ist ein Generalist, kein Coder-Modell — dafür gewinnt es bei der T-SQL-Aggregation.
Warum die Architektur über Dauerlast entscheidet
Was die Maschine ändert, ist das Tempo — und die vier Messreihen ergeben ein vollständiges Vier-Felder-Bild:
| MacBook Pro M5 Max | Server mit RTX 6000 Pro | |
|---|---|---|
| dichtes Modell (32 Mrd. aktiv) | 24 → 8 tok/s, drosselt | 65 tok/s, konstant |
| MoE-Modell (3 Mrd. aktiv) | 77 tok/s, konstant | 177 tok/s, konstant |
Drei der vier Felder sind unauffällig: Der Server hielt sein Tempo mit beiden Modellen über alle 21 Läufe — 65,4 Token pro Sekunde beim dichten Modell bei einer Spanne von nur 64,1 bis 65,7 und 176,7 beim MoE-Modell bei 161,4 bis 178,0. Auch das Notebook blieb mit dem MoE-Modell stabil. Nur das dichte Modell auf dem Notebook startete bei rund 24 und wurde immer langsamer.
Um andere Ursachen auszuschließen, folgte ein kontrollierter Serientest: Docker gestoppt, ein Slot statt vier, kleinerer Kontext, achtmal dieselbe Anfrage hintereinander, Systemlast durchgehend stabil. Derselbe Aufbau lief anschließend mit dem MoE-Modell, damit die Kurven vergleichbar sind.
| Durchlauf | dichtes Modell | MoE-Modell |
|---|---|---|
| 1 | 23,8 | 76,2 |
| 2 | 23,3 | 78,1 |
| 3 | 22,5 | 79,5 |
| 4 | 21,1 | 68,6 |
| 5 | 19,5 | 74,9 |
| 6 | 18,0 | 70,2 |
| 7 | 15,0 | 73,8 |
| 8 | 8,4 | 74,7 |
Ein Rückgang um 65 Prozent bei konstanter Systemlast — und alle plausiblen Störfaktoren waren vorher ausgeschlossen. Das ist thermische Drosselung, kein Messrauschen.
Die rechte Spalte ist der eigentliche Befund dieses Nachtrags: Dasselbe Notebook, derselbe Aufbau, dieselbe Zahl an Läufen — nur eine andere Modellarchitektur. Das MoE-Modell startet bei 76,2 und liegt nach acht Läufen bei 74,7. Das ist kein Trend nach unten, das ist die normale Schwankung zwischen zwei Läufen.
Der Grund liegt in der Rechenlast je Token. Ein MoE-Modell aktiviert nur einen Bruchteil seiner Parameter und erzeugt damit deutlich weniger Abwärme pro erzeugtem Token. Bei anhaltender Volllast über mehrere tausend Token gibt zwar auch das MoE-Modell nach, findet aber ein Plateau bei rund 80 Prozent seines Ausgangswerts, statt wie das dichte Modell ohne Boden durchzurutschen — dieses landet nach acht Läufen bei einem Drittel.
Ein dichtes 32-Milliarden-Modell ist auf einem Notebook nicht dauerlastfähig. Für einzelne Anfragen spielt das keine Rolle: Wer eine Frage stellt und die Antwort liest, bekommt vom Einbruch nichts mit. Für agentische Schleifen oder Stapelverarbeitung, bei denen Anfrage auf Anfrage folgt, bricht die Leistung dagegen nach wenigen Minuten ein — mit einem MoE-Modell dagegen nicht.
Die Architektur entscheidet also stärker als die Maschine. Zwischen dichtem und MoE-Modell liegen auf demselben Notebook 24 gegen 77 Token pro Sekunde, also Faktor 3. Zwischen Notebook und Rechenzentrums-Server liegt beim selben Modell Faktor 2,7. Wer lokal betreiben will, wählt deshalb zuerst die Modellarchitektur und danach die Hardware — nicht umgekehrt.
Bemerkenswert nebenbei: Der Abstand zwischen Notebook und Server fällt beim MoE-Modell kleiner aus als beim dichten. Das Notebook holt genau dort auf, wo die Architektur zu ihm passt.
Wie genau ist diese Messung?
Bei Unterschieden von einem oder zwei Punkten stellt sich die Frage, wie viel davon überhaupt Signal ist. Also lief derselbe Test dreimal: dasselbe Modell, dieselbe Maschine, dieselben Aufgaben.
| Aufgabe | Durchgang 1 | Durchgang 2 | Durchgang 3 | Abweichung |
|---|---|---|---|---|
| A · Nebenläufigkeit | 0 von 3 | 0 von 3 | 0 von 3 | keine |
| B · T-SQL-Aggregation | 1 von 3 | 0 von 3 | 1 von 3 | 1 Punkt |
| C · Code-Review | 3 von 3 | 3 von 3 | 3 von 3 | keine |
| D · Blazor-Dialog | 0 von 3 | 0 von 3 | 0 von 3 | keine |
| E · EF-Core-Abfrage | 0 von 3 | 0 von 3 | 0 von 3 | keine |
| F · Regex-Parser | 0 von 3 | 0 von 3 | 0 von 3 | keine |
| G · Refactoring | 2 von 3 | 2 von 3 | 1 von 3 | 1 Punkt |
| Gesamt | 6 von 21 | 5 von 21 | 5 von 21 | ±1 Punkt |
Fünf der sieben Aufgaben liefern in allen drei Durchgängen exakt dasselbe Ergebnis. Nur B und G schwanken um je einen Punkt — beides Aufgaben, bei denen das Modell knapp an der Lösung liegt. Gewertet wird in der Tabelle darüber der erste Durchgang; die beiden anderen bleiben als Rohdaten liegen und dienen genau dieser Streuungsmessung.
Damit ist die Messgenauigkeit erstmals gemessen statt geschätzt — und sie ändert die Lesart aller Zahlen hier: Ein Punkt Unterschied ist Rauschen, keine Aussage. Sechs gegen sieben heißt gleichwertig. Erst ab etwa drei Punkten Abstand lohnt sich eine Interpretation, so wie beim Modellvergleich aus dem ersten Teil, wo fünf gegen zehn standen.
Was die Rechenleistung kostet
Öffentlich verfügbare Angaben, Stand August 2026:
| Variante | Kosten | Anmerkung |
|---|---|---|
| Server mit 96-GB-Karte, deutscher Anbieter | rund 1.200 bis 1.600 € im Monat | je nach RAM-Ausstattung, zzgl. Einrichtung |
| Größere Variante mit 768 GB RAM | rund 2.100 € im Monat | nach der Preisanpassung im April 2026 |
| Einführungspreis desselben Angebots | 889 € im Monat | Dezember 2025 — inzwischen überholt |
| Karte als Neukauf | rund 8.500 → 13.250 USD | Markteinführung 2025 gegen heute, plus 55 % |
| MacBook Pro M5 Max, 128 GB | einmalige Anschaffung | keine laufenden Kosten, mobil einsetzbar |
Die Preise bewegen sich derzeit stark nach oben: Beim Hosting kam im April 2026 eine Anpassung um knapp die Hälfte, der Kaufpreis der Karte legte binnen anderthalb Jahren um 55 Prozent zu — Ursache ist die Knappheit bei GDDR7-Speicher. Wer heute rechnet, sollte die Angaben vor einer Entscheidung direkt beim Anbieter prüfen; die öffentlich auffindbaren Zahlen widersprechen sich teils, weil ältere Vergleichsseiten noch den Einführungspreis führen. Ein Anbieter ist hier bewusst nicht genannt — die Auswahl ist austauschbar, vergleichbare Angebote gibt es bei mehreren deutschen Rechenzentren.
Welches Modell wofür?
Die Messwerte in Einsatzgebiete übersetzt — die beiden Modelle haben unterschiedliche Stärken:
| Einsatzgebiet | Spezialisiertes Coder-Modell | Generalistisches MoE-Modell |
|---|---|---|
| Code-Review, Bug-Suche, Erklärungen | geeignet | geeignet |
| Legacy-Refactoring | gut geeignet | eingeschränkt |
| SQL-Abfragen, einfache Aggregation | eingeschränkt | eingeschränkt |
| Nebenläufigkeit, Framework-Randbereiche | nicht geeignet | nicht geeignet |
| Agentische Schleifen, Stapelverarbeitung | nicht geeignet — drosselt | geeignet, bleibt stabil |
| Arbeiten mit vertraulichem Code | geeignet | geeignet |
„Nicht geeignet" heißt hier: in keinem der drei Läufe ein verwendbares Ergebnis.
Lokale Modelle sind Analysewerkzeuge, keine Codegeneratoren. Beim Code-Review erreichen beide Modelle die volle Punktzahl — dort ersetzen sie einen Cloud-Dienst ohne Abstriche. Bei Generierung mit subtilen Korrektheitsanforderungen scheitern beide zuverlässig an denselben Aufgaben. Die Architektur entscheidet dann nur noch darüber, wie lange man durchhält: Wer in agentischen Schleifen arbeitet, kommt am MoE-Modell nicht vorbei.
Wann welche Maschine?
Das Notebook genügt für einzelne Anfragen und interaktives Arbeiten, für Reviews und die Analyse sensibler Codebestände. Es ist mobil einsetzbar und verursacht keine laufenden Kosten. Für Dauerlast taugt es nur mit einem MoE-Modell — mit einem dichten Modell bricht es ein.
Der Server liefert das zwei- bis dreifache Tempo, unabhängig von der Architektur und ohne Einbruch unter Dauerlast, hat mit 96 GB VRAM Platz auch für große Modelle und bedient mehrere Nutzer parallel. Dafür laufen die Kosten monatlich weiter.
Die Frage ist nicht, welche Maschine besser ist — sondern wie oft man sie braucht. Bei gelegentlicher Nutzung gewinnt das Notebook, weil es ohnehin vorhanden ist. Bei durchgehender Auslastung gewinnt der Server, weil er das Tempo hält. Die Modellqualität spielt bei dieser Entscheidung keine Rolle: Sie ist auf beiden Maschinen gleich.
Die erste Entscheidung ist aber ohnehin eine andere. Wer lokal betreiben will, wählt zuerst die Modellarchitektur und danach die Maschine — das richtige Modell auf dem vorhandenen Notebook schlägt das falsche Modell auf gemieteter Rechenzentrums-Hardware.
Alle elf Folien des Nachtrags stehen unten in der Galerie, die vollständige Präsentation gibt es als PDF zum Herunterladen. Grundlagen und Modellqualität behandelt der erste Teil.