Qwen3.6-27B: Flaggschiff-Niveau bei der Coding-Performance aus einem 27-Mrd.-Dense-Modell

 (qwen.ai)
7 Punkte von GN⁺ 7 일 전 | 4 Kommentare | Auf WhatsApp teilen
  • Als 27-Milliarden-Parameter-Dense-Multimodalmodell veröffentlicht und unterstützt in einem einheitlichen Checkpoint sowohl Thinking- als auch Non-Thinking-Modi sowie Bild- und Videoverarbeitung
  • Die agentic coding performance übertrifft bei wichtigen Coding-Benchmarks durchgehend das Open-Source-Flaggschiff der Vorgängergeneration Qwen3.5-397B-A17B und schlägt sogar Modelle mit bis zu 15-fach höherer Gesamtparameterzahl
  • Erreichte SWE-bench Verified 77.2, SWE-bench Pro 53.5, Terminal-Bench 2.0 59.3, SkillsBench 48.2; außerdem wurden Werte für Text-Reasoning und STEM wie GPQA Diamond 87.8 und AIME26 94.1 veröffentlicht
  • Durch die Dense-Architektur entfällt die Komplexität des MoE-Routings, das Deployment wird einfacher, und es gibt Unterstützung für Open Weights, API, sofortige Nutzung über Qwen Studio sowie Integrationen mit OpenClaw, Qwen Code und Claude Code
  • Zeigt, dass ein gut trainiertes Dense-Modell die deutlich größere Vorgängergeneration bei zentralen Entwickleraufgaben übertreffen kann, und erweitert zugleich die agentic coding-Ausrichtung der Qwen3.6-Familie

Überblick

  • Qwen3.6-27B wurde als 27-Milliarden-Parameter-Dense-Multimodalmodell veröffentlicht und unterstützt sowohl multimodale Thinking- als auch Non-Thinking-Modi
  • Bei der agentic coding performance übertrifft es das Open-Source-Flaggschiff der Vorgängergeneration Qwen3.5-397B-A17B über die wichtigsten Coding-Benchmarks hinweg
  • Durch die Dense-Architektur ohne MoE-Routing-Komplexität ist das Deployment einfacher und liefert Top-Coding-Performance in einer praktischen, breit einsetzbaren Größenklasse
  • Es ist sofort in Qwen Studio nutzbar; zusätzlich werden Open Weights für die Community und API-Zugänge bereitgestellt
  • Zu den Kerneigenschaften zählen agentic coding auf Flaggschiff-Niveau, starkes Text-Reasoning und multimodale Reasoning-Fähigkeiten

Leistung

  • Für Qwen3.6-27B wurde eine Gesamtevaluierung gegenüber Dense- und MoE-Referenzmodellen vorgestellt; bei agentic coding benchmarks wurden deutliche Fortschritte erzielt
  • Es wird ausdrücklich angegeben, dass das Modell sogar bis zu 15-mal größere Modelle bei der Gesamtparameterzahl übertrifft
  • Die Evaluationskategorien umfassen Sprache, Wissen, STEM und Reasoning, Vision-Language, Dokumentenverständnis, Videoverständnis und Visual Agent

  • Sprache

    • Schon mit 27 Milliarden Parametern übertrifft es Qwen3.5-397B-A17B bei allen wichtigen Coding-Benchmarks
      • SWE-bench Verified 77.2 gegenüber 76.2
      • SWE-bench Pro 53.5 gegenüber 50.9
      • Terminal-Bench 2.0 59.3 gegenüber 52.5
      • SkillsBench 48.2 gegenüber 30.0
    • Auch andere Dense-Modelle derselben Größenklasse werden mit deutlichem Abstand übertroffen
    • Bei Reasoning-Aufgaben erreicht es 87.8 Punkte in GPQA Diamond, ein Wert auf Augenhöhe mit Modellen, die um ein Mehrfaches größer sind
    • Die Detailtabelle enthält Vergleiche mit Qwen3.5-27B, Qwen3.5-397B-A17B, Gemma4-31B, Claude 4.5 Opus, Qwen3.6-35B-A3B und Qwen3.6-27B
    • Wichtige Kennzahlen im Bereich Coding Agent
      • SWE-bench Multilingual 71.3
      • QwenWebBench 1487
      • NL2Repo 36.2
      • Claw-Eval Avg 72.4
      • Claw-Eval Pass^3 60.6
      • QwenClawBench 53.4
    • Wichtige Kennzahlen im Bereich Knowledge
      • MMLU-Pro 86.2
      • MMLU-Redux 93.5
      • SuperGPQA 66.0
      • C-Eval 91.4
    • Wichtige Kennzahlen im Bereich STEM und Reasoning
      • HLE 24.0
      • LiveCodeBench v6 83.9
      • HMMT Feb 25 93.8
      • HMMT Nov 25 90.7
      • HMMT Feb 26 84.3
      • IMOAnswerBench 80.8
      • AIME26 94.1

  • Einstellungen der Sprachevaluation

    • Die SWE-Bench Series verwendet ein internes Agent-Scaffold sowie Bash- und File-Edit-Tools, mit temp 1.0, top_p 0.95 und einem Kontextfenster von 200K
      • Alle Referenzmodelle wurden auf einem verfeinerten Benchmark evaluiert, in dem einige problematische Tasks des öffentlichen SWE-bench-Pro-Sets korrigiert wurden
    • Terminal-Bench 2.0 nutzt den Harbor- oder Terminus-2-Harness
      • 3 Stunden Timeout, 32 CPU, 48 GB RAM
      • temp 1.0, top_p 0.95, top_k 20, max_tokens 80K, 256K ctx
      • Durchschnitt aus 5 Läufen
    • SkillsBench evaluiert 78 Tasks mit OpenCode
      • Verwendet wird ein in sich geschlossenes Subset ohne API-abhängige Tasks
      • Durchschnitt aus 5 Läufen
    • Für die Bewertung anderer Modelle auf NL2Repo wurde Claude Code verwendet
      • temp 1.0, top_p 0.95, max_turns 900
    • QwenClawBench ist ein Claw-Agent-Benchmark auf Basis realer Nutzerverteilungen
      • temp 0.6, 256K ctx
    • QwenWebBench ist ein interner Benchmark zur Frontend-Codegenerierung
      • Zweisprachig in EN und CN aufgebaut
      • 7 Kategorien: Web Design, Web Apps, Games, SVG, Data Visualization, Animation, 3D
      • Bewertet werden Code und visuelle Übereinstimmung per Auto-Render und multimodalem Judge
      • Verwendet wird das BT- oder Elo-Rating-System
    • AIME 26 nutzt vollständig AIME 2026 I und II
      • Es wird darauf hingewiesen, dass die Werte von den Qwen-3.5-Notizen abweichen können

  • Vision-Language

    • Qwen3.6-27B unterstützt in einem einzigen integrierten Checkpoint sowohl Vision-Language-Thinking- als auch Non-Thinking-Modi
    • Kann neben Text auch Bilder und Videos verarbeiten
    • Unterstützt multimodales Reasoning, Dokumentenverständnis und visuelle Frage-Antwort-Aufgaben
    • Die Vergleichstabelle wird anhand von Qwen3.5-27B, Qwen3.5-397B-A17B, Gemma4-31B, Claude 4.5 Opus, Qwen3.6-35B-A3B und Qwen3.6-27B gezeigt

    • STEM und Rätsel

      • MMMU 82.9
      • MMMU-Pro 75.8
      • MathVista mini 87.4
      • DynaMath 85.6
      • VlmsAreBlind 97.0

    • Allgemeines VQA

      • RealWorldQA 84.1
      • MMStar 81.4
      • MMBench EN-DEV-v1.1 92.3
      • SimpleVQA 56.1

    • Dokumentenverständnis

      • CharXiv RQ 78.4
      • CC-OCR 81.2
      • OCRBench 89.4

    • Räumliche Intelligenz

      • ERQA 62.5
      • CountBench 97.8
      • RefCOCO avg 92.5
      • EmbSpatialBench 84.6
      • RefSpatialBench 70.0

    • Videoverständnis

      • VideoMME(w sub.) 87.7
      • VideoMMMU 84.4
      • MLVU 86.6
      • MVBench 75.5

    • Visual Agent

      • V* 94.7
      • AndroidWorld 70.3

    • Hinweis

      • Leere Felder (--) in der Tabelle bedeuten, dass noch keine Werte vorliegen oder die Angabe nicht zutrifft

Einsatz von Qwen3.6-27B

  • Unterstützung in Alibaba Cloud Model Studio soll laut Angabe in Kürze verfügbar sein
  • Open Weights werden auf Hugging Face und ModelScope bereitgestellt; Self-Hosting ist möglich
  • Es gibt einen Nutzungsweg über die Alibaba Cloud Model Studio API sowie eine direkte Testmöglichkeit in Qwen Studio
  • Unterstützt Integrationen mit Coding-Helfern von Drittanbietern wie OpenClaw, Claude Code und Qwen Code
  • Erwähnt werden die Vereinfachung von Entwickler-Workflows und die Unterstützung einer context-aware coding experience

  • API-Nutzung

    • Dieses Release unterstützt die Funktion preserve_thinking
    • Sie bewahrt die in allen vorherigen Turns einer Nachricht erzeugten Thinking-Inhalte und wird für agentic tasks empfohlen

  • Alibaba Cloud Model Studio

    • Unterstützt OpenAI-kompatible Chat-Completions- und Responses-APIs
    • Zusätzlich wird eine Anthropic-kompatible API-Schnittstelle unterstützt
    • Laut offizieller Dokumentation werden folgende Beispiel-Umgebungsvariablen angegeben
      • DASHSCOPE_API_KEY
      • DASHSCOPE_BASE_URL
      • DASHSCOPE_MODEL
    • Dazu werden auch Beispielregionen für die Base URL genannt
    • Im Beispielcode wird standardmäßig der Modellname qwen3.6-27b verwendet
    • In extra_body ist enable_thinking: True enthalten
      • preserve_thinking: True ist als Kommentar dargestellt
    • Enthalten ist außerdem ein Beispiel für Streaming-Antworten, bei dem reasoning_content und answer content getrennt gesammelt werden
    • Für weitere Informationen wird auf den Link zur API doc verwiesen

  • Coding & Agents

    • Qwen3.6-27B verfügt über agentic-coding-Fähigkeiten und lässt sich nahtlos mit OpenClaw, Claude Code und Qwen Code integrieren

    • OpenClaw

      • OpenClaw ist ein selbst gehosteter Open-Source-AI-Coding-Agent; frühere Namen waren Moltbot oder Clawdbot
      • In Verbindung mit Model Studio bietet es im Terminal ein vollständiges agentic-coding-Erlebnis
      • Das Startskript umfasst Node.js 22+, das Ausführen des Installationsskripts, das Setzen von DASHSCOPE_API_KEY und das Starten von openclaw dashboard oder openclaw tui
      • Bei der ersten Nutzung muss ~/.openclaw/openclaw.json bearbeitet werden
        • Es wird ausdrücklich darauf hingewiesen, nicht die gesamte Datei zu überschreiben
        • Stattdessen sollen nur die erforderlichen Felder zusammengeführt werden, um bestehende Einstellungen zu erhalten
      • Die Beispielkonfiguration enthält den Provider modelstudio und das Modell qwen3.6-27b
        • api ist openai-completions
        • Der Wert für reasoning ist true
        • Eingabetypen sind text, image
        • contextWindow ist 131072
        • maxTokens ist 16384
        • Das primäre Standardmodell ist modelstudio/qwen3.6-27b

    • Qwen Code

      • Qwen Code ist ein Open-Source-AI-Agent für das Terminal und ein tief auf die Qwen Series optimiertes Tool
      • Das Startskript umfasst Node.js 20+, die Installation von @qwen-code/qwen-code@latest und das Ausführen von qwen
      • Innerhalb der Session werden Beispiele für die Befehle /help und /auth gezeigt
      • Bei der ersten Nutzung erscheint ein Login-Prompt; über /auth kann die Authentifizierungsmethode gewechselt werden

    • Claude Code

      • Qwen APIs unterstützen auch das Anthropic-API-Protokoll
      • Es wird ausdrücklich erwähnt, dass sie mit Tools wie Claude Code verwendet werden können
      • Die Beispielkonfiguration enthält folgende Umgebungsvariablen
      • Der Ausführungsbefehl ist claude

Fazit

  • Qwen3.6-27B belegt, dass ein gut trainiertes Dense-Modell die deutlich größere Vorgängergeneration bei für Entwickler wichtigen Aufgaben übertreffen kann
  • Trotz 27 Milliarden Parametern übertrifft es Qwen3.5-397B-A17B in allen wichtigen agentic-coding-Benchmarks
  • Die Struktur vereinfacht Deployment und Betrieb, und die Qwen3.6 Open-Source-Familie deckt mit der Ergänzung von Qwen3.6-27B nun ein breiteres Modellspektrum ab

Verwandte Beiträge

4 Kommentare

 
kaydash 6 일 전

Es müsste schon ein a3b sein, damit man es wenigstens ein bisschen lokal laufen lassen kann, haha
 
kirinonakar 7 일 전

Die Benchmarks sollen zwar gut sein, aber im praktischen Einsatz scheint es mir noch nicht auf einem Niveau zu sein, auf dem man es als Coding-Agent wirklich sinnvoll nutzen kann.
 
b89kim 4 일 전

Ich habe es ausprobiert, und beim agentischen Coding gibt es keine größeren Probleme. Wie schon gesagt ist die Leistung in der Praxis und beim allgemeinen Coding im Vergleich zu Modellen mit mehr Parametern aber zwangsläufig schwächer. Bitte beachten Sie auch, dass sich die Einstellungen von 3.5 unterscheiden und zusätzlich ein preserve_thinking-Modus hinzugekommen ist. Mit einer 27B-4bit-Quantisierung gab es bei der lokalen Nutzung keine Probleme.
 
GN⁺ 7 일 전
Hacker-News-Kommentare
  • Für mich waren die pelican-Ergebnisse für ein lokal laufendes, auf 16,8 GB quantisiertes Modell wirklich hervorragend. Ich habe sie hier zusammengefasst: https://simonwillison.net/2026/Apr/22/qwen36-27b/. Es lief auf einem M5 Pro mit 128 GB RAM, brauchte tatsächlich aber nur etwa 20 GB Speicher, daher sollte es wohl auch auf einer 32-GB-Maschine problemlos laufen. Das Lesen verarbeitete 20 Tokens in 0,4 Sekunden, also 54,32 tokens/s, und bei der Generierung entstanden 4.444 Tokens in 2 Minuten 53 Sekunden, also 25,57 tokens/s. Das Ergebnis gefiel mir besser als der pelican, den ich vor ein paar Tagen mit Opus 4.7 erzeugt hatte. https://simonwillison.net/2026/Apr/16/qwen-beats-opus/
    • Das ist fast schon zu gut gelungen, sodass ich mich frage, ob es nicht doch in den Trainingsdaten enthalten war. Ich würde gern noch weitere Tests sehen, um die Unterschiede besser einschätzen zu können.
    • Halb im Scherz denke ich, dass die Modellanbieter irgendwann anfangen könnten, gezielt auf Simons einflussreichen pelican riding a bicycle-Test hin zu optimieren.
    • Auch die Fliege beim Qwen Flamingo wirkt wirklich verblüffend passend.
    • Soweit ich mich erinnere, hört man beim pelican-Test nur äußerst selten Formulierungen wie excellent; hier scheint das aber wirklich gerechtfertigt. Interessant ist auch, dass nach einer Phase mit starkem Fokus auf MoE nun wieder dense Modelle Aufmerksamkeit bekommen. Ich frage mich, ob die geschlossenen Modelle ebenfalls in Richtung schnelle MoE-Linien und dense Pro-Linien gehen.
    • Inzwischen müssten LLMs doch erkannt haben, dass ein Fahrradrahmen im Grunde eine Raute ist → ◿◸. Hoffentlich ruiniere ich den Test nicht, indem ich das ausspreche.
  • Seit Gemma 4 rund um Ostern erschienen ist, habe ich das Gefühl, dass der Abstand zwischen self-hosted Modellen und Claude deutlich kleiner geworden ist. Natürlich ist der Unterschied immer noch groß, aber die früheren lokalen Modelle waren schlicht kaum konkurrenzfähig, daher ist die Lage jetzt viel besser. Und wenn Qwen 3.6 noch einmal eine Stufe über Gemma 4 liegt, ist das ziemlich spannend. Trotzdem driften lokale Modelle weiterhin manchmal in seltsame Richtungen ab oder scheitern, deshalb habe ich Opus immer griffbereit. Wenn mir ein lokales Modell aber wieder einmal richtig hilft, komme ich dem Gefühl näher, dass Coding weiterhin frei sein sollte. Frei im Sinn von kostenlos und frei im Sinn von Freiheit. Mein Setup ist eine separate Ubuntu-Maschine mit RTX 5090, und genau jetzt nutzt Qwen 3.6 27B 29 GB von 32 GB VRAM. Ollama läuft bei mir in einer rootlosen podman-Instanz, und im Editor nutze ich OpenCode als ACP Service; sehr empfehlenswert. ACP steht für Agent Client Protocol, und meiner Meinung nach sollte sich die Welt in diese Richtung bewegen. Und ich bin dem Qwen-Team dankbar, dass es die Welt in einer Welt voller Sam Altmans ein Stück besser macht.
    • Von den Modellen, die ich lokal auf meinem M5 MBP ausprobiert habe, fühlte sich Gemma4 am ehesten nach Claude an.
    • Ich teile das Ideal von free und local, aber am Ende halte ich nachhaltigen Wettbewerb für das Entscheidende. Allein dass dadurch Druck entsteht, Kosten von 200 Dollar im Monat massiv nach unten zu bringen, finde ich schon sehr erfreulich.
    • Ich frage mich, wie weit ein 27B-Modell bei echten Programmieraufgaben tatsächlich kommt. Selbst Claude lässt mich manchmal noch im Stich, daher fällt es mir schwer, mir vorzustellen, wie praxistauglich 27B ist.
    • Mich würde interessieren, wie viele tokens/s auf einer RTX 5090 herauskommen.
  • Ich wünschte, bei jeder Modellankündigung würde direkt dabeistehen, auf welcher consumer hardware das Modell sofort läuft, was es kostet und welche tok/s zu erwarten sind.
    • Um das direkt veröffentlichte 27B-Modell nativ in 16-Bit auszuführen, braucht man erhebliche Hardware. Nötig wären etwa Macs oder Strix-Halo-Systeme mit 128 GB, mehrere große Consumer-GPUs oder Workstation-Karten auf RTX-6000-Niveau. Deshalb bewerben sie wohl nicht offensiv, auf welcher Consumer-Hardware es läuft. Der Grund ist, dass das Original-Release, das diese Ergebnisse liefert, in typische Consumer-Systeme nicht gut hineinpasst. Die meisten nutzen statt des Originals quantisierte Varianten mit geringerer Bitzahl. Quantisierung bringt aber klare Trade-offs mit sich, daher sollte man nicht exakt dieselbe Qualität wie bei den beworbenen Ergebnissen erwarten. Beim früheren Qwen3.5 27B waren je nach tolerierbarem Qualitätsverlust Q5 oder Q4 noch ziemlich brauchbar, und auf Systemen mit Unified Memory brauchte man zusätzlich 32 GB RAM, sodass ein 64-GB-Mac meist passend war. Auch mit einer NVIDIA 5090 32GB oder zwei 16-GB- beziehungsweise 24-GB-GPUs war es möglich, aber durch die Verteilung war es langsamer. Behauptungen, dass es auf einem iPhone oder noch kleineren Systemen lief, sollte man meiner Meinung nach mit Vorsicht betrachten. Mit extremer Quantisierung und allerlei Tricks lässt sich die Ausführung zwar irgendwie ermöglichen, aber die Ausgabequalität ist oft nicht mehr praktisch nutzbar. Für Social-Media-Prahlerei tauchen immer wieder Repositories auf, die zeigen, dass es auf sehr kleiner Hardware läuft, aber die Ergebnisse sind häufig nicht wirklich gut.
    • Auf meinem M4 mit 32 GB RAM bekam ich etwa ~5 tokens/s. Ich habe unsloth/Qwen3.6-27B-GGUF:Q4_K_M mit llama-server ausgeführt, und das 35B-A3B-Modell kam auf rund 25 t/s. Zum Vergleich: Auf einer A100 waren es jeweils etwa 41 t/s und 97 t/s. Das 27B habe ich noch nicht lange getestet, aber das 35B-A3B ist oft entgleist, wenn der Kontext über 15k~20k Tokens hinausging. Für grundlegende Aufgaben kann man es stabil einsetzen, aber Frontier-Niveau würde ich das nicht nennen.
    • Die möglichen CPU/GPU-Kombinationen für lokale LLMs sind praktisch unendlich, deshalb wählen die meisten ein System passend zu Budget und Zielen und schätzen dann anhand von Modellgröße und Quantisierung grob den VRAM-Bedarf ab. Wenn man tiefer einsteigen will, kann man einen Online-VRAM-Rechner nutzen, zum Beispiel https://smcleod.net/vram-estimator/. Mit einem huggingface-Account kann man dort sogar seine Systemkonfiguration eingeben und anhand von Farben sehen, welche Quants wahrscheinlich passen. Und t/s hängt stark von Variablen wie der Kontextgröße ab, daher sind bestenfalls Schätzungen möglich. Lokale LLMs sind derzeit buchstäblich an jedem Punkt voller Trade-offs, sodass man je nach Aufgabe ständig neu entscheiden muss, was optimiert werden soll.
    • Qwen3.5-27B läuft mit 4bit quant auf einer 24-GB-Karte problemlos. Ich betreibe es mit zwei Nvidia-L4-Karten und einigen vllm-Flags für zehn Entwickler mit 20~25 tok/s; in ruhigen Phasen geht es bis etwa 40 tok/s hoch. Die Entwickler sind mit dieser Leistung zufrieden, haben aber dennoch nach zusätzlichen GPUs gefragt, um den Durchsatz weiter zu erhöhen.
    • Auf meiner RTX 4090D komme ich auf etwa 30 t/s, und der VRAM-Verbrauch liegt bei 42 von 48 GB. Die Quantisierung ist UD-Q6_K_XL, und die zugehörige Diskussion findet sich hier: https://huggingface.co/unsloth/Qwen3.6-27B-GGUF/discussions/7
  • Qwen oder Minimax veröffentlichen Open-Source-Modelle, die zwar etwas unter OpenAI oder Anthropic liegen, aber ähnliche Benchmark-Ergebnisse liefern. Deshalb frage ich mich, worin der Wettbewerbsvorteil von OpenAI oder Anthropic derzeit eigentlich genau besteht. Dazu kommt, dass die Tokenpreise dieser offenen Modelle nur einen Bruchteil von Anthropic Opus 4.6 ausmachen. https://artificialanalysis.ai/models/#pricing
    • Beim Coding halte ich die letzten paar Prozent Qualitätsunterschied für wichtig genug, um dafür einen Aufpreis zu zahlen. Das ist etwas anderes, als massenhaft Spam-Mails oder HN-Kommentare zu produzieren. Ich glaube, darin liegt auch der Grund, warum die Vergütung zwischen durchschnittlichen Ingenieuren und P99-Ingenieuren so stark auseinandergeht. Und dass Frontier-Anbieter aktuell trotz hoher R&D-Kosten wettbewerbsfähig bleiben, ist langfristig ein Vorteil, weil es sie zu besseren Produkten und mehr Mehrwert zwingt. Vor allem Anthropic scheint die Position eines vertrauenswürdigeren Anbieters anzustreben. Selbst Ali hostet inzwischen kostenpflichtige Frontier-Modelle, aber wenn man kein chinesisches Unternehmen ist, stellt sich die Frage, ob man produktive Code-Workloads bei einem in China gehosteten Anbieter laufen lassen möchte. Bei OpenAI habe ich auch gemischte Gefühle, aber ich würde dort immerhin weniger vermuten, dass Geschäftsgeheimnisse komplett abgeschöpft werden. Anthropic vertraue ich noch etwas mehr. Deshalb kann es dafür einen Aufpreis geben. Die historische Erfahrung, dass chinesische Hosting-Unternehmen jeden möglichen Wettbewerbsvorteil ausschöpfen und mit Regierung oder anderen Firmen teilen könnten, ist so präsent, dass die Leute dieses Risiko im Preis einrechnen.
    • Ich nutze sowohl Opus als auch Qwen, und subjektiv ist der Abstand zwischen beiden viel größer, als es Benchmark-Charts vermuten lassen. Wenn man mit gehosteten Modellen vergleichen will, sollte man derzeit eher auf GLM schauen. Das ist den großen Anbietern am nächsten; früher war es extrem günstig, aber inzwischen wurden die Preise angehoben.
    • Falls solche Ergebnisse auf vampire attacks zurückgehen, könnte die Leistung nicht mehr so gut aussehen, sobald geschlossene Modelle lernen, die Wege zu vergiften, über die ihre Antworten abgesaugt werden. Und im Alltags-Workflow fühlt es sich ohnehin noch nicht wirklich gleichwertig an. Für oberflächliches Reasoning mag es reichen, aber bei Coding oder schwierigeren Aufgaben gibt es weiterhin einen deutlichen Unterschied. Zumindest habe ich unter den offenen Modellen, die ich ausprobiert habe, noch keines gefunden, das mit geschlossenen Modellen mithalten kann. Falls jemand gute Einstellungen hat, würde ich sie gern erfahren.
    • Im Moment sehe ich keinen Wettbewerbsvorteil. Aber sobald sich irgendein Ökosystem zu integrieren beginnt, dürfte daraus ein Vorteil entstehen.
    • Der hohe Tokenpreis von Opus ist für mich eher ein Beleg dafür, dass Menschen bereitwillig für ein entsprechend besseres Modell zahlen. Die neuen Modelle von OpenAI und Anthropic sind sichtbar besser als Open Source; Open Source ist zwar nicht unbrauchbar, aber Frontier ist klar überlegen und wird das vermutlich noch eine Weile bleiben. Wenn SWE-Zeit mehr als 1 Dollar pro Minute kostet, dann lohnt sich selbst ein 10-Dollar-Prompt, wenn er 10 Minuten spart. Gerade bei Code-Arbeit führen subtile Qualitätsverbesserungen meiner Einschätzung nach zu großen Zeiteinsparungen.
  • Ich nutze auf meinem M4 MBP Qwen 3.6 35B und Gemma 4 26B; sie sind zwar nicht auf Opus-Niveau, erledigen aber 95% von dem, was ich brauche, und allein die Tatsache, dass all das vollständig lokal läuft, ist schon erstaunlich.
    • Mich würde interessieren, welche Art von Aufgaben du machst und über welches Harness oder welchen Ansatz du Qwen oder Gemma anbindest. Anders gesagt: Wie sehen dein Workflow und dein Software-Stack aus?
    • Inzwischen sind sie gut genug nutzbar, sodass ich ihnen mehr Arbeit übertrage, ähnlich wie Codex sich seine eigene Arbeit reduziert. Und auf meinem M4 hat die 122B-Version einen deutlich besseren Durchsatz als das dense 27B, daher freue ich mich auch sehr auf diese Variante.
    • Nutzt du dafür Ollama oder etwas anderes?
    • Ich würde gern genauer verstehen, was mit 95% gemeint ist. Mich interessieren zwei Dinge. Erstens: Bedeutet das, dass die Genauigkeit der Ausgabe bei etwa 95% von Opus 4.5 oder 4.6 liegt? Zweitens: Bedeutet es, dass es bei Tool-Calling oder agentischen Aufgaben, etwa Reiseplanung, im Vergleich zu Opus auf etwa 95% Leistungsfähigkeit kommt?
  • Ich bin bei lokalen LLMs noch nicht besonders erfahren und habe gestern etwas Zeit darauf verwendet, einige Qwen3.6-35B-A3B-Modelle einzurichten und zu testen. Es waren wohl mlx 4b und 8b sowie gguf Q4_K_M und Q4_K_XL. Auf meinem 64-GB-M4 war das schon ziemlich beeindruckend. Laut der Tabelle von TFA wirkt das neue Modell allerdings etwas smarter, scheint aber mehr VRAM zu brauchen. Ich frage mich, ob der entscheidende Unterschied darin liegt, dass es dense ist. Und weil 27B kleiner als 35B ist, hoffe ich, dass bald quantisierte Modelle erscheinen, die die VRAM-Anforderungen noch weiter senken.
    • Entscheidend ist nicht einfach der Vergleich der Parameterzahl. Das 35B-A3B ist ein Mixture of Experts-Modell, bei dem jeweils nur ungefähr 3B Parameter gleichzeitig aktiv sind. Deshalb skaliert der tatsächliche Rechenaufwand eher in Richtung dieser 3B als der vollen 35B. Natürlich braucht man weiterhin breitbandigen Zugriff auf alle 35B-Layer. Das neue Modell dagegen ist dense und dürfte auf Macs deutlich langsamer sein. Auf meinem M4 Pro waren es zum Beispiel mit Q6 gguf rund 9 tok/s, während 35-A3B mit Q4 und mlx, also kein fairer Vergleich, auf etwa 70 tok/s kam. Im Allgemeinen laufen solche dense Modelle auf dedizierten GPUs besser, und wenn genug VRAM da ist, um das gesamte Modell resident zu halten, wird die Entscheidung einfacher. Ich schätze, dieses Modell dürfte mit ungefähr 24GB VRAM oder mehr gut funktionieren, also etwa auf NVIDIA 3090, 4090 oder 5090.
  • Wenn man es im llama server mit Q4_K_M ausführt, kommt man bei 24 GB auf etwa 91k context, und nachgerechnet liegt der KV-Cache pro 1K Kontext bei rund 70 MB. Mit Q5 wären vermutlich noch etwa 30K Tokens an Spielraum übrig geblieben, was ich schon ziemlich beeindruckend finde.
  • Ich habe einen Fahrrad fahrenden pelican als SVG erzeugt, das Ergebnis ist https://codepen.io/chdskndyq11546/pen/yyaWGJx. Außerdem habe ich einen Drachen erzeugt, der Auto fährt und dabei einen Hotdog isst, das Ergebnis ist https://codepen.io/chdskndyq11546/pen/xbENmgK. Es ist nicht perfekt, aber schon an solchen Ergebnissen sieht man gut, wie leistungsfähig die Modelle geworden sind.
    • Das Drachenbild hat Probleme wie nur ein Auge oder einen merkwürdigen Schwanz, aber der pelican war fast perfekt, so gut, dass ich ihn für den besten halte, den ich bisher gesehen habe.
    • Das ist inzwischen ein so bekannter benchmark, dass ich mich frage, ob die Modelle nicht bereits gezielt auf diesen Test trainiert wurden.
  • Nach allem, was ich bisher mit lokaler Inferenz erlebt habe, bin ich noch nicht wirklich beeindruckt. Auf einem M5 Pro mit 128 GB RAM bekam ich mit omlx etwa 11 tokens/s und brauchte am Ende eine Stunde, um ein paar Hundert Zeilen nicht funktionierenden Code zu schreiben. Dieselbe Aufgabe erledigten Opus und Sonnet in CC in wenigen Minuten erfolgreich. Das 3.6-35b-Modell, das ich gestern mit Ollama ausgeführt habe, wirkte ganz okay. Ich will noch andere Harnesses außer Claude Code ausprobieren, aber momentan fühlen sich lokale Modelle schlicht zu langsam an.
    • Das ist ein dense model, daher ist es normal, dass es auf einem Mac langsam ist. Auf einem Mac solltest du eher das Mixture-of-Experts-Release von Qwen3.6 versuchen, also Qwen3.6-35B-A3B. Auf meinem M4 Pro kam das auf ungefähr 70 tok/s. Wenn es bei dir viel langsamer ist, nutzt du möglicherweise versehentlich das GGUF-Format. Auf dem Mac ist das Apple-spezifische MLX-Format oft schneller.
    • Auf meinem M2 Max MacBook bekam ich mit der MLX-8-Bit-Quantisierung etwa 7 tokens/sec bei der Generierung.
    • OpenCode schien lokale Modelle besser zu nutzen als Claude.
  • Ich frage mich, was man auf einem M4 Pro mit 48 GB RAM laufen lassen kann.