モデルをローカルで動かすということはダウンロードすることであり、ダウンロードしたものは残り続けます。ローカル推論を簡単にするツールはどれも、もう1つモデルを試すことも簡単にしますが、この1か月の試行が合計でどれだけになったかを教えてくれるツールはありません。私たちがスキャンしているMacでは、Ollamaで午後を過ごしたことのある人にとってAIモデルのカテゴリが最大の項目であり、ツールのどこにも合計が表示されないため、最も驚かれる項目でもあります。

この記事では、各ツールがファイルをどこに保存するのか、サイズはどれくらいか、テストによってなぜ増えていくのか、そして取り戻せないものを失わずに削除できるのはどれかを説明します。

モデルの大きさ

サイズはパラメータ数と量子化によって決まります。これらのツールがダウンロードするフォーマットについての目安は次のとおりです。

モデルサイズ 4ビット（Ollama、MLX、ほとんどのGGUF） 8ビット 16ビット（公開時のHugging Face safetensors）
1から3B 1から2 GB 2から3.5 GB 2.5から7 GB
7から9B 4から5.5 GB 8から9.5 GB 14から18 GB
12から14B 7から9 GB 13から15 GB 25から30 GB
27から35B 16から20 GB 32から36 GB 55から70 GB
70B 38から43 GB 70から75 GB 130から145 GB

サイズは重みのみで、2026年9月時点の値を丸めたものです。量子化されていないHugging Faceのモデルは16ビットの列に該当し、量子化されていない8Bモデル1つが4ビットのモデル3つより多くの容量を取るのはそのためです。

一緒に付いてくるその他のファイルとして、Whisper largeは約3 GB、Stable DiffusionやFluxのような画像モデルはチェックポイントあたり4から25 GB、埋め込みモデルは1つあたり0.3から2 GB、視覚言語モデルは1から2 GBの2つ目のエンコーダを同梱しています。

各ツールの保存場所

Ollamaはすべてを~/.ollama/modelsの下に保存します。重みはコンテンツアドレス方式のblobで、タグごとのマニフェストがそれを指しているため、同じファイルを元にした2つのタグは共有されます。同じモデルの2つの量子化は共有されません。ollama listは各モデルのサイズを表示し、ollama rmは1つを削除しますが、フォルダ全体の容量を表示するコマンドはありません。

LM StudioはダウンロードしたGGUFとMLXのファイルを~/.lmstudio/modelsの下に（古いバージョンでは~/.cache/lm-studio/modelsに）、公開者とモデルごとに整理して保存します。各ダウンロードは完全なファイルです。1つのモデルのQ4、Q5、Q8ビルドを試すと、完全なコピーが3つできます。

Hugging Faceは人を驚かせるものです。transformers、diffusers、sentence-transformers、huggingface_hubの各ライブラリはすべて~/.cache/huggingface/hubにダウンロードし、リポジトリごとに1つのフォルダ、リビジョンごとに1つのスナップショットを作ります。モデルを取得し、作者が修正をプッシュした後にもう一度取得すると、スナップショットは2つになります。スクリプトでモデルを一度読み込めば、それはずっと残ります。huggingface-cli scan-cacheは全体をサイズ付きで表示し、huggingface-cli delete-cacheはリビジョンの削除を対話的に案内します。データセットは~/.cache/huggingface/datasetsに保存され、モデルより大きくなることもあります。

Appleシリコン上のMLXは、mlx-communityのモデルに同じHugging Faceのハブキャッシュを使います。mlx_lm.convertで自分でモデルを変換した場合、出力は指定した場所（多くはプロジェクトフォルダ）に置かれ、元の16ビットの重みはハブキャッシュに残ったままです。変換1回でモデルのフルサイズがもう1つ分増えます。

その他すべて。 Python環境はvenvごとに2から4 GBのPyTorchを取り込み、MLプロジェクトがいくつかあるMacにはそれがいくつもあります。DockerのモデルランナーとOllamaのDockerイメージは、Dockerのディスクイメージの中に独自のコピーを持ちます。Jupyterのチェックポイントと.ipynb_checkpointsフォルダはノートブックのコピーを保持していて、個々は小さいものの数が多くなります。

テストで膨らむ理由

評価の午後はこのように進みます。Qwen 2.5 7Bと比較するためにOllamaでLlama 3.1 8Bを取得します。9 GBです。どちらかが遅いので、LM StudioでQ8ビルドを試します。さらに8 GBです。論文で14Bの推論モデルが言及されていたので試します。9 GBです。文書を埋め込みたいので、スクリプトが埋め込みモデルをダウンロードし、サンプルをそのままコピーしたために、デモで使われていたチャットモデルの16ビット版も一緒にダウンロードします。15 GBです。このMacではMLXの方が速いはずなのでMLXを試すと、4ビットの変換が、変換元の16ビットのオリジナルの隣にさらに4.5 GB増えます。

これで約46 GB、5つのツール、そして今も使っているモデルは1つです。この流れの中に間違いは1つもありません。評価とはそういうものです。ビルドキャッシュとの違いは、ツールが代わりに片付けてくれないことと、ファイルが大きいためにその数個が、余裕のあるディスクといっぱいのディスクの差になることです。

私たちがスキャンしている環境では、AIを中心に開発している人のMacはこのカテゴリに80 GB以上を抱えています。ローカルモデルをときどき使うPythonおよびMLエンジニアでも40から50 GBを抱えています。環境別の完全な表を参照してください。

削除しても安全なもの

これらはすべてダウンロードで戻ってくるため、Cache Goblinはすべてのモデルを「安全」ではなく「復元可能」に分類します。一覧にして、それぞれのサイズを表示し、ゴミ箱に移動する前に確認します。ダウンロードしたモデルには、あなたのMac固有のものは何もありません。

例外は自分で作ったファイルです。自分で学習させたファインチューン、LoRAアダプタ、もう一度調べ直さなければならない設定で変換したモデル、imatrixを使って自分で量子化したGGUFなどです。これらはダウンロードしたものの隣にあり、見た目も同じですが、Cache Goblinは最近触ったプロジェクトフォルダ内の重みをあなたのものとして扱い、削除を提案せずに表示だけします。

実践的な順序は次のとおりです。

  1. ollama listを実行し、一度試しただけのモデルを削除します。実際に呼び出しているものは残します。
  2. huggingface-cli scan-cacheを実行し、古いリビジョンと、ダウンロードした覚えのないものを削除します。通常はこれが最大の数字です。
  3. LM Studioのモデルフォルダで1つのモデルの重複した量子化を探し、1つだけ残します。
  4. 4ビットのMLX変換でしか実行していないモデルの16ビットのオリジナルがハブキャッシュにないか確認します。
  5. 終了したプロジェクトのPython環境を削除します。PyTorchはコピーごとに数GBあります。

あるいはスキャンを実行します。Cache GoblinはOllama、LM Studio、Hugging Face、MLXのモデルを名前とサイズ付きで1か所に一覧表示し、ツールが決して表示しない合計を示し、「復元可能」ボタンで選んだものを削除します。

Cache Goblinを無料でダウンロードして、午後のテストが何を残したかを確認してください。