Anubhav formuliert es in seinem Artikel klar: Das beste lokale Coding-Modell ist nicht das mit dem höchsten Benchmark-Wert, sondern das, das deine Maschine tatsächlich ausführen kann, ohne einzufrieren. Er plädiert dafür, ein lokales Coding-Modell nach Hardware, Latenz und Datenschutz auszuwählen statt nach Leaderboard-Screenshots: «You cannot pick a model based on a leaderboard. You have to pick a model based on your silicon.» Dieser Methodik stimme ich fast vollständig zu. Aber ich habe eine vorgelagerte Frage, und die ist meiner Meinung nach wichtiger.
Die Frage lautet nicht «welches lokale Modell gewinnt». Sie lautet: wo ein lokales Modell überhaupt hingehört. Ich betreibe LM Studio und einen lokalen MCP, ich nutze diese Modelle täglich — und halte sie trotzdem für produktionsuntauglich. In «The Harness Is the Cheap Part» habe ich argumentiert, dass eine lokale LLM nicht dort stehen darf, wo Produktionspräzision verlangt wird. Echte Arbeit übergebe ich der Cloud. Dieser Artikel ist ein guter Anlass, diesen Gedanken auf eine einzige Linie zuzuspitzen.
Wo die Grenze verläuft
Die Grenze ist nicht «lokal gegen Cloud» als Weltanschauung. Sie verläuft entlang der Natur der Aufgabe. Es gibt agentische Schleifen, in denen die Token-Kosten dominieren: ein Skript liest einen fehlgeschlagenen Test, schlägt einen Fix vor, kompiliert, wiederholt — fünfzigmal am Tag. Anubhav beschreibt genau dieses Szenario und zieht den richtigen Schluss: «You buy the hardware once and run infinite tokens.» Solche Iterationen sind billig, hochvolumig und fehlertolerant — ein einzelner missglückter Versuch kostet nichts, weil die Schleife es ohnehin erneut versucht. Genau hier passt ein lokales Modell perfekt.
Und dann gibt es die Ausgabe, von der das Ergebnis abhängt: der finale Patch, die Architekturentscheidung, der Code, der ins Review und in die Produktion geht. Hier sind die Kosten eines Fehlers nicht «ein zusätzliches Token», sondern ein kaputtes Release. Diese Ausgabe geht in die Cloud — bei mir zu Claude. Billige, hochvolumige Schleifen laufen lokal; präzisionskritische Ausgabe geht in die Cloud. Das ist die Grenze, und sie ist wichtiger als jedes Modell-Ranking.
Was an der Methodik bleiben sollte
Das Wertvollste an dem Beitrag ist nicht die Modellliste, sondern die ingenieurmäßige Methode: «wähle nach deinem Silizium, nicht nach dem Leaderboard.» Die würde ich vollständig behalten, weil sie mit dem nächsten Release nicht verrottet.
- Q4_K_M als praktische Qualitätsuntergrenze. Anubhav warnt unmissverständlich: «==The tradeoff is a slight loss in reasoning capability.==» Unter Q4 wird ein Modell beim Coden «forget basic syntax and hallucinate variables.» Das deckt sich mit meiner Erfahrung.
- Ein kleineres Modell in Q8 schlägt ein größeres in Q2. «I always recommend running a smaller parameter model at Q8 rather than a bigger model at Q2.» Der Parameterzahl hinterherzujagen und sie dann mit aggressiver Quantisierung zu erschlagen, ist Selbstbetrug.
- Der KV-Cache konkurriert mit den Gewichten um den Unified Memory. Kontext belegt physisches RAM neben den Modellgewichten; das, nicht allein die Gewichtsgröße, stößt meist an die Decke.
- Swap-to-Disk killt den Durchsatz. Geht der Unified Memory aus, fällt deine «generation speed will immediately drop from 30 tokens a second to 1 token a second.» Das ist keine Verschlechterung, das ist das Ende.
- Ziele auf ~15 Tok/s für Chat und ~40 Tok/s für Autocomplete. «Latency will kill your focus faster than a slightly wrong answer will» — eine Formulierung, die ich unterschreibe. Unter der Schwelle: kleineres Modell nehmen oder stärker quantisieren.
Und die Hardware-Tiers — drei praktische Klassen (~16 GB Unified, 32–64 GB oder 24 GB VRAM, 128 GB und Multi-GPU) — sind ein ehrlicher Rahmen für das Gespräch «was kann ich überhaupt ausführen», ohne Illusionen.
Wo ich abbremsen würde
Vorsicht verdient die 2026er-Konkretik. Der Artikel nennt recht bestimmte Modelle und Zahlen: ein Headline-Modell mit 80B MoE und «==it scores 58.7% on SWE-bench Verified==», eine Familie von 27B-Modellen, ein April-Release von Google unter Apache 2.0, eine Coding-Familie von Mistral, zusammengefasst in ein einzelnes 128B-Modell, ein separates Reasoning-Modell und ein schmaler Autocomplete-Spezialist. Ich kann weder diese Namen noch diese Zahlen bestätigen. Das Open-Weight-Ökosystem, wie der Autor selbst schreibt, «moves incredibly fast» — einige dieser Modelle könnten umbenannt worden sein, und mehrere SWE-bench-Zahlen habe ich keine Möglichkeit zu prüfen. Deshalb behandle ich die Namen und Werte als Illustration, nicht als Fakt: sie zeigen, wie man denkt (nach Tier und Quantisierung), aber die konkrete Tabelle wird bis zum nächsten Release veraltet sein. Stütze dich auf die Prinzipien, nicht auf die Tabelle.
Fazit
Als Hardware-Tier-Framework ist der Artikel nützlich: er verbindet ehrlich «was in deiner Maschine steckt» mit «was du ausführen kannst» und setzt die richtigen Latenzschwellen. Als Modell-Leaderboard sollte man ihm nicht trauen: die Namen und SWE-bench-Zahlen sind schnelllebig und teils nicht überprüfbar. Der eine bleibende Wert hier ist dieser: wähle nach deinem Silizium und deiner Nische, nicht nach einem SWE-bench-Screenshot. Und die Nische lokaler Modelle sind billige, hochvolumige agentische Schleifen, in denen ein Fehler billig ist. Präzision wohnt weiterhin in der Cloud.