Vorstellung des Modells Qwen3-Coder-Next

• Qwen3-Coder-Next ist ein Open-Weight-Sprachmodell, das für Code-generierende Agenten und lokale Entwicklungsumgebungen entwickelt wurde und auf hybrider Attention sowie einer MoE-Architektur basiert
• Es wurde durch umfangreiche Synthese ausführbarer Aufgaben, Interaktion mit Umgebungen und Reinforcement Learning trainiert und verfügt dadurch auch bei niedrigen Inferenzkosten über starke Coding- und Agentenfähigkeiten
• Statt einer bloßen Skalierung der Parameter liegt der Fokus auf der Skalierung von Agenten-Trainingssignalen; mithilfe verifizierbarer Coding-Aufgaben und ausführbarer Umgebungen lernt es direkt aus Feedback
• Auf SWE-Bench Verified erreicht es über 70 % und zeigt auch auf SWE-Bench Pro sowie in mehrsprachigen Umgebungen eine Leistung, die mit großen Modellen konkurrieren kann
• Trotz seiner kompakten Größe erreicht das Modell ein Pareto-Gleichgewicht aus Effizienz und Leistung und ist damit besonders relevant für kosteneffiziente Agenten-Deployments

---

Überblick über Qwen3-Coder-Next

• Qwen3-Coder-Next ist ein Open-Weight-Sprachmodell auf Basis von Qwen3-Next-80B-A3B-Base
  • Es verwendet hybride Attention und eine Mixture-of-Experts-(MoE)-Architektur
  • Das Training erfolgte durch groß angelegte Synthese ausführbarer Aufgaben, Umgebungsinteraktion und Reinforcement Learning
• Ziel ist die effiziente Nutzung in Coding-Agenten und lokalen Entwicklungsumgebungen
  • Es bietet starke Reasoning-Fähigkeiten und Coding-Performance bei niedrigen Inferenzkosten

Ansatz zur Skalierung des Agenten-Trainings

• Das Modell konzentriert sich stärker auf die Skalierung von Agenten-Trainingssignalen als auf die Skalierung der Parameterzahl
  • Durch die Kombination verifizierbarer Coding-Aufgaben mit ausführbaren Umgebungen lernt es direkt aus Umgebungsfeedback
• Wichtige Trainingsphasen
  • Fortlaufendes Pretraining mit code- und agentenfokussierten Daten
  • Supervised Fine-Tuning mit hochwertigen Agenten-Trajektoriendaten
  • Fachspezifisches Training für Bereiche wie Software Engineering, QA und Web/UX
  • Destillation mehrerer Expertenmodelle in ein einzelnes, deploybares Modell
• Dieser Ansatz stärkt Fähigkeiten für langfristiges Reasoning, Tool-Nutzung und Wiederherstellung nach Ausführungsfehlern

Benchmark-Leistung für Coding-Agenten

• Bewertet auf verschiedenen Benchmarks wie SWE-Bench (Verified, Multilingual, Pro), TerminalBench 2.0 und Aider
  • Auf SWE-Bench Verified werden über 70 % erreicht
  • Auch auf SWE-Bench Pro und in mehrsprachigen Umgebungen bleibt das Modell konkurrenzfähig
  • Trotz einer kleinen Zahl aktiver Parameter erreicht es eine Leistung auf oder über dem Niveau größerer Open-Source-Modelle
• Bei Multi-Turn-Agentenaufgaben zeigt sich, dass mit steigender Zahl an Agenten-Turns auch die Fähigkeit zu langfristigem Reasoning zunimmt

Balance zwischen Effizienz und Leistung

• Qwen3-Coder-Next (3B active) erreicht auf SWE-Bench-Pro eine ähnliche Leistung wie 10- bis 20-mal größere Modelle
• Proprietäre Modelle auf Basis vollständiger Attention liegen bei der absoluten Leistung zwar vorn, doch Qwen3-Coder-Next positioniert sich bei der Kosteneffizienz auf einer überlegenen Pareto-Frontier
• Das zeigt, dass das Modell gut für kosteneffiziente Agenten-Deployments geeignet ist

Demos und Anwendungsbeispiele

• Als kompaktes und schnelles Coder-Modell kann es in verschiedene Anwendungsszenarien integriert werden
  • Demonstriert in OpenClaw, Qwen Code, Claude Code, Web Dev, Browser Use und Cline
  • Webbasierte Nutzung ist über coder.qwen.ai möglich

Zusammenfassung und Ausblick

• Qwen3-Coder-Next hat hohe Geschwindigkeit und starke Reasoning-Fähigkeiten in Benchmarks für Coding-Agenten bewiesen
• Im Vergleich zu großen Open-Source-Modellen zeigt es wettbewerbsfähige Leistung, bietet aber weiterhin Raum für Verbesserungen
• Künftig sollen Tool-Nutzung, Lösen komplexer Probleme und Entscheidungsfähigkeit weiter ausgebaut werden
  • Außerdem sind Unterstützung für mehr Aufgaben und schnelle Updates auf Basis von Nutzerfeedback geplant

[GN⁺]

Hacker-News-Kommentare

• Dieses GGUF-Modell ist 48,4 GB groß und kann selbst auf einem leistungsstarken Laptop ausgeführt werden
  Bisher habe ich noch kein lokales Modell gesehen, das auf meinem 64-GB-MacBook Pro einen Coding-Agenten auf dem Niveau von Codex CLI oder Claude Code wirklich ordentlich laufen lässt
  Vielleicht ist es dieses Mal anders. Der Unsloth-Leitfaden lässt darauf hoffen

  • Ich finde, statt des Ausdrucks „lokales Modell“ braucht es einen neuen Begriff wie „Modell auf meinem Rechner“
    Es reicht nicht, etwas als lokal zu bezeichnen, nur weil es per llama.cpp auf derselben Maschine verbunden ist. Mit lokal meine ich ein LAN-Modell, also ein Niveau, bei dem Inferenz auf Hardware unter meiner direkten Kontrolle praktisch „kostenlos“ läuft
    Zum Beispiel kostet eine Konfiguration mit 5090 + Threadripper + 256 GB RAM etwa 10.000 Dollar, der MLX-Weg etwa 6.000 Dollar
    Da sich die interne Struktur des Modells und die Quantisierungsmethode stark auf den tatsächlichen Speicherverbrauch auswirken, wird ein Vergleich allein über die Parameterzahl immer weniger aussagekräftig
    Deshalb braucht es meiner Meinung nach ein System, das reale Aufgaben wie Tool-Calling, Code-Erzeugung und Dokumentenverarbeitung auf standardisierter Hardware benchmarkt
  • Ich betreibe Qwen3-Coder-30B-A3B-Instruct gguf auf einer VM mit 13 GB RAM und einer RTX 2060 GPU mit 6 GB
    Selbst auf meinem alten Razer-Black-Laptop läuft es bis 64k Kontext ziemlich stabil
    Für kleine Projekte, Bugfixes oder UI-Verbesserungen ist es absolut brauchbar
    Ich denke aber, dass der Maßstab für „usable“ von Person zu Person unterschiedlich ist. Je nachdem, welche Aufgaben man ausprobiert hat, fällt das Urteil anders aus
  • Ich habe GPT-OSS-120b (MXFP4) zusammen mit Codex verwendet; dabei wurden etwa 66 GB VRAM genutzt
    Es könnte ziemlich nützlich sein, gute Ausführungslogs des 120b-Modells zu sammeln und damit eine Nachtrainierung (Fine-Tuning) einer 20b-Version zu machen
    Mit höherem reasoning_effort liefert es ziemlich ordentliche Ergebnisse, aber wegen der 64-GB-Speichergrenze ist eine Verbesserung des 20b realistischer
  • Ich habe Claude Code mit einem lokalen Modell (ollama run glm-4.7-flash) auf einem Mac mini M2 Pro mit 32 GB laufen lassen
    Für Dinge wie Aufräumen von altem Git-Projektcode, Dokumentation und das Hinzufügen von Tests war es völlig ausreichend
    Vielleicht sind meine Maßstäbe niedrig, aber als lokale Coding-Hilfe bin ich ziemlich zufrieden
  • In etwa fünf Jahren werden sich die meisten Modelle wohl lokal ausführen lassen
    Wenn die Produktion von High-End-GPUs und Speicher steigt und die Modelloptimierung voranschreitet, dürfte auch Hardware der Mittelklasse eine ausreichend gute Leistung liefern

• Ich habe die Dynamic Unsloth GGUF für lokale Deployments auf Hugging Face hochgeladen
  und außerdem einen Leitfaden zum lokalen Einsatz von Claude Code / Codex geschrieben

  • Auf meinem System läuft es mit ungefähr 39 tok/s bei rund 60 % GPU-Auslastung
    Ich habe einen llama.cpp-Server in einer Umgebung auf Basis einer Radeon RX 7900 XTX betrieben, und mit der Einstellung ctx-size 32768 lief es stabil
  • Ich habe Feedback bekommen, dass mein Modell in Framework Desktop genutzt wird
    Es gab die Frage, warum man statt des Standard-GGUF von Qwen3 die Unsloth-Version verwenden sollte
  • Es gab den Wunsch, dass IQuest-Coder auf dieselbe Weise bereitgestellt wird
  • Es wurde nach dem Unterschied zwischen der UD-Version und der normalen Version gefragt
  • Es gab auch erstaunte Reaktionen nach dem Motto: „Wie konntest du das so schnell bauen?“

• Ich habe llama.cpp über Homebrew installiert und das quantisierte Modell von Unsloth lokal ausgeführt
  Ich konnte gleichzeitig die CLI-Oberfläche und einen OpenAI-kompatiblen API-Server starten, wobei etwa 28 GB RAM genutzt wurden

  • Jemand fragte, wie hoch die Token-Geschwindigkeit (token/s) sei
  • Eine andere Person wollte wissen, wie der allgemeine Eindruck sei

• Wenn dieses Modell wirklich hält, was behauptet wird, dann wäre Coding-Leistung auf Sonnet-4.5-Niveau mit 3B aktiven Parametern enorm

  • Ich habe die quantisierten Versionen Q2 und Q4 getestet; es ist zwar beeindruckend, dass sie lokal laufen, aber Sonnet-4.5-Niveau ist es nicht
    Selbst bei einfachen Problemen gab es Fehler, und teilweise geriet es in eine Thinking-Loop
    Das könnte ein Bug der frühen Implementierung sein, aber im Moment wirken die Leistungsbehauptungen überzogen
  • Meinem Eindruck nach ist es eher auf Haiku-Niveau
  • Dabei fällt mir der Satz ein: „Wenn es zu gut aussieht, um wahr zu sein, ist es das wahrscheinlich auch nicht.“

• Ich habe Qwen3 Coder 30B lokal auf einem Mac M4 Max (36 GB) ausprobiert
  Es war zwar langsam, funktionierte aber und lieferte ziemlich gute Ergebnisse
  Ich teile ein Demo-Video und einen Blogpost zur Einrichtung

• Auf einem Laptop mit 6 GB VRAM waren 17 tok/s möglich, mit bis zu 100k Kontext
  Beeindruckend, aber die Geschwindigkeit ist zu langsam, deshalb werde ich wohl weiter Cloud-Inferenz nutzen
  Es wurde ein [docker-compose-Konfigurationsbeispiel] geteilt

• Ich habe das FP8-Modell in einer Umgebung mit DGX Spark + vLLM 0.15.1 gebenchmarkt
  Bei einer einzelnen Anfrage waren etwa 43 tok/s drin, bei parallelen Anfragen bis zu 62 tok/s

  • Ich habe das FP8-Modell in vLLM ausgeführt, aber während der Laufzeit wurde es nach BF16 dequantisiert, was zu Memory-Swapping führte
    Die 4-Bit-quantisierte Version in llama.cpp erreicht etwa 30–35 tok/s und nutzt selbst bei 200k Kontext nur 50 GB RAM

• Mit 3B aktiven Parametern liegt die Leistung etwas unter GLM 4.7, aber die Effizienz ist beeindruckend
  Wenn man einen schnellen, aber einfachen Coding-Agenten zusammen mit einem Orchestrator einsetzt, könnte die Gesamtspeed sogar höher ausfallen

  • Ich nutze Claudes Sub-Agent-Funktion, um TypeScript-Agenten auf Mastra-Basis per CLI laufen zu lassen
    Damit automatisiere ich wiederkehrende Aufgaben wie Code-Scans, Bibliothekssuche und Sourcegraph-Erkundung
    Dank der Workspace-Funktion von Mastra ist eine noch leistungsfähigere agentische Entwicklung möglich geworden
  • Letztlich wird sich das alles wohl erst dann breiter durchsetzen, wenn die großen AI-Unternehmen ihre Preise anheben

• Ich habe lmstudio-community/Qwen3-Coder-Next-GGUF:Q8_0 auf Strix Halo ausprobiert
  32 tok/s und bis zu 128k Kontext waren möglich. Es ist etwas schwächer als MiniMax M2.1 Q6, aber trotzdem beeindruckend

  • Es gab die Frage, wie Strix Halo so ist. Außerdem meinte jemand, dass er eine Maschine wolle, die lokale Inferenz ohne Quantisierung ermöglicht
  • Auf NVIDIA Spark habe ich ähnliche Werte erreicht und teste gerade die Version Q4_K_XL
    FP8 nutzte 110 GB und erlaubte nur 16k Kontext
    Ich habe es für die Generierung von Rust-Code verwendet, und es war ziemlich fähig. Wenn nur die Geschwindigkeit besser würde, könnte es tatsächlich nutzbar sein
    Wahrscheinlich werden API-Anbieter dieses Modell bald günstig anbieten

• Ich frage mich, welchen Quellen für Rankings lokaler Modelle man vertrauen kann
  Benchmarks wirken oft zu manipuliert, deshalb finde ich persönliche Reviews aussagekräftiger
  Ich würde gern wissen, ob es irgendwo eine Übersicht über die besten Modelle nach Domäne gibt, etwa für Code, Sprache, Bilder, Zusammenfassungen oder Musik