Qwen3が出ていて、14Bを中心にいろいろ試したのだけど、かなり使い物になって、日常的な用途ではこれでいいのでは、という感じもします。
4BでもGPT-4oを越えているという話もありますが、確かに単純な用途ではGPT-4oの代わりにしてもいいなと場面も割とありそうな出力です。さすがにちょっと込み入ったものだと4oだけど。
1.7Bなど小さいモデルも既存のモデルより使えるものになっていて、ローカルLLMの世界を変えそう。
解説動画も撮りました。
週間ニュースのまとめはじめました。
サイズとしては0.6B, 1.7B, 4B, 8B, 14B, 32Bと、MoEモデルの30B-A3B, 235B-A22Bです。
30B-A3Bが賢いというベンチマークだけど、コーディング用途だと14Bや32Bのほうがいいかも。MacならMLXで30B-A3Bは めちゃ速くていいけど。という感じでどのサイズにも用途があってすごい。
GitHub - QwenLM/Qwen3: Qwen3 is the large language model series developed by Qwen team, Alibaba Cloud.
Qwen3: Think Deeper, Act Faster | Qwen
ということで、14Bから1.7Bまで4bit量子化モデルをLM Studioで試していきます。
ブロック崩しを作らせる
14Bで「JavaのSwingでブロック崩しを作って」です。
なんと、一発で動くコードが生成されました。ウィンドウサイズだけ縦に大きく調整したけど、それだけ。
デフォルトでthinkingモデルになります。
thinkingなしで試してみます。
/nothinkを付けるとthinkingなしになります。
なんか、それなりに説明をしてから生成する傾向あります。Thinkingの名残かな。
ちゃんと一発で動きました。ただ、ボールが下向きに動いて始まって即ゲームオーバーになってたので、ボールの向きを変えてもらったりしました。
3月にGemma3やQwQで試したとき、Gemma 3もQwQも一発で作ってくれなくて、ChatGPTが一発で作ってすごいと言ってたのだけど、その意味ではほんとGPT-4o並みと言えます。
コーディングはQwQに軍配かな。Gemma 3は編集が続くと弱そう - きしだのHatena
8Bモデルで雑コーディングエージェントを試す
8Bの4bitを試してみます。
この雑なコーディングエージェントで試してみます。
LangChain4Jで雑なAIコーディングエージェントを作る - きしだのHatena
これ、JTableを使うとDefaultTableModelというのが必要になり、このパッケージがjavax.swing.tableなので、import javax.swing.*だけではコンパイルエラーになるというミスをLLMは起こしがちです。人間はIDEの自動補完なしでは書けないのだけど。
で、結果からいうと、コンパイルエラーを自力で解決して動かしていました。
8GB程度のVRAMがあれば、GPUオフロードを調整することで結構動いてくれると思います。
4Bモデルを試す
4Bの4bitモデルを試します。これが、ちゃんとした返答するんですよね。
「CQRSと関数型プログラミングの関係」を聞いてみてます。そうすると、まずCQRSとは、関数型プログラミングとはという言葉の解説から始まります。
そんで、まとめ。
これ、ChatGPTで聞いたときと同じ流れなんです。
ChatGPTの4o並みというのは、このあたりのことですね。確かに、ChatGPTに一回質問を投げたら終わりというような使い方だと、Qwen3 4Bでも使えそうです。大きいモデルのほうが安心感あるけど。
ChatGPTのほうが要点を的確にまとめている感じはあります。
だいたいにおいて、同じことでも小さいモデルは冗長に説明しがちで、余分なものをつけがちです。これは、大きいモデルのほうが返答を表すベクトルに最短距離で近づけるから、とえらい人が言ってました。
ブロック崩しは、こんな感じで謎のゲームができてたけど、一発で動いたのでヨシ。このサイズのコードを一発で動かすのすごいです。
あと、Tool Use(Function Calling)。
このサンプルを試してみます。
Gemma 3とLangChain4JでローカルLLMでFunction Calling - きしだのHatena
結構いけますね。これは成功だけを撮ってるけど、失敗も多いです。確実さを求めると8Bや14Bがほしい。
1.7Bは？
それっぽいこと返してきて恐ろしい。つまり人類の知識って1.3GBにおさまるんか？
※記憶のホログラム理論まさにそのままで、全ての記憶が全体に重ね合わせて記録されるので、一部が失われたりサイズが小さくなるとあいまいになっていくだけ、という話ではある。
ブロック崩しは、ぜんぜんブロック崩しじゃないものができました。
Tool Useも簡単なものなら動きます。ただ、/nothinkでのThinking抑制は全然効きませんでした。
コードはこちら。
https://gist.github.com/kishida/53863bd4e460baed0b99193e3b8674ad
上の図形操作は、同じことを延々くりかえしたりが発生してちょっとダメでした。4Bでもたまに勝手に操作を繰り返したりがあったけど、すぐ1.7Bはダメに。
Gemma3 4Bは、Qwen3 4Bと1.7Bの間で、ダメになることが比較的多かった。
MacならMLX版30B-A3Bも
ちなみにこのA3Bというのは、実行時にActivateされるのが3Bという意味のようです。なので、実行時に必要なのは3Bだけ。
ということで、ぜんぶVRAMに載せないといけないので30Bが乗り切らない独立GPUより統合RAMのほうが相性がいいです。実行時の計算量は3Bモデルと等価になるので。そしてMLXのエンジンがうまく最適化されている。
ということでApple SiliconのMacでメモリ32GB以上乗ってるなら、30B-A3BのMLX版です。40token/sec出てました。GGUF版だと20token/secです。14BはMLXで17token/sec、GGUFで13token/secなので、それよりは早いけど。 RTX4060 Tiが14B 4bitで22token/secで、それより速い。4Bが50token/secだったので、それよりは遅いけど、近い数字です。30B-A3BはCPUオフロードが必要で10token/secしか出ませんでした。
ただ、パドルがペルだったり、14Bでブロック崩しをtetrisだと言ったり、なんか日本語のトークン化がおかしい気配があるのが、ちょっと不安。要約や翻訳のように日本語能力が求められる用途にはGGUFモデルを使うほうが無難です。
MLX版Qwen3-30B-A3B、この速さ出る。すごい。
— きしだൠ(K1S) (@kis) 2025年4月29日
40token/sec。GGUFだと20token/sec。
14BだとMLXで17token/sec、ggufだと13token/sec。
ちなみにRTX4060tiだと22token/sec。30Bは10token/sec。。。MoEがMLXと相性よすぎか。
ただ、パッドがペルだったり、なんか日本語トークンおかしい気配ある pic.twitter.com/hZZAHDnxtc
しかし、30B-A3Bはブロック崩しが一発でまともに動いたことはないので、コーディング能力は14Bのほうがあると思います。
まとめ
14Bでかなり使えます。単発のコード生成はかなりいける。単発の質問ならGPT-4oの代わりに十分なりそうです。4Bでも簡単な応答ならGPT-4oの代替になりそう。ただし、4oだと簡潔に答えることを、いらんこといっぱい書いてきます。
1.7BでTool Useに割と対応できるので、LangChainなどのAIプログラミングをローカルで試したいという場合に、ハード要件がかなりさがるのでおすすめ。
確実性を高めたければ4Bや8Bが欲しいところ。
そしてMacでの30B-A3BというMoEモデルの速さ。
コーディングエージェントには32Bでも厳しいかもしれないけど、普通の業務ワークフローを自動化する用途だと14Bあれば十分かもしれない。ファインチューニングすれば4Bでもいけるかも。
1.6Bはツール呼び出しが不安定なので、エージェントには向かないけど、これもファインチューニングして特定用途には使えそう。ただ、thinkingの抑制が効かないのでちょっと使いづらいかも。
とはいえ、普通のPCで動くローカルLLMにちゃんとした用途ができそうという期待が持てました。
しかし、2年前には14Bのモデルで「日本の首都は」に「東京」と続いたらえらいというくらいだったのに、進化したものだ。
メモリを追加して64GBになったので動かせなかった言語モデルを試した - きしだのHatena