Benchmark von lokalem qwen3-coder bei einem Astro-6-Build auf M4 Max — 4 Modell-Fehler, keine Mac-Fehler

Seit Wochen teste ich lokale Modelle mit Ollama. Ich habe wm-project-llm-routing gebaut, um mechanische Tasks (File Search, Lint, Find-Replace, Doc-Gen) an ein lokales Modell zu routen und die Anthropic-API für Design und Reasoning zu behalten. Um zu validieren, was das lokale Modell verkraftet, habe ich mein eigenes Smoke-Test-Harness geschrieben — 8 Tasks, falsifizierbare Kriterien.

Diese Woche habe ich es ausgereizt. Prompt mit ~2000 Wörtern, damit qwen3-coder:30b-a3b-q4_K_M eine vollständige Astro-6-Site baut, mit 11 Acceptance-Checks am Ende.

Ergebnis: Das Modell schrieb Svelte innerhalb von .astro-Dateien, ignorierte ein explizites STOP und blockierte 30 Minuten in einem einzigen Turn. Vollständiges Postmortem unten — harte Daten, exakte Dateien, 4 Ursachen verifiziert gegen GitHub-Issues + Vendor-Paper.

Die echte Frage, die das Experiment beantwortet hat: Kann ich lokalen LLMs vertrauen, um die Anthropic-API im täglichen Workflow zu ersetzen? Kurze Antwort: noch nicht. Lange: hängt vom Task-Typ ab.

Das Setup: Es lag nicht an der Hardware

Specs zuerst. Falls deine erste Reaktion auf “das lokale Modell ist gescheitert” lautet: “Dein Mac war wohl zu schwach” — nein:

MacBook Pro Mac16,5 mit M4 Max. Spitze von Apples Consumer-Grade-Lineup. 64 GB Unified Memory → die GPU adressiert riesige Gewichtungen ohne PCIe-Penalty. qwen3-coder:30b belegt 45 GB im VRAM während der Inferenz. 19 GB bleiben für den Rest des Systems. Knapp, aber es funktioniert.

ollama ps zeigte PROCESSOR: 100% GPU während der ganzen Session. Kein Swap. Kein Thermal-Throttling. Nichts auf der Hardware-Seite konnte entschuldigen, was danach kam.

Der Bottleneck war das Modell. Nicht der Mac.

Warum lokal testen

Drei Gründe:

1. Datenschutz. Ich arbeite mit Kunden-Code. “Wir trainieren nicht auf deinen Prompts”-Policies sind glaubwürdig, aber nicht kryptographisch. Lokal ist es: Wenn nichts den Mac verlässt, ist nichts gegangen.
2. Kosten. Für mechanische Tasks (File Search, Lint, Find-Replace, Doc-Gen) Opus-Rates zu zahlen ist verschwenderisch. wm-project-llm-routing routet diese an lokales Ollama; die API bleibt für Design, Recht, komplexes Reasoning.
3. Neugier. Ich will wissen, wie ernst ich Open-Source-Modelle 2026 nehmen kann.

Relevanter Hinweis zu Punkt 1: Ollama ist nicht mehr 100 % lokal by default. Neuer Cloud-Track seit Frühjahr 2026 — Modelle mit Suffix :cloud laufen auf Ollama-Infrastruktur, nicht auf deinem Mac. Detail unten in der eigenen Sektion.

Der Smoke-Test, der bestand (88 %) — der irreführende Spoiler

Vor dem Benchmark habe ich das Modell mit wm-llm-smoke-test validiert — eigene Suite, 5 Kategorien × ~2 Tasks, isolierte Prompts ohne Tool-Use, bewertet gegen erwartete Keywords.

Ergebnis: 7/8 (88 %). Der einzige Fail: Path-Halluzination — das Modell antwortete src/task_classifier.py, wo die richtige Antwort lib/classification.py gewesen wäre. Ehrlicher und bekannter Fail: LLMs halluzinieren Pfade ohne Tool-Use. Für Refactors, Doc-Gen und Formatting: gut.

Der Benchmark: rockshop.com.mx von Null bauen

rockshop.com.mx ist eine Domain von mir mit historischem SEO-Equity für kommerzielle Queries in Mexico-Stadt. Heute ein Placeholder. Ich gab dem Modell einen detaillierten Prompt (~2000 Wörter) mit:

• Gepinntem Stack: Astro 6.x, Tailwind 4.x via @tailwindcss/vite, TypeScript strict, Node 22 LTS
• Verpflichtender Atomic-Design-Struktur (atoms/, molecules/, organisms/)
• Design-Tokens in CSS-Custom-Properties, hartkodierte Farben verboten
• 3 Seiten: Startseite, Placeholder-Katalog, Kontakt
• Harte Regeln: keine Open-Source-Lizenzen, keine Stockfotos, keine erfundenen Business-Claims, Copy in mexikanischem Spanisch ohne Voseo
• Acceptance-Test am Ende mit 11 falsifizierbaren Checks (grep dies, verifiziere das, Build muss passen)

Prompt-Regeln: keine stille Vereinfachung, keine Scope-Degradation, keine Simulation. Das Modell muss die Site komplett bauen und am Ende den Acceptance-Test selbst ausführen, mit ehrlichem PASS/FAIL pro Check.

Ich startete das Experiment + paralleles Monitoring:

• ollama ps alle paar Minuten → GPU-Nutzung bestätigen
• find über den Output-Ordner → erstellte Dateien zählen
• Prozess-Inspektion → erkennen, ob Claude Code auf Tool-Call-Approval wartete oder arbeitete

Nicht “mal sehen, was passiert”. Verhalten messen.

Was es in 22 Dateien baute: gut angefangen

Fünfzehn Minuten später stand der Datei-Count bei 22 mit sauberer Struktur:

An diesem Punkt sah das Experiment vielversprechend aus. Den mechanischen Teil — den Teil, in dem ein Coding-spezialisiertes Modell glänzen sollte — hat es geschafft.

Dann brach es.

Der exakte Moment des Versagens

Ich erkannte den Degrade beim Mitlesen des Live-Outputs. Ich fragte, was es gerade tat. Die wortwörtliche Antwort:

Ich habe Probleme mit der Syntax der Astro-Komponenten. Vereinfachen
wir den gesamten Ansatz und erstellen ein einfaches Projekt ohne
komplexe Komponenten. Zuerst lösche ich alle atomaren und
molekularen Komponenten und erstelle eine minimale Struktur.

Dieser Satz bricht drei explizite Regeln des Prompts: “nicht vereinfachen ohne Warnung”, “Atomic Design ist Pflicht”, “Scope nicht eigenmächtig degradieren”. Das Modell entschied von sich aus, dass die Lösung für einen Syntax-Fehler darin bestand, die gesamte Architektur zu löschen.

Ich ging Datei für Datei durch. Öffnete atoms/Heading.astro, atoms/Button.astro und atoms/Text.astro im Editor und das Problem wurde offensichtlich:

---
props: {
  level: 1,
  text: String,
  className: String,
}
---

{#if props.level === 1}
  <h1 class={props.className}>{props.text}</h1>
{:else if props.level === 2}
  <h2 class={props.className}>{props.text}</h2>
{:else if props.level === 3}
  <h3 class={props.className}>{props.text}</h3>
{/if}

---
interface Props {
  level?: 1 | 2 | 3 | 4 | 5 | 6;
  text: string;
  class?: string;
}

const { level = 1, text, class: className } = Astro.props;
const Tag = `h${level}`;
---

<Tag class={className}>{text}</Tag>

Was es geschrieben hat, ist kein Astro. Es ist Svelte: Der Block {#if condition}...{:else if}...{/if} ist reine Svelte-Syntax, und die props: {...}-Deklaration im Frontmatter ist etwas zwischen Vue 3 Options API und Svelte, aber sicher nicht Astro. Astro verwendet interface Props {} in TypeScript und rendert mit JSX-like Syntax, ohne {#if}-Blöcke.

Das Modell hat ein Framework mit einem anderen verwechselt. Es kannte die Astro-Syntax nicht, also füllte es mit dem auf, was es kannte. Jede Datei war lexikalisch ungültig für den Astro-Parser — kein npm run build würde mit diesem Code durchgehen.

Ich schickte ihm eine explizite Nachricht: “STOP. Lösch atoms/ nicht, schreib nichts um, gib mir zuerst den Error wortwörtlich”. Das Modell stimmte höflich zu und schrieb drei weitere Dateien mit der gleichen kaputten Syntax um, bevor es mir den Error zeigte. Es hat das STOP ignoriert. Und weitergemacht.

Nach ~30 Minuten “Deciphering… 29m 36s” auf einem einzigen Turn war das Modell weiter blockiert. Ich killte es mit Ctrl+C und schloss die Evaluation ab.

Die Diagnose: vier Ursachen

Das war kein Single-Factor-Fail. Für jede Hypothese startete ich parallele Suchen gegen GitHub-Issues, das offizielle Paper des Modell-Vendors und Community-Reports. Was ich fand:

Für drei der vier Ursachen gibt es dokumentierte Fixes: Ollama upgraden, num_ctx überschreiben, zu einem anderen Modell wie GLM-4.7-Flash wechseln, das Zhipu AI speziell für agentic Patterns tuned. Die erste Ursache — Astro-Cross-Framework-Halluzination — löst sich nur, wenn jemand ein Modell mit neueren Daten trainiert. Oder wenn du eine API nutzt, die sie schon hat (Claude, GPT, Gemini).

Ich bin nicht allein damit: dokumentierte analoge Fälle

Nach dem Fail habe ich externe Quellen gesucht, um zu verifizieren, ob das, was ich erlebt habe, anekdotisch oder systematisch war. Es ist systematisch. Fünf relevante Funde:

Falls du fürchtest, es sei nur “dein Modell auf deinem Mac” — nein. Es ist systematisches Verhalten des aktuellen Zustands offener Modelle in langen agentic Harnesses. Der sauberste Fix bleibt: Verwende sie noch nicht dafür.

Kontext-Hinweis: Ollama ist seit Frühjahr 2026 nicht mehr standardmäßig 100 % lokal

Ich nutze dieses Postmortem, um etwas Wichtiges über den aktuellen Stand des Ökosystems festzuhalten, denn falls du über die Suche nach “lokales LLM” hierhergekommen bist, hast du es vielleicht nicht mitbekommen: seit Frühjahr 2026 fährt Ollama zwei getrennte Tracks, und der neue Befehl ollama launch claude mischt sie im selben Picker:

Das Feature ollama launch claude wurde im Frühjahr 2026 ausgerollt. Es verdrahtet Claude Code mit Ollama ohne Env-Var-Fummelei. Aber Achtung: Im Claude-Code-UI-Header erscheint “API Usage Billing” für jeden Ollama-Backend, inklusive dem lokalen. Dieses irreführende Label hat mich eine Weile zweifeln lassen, ob mein Modell wirklich auf meinem Mac läuft. Bestätigt habe ich es mit ollama ps (PROCESSOR: 100% GPU während der ganzen Session). Das Label ist generisch; es bedeutet nicht, dass du Anthropic bezahlst.

Wenn deine Priorität verifizierbarer Datenschutz ist, wähle nur Modelle ohne :cloud-Suffix. Wenn deine Priorität Geschwindigkeit ist und du die “No-Logging”-Policy von Ollama akzeptierst, hat der Cloud-Track SOTA-Modelle (kimi-k2.6, glm-5.1) zu vertretbaren Preisen. Es sind keine äquivalenten Optionen — es sind unterschiedliche Trade-offs.

Verdikt: wann lokales qwen3-coder SICH lohnt

Zusammenfassung als Tabelle:

Funktioniert als isolierter Pair-Programmer. Gib ihm eine Funktion, bekomm sie refaktorisiert zurück. Gib ihm einen Absatz, bekomm ihn dokumentiert. Dafür ist 88 % Pass-Rate echt und ausreichend.

Funktioniert NICHT als autonomer Many-Turn-Agent. Zumindest nicht in meinem Setup Mai 2026. Wenn dein echter Workflow ganze Projekte unbeaufsichtigt bauen oder refaktorisieren muss, brauchst du weiterhin die API. Oder du zerlegst den Scope aggressiv — eine Datei nach der anderen, mit menschlicher Verifikation dazwischen.

Fazit: Der M4 Max ist nicht der Bottleneck

64 GB Unified Memory, 40 GPU-Kerne, jede Menge Spielraum für riesige Modelle — und das Experiment ist trotzdem gescheitert. Nicht wegen der Hardware. Wegen Modell-Capability und Harness-Reife.

Für die Hardware, die ich habe, ist lokales qwen3-coder ein valides Tool für Mikro-Tasks. Es ersetzt Claude Opus bei echten Builds nicht. Und das ist okay — es sind unterschiedliche Tools für unterschiedliche Probleme.

Wenn du in einen Mac mit genug RAM für lokale LLMs investierst, tu es im Wissen: das Ceiling wird vom Open-Modell-Ökosystem + Tooling gesetzt. NICHT von der Hardware. Der M4 Max gibt dir Spielraum für die nächsten 2–3 Jahre. Was fehlt, ist dass Open Models proprietäre Modelle in agentic Capability einholen. Heute sind sie nicht da. 2027 wahrscheinlich.

Während dieses Postmortem verifizierte Quellen:

• github.com/ollama/ollama/issues/15390 — Invalid tool parameters + CPU-Fallback mit Claude Code
• github.com/NousResearch/hermes-agent/issues/17031 — Qwen3.6 konfabuliert Session-History
• docs.ollama.com/integrations/claude-code — offizielle Integration
• ollama.com/library/qwen3-coder — Model-Card
• ollama.com/blog/launch — ollama launch-Rollout Frühjahr 2026
• ollama.com/cloud — Pricing + Policy des Cloud-Tracks
• github.com/continuedev/continue/issues/5419 — Agent-Mode funktioniert nicht mit Qwen3 (analoger Fall in einer anderen IDE)
• arxiv.org/abs/2603.00729 — Qwen3-Coder-Next Technical Report (offizielle Anerkennung von Produktions-Instabilität)
• eval.16x.engineer/blog/qwen3-coder-evaluation-results — formaler Benchmark: Qwen3 Coder 1/10 bei TypeScript-Narrowing
• blog.logrocket.com/qwen-3-coder-agentic-cli/ — LogRocket Svelte 5 + Firebase Test mit Qwen3-Coder