🌠Qwen3-Coder-Next: ローカル実行方法
Qwen3-Coder-Next をお使いのデバイスでローカル実行するガイドです!
Qwen が Qwen3-Coder-Next をリリース。80B MoE モデル(有効パラメータ 3B)で、 256K のコンテキスト 高速なエージェント的コーディングとローカル利用向け。10〜20倍多い有効パラメータを持つモデルと同等の性能です。
これは 46GB の RAM/VRAM/統合メモリ(8-bit では 85GB)で動作し、超高速なコード応答のために非推論モードです。このモデルは、長期的推論、複雑なツール使用、実行失敗からの復旧に優れています。
2月19日 अपडेट: llama.cpp のパース修正後、ツール呼び出しはさらに良くなっているはずです。
新! 参照 量子化ベンチマーク Dynamic GGUF 向け!
2月4日: llama.cpp の計算を修正するバグを修正しました ベクトル化された key_gdiff。 これで以前のループや出力の問題が修正されます。GGUF を更新しました。 再ダウンロード および 更新 llama.cpp して、より良い出力を得てください。
また、Codex と Claude Code でモデルを実行する方法も学べます。 ファインチューニングでは、Qwen3-Next-Coder は Unsloth の bf16 LoRA なら単一の B200 GPU に収まります。
Qwen3-Coder-Next Unsloth Dynamic GGUF で実行するには: unsloth/Qwen3-Coder-Next-GGUF
GGUF 実行チュートリアルCodex と Claude CodeFP8 vLLM チュートリアル
⚙️ 使用ガイド
46GB の RAM または統合メモリがありませんか?心配無用です。3-bit などの小さい量子化版を実行できます。モデルサイズは計算資源の合計( ディスク容量 + RAM + VRAM ≥ 量子化版のサイズ)と同じくらいであるのが理想です。 量子化版がデバイスに完全に収まるなら、20 tokens/s 以上が期待できます。収まらなくてもオフロードで動作しますが、速度は遅くなります。
最適な性能を得るには、Qwen は以下の設定を推奨しています:
Temperature = 1.0Top_P = 0.95Top_K = 40Min_P = 0.01(llama.cpp のデフォルトは 0.05)繰り返しペナルティ= 無効、または 1.0
ネイティブで最大 262,144 コンテキストまで対応していますが、 32,768 トークンに設定してメモリ使用量を減らすこともできます。
🖥️ Qwen3-Coder-Next を実行
用途によって異なる設定が必要です。このガイドでは 4-bit を使うため、約 46GB の RAM/統合メモリが必要です。最高の性能のために、少なくとも 3-bit 精度を推奨します。
2月4日更新: llama.cpp の計算を修正するバグを修正しました ベクトル化された key_gdiff。 これで以前のループや出力の問題が修正されます。GGUF を更新しました。 再ダウンロード および 更新 llama.cpp して、より良い出力を得てください。
注意:このモデルは非思考モードのみをサポートし、出力に <think></think> ブロックを生成しません。そのため、 enable_thinking=False を指定する必要はなくなりました。
Llama.cpp チュートリアル(GGUF):
llama.cpp で実行する手順(ほとんどのデバイスに収まるように 4 ビットを使用する点に注意):
最新の llama.cpp を GitHub こちらで入手してください。以下のビルド手順に従うこともできます。GPU がない、または CPU 推論のみを行いたい場合は、 -DGGML_CUDA=ON を -DGGML_CUDA=OFF に変更してください。 Apple Mac / Metal デバイス向けでは、 -DGGML_CUDA=OFF を設定してから通常どおり続けてください。Metal サポートはデフォルトで有効です。
Hugging Face から直接取得できます。RAM/VRAM に収まるなら、コンテキストを 256K まで増やせます。 --fit on を使うと、コンテキスト長も自動で決定されます。
推奨パラメータを使えます: temperature=1.0, top_p=0.95, top_k=40
以下でモデルをダウンロードしてください(事前に pip install huggingface_hub)。 UD-Q4_K_XL または他の量子化版。ダウンロードが止まる場合は、 Hugging Face Hub、XET デバッグ
その後、会話モードでモデルを実行します:
また、必要に応じて コンテキストウィンドウ 必要に応じて、最大 262,144
注意:このモデルは非思考モードのみをサポートし、出力に <think></think> ブロックを生成しません。そのため、 enable_thinking=False を指定する必要はなくなりました。
🦙Llama-server の提供とデプロイ
Qwen3-Coder-Next を本番環境へ展開するには、 llama-server 新しいターミナルで tmux などを使ってください。次に、以下でモデルを展開します:
その後、新しいターミナルで、 pip install openai、モデルを実行できます:
すると次のような出力になります:
HTML を抽出して実行してみたところ、生成された Flappy Bird のサンプルはうまく動作しました!

👾 OpenAI Codex と Claude Code
ローカルのコーディングエージェント的なワークロードを通じてモデルを実行するには、 こちらのガイドに従ってください。モデル名を 'GLM-4.7-Flash' から 'Qwen3-Coder-Next' に変更し、Qwen3-Coder-Next の正しいパラメータと使用手順に従ってください。 llama-server さっき設定したものを使ってください。
たとえば Claude Code の手順に従うと、次のように表示されます:

それから、例えばこう尋ねられます チェスの Python ゲームを作成して :



次が表示されたら 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}} それはコンテキスト長を増やす必要があるか、 Qwen3-Coder-Next

🎱 vLLM における FP8 Qwen3-Coder-Next
新しい FP8 Dynamic 量子化版 を使って、高品質で高速な推論ができます。まず nightly 版の vLLM をインストールします。 --extra-index-url https://wheels.vllm.ai/nightly/cu130 を、 nvidia-smi で確認した CUDA バージョンに変更してください。 - 現時点でサポートされているのは および cu129 cu130
だけです。vLLM / SGLang を使う場合は、スループットを 25% 以上向上できる FP8-Dynamic 量子化版を試してください! Qwen3-Coder-Next
次に serve します Unsloth のダイナミック FP8 版 を。さらに、次を追加して FP8 を有効にし、KV キャッシュのメモリ使用量を 50% 削減できます: --kv-cache-dtype fp8 こちらは 4 GPU で実行しましたが、1 GPU しかない場合は CUDA_VISIBLE_DEVICES='0' を使い、 --tensor-parallel-size 1 を設定するか、この引数を削除してください。 tmux を使って以下を新しいターミナルで起動し、その後 CTRL+B+D を押してください。戻るには tmux attach-session -t0 を使います。
以下のようなものが表示されるはずです。 Qwen3-Coder-Next Qwen3-Coder-Next を OpenAI API とツール呼び出しで実際に使う方法については

🔧Qwen3-Coder-Next でのツール呼び出し
新しいターミナルで、2つの数の加算、Python コードの実行、Linux 関数の実行など、いくつかのツールを作成します:
その後、以下の関数(コピーして貼り付けて実行)を使います。これにより関数呼び出しが自動的に解析され、どのモデルに対しても OpenAI エンドポイントが呼び出されます:
以下では、さまざまなユースケース向けにツール呼び出しを実行する複数の方法を紹介します:
生成された Python コードを実行

任意のターミナル関数を実行
ファイルが作成されたことを確認できました。実際に作成されています!

参照 Tool Calling Guide ツール呼び出しのさらに多くの例は
📐ベンチマーク
GGUF 量子化ベンチマーク
こちらは第三者評価者によって実施された量子化ベンチマークです。


ベンチマークは Aider Polyglot サーバー上で第三者の協力者により実行され、Aider Polyglot ベンチマーク(スコア対 VRAM)で Unsloth GGUF 量子化版を比較しました。特に 3-bit の UD-IQ3_XXS 量子化版は BF16 性能にかなり近く、 3-bit は妥当な最小値 となっており、ほとんどの用途に適しています。
NVFP4 は BF16 の参照実装をわずかに上回っています。これは実行回数が限られているためのサンプリングノイズかもしれません。ただし、全体的な傾向としては: 1-bit → 2-bit → 3-bit → 6-bit が着実に改善していることから、このベンチマークは Unsloth GGUF 間の意味のある品質差を捉えていると考えられます。 非 Unsloth FP8 は両方よりも性能が悪いようです UD-IQ3_XXS および UD-Q6_K_XL。これは量子化パイプラインの違い、あるいはやはりサンプリング不足を反映しているのかもしれません。
Benjamin Marie(サードパーティ)がベンチマークを実施 Qwen3-Coder-Next Unsloth と Qwen GGUF を使って 750 プロンプトの混合スイートで (LiveCodeBench v6、MMLU Pro、GPQA、Math500)、以下の両方を報告: 全体精度 および 相対誤差増加 (量子化モデルが元モデルよりどれだけ多く間違えるか)。
グラフは明らかに、Unsloth の Q4_K_M 量子化版が標準の Q4_K_M より優れていることを示しています。Q3_K_M は予想どおり Live Code Bench v6 では標準の Q4_K_M より性能が悪いですが、驚くことに HumanEval では標準の Q4_K_M よりかなり良い結果です。 最も効率よく動作するようなので、少なくとも Q4_K_M を使うことを推奨します。
Qwen3-Coder-Next ベンチマーク
Qwen3-Coder-Next はサイズに対して最も高性能なモデルであり、その性能は 10〜20 倍多いアクティブパラメータを持つモデルに匹敵します。
SWE-Bench Verified (w/ SWE-Agent)
70.6
70.2
74.2
74.8
SWE-Bench Multilingual (w/ SWE-Agent)
62.8
62.3
63.7
66.2
SWE-Bench Pro (w/ SWE-Agent)
44.3
40.9
40.6
34.6
Terminal-Bench 2.0 (w/ Terminus-2 json)
36.2
39.3
37.1
32.6
Aider
66.2
69.9
52.1
61.0



最終更新
役に立ちましたか?

