AIプログラムの開発、つまり、AIにコードを書かせるのではなくて、LLMを呼び出したりRAGを実装したりエージェントを作ったりといったAIを組み込むプログラミングの演習をしたいときに、参加者のPCに十分なリソースを前提とできないことは多いと思います。

Java AIプログラミング記事でQwen3 1.7B Q4_K_Mを選んだ

先月gihyo.jpの連載で、「JavaでAIプログラミングをはじめよう」という記事を出しました。
「JavaでAIプログラミングをはじめよう」という短期連載をgihyo.jpで出しました - きしだのHatena

そのときに、読者のPCにGPUが載ってたりMacであることだったりは前提にできないので、なるべく必要なリソースが少ないモデルを選ぶ必要があって、最終的にQwen3 1.7BのQ4_K_Mを選びました。初回に、LM Studioとあわせた導入方法を載せてます。導入部分はJava関係なく読めるはずです。
JavaでLLMにアクセスしてみよう | gihyo.jp

Qwen3 1.7BのQ4_K_Mだとモデルのファイルサイズが1.2GBで1.5GBくらいメモリに余裕があれば動きます。たぶん、コア数は4コアくらいはあったほうがいいです。

サンプルプログラムを動かすときに求めるLLM能力は指示追随

あと、こういったプログラムを試すときにLLMに求める能力は、知識量やハルシネーションの少なさではなく、指示追随性です。システムプロンプトに書いた指示にしたがってくれるかどうかが大事。
重要なのが、ツール呼び出しです。Function CallingやMCPを動かすときに、安定して動いてもらえないと、プログラムが悪いのかプロンプトが悪いのかといったことが判断できない。

最初はQwen3 4BのQ2Kで試していて、これもファイルサイズが1.7GBくらいでリソース消費が少ないんですが、ちょっと動きが安定してませんでした。
量子化は3bitあたりから性能が劣化して、Q2_Kになるとかなり劣化することをこの記事を見ていたので、これはアホになった4Bよりまともな1.7Bのほうがよさそうと思って1.7BのQ4_K_Mにしました。
GGUFって結局どのサイズ選んだらいいの？？

ただし、プロンプトが長いときの動作はあてにならなくて、Qwen3は/no_thinkを入れるとthinkingを抑制できるんですが、Function CallingやMCPなどでシステムプロンプトが長くなっているときには、1.7Bはぜんぜん効いてくれませんでした。

実際に開発をするときはQwen3 14B Q4_K_M

じゃあちょっといいマシンを使って実際に開発するというときにリソース消費少ないなかで何がいいかというと、Qwen3 14B Q4_K_Mになります。
あとで書きますが、アプリとしての使用感を見るには本気モデルを使うほうがいいのだけど、単にコードが正常に動くことを確認したいなど開発作業をまわすとき、特にユニットテストのように頻繁に呼び出すときに課金を考えたくないという場合にリソースの負荷が少なく動作に安心感があるのがQwen3 14B Q4_K_Mという感じです。

Qwen3でも32Bになるとちょっと重い。特に、これはMoEではないので、動作も重いです。Q3とかQ2にするなら、Q4で動く14Bがいいです。8Bでもいいんだけど、なんだかんだで動かすときに推論力も欲しいので14Bに。じゃあQwen3 30B-A3Bはどうかというと、動かしやすい量子化を選ぶとちょっと関数呼び出しの失敗が増える感じがします。
GPT-oss 20BはXMLの扱いに失敗が多くて、不安定です。Gemma 3はオープンウェイトモデルでは日本語が一番流暢なのだけどツールの利用が苦手。
コーディングエージェントなどを作る場合にはDevstral Smallを使いたくなりますが、ツール呼び出しができません。
手元で動かすとすると、現状ではQwen3 14B Q4_K_Mが一番消費リソース少なく性能よく安定していると思います。