2026年の優れたローカルLLM：どのLLMを実行すべきか、そしてどのハードウェアで実行すべきか

このブログとしては珍しく、ここでは販売するものがほとんどありません。私たちはGeonodeというプロキシ販売業者ですが、ご自身のマシンで言語モデルを実行するには、そうしたものは一切必要ありません。 プロキシも、帯域幅も、アカウントも不要です。関連性は一歩離れたところにあります。ローカルモデルは、多くの場合、ご自身のデータに対する検索機能を備えて展開されますが、そのデータが公開ウェブから取得される場合、誰かがそれを収集しなければなりません。それが私たちの担当するパイプラインの末端であり、モデルとは真に独立したものです。 ですから、この記事を、あなたがどのモデルを選ぶかに関与しない立場の人々が書いたガイドとしてお読みください。この分野において、そのような立場は本来あるべき姿よりも稀なものです。

「ローカル」がもたらすメリットとコスト

この点については、双方とも常日頃から過大評価されがちなので、具体的に説明しておく価値があります。

得られるメリット。 データは決して自分のマシンから外に出ません。規制対象の業務においては、これは単なる好みではなく、必須要件です。 トークン単位のコストがかからないため、ハードウェア費用さえ賄えれば、大量利用や実験的な利用も無料です。レート制限もなく、他者の稼働状況に依存することもありません。完全なバージョン安定性――モデルが利用中に変更されることはありません。これは、モデルの挙動に合わせてプロンプトを調整している場合、極めて重要な点です。さらに、データをどこにも送信することなく、自身のデータで微調整を行うことも可能です。

支払うもの。 主に「性能」です。2026年の最高のローカルモデルは確かに優れていますが、高度な推論においては、最先端のホスト型モデルにはまだ及ばないでしょう。ハードウェアは、実質的な資本コストとなります。また、本格的なハードウェアを購入していない限り、処理速度も犠牲になります。 セットアップ、量子化の選択、統合に費やす自身の時間。そして電力——持続的な負荷がかかるマシンにとっては、決して無視できないコストです。

人々を誤った方向に導くのは、これを単なるコスト比較として捉える考え方です。 もし月に数十万トークンをホスト型APIに送信しているなら、ローカルモデルではコスト削減にはなりません――ハードウェアのコストが、その利用料を数年分も上回ってしまうからです。ローカルモデルが優位となるのは、プライバシー、制御性、安定性、あるいは非常に大規模な処理量の場合です。もしこれらのいずれにも当てはまらないのであれば、経済的なメリットもありません。

ハードウェアの仕様がすべてを決定づける

どのモデルを検討するにしても、まずVRAMの容量を把握しましょう。それ以外のすべてはそこから決まります。

この計算式を有利に変える要素が2つあります。

Mixture-of-Experts（MoE）アーキテクチャ。 これらは総パラメータ数は多いものの、トークンごとにその一部のみを活性化します。gpt-oss-120bの総パラメータ数は1,170億で、そのうち51億が活性化されます。 OpenAIのモデルカードによると、エキスパートの重みにMXFP4量子化を適用することで、「単一の80GB GPU（NVIDIA H100やAMD MI300Xなど）」に収まるとされています。gpt-oss-20bは総パラメータ数210億、アクティブなパラメータ数36億で、「16GBのメモリ内」で実行されます。 これにより、はるかに小型のモデルと同等のメモリと処理速度のコストで、大規模モデルに匹敵する品質上のメリットを得ることができます。

Apple Siliconのユニファイドメモリ。 Macでは、システムメモリがGPUメモリとなります。64GBのユニファイドメモリを搭載したマシンであれば、一般のユーザーが所有していないような専用GPUカードを必要とするモデルも実行可能です。スループットは同等の容量を持つディスクリートGPUよりも低くなりますが、コストパフォーマンスの面では容量の上限がはるかに高くなります。

また、コンテキストの容量も予算に組み込んでください。モデルの重みだけでは不十分です。KVキャッシュはコンテキストの長さに比例して増加し、長い入力の場合には数ギガバイトを消費する可能性があります。4Kのコンテキストに収まるモデルでも、128Kでは収まらない場合があります。

2026年に実行する価値のあるモデル

Qwen3は、ローカル展開において最も有用なモデルファミリーです。その主な理由は、あらゆるサイズ範囲を網羅しつつ、一貫した挙動を示す点にあります。Hugging Faceのコレクションには、0.6B、1.7B、4B、 8B、14B、32Bのデンセモデルに加え、30B-A3Bおよび235B-A22Bのミクスチャー・オブ・エキスパート（MOE）バリアントが掲載されており、FP8、GGUF、AWQ、GPTQ、MLX形式の量子化ビルドが用意されています。

Qwen3-8Bモデルカードには、重要な特徴が記載されています。Apache 2.0ライセンス、32,768トークンのネイティブコンテキスト（YaRNスケーリングにより131,072トークンまで拡張可能）、そして「100以上の言語および方言のサポート」です。 このモデルの最大の特徴は、推論を多用する作業向けの「思考モード」と、効率的な対話向けの「非思考モード」を、1つのモデル内で切り替えられる点にあります。

そのカードに記載されている、見落とされがちな実用的な詳細として、サンプリング設定が重要であり、推奨値はモードによって異なる点が挙げられます。思考モードでは温度 0.6、top-p 0.95、top-k 20、それ以外のモードでは温度 0.7、top-p 0.8、top-k 20 です。 思考モードでは、貪欲なデコードは明示的に推奨されていません。モデルのパフォーマンスが期待を下回っている場合は、モデルを非難する前にサンプリングパラメータを確認してください。

GoogleのGemma 4は、Gemmaのライセンスに以前躊躇していた人にとって注目すべきリリースです。なぜなら、ライセンスがApache 2.0になったからです。 モデルカードには、E2B、E4B、12B、26B、A4B、31Bの5つのサイズが記載されており、「128Kのコンテキストウィンドウを備え、中規模モデルは256Kをサポート」しているほか、 「140以上の言語」に対応しており、E2B、E4B、12Bモデルでは音声を含むテキストおよび画像入力がサポートされています。小型のオープンウェイトモデルでネイティブの音声入力がサポートされているのは珍しく、そのようなユースケースを検討している場合は知っておく価値があります。

OpenAIのgpt-ossは、その両極端を網羅しています。 20Bは16GBのマシンに収まり、120Bは80GBのカード1枚に収まります。どちらもApache 2.0ライセンスで、モデルカードには「寛容なApache 2.0ライセンス：コピーレフトの制限や特許リスクなしに自由にビルド可能」と記載されています。 20Bは「低レイテンシ、およびローカルまたは特殊なユースケース」向けに位置付けられており、エージェント型処理、関数呼び出し、コード実行などが明示された用途に含まれています。

DeepSeek-R1は、オープンな推論モデルの基準であり続けており、MITライセンスが適用されています。モデルカードには、「商用利用をサポートし、あらゆる改変や派生作品の作成を許可する」と記載されています。ローカル利用においては、フルモデルよりもディスティル版の方が重要です： Qwenベースのディスティル版は1.5B、7B、14B、32B、Llamaベースは8Bおよび70Bがあり、いずれも「DeepSeek-R1を用いて精選された80万サンプル」で微調整されています。 14Bおよび32Bのディスティル版は、一般向けハードウェアにとって実用的な選択肢です。

Llamaは依然として、他を大きく引き離して最もダウンロードされているファミリーです。Ollamaのライブラリによると、llama3.1のダウンロード数は1億1,910万回、llama3.2は8,210万回で、deepseek-r1の9,220万回やgemma3の4,000万回を上回っています。 人気が高いということは、最高のツールセット、最も多くのコミュニティによる微調整、そして最も豊富なトラブルシューティング資料が揃っていることを意味し、これは純粋な機能とは別に、真の利点となります。

また、埋め込みモデルも見逃してはなりません。nomic-embed-textはOllamaのライブラリで84.2Mのプル数を記録し、3位にランクインしています。これは、ローカルのLLMの利用が、チャットではなく、実際にはプライベートなドキュメントからの情報検索にどれほど多く使われているかを物語っています。

ベンチマークよりもライセンスの方が重要

このセクションは、高額な損失につながるミスを防ぐためのものですが、モデル比較では常々省略されがちです。

「オープンウェイト」は一様ではありません。上記のモデルは、以下の3つのグループに分類されます：

Apache 2.0 — Qwen3、Gemma 4、gpt-oss、QwenベースのDeepSeekディスティル。許容範囲が広く、商用利用可能、利用分野の制限なし、特許許諾を含む。製品をリリースする場合、これが最適です。

MIT — DeepSeek-R1自体。同様に許容範囲が広く、商用利用、改変、派生作品の作成を明示的に許可しています。

カスタムコミュニティライセンス — Llamaファミリー、およびそれに基づくLlamaベースのDeepSeekディスティル。これらはそれぞれLlama 3.1およびLlama 3.3のライセンスを適用します。 これらは多くのことを許可していますが、ApacheやMITではありません。利用許容ポリシー、帰属表示の要件、およびユーザー数が一定数に達した際に発効する条件が含まれています。通常は問題ありませんが、自動的に問題ないとは限らないため、これらに基づいて製品を構築する前に一読する価値があります。

Gemma 4がApache 2.0に移行したことは、Gemmaが以前はカスタムライセンスを使用していたからこそ、非常に重要な意味を持ちます。以前にこのファミリーを評価し、ライセンス上の理由で採用を見送った場合、その理由はもはや当てはまりません。

実用的な点を2つ挙げます。まず、ファミリー全体ではなく、取得する特定のモデルのライセンスを確認してください。DeepSeekのディスティルが最も明確な例であり、同じリリースの異なるディスティルでも、ベースモデルに応じて異なるライセンスが適用されます。 次に、微調整を行う場合は、派生作品や命名に関するライセンス条項をよく読んでください。派生作品に元の名称を冠することを義務付けるライセンスもあるためです。

ツール：Ollama、llama.cpp、LM Studio、vLLM

Ollamaは、ほとんどの人にとって最適なデフォルトの選択肢です。1つのコマンドでモデルを取得でき、OpenAI互換のHTTPエンドポイントが用意されており、量子化の設定も適切なデフォルト値が採用されています。唯一の限界は、推論パラメータを精密に調整したい場合、最終的にはその限界に達してしまう点です。

llama.cppはOllamaの基盤となっており、これを直接使用することで、量子化、コンテキスト処理、GPUレイヤーのオフロード、CPUスレッド処理を完全に制御できます。また、旧式のグラフィックカード、CPUのみ、Apple Siliconなど、特殊なハードウェア環境でも最もサポートが充実しています。

LM Studioは、モデル検索機能とチャットインターフェースを備えたデスクトップアプリケーションです。モデルを利用するユーザーが開発者でない場合、これが最適な選択肢となります。

vLLMはローカルツールではなくサービングシステムであり、継続的なバッチ処理によるスループットを重視して構築されています。個人ではなくチーム向けにモデルを実行する場合は、このティアに移行することになります。なお、vLLMでは本格的なGPUハードウェアが必須となります。

便利なパターンとして、OllamaのOpenAI互換エンドポイントを使用して開発を行い、後で正式にサービングする必要が生じた場合は、同じインターフェースの背後でvLLMに移行する方法があります。アプリケーションのコードを変更する必要はありません。

曖昧さを排除した量子化

量子化とは、重みの数値精度を下げることで、モデルに必要なメモリ量を削減する手法です。これにより、本来なら60 GBのメモリを必要とするモデルでも、24 GBのメモリを搭載したGPU上で実行できるようになります。

実務で通用するルール：量子化率が高く、モデル規模が大きいほど、量子化率が低く、モデル規模が小さい場合よりも通常は性能が優れる。 同じメモリ予算であれば、Q4の32Bモデルは通常、Q8の14Bモデルよりも優れた性能を発揮する。 例外は極端な場合です。Q3未満では、性能低下が著しくなり、この関係が逆転します。

また、gpt-ossのエキスパート重みに使用されているMXFP4は、量子化が事後的に適用されるものではなく、モデル設計の一部となっているケースである点にも注意してください。 そのため、これらのモデルカードのメモリ使用量はこれほどまでに低いのです。

この表を含め、表を鵜呑みにするのではなく、ご自身のワークロードでテストを行ってください。量子化は機能ごとに不均一に性能を低下させ、要約処理では目立たないレベルの低下でも、コード生成では顕著に現れる場合があります。

現実的な期待と最先端技術

これらを正しく設定しておけば、失望のほとんどは避けられます。

ローカルモデルが真に競争力を持つ分野： 要約、情報抽出、分類、翻訳、単純なコード補完、下書き作成、自社文書を対象とした検索補助型質問応答。 これらすべてにおいて、適切に選択された14B～32Bのモデルで十分であり、ホスト型最先端モデルとの差はごくわずかで、気づくのも難しいほどです。

依然として差が存在する分野： 長文の多段階推論、複雑なエージェント型作業、真の理解を必要とする大規模なコードベース、広範かつ最新の世界知識を要するタスク。その差は大幅に縮まったものの、完全に埋まったわけではありません。

ローカルモデルが圧倒的に優位な場面： データが自社のインフラから持ち出せない場合、および処理量が十分に多く、トークン単位の課金が支配的となる場合。これらは機能面での議論ではなく、しばしば決定的な要因となります。

もう一つ調整すべき期待値として「速度」があります。一般向けのハードウェアでは、32Bモデルが生成するトークンのレートは、チャットインターフェースには問題ありませんが、バッチ処理には遅すぎます。1万件のドキュメントを処理する場合は、アーキテクチャを決定する前にスループットを測定してください。

APIを使うべき場合

この前提に異議を唱えるセクション。

処理量が少ない場合。 月に数十万トークン程度の処理であれば、ホスト型APIの利用コストはごくわずかで、GPUを購入するほどの価値は決してありません。わずかな費用を節約するためにハードウェアを購入するのは、そのハードウェアに他の用途がない限り、割に合わない投資です。

最先端の機能が必要な場合。 タスクが真に利用可能な最強の推論能力を必要とする場合、ローカルモデルはまだそのレベルに達しておらず、そうでないふりをするのは数週間の無駄になります。

ハードウェアを持っていない場合。 手元にあるのが8GBのGPUカードだからといって、そこに70億パラメータのモデルを実行し、「ローカルモデルは役に立たない」と結論づけるのは、よくあるが避けられる失望です。実行できるモデルと、文献で読んでいるモデルは別物なのです。

メンテナンスコストを吸収できない場合。 モデルは更新され、ツールは変わり、量子化形式も進化します。ホスト型APIであれば、運用上の問題は他者の責任となります。

プロトタイプ開発中である場合。 APIを基に構築し、製品が機能することを確認してから、ローカル移行に価値があるかどうかを評価してください。 順序を逆にしてしまうと、アイデアが優れているかどうかを知る前に、ハードウェアの問題を解決することになってしまいます。

そして、曖昧さの全くないケースとして、データが自社施設外に出してはならないという制約がある場合は、上記のいずれにも該当しません。その状況では、ローカル環境は単なる選択肢ではなく、どのモデルが自社のハードウェアに適合するかという問題のみが問われることになります。

よくある質問

2026年に最適なローカルLLMはどれですか？

一概にこれという答えはありませんが、Qwen3は0.6Bから235Bまでをカバーし、一貫した動作とApache 2.0ライセンスを備えているため、ローカル展開には最も有用なシリーズです。 VRAMの容量に合わせてサイズを選びましょう。8～16 GBの場合は8B、24 GBの場合は30B-A3Bのミクスチャー・オブ・エキスパートモデル、80 GBのカードをお持ちの場合はgpt-oss-120bが適しています。

ローカルLLMを実行するには、どれくらいのVRAMが必要ですか？

8 GBあれば、量子化された4B～8Bクラスの実用的なモデルを実行できます。16 GBあれば、12B～14Bクラスのモデルを余裕を持って実行できます。また、gpt-oss-20bは16 GB以内で動作することが確認されています。 24 GBあれば、30Bクラスのモデルも利用可能になります。ミクスチャー・オブ・エキスパート（MoE）アーキテクチャでは、トークンごとにアクティブになるパラメータはごく一部であるため、この要件が緩和されます。

ローカルLLMはChatGPTやClaudeと同等の性能がありますか？

最も難易度の高い推論タスクに関しては、そうではありません。要約、情報抽出、分類、翻訳、および自身の文書に対する検索といったタスクにおいては、優れた14B～32Bのローカルモデルであれば、その性能はChatGPTやClaudeに十分近く、その差がほとんど問題にならないほどです。その差は縮まりつつありますが、まだ埋まっていません。

商用利用可能なローカルLLMにはどのようなものがありますか？

Qwen3、Gemma 4、gpt-ossはApache 2.0ライセンスです。DeepSeek-R1はMITライセンスです。いずれも利用分野の制限なく商用利用が可能です。Llamaファミリーは、コミュニティ独自のライセンスを採用しており、多くのことが許可されていますが、一読すべき条件が設けられています。 モデルファミリー全体ではなく、個々のモデルを確認してください。DeepSeekのQwenベースのディスティルモデルはApache 2.0ですが、LlamaベースのディスティルモデルはLlamaライセンスが適用されます。

LLMをローカルで実行する最も簡単な方法は？

開発者向けにはOllama — 1つのコマンドでモデルを取得でき、OpenAI互換のHTTPエンドポイントが利用可能です。グラフィカルインターフェースを望み、コマンドラインを使いたくない場合はLM Studioが適しています。どちらも量子化とハードウェア検出を自動的に処理してくれます。

量子化は品質を低下させますか？

多少は低下しますが、その程度はモデルによって異なります。Q8はフル精度とほぼ見分けがつきません。Q4_K_Mは一般的なデフォルト設定で、品質の低下は軽微であり、ほとんどの人が気づかない程度です。 Q3以下になると、品質の低下が明らかになります。原則として、同じメモリ予算であれば、Q4の大型モデルはQ8の小型モデルよりも優れた性能を発揮します。

MacでローカルのLLMを実行できますか？

はい、可能です。しかも、同価格帯のPCよりもパフォーマンスが優れていることがよくあります。これは、Apple Siliconの統合メモリがGPUでも利用可能だからです。64 GBのMacであれば、一般の人が所有していないようなグラフィックカードが必要なモデルも実行できます。スループットはディスクリートGPUより低くなりますが、コストパフォーマンス（1ポンドあたりの処理能力）ははるかに高くなります。

ローカルLLMにはプロキシや特別なネットワーク設定が必要ですか？

いいえ。モデルはご自身のマシン上で実行され、ネットワークリクエストは一切行いません。ネットワークが関与するのは、取得するためにWebデータを収集する場合のみですが、これはパイプラインのまったく別の部分です。

まとめ

まずメモリ容量、次にライセンス、そしてベンチマークの順で選ぶ。この順序は、一般的な比較記事の書き方とは正反対だが、実際に動作するシステムを構築するにはこの順序が最適だ。

どのモデルが候補となるかはVRAMによって決まりますが、エキスパート混合アーキテクチャの登場により、その制約は大幅に緩和されました。かつては、80GBの単一カードで1,170億個のパラメータ、あるいは16GBのカード内で210億個のパラメータを扱うことは現実的ではありませんでした。 ライセンスは、構築したものを配布できるかどうかを決定するものであり、Gemma 4がApache 2.0に移行したことで、許容範囲の広いライセンスが現在、有力な選択肢の大部分をカバーするようになった。ベンチマークが最後に来るのは、同じ規模クラス内では差が小さく、具体的なワークロードによってはランキング上位の結果とは異なる結果になるためだ。

現状を率直にまとめると、プライバシー制約のある作業、大量処理、そしてモデルの仕様が途中で変更されないことが求められるあらゆる場面において、ローカル実行はもはや妥協案ではなく、単純に優れた選択肢となっています。一方、最先端の機能を活用する偶発的な利用においては、依然として適しておらず、ホスト型APIが賢明な解決策であり続けます。