Qwen3-Coder-Next モデル公開

 (qwen.ai)
6 ポイント 投稿者 GN⁺ 2026-02-04 | 1件のコメント | WhatsAppで共有
  • Qwen3-Coder-Next は、コード作成エージェントとローカル開発環境向けに設計された オープンウェイト言語モデル で、ハイブリッドアテンションと MoE 構造をベースとしている
  • 大規模な 実行可能タスク合成 と 環境インタラクション、強化学習 を通じて訓練され、低い推論コストでも強力な コーディング能力とエージェント能力 を備える
  • 単純なパラメータ拡張ではなく エージェント訓練シグナルの拡張 に焦点を当て、検証可能なコーディング課題と実行環境を活用して直接フィードバックを学習する
  • SWE-Bench Verified で 70% 以上を達成し、SWE-Bench Pro および多言語環境でも大規模モデルと競争可能な性能を示す
  • 小型モデルでありながら効率性と性能の パレートバランス を達成し、コスト効率の高い エージェント配備 において重要な意味を持つ

Qwen3-Coder-Next の概要

  • Qwen3-Coder-Next は Qwen3-Next-80B-A3B-Base をベースとしたオープンウェイト言語モデル
    • ハイブリッドアテンションと Mixture of Experts(MoE) 構造を採用
    • 大規模な 実行可能タスク合成、環境インタラクション、強化学習 を通じて訓練
  • 目標は コーディングエージェント と ローカル開発環境 での効率的な活用
    • 低い推論コストでも強力な 推論能力 と コーディング性能 を提供

エージェント訓練の拡張方式

  • モデルは パラメータ数の拡張 よりも エージェント訓練シグナルの拡張 に注力
    • 検証可能なコーディング課題と実行可能な環境を組み合わせ、環境からのフィードバックを直接学習
  • 主な訓練段階
    • コードおよびエージェント中心データによる 継続事前学習
    • 高品質なエージェント軌跡データを活用した 教師ありファインチューニング
    • ソフトウェアエンジニアリング、QA、Web/UX など分野別の専門訓練
    • 複数の専門家モデルを 単一配備型モデルへ蒸留
  • このようなアプローチは 長期推論、ツール使用、実行失敗からの復旧 能力を強化する

コーディングエージェントのベンチマーク性能

  • SWE-Bench (Verified, Multilingual, Pro)、TerminalBench 2.0、Aider など多様なベンチマークで評価
    • SWE-Bench Verified で 70% 以上を達成
    • SWE-Bench Pro および多言語環境でも競争力を維持
    • 小さなアクティブパラメータ数にもかかわらず、より大きなオープンソースモデルと同等またはそれ以上の性能
  • マルチターンのエージェントタスク では、エージェントのターン数を増やすほど 長期推論能力 が強化されることを確認

効率性と性能のバランス

  • Qwen3-Coder-Next (3B active) は 10〜20倍大きいモデル と同等の SWE-Bench-Pro 性能を達成
  • 全アテンションベースの独占モデル が絶対性能では先行する一方、Qwen3-Coder-Next は コスト対効率 において優れたパレートフロンティア上に位置する
  • これは コスト効率の高いエージェント配備 に適したモデルであることを示している

デモと適用例

  • 小型・高速のコーダーモデルとして、さまざまな応用環境に統合可能
    • OpenClaw、Qwen Code、Claude Code、Web Dev、Browser Use、Cline などでデモを実施
    • coder.qwen.ai を通じて Web ベースで利用可能

要約と今後の計画

  • Qwen3-Coder-Next は コーディングエージェントのベンチマークで優れた速度と推論能力 を実証
  • 大規模オープンソースモデルと比べても 競争力のある性能 を示すが、依然として改善の余地はある
  • 今後は ツール活用能力、複雑な問題解決、意思決定能力 を強化し
    • より多くのタスク対応と、ユーザーフィードバックに基づく 迅速なアップデート を計画

関連記事

1件のコメント

 
GN⁺ 2026-02-04
Hacker Newsのコメント

  • このGGUFモデルは48.4GBで、ハイスペックなノートPCでも実行可能とのこと
    これまで自分の64GB MacBook ProでCodex CLIやClaude Code級のコーディングエージェントをまともに動かせるローカルモデルは見たことがなかった
    今回は違うかもしれない。 Unslothガイドを見ると可能性がありそう

    • 「ローカルモデル」という表現の代わりに、「自分のコンピュータモデル」のような新しい用語が必要だと思う
      単に同じマシンで llama.cpp に繋がっているだけではローカルと呼ぶには不十分。ここで言うローカルとは、LANモデル、つまり自分で直接制御するハードウェア上で推論を“無料で”回せるレベルを意味する
      たとえば 5090 + Threadripper + 256GB RAM の構成は約1万ドル、MLX ルートなら約6000ドル
      モデルの      内部構造と量子化方式      が実際のメモリ使用量に大きく影響するので、単純にパラメータ数だけで比較することの意味はますます薄れている
      そのため、標準化されたハードウェア基準でtool calling、コード生成、文書処理のような実作業をベンチマークする仕組みが必要だと思う
    • 自分はQwen3-Coder-30B-A3B-Instruct ggufを13GB RAM の VM と 6GB RTX 2060 GPU で動かしている
      古い Razer Blade ノートPC なのに、64k コンテキストまではかなり安定して動く
      小さなプロジェクトやバグ修正、UI 改善のような作業には十分使える
      ただし「usable」の基準は人それぞれだと思う。どんな作業を試したかで評価は変わるはず
    • 自分はGPT-OSS-120b (MXFP4) を Codex と一緒に使ってみたが、約66GB VRAMを使用した
      120b モデルの良い実行ログを集めて 20b 版を**追加学習（fine-tuning）**すればかなり有用になりそう
      reasoning_effort を上げるとかなり良い結果が出るが、64GB メモリの制約があるので 20b 改善の方が現実的
    • Claude Codeをローカルモデル（ollama run glm-4.7-flash）に設定して 32GB M2 Pro Mac mini で動かしてみた
      古い git プロジェクトのコード整理、ドキュメント化、テスト追加には十分実用的だった
      自分の基準が低いのかもしれないが、ローカルのコーディング補助としてはかなり満足している
    • これから5年ほどで、たいていのモデルはローカル実行できるようになる気がする
      高性能GPUとメモリの生産が増え、モデル最適化が進めば、中級クラスのハードウェアでも十分良い性能が出せるはず

  • ローカル配布向けのDynamic Unsloth GGUFを Hugging Face に上げ、
    Claude Code / Codexをローカルで使うためのガイドも作成した

    • 自分のシステムでは約39 tok/s、GPU 使用率 60% 前後で動いている
      Radeon RX 7900 XTX ベースの環境で llama.cpp サーバーを実行し、ctx-size 32768設定で安定して動作した
    • Framework Desktop で自分のモデルを使っているというフィードバックを受けた
      なぜ Qwen3 の標準 GGUF ではなく Unsloth 版を使うべきなのか気になる、という質問があった
    • IQuest-Coderも同じ方式で配布してほしいという要望があった
    • UD 版と通常版の違いを尋ねる質問もあった
    • 「これをこんなに早く作れた理由は何なんだ」という、驚き交じりの反応もあった

  • Homebrew でllama.cppをインストールし、Unsloth の量子化モデルをローカルで実行した
    CLI インターフェースとOpenAI 互換 API サーバーを同時に立ち上げられ、約28GB RAMを使用した

    • トークン速度（token/s）がどれくらいかと尋ねる人がいた
    • 別の人は全体的な印象（impression）がどうか気にしていた

  • このモデルが本当に主張どおりなら、3B アクティブパラメータで Sonnet 4.5 級のコーディング性能を出すというのはとてつもないこと

    • Q2、Q4 量子化版を試してみたが、ローカルで動くのは驚きでもSonnet 4.5 級ではない
      簡単な問題でもエラーがあり、thinking loopに陥ることもあった
      初期実装のバグかもしれないが、現時点では誇張された性能主張に見える
    • 体感ではHaiku級に近い
    • 「うますぎる話はたいてい本物ではない」という言葉を思い出す

  • Qwen3 Coder 30Bを Mac M4 Max（36GB）でローカル実行してみた
    遅くはあったが動作し、かなり良い結果が出た
    デモ動画 と 設定方法のブログ を共有している

  • 6GB VRAM のノートPCで17 tok/s、最大 100k コンテキストまで可能だった
    驚きではあるが速度が遅いので、結局はクラウド推論を引き続き使う予定
    [docker-compose 設定例]を共有した

  • DGX Spark + vLLM 0.15.1環境で FP8 モデルをベンチマークした
    単一リクエストでは約43 tok/s、並列リクエストでは最大 62 tok/s に達した

    • FP8 モデルを vLLM で動かしてみたが、実行中にBF16 にデクォンタイズされてメモリスワップが発生した
      llama.cpp の 4-bit 量子化版は約 30〜35 tok/s で、200k コンテキストでも 50GB RAM しか使わなかった

  • 3B アクティブパラメータで GLM 4.7 よりやや低い性能だが、効率は驚異的
    高速だが単純なコーディングエージェントをオーケストレーターと組み合わせれば、全体の速度はさらに上がるかもしれないと思う

    • 自分はClaude の sub-agent 機能を活用して、Mastra ベースの TypeScript エージェント群を CLI で動かしている
      コードスキャン、ライブラリ検索、SourceGraph 探索のような反復作業を自動化している
      Mastra のWorkspace 機能のおかげで、より強力なエージェント型開発が可能になった
    • 結局これらすべてがもっと広く使われるようになるのは、大手AI企業が価格を上げたときになりそう

  • lmstudio-community/Qwen3-Coder-Next-GGUF:Q8_0を Strix Halo で動かしてみたところ、
    32 tok/s、128k コンテキストまで可能だった。MiniMax M2.1 Q6 よりやや弱いが印象的

    • Strix Halo がどうなのか気になるという質問があった。量子化なしでローカル推論できるマシンが欲しいという意見もあった
    • NVIDIA Spark でも似たような数値が出ており、Q4_K_XL 版をテスト中とのこと
      FP8 は 110GB を使って 16k コンテキストしか取れなかった
      Rust のコード生成に使ってみたがかなり有能だった。速度さえ改善されれば実用になりそう
      近いうちにAPI プロバイダーがこのモデルを安価に提供し始める気がする

  • ローカルモデルのランキングを信頼できる場所がどこなのか気になる
    ベンチマークは操作されすぎている感じがして、個人レビューの方が意味があると思う
    コード、音声、画像、要約、音楽などドメイン別の優秀なモデルを整理している場所があれば知りたい