2026年夏のローカルLLM事情を整理してみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

半年前に「2026 年のローカル LLM 事情を整理してみた」という記事を公開しました。ありがたいことに多くの方に読んでいただいたのですが、この半年でローカル LLM の景色はまた大きく変わっています。Qwen3.6 と Gemma 4 の世代交代、DeepSeek V4、そして Ollama の大幅な高速化。「半年経った今はいったいどうなっているの？」と気になっている方も多いのではないでしょうか。

https://dev.classmethod.jp/articles/local-llm-guide-2026/

前作の公開後、自分は DGX Spark を使って Qwen3.6、Gemma 4、Nemotron 3、Laguna S 2.1 と実機検証を重ねてきました。今回はその実測データを持ち寄って、前作の「選び方ガイド」を 2026 年夏版に書き直してみます。

先に結論を書いておくと、この半年で主役は「MoE + 4bit 量子化」に移りました。日本語込みの汎用用途なら Qwen3.6-35B-A3B が第一候補で、手元の実測では投機デコード込みで 108.3 tok/s が出ています。そしてツール側では Ollama が 0.32 系で大きく速くなり、単一ストリームのデコード速度なら vLLM と並ぶようになりました。

この記事では、この半年の変化の整理と、2026 年 7 月時点でのモデル・ハードウェア・ツールの選び方を紹介します。前作を読んでいなくても通して読めるようにしています。

この半年でローカル LLM の何が変わったか

本題の前に、この記事の骨子になる用語を押さえておきます。MoE（Mixture of Experts）は、モデル全体のうち一部の専門家パラメータだけが 1 トークンごとに働く方式です。モデル名の「35B-A3B」は総 35B のうち Active（実際に働く分）が 3B という意味で、総サイズの割に速く動きます。対して従来型の dense は全パラメータが毎回働きます。投機デコードは、小さな下書きモデルに数トークン先読みさせて本体がまとめて検証する高速化技術です。

この前提で、前作時点との差分を一覧にしてみます。

モデルの顔ぶれも入れ替わりました。1 月に「主要モデル」として紹介した Qwen3、Gemma 3、DeepSeek-V3.2 は、4 月に Qwen3.6、Gemma 4、DeepSeek V4 へ世代交代しています。ほかにも Devstral 2（2025 年 12 月）、Kimi K2.6（4 月）、コード特化の Laguna S 2.1（7 月）と、半年でよくこれだけ出たなという密度です。

一方で変わっていないものもあります。gpt-oss は 2025 年 8 月版のまま後継が出ておらず、Llama 4 も 2025 年 4 月から更新がありません。「オープンモデルの進化 = 中国勢 + Google の高速回転」という構図が、この半年でより鮮明になった印象です。

そこにもうひとつ、NVIDIA の軸が加わってきました。Nemotron 3 は学習データやレシピまで公開する方針で、日本語向けにも Nemotron-Personas-Japan のような合成データセットが出ています。Physical AI 向けの Cosmos 3 も含めて、「そのまま使う」だけでなくファインチューニングの土台として使える、癖のないモデル群が揃ってきたのが NVIDIA 勢の面白いところです。速度競争とは別のレイヤーで、ローカル LLM の裾野を広げている印象があります。

2026 年夏の主要モデル比較

ここからが本題です。用途別のおすすめを前作と並べる形で更新します。

用途別おすすめモデル

モデル詳細比較

前作で「迷ったら Apache 2.0」と書きましたが、この構図は変わっていません。Qwen3.6 と Gemma 4 がどちらも Apache 2.0 なので、商用利用の観点では選びやすい 2 強です。なおフラッグシップの Qwen3.6-Max は重み非公開の API 専用で、オープンに使えるのは 27B / 35B-A3B などの中型帯です。

日本語性能

日本語性能の評価も更新します。Nejumi Leaderboard 4（2026 年 7 月版）を参照しつつ、自分の実測での印象を加えた評価です。

前作で「日本語なら Qwen 系を軸に」と書いた結論は維持です。変わったのは Gemma 4 の躍進で、特に 26B-A4B は MoE の速度と日本語品質を両立していて、手元の検証でも扱いやすいモデルでした。国産勢はまだ総合上位に入っていませんが、日本語特化の Nemotron Nano 9B v2 Japanese が小型枠で健闘しています。

decode 速度は「1 トークンで読むバイト量」でほぼ決まる

半年間いろいろなモデルを測ってきて、一番役に立った法則がこれです。decode はプロンプトを読み終えたあとにトークンを吐き出す生成フェーズのことで、体感速度のほぼすべてを決めます。この速度はメモリ帯域で律速されるため、「Active パラメータ数 × 量子化バイト数 = 1 トークンの生成で読むバイト量」に反比例します。なお長文プロンプトの処理速度（prefill）は別の軸なので、この記事では扱いません。

DGX Spark 単体での single decode 実測（vLLM v0.24.0〜v0.25.1、base + 投機デコードの上乗せ）。同じ 100B 超級でも Active 8.5B の Laguna S 2.1 は Active 12B の Nemotron 3 Super（120B）より速い。

横軸は Active params × 量子化バイト（対数）。総パラメータ数ではなくこの値が速度を決めるのがよくわかる。

グラフから読み取れるポイントは 3 つあります。

まず、総パラメータ数は速度の指標にならないということ。118B の Laguna S 2.1（Active 8.5B）が 27B dense の Qwen3.6-27B より速い、という逆転が普通に起きます。MoE 全盛の現在、「何 B のモデルか」より「Active 何 B か」を見る習慣をつけると、スペック表から速度をだいたい予想できるようになります。

次に、投機デコードが実用になったこと。モデル同梱の下書き機構が MTP（Multi-Token Prediction）、別配布の小型下書きモデルが drafter で、どちらも出力品質を変えずに速度だけ上乗せします。Qwen3.6-35B-A3B は MTP 有効で 76.66 から 108.3 tok/s（1.4 倍）に、素が遅い dense ほど倍率が乗るため Qwen3.6-27B は 12.13 から 29.38 と 2.4 倍に伸びました。前作では触れもしなかった技術が、半年で「対応モデルなら基本オン」になりました。

最後に、この法則は帯域律速なので他の環境にも読み替えられること。DGX Spark の帯域は約 273GB/s で、Mac の M4 Pro や Ryzen AI Max とだいたい同じ帯域クラスです。dGPU はもっと速く、中古定番の RTX 3090 で帯域は約 3.4 倍、RTX 5090 なら約 6.5 倍なので、グラフの数値をおおまかにスケールして目安にできます。

このあたりの実測の詳細は、連載 4 本（Qwen3.6-27B 起点の横断比較、Qwen3.6-35B-A3B 対決、Gemma 4 対決、Laguna S 2.1、いずれも 2026 年 7 月時点の記事です）にまとめています。

量子化形式の勝者はモデル依存だった

前作では量子化を「精度を犠牲にメモリを節約する手法」と 1 節で済ませました。この半年で状況が変わり、配布側が最初から 4bit 版を出すのが当たり前になっています。そこで見えてきたのが「同じ 4bit でも配布元によって速度がまったく違う。しかもどちらが速いかはモデル依存」という事実です。

ここでも用語を整理しておきます。NVFP4 は NVIDIA の 4bit 量子化形式で vLLM 圏の主流、GGUF は llama.cpp / Ollama 圏で使われる形式、QAT（Quantization-Aware Training）は 4bit 化を前提に学習し直した高品質版です。

まず NVIDIA 公式版と Unsloth 版の NVFP4 量子化を DGX Spark で比較した結果がこちらです。

Qwen では NVIDIA 版の全勝、Gemma では Unsloth 版の全勝。真逆です。原因は量子化形式（modelopt static と compressed-tensors dynamic）と実装の相性で、事前にどちらが勝つかを予想する方法は今のところありません。実践的な指針はシンプルで、同じモデルの 4bit 版が複数の配布元から出ていたら、両方試して速い方を使う。これだけで 5 割増しの速度を取りこぼさずに済みます。

GGUF ユーザーにも同じ話があります。Gemma 4 には Google 公式の QAT 版があり、Ollama で gemma4:26b-a4b-it-qat を動かすと手元の実測で 55.46 tok/s でした。vLLM の NVFP4 base（49.13）より速い、という結果です。量子化は「節約のための妥協」から「配布元選びで性能が変わる選定ポイント」に変わりました。

ちなみに Ollama のモデルライブラリを眺めると、-qat だけでなく -nvfp4 や -mtp-q4 といったタグが並ぶようになっています。vLLM 圏の技術が Ollama 圏に流れ込んできているのが、タグ一覧からも見て取れて面白いですね。

ハードウェア要件と統合メモリ機の台頭

VRAM 別の選定目安も更新します。今回から「128GB 統合メモリ」の行が主役級に昇格しました。

表の小型帯に前世代の Qwen3.5 が残っているのは、Qwen3.6 に 27B 未満のサイズが存在しないためです。小型はしばらく Qwen3.5 系と Gemma 4 の 12B 以下が受け皿になります。

統合メモリ機の顔ぶれは半年で一気に充実しました。AMD Ryzen AI Max+ 395（Strix Halo）搭載のミニ PC は 128GB 構成の帯域が約 256GB/s と DGX Spark（約 273GB/s）とほぼ同じで、差は CUDA エコシステムと価格です。半年前には $1,500 台の実売もありましたが、DRAM 高騰の影響で 2026 年 7 月時点の現実的な下限は $1,800〜2,000、ベンダーによっては $3,000 超えの表示も見かけます。Apple も M3 Ultra の 512GB 構成が同じ DRAM 高騰で販売終了になるという逆風を受けつつ、帯域 819GB/s は依然として別格です。NVIDIA も GB10 派生のコンシューマ向けチップ N1X を準備中で、「128GB 統合メモリでローカル LLM」はこの下半期にさらに手が届きやすくなりそうです。

一点注意が必要です。128GB あっても帯域は 24GB クラスの dGPU より細いため、dense の大型モデルは容量的に載っても速度が出ません。手元の DGX Spark でも dense 70B は数 tok/s まで落ちます。128GB 統合メモリ機は「大型 MoE を動かすためのハード」と割り切るのが現実的です。

なお世の中のレビューでは、DGX Spark や GB10 互換機を 2 台・4 台とつないで数百 GB 級のモデルを動かす事例も増えてきました。自分も DGX Spark 2 台で DeepSeek V4 Flash を動かした記事（2026-06-30 時点の記事です）を書いていますが、このあたりまで来ると個人のローカル LLM というよりミニクラスタの世界です。どこまでをローカル LLM と呼ぶかは悩ましいところですが、この記事では「1 台・128GB まで」を範囲として扱っています。

「自分の Mac ではどうなの？」という向きに、Mac mini（M4、16GB）での実感値も測ってみました。Gemma 4 12B QAT が Ollama で 11.26 tok/s、Nemotron 9B が LM Studio で 9.29 tok/s。9〜12B クラスの Q4 で 10 tok/s 前後、読みながら待てる速度です。エンジンの差よりモデルサイズと帯域が支配的なので、16GB 帯はモデル選びがほぼすべてですね。

なお中古 GPU 市場は高騰していて、RTX 4090 の中古が新品 RTX 5080 より高い逆転現象が起きています。VRAM 単価で見ると中古 RTX 3090（24GB）が引き続き本命ですが、マイニング酷使個体には注意してください :)

ツール選定 2026 夏の現在地

ツールの評価も半年でかなり動きました。まず比較表の更新版です。

今回いちばん驚いたのが Ollama です。この半年でリリースを重ねて着実に速くなりました。手元の DGX Spark で同じ qwen3.6:35b-a3b を測ると、0.20 系の 59.70 tok/s から 0.32.3 では 76.19 tok/s。ランタイム更新だけで +28% です。この数字は vLLM の base（76.66）とほぼ同じで、「Ollama は手軽だけど遅い」という前作時点の相場観は、単一ストリームに関してはもう古くなりました。vLLM の優位は投機デコード（108.3）と並列スループットに移っています。

Ollama の半年分の変化で押さえておきたいのは 4 つです。Apple Silicon では Gemma 4 の MTP がデフォルト有効になり約 90% 高速化。ollama launch の連携先は Claude Code だけだったのが 16 統合（Codex、Copilot、OpenCode、Cline など）に拡大し、ローカルモデルをコーディングエージェントに繋ぐハブになりつつあります。OpenAI 互換 API の reasoning_effort で思考モデルの思考を止められるようになり（"none" 指定で即答）、ルーティングや分類用途で便利です。そして新しめのモデルタグは古いクライアントを拒否するので、モデルが pull できないときはまずランタイム更新を疑ってください。自分も gemma4 タグで「requires a newer version」に当たりました。

LM Studio は逆に足踏みがあります。0.3.23 で入った「MoE エキスパート重みを CPU に退避するトグル」が 0.4 系でレイヤー単位のスライダーに置き換わり、bug tracker には旧トグルの復活要望が上がっています。MoE オフロード目的なら、現時点では llama.cpp 直（--cpu-moe / --n-cpu-moe）が確実です。llama.cpp は投機デコードも --spec-type draft-mtp で入り、DeepSeek や GLM の MTP ヘッドに対応しています。

もうひとつ、この半年で存在感を増したのが Apple Silicon 向けランタイムの MLX です。6 月の WWDC 2026 では Apple 自身のローカル LLM 戦略も見えてきました。アプリの言語モデル層である Foundation Models フレームワークがサードパーティモデルに開放され、Hugging Face の MLX コミュニティモデルをオンデバイスモデルと差し替えられる仕組みが発表されています。ツール側でも LM Studio が MLX 形式を GGUF と並ぶ第一級の選択肢として扱い、Ollama のモデルライブラリにも gemma4:12b-mlx や qwen3.6:27b-mlx といったタグが並び始めました。Mac でのローカル LLM は GGUF 一択から「MLX という第二の標準」がある状態に変わりつつあります。

視点をもう一段上げると、モデルを「使い分ける」レイヤーも動き始めています。ローカル LLM ではありませんが、Sakana AI の Fugu（2026-06-22 時点の記事です）は複数のモデルを指揮するオーケストレーターとしてのモデルという新しい在り方を見せました。NVIDIA の NeMo Switchyard（2026-07-03 時点の記事です）のような LLM ルーターも登場していて、自分も手元では振り分け判定にローカルの Qwen3.6 を使う構成で常用しています。モデルが用途別に量産されていく流れを見ると、こうしたルーティング層は今後ローカル環境でも当たり前になっていくのではと見ています。

まとめ

改めて振り返ると、半年でシーンは本当に大きく変わりました。モデルの主役は MoE + 4bit 量子化に移り、日本語込みの汎用なら Qwen3.6-35B-A3B、16GB 帯なら Gemma 4 12B の QAT 版が現在の推しです。スペック表を見るときは総パラメータではなく Active 数を、ダウンロードするときは配布元を 2 つ試す。この 2 つの習慣だけでも、この記事から持ち帰る価値があるかなと思っています。ハードウェアは 24GB GPU が引き続き主戦場ですが、大型 MoE を狙うなら 128GB 統合メモリ機が現実的な選択肢になりました。dense の大型モデルには向かない点だけ忘れずに。

半年前は「オープンソース LLM が実務ツールに移行するタイミング」と書きました。今は一歩進んで、投機デコードや量子化形式の選び方といった「使いこなし」で差がつくフェーズに入った実感があります。そして前作がわずか半年でここまで古びたように、この記事の内容も今まさに日々塗り替えられている最中です。次の大きな波が来たら、また実測込みで整理し直したいと思います。Strix Halo 機の実機検証も、年末のこのガイドの冬版も、やってみたいところです。

参考リンク

• 2026年のローカルLLM事情を整理してみた（前作、2026-01-28）
• Qwen3.6 GitHub
• Gemma 4 モデルカード
• DeepSeek V4 リリースノート
• Introducing Devstral 2 and Mistral Vibe CLI（Mistral AI）
• openai/gpt-oss-120b（Hugging Face）
• Ollama Releases
• Ollama library: gemma4
• Ollama library: qwen3.6
• LM Studio bug tracker #1421 — MoE オフロードトグルの復活要望
• 日本語 LLM ランキング 2026（Nejumi Leaderboard 4 解説）
• NVIDIA DGX Spark review（Tom's Hardware）