【推し】筆者が利用しているおすすめローカルLLMランキング①【2026年後半版】
はじめに
筆者が実際に利用しているローカルLLMを定期的に紹介するシリーズ記事です。
前回(2026年前半)はこちら。量子化等の基本的な選び方も紹介しています。
しかし、2026年後半はランキング形式をやめます
ゲーミングPCで動作するパラメータ規模のLLMにおいて、Google Gemma4 / Alibaba Qwen3.6という二大巨頭が目立ちすぎた結果、マイナーモデルがあまり頑張らなくなりました。(実際はチラホラあるのですが、同規模帯で性能を超えられないようです)
一方で、これらモデルのパフォーマンスを改良したものや、より賢いモデルで作成した学習データを利用し、gmma4/qwen3.6をベースにしたカスタムモデルがコミュニティの流行りだと思います。
なので、筆者が実際に主利用している、Gemma4系とQwen3.6系のモデルの紹介をしたいと思います。
Gemma4系
海外ではQwenと比べてイマイチ人気がありません。理由は、(ツール呼び出し等の)エージェント性能とコーディング性能が若干劣るからです。
しかし日本では、圧倒的な日本語性能を持っているので、IT技術者以外(の日本語利用者)であれば、Gemma4が最も良い選択だと思います。
Gemma4には、Google公式が公開している高度な量子化であるQAT版と、性能を落とさず2〜3倍以上の高速化を実現するMTP版があります。もちろん、QAT+MTPは同時に利用可能です。
※ ただし現状では、LM Studioやollamaで簡単にGemma4 MTP版を利用できません。Unsloth Studioやllama-server(llama.cpp)等で直接動作させる必要があります
Gemma4 31B
現状のゲーミングPCで動作するLLMの中では最高性能ですが、大量のVRAMが必要になります。筆者のRTX5060ti 16GB×2=32GB環境でも、256kトークンでの運用はできません。QAT+KVキャッシュQ8_0で128kが上限でした。
筆者はunsloth版のqat-31Bを利用しています。
※ ただし、「ollama pull」コマンドではエラーが出るので、個別にダウンロードした後にollamaモデルファイルを作る方が無難でした。

RTX5060ti 16GB×2枚+Linux環境での通常のollamaでは20〜30 token/s程度ですが、
強引な手法で、QAT+MTP+split-tensorを有効化し、70〜90 token/sで運用できています
Gemma4 26B MoE A4B
多くのゲーミングPCユーザーにとって最も適しているモデルです。26Bという大パラメータですが、選択的に4Bしか利用しないため、演算速度において大きな利点があります。
多くの環境で安定的に動作するため、筆者がメイン利用しているモデルです。
CPU+GPUのハイブリッドやCPUオンリーであっても、チャット用途なら、実用(10〜50 token/s)利用できます。つよつよCPUならば、CPUだけでも30 token/s出ます。
一般に利用されるのは、Q3〜Q4_K_M等の量子化モデル、またはQAT版を利用する事になります。
ただし、llama.cpp(またはgguf変換)の問題・バグの可能性がなくもないのですが、同じ4bit量子化でも、性能はQ4_K_Mの方が良いという報告が多いと思います。筆者もそう感じます。
QAT版 < Q4_K_M
※ 31Bと異なり、26Bは、4Bパラメータ動作の超軽量モデルなので、(ミドルクラスのGPUでは)並列処理やMTPで大きな差が出ません。または逆に遅くなる事もあると思います。実際に、現バージョンollama付属のllama-serverでは遅くなります。

例:RTX 3060 12GB×2(Windows11、MTPなし、split tensorなし)

例:RTX 5060ti 16GB×2(Linux、MTPなし、split tensorなし)
上手くCPUへのオフロード調整すれば、RTX5060ti 16GB VRAM(1枚)でも、128k程度なら、安定した50 token/sを達成できます。
ただし、ollamaではオフロード調整が難しいので、LM Studioでの実行がおすすめです。
※ 上述31Bで利用した「強引な手法」であれば、直接llama-serverの引数をコントロールできるので、ollama + OpenWebUIでも可能です
Gemma4 12B
ミドルクラスのゲーミングPCにおいて、もう一つの選択肢が12Bです。MoEではないので26Bよりも動作速度が遅くなりますが、モデルの重みデータの総量(静的データ)が小さいので、12GB〜16GB VRAMであれば、ほぼフルスペックで動作します。
8GBのVRAMでも、量子化サイズとコンテキスト長を調整すればGPUに収まります。
ただし、快適といってもdenseモデルなので遅い(重い)です。VRAMにすべて乗った場合は、26B A4Bの方が圧倒的に速いと思います。
また、総合力では26Bの方が高性能だと思いますが、分野によっては12Bの方が賢い事もあります。

RTX5060ti 16GB×2

RTX3060 12GB×2
筆者(ollama)環境では、並列やMTPでの高速化は見込めないので、あまり使い勝手は良くありません。1GPUの方が速いかもしれません。
モデルサイズは小さいので、(VRAMではなく)システムメモリが絶対的に足りず、26Bが動作しない環境の選択肢になると思います。
※ 検証していませんが、筆者のミドルクラスGPUの12B動作はイマイチですが、8〜12GB VRAMの小さなVRAMでも、VRAM帯域幅が強力なハイエンドGPUならば、より良い結果を出す可能性は高いと思います。筆者環境では明らかにGPU電力利用率が悪いので、大きなボトルネックが発生しています。演算可能なCUDAが余っているのに転送が追い付いていない状態です。
Gemma4 E4B
このクラスからは、エントリークラスのゲーミングPCやノートパソコンでもなんとか動作するようになります。
同じ量子化度合いでも、ファイルサイズがGemma4 12B版よりも大きかったりしますが、VRAMへ読み込む必要のないデータを含むので、最新のollamaやLM Studio等の対応した動作環境では、より省VRAMメモリで動作します。
E4Bや、8Bあたりのパラメータモデルが、汎用性もある実用的な最小のモデルだと思います。Gemma4にはE2Bという更に小さなモデルがありますが、シンプルな会話用途には利用できても、論理的判断は少し難しいと思います。
※ E4Bとありますが、4Bではなく、その実(ファイルサイズ)は8Bクラスなので、他と比べる場合は8B前後(QwenならQwen3.5 9B)がライバルになります。

東大の入試問題であっても、リーズニングありだと正解までいきます

ただし正解まではたどり着けず。(リーズニングなし)
Qwen3.6系
Qwenの弱点は明らかで、日本語生成を(時々)失敗する事です。特に簡体字(中国語)を出してしまうのは分かりづらいので少しストレスです。日本語での要約や編集作業であるなら、Gemma4に全く敵いません。
しかし、ツール呼出し性能・コーディング性能、チューニングの使い勝手が良いこともあり、日本語が関係ない世界のコミュニティーでは、多くのAIエージェント・コーディング向けのカスタムモデルが日々作られています。
筆者もベースモデルはほとんど利用せずに、カスタムモデルを利用しています。
賢さ順
Gemma4の場合は、パラメータ規模の大きさと賢さが比例関係にあるのでわかりやすいのですが、Qwenは少し異なります。賢い(高性能)順に並べると、下記になります。27B(dense)と35B(MoE)が逆転している事に注意が必要です。
Qwen3.6 27B > Qwen3.6 35B > Qwen3.5 9B > Qwen3.5 4B
Qwopus3.6-27B-Fusion
Qwen3.6-27Bベースのモデルです。ただし、Gemma4だと31Bがライバルdenseモデルなので、24GB〜32GBのVRAMがないと快適に利用できません。
Qwopusは新しいモデルではなく、定番人気モデルの一つです。名前の通り、Claude Opusのリーズニングを主に学習したものです。
最近、通常版とコード版をマージしたモデル(Fusion)が公開されましたが、なかなかの安定性だと思います。
※ Qwen3.6は、Gemma4と異なり、LM StudioやOllamaでMTPを利用可能です。ただし、1.5倍程度にしかなりません。

Gemma4-31Bと同じ手法の改造ollama(MTP+split-tensor)
Ornith-1.0 35B
Qwen3.6 35B A3Bベースのモデルです。MoEなので、Gemma4-26Bとコンパラです。Qwopusと同様に、定番の人気モデルです。9B版もあります。
A3BのMoEなので、つよつよCPUとシステムメモリに余裕があれば、CPU動作でも十分戦えます。
Qwopusと同じく、AIエージェント・コーディング向けのモデルです。



Gemma4 26Bは(llama.cppで)MTPを上手く扱えないのですが、Qwen3.6 35Bでは、1.5倍程度の効果がでます。しかし、ハイブリッドだとあまり効果がありません。
Macaron-V1-Tall 35B
最近公開されたモデルですが、期待は大です。
まとめ
最近は、GLM5.2やK3等のオープンではあっても家庭(のゲーミングPC)では物理的に実行できない巨大モデルの公開が話題になっていますが、全く関係のない事ではありません。
自由で高性能なモデルがオープンに公開されればされるほど、それらは研究や学習に利用され、より小型のモデルの性能を底上げします。
たとえば、Qwopusは確かにOpusの結果を利用していますが、そのまま利用できるわけではありません。商用サービスのリーズニングは暗号化・改竄(ガードレール解析や悪用を防ぐため)されているため、そのままでは学習に効率よく利用できず、性能低下を引き起こします。
一方で、オープンモデルはそのまま出力されるため、コミュニティーの学習や新モデル作成に大きな利点があります。
オープンモデルがクローズドのフロンティアモデルに匹敵するようになったのであれば、さらに高性能な小型・メディアムモデルの登場も今後加速していくと思います。
以下、関連する記事の【PR】です
