いままでの流れ
モデル
実際の比較
量子化の中身
ハードウェア
高速化技法
ローカルでコーディングエージェントするために使える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 |
| MiniMax M2.7 | 230B | A10B | フル | 62 | 3072 |
| DeepSeek V4 Flash | 284B | A13B | スパース | 43 | 4096 |
| MiMo-V2.5 | 310B | A15B | スライド | 61 | 4096 |
| GLM-5.1 | 744B | 40B | スパース | 79 | 6144 |
とはいえ、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(n2)なので、いろいろ削減の工夫がされてます。 フルはそのままO(n2)でやる スパースとスライドは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
— Benjamin Marie (@bnjmn_marie) 2026年4月26日
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
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
埋め込み
エンベディングの幅を書いてますが、これはLLMのモデル内で情報を扱う単位です。
基本的にはアクティブパラメータに比例する設定になっています。
レイヤー間で伝送されるデータは、トークン数 x エンベディング幅なので、マルチGPUでの性能劣化を考えるときにはちょっと気にしたほうがいい数字です。
2023年からの3年でおうちで動くLLMはどう変わったか
ちょっと、おうちで動くLLMを振り返ってみます。
年間を通してではなく、毎年の3-4月くらい、16GB VRAMのGPUで動くくらいのモデルがどんな状況だったかをみてまとめるとこんな変遷
動いてえらい(2023)->返答がまとも(2024)->返答が使える(2025)->こだわらなければ使える(2026)
2023「動いてえらい」
最初に動かしたのはChatRWKVというモデルですね。TransformerではなくRNNを使うモデル。
おうちの8GB VRAM GPUでChatRWKVと会話する - きしだのHatena
こんな感じ。「寿司は好き？」って聞いたら英語でそれっぽい返事してくれてる。
いろいろ出てるのはデフォルトの文章で、このように会話形式の文に続けることで同様に会話してくれるんではないか、という作戦。チャット向けにファインチューンされてるわけではありません。
基本的に、海外のモデルは日本語を理解するけど出力しませんでした。
で、これはRinna社が開発したモデルで、ちゃんと日本語で会話ができています。
GPT-NEOXというアーキテクチャで、名前からもわかるように言語モデルの種類としてのGPT、つまりTransformerです。
そして、対話ができるようファインチューンもされています。
このころは「対話ができて偉い！」「日本語でやりとりできて偉い！」「聞いたことを答えてくれて偉い！」という感じでしたね。
あと、モデル開発もちょっと牧歌的でした。しかし牧歌的であるがゆえにマネタイズにはつながらかったのだろうな。
2024「返答がまとも」
GoogleからGemmaが出てなんかまともなことを話してくれるようになりました。
単文レベルの答えしか期待できなかったのが、まともな文章を、それも日本語を特別に学習してないモデルが返してくれるようになりました。
ただ、「動くぞ！」という感激は過ぎて、かといって「使えるぞ」というにはまだまだという状況で、振り返るとそこまで盛り上がってなかった。
2025「返答が使える」
Gemma 3やQwen3が出ました。
特にQwen3は、使える出力をするようになりました。
Qwen3はローカルLLMの世界を変えたかも - きしだのHatena
Qwen3 4Bに「CQRSと関数型プログラミングの関係」を聞いてみると、まず「CQRSとは、関数型プログラミングとは」という言葉の解説から始まり、ちゃんとした説明が出力されます。
また、14Bは「JavaのSwingでブロック崩しを作って」で一発目でちゃんと動くブロック崩しを作りました。
Q4_K_Mのような量子化も普及して小さいサイズで十分な精度を出せるようにもなり、おうちでLLMを動かすということもやりやすくなりました。 2023年は8GB VRAMのGPUつかってたのだけど、3BのモデルがFP16で動くのでギリギリとかが、2025年なら14BがちょっとCPU使いつつ動くという感じに。16GBあれば余裕です。
2026「実際に使える」
Qwen3.6とGemma 4が出て、実際に使えるようになりました。
例えばこれはDeepSeek V4のテクニカルレポートをQwen3.6-35B-A3Bに渡して内容を説明してもらっています。
そして追加の質問をしても答えてくれています。
英語PDFの内容を確認したいという用途であれば十分に使えます。
新しいアイデアを形にしたい、という場合にはちょっと足りないですが、既存情報を解説してもらう、要約してもらう、翻訳してもらう、といった、新しい考えや知識を付け足す必要がない用途であれば実用できます。
ブロック崩しもこんな感じに。
LLMの推論を速くする投機的デコードMTPは想定ユースケースに近いかどうかが重要？ - きしだのHatena
RPGも簡単なプロンプトで複数のモンスターの描画まで行って作っていました。
Qwen3.6-27BにRPGを作ってもらったらすごすぎた - きしだのHatena
1800行のHTMLになったのですが、これをJavaに移植もちゃんとやってます。
2025年のGemma 3やQwen3では、使える出力をするものの、じゃあどこで使う？というと困る程度でしたが、Gemma 4やQwen3.6では1～2往復のチャットでおさまりそうなやりとりや、単機能のアプリケーションであれば十分に使えるというところまで来ています。
ローカルLLMを動かすハードウェア
LLMを動かすハードウェア、軽くまとめておきます。
SoC
LLMを動かそうとしたら、まず候補にしたいのはCPU+NPU+GPUのSoCが載ったマシン。
GPUカードのようなパフォーマンスは出ないけど、現実的な値段で大きいモデルが動かせます。
※ 追記(2026/5/14) 現状ではMacだけ普通で他は特別なマシンという感じですが、インテルも対応した今後は「パソコンを買ったらLLMが動かせる。せっかくLLM動かすならちょっとお金を足して30Bが動く程度にメモリ積もう」となるんじゃないかと思います。
Ryzen AI Max+ 395搭載の128GBのEVO-X2が48万円、と思ったら品切れ・・・
※追記
本家に「在庫たっぷり」と売ってあった。
※さらに追記
去年の11月くらいには30万弱で買えたんですよ・・・夏くらいには192GBとか256GBとか買えるようになるかなと思ってたんですよ・・・
GMKtec EVO-X2 AMD Ryzen™ AI Max+ 395 ミニPC – GMKtec JP
GB10が載ってDGX Spark互換のGX10が58万円。
Mac Studioの96GBが60万円。(128GB以上は注文できない状況)
インテルもようやくCore UltraでLLMが動くようになりました。32GBで22万円。
CPU+NPU+GPUなSoCとして他にはQualcommのSnapdragon Xシリーズがあるけど、「LLMを動かす」だとまだ物足りない様子。
Qualcommとしては、やっとPC用CPUが勝負になってきたと思ったらGPU勝負が始まってた、という感じになってますね。
GPU(32GB)
コーディングエージェントをターゲットと考えると16GBは足りない、コンテキスト長を考えると24GBも心もとない、ということで32GBで考えます。
RTX 5060 Ti 16GBを2枚挿すのが恐らく現状で一番安く20万弱で32GBを得ることができます。
インテルのIntel Arc Pro B70が32GBで22万5000円。
ファンレス版も。32GB VRAM搭載の「Intel Arc Pro B70」ビデオカード - PC Watch
しかしAmazonだと32万円ですね。
AMDのRadeon AI Pro R9700が25万円。
RTX 5090だと60万円から。
RTX Pro 4500も60万円
電源などあわせてそろえることを考えるとLLMの推論だけが目的ならSoC系のマシンを買うほうがよさそう。
大きいモデルを動かそうと思うと、メインメモリも増やして、いい感じの設定で動かす必要もあります。
動画生成や学習までさせるならRTX系は有力だけどDGX Sparkでもいい。
LLMの推論を速くする投機的デコードMTPは想定ユースケースに近いかどうかが重要？
Qwen3.6-27BのMTP対応GGUFがUnslothさんのところから出ていたので試してみたところ、出力内容によって性能変わったので、ドラフトモデルの想定ユースケースに近いことが大事かもしれない、って話
MTP(multi-token prediction)は、軽いモデルにあらかじめ3トークンくらい出力させておいて、本番モデルで確認して当たればラッキー、外れてもそんなに損しない、なので推論が速くなるよって仕組みです。
Multi-token-prediction in Gemma 4
で、UnslothさんがMTP対応のQwen3.6を出していたので試していました。
https://huggingface.co/unsloth/Qwen3.6-27B-MTP-GGUF
Qwen3.6-27Bは64レイヤーなので、本来はblk.63までしかないのですが、blk.64が追加されています。これがドラフトモデルですね。
で、「Javaの最新バージョンは？」と聞いて試してみました。
通常版は26.3tok/sec。
これがMTP版では28.8tok/sec
15%速くなりました！
でも、1.5～2.0x fasterってUnslothさんのところに書いてるので、ちょっと物足りないですね。 さっき見たように、ドラフトモデルは1レイヤーの簡素なモデルなので、幅広く学習してるわけではないと思います。なんらかの使い方を想定して学習してるはず。そして恐らくそれは日本語ではない。
ということで、「Please write Breakout game in Java Swing」と英語でJava版ブロック崩しをお願いすると32.6tok/sec。
通常版では25.9tok/secです。
つまり25%スピードアップ！
かなり変わりましたね。ということで、MTPはドラフトモデルの想定ユースケースに近い使い方のほうが性能が高くなりそうです。
ところで、いつも「ブロック崩しをJavaのSwingで作って」と日本語で指示すると簡素なブロック崩ししか作ってくれなかったのだけど、英語でお願いするとJavaScript版と同様のブロック崩しを作ってくれました。しかも、アイテムも出てくる！
速度比較用に同じプロンプトを2回流してますが、どちらも似たようなものができていました。
つまり、速度的にも内容的にも、最高性能を出そうと思ったら英語がいいと・・・
ところで、ようやくインテルからもLLMが動くCore Ultra出ましたね。
ggufの歩き方 - LLMの構造をみてみる -
ggufはLLM推論エンジンllama.cppの重みデータフォーマットですが、Hugging Faceではモデルの構造が確認できます。
ということで、Hugging Faceでモデルの構造を見てみます。
コードやアルゴリズムを見てLLMを学ぶというアプローチはよくみますが、実際のモデルの構造をみてLLMを学ぶというのもいいんじゃないかと。
モデルを探す
まずはモデルのリポジトリ
「モデル名 + GGUF」で検索します。
たとえばQwen3.6-27Bであればこんな感じ
モデルのファイルを確認
Files and versionsにいきます。
そうすると、量子化ごとにファイルがあります。大きいモデルだとファイルが分割されるのでフォルダにわかれています。
ファイルを見る
今回はQ4_K_Mを見てみます。多くのモデルでQ4_K_Mは提供されてるので、比較もやりやすいはず。
開いてみると、モデル名とかアーキテクチャとか書かれてますね。分割されてる場合は最初のファイルにこういったメタ情報があります。
https://huggingface.co/unsloth/Qwen3.6-27B-GGUF/blob/main/Qwen3.6-27B-Q4_K_M.gguf
モデルの全体像を見る
モデルの全体像も書かれてますね。
block_countはいわゆるレイヤー数です。実際にはblockの中が複数のレイヤーに分かれてるのだけど、だいたい「レイヤー」というとこのblock_countであらわされるblockを指しますね。
コンテキスト長もcontext_lengthとして書いてあります。
embedding lengthは、雑にいうとひとつの情報の単位です。モデル内に流れる情報は、このembedding lengthを単位として扱われます。27Bでは5128。
attention.head_countがアテンションを計算するときの分割数ですね。こうやって分割するのでマルチヘッドアテンションと言われるわけです。
あと、35BのようにMoEの場合はエキスパート数と推論時に使われるエキスパートの数が書かれてます。
https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF/blob/main/Qwen3.6-35B-A3B-UD-Q4_K_M.gguf
ちなみにアーキテクチャはqwen35moe。27Bではqwen35だった。
35Bではembedding_lengthは2048です。つまり、1単位の情報の精度が半分ってことになりますね。このあたりでも、27Bが35Bより「賢い」理由がうかがえます。
そのあとはトークナイザの情報とか。これは27Bも35Bも共通。
レイヤーの情報をみる
実際のウェイトのデータはTensorsのところから始まります。
最初はtoken_embed、トークンをエンベディングにするところですね。embedding_length x 24万になっています。
そのあとblock_count分のblkが続きますが、4つごとに要素が少ないですね。
Qwen3.5/3.6はGated DeltaNetと通常のアテンションを3:1でまぜたアーキテクチャになっています。要素が多いところがGated DeltaNetで、要素が少ないところが通常のアテンションということになります。
35Bを見ても、token_embedがembedding_length x 24万、そして4つごとに要素が少ないblkがblock_count分ならんでます。
あと、27Bでは精度がQ4_Kだけど、35BはQ8_0ですね。なので、データ量としては同じくらいになりそう。
レイヤーの中身をみる
じゃあまずGated DeltaNetになってるblk.0を見てみます。
attn、ffn、ssmと並んでます。Gated DeltaNetはState-Space Model、状態空間モデルの一種ということで、ssmはGated DeltaNetの層を表してます。
ffnはup/gate/downの組になってますね。LLMのFFNはこの３つがセットになってます。
で、ここを見るとattnやffnにはQ4_KやQ6_Kが使われてますが、ssmはF32で量子化されてないことがわかります。
Gated DeltaNetのような線形アテンションでは、O(n2)のアテンションを数学的に等価な計算でO(n)にしています。が、これは理論上で、実際に計算をすると誤差がたまっていきます。この誤差はどんどん蓄積するのでできるだけ精度が高いほうがいい、ということでssmではF32が使われているのですね。
また、ssmでのパラメータ数は24万。
ffnでのパラメータ数は8900万。
桁が2桁違うので、ssmで少々サイズが大きくなってもあまり影響がありません。他も、1次元のところはさらに桁が少ないのでそのままF32になってますね。
ffnでも、性能に影響がある部分は精度を高くQ6_Kにしています。Q4_K_MのQ4は、「最低がQ4」という感じですね。
このように、どこでどれだけ精度を高くして、性能を落とさずサイズを減らすかというのが、UnslothやBartowskiなど量子化やさんの腕の見せ所というわけです。
ちなみに、Q4_K_Sだと、Q6_KのかわりにQ5_Kが使われて少しサイズが少なくなります。
SはSmall、MはMediumなので、Sのほうが少し小さいのです。Kはk-mean量子化をあらわします。
通常のアテンションを使うblk.3はこんな感じ。ssmがなくなって、attnが増えました。
q、k、vのweightがありますね。このq、kをエンベディング列にそれぞれ掛けたものの内積をとってマスクしてSoftmaxを適用して、エンベディング列にvをかけたものをかけると、アテンションの計算になります。たぶん。
TransformerのSelf AttentionのQKVを直感的に解説する #AI - Qiita
つまり、qとkの計算結果はあとからSoftmaxを適用するのでそこまで精度高くなくてもよい、でもvをかけた結果はそのまま使うのでvには精度が欲しい、ともなります。
MoEモデルを見る
最後にMoEモデルの35Bのほうを見るとこんな感じ。
ここで、まず、それぞれのウェイトがexpert_count、ここでは256要素あるのがわかります。Denseモデルでは2次元でしたが、MoEモデルではExpertがあって3次元になります。
そして、up/gate/downとは別にgate_inpというのがあるのがわかります。 これが、どのエキスパートを実際に使うかを選ぶルーターになります。 出力は256になるので、エキスパートごとのスコアがでて高い順に選ぶという感じですね。
まとめ
ということで、GGUFをおっかけると、モデルの構造がどのようになってるのか、量子化のK_Mとかなんなのか、というのがちょっとわかるようになりますね。
なぜ「ループは2重まで」が実務的にまわるのか
「ループの変数、i, jのあと悩むよね」「ループは2重まで。問題ない」というネタ的やりとりがあったのだけど、実際に「ループは2重まで」というのはコーディングの基準として割と受け入れられて、そしてそれで実務的にまわりがち。
でなぜか。
多くのアプリケーションの範囲では、まとまりのあるループとしては2重までがほとんどで、3重ループというのはあまり出てこないんじゃなかろうか。
つまり、
for (i) {
for (j) {
なにか処理
}
}
のように、ループの一番内側までアプリケーション的な処理がない、あっても前処理後処理的なもの、というのはだいたい2重まででは、という仮説。
まとまりのある3重ループが出るときは、立体空間を処理するなど、特殊ドメインになり、さまざまなアプリケーションのあちこちに出るとは なりにくいと思う。
2重ループは、複数の要素のすべての属性とか、要素同士のすべての組み合わせとか、広く使われると思う。
だいたいの3重以上のループは、ひとまとまりの2重ループを大きなループの中で一処理として使うか、ひとまとまりの2重ループの中で単ループを一処理として使うんじゃなかろうか。
そのため、2重ループ側か単ループ側を関数として切り出したほうが自然に書きやすくなる。もしくは、すべて独立したループ。
大きなループのなかで二重ループを使うというのはこういうの。
for (items) {
なにか処理
with_double_loop(n)
さらに処理
}
func with_double_loop(n) {
for (i) {
for (j) {
なにか処理
}
}
}
二重ループの中で単ループを使うのはこういうの
for (i) {
for (j) {
なにか処理
with_single_loop(i, j)
さらに処理
}
}
func with_single_loop(i, j) {
for (n) {
なにか処理
}
}
恐らく後者は無意識に頻出している。たとえば表をHTMLのtableで出すとき。
print("<table>")
for (row) {
print("<tr>")
for (item in column) {
print("<td>")
print(item)
print("</td>")
}
print("</tr>")
}
print("</table>")
という処理、printの中で文字ごとのループがあるので、少なくとも3重ループ以上のループになってる
あと、ひとまとまりの3重ループをやりたいという場合、3重だけじゃなく4重や5重もやりたいとなって再帰を使ってループ構文は使わなくなりがち。
こういうの。
func with_loop(items) {
if (items is null) return
なんか処理
for(item in items) {
with_loop(item)
}
さらに処理
}
ということで、「ループは2重まで」というのは、だいたいのアプリケーションのだいたいの処理で問題ないし、むしろ扱いやすくなりがちなので、実務的にまわるんじゃないかな。
