Einsatzbericht: Qwen 3.6 27B auf einem M2 MacBook Pro (32 GB) – quälend langsam, aber intelligente Ausgabe

Ein Entwickler auf r/LocalLLaMA hat Qwen 3.6 27B (IQ4_XS unsloth Quantisierung) auf einem M2 MacBook Pro mit 32 GB RAM getestet. Erwartungsgemäß ist die Maschine für ein dichtes 27B Modell unterdimensioniert, aber der Erfahrungsbericht liefert konkrete Zahlen und eine realistische Einschätzung von Leistung und Ausgabequalität.
Befehl und Einrichtung
Das Modell wurde mit llama-server unter Verwendung des folgenden Befehls ausgeführt:
llama-server -m ~/models/unsloth/Qwen3.6-27B-IQ4_XS.gguf --mmproj ~/models/unsloth/Qwen3.6-27B-mmproj-BF16.gguf -c 131072 --batch-size 256 -ngl 99 -np 1 --host 127.0.0.1 --port 8899 -ctk q8_0 -ctv q8_0 --spec-type ngram-mod --spec-ngram-size-n 24 --draft-min 12 --draft-max 48
Bemerkenswerte Entscheidungen: Ein einzelner Prozess (-np 1), um die GPU nicht zu überlasten, spekulative Dekodierung mit ngram-mod und ein Kontextfenster von 131072 Token.
Leistungsaufschlüsselung
Anfangsgeschwindigkeiten: 80 t/s Promptverarbeitung, 7,9 t/s Token-Generierung. Bei 52.000 Token Kontext brach die Leistung auf 4 t/s Promptverarbeitung ein – was der Autor bestätigt, ist kein Tippfehler – und 3,1 t/s Token-Generierung. Der Arbeitsspeicherdruck erreichte nie die rote Zone, was darauf hindeutet, dass der Engpass die Speicherbandbreite ist, nicht der Swap.
Spekulative Dekodierung nicht effektiv
Der Tester aktivierte die ngram-mod spekulative Dekodierung, sah aber keinen wirklichen Nutzen. Die Logs zeigten:
accept: low acceptance streak (3) – resetting ngram_mod ... draft acceptance rate = 1.00000 ( 2 accepted / 2 generated)
Das Modell setzt aufgrund geringer N-Gramm-Übereinstimmungen ständig zurück; die scheinbare 100%ige Akzeptanzrate ist ein Artefakt winziger Stichprobengrößen. Der Autor folgert, dass dichte Modelle wie dieses sich nicht genug wiederholen, damit der ngram-mod-Ansatz gut funktioniert.
Codequalität
Trotz der Langsamkeit wurde der von Qwen 3.6 27B generierte Code als ausgezeichnet bewertet. Es analysierte eine bedeutende Codebasis ohne zusätzliche Aufforderung über die anfängliche Aufgabe hinaus und übertraf das Qwen 35B A3B (MoE) Modell in der Qualität. Der Autor vergleicht die Ausgabe mit dem, was man von einem selbst gehosteten Claude Sonnet erwarten würde, und stellt fest, dass selbst Claude Opus 4.7 beeindruckt war.
Wichtige Erkenntnisse
- Speicherbandbreite dominiert dichte Modelle: Auf Apple Silicon halbierte sich die Token-Generierung mit wachsendem Kontext. Selbst ohne Swap bremste die Bandbreitendrosselung die Leistung.
- Ein einzelner Prozess ist der richtige Weg: Gleichzeitige Agentenaufgaben auf dieser Hardware bieten keinen Vorteil – nur serielle Warteschlangen.
- Spekulative Dekodierung ist modellabhängig: Ngram-mod half hier nicht; die geringe Wiederholungsneigung des Modells verhinderte Entwurfsübereinstimmungen.
Der Autor plant, Qwen 3.6 27B auf einer Cloud-GPU mit Spezifikationen zu testen, die mit der R9700 vergleichbar sind (aktuell ~1.400 $ auf Amazon, höher auf eBay), um ein wahres Gefühl für ihre Fähigkeiten bei eigenen Programmieraufgaben zu bekommen.
📖 Read the full source: r/LocalLLaMA
👀 Siehe auch

Durchsetzung harter Leitplanken für OpenClaw-KI-Agenten: Genehmigungs-Gating und Nebenläufigkeitsgrenzen
Ein r/openclaw-Benutzer fragt, wie man harte Regeln wie E-Mail-Genehmigung und Nebenläufigkeitslimits für einen Discord-verbundenen OpenClaw-Bot mit Ollama und GLM durchsetzt. Die Antwort: Die Durchsetzung aus der Denkschleife des Modells herausnehmen.

Claude-Prompt-Codes neu getestet: L99 schärfer, OODA enger, ARTIFACTS verblasst und 3 neue Codes zur Nutzung
Ein 6-Monate-Retest der Prompt-Codes L99, OODA und ARTIFACTS auf Claude zeigt, dass L99 auf Sonnet 4.6/Opus 4.7 schärfer ist, OODA bei strategischen Prompts versagt, ARTIFACTS für Code unnötig ist und drei neue Codes (/skeptic, /blindspots, /decompose) täglich verwendet werden können. Stapeln Sie nicht mehr als 2 Codes.

Reduzierung der MCP-Token-Nutzung durch Ersetzen von Servern durch CLI-Alternativen
Ein Entwickler stellte fest, dass MCP-Server 30-40 % ihres Kontextfensters mit Werkzeugdefinitionen belegten, also ersetzte er vier MCP-Server durch CLI-Tools, wo verfügbar, und reduzierte so von 6 auf 2 MCP-Server, während die Funktionalität erhalten blieb.

Token-Verschwendung in Claude Code: Eine Selbstkontrolle zeigt, dass Verhaltensänderungen besser sind als Modellwechsel
Ein Nutzer maß die Token-Nutzung in Claude Code und stellte fest, dass /clear zwischen Aufgaben, Planung vor dem Bearbeiten und das Verhindern von erneutem Lesen bearbeiteter Dateien mehr Tokens einsparte als der Modellwechsel. Praktische Disziplin schlägt Wrapper.