この記事の要点
- 当サイトの2TB のデータ用ドライブは、モデルも生成物も消さずに残した結果、空きが 149.5 GB まで減っていた。
- モデル側の容量は本数だけでは決まらず、1本の大きさで決まった。画像・動画モデルの本体は 12 件で 191.9 GB。
- 生成物は動画で桁が変わり、1件あたりは png が 1.6 MB、mp4 が 90.1 MB。
数字はすべて、Windows 11 の1台の環境で 2026年9月6日に全ファイルを数えた時点の値で、ファイルサイズの合計であってドライブが確保した量ではない。このドライブには AI と無関係のファイルも同居しており、空きの値もその状態で測ったものになる。この1台が何を入れて何を残したかの結果であり、必要量の基準にはならない。読み書きの速度は測っていない。
2TBのSSDには何が入っているのか
ここから挙げるのは、当サイトの検証環境で数えた結果である。LLM と画像・動画生成をどちらも回し、モデルも生成物も消さずに残してきた 2TB のデータ用ドライブは、容量 2048.4 GB のうち空きが 149.5 GB まで減っていた。
中身を領域別に集計すると、LLM 側のツールとモデルで 709.9 GB、ComfyUI 本体と画像・動画モデルで 448.6 GB、生成物を書き出すフォルダで 168.4 GB。AI に関わるのはこの3つで、合わせて 1326.9 GB になる。ほかに AI と無関係の動画ファイル 245.3 GB も同居している。さらにシステムドライブ側にも AI 関連が 269.5 GB あり、両方あわせると 1596.4 GB が AI のために使われていることになる。
| 領域 | 実消費 | 実体数 |
|---|---|---|
| LLM 側のツールとモデル（Ollama・llama.cpp・GGUF） | 709.9 GB | 398804 件 |
| ComfyUI 本体と画像・動画モデル | 448.6 GB | 91509 件 |
| AI と無関係の動画ファイル | 245.3 GB | 2975 件 |
| ComfyUI が生成物を書き出すフォルダ | 168.4 GB | 16663 件 |
| クラウドストレージの同期フォルダ | 17.2 GB | 24768 件 |
| バックアップ用フォルダ | 10.5 GB | 1919 件 |
| 掲載外（AI と関係のない小さいファイル群） | 7.9 GB | 15922 件 |
| 走査できた合計（同じ実体を1回だけ数えた値） | 1607.8 GB | 552560 件 |
| 同じ範囲を単純に足し上げた値 | 1966.7 GB | — |
| 差（同じ実体を複数のパスから数えていたぶん） | 358.8 GB | — |
領域別の内訳で目を引くのは実体数の偏りである。LLM 側は 398804 件と件数が突出しているが、この領域はモデルとツール本体・作業ファイルを分けて数えていない。単純に足し上げた 1966.7 GB と、走査できた 1607.8 GB の差 358.8 GB が何なのかは、見かけの合計と実消費のずれとして、あとの節で扱う。
測定の前提と数え方
本記事の容量の内訳は2026年9月6日時点・当該構成での測定に基づく。測定に使ったのは Windows 11 の1台で、ドライブの構成と空き容量は Get-PhysicalDisk と shutil.disk_usage で取得した。
| ドライブ | 型番 | 容量 | 空き |
|---|---|---|---|
| システムドライブ | CT2000T500SSD8（NVMe SSD） | 1999.2 GB | 577.6 GB |
| データ用ドライブ | Hanye HE80-2TGHS（NVMe SSD） | 2048.4 GB | 149.5 GB |
型番は測定条件の記録であって、製品の優劣や現在入手できるかどうかを示すものではない。空きの値も測ったその時点のものである。
走査は os.walk と os.stat で全ファイルを辿り、（デバイス番号, ファイルID）が同じものは1回だけ数えた。ごみ箱とシステムボリューム情報は対象から外している。データ用ドライブの使用量が 1898.9 GB なのに対して走査できたのは 1607.8 GB で、その差の内訳は測っていない。走査対象から外した領域のほか、ファイルサイズの合計には現れない割り当て単位の端数やファイルシステム自身の領域も、この差に含まれる。
数え方の定義は2つある。ひとつ、各表の「実消費」は同じ実体を1回だけ数えたファイルサイズの合計であり、ドライブが確保した量とは一致しない。ふたつ、複数のフォルダから同じ実体に届く場合は、最初に数えたフォルダにだけ計上している。この数え方は同じ（デバイス番号, ファイルID）に届くパスを1つにまとめるため、ハードリンクに限らず同じ実体に届く複数のパスがまとめられる。なお本文と表の GB 値は元のバイト値をそれぞれ丸めて表示しているため、表示された値どうしで加減算すると 0.1 GB 程度ずれることがある。
測っているのは容量だけで、読み書きの速度やモデルの読み込みにかかる時間は測定していない。速度がどこに関わるかの整理はローカルAIのSSD・メモリ選びは「どこに効くか」が重要｜VRAMとの役割分担を見極める、読み出しの仕組みそのものはGPUがSSDを直接読む仕組み｜cuFileオープンソース化とローカルAIでモデルロードが速くなる条件で別に扱っている。
容量を決めるのは本数だけではなく1本の大きさ
ComfyUI の models フォルダは、合計 108 件で 440.6 GB。1本あたりにすると 4.1 GB になるが、この平均値は内訳を平らにしすぎている。画像・動画の本体が入る diffusion_models はわずか 12 件で 191.9 GB、1本あたり 16.0 GB に達する。
| フォルダ | 実消費 | ファイル数 | 1本あたり |
|---|---|---|---|
| diffusion_models（画像・動画の本体） | 191.9 GB | 12 件 | 16.0 GB |
| checkpoints（一体型のモデル） | 113.8 GB | 8 件 | 14.2 GB |
| text_encoders（プロンプトを解釈する側） | 75.6 GB | 13 件 | 5.8 GB |
| clip | 24.8 GB | 5 件 | 5.0 GB |
| unet | 22.6 GB | 3 件 | 7.5 GB |
| vae | 10.5 GB | 9 件 | 1.2 GB |
| loras | 1.1 GB | 3 件 | 0.4 GB |
| upscale_models | 0.2 GB | 4 件 | 0.1 GB |
| 掲載外（設定ファイル等、容量をほとんど持たないもの） | 0.03 GB | 51 件 | — |
| 合計（同じ実体を1回だけ数えた値） | 440.6 GB | 108 件 | 4.1 GB |
| 同じ一式を単純に足し上げた値 | 502.0 GB | — | — |
| 差（このフォルダ内での共有分） | 61.5 GB | — | — |
このフォルダに何が入るかは使ったモデルで決まる値であり、ここに挙げたのは画像モデルと動画モデルを両方入れた環境で数えた値である。フォルダ別の行は、共有されている実体を最初に出会った1つのフォルダにだけ計上しているため、8つのフォルダに載っている実体の合計は全体の実体数より少ない。残りは容量をほとんど持たない補助ファイルだった。
「1本あたり」の列は、このフォルダに入っている本数で割った値である。他の構成へ掛ける係数ではなく、この種類のモデル1本がどれくらいの規模になりやすいかの目安として読む。実際の見込み量は、入れるつもりのモデルのファイルサイズを配布元で確かめて足すほうが近い。逆に、ファイル数が少ないフォルダほど1本が大きい、という読み替えは成り立たない。loras は 3 件で 1本あたり 0.4 GB、unet も 3 件だが 1本あたり 7.5 GB と、同じ件数でも規模が違う。
ComfyUI の公式ドキュメントも、生成モデルは1つで数ギガバイトになることが多く、ダウンロードや同期の際にはディスク容量と時間を見込む必要があると記している。1本の大きさは量子化フォーマットの選び方でも変わるため、そちらはローカルLLMの量子化フォーマットの選び方｜Q4_K_M〜Q8・QATを精度・サイズと16GB VRAMで見極めるにまとめてある。
LLM 側も同じ見方になる。Ollama のモデル保存フォルダのマニフェストから、タグごとの層サイズを合計した。
| タグ | 論理サイズ |
|---|---|
| qwen3.6:35b-a3b | 23.94 GB |
| qwen3.5:35b | 23.87 GB |
| qwen3.5:35b-a3b | 23.87 GB |
| Ornith-1.0-35B-GGUF:Q4_K_M | 21.17 GB |
| qwen3:32b | 20.20 GB |
| gemma4:31b | 19.87 GB |
| qwen3-coder:30b | 18.56 GB |
| gemma4:26b | 17.99 GB |
論理サイズはマニフェストの申告値で、実ファイルの合計とは別に数えている。この環境で作成したローカル派生タグは一覧から除いたが、残る中には公開レジストリではなく Hugging Face から取り込んで名前を付けたもの（Ornith-1.0-35B-GGUF:Q4_K_M）も含まれる。大きい側のタグは 17.99 GB から 23.94 GB の帯に収まっている。これはこの環境が 30B 級前後を中心に置いた結果で、扱うモデルの規模が違えば帯そのものが動く。
生成物は動画で桁が変わる
ComfyUI が生成物を書き出すフォルダを拡張子別に集計し、本数の多い4種を挙げた。このフォルダには生成物以外のファイルも入っている。
| 種類 | 本数 | 実消費 | 1件あたり |
|---|---|---|---|
| py（付随ファイル） | 4619 件 | 0.1 GB | 0.0 MB |
| pyc（付随ファイル） | 3799 件 | 0.1 GB | 0.0 MB |
| png（画像） | 2840 件 | 4.5 GB | 1.6 MB |
| mp4（動画） | 1809 件 | 163.0 GB | 90.1 MB |
本数だけを見れば py と pyc が最も多いが、容量はほとんど持たない。画像は 2840 件で 4.5 GB、動画は 1809 件で 163.0 GB。フォルダ全体 168.4 GB のうち、mp4 だけで 163.0 GB を占めている。1件あたりでは png が 1.6 MB、mp4 が 90.1 MB。生成物の見積もりを動かすのはこの1件あたりの差である。解像度・長さ・保存形式で1件あたりの大きさは変わり、いずれも消さずに貯め続けた場合の値になる。
増え方は月ごとに大きく違う。ファイルの更新時刻の年月で分類し、増えた量が 100MB に満たない月を省いた集計が月別の内訳になる。
| 年月 | 件数 | その月に増えた量 |
|---|---|---|
| 2024-01 | 2876 件 | 0.1 GB |
| 2026-01 | 596 件 | 0.3 GB |
| 2026-02 | 19 件 | 4.4 GB |
| 2026-03 | 9890 件 | 137.6 GB |
| 2026-04 | 943 件 | 18.0 GB |
| 2026-05 | 223 件 | 6.0 GB |
| 2026-06 | 163 件 | 0.2 GB |
| 2026-07 | 756 件 | 0.8 GB |
| 2026-08 | 749 件 | 0.7 GB |
| 2026-09 | 448 件 | 0.4 GB |
動画を集中的に回した 2026-03 の1か月で 137.6 GB が増え、翌月も 18.0 GB。この2か月がフォルダの大半を作っている。19 件で 4.4 GB の 2026-02 のように、件数が少なくても量が出る月もある。なお更新時刻は後から変わりうるため、生成した月と一致しないファイルが混じる可能性がある。件数の列には py・pyc のような生成物でないファイルも入っており、生成本数としては読めない。月別に読めるのは増えた量のほうである。
見かけの合計は実際より大きく出る
領域別の内訳には、単純に足し上げた 1966.7 GB と、同じ実体を1回だけ数えた 1607.8 GB という2つの合計が並んでいる。差の 358.8 GB は、同じ実体に複数のパスから届いていたぶんである。この差がどう生まれるかは、実際に作って空き容量を読めば確認できる。
データ用ドライブ上に 1,073,741,824 バイトのファイルを作り、ハードリンクとコピーを1つずつ追加して、その都度ドライブの空き容量を読んだ。測定後に3つとも削除している。
| 操作 | 見かけのサイズ | 空き容量の減少 |
|---|---|---|
| 1GiBファイルを作成 | 1.07 GB | 1.07 GB |
| ハードリンクを1本追加 | 1.07 GB | 0.00 GB |
| 同じ内容をコピー | 1.07 GB | 1.04 GB |
ハードリンクは見かけ上 1.07 GB のファイルがもう1つ増えるのに、空き容量は 0.00 GB しか減らない。コピーは 1.04 GB 減る。ただしコピーで減った 1.04 GB は、作成時の 1.07 GB より小さい。通常の非圧縮・非スパースのファイルでは、割り当て単位の丸めは消費が増える側にしか出ない。この差はその丸めだけでは説明が付かない。原因は特定していない。3操作とも1回ずつの測定で、測定中に他の書き込みや削除を止めてもいない。
Microsoft の公式ドキュメントによれば、NTFS のハードリンクは同じボリューム上の1つのファイルを複数のパスから参照する仕組みで、ディレクトリには使えず、ボリュームをまたぐこともできない。フォルダごとに足し上げた数字が実際の消費より大きく出るのは、同じ実体に複数のパスから届いているためである。ハードリンクはその作られ方のひとつで、この走査は（デバイス番号, ファイルID）が同じかどうかしか見ていないため、どの作られ方かは区別していない。
同じずれは ComfyUI の models フォルダの中にもある。単純に足し上げた 502.0 GB に対して、同じ実体を1回だけ数えると 440.6 GB。差は 61.5 GB ある。Ollama 側も同型で、タグの論理サイズを足し上げた値と、実際に置かれている層の合計は一致しない。
| 見方 | 値 |
|---|---|
| タグの論理サイズを足し上げた値 | 343.6 GB |
| 実際に置かれている層（blob）の合計 | 286.6 GB |
| 差（同じ層を複数のタグが指しているぶん） | 57.0 GB |
| タグ数 | 30 件 |
| 層の数 | 72 件 |
| 1タグあたりの論理サイズの中央値 | 9.28 GB |
30 件のタグを申告値どおりに足すと 343.6 GB だが、実際に置かれている層は 72 件で 286.6 GB。同じ層を複数のタグが指す場合、論理サイズの合計は実際の消費より大きく出る。タグ一覧の申告値をそのまま足して見積もると、この 57.0 GB のぶんだけ過大に出ることになる。
逆に、同じ内容が別の場所にあれば必ず合計から消える、という読み方も成り立たない。同じドライブ上に別実体として2本置けば、全ファイル走査の合計には2本分きちんと現れる。合計に現れないのは、片方が走査対象の外にある場合か、タグ名やファイル名の一覧から見積もった場合に限られる。
同じモデルが別の場所に増える
置き場が増えると、同じ内容が別実体として二重に置かれることがある。システムドライブ側とデータ用ドライブ側のモデル置き場をまとめて走査し、1GB を超えるファイルのうちサイズが一致するものを候補として拾い、その候補についてはファイル全体の SHA-256 を照合した。ハードリンクで結ばれたものは同一実体として除外済みである。
| 重複していた場所の組み合わせ | 組数 | 余分に使っている量 |
|---|---|---|
| システムドライブ側・Ollama の既定の置き場 と データ用ドライブ側・Ollama | 14 件 | 119.5 GB |
| システムドライブ側・Hugging Face キャッシュ と データ用ドライブ側・llama.cpp 用のフォルダ | 4 件 | 48.1 GB |
| 合計 | 18 件 | 167.6 GB |
候補として挙がった組は、合計 335.2 GB を読み直してファイル全体の SHA-256 を突き合わせ、18 組すべてで一致した (不一致は0組)。1GB 以下のファイルは候補に入れていないため、そこに二重があるかどうかはこの照合では分からない。「余分に使っている量」は、同じ内容が2か所にあるときの2本目のぶんを指す。この数え方で 18 件・167.6 GB が二重に置かれていた。
二重になる生まれ方そのものは単純で、既定の置き場のまま取り込んだぶんと、ツール側で置き場を指定してから取り込んだぶんが並存すると、内容が同じでも別実体として両方に残る。
そしてシステムドライブ側の2か所は、データ用ドライブの走査には入らない。データ用ドライブと同じ数え方で集計した値が置き場別の内訳になる。
| 置き場 | 実消費 | 実体数 |
|---|---|---|
| Ollama の既定の置き場 | 169.3 GB | 114 件 |
| Hugging Face キャッシュ | 100.2 GB | 115 件 |
| 合計 | 269.5 GB | — |
| このドライブの空き | 577.6 GB | — |
Ollama の既定の置き場に 169.3 GB、Hugging Face キャッシュに 100.2 GB で、合わせて 269.5 GB。データ用ドライブの 1607.8 GB という数字に、この 269.5 GB は含まれていない。Ollama 側は、起動時に置き場を指定しない経路で使われる既定のパスにあたる。
Hugging Face キャッシュの中身をリポジトリ別に見ると、大きいものは GGUF 形式の LLM に偏る。リポジトリ別の値は hub 配下（ファイルキャッシュ）を集計したもので、xet（転送用のチャンク/シャードキャッシュ）は別系統として分けて数えた。
| リポジトリ | 実消費 |
|---|---|
| unsloth/gemma-4-26B-A4B-it-GGUF | 42.80 GB |
| unsloth/Qwen3.6-35B-A3B-MTP-GGUF | 23.76 GB |
| nvidia/Nemotron-3-Embed-8B-BF16 | 15.92 GB |
| unsloth/gemma-4-12b-it-GGUF | 7.76 GB |
| Systran/faster-whisper-large-v3 | 3.09 GB |
| nvidia/Nemotron-3-Embed-1B-BF16 | 2.30 GB |
| 掲載外（音声認識モデル等） | 4.50 GB |
| hub 配下の合計 | 100.1 GB |
| xet（転送用のチャンク/シャードキャッシュ） | 0.09 GB |
| キャッシュ全体 | 100.2 GB |
hub 配下のファイルキャッシュはデータ用ドライブではなくシステムドライブ側にあり、自分で整理しない限り残る。注意したいのは、キャッシュ全体の 100.2 GB がそのまま二重に置かれているわけではない点である。二重になっていたのは照合で一致した 4 件・48.1 GB のぶんである。残りについては 1GB 以下のファイルを照合していないため、二重かどうかはこの照合では分からない。
公式ドキュメントによれば、Hugging Face Hub のキャッシュは既定で ~/.cache/huggingface/hub に置かれ、HF_HOME か HF_HUB_CACHE の環境変数で場所を変えられる。また、新しいリビジョンを取得しても以前のファイルは残り、自動では削除されない。加えて、シンボリックリンクが使えない環境では blobs を使わず snapshots に直接保存されるため、同じリポジトリの複数リビジョンを取得すると同じファイルが複数回ダウンロードされることがある。Windows で開発者モードでも管理者実行でもない場合に該当しうる条件で、キャッシュが膨らむ経路のひとつになる。
必要な容量の目安はどれくらいか
必要量は使い方の広がりに応じて積み上がる。ただしここから挙げる値は、この1台が実際に何を入れて何を残したかの結果であって、必要量の基準ではない。入れるモデルも出力の設定も残す方針も構成ごとに違うので同じ数字にはならず、使えるのは数値そのものではなく、どの項目を積むかという数え方のほうになる。
- LLM だけを動かす場合：Ollama の層だけなら 286.6 GB で、llama.cpp 側に置いた GGUF はこの値に入っていない。ツール本体や作業ファイルも含む領域全体では 709.9 GB あり、この内訳は分けて数えていない。この環境が置いているのは 30B 級前後が中心で、タグ1本の論理サイズは 17.99〜23.94 GB の帯だった。扱う規模が違えば1本の大きさも変わる。システムRAM 側の必要量はローカルAIにシステムRAMは何GB必要か｜LLM推論と画像生成の消費量を96GB実機で実測で別に測っている。
- 画像生成まで広げる場合：ComfyUI 本体と画像・動画モデルで 448.6 GB。models フォルダだけなら 440.6 GB（共有を1回だけ数えた値で、単純に足し上げると 502.0 GB）。この環境が入れているモデルでは diffusion_models 1本 16.0 GB、checkpoints 1本 14.2 GB で、何を入れるかによって1本の大きさは変わる。GPU 側の要件はComfyUI推奨スペック実測ガイド｜VRAM 8・12・16GBとメモリ・CPUにまとめてある。
- 動画も出して生成物を残す場合：書き出しフォルダで 168.4 GB。この環境の1件あたりは png 1.6 MB、mp4 90.1 MB だった。解像度・長さ・保存形式で変わる値なので、自分の設定で数本出して測り直すことになる。
測定した構成は3つ目にあたる。その結果、容量 2048.4 GB のデータ用ドライブは空きが 149.5 GB まで減り、これとは別にシステムドライブ側にも 269.5 GB のモデルとキャッシュが載っている。AI と無関係の動画 245.3 GB も同居したこの構成で、どれも消さずに残した結果が、この 2TB 1台に収まらない状態である。
自分の数字へ置き換える手順は3つに分けられる。
- 入れるつもりのモデルを先に決めて、配布元に出ているファイルサイズを足す。この環境の1本あたり（diffusion_models 16.0 GB、checkpoints 14.2 GB、Ollama のタグ 17.99〜23.94 GB）は、そこに何を入れたかで決まった結果であって、他の構成へ当てはめる係数ではない。
- 生成物は、自分が出す設定で数本つくって1件あたりを測り、残す件数を掛ける。この環境の 90.1 MB と 1.6 MB は、使った解像度・長さ・保存形式での値なので、設定が違えば桁から変わる。
- モデルの置き場をいくつ持つかを数える。既定の置き場とツール側で指定した置き場が分かれていて、同じモデルをどちらの経路でも取り込んでいれば、そのぶんが別実体として重なる。測定した構成では、システムドライブ側に載っていた 269.5 GB のうち 18 件・167.6 GB が二重だった。
共有分の差し引きは、この積み上げとは別の話になる。ハードリンクや同じ層の共有で実消費が申告値より小さくなるのは、すでにある環境を数え直すときの補正であって、これから積む側には当てはまらない。新しく積む側で実際にどれだけ増えるかは、ツール側に重複排除の仕組みがあるかどうかでも変わる。この環境の Ollama では 30 のタグに対して層が 72 で、同じ層を指すタグは消費を増やしていない。そうした仕組みが働かない置き方をすれば、そのぶんは実際に消費することになる。容量以外に規格や速度の面で見る点はAI用PCのSSD選び方ガイド｜容量・速度・NVMe規格の違いを用途別に解説で整理している。
足りなくなったときの対処法
対処法は、保存先を移す・共有する・消すの3方向に分かれる。まず見直せるのは、システムドライブ側に載っていた 269.5 GB のように置き場が分散したぶんで、消す対象はそれに限らない。
移す。Ollama が Windows でモデルを置く既定の場所はユーザーフォルダ配下の .ollama\models で、公式 FAQ は OLLAMA_MODELS を設定すれば変更できると案内している。反映の手順も同じ FAQ にあり、まずタスクバーの Ollama を終了し、環境変数を設定してから、スタートメニューで起動し直す流れになる。Hugging Face 側は、hub 配下のファイルキャッシュの場所を HF_HOME か HF_HUB_CACHE で指定する。
これらの設定が変えるのは、これから置く先である。すでにダウンロード済みの実体がどうなるかは本記事では扱っていない。設定を変えただけで既存のファイルが移動する、とは読めない。
共有する。ComfyUI の Portable 版と手動導入版は、ルートに置く extra_model_paths.yaml で追加のモデル検索パスを指定でき、公式ドキュメントは複数のインスタンスでモデルファイルを共有してディスク容量を節約する用途を挙げている。同じ一式を共有関係を保持せず通常のコピーで持てば、この環境では単純に足し上げた 502.0 GB 相当を消費することになる。
消す。Hugging Face のキャッシュは hf cache ls で中身を一覧でき、hf cache rm と hf cache prune で削除できる。対象は hub 配下のファイルキャッシュで、xet ディレクトリの回収は公式ドキュメントで別に案内されている。以前のファイルは自動では削除されないため、更新されたファイルや不要になったリビジョンが積み上がる。
ハードリンクや環境変数の扱いについてここに書いたのは、公式ドキュメントが示している設定項目と、その案内の範囲までである。
まとめ
容量を決めるのは、モデル1本の大きさと、生成物を残すかどうかの2点になる。モデルは本数が少なくても1本が大きく、生成物は画像と動画で1件あたりが桁で違う。動画を出して残す運用なら、モデルとは別にその分の置き場が要る。
見積もりを外すのは数え方のほうで、ずれは両方向に出る。パスやタグを数えて足すと、共有されている1つの実体を何度も数えて実際より大きく出る。逆に、既定の置き場とツール側で指定した置き場が分かれていると、同じモデルが別実体で両方に残り、片方のドライブだけを数えた合計には現れない。向きが逆なので、片方だけを補正すると反対側で外れる。
当サイトの検証環境では、2TB のデータ用ドライブの空きが 149.5 GB まで減り、システムドライブ側にも 269.5 GB が載っていた。これは1台が何を入れて何を残したかの結果で、必要量の基準にはならない。自分の構成に当てはめるなら、入れるつもりのモデルのファイルサイズを配布元で確かめ、出力は自分の設定で数本つくって1件あたりを測るところから積み上げることになる。数字はいずれも、Windows 11 の1台の環境で2026年9月6日に全ファイルを数えた時点の値で、実消費はファイルサイズの合計であってドライブが確保した量とは一致しない。読み書きの速度は測っていない。
よくある質問
タグを増やすと、その論理サイズのぶんだけ空きが減るのか
減るとは限らない。測定した構成では 30 件のタグの論理サイズを足すと 343.6 GB だが、実際に置かれている層は 72 件で 286.6 GB、差は 57.0 GB あった。すでにある層を指す派生タグなら、消費はほとんど増えない。一方、層を共有しない別系列のモデルを増やす場合は、その系列のぶんが加わる。タグ1本の論理サイズは中央値で 9.28 GB だったが、これは申告値の中央値であって、1タグ増やしたときに実際に減る空きとは別に読む値である。
生成物はどのくらいのペースで貯まるのか
使い方に左右されるが、測定した構成では消さずに貯め続けた結果、mp4 が 1809 件で 163.0 GB になった。1件あたりは 90.1 MB で、これは使った解像度・長さ・保存形式での値なので、設定が違えば桁から変わる。貯まる量は1件あたりと本数の掛け算になるため、自分の設定で数本出して1件あたりを測るところが起点になる。png は 2840 件で 4.5 GB で、件数が多くても量は伸びていない。
別のドライブに置いたモデルを ComfyUI から読ませられるか
公式ドキュメントは、Portable 版と手動導入版ならルートの extra_model_paths.yaml で追加のモデル検索パスを指定できると案内しており、複数インスタンスでモデルファイルを共有してディスク容量を節約する用途を挙げている。同じ一式を各所にコピーする代わりに、参照先を増やす形になる。
Ollama のモデル保存先は変えられるか
公式 FAQ は、既定のユーザーフォルダ配下の .ollama\models から変える場合に OLLAMA_MODELS を設定するよう案内している。Windows での反映は、タスクバーから Ollama を終了し、環境変数を設定してから、スタートメニューで起動し直す手順になる。設定が指すのはこれから置く先であり、既存の実体の扱いは本記事の測定範囲外である。
Hugging Face のキャッシュは何を消せばよいか
まず hf cache ls で中身を一覧し、不要なものを hf cache rm、まとめての整理は hf cache prune という案内が公式ドキュメントにある。対象は hub 配下のファイルキャッシュで、xet 側はこれらの対象に入らず、別に案内されている。
