🌠Qwen3-Coder-Next: ローカルで実行する方法
Qwen3-Coder-Next をローカルで実行するためのガイド!
QwenはQwen3-Coder-Nextをリリースしました。これは80BのMoEモデル(アクティブパラメータ3B)で、 256Kコンテキスト エージェント志向の高速コーディングとローカル利用向けです。アクティブパラメータが10〜20倍多いモデルと同等の性能を示します。
それは 46GBのRAM/VRAM/統合メモリ(8ビットで85GB)で動作し、超高速なコード応答のために思考モードではありません。モデルは長期的な推論、複雑なツール使用、および実行失敗からの回復に優れています。
2月19日更新:llama.cppの解析修正後、ツール呼び出しがさらに良くなっているはずです。
新着! 詳細については、こちらを参照してください 量子化ベンチマーク 我々のダイナミック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による推論のみを行いたい場合。 AppleのMac/Metalデバイスの場合、を設定し、 -DGGML_CUDA=OFF 通常通り続けてください - Metalサポートはデフォルトで有効です。
Hugging Faceから直接プルできます。RAM/VRAMが許せばコンテキストを256Kに増やせます。を使用すると、コンテキスト長も自動的に決定されます。 --fit を はコンテキスト長も自動決定します。
推奨パラメータを使えます: temperature=1.0, top_p=0.95, top_k=40
pip install huggingface_hub hf_transfer 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エラー: 400 {"error":{"code":400,"message":"リクエスト(16582トークン)が利用可能なコンテキストサイズ(16384トークン)を超えています。増やしてみてください","type":"exceed_context_size_error","n_prompt_tokens":16582,"n_ctx":16384}} これはコンテキスト長を増やす必要があるか、を参照してください Qwen3-Coder-Next

🎱 vLLMでのFP8 Qwen3-Coder-Next
現在、私たちの新しい FP8ダイナミック量子化 プレミアムで高速な推論のためのモデル。まず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 我々は4GPUでサービスしましたが、GPUが1つしかない場合は、代わりに CUDA_VISIBLE_DEVICES='0' そして設定してください --tensor-parallel-size 1 またはこの引数を削除してください。以下を新しいターミナルで起動してからCTRL+B+Dを押します - 戻るには tmux を使用してください tmux attach-session -t0 でそれに戻ります。
以下のような出力が表示されるはずです。詳しくは Qwen3-Coder-Next vLLMやllama-serverでのOpenAI APIとツール呼び出しを使ってQwen3-Coder-Nextを実際に使う方法については、を参照してください。

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

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

詳細については、こちらを参照してください Tool Calling Guide ツール呼び出しのさらなる例については、を参照してください。
📐ベンチマーク
GGUF量子化ベンチマーク
以下は第三者評価者による量子化ベンチマークの結果です。


ベンチマークは第三者の寄稿者によりAider Polyglotサーバーで実行され、Aider Polyglotベンチマーク上でUnslothのGGUF量子化をVRAMに対するスコアで比較しました。注目すべきは、3ビットの UD-IQ3_XXS 量子化がほぼ BF16 の性能に近く、 3ビットはほとんどのユースケースで妥当な最低選択となります。 NVFP4
はBF16参照をわずかに上回りますが、これは試行回数が限られているためのサンプリングノイズかもしれません;しかし全体的なパターンとして: 1ビット → 2ビット → 3ビット → 6ビット が着実に改善していることは、ベンチマークがUnsloth GGUF間の品質差を意味のある形で捉えていることを示唆しています。 非Unsloth FP8は両方よりも性能が劣るように見え、これは量子化パイプラインの違いか、再びサンプリング不足を反映している可能性があります。 でUnslothとQwenのGGUFを使用している UD-IQ3_XXS および UD-Q6_K_XLグラフは明確にUnslothのQ4_K_M量子化が標準のQ4_K_Mよりも優れていることを示しています。Q3_K_Mは予想通りLive Code Bench v6では劣りますが、HumanEvalでは驚くほど標準Q4_K_Mより良い結果を示しました。
最も効率的に動作するようで、少なくともQ4_K_Mの使用が推奨されます。
Benjamin Marie(第三者)がベンチマークを実施しました Qwen3-Coder-Next Qwen3-Coder-Nextベンチマーク 750プロンプトの混合スイートで (LiveCodeBench v6、MMLU Pro、GPQA、Math500)、両方を報告しています: 全体的な精度 および 相対誤差増加 (量子化モデルがどれだけ多く元のモデルより誤答するか)。
Qwen3-Coder-Nextはそのサイズにおいて最も高性能なモデルであり、その性能はアクティブパラメータが10〜20倍多いモデルに匹敵します。
Qwen3-Coder-Next(80B)
DeepSeek-V3.2(671B)
SWE-Bench Pro(SWE-Agent付)
70.6
70.2
74.2
74.8
Terminal-Bench 2.0(Terminus-2 json付)
62.8
62.3
63.7
66.2
Aider
44.3
40.9
40.6
34.6
Aider
36.2
39.3
37.1
32.6
Aider
66.2
69.9
52.1
61.0



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

