2025年初頭、Local LLM(自分のPCや端末上で動かす大規模言語モデル)の流れを大きく変えた出来事は、DeepSeek-R1の公開だったと思う。

数学、コーディング、論理推論などで高い性能を示したモデルが、MITライセンスで公開された。さらに、蒸留版と呼ばれる小型モデルは、7Bから70B程度の規模でローカルに動かせた。これまでクラウドでしか扱いにくかった処理を、手元の環境で試せるようになった出来事だった。

それから1年以上が経ち、モデル、実行ツール、ハードウェアのいずれも変化している。ここでは、2026年5月時点での状況と、今後の流れを整理する。

ローカルモデルは何ができるようになったのか

主要モデルの現在地

ローカルモデルを比較するときは、パラメータ数だけを見ても判断できない。MoE(Mixture of Experts)のように、全体のパラメータのうち一部だけを推論に使う構成もある。また、量子化の方法、コンテキストの長さ、画像や音声への対応によって、必要なハードウェアと使い勝手は変わる。

2026年5月時点で、特に気になるモデルは次のとおりだ。

Meta Llama 4(2025年4月公開)は、ScoutとMaverickの2種類がある。MoE構成を採用し、Scoutは109Bの総パラメータを持ちながら、推論時に使うアクティブパラメータは17B相当とされている。コンテキストウィンドウは10Mトークンで、画像入力にも対応する。Scoutは24GBの単一GPUで動かせる一方、Maverickは400B超の大規模モデルで、マルチGPU環境が前提になる。

Qwen 3.5 / 3.6(Alibaba、2026年)は、日本語を含む多言語での利用を考えやすいシリーズだ。Qwen3.5にはMoE 397B-A17Bなどのラインナップがあり、27B Dense版はSWE-bench Verifiedで72.4%というコーディング性能を示している。16GB VRAMのGPUで動かせるモデルもある。Qwen 3.6はMoE構成をさらに進め、235B規模のモデルでも推論時の計算量を抑える方向に進んでいる。Apache 2.0ライセンスで、商用利用を検討しやすい点も特徴だ。

Gemma 4(Google DeepMind、2026年4月公開)は、E2B、E4B、26B-A4B(MoE)、31Bの4サイズがある。全モデルがテキストと画像を扱え、小型の2モデルは音声入力にも対応する。コンテキストウィンドウは最大256Kトークンで、140言語以上をサポートする。31B Dense版はRTX 4090単体で動き、ollama run gemma4 の一行で試せる手軽さもある。

Phi-4 / Phi-4-reasoning(Microsoft、2025年)は、14Bという比較的小さな規模で、推論とコーディングを重視している。Phi-4-reasoningは、一部のベンチマークでDeepSeek R1の70B蒸留版を上回るスコアを示している。メモリや消費電力に制約がある環境で、候補にしやすいモデルだ。

DeepSeek V4-Pro(2025〜2026年)は、コーディング用途で有力なオープンモデルとして評価されている。商用のクローズドモデルに近いスコアを示すベンチマークもあり、ローカルモデルを選ぶ理由の一つになっている。

ここで挙げた性能や動作条件は、モデルの版、量子化方式、コンテキスト長によって変わる。実際に導入する場合は、ベンチマークの数字だけでなく、自分のデータとハードウェアで測る必要がある。

推論モデルがローカルに降りてきた

2025年から2026年にかけての大きな変化は、「考えてから答える」推論モデルがローカルで使いやすくなったことだと思う。

DeepSeek-R1の蒸留版をきっかけに、QwQ-32BやPhi-4-reasoningなどの推論特化モデルが登場した。簡単な数学や論理問題であれば、クラウドに接続しなくても解ける場面が増えている。Qwen3シリーズのThinking Modeも、同じ方向のアプローチだ。

用途別の選択肢

モデルの「おすすめ」は、利用目的と手元のメモリで変わる。以下は出発点としての目安であり、実際には量子化とコンテキスト長を含めて確認したい。

用途おすすめモデル必要VRAMの目安
汎用(低スペックPC)Gemma 4 E4B、Phi-4-mini8GB以下
汎用(Apple Silicon)Gemma 4 26B-A4B、Qwen3.5 14B統合メモリ32GB〜
汎用(RTX 4090)Gemma 4 31B、Llama 4 Scout24GB VRAM
コーディングQwen3.5 27B、DeepSeek V4-Pro16〜24GB
日本語Qwen3 / Qwen3.5 各サイズサイズ次第
推論・数学Phi-4-reasoning、QwQ-32B16〜24GB
プライベート文書のRAGLlama 4 Scout(長いコンテキスト)24GB〜
スマートフォンGemma 4 E2B、Phi-4-miniオンデバイス

実行ツールは用途で選ぶ

Ollamaは、モデルを取得してすぐに試したい場合に使いやすい。ollama run qwen3:8b のように一行で起動でき、Open WebUIと組み合わせれば、チャット形式の画面も用意できる。

LM Studioは、GUIでモデルを探し、設定を変えながら試したい人に向いている。モデルの比較や、エンジニア以外が触りやすい導入手順を重視するなら候補になる。

llama.cppは、さまざまな環境でモデルを動かすための基盤として存在感がある。Vulkanバックエンドの改善により、AMD GPUやIntel Arcでの利用も検討しやすくなっている。

用途が決まっていない段階ならOllama、設定を見ながら試すならLM Studio、性能やバックエンドまで細かく制御するならllama.cpp、という分け方が分かりやすい。

ハードウェアをどう考えるか

Apple Silicon

M4 Pro / M4 Maxでは、メモリ帯域と統合メモリの容量を活かして、比較的大きなモデルを動かせる。M4 Maxの128GB環境なら、70BモデルをQ4_K_M量子化で毎秒20〜30トークン程度という例もある。

Apple Siliconで重要なのは、専用VRAMの容量ではなく、CPUとGPUが共有する統合メモリだ。ただし、コンテキストを長くするとKVキャッシュにもメモリが必要になる。長文処理を多用するなら、モデル本体だけでなく、コンテキスト分の余裕も見ておきたい。

NVIDIA

RTX 5090は32GB VRAMを搭載し、ローカルLLMで目安になってきた24GBの壁を超える選択肢として注目されている。価格は高いが、Gemma 4 31BやQwen3.5 27Bを大きな制約なしに動かしやすい。

価格と入手性を考えると、RTX 4090も依然として有力だ。ただし、製品価格や在庫は時期と地域で変わる。購入を検討する場合は、その時点の価格を確認したい。

量子化の進化

モデルをローカルで動かすうえで、量子化は重要な技術だ。量子化は、モデルの重みを少ないビット数で表現し、メモリ使用量を減らす方法である。QAT(Quantization Aware Training)のように、量子化後の精度低下を抑える手法も普及している。

Q4_K_M量子化なら、70Bモデルをコンテキスト4Kの条件で40GB弱に収められる場合がある。ただし、モデルの種類や実装で変動する。「70Bが8〜10GBで動く」という数字を見かけても、極端に低いビット数や短いコンテキストを前提にしている可能性がある。実用条件では、より大きなメモリを想定したほうが安全だ。

1-bit LLM:モデルをさらに小さくする方向

量子化をさらに進めたものとして、1-bit / 1.58-bit LLMにも注目している。

Bonsai(PrismML、2026年3月公開)は、商用利用可能なtrue 1-bit LLMとして登場した。1.7B、4B、8Bの3サイズがあり、Bonsai 8Bは1.15GBに収まる。同規模の通常精度モデルと比べてメモリフットプリントが小さく、推論速度も高いとされている。Apache 2.0ライセンスとGGUF形式に対応し、llama.cppやApple MLXで扱える。

ベンチマークではLlama 3 8Bと同等レベルに達しているが、複雑な推論やコード生成では差が出る。チャット、要約、文書検索などには使えても、用途を選ぶモデルだ。

Microsoft BitNet b1.58は、重みを-1、0、+1の三値で表す1.58-bitのモデルだ。公式推論エンジンのbitnet.cppを使えば、CPUだけで動かせる。2Bパラメータのbitnet-b1.58-2B-4Tでは、ARM CPUでの高速化やエネルギー消費の削減が報告されている。

1-bit系モデルの現状を表にすると、次のようになる。

モデルパラメータモデルサイズ動作環境用途適性
Bonsai 8B8B1.15GBCPU / GPU / Apple MLXチャット・RAG
Bonsai 4B4B約600MBCPU / スマートフォンオンデバイス
BitNet b1.58 2B4T2B約400MBCPUのみ(bitnet.cpp)実験・研究用途

1-bitモデルは、すべてのタスクでQ4_K_M量子化の通常モデルを置き換えられる段階にはない。それでも、GPUなしで数百MBのメモリに収まるLLMが現れたことは、エッジデバイスやオフライン環境の選択肢を広げる。

これから起きそうなこと

オンデバイス推論の本格化

Apple Intelligenceのように、処理をクラウドと端末で分担する仕組みは今後も増えるはずだ。Gemma 4 E2BやPhi-4-miniのような端末向けモデルが整備されれば、スマートフォンでLLMを使うことも特別ではなくなる。

エージェントとの融合

ローカルLLMの用途は、質問に答えるだけではない。ツールを呼び出して、ファイルを整理したり、コードを実行したりするエージェントにも使える。

ローカルで動くエージェントには、通信による遅延が小さく、外部APIの利用料金を気にせず試せるという利点がある。MCP(Model Context Protocol)のようなツール統合の仕組みが広がれば、ローカルモデルを実際の作業へ組み込みやすくなる。

Llama 4 Scoutの長いコンテキストも、大量のコードや文書を扱うエージェントと相性がよい。ただし、長いコンテキストはメモリを消費する。モデルのスペックだけでなく、実際に扱うデータ量との組み合わせで考える必要がある。

プライバシーとオンプレミス

医療、法律、金融など、データを外部へ出しにくい領域では、ローカルやオンプレミスのLLMが候補になる。クラウドLLMの便利さは大きいが、データを外部へ送る制約がなくなるわけではない。

ただし、ローカルで動かせば自動的に安全になるわけではない。ログの設定、外部ツールとの連携、RAGの構成によっては、情報が外部へ渡る経路が残る。安全性はモデルの場所だけでなく、運用全体で確認する必要がある。

オープンモデルとクローズドモデルの差

DeepSeek-R1やQwen3.5 / 3.6の登場により、オープンモデルとクローズドモデルの差は用途によって小さくなっている。コーディング、日本語、長文処理では、オープンモデルで十分なケースも増えている。

一方、画像を含む高難度タスクや、最新情報へのアクセスでは、クローズドモデルが有利な場面も残っている。今後は「どちらが優れているか」ではなく、「どのデータを、どの場所で、どのコストで処理するか」によって使い分けることになりそうだ。

まとめ

Local LLMは、特別な機材を持つ人だけのものではなくなりつつある。モデルの性能、実行ツール、ハードウェアがそろい、用途を選べば実用になる段階に入った。

まず試すなら、Ollamaで ollama run gemma4ollama run qwen3:8b を実行するところから始めるのがよいと思う。手元の環境でどのくらい動くのかを確認してから、モデルのサイズや量子化、長いコンテキストを検討すればよい。

「クラウドかローカルか」という二択ではなく、処理内容とデータの性質に応じて両方を使い分ける。その選択肢が現実的になってきたことが、いまのLocal LLMの一番大きな変化だと思う。


ばりぃ


AI 利用について 本記事の執筆・情報収集・構成の整理には AI(Claude)を活用しています。 内容の最終確認と判断は筆者が行っていますが、ご参考までに。