ローカルLLMのモデル選定とコンテキスト長｜2026年版・Mac/Apple Silicon対応の選び方

◉ 2025.10.25 · 11min

こんにちは、パレイド技術部の夏目です。

ローカル LLM を手元のマシンで実用レベルに仕上げるには、「どのモデルを選び」「コンテキスト長（文脈長）をどう設定するか」の二点が要になります。本稿では Mac（Apple Silicon）を中心に、2026 年時点のモデル世代を踏まえてこの二点の勘所を整理します。題材は初心者にも扱いやすい Ollama に加え、Apple Silicon でネイティブに速い MLX にも触れます。

なお、量子化・KV キャッシュ・統合メモリ／独立メモリの構造といった「核の概念」は世代が変わっても効きます。変わったのは具体的なモデル名と VRAM の前提です。そこを 2026 年の景色に合わせて読み替えていきます。

導入から高速化・RAG までローカル LLM 全体を俯瞰したいときは、目次となるローカルLLM完全ガイド（Mac・Apple Silicon・2026年版）から入ると迷いません。本稿はその中の「モデル選定とコンテキスト長」を受け持つ一本です。

モデル選定で押さえる3要素

ローカルでモデルを安定して動かすには、次の 3 つを揃えて考えます。

パラメータ数（例：8B・26B・35B） — 知識量と精度を決める。大きいほど賢いが重く、メモリを多く使う
量子化（例：q4・q5・q8） — 数値精度を下げて軽量化する技術。少ないメモリで動くが、わずかに精度が落ちる
最大コンテキスト長 — どこまで前の文脈を覚えていられるか。長くすると記憶力は増すが、速度が落ち、メモリを圧迫する

量子化（Quantization） は、モデル内部の数値精度（16bit→8bit→4bit）を下げてメモリ消費を 30〜60% ほど削る技術です。q4・q5・q8 などの形式で配布され、低スペック環境でも大きなモデルを動かせます。ただし論理推論や計算系のタスクでは精度がわずかに落ちることがあります。基本方針はシンプルで、高精度を求めるなら非量子化＋短めの文脈、省メモリや長文重視なら量子化＋長めの文脈です。

2026年に選ばれるモデル（世代の更新）

ここが旧版から最も変わった部分です。2025 年の Llama 3 / Mistral / Qwen 2.5 という選択肢は、2026 年では一段世代が進んでいます。手元の用途別に、現行の有力候補を挙げます。

汎用・記事生成: gemma4（Google、Apache 2.0）、qwen3.5 / qwen3.6（Alibaba、オープンウェイト）。32GB の MacBook Air M5 クラスでも記事生成パイプラインに乗る実用域です
MoE（Mixture of Experts）で軽く速く: 例えば qwen3.5:35b-a3b は総パラメータ 35B でも、推論時に活性化するのは 3B 分だけ。知識は 35B、速度は 3B 級という設計で、密結合（Dense）の 27B より速いケースもあります
OpenAI 系オープンウェイト: gpt-oss:20b のような、ローカルで動かせる中型の選択肢
極小・エッジ志向: 1-bit の Bonsai 8B（1.15GB）、1.58-bit の Ternary Bonsai 8B。サイズが桁違いに小さく、スマホ・タブレットまで視野に入ります

ここで挙げた数字や得手不得手は、いずれも当サイトが実機（MacBook Air M5 など）で計測した一次情報に基づきます。詳細は本稿末尾の検証記事へ送りますので、選定の最終判断はそちらの数字と突き合わせてください。

用途	現行の出発点モデル	目安
記事生成・汎用チャット	gemma4 / qwen3.5・3.6	32GB Mac で実用域
速度重視（知識は欲しい）	MoE 系（例 qwen3.5:35b-a3b）	活性 3B 相当の速さ
省メモリ・エッジ	Bonsai 8B（1-bit）など	1〜2GB 級、スマホも視野

ひとつ正直に添えると、ツール呼び出し（function calling）など一部のタスクでは 1-bit 系の劣化が目立ちます。Bonsai 8B の BFCL スコアは 65.7 で、ベースの Qwen3 8B（81.0）から約 2 割落ちます。「軽い＝なんでも置き換えられる」ではなく、用途で割り切る前提です。

VRAM/メモリの目安 — 2026年の読み替え

モデルの「ファイルサイズ」と、実行時に必要な「メモリ（VRAM／RAM）」は一致しません。ロード時に重み・KV キャッシュ・中間テンソルを展開するため、実メモリはファイルサイズの 1.5〜3 倍が目安です。例えば 4〜6GB の量子化 7B でも実行時は 8〜12GB を使います。

旧版では「個人向け GPU は VRAM 16〜24GB が上限」と書いていましたが、これは独立 GPU（CUDA）を前提にした 2025 年の見方です。2026 年は前提が二つ動きました。ひとつは Apple Silicon の統合メモリで、32GB／64GB といった容量をそのまま GPU から使えるため、独立 GPU の VRAM 枠に縛られず大型モデルがロードできます。もうひとつは 量子化と 1-bit／1.58-bit 系の進歩で、同じメモリでより大きな「知識量」を載せられるようになりました。

ただし「載る」と「速い」は別です。実機では、qwen3.5:35b（ファイル 23GB）が実メモリ約 30GB で生成 16 tok/s 前後、対して 1.15GB の Bonsai 8B が 26〜30 tok/s。統合メモリは容量で勝っても、長い文脈や高負荷では帯域で頭打ちになります。判断の実務はこの 3 点に集約されます。

ファイルサイズ × 2〜3 倍を実メモリの目安にする
メモリが足りなければ量子化版（q4〜q5）を選ぶ
それでも厳しければコンテキスト長を小さくして KV キャッシュを抑える

コンテキスト長の設定

モデルにはそれぞれ固有の最大サポートコンテキスト長があり（32k・128k など）、ローカルでは実行時に明示指定できます。用途別の出発点は下表のとおりです。

用途	推奨コンテキスト長
短文QA・チャット	4k〜8k
コードレビュー・中長文解析	8k〜16k
大規模ドキュメントの要約・分析	16k〜32k

Ollama の既定は多くのモデルで num_ctx が 4096 と短めです。すべてのモデルが安全に動く下限なので、長文要約や会話履歴を保ちたいなら明示的に上げます。ただし上げ過ぎは逆効果で、(1) 参照トークンが増えて応答が遅くなり、(2) KV キャッシュ（文脈保持用のメモリ）が肥大して VRAM／RAM を圧迫し、(3) ロード直後の初動も鈍ります。逆に小さすぎると入力先頭が切られ（truncating input prompt）、前の指示や会話を見失います。

実務上は 8k〜16k あたりで速度と品質を測り、足りなければ伸ばすのが効率的です。スライダーを上げてもモデルが非対応の範囲は自動で切り捨てられ、下げればその値までしか保持しません。長文をそのまま投げるより、RAG（検索で関連チャンクを抽出して短い文脈に投入）の方がコスト・品質のバランスが良い場面も多くあります。

頻用する設定は Modelfile で固定しておくと楽です。

# Modelfile: ベースモデルと既定パラメータを固定
FROM qwen3.5:9b
PARAMETER num_ctx 16384
PARAMETER temperature 0.1

# カスタムモデルとして登録（以後オプション指定が不要に）
ollama create qwen35-16k -f Modelfile

Mac と Windows/Linux のメモリ構造

実行速度は GPU 単体の性能だけでなく、メモリの構造と帯域に大きく左右されます。Mac（Apple Silicon）は Metal による統合メモリ（Unified Memory）、Windows／Linux の GPU は CUDA／ROCm による独立メモリ（Discrete Memory）を採用しており、この差が動作特性に直結します。

項目	Metal（Apple Silicon）	CUDA（NVIDIA）	ROCm（AMD）
構造	統合メモリ（CPU/GPU 共有）	独立メモリ（別々）	独立メモリ（別々）
メモリ帯域	約 200〜400 GB/s（M2/M3 系）	約 700〜1000 GB/s（4090 等）	約 500〜900 GB/s
VRAM 容量	システムと共有（〜64GB など）	GPU 専用（8〜24GB など）	GPU 専用（8〜24GB など）
傾向	大型も載るが長文で帯域不足	高速・安定、長文に強い	CUDA に近いが最適化やや遅れ

要点はこうです。Metal は転送コストがない代わりに GPU 専用帯域がないため、容量で大型モデルを載せられても、長い文脈や高負荷では CPU と帯域を取り合って速度が落ちます。一方 CUDA/ROCm は転送コストがある代わりに GPU が全力で回せるので、一度ロードすれば長文・連続生成で速い。「Mac では動くのに遅い」「Windows では速いがメモリが足りない」という現象は、この構造差で説明できます。

なお Mac では、Ollama の MLX（Apple Silicon ネイティブの推論フレームワーク）対応が状況を変えつつあります。MLX 経由だと M5 系の GPU を活かして同じモデルでも体感が変わるため、Mac で速さを求めるなら MLX 対応モデルを優先するのが 2026 年の現実解です。

まとめ

ローカル LLM を実務に乗せる核は、「世代の合ったモデルを選ぶ」「コンテキスト長を必要十分に保つ」「速度・品質・メモリをバランスさせる」の 3 点です。2026 年は gemma4・qwen3.5/3.6・MoE・1bit 系と選択肢が一気に広がり、Apple Silicon の統合メモリと MLX で「Mac で大型を動かす」が現実になりました。まずは 8k〜16k で測り、必要に応じて文脈を伸ばすかモデルを上げる——この段階的アプローチで迷わず進められます。

具体的なモデルごとの実測値は、当サイトの実機検証記事にまとめています。選定の最終判断は以下の数字と突き合わせてください。

パレイドOllama MLX対応で Qwen3.5 を試す｜35Bが27Bより速い？MoEの実力をベンチマークこんにちは、パレイド技術部です。 Ollama が v0.19 で Apple MLX フレームワークに対応しました。M5 チップの GPU Neural Ac… パレイドMoE 三つ巴｜gemma4 vs Qwen3.5 vs Qwen3.6、32GB MacBook Air M5 で記事生成に最適な MoE はどれかこんにちは、パレイド技術部です。昨日 (4/17) の記事で、新しくオープンウェイト化された Qwen3.6-35B-A3B を Qwen3.5 と比較し、記… パレイドAI自動編集に挑む(4)｜Gemma 4 で記事は書けるか？記事生成パイプラインで Qwen3.5 と実戦比較こんにちは、パレイド技術部です。これまで数回にわたり、ローカル LLM の速度ベンチマークを行ってきました。速度はわかりました。MoE は速い、De… パレイドQwen 3.6 オープンウェイト版の実力は？記事執筆用途の 32GB MacBook Air M5 で Qwen 3.5 と世代対決こんにちは、パレイド技術部です。先週 (4/7) の記事で、Alibaba が発表したフラッグシップ LLM Qwen 3.6-Plus のニュースを取り上げ… パレイド1.58-bit LLM「Ternary Bonsai 8B」が登場｜MLXネイティブ対応、M5 Mac で前作と比較してみたこんにちは、パレイド技術部です。前回の記事で取り上げた PrismML が、約2週間のインターバルで続報を出してきました。今度は 1.58-bit の Ter… パレイド世界初の1-bit LLM「Bonsai 8B」が登場｜1.15GBでLlama 3.1超え、Macで動かしてみたこんにちは、パレイド技術部です。 Caltech 発の AI ラボ PrismML が、世界初の商用レベル 1-bit LLM「Bonsai 8B」を Apa…