技術 約5分で読めます

Qwen3-Coder-Next: 3Bアクティブパラメータでローカル動作するコーディングエージェント

AI LLM オープンソース エージェント

AlibabaのQwenチームが2026年2月にリリースしたQwen3-Coder-Nextが面白い。80Bパラメータのモデルなのに、実際にアクティベートされるのはたった3B。SWE-Bench Verifiedで70%超えを達成しながら、RTX 4090単体やMacBook Proでもローカル動作する。

ローカルで動くコーディングエージェントを探していたので、技術的な特徴をまとめた。

アーキテクチャ

Mixture of Experts（MoE）ベースで、主要スペックは以下の通り。

項目値
総パラメータ数80B
アクティブパラメータ数3B
非埋め込みパラメータ79B
レイヤー数48（ハイブリッドレイアウト）
エキスパート数512
アクティブエキスパート10
共有エキスパート1
隠れ層次元2048
アテンションヘッドQ:16, KV:2
コンテキスト長256K
ライセンスApache 2.0

注目すべきはアクティブパラメータと総パラメータの比率。Kimi K2.5が1T中32Bをアクティベートするのに対し、Qwen3-Coder-Nextは80B中わずか3B。パラメータ効率が桁違いに高い。

Gated DeltaNet

長文コンテキスト処理のボトルネックは、通常のアテンションの計算量が入力長の二乗に比例すること。Qwen3-Coder-NextではGated DeltaNet（線形アテンション、O(n)計算量）と従来のアテンションをハイブリッドで組み合わせている。

これにより256Kトークンの長いコンテキストでも、二次関数的な速度低下が起きにくい。エージェントタスクでは会話履歴やツール呼び出し結果が蓄積されていくため、この設計は理にかなっている。

ベンチマーク

SWE-Bench Verified

モデルスコアアクティブパラメータ
Claude Opus 4.580.9%非公開
GPT-5.280.0%非公開
Claude Sonnet 4.577.2%非公開
Kimi K2.576.8%32B
Qwen3-Coder-Next70.6%3B

70%超えという数字自体はトップモデルに及ばないが、3Bのアクティブパラメータで達成している点が重要。10〜20倍のパラメータを持つモデルと同等レベルの性能を、はるかに少ない計算リソースで実現している。

実務タスク評価

16x Engineerの評価結果。

タスクスコア
Markdown整形（中難度）9.25/10
フォルダー監視修正（通常）8.75/10
Next.js TODO機能（簡単）8.0/10
ベンチマーク可視化（難）7.0/10
TypeScript型絞り込み（特殊）1.0/10
総合平均6.8/10

中難易度の標準的なコーディングタスクでは強い。一方、TypeScriptの型絞り込みのような特殊なパターンは苦手。オープンソースではDeepSeek V3を上回り、Kimi K2に次ぐポジション。

ローカル実行

ハードウェア要件

量子化を使えば、意外と現実的なハードウェアで動作する。

  • RTX 4090（24GB VRAM）: Q4量子化で動作可能
  • MacBook Pro（十分なRAM）: GGUF形式で動作可能
  • 推奨: 64GB以上のシステムRAM

対応フォーマット

フォーマット用途
Safetensors（BF16）フルモデル
FP8量子化版（メモリ削減）
GGUFllama.cpp/Ollama用

Ollamaでの実行

ollama run qwen3-coder-next

llama.cppでの実行

./llama-server -m Qwen3-Coder-Next.gguf -c 32768 -ngl 99

メモリ不足の場合はコンテキスト長を32,768に削減することが推奨されている。

エージェント統合

対応プラットフォーム

Claude Code、Qwen Code、Cline、Continue、Cursor等の主要なコーディングアシスタントに対応。OpenAI互換APIとして動作するため、既存のツールチェーンにそのまま組み込める。

vLLMでのサーバー起動

pip install 'vllm>=0.15.0'
vllm serve Qwen/Qwen3-Coder-Next \
  --port 8000 \
  --tensor-parallel-size 2 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

SGLangでのサーバー起動

pip install 'sglang[all]>=v0.5.8'
python -m sglang.launch_server \
  --model Qwen/Qwen3-Coder-Next \
  --port 30000 \
  --tp-size 2 \
  --tool-call-parser qwen3_coder

ツール呼び出し

OpenAI互換のFunction Callingに対応。

from openai import OpenAI

client = OpenAI(base_url='http://localhost:8000/v1', api_key="EMPTY")

tools = [{
    "type": "function",
    "function": {
        "name": "read_file",
        "description": "ファイルの内容を読み取る",
        "parameters": {
            "type": "object",
            "required": ["path"],
            "properties": {
                "path": {"type": "string", "description": "ファイルパス"}
            }
        }
    }
}]

response = client.chat.completions.create(
    model="Qwen3-Coder-Next",
    messages=[{"role": "user", "content": "main.pyの内容を確認して"}],
    tools=tools,
    max_tokens=65536
)

推奨サンプリングパラメータ

  • Temperature: 1.0
  • Top P: 0.95
  • Top K: 40

注意点

  • 思考モードなし: <think></think>ブロックは生成されない。推論過程を見たい場合は別のモデルを検討
  • 特殊パターンが苦手: TypeScriptの型絞り込みなど、あまり見かけないコードパターンでは精度が落ちる
  • UI生成は微妙: ビジュアライゼーションタスクでフォーマットの問題が報告されている

所感

Claude 4系やGPT-5系の有料モデルとは差があるものの、ローカルで動作するコーディングエージェントとしては現状最強クラス。3Bのアクティブパラメータで70%超えのSWE-Benchスコアは効率面で画期的。

APIコストを気にせず使い倒せるのは大きい。プライベートなコードベースを外部に送りたくない場合や、オフライン環境で開発したい場合に選択肢になる。

とはいえ、個人的には今Claude Opus 4.5、GPT-5.2、Gemini 2.5 Proの有料最上位を使っているので、利用頻度は低くなりそう。Claude Sonnet 5も控えているし、ローカルLLMにもSonnet 4.5くらいの性能は欲しいところ。軽めのタスクを投げて比較検証してみるかもしれない。

参考