ローカルでコーディングエージェントするために使えるLLM

ローカルでコーディングエージェントするために使えるLLMもまとめておきます。

モデルと傾向

いまコーディングエージェントで使えるかなというモデルはこのくらい。

モデル	パラメータ	アクティブ	アテンション	層	埋め込み
Qwen3.6	27B	Dense	線形	64	5120
Qwen3.6	35B	A3B	線形	40	2048
Gemma 4	26B	A4B	スライド	30	2816
Gemma 4	31B	Dense	スライド	60	5376
Qwen3.5	122B	A10B	線形	48	3072
Step 3.7 Flash	198B	A11B
MiniMax M2.7	230B	A10B	フル	62	3072
MiniMax M3	428	A23B	スパース	60	6144
DeepSeek V4 Flash	284B	A13B	スパース	43	4096
MiMo-V2.5	310B	A15B	スライド	61	4096
GLM-5.2	744B	40B	スパース	79	6144
Kimi K2.7	1T	32B	スパース	61	7168

※ 2026/6/19 Kimi K2.7、GLM-5.2、MiniMax M3を追加

とはいえ、Qwen3.6-35Bはちょっとコードが書くのが下手、Gemma 4はコーディングエージェントとしての動きが弱い、GLM-5.1は重すぎ、というのはあります。候補にできるかな、くらい。

リリースされていてもGGUFやMLXが対応していなくてローカルで使いにくいものもありますが、ここに上げたものは実際に試せたモデルです。

現実的には、300Bより大きいモデルは生成は速くても、コーディングエージェントで数万トークンになったプロンプト読み込みに5分かかったりするので、そのくらいが限界だと思います。

また、30Bくらいだと知識量が足りないので、細かいAPI呼び出しを間違えたりしやすくなるので、完全にこれだけというのは難しいです。

新しいコードを書くときは30Bくらいのモデルで試行錯誤をやりやすく、バグ修正は200Bのモデルで、さらに難しい検証などはGPTやClaudeを使う、のような階層的な使い分けが大切かと思います。
ローカルLLMコーディングエージェントは重くて賢いモデルと軽くて新しいモデルを組み合わせるようになるんでは - きしだのHatena

LLMの構造

LLMは基本的にアテンション+FFN(ニューラルネット)でできてます。アテンションはパラメータ数は少ないけど計算が重い、FFNはパラメータ数が多いけど計算は単純です。アテンションは文章の読み方、FFNには考え方と知識を扱います。

アテンションの種類

アテンションはトークン数nに対してO(n²)なので、いろいろ削減の工夫がされてます。フルはそのままO(n²)でやるスパースとスライドはnの部分を減らす。スパースは間引く。スライドは一部領域をみるなので、スパースは全体をみれるけどちょっとあいまいになる。スライドははっきり認識するけど局所的になる、みたいなイメージ。線型は計算を工夫してO(n)にする。ただ、理論的には等価だけど実際には離れたところほど誤差が出てしまう。なので、たとえば長いコードを少し修正して出し直させると、1行ぬけてたり、ちょっと変わってたりする。

FFNの種類

FFNではDenseとMoEがあります。 Denseはふつうに全部のパラメータを使うモデル。
MoEは小さいFFNがたくさんExpertとして用意されていて、実行時にはいくつか選んで使うというものです。MoEで実際に使われるパラメータ数がアクティブパラメータです。

アクティブパラメータ数は推論の速さや考えの深さにつながります。
Qwen3.6-35B-A3BとGemma 4 26B-A4Bがわかりやすいですが、Qwen3.6のほうが総パラメータ数は多いけどアクティブパラメータが少ないのでGemma 4より速く、Gemma 4は総パラメータ数は少ないけどアクティブパラメータ数が多いので間違いが少なくコード書けます。

Denseであれば、総パラメータ数=アクティブパラメータ数なので、思考が深く、Qwen3.6-27BがQwen3.5-122B-A10Bと勝負できるくらいのコーディング力になったりします。さすがにQwen3.5-122B-A10Bのほうが総合力で勝つのだけど。

量子化

LLMは、学習時には精度が必要だけど、推論時にはそれほど精度が必要ありません。
なので、16bit浮動小数のパラメータを、8bitや4bitに精度を落としてもサイズが減った割には性能が落ちません。

また、アテンション部分では精度が必要ですが、FFNではあまり精度が必要ないので、アテンション部分だけ精度を高めて、FFNは精度を落とすというようにうまく量子化すれば、性能を落とさずにサイズを減らすことができます。

Q4_K_Mなど、4bit量子化くらいまではほとんど性能が落ちないので、ローカルでLLMを使う場合にはそのくらいの量子化モデルが使われます。

うまくやれば、Q3くらいまで性能があまり落ちません。

Updated: Qwen3.6 GGUF evals

I added models from bartowski and lm-studio. All good overall.

I also tried going below Q2_K_XL, but those quants are not usable. Most could not finish the benchmarks in a reasonable time because they generated way too many tokens. Endless… pic.twitter.com/QcPWZYcVXx
— Benjamin Marie (@bnjmn_marie) 2026年4月26日

LLMでのボトルネックはメモリ帯域です。なので、性能とのバランスを考えると、Q6やQ8を使う理由はあまりありません。

ただし、コーディングエージェントには性能が足りないのでここで上げてませんが、10Bより小さくなると量子化の影響が出やすくなってくるのと、そもそもパラメータ数が少ないのであまりメモリ削減する必要もなくなってくるので、Q6やQ8も候補になります。

実際にどのように量子化されているかは、GGUFの中身を見るとわかります。
ggufの歩き方 - LLMの構造をみてみる - - きしだのHatena

読み込み

SoCではなくdGPUを使う場合、CPUとGPUの振り分けも大事になります。
Denseモデルの場合は層をどれだけGPUに乗せるか単純に考えればいいです。
MoEの場合は、アテンションはなるべくGPUにのせて、FFNをCPUに乗せるほうがいいです。
そのあたりの設定はこちらに。
Qwen3.6-35B-A3Bの動作環境と設定、出力速度まとめ - きしだのHatena