🌠Qwen3-Coder-Next: ローカルで実行する方法
Qwen3-Coder-Next をローカルデバイスで実行するためのガイド!
Qwenは、アクティブパラメータ3Bの80B MoEモデルであるQwen3-Coder-Nextをリリースしました(特徴: 256Kコンテキスト 急速なエージェント型コーディングとローカル使用向け。アクティブパラメータが10~20倍多いモデルと同等の性能を示します。
実行環境は 46GBのRAM/VRAM/統合メモリ(8ビットで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 GGUFs 実行用: unsloth/Qwen3-Coder-Next-GGUF
GGUF実行チュートリアルCodex & Claude CodeFP8 vLLMチュートリアル
⚙️ 使い方ガイド
46GBのRAMや統合メモリがない?心配いりません。3ビットなど小さい量子化で実行できます。モデルサイズは利用可能な計算資源の合計( ディスク容量 + RAM + VRAM ≥ 量子化サイズ)。 量子化データがデバイスに完全に収まる場合、20トークン/秒以上を期待できます。収まらない場合でもオフロードで動作しますが遅くなります。
最適な性能を得るために、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ビットを使用するため、約46GBのRAM/統合メモリが必要です。最高の性能のために少なくとも3ビット精度を使用することを推奨します。
2月4日アップデート: llama.cpp で、次の計算を修正するバグが修正されました: ベクトル化された key_gdiff。 これにより以前のループや出力の問題が修正されます。GGUFを更新しました - どうぞ 再ダウンロード して アップデート llama.cpp してより良い出力を得てください。
注:このモデルは非思考モードのみをサポートしており、出力に <think></think> ブロックを生成しません。したがって enable_thinking=False を指定する必要はなくなりました。
Llama.cppチュートリアル(GGUF):
llama.cppで実行する手順(ほとんどのデバイスに収めるため4ビットを使用します):
最新の llama.cpp を入手してください GitHubはこちら。以下のビルド手順に従うこともできます。変更してください -DGGML_CUDA=ON を -DGGML_CUDA=OFF に、GPUがない場合やCPU推論のみを行いたい場合はしてください。
Hugging Faceから直接取得できます。RAM/VRAMに余裕があればコンテキストを256Kに増やすことも可能です。使用することで --fit オン はコンテキスト長を自動的に決定します。
推奨パラメータを使用できます: 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 を、お使いのCUDAバージョンに合わせて(次のコマンドで確認) nvidia-smi - 現在サポートされるのは cu129 して cu130 のみです。
vLLM / SGLangを使用する場合は、スループットを25%以上向上させることができるFP8-Dynamic量子化を試してください!参照: Qwen3-Coder-Next
その後、次をサーブします Unsloth の動的 FP8 バージョン モデルの。KV キャッシュのメモリ使用量を 50% 削減するために FP8 を有効にすることもできます(次を追加:) --kv-cache-dtype fp8 4 GPU で提供しましたが、もし GPU が 1 台しかない場合は、次を使用してください CUDA_VISIBLE_DEVICES='0' そして次を設定します --tensor-parallel-size 1 またはこの引数を削除してください。次を使って tmux 新しい端末で下記を起動し、CTRL+B+D を押します - 使用するには tmux attach-session -t0 で戻れます。
次のような表示が出るはずです。実際に Qwen3-Coder-Next を OpenAI API とツールコーリングで使う方法は、を参照してください - これは vLLM と llama-server 両方に対応します。 Qwen3-Coder-Next Qwen3-Coder-Next を OpenAI API とツールコーリングで実際に使う方法については参照してください - これは vLLM と llama-server に対して機能します。

🔧Qwen3-Coder-Next を使ったツールコーリング
新しい端末で、2 つの数を足す、Python コードを実行する、Linux 関数を実行する等、多くのツールを作成します:
次に下記の関数を使用します(コピーして貼り付けて実行) — これらは関数呼び出しを自動的に解析し、任意のモデルに対して OpenAI エンドポイントを呼び出します:
以下では、さまざまなユースケースに対するツールコーリングの複数の実行方法を紹介します:
生成された Python コードを実行する

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

参照: Tool Calling Guide ツールコーリングのさらなる例については参照してください。
📐ベンチマーク
GGUF 量子化ベンチマーク
以下は第三者評価者によって実施された量子化ベンチマークの結果です。


ベンチマークは第三者の寄稿者により Aider Polyglot サーバー上で実行され、Aider Polyglot ベンチマークでの Unsloth GGUF 量子化(スコア vs VRAM)を比較しました。注目すべきは、3 ビットの UD-IQ3_XXS 量子化はほぼ BF16 の性能に近く、 3 ビットはほとんどのユースケースにとって妥当な最小値であるということです。 。
NVFP4 は BF16 参照よりやや優れており、これは試行回数が限られているためのサンプリングノイズである可能性があります;しかし全体的なパターン: 1 ビット → 2 ビット → 3 ビット → 6 ビット で着実に改善していることは、ベンチマークが 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 では性能が低いですが、驚くべきことに HumanEval では標準の Q4_K_M よりもはるかに良好でした。 最も効率的に動作するようで、少なくとも Q4_K_M の使用が推奨されます。
Qwen3-Coder-Next ベンチマーク
Qwen3-Coder-Next はそのサイズに対して最も高い性能を示すモデルであり、その性能は 10〜20 倍のアクティブパラメータを持つモデルと比較しても同等です。
SWE-Bench 検証済み(SWE-Agent 使用)
70.6
70.2
74.2
74.8
SWE-Bench 多言語(SWE-Agent 使用)
62.8
62.3
63.7
66.2
SWE-Bench Pro(SWE-Agent 使用)
44.3
40.9
40.6
34.6
Terminal-Bench 2.0(Terminus-2 json 使用)
36.2
39.3
37.1
32.6
Aider
66.2
69.9
52.1
61.0



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

