Qwen3-Coder-Nextが出ていますね。
Qwen3-Coder-Next: Pushing Small Hybrid Models on Agentic Coding
Qwen3-Next 80B-A3Bをベースにしたコーディングモデルです。80Bで、Activeパラメータは3Bということで、かなり軽快に動きます。
しかし、元になるQwen3-Nextでは一発のコードはかけるものの やりとりすると弱く、あまりコードは書かせれないなと思っていたので、同じアーキテクチャならちょっと不安が。Qwen3-Nextは線形アテンションを取り入れてるけど、コーディングには向かないんじゃなかろうか、と思っていたので。
そして、その不安は現実に、ということをまとめます。失敗の質が悪い。アーキテクチャについては最後にまとめてます。
確かに、Qwen3-Nextに比べるとかなりコードが書けるようになったようです。でも、単発のコードはかなり書けるが、やりとりの筋が悪く、長いタスクはまかせれない、というところ。コードを書いてもらって編集の指摘をして、と進む作業には不安があります。
なので、ベンチマークなどコード一発かかせて「性能が高い！」という話はあまり鵜呑みにせず、実際の利用形態で確認するほうがいいです。
GGUFとMLXで試す
Mac Studio 512GBのLM Studioで動かします。
MLXが爆速！58toc/sec出てました。GGUFでは36toc/secです。
GGUFはUnslothさんところのQ4_K_Mです。
https://huggingface.co/unsloth/Qwen3-Coder-Next-GGUF/blob/main/Qwen3-Coder-Next-Q4_K_M.gguf
6bit成分多め。
ちなみに、llama.cppでのQwen3 Next実装にバグがあったらしく、修正されています。LM Studioに来るまでタイムラグがあると思うので、いま試してる人は注意。
https://github.com/ggml-org/llama.cpp/pull/19324
MLXはLM Studio CommunityのMLX 4bit。
https://lmstudio.ai/models/qwen/qwen3-coder-next
MLXはプロンプト読み込みが遅いと書いたのですが、Qwen3-Coder-NextではMLXのほうが速いです。
MacでLLMを動かすときMLX版はGGUF版に比べてプロンプト処理がかなり遅い - きしだのHatena
「注文の多い料理店」の要約では、プロンプト読み込みがGGUFで4秒、MLXで2秒くらいでした。GLM-4.7のときに30秒と60秒だったのに比べると激速。
これは線形アテンションの恩恵かな。
コードを書かせた
まずは、いつものブロック崩し。
JS版でやってみた。あとでパーティクルの追加とブロックのグラデーションをやってもらってる。
Java版も。
型エラーを出してきたので、ちょっと印象が悪いけど、指摘したらすぐなおしたので問題なし。
main.java:138: エラー: 不適合な型: 精度が失われる可能性があるdoubleからintへの変換
dx = 4 (hitPos - 0.5) 2; // 左/右へ曲がる
^
エラー1個
エラー: コンパイルが失敗しました
新しいswitch構文も使ってますね。JavaのSwingのコードは古いものが多く、ラムダ式ではなく匿名クラスを使ったり新しい構文を使わないことがあるのだけど、安定して新しい構文を使ってる印象。
そして、コード差分を表示するツールも一発で作ってくれました。
コードの修正が怪しいと感じていたので、確認用に。こういう、その場で必要なツールをその場で用意できるのは便利ですね。
一発のコード生成はかなり向上してるようです。
gpt-oss 120bやGLM 4.5 Air(106B)など、他の100Bクラスのモデルよりも難しいコードを書けるかな、という印象です。
GLM 4.7と比べると、先ほどのようなコンパイルエラーがあったり、パストレーシングのような難しいコードはうまく書いてくれませんでした。
確実性でいうと、gpt-oss 120bやGLM 4.5-Airのほうが安定感があります。
Spring Bootアプリ
OpenCodeでSpring BootでのTODO管理を作ってもらうとこんな感じ。
Qwen3-Nextだとこうだったので、画面構成はかなりの進化。
最近のモデルはだいたいちゃんとスタイルシートをあてるようになってきているので、これは昨年頭からのコーディングエージェント流行をみてHTMLデザインのトレーニングを増やしたんではないかという気がする。9月に出たQwen3-Nextでは間に合わなかったということだろう。
ただし、Thymeleafではエラーを出しまくっていた。こんな感じで、タグの中にタグをかくようなこともやっていた。
<button type="submit" class="btn btn-sm btn-outline-<th:block th:if="${todo.completed}">success</th:block><th:block th:unless="${todo.completed}">primary</th:block>">
やりとりしてると怪しい
「誤差逆伝播を可視化して」という雑プロンプトでお願いしてみました。最初にPythonで書いてきたので「HTMLにして」と。
HTML版で図にはなったけど、アニメーションも欲しい。
「アニメーションしない」というと、アニメーションをしないバージョンを作ってきました。元からアニメーションしてないんだけど。
このように、所望の挙動をしていない問題を伝えると、その挙動をしないようにしてという指示なのかと、なんか工夫してくることはよくあること。それ自体は仕方ない。
けど、「アニメーションして」というと、ノードを結ぶ線が消えてます。
このとき、「意図せず簡略化されてしまいました」にちょっとした不安。他のLLMで、意図せず消えたということある？と。
そして、修正してもらっても表示されず。
最終的に、変なところに線が引かれてよくわからなくなりました。究極可視化なのに。
アニメーション可視化->完全可視化->完全可視化確実表示版->究極可視化と育っていくのがいいですね。
そのときの言葉、「究極の誤差逆伝播可視化をご提供します」は胸が熱くなりますね！動かなかったけど。
あと、この配色にQwenらしさある。
GLM-4.7では、こう。
GLM-4.7で自宅コーディングエージェントが現実的に。日本語力も高く幅広く使える。 - きしだのHatena
毎回UIがちょっとずつ違う
「パストレーシングでのcgをhtml+javascriptでつくって」とやってみたんです。
そうすると、こう。青黒の画面。まあ、CG出力プログラムではよくあること。GLM-4.7も一発目は黒い画面でした。
そうこうすると、なんか黒い球っぽいものが。
CGのコード、これが大事ですね。レンダリングしたい物体がちゃんと画角におさまってる。
次こそ！と思ったら、また表示されなくなる。
そのときの反応が「requestAnimationFrame(renderLoop) の呼び出しを忘れていました」ってそんなことある？二回目。
そしたら、キター！これレンダリング途中じゃなく、レンダリング完了したところです。
そして、全体を表示してほしいと、状況を伝えると、次はこれ。
レイトレのコードを開発する過程で、ここまで来て真っ暗に戻るというのは考えづらい。
ちょっと、コード作業があてにならんなというところでエラーが出て終了。
上記のキャプチャ、よく見るとUIの文言などが安定してないですね。そのあたりで修正作業の不安定感が出始めていました。
ちなみにGLM 4.7
コーディングがあてにならない
これ、GGUFがだめなのかなと、MLX版でやってみました。
最初から何かが表示される。
角に黒いなにかが表示されるだけ、と伝えたらこれ。何か見えてる！
これは幸先いいぞと思ったら黒画面・・・
レイトレのコードを開発する過程で、ここまで来て真っ暗に戻るというのは考えづらい(2回目)。
何回か修正依頼してたらログを吐くようにしたバージョンを出してきた。どうやらhitにatという関数がないっぽい。
30行前に自分で生成コードを書いたオブジェクトの呼び出し関数を間違えるのどうなの、
それはともかく、なんか動くようになった。。。
けど球体どこ・・・
ところで、UIもまた揺らいでますね。例えば「サンプル数」->「サンプル数(品質)」->「品質(サンプル数)」->「サンプル数」とか。
結局、こういった揺らぎがコードでもおきてたのでした。
58tok/secで出てくるコードを眺めながら、「毎回違わんか？」と思って確認したら毎回違う・・・
いくつかのバージョンでクラスや関数をまとめたものがこちら。
クラスがRayクラスさえ消えていたり。そしてEllipsoidクラスが生えてる。その後Rayクラスが復活して、しばらくするとEllipsoidクラスが消えた。
黒まる3つのあと何も表示されなくなったのは、Rayクラスを消したからだったようだ。そして、復活しても何も表示されないのは、新たなバグを生み出したから。
つまりまた、なぜか消えてる。
関数もchangeSampleがupdateSamplesになり、すぐ消え、renderはrenderLoopになり、最初から最後まであるのはtraceとclampくらいか。
要するに、ごっそり最初から書き直してる。なので、「今まで動いてた」が通用しない。ひとつずつバグを潰して、ということにならない。
そりゃ「意図せず簡略化」や「呼び出しを忘れていました」も、そんなことある。
もちろん、今回はチャットUIでやっていて毎回書き直しだから、コーディングエージェントでファイルの一部編集ならこういうことは起きにくいというのはあるかも。
けど、HTMLで画面配置をいじるとタグをまとめて書き換えるときがある。そのとき、ちょっと文言やデザイン、UI要素が変わるということは起こりそう。リファクタリングだと、それっぽい別実装になりそう。
あと、コーディングエージェントのセッション中の指示を忘れそう。「Javaプロセスを殺すな」と言ったその3ステップ後にJavaコマンドを殺すコマンドを入力していた。
ところでこんなJavaScript解析ツールをClaudeさんに作ってもらってます。
最初はQwen3-Coder-Nextに作ってもらってたんだけど、JavaScriptは
コード中に</script>があるとスクリプトを抜けて処理が終わってしまう仕様で、毎回ひっかかるのであきらめた。
これ「</script>が入ると動かないので修正して」として出てきたもの。
一度は動いたけど、それを修正したらまた</script>だらけになっていた。これも全部書き換えなおす挙動のせいともいえる。よく見ると、表示の文言は毎回すこしずつ変わっていた。
Qwen3-Coder-Nextのアーキテクチャ
なんでこうなるかというと、これはQwen3-Nextのアーキテクチャが原因じゃないかと思います。
Qwen3-Nextは、TransformerのO(n2)を回避するために、O(n)で計算可能な線形アテンションを採用しています。
その線形アテンションとして選んだのがGated DeltaNet。
Qwen3-Next: Towards Ultimate Training & Inference Efficiency
Gated DeltaNetを基本に、4回に1回はTransformer系(Gated Attention)を使うというものです。
同じく線形アテンションを採用したNemotron 3はMamba2を使ってるけど、似た感じでMamba2 x 3 + Attentionというグループを重ねてるみたい。
NVIDIAのLLM、Nemotron 3 Nanoは賢いけどコーディングには向かないかも。Mamba 2の特性が悪く出てる？ - きしだのHatena
実際のQwen3-Coder-Nextのモデル構成を見ると、2進数で下二桁が11のレイヤーはself_attnを持つけど、それ以外はlinear_attnです。これがGated DeltaNextということですね。
https://huggingface.co/Qwen/Qwen3-Coder-Next/blob/main/model.safetensors.index.json
では、線形アテンションで、Transformerがトークン同士を比較してO(n2)になっているのをどうやって線形に、つまりO(n)にするかというと、ざっくり言えば、やってきたトークンをそこまでのすべてのトークンと比較するのでなく、大きさ固定の一塊に対して処理をします。その大きさ固定の一塊にはそこまでのトークンの総合情報がある。そして、トークンを処理したあと、その一塊にトークンを混ぜ込めば線形時間で表現できる。
MambaなんかはTransformerと数学的に等価だと言ってるけど、実在の計算機での計算だと最初のトークンほど誤差が積みあがっていく。
線形アテンションには、そういった、最初に計算したトークンに誤差が積みあがっていく性質がでてくるはず。
これは、翻訳や要約、解説、対話など、多くの言語処理では問題ないけど、コーディングでは厳しそう。
TransformerのO(n2)問題は対処していく必要があって、Qwen3-Nextのチャレンジも大切で、アーキテクチャやトレーニングの改善で線形アテンションでコーディングもできるようになることには期待している。
