NVIDIAのLLM、Nemotron 3 Nanoは賢いけどコーディングには向かないかも。Mamba 2の特性が悪く出てる?

NVIDIAから新しいモデル、Nemotron 3 Nanoが出ていました。30BのMoEでアクティブパラメータは3B。つまり30B-A3Bです。
試してみたら、かなり賢いんだけど、コーディングの長いやりとりをしてたら過去のコードをうろ覚えになってて変な挙動をしてました。
どうやら、Transformerの代わりに使ってるMamba 2だとそういう挙動になるみたい。自信がないので、こうやって書いたら、だれかが間違いを指摘してくれるはずメソッド。

追記:30Bモデルの主戦場になるのは、言語処理的な単機能部品だと考えると、長いやり取りは不要なので、かなり強いモデルではないかと思います。また別にブログかきます。たぶん。

Nemotron 3

Nemotronはこちらにブログが。
Inside NVIDIA Nemotron 3: Techniques, Tools, and Data That Make It Efficient and Accurate | NVIDIA Technical Blog

30B-A3Bということだったので、Qwen3 30B-A3Bと同じアーキテクチャなんかな?と思ったりもしたけど、Q4_K_M量子化のサイズが30Bなのに24GBあって、Qwen3は18Bだったので全然違いそう。

で、ブログを見ると、どうやらTransformerの代わりにMamba 2というのを使ってるみたい。
Mamba 2とMoeの層が全部で23層あって、3層に一回くらいMamba 2とMoeの間にAttentionが入ってる。
Nemotron 3 Nanoアーキテクチャ

Mamba 2というのは、O(n2)なTransformerと等価な計算をO(n)で線形に計算できるようにものらしい。
PLaMo翻訳でも使ってますね。

これをNVIDIAの4bit浮動小数、NVFP4で学習したというモデル。

日本語は?

小説を出してもらったら、それなりの長さの物語を自然な日本語で書いてくれました。

日本知識

奈良になんで都ができたか聞いてみたら、結構くわしく説明してくれました。
正しいかどうかようわからん。けど違和感あることは書いてなさそう。
話題として出してくる項目や構成など見ても、結構いい感じです。

要約

この記事の全文を渡して要約してもらいました。
IT土管はAIにまかせて、人間は情報に価値をのせよう - きしだのHatena

だいたい文意は拾えてそう。
要約結果画面

あと、宮沢賢治の「注文の多い料理店」を400文字で。
だいたいの文章は抜き出せてるけど、物語の筋はよくわからないことに。
注文の多い料理店の要約結果

面白いのが、Thinkingの中で素案を出してカウントしてるところ。律儀だ。
Thinkingで文字数カウントしている様子

論理的思考

「64歳以上であれば100円、64歳未満は1000円」を整数四則演算で実現してもらいます。
Reasoningモデルで、1分ちょい考え込んでいました。ループに入ってないかなと思ったけど、ちゃんと答えが。

price=1000900a64が答えです。127歳までは正しく計算できます。

14BのMinistral 3だけでなく106BのGLM 4.6Vでも思考が無限ループしてたのを考えると、妥当な答えが出るだけでえらい。
Ministral 3は性能はもう一歩だけど存在が大切。文字読み取り性能は高い - きしだのHatena
Z.aiの新しい画像言語モデルGLM 4.6Vよさそう - きしだのHatena

128歳で-800になると文句を言うと、3分半考えて、次のような答え。

変数を使ってますが、展開すれば四則演算だけで計算できます。

長考してループに陥らずちゃんと答えを出すのはすごい。
あと、じゃあいつも長考するかというとそうでもなく、小説や奈良の話では2-3秒の思考でした。 思考時間の調整がうまくいってそう。

コーディング

いつも通りブロック崩しを。1ヶ所、手で修正したのだけど、ちょっとボールの動きはおかしいけど、それなりのコードができてます。
ブロック崩し動画GIF

ただ、まず気になったのが、最初にクラスごとにわかれたソースを出したあとで1ファイルにまとめてきたんだけど、たとえば最初のBallクラスの末尾はこれ。
ソースコード

そしてまとめられたコードでのBallクラスの末尾。
ロジックは同じだけど、publicが消えていたり、変数名が違ったり、メソッドが増えてたり、微妙な違いがあります。
ソースコード

で、動かしたら例外が出たので貼り付けると、「あなたのコード」と人ごとのような対応。そして、コードの存在を忘れて、「例としては次のような書き方」って言ってます。
ランタイムエラーへの反応

そのあとのやりとりでも、ちょっと要領を得ない感じがありました。
なんか、見えているコンテキストが狭そう。

で、例外が出てたのはここのnew Colorで、BRICK_ROWSは5なので150+4*30=270になって、ここでは255までしか指定できないというもの。

for (int r = 0; r < BRICK_ROWS; r++) {
    for (int c = 0; c < BRICK_COLS; c++) {
        int idx = r * BRICK_COLS + c;
        bricks[idx] = new Brick(
                ...
                new Color(0, 150 + r * 30, 255) 
        );
    }
}

なんだけど、「期待しない型や値を渡しています」と説明が。それだとコンパイルエラーで、例外にはならないというのに。
ということで、エラー対応も苦手かも。

コードを書く能力はあるけど、エラー処理がにがてで、なにより離れたところのコードがうろおぼえっぽい挙動をするので、コーディングエージェントには使えないかも。

まとめ

なんか調べたりChatGPTやGeminiに聞いてると、どうも離れたコンテキストを圧縮していくような挙動になっているらしく、どんどんうろおぼえみたいになるらしい。
これは、長い範囲を正確に把握する必要のない要約や翻訳、離れた過去はうろおぼえでもいいような対話では問題なく、むしろ長い対話を適切に行えると思うのだけど、離れた部分でも正確に扱える必要のあるコーディングでは使えないんじゃないかという気がした。