ローカルAIの最低スペックはどこまで低くて良いか──8GBメモリの実機で確かめた

「ローカルAI 最低スペック」で検索すると、多くの記事が「VRAM 8GB以上」「7Bモデルなら動く」という目安を示している。だがその目安は、CPU・OS・他のアプリが何も動いていない静かな環境が前提になっていることが多い。

手元に統合メモリ8GBのMacBook Air(Apple M2)があったので、Ollamaを実際に動かし、どのサイズのモデルまでが「使い物になる速度」で、どこから崩れるのかを測った。

3行まとめ

1. 統合メモリ8GBのMacBook Air(Apple M2)で実測したところ、1B〜3B級のモデルは毎秒44〜75トークンで問題なく応答したが、8Bモデル(4.9GB、Q4_K_M量子化)は生成速度が毎秒0.88トークンまで落ち込んだ
2. 原因はディスク容量ではなくメモリのスワップだった。8Bモデルの読み込み時、5,120MB中4,646.69MB(約91%)のスワップ領域が使用されていた
3. 実用的な速度を維持できた目安は、実測ベースでファイルサイズ2GB前後・パラメータ数3B程度まで。7B〜8Bは「起動はする」が「使える速度ではない」という結果になった

検証環境

• 機種: MacBook Air / Apple M2 / CPU 8コア(性能4+効率4) / 統合メモリ8GB
• OS: macOS 15.1.1
• Ollama: v0.33.0(Homebrewでインストール済み)
• ストレージ空き: 23GB(内蔵ストレージの空き容量。検証時点で複数のモデル計約11GBをすでにダウンロード済みの状態)

先に断っておくと、この機材は検証専用の静かな1台ではない。他のツールやプロセスが並行して動いている状態での計測になった。数値の意味と限界は「正直に言うと」の章にまとめる。

計測前のtopの出力では、物理メモリ8,192MBのうち7,457MBが使用中で、空きは164MBしかなかった。この状態からモデルを読み込んでいる。

1B〜3Bは、体感で「使える」速度だった

まず小さいモデルから試した。ollama run <モデル> --verboseで表示されるeval rate(生成速度)を基準にする。

「Pythonでリストを逆順にする関数を1行で書いて」とqwen2.5-coder:1.5bに投げると、my_list[::-1]という正しい答えが3〜4秒で返ってきた。日本語の一問一答(「日本の首都は?」)なら1〜3秒台で完結する。8GBメモリのMacBook Airでも、1B〜3B級のモデルは体感でストレスのない速度で動く。

8Bモデルで何が起きたか

次に、すでにダウンロード済みだったllama3.1:8b(ファイルサイズ4.9GB、Ollama公式ページで確認した既定の量子化はQ4_K_M=4bit量子化)を同じ条件で試した。

結果:

total duration:       35.286146667s
load duration:        27.3509245s
prompt eval rate:     5.34 tokens/s
eval count:           4 token(s)
eval duration:        4.520714s
eval rate:            0.88 tokens/s

モデルの読み込みだけで27.35秒。そこから「日本の首都は?」への回答("東京です。"の4トークン)を生成するのに4.52秒かかり、生成速度は毎秒0.88トークンまで落ちた。3Bモデルの44.70トークン/秒と比べると、単純計算で約50分の1の速度になる。

このときsysctl vm.swapusageを確認すると、macOSのスワップ領域は総容量5,120MBのうち4,646.69MB(約91%)が使用中だった。8Bモデルのファイルサイズ(4.9GB)が、すでに164MBしか空きがなかった物理メモリに収まりきらず、システムがディスク上のスワップ領域を使って処理を続けていたと考えられる。ディスクへの読み書きはメモリアクセスよりずっと遅いので、これが生成速度が1トークン/秒を切った直接の原因とみて間違いない。

ollama stop llama3.1:8bでモデルを解放した後、qwen2.5:3bを再度動かしても、スワップ使用量はすぐには元に戻らなかった。数十秒後に確認した時点でもまだ4,142.69MB使用中で、macOSがスワップを解放するには時間がかかることも分かった。

なぜ「Q4量子化すれば8Bも動く」が崩れたか

「量子化すれば大きいモデルも軽くなる」という説明は間違っていない。実際、llama3.1:8bは素の重み(80億パラメータ×2バイト=約16GB相当)ではなく、Ollama側が既定で配信しているQ4_K_M(4bit)版で4.9GBまで圧縮されている。

だが8GBメモリという条件では、この「圧縮後のサイズ」がそのまま罠になる。OS・バックグラウンドプロセス・Ollamaサーバー自体がすでに7GB超のメモリを使っている状態では、4.9GBのモデルを読み込む余地は物理メモリ側にほとんど残っていない。量子化は「モデルを小さくする」施策であって、「空きメモリを作る」施策ではない。空きが数百MBしかない機体では、量子化された4.9GBのファイルでも収まりきらずスワップに落ちる。

今回の結果を見る限り、8GBメモリのMac(他のアプリを併用する現実的な使い方)で実用的な生成速度を維持できる目安は、ファイルサイズにして2GB前後、パラメータ数で3B程度までというのが実測ベースの線になる。7B〜8Bクラスは「一応起動はする」が「使える速度ではない」という状態だった。

コンテキスト長を伸ばすと、この余裕はさらに減る

今回の計測は「日本の首都は?」のような短い一問一答にとどめたが、長い文章を扱えばこの余裕はさらに減るはずだ。Ollama公式ドキュメント「Context length」（curlで確認）には、コンテキスト長（モデルがメモリ上に保持できる最大トークン数）のデフォルト値が、VRAM容量に応じて次のように決まると明記されている。

"Ollama defaults to the following context lengths based on VRAM: < 24 GiB VRAM: 4k context, 24-48 GiB VRAM: 32k context, >= 48 GiB VRAM: 256k context"

24GiB未満のVRAM環境では既定で4kトークンに制限されるとのことで、今回の8GBメモリ機はこの最小区分に該当する。同ドキュメントは「コンテキスト長を大きくするほど、モデルを動かすのに必要なメモリが増える」とも明記しており、今回の8Bモデルで起きたスワップは、コンテキスト長を既定の短い設定のままで一問一答をこなした結果だ。要約や長いコーディングセッションのようにコンテキストを伸ばす使い方をすれば、同じ8Bモデルでもさらに早く同じ状態（あるいはそれ以上のスワップ）に陥る可能性が高い。ただし、このドキュメントの数値区分はVRAM（GPU専用メモリ）を基準にしたもので、Apple Siliconの統合メモリ環境にそのまま同じ閾値が適用されるかどうかまでは、この記事では確認していない。

ストレージの壁は、今回は見えなかった

設計段階では「空き19GBという制約」も検証材料になる想定だったが、実際に計測した時点でのストレージ空きは23GB(ダウンロード済みモデル計約11GB込み)で、今回試した1B〜8Bクラスのモデル(986MB〜4.9GB)を保存する分には余裕があった。

ボトルネックになったのはディスク容量ではなく、メモリとスワップだった。ここは設計時の想定と実測がずれた点として、修正しておく。ただし、これは「ディスクが制約にならない」という意味ではない。13B〜70Bクラスのモデルはファイルサイズが8GB〜40GB超になる(Ollama Libraryの一覧で確認できる)。今回の23GBという空き容量では、大型モデルを複数保存しようとすればすぐに足りなくなる計算になるが、これは実測ではなくファイルサイズからの算出であることを断っておく。

判断の目安

実測から言えるのはここまでだ。

• 8GBメモリのMacで、他の作業と並行してローカルAIを動かすなら、3B前後までのモデルを選ぶと生成速度でストレスは出にくい
• 7B〜8Bクラスを試す場合、それ単体を動かす前提でも、他のアプリ(ブラウザのタブを多数開いた状態など)を閉じてから起動しないと、スワップに落ちて実用速度を割り込む可能性がある
• 量子化版だから軽い、は正しいが、空きメモリがゼロに近い機体では別問題になる。ファイルサイズだけでなく、起動前の空きメモリをtopやアクティビティモニタで確認してから判断した方がいい

モデル選びの一覧やVRAMの目安表はローカルLLMとは何か、モデルごとの特徴比較はローカルLLMおすすめモデル10選にまとめている。GPUを持たない環境での画像生成側の検証はローカルAIの画像生成は単体グラボなしでも動くのか、コーディング用途での実用性はローカルLLMでコーディングエージェントは実用になるかで扱っている。

静かな専用機での実測ではないことを明記しておく

• 検証機は静かな1台ではなかった。 計測中、他のプロセスがバックグラウンドで動いており(ollama psで自分が起動していないqwen2.5-coder:3bのセッションが並行して見えた)、CPU・メモリ・スワップを取り合っている状態での数値になっている。絶対値(トークン/秒)は、他に何も動いていない専用機よりも悪い方に振れている可能性が高い。ただし「1B〜3Bは実用速度、8Bはスワップで崩れる」という相対的な傾向は、この負荷状況下でも明確に出た
• モデルのダウンロード自体は自分で行っていない。 検証を始めた時点で5つのモデル(計11GB前後)がすでに存在しており、ダウンロード時間やダウンロード中のディスク挙動は観測できていない
• 短い一問一答しか試していない。 Ollama公式ドキュメントで「コンテキスト長を伸ばすほど必要メモリが増える」という一般論は確認できたが、実際に長文生成や長いコンテキストを維持する使い方(要約・長いコーディングセッションなど)を、この8GB機で試してどこまで崩れるかは測っていない
• 3Bと8Bの間(4B〜7B級)は試していない。 「どこまでが3B」「どこからが8B」の境目を精密に特定したわけではなく、今回試した具体的なサイズでの二点比較にとどまる
• Windows機や、統合メモリではなくVRAM+システムRAMに分かれた構成では試していない。 Apple Siliconの統合メモリアーキテクチャ特有の挙動である可能性があり、他機種にそのまま当てはめられるかは分からない。Ollama公式のコンテキスト長デフォルト値もVRAM基準の区分であり、統合メモリ環境に同じ閾値が適用されるかは確認していない
• スワップが元の水準に戻るまでの時間は計測していない。 モデル解放後もスワップ使用量がすぐには下がらなかったことは確認したが、どれくらい待てば、あるいは何をすれば解消するかは追っていない