KI-Modellvergleich: das eigene Coding-Modell gegen die Cloud
Ich habe mir ein MacBook Pro M5 Max zugelegt — unter anderem, um KI-Modelle lokal zu betreiben. Jetzt habe ich mir genauer angesehen, was die Maschine tatsächlich leistet. Die naheliegende Frage: Reicht das eigentlich? Oder ist der Eigenbetrieb ein teures Hobby, während die Cloud die Arbeit ohnehin besser erledigt? Statt auf das Bauchgefühl zu hören, habe ich nachgemessen.
Aufgabenstellung und Vorgehen
Der Vergleich stellt das selbst gehostete Qwen3-Coder-Next 80B den Claude-Modellen Haiku 4.5, Sonnet 4.6, Sonnet 5, Opus 4.8, Opus 5 und Fable 5 gegenüber. Später kamen zwei weitere lokale Modelle dazu — gpt-oss-120b und Qwen 3.6 27B; dazu weiter unten mehr. Alle Modelle bekommen sieben praxisnahe Aufgaben aus dem .NET- und T-SQL-Alltag mit identischen Prompts:
- ein thread-sicherer Async-Cache mit TTL und Schutz gegen den Stampede-Effekt,
- eine Stored Procedure für Gruppensalden — mit einer bewusst eingebauten Fan-Out-Falle,
- ein Code-Review eines Schnipsels mit vier platzierten Fehlern,
- ein Blazor-Server-Dialog mit Formular, Validierung und Fehlerbehandlung,
- eine EF-Core-Abfrage, die in genau einem Roundtrip serverseitig übersetzbar sein muss,
- ein Regex-Parser für deutsche Geldbeträge samt Schutz vor katastrophalem Backtracking,
- die Sanierung einer Legacy-Methode mit SQL-Injection und Ressourcenlecks.
Entscheidend ist die Bewertung: Es wurde nicht gelesen, sondern gemessen. Jede Antwort ging durch eine objektive Testbench aus Compile-, Unit-, SQL- und EF-Runtime-Tests. Eine Antwort, die plausibel aussieht, aber nicht kompiliert oder das falsche Ergebnis liefert, fällt damit auf — und genau das ist häufiger passiert, als ein reiner Blick auf den Code vermuten ließe.
Das Ergebnis in einer Tabelle
Bewertung 0–10 je Aufgabe, korrigiert durch die Testbench, gemittelt über alle sieben Aufgaben:
| Modell | Ø |
|---|---|
| Opus 5 | 9,0 |
| Opus 4.8 | 8,7 |
| Sonnet 5 | 8,4 |
| Fable 5 | 8,4 |
| Sonnet 4.6 | 8,0 |
| gpt-oss-120b (lokal) | 5,5 |
| Haiku 4.5 | 5,5 |
| Qwen3-Coder-Next 80B (lokal) | 4,2 |
Opus 5 löst als einziges Modell alle sieben Aufgaben vollständig. Opus 4.8 liegt mit 8,7 dicht dahinter und stolpert an einer lehrreichen Stelle: Es beschreibt im Kommentar einen Schutz gegen katastrophales Backtracking, den der Code gar nicht enthält. Eine Testbench prüft eben nur, wonach sie fragt — und ein Kommentar ist kein Verhalten.
Das erste lokale Modell landet mit 4,2 knapp unter Haiku. Über alle sieben Aufgaben hinweg bestanden davon 12 von 42 Läufen. Das klingt ernüchternd, ist aber die falsche Zusammenfassung, denn der Durchschnitt verdeckt einen sehr deutlichen Unterschied zwischen zwei Arten von Arbeit.
Analysieren kann es. Generieren nicht.
Beim Code-Review hat das lokale Modell jeden einzelnen Lauf bestanden — 3 von 3 auf dem Mac, 6 von 6 auf dem Windows-PC, dabei durchgehend alle vier platzierten Bugs gefunden, teilweise mit zutreffenden Zusatzfunden obendrein.
Bei der Code-Generierung dagegen besteht selten mehr als ein Drittel der Läufe: Compilefehler, erfundene APIs, eine Aggregation, die durch die Fan-Out-Falle läuft und Anna 300 statt 150 Euro zuschreibt.
Das ist die eigentliche Erkenntnis des ganzen Vergleichs: Analyse ist demokratisiert. Reviews, Erklärungen und Fehlersuche laufen lokal bedenkenlos — bei voller Datenhoheit und ohne API-Kosten. Für das Erzeugen von Code, der auf Anhieb kompiliert und das Richtige tut, ist die Cloud weiterhin eine andere Liga.
Interessant ist auch, was nicht hilft: Das höhere Quant Q8_0 mit 84 GB bringt keinen Qualitätsgewinn gegenüber Q6_K. Die Halluzinationen sind in beiden Varianten dieselben — es handelt sich um Modellwissen, nicht um ein Artefakt der Quantisierung.
Ein zweites lokales Modell: gpt-oss-120b
Nach der ersten Messreihe lag der Verdacht nahe, dass 80 Milliarden Parameter für ordentliche Codegenerierung schlicht zu wenig sind. Ein zweiter Kandidat widerlegt das: gpt-oss-120b besteht 10 von 21 Läufen statt 5 und landet damit bei Ø 5,5 — erstmals Haiku-Niveau aus dem eigenen Gerät, bei voller Datenhoheit und ohne API-Kosten.
Der Sprung ist genau dort am größten, wo das erste Modell am klarsten gescheitert war: Beim Async-Cache steigt die Bewertung von 4 auf 9, bei der T-SQL-Aggregation von 2 auf 9 — die Fan-Out-Falle erkennt gpt-oss in allen drei Läufen, statt Anna wie zuvor 300 statt 150 Euro zuzuschreiben.
Der Hebel ist dabei nicht die Modellgröße, sondern die Zahl der je Token aktiven Parameter: Qwen aktiviert rund 2,5 von 80 Milliarden, gpt-oss rund 5 von 117 Milliarden. Das ist doppelte Rechenleistung pro Token — und das bei kleinerem Speicherbedarf (63,4 statt 65,6 GB).
Was auch das zweite Modell nicht löst: Blazor-Dialog, EF-Core-Abfrage und Regex-Parser bleiben bei 0 von 3. Das sind genau die Aufgaben, an denen auch Cloud-Modelle straucheln — die EF-Falle riss Sonnet 4.6, Sonnet 5 und Fable 5 im Erstentwurf.
Warum MoE — und was dichte Modelle kosten
Beide bisher genannten lokalen Modelle sind Mixture-of-Experts: Sie tragen sehr viele Parameter, rechnen je Token aber nur einen kleinen Teil davon durch. Zum Gegentest kam ein dichtes Modell dazu, Qwen 3.6 27B, das bei jedem Token sämtliche Parameter aktiviert:
| Modell | Architektur | aktiv je Token | Speicher | tok/s | bestanden |
|---|---|---|---|---|---|
| Qwen3-Coder-Next 80B | MoE | ~2,5 Mrd. | 65,6 GB | 76,8 | 5 von 21 |
| gpt-oss-120b | MoE | ~5 Mrd. | 63,4 GB | 37,4 | 10 von 21 |
| Qwen 3.6 27B | dense | 27 Mrd. | 28,6 GB | 17,4 | abgebrochen |
Weniger Speicher heißt nicht schneller. Das dichte Modell belegt weniger als die Hälfte und ist trotzdem viermal langsamer als das große MoE — eben weil es je Token alle 27 Milliarden Parameter durchrechnet statt nur 2,5 Milliarden.
Abgebrochen wurde es allerdings aus einem anderen Grund: Alle Läufe endeten mit finish_reason=length.
Das Modell verbrauchte das gesamte Token-Budget für internes Nachdenken — 5.200 bis 11.000 Zeichen je
Lauf — und kam gar nicht mehr zum Code. Ein größeres Budget wäre vom Messprotokoll aller anderen
Modelle abgewichen und hätte den Vergleich wertlos gemacht.
Für den lokalen Einsatz auf Apple Silicon heißt das: MoE-Architekturen sind die richtige Wahl. Dichte Modelle jenseits von etwa 20 Milliarden Parametern lassen sich zwar laden, sind für agentische Codegenerierung aber praktisch unbrauchbar.
Die Plattform entscheidet über das Tempo, nicht über die Qualität
Gemessen wurde auf zwei Rechnern: einem MacBook Pro M5 Max mit 128 GB Unified Memory und einem Windows-PC mit RTX 5070 Ti. Beide liefen mit bit-identischen Gewichten, per SHA256 verifiziert. Das Ergebnis ist eindeutig: Die Plattform beeinflusst nur das Tempo, nicht die Qualität.
Beim Tempo allerdings deutlich. Nach getrennter Optimierung beider Seiten erreicht das MacBook 76,8 tok/s, der Windows-PC 21,2 tok/s — ein Tempo-Faktor von 3,6×. Der Hebel ist nicht die GPU, sondern die Speicherbandbreite: 546 GB/s Unified Memory gegen rund 40 GB/s DDR4. Bei einem MoE-Modell, das je Token nur einen Bruchteil seiner Parameter aktiviert, ist genau das der Flaschenhals. Der Unterschied ist im Alltag sofort spürbar: Auf dem Mac liest man die Antwort flüssig mit, auf dem PC wartet man.
Fazit
Lokal für Reviews und sensible Daten — mit einem MoE-Modell wie gpt-oss-120b inzwischen auch für Nebenläufigkeit und SQL-Aggregation. Für Framework-Randbereiche wie Blazor, EF Core und den Regex-Generator bleibt die Cloud nötig. Und unabhängig von der Herkunft: Generierten Code immer durch Compile und Test schicken. Genau das hat in diesem Vergleich die interessanten Fehler überhaupt erst sichtbar gemacht.
Eine Frage bleibt damit offen — und wo lässt man das Ganze laufen? Alle Messungen hier liefen auf einem Notebook und einem Desktop-PC. Was professionelle Rechenzentrums-Hardware daran ändert, steht im Nachtrag: Wo lasse ich lokale Modelle laufen?
Alle 21 Folien der Auswertung stehen unten in der Galerie, die vollständige Präsentation gibt es als PDF zum Herunterladen.