🌠Qwen3-Coder-Next: Anleitung zum lokalen Betrieb
Anleitung zum lokalen Ausführen von Qwen3-Coder-Next auf deinem Gerät!
Qwen veröffentlicht Qwen3-Coder-Next, ein 80B MoE-Modell (3B aktive Parameter) mit 256K Kontext für schnelles agentisches Codieren und lokale Nutzung. Es ist vergleichbar mit der Leistung von Modellen mit 10–20× mehr aktiven Parametern.
Es läuft auf 46GB RAM/VRAM/einheitlichem Speicher (85GB für 8-Bit), ist nicht-denkend für ultraschnelle Code-Antworten. Das Modell ist hervorragend bei Langzeit-Reasoning, komplexer Werkzeugnutzung und der Wiederherstellung nach Ausführungsfehlern.
Update vom 19. Feb: Tool-Aufrufe sollten jetzt nach den llama.cpp-Parser-Fixes noch besser sein.
NEU! Siehe Quantisierungs-Benchmarks für unsere Dynamic GGUFs!
4. Feb: llama.cpp behob einen Fehler, der die Berechnung für vektorisierten key_gdiff korrigierte. Das behebt frühere Schleifen- und Ausgabeprobleme. Wir haben die GGUFs aktualisiert - bitte erneut herunterladen und AKTUALISIEREN llama.cpp für bessere Ausgaben.
Sie lernen außerdem, das Modell auf Codex & Claude Code auszuführen. Für Feinabstimmung, Qwen3-Next-Coder passt für bf16 LoRA in Unsloth auf eine einzelne B200-GPU.
Qwen3-Coder-Next Unsloth Dynamische GGUFs zum Ausführen: unsloth/Qwen3-Coder-Next-GGUF
GGUF-Tutorial ausführenCodex & Claude CodeFP8 vLLM Tutorial
⚙️ Gebrauchsanleitung
Haben Sie keinen 46GB RAM oder einheitlichen Speicher? Kein Problem — Sie können unsere kleineren Quants wie 3-Bit verwenden. Am besten ist, wenn die Modellgröße gleich der Summe Ihrer Rechenressourcen ist ( Festplattenspeicher + RAM + VRAM ≥ Größe des Quants). Wenn Ihr Quant vollständig auf Ihr Gerät passt, rechnen Sie mit 20+ Tokens/s. Wenn es nicht passt, funktioniert es weiterhin durch Auslagerung, wird aber langsamer.
Um optimale Leistung zu erreichen, empfiehlt Qwen diese Einstellungen:
Temperatur = 1.0Top_P = 0.95Top_K = 40Min_P = 0.01(llama.cpp's Standard ist 0.05)Wiederholungsstrafe= deaktiviert oder 1.0
Unterstützt bis zu 262,144 Kontext nativ, aber Sie können ihn auf 32,768 Tokens für geringeren Speicherverbrauch setzen.
🖥️ Qwen3-Coder-Next ausführen
Je nach Anwendungsfall benötigen Sie unterschiedliche Einstellungen. Da dieses Handbuch 4-Bit verwendet, benötigen Sie etwa 46GB RAM/einheitlichen Speicher. Wir empfehlen mindestens 3-Bit-Präzision für beste Leistung.
Update vom 4. Feb: llama.cpp behob einen Fehler, der die Berechnung für vektorisierten key_gdiff korrigierte. Das behebt frühere Schleifen- und Ausgabeprobleme. Wir haben die GGUFs aktualisiert - bitte erneut herunterladen und AKTUALISIEREN llama.cpp für bessere Ausgaben.
HINWEIS: Dieses Modell unterstützt nur den Nicht-Denk-Modus und generiert keine <think></think> Blöcke in seiner Ausgabe. Daher ist die Angabe von enable_thinking=False nicht mehr erforderlich.
Llama.cpp Tutorial (GGUF):
Anweisungen zum Ausführen in llama.cpp (Hinweis: wir verwenden 4-Bit, um auf die meisten Geräte zu passen):
Holen Sie sich das neueste llama.cpp auf GitHub hier. Sie können auch den Build-Anweisungen unten folgen. Ändern Sie -DGGML_CUDA=ON zu -DGGML_CUDA=OFF wenn du keine GPU hast oder einfach nur CPU-Inferenz möchtest. Für Apple Mac / Metal-Geräte, setze -DGGML_CUDA=OFF und fahre dann wie gewohnt fort - Metal-Unterstützung ist standardmäßig aktiviert.
Sie können direkt von Hugging Face ziehen. Sie können den Kontext auf 256K erhöhen, wenn Ihr RAM/VRAM es zulässt. Die Verwendung von --fit on bestimmt ebenfalls automatisch die Kontextlänge.
Sie können die empfohlenen Parameter verwenden: temperature=1.0, top_p=0.95, top_k=40
Laden Sie das Modell über (nach Installation von pip install huggingface_hub). Sie können UD-Q4_K_XL oder andere quantisierte Versionen. Falls Downloads hängen bleiben, siehe Hugging Face Hub, XET-Debugging
Dann das Modell im Konversationsmodus ausführen:
Passen Sie außerdem Kontextfenster wie benötigt an, bis zu 262,144
HINWEIS: Dieses Modell unterstützt nur den Nicht-Denk-Modus und generiert keine <think></think> Blöcke in seiner Ausgabe. Daher ist die Angabe von enable_thinking=False nicht mehr erforderlich.
🦙 Llama-Server Bereitstellung & Deployment
Um Qwen3-Coder-Next für die Produktion bereitzustellen, verwenden wir llama-server In einem neuen Terminal, z. B. via tmux. Dann stellen Sie das Modell bereit mit:
Dann in einem neuen Terminal, nachdem Sie pip install openaiausgeführt haben, können wir das Modell starten:
Was Folgendes ausgibt:
Wir haben das HTML extrahiert und ausgeführt, und das erzeugte Beispiel-Flappy-Bird-Spiel funktionierte gut!

👾 OpenAI Codex & Claude Code
Um das Modell für lokale agentische Coding-Workloads auszuführen, können Sie unserem Leitfaden folgen. Ändern Sie einfach den Modellnamen 'GLM-4.7-Flash' in 'Qwen3-Coder-Next' und stellen Sie sicher, dass Sie die korrekten Qwen3-Coder-Next-Parameter und Gebrauchsanweisungen befolgen. Verwenden Sie das llama-server das wir gerade eingerichtet haben.
Nachdem Sie beispielsweise die Anweisungen für Claude Code befolgt haben, werden Sie Folgendes sehen:

Wir können dann zum Beispiel fragen Erstelle ein Python-Spiel für Schach :



Wenn Sie sehen API Error: 400 {"error":{"code":400,"message":"request (16582 tokens) exceeds the available context size (16384 tokens), try increasing it","type":"exceed_context_size_error","n_prompt_tokens":16582,"n_ctx":16384}} dann bedeutet das, dass Sie die Kontextlänge erhöhen müssen oder siehe Qwen3-Coder-Next

🎱 FP8 Qwen3-Coder-Next in vLLM
Sie können jetzt unser neues FP8 dynamische Quantisierung des Modells für hochwertige und schnelle Inferenz verwenden. Installieren Sie zuerst vLLM aus dem Nightly-Build. Ändern Sie --extra-index-url https://wheels.vllm.ai/nightly/cu130 auf Ihre CUDA-Version, die Sie mit nvidia-smi finden - nur und cu129 cu130
werden derzeit unterstützt. 🎱 FP8 Qwen3-Coder-Next in vLLM
Dann starten Sie den Dienst Unsloths dynamische FP8-Version Unsloths dynamische FP8-Version --kv-cache-dtype fp8 --kv-cache-dtype fp8 CUDA_VISIBLE_DEVICES='0' und setzen Sie --tensor-parallel-size 1 --tensor-parallel-size 1 tmux oder entfernen Sie dieses Argument. Verwenden Sie um das Folgende in einem neuen Terminal zu starten und dann CTRL+B+D - verwenden Sie tmux attach-session -t0
--port 8001 Qwen3-Coder-Next wie man Qwen3-Coder-Next tatsächlich mit der OpenAI-API und Tool-Aufrufen verwendet - dies funktioniert für vLLM und llama-server.

🔧Tool-Aufrufe mit Qwen3-Coder-Next
In einem neuen Terminal erstellen wir einige Tools wie das Addieren von 2 Zahlen, Ausführen von Python-Code, Ausführen von Linux-Funktionen und vieles mehr:
Anschließend verwenden wir die untenstehenden Funktionen (kopieren, einfügen und ausführen), die Funktionsaufrufe automatisch parsen und den OpenAI-Endpunkt für jedes Modell aufrufen:
Nun zeigen wir mehrere Methoden zum Ausführen von Tool-Aufrufen für viele verschiedene Anwendungsfälle unten:
Ausführen generierten Python-Codes

Ausführen beliebiger Terminalbefehle
Wir bestätigen, dass die Datei erstellt wurde — und das wurde sie!

Siehe Tool Calling Guide für weitere Beispiele für Tool-Aufrufe.
📐Benchmarks
GGUF-Quantisierungs-Benchmarks
Hier sind einige Quantisierungs-Benchmarks, die von Dritten durchgeführt wurden.


Die Benchmarks wurden von Drittbeiträgen auf dem Aider Polyglot-Server durchgeführt und verglichen Unsloth GGUF-Quantisierungen auf dem Aider Polyglot-Benchmark (Punktzahl vs. VRAM). Bemerkenswert ist, dass die 3-Bit UD-IQ3_XXS Quant kommt nahe an BF16 Leistung, wodurch 3-Bit ein sinnvolles Minimum für die meisten Anwendungsfälle ist.
NVFP4 übertrifft die BF16-Referenz leicht, was auf Stichprobenrauschen durch eingeschränkte Durchläufe zurückzuführen sein kann; das allgemeine Muster für: 1-Bit → 2-Bit → 3-Bit → 6-Bit stetige Verbesserung legt nahe, dass der Benchmark aussagekräftige Qualitätsunterschiede zwischen Unsloth-GGUFs erfasst. Das nicht-Unsloth FP8 scheint schlechter abzuschneiden als beide UD-IQ3_XXS und UD-Q6_K_XL, was Unterschiede in der Quantisierungspipeline widerspiegeln könnte oder wiederum auf unzureichende Stichprobengröße hindeutet.
Benjamin Marie (Drittpartei) hat bewertet Qwen3-Coder-Next unter Verwendung von Unsloth- und Qwen-GGUFs auf einer 750-Prompt-Misch-Suite (LiveCodeBench v6, MMLU Pro, GPQA, Math500) und berichtete sowohl über gesamte Genauigkeit und relative Fehlerzunahme (wie viel häufiger das quantisierte Modell Fehler macht im Vergleich zum Original).
Die Grafiken zeigen deutlich, dass die Unsloth Q4_K_M-Quants besser abschneiden als Standard Q4_K_M. Q3_K_M schneidet erwartungsgemäß schlechter im Live Code Bench v6 ab, überraschenderweise jedoch deutlich besser bei HumanEval als das Standard Q4_K_M. Es scheint am effizientesten zu laufen; es wird empfohlen, mindestens Q4_K_M zu verwenden.
Qwen3-Coder-Next Benchmarks
Qwen3-Coder-Next ist das leistungsstärkste Modell für seine Größe, und seine Leistung ist vergleichbar mit Modellen mit 10–20× mehr aktiven Parametern.
SWE-Bench Verifiziert (mit SWE-Agent)
70.6
70.2
74.2
74.8
SWE-Bench Mehrsprachig (mit SWE-Agent)
62.8
62.3
63.7
66.2
SWE-Bench Pro (mit SWE-Agent)
44.3
40.9
40.6
34.6
Terminal-Bench 2.0 (mit Terminus-2 json)
36.2
39.3
37.1
32.6
Aider
66.2
69.9
52.1
61.0



Zuletzt aktualisiert
War das hilfreich?

