Featured image of post Cドライブを汚さずにAI画像生成環境を作る【Forge Neo】
IT

Cドライブを汚さずにAI画像生成環境を作る【Forge Neo】

GPUを新しくしたので画像生成を試したい。でもインストーラ任せにするとCドライブがキャッシュで埋まります。uvと環境変数で全部まとめて別ドライブに閉じ込めて、飽きたらフォルダごと消せる構成でForge Neoを入れてみました♪

5955文字

PR この記事には広告（アフィリエイトリンク）が含まれています。 詳細

グラボを替えたので画像生成をやってみたい

グラフィックボードを RTX 5060 Ti（16GB） に新調しました。買ったのはMSIの2連ファンのモデルです。

MSI GeForce RTX 5060 Ti 16G VENTUS 2X OC PLUS グラフィックスボード VD9137
Amazon楽天市場メルカリ MSI GeForce RTX 5060 Ti 16G VENTUS 2X OC PLUS グラフィックスボード VD9137VRAM 16GB。SDXL や FLUX がVRAMに収まるので画像生成が一気に楽になる

筆者が買ったときは 134,800円 でした。GPUもメモリもSSDも軒並み高い時期なので、なかなかの出費です。。。

それでも踏み切ったのは、VRAMが8GBから16GBになるのが大きかったからです。せっかくなので、AIの画像生成を試してみようと思い立ったわけですね♪

ただ、この手のツールはインストールした瞬間にCドライブをもりもり食うことで有名でして。筆者のCドライブは空きが47GBしかありません。ここにモデルやらキャッシュやらを放り込まれると、あっという間に詰みます。

というわけで今回は、

全部別のドライブに閉じ込めて、飽きたらフォルダごと削除で終わりにする

という構成で入れてみました。結論から言うと、Cドライブの空きは最後までほぼ変わりませんでした。

何が勝手にCドライブに溜まるのか

まず敵を知るところからです。

この手のツールを素直にインストールすると、インストール先とは別の場所に、こういうものが溜まっていきます。

溜まるもの既定の置き場大きさの目安
ダウンロードしたモデルユーザーフォルダ\.cache\huggingface数十GB
pip が落としてきたパッケージAppData\Local\pip\Cache数GB
Python 本体ツールによってまちまち数百MB
一時ファイルAppData\Local\Temp一時的に数GB

一番やばいのはモデルです。 今回使う FLUX.1 というモデルは1つで12GBくらいあります。これが何も言わずにユーザーフォルダへ降ってくるわけですね。

そして地味に効くのが一時ファイルです。PyTorch のパッケージは1つ2〜3GBあって、インストール時に一度展開してから入ります。つまりインストール中だけCドライブが数GB膨らみます。

逃がし先を決める

対策はシンプルで、環境変数で全部の置き場を指定するだけです。

筆者はNVMeのGドライブ（空き920GB）に G:\AI\ を作って、そこに集約しました。

G:\AI\ の構成
G:\AI\
├─ _cache\      逃がしてきたキャッシュ置き場
│  ├─ uv\ pip\ hf\ torch\ xdg\ tmp\
├─ _tools\      uv などの道具
├─ _docs\       作業ログ（記事用）
├─ Models\      モデル共通置き場
├─ ForgeNeo\    ← 今回入れるもの
├─ ComfyUI\     ← 次に入れるもの
└─ Output\      生成した画像

モデル置き場をツールの外に出しているのがポイントです。あとで ComfyUI を入れたときに、同じモデルを両方から参照できます。12GBのファイルを2つ持つのは馬鹿馬鹿しいですからね。笑

env.bat にまとめて書く

環境変数はシステムに登録しません。起動バッチの中だけで有効にします。

こうしておくと、普段使っているPowerShellや他のアプリには一切影響しません。AIツールを起動したときだけ、その中で効く形になります♪

G:\AI\env.bat（抜粋）
set "AI_ROOT=G:\AI"
set "AI_CACHE=%AI_ROOT%\_cache"

rem uv : its own Python builds and package cache
set "UV_PYTHON_INSTALL_DIR=%AI_ROOT%\_tools\uv\python"
set "UV_CACHE_DIR=%AI_CACHE%\uv"

rem pip : downloaded wheels
set "PIP_CACHE_DIR=%AI_CACHE%\pip"

rem HuggingFace : model downloads (the biggest one)
set "HF_HOME=%AI_CACHE%\hf"
set "HF_HUB_CACHE=%AI_CACHE%\hf\hub"

rem torch hub
set "TORCH_HOME=%AI_CACHE%\torch"

rem catch-all used by assorted libraries
set "XDG_CACHE_HOME=%AI_CACHE%\xdg"

rem temp : pip extracts multi-GB wheels here before installing
set "TMP=%AI_CACHE%\tmp"
set "TEMP=%AI_CACHE%\tmp"

各ツールの起動バッチは、先頭でこれを呼ぶだけです。

HF_HUB_CACHE を HF_HOME と別に書いているのは、古いライブラリが前者を直接見にいくことがあるためです。両方指定しておけば取りこぼしません。

順番がとても大事です

一度でも素の状態で起動してしまうと手遅れになります。

その瞬間にCドライブへキャッシュが作られてしまい、あとから環境変数を変えてもすでに置かれたものは消えません。

なので、

  1. フォルダを作る
  2. env.bat を書く
  3. それから初めてインストールを始める

という順番を守ります。ここだけは面倒がらずに先にやっておくのがおすすめです♪

基準値を記録しておく

「汚れていない」と言うからには、数字で示せないと意味がありません。

というわけで、インストール前のCドライブの状態を記録しておきます。あとで同じものを測って比べる作戦です。

インストール前の状態
時刻: 2026-10-23T18:14:22
  C:\ 空き 47.20 GB / 合計 232.12 GB
  G:\ 空き 920.58 GB / 合計 953.85 GB

  フォルダ                                       サイズ  説明
  %LOCALAPPDATA%\pip\Cache                     0.70 GB  pip のホイールキャッシュ
  %LOCALAPPDATA%\uv                                  -  uv のキャッシュ
  %USERPROFILE%\.cache\huggingface             0.53 GB  HuggingFace のモデル
  %USERPROFILE%\.cache\torch                         -  torch hub
  %USERPROFILE%\.cache                         2.12 GB  キャッシュ全般
  %USERPROFILE%\.local                               -  uv 公式インストーラの既定の置き場
  %APPDATA%\Ultralytics                        0.00 GB  ADetailer などが使う YOLO
  %USERPROFILE%\Downloads                      1.16 GB  ブラウザの保存先
  %LOCALAPPDATA%\Temp                          0.98 GB  一時ファイル

C: の空きは 47.20GB からのスタートです。この数字を覚えておいてください。

uv を用意する

Forge Neo の公式手順では、Python環境の構築に uv というツールを使うことが推奨されています。

これが今回の目的にぴったりで、uv は自分でPythonをダウンロードしてきて、プロジェクト専用の環境に閉じ込めてくれます。システムのPythonを一切汚しません♪

ただし公式のインストールスクリプトを使うと、ユーザーフォルダに入ってPATHも書き換えられます。それは避けたいので、実行ファイルだけ落としてGドライブに置きます。

uv をGドライブに置く
$dst = "G:\AI\_tools\uv"
$url = "https://github.com/astral-sh/uv/releases/latest/download/uv-x86_64-pc-windows-msvc.zip"
Invoke-WebRequest -Uri $url -OutFile "$dst\uv.zip" -UseBasicParsing
Expand-Archive -Path "$dst\uv.zip" -DestinationPath $dst -Force
Remove-Item "$dst\uv.zip"
結果
14.6 MB 取得

=== 配置 ===
  uv.exe   30.4 MB
  uvw.exe   0.3 MB
  uvx.exe   0.3 MB

=== バージョン ===
uv 0.13.5 (46776a95d 2026-10-21 x86_64-pc-windows-msvc)

あとはこの uv.exe をフルパスで呼ぶだけです。PATHに登録しないので、他の環境に影響しません。

Forge Neo を取ってくる

公式リポジトリの neo ブランチをクローンします。

クローン
cd G:\AI
git clone https://github.com/Haoming02/sd-webui-forge-classic ForgeNeo --branch neo
確認
ブランチ : neo
コミット : a83c1c82 2026-10-23 unpatch
サイズ   : 92 MB

この時点ではただのソースコードなので92MBしかありません。重いものはこれから入ります。

Python環境を作る

ここで uv の出番です。公式手順どおり、Python 3.13 の仮想環境を作ります。

venv を作る
cd G:\AI\ForgeNeo
G:\AI\_tools\uv\uv.exe venv venv --python 3.13 --seed

セキュリティソフトに邪魔されました

ところがこれ、最初は失敗しました。

エラー
error: Failed to download `https://github.com/astral-sh/python-build-standalone/releases/
download/20261021/cpython-3.13.17+20261021-x86_64-pc-windows-msvc-install_only_stripped.tar.gz`
  cause: error sending request for url (...)
  cause: client error (Connect)
  cause: invalid peer certificate: UnknownIssuer

証明書の発行元が信頼できないと怒られています。

原因はセキュリティソフトでした。この手のソフトは通信を検査するためにHTTPSを一度復号して、自前の証明書で包み直します。ブラウザやgitはその証明書をWindowsの証明書ストアから見つけられるのですが、uvは自前の証明書ストアを持っているため、見つけられずに弾いてしまうわけですね。

解決策は「Windowsの証明書ストアを使え」と指示することです。

env.bat に追記
rem uv ships its own certificate store, which fails when security
rem software intercepts TLS ("invalid peer certificate: UnknownIssuer").
rem Tell uv to use the Windows certificate store instead.
set "UV_SYSTEM_CERTS=1"

これで通りました。

成功
Downloading cpython-3.13.17-windows-x86_64-none (download) (21.0MiB)
 Downloaded cpython-3.13.17-windows-x86_64-none (download)
Using CPython 3.13.17
Creating virtual environment with seed packages at: venv
 + pip==26.2.2

ちなみに UV_NATIVE_TLS という変数でも同じことができますが、こちらは非推奨になっていて警告が出ます。新しい UV_SYSTEM_CERTS を使いましょう。

ちゃんとGドライブに入ったか確認

言いっぱなしは良くないので、実際にどこに置かれたか見てみます。

確認結果
=== uv が入れた Python の場所 ===
  cpython-3.13-windows-x86_64-none         60 MB
  cpython-3.13.17-windows-x86_64-none      60 MB

=== venv ===
  Python 3.13.17
  実体: G:\AI\ForgeNeo\venv\Scripts\python.exe
  base: G:\AI\_tools\uv\python\cpython-3.13-windows-x86_64-none

=== G:\AI\_cache の使用量 ===
  uv            5.5 MB

Python本体もvenvも、すべてGドライブの中に収まっています。Cドライブには何も置かれていません♪

起動バッチを書く

Forge Neo には webui-user.bat という設定用のバッチが付いてきますが、これは触りません。

リポジトリで管理されているファイルなので、書き換えると git pull のたびに衝突します。代わりに start-forge.bat を自分で用意して、そこに全部書く方針にしました。

G:\AI\ForgeNeo\start-forge.bat
@echo off

rem always work from this script's own folder
cd /d "%~dp0"

rem send every cache to G: BEFORE anything else runs
call "G:\AI\env.bat"

rem webui.bat looks for `uv` on PATH. Add it for this session only.
set "PATH=G:\AI\_tools\uv;%PATH%"

rem pin the interpreter
set "PYTHON=%~dp0venv\Scripts\Python.exe"
set "VENV_DIR=%~dp0venv"

set COMMANDLINE_ARGS=--uv --cuda-malloc --cuda-stream --pin-shared-memory ^
 --ckpt-dirs G:/AI/Models/checkpoints ^
 --lora-dirs G:/AI/Models/loras ^
 --vae-dirs G:/AI/Models/vae ^
 --embeddings-dir G:/AI/Models/embeddings ^
 --esrgan-models-path G:/AI/Models/upscale_models

call "%~dp0webui.bat"

ポイントが4つあります。

PATHに uv を足しています。 webui.bat の中身を読むと、uv help python というコマンドで uv を探していました。PATHに無いと見つけられないので、このバッチの中でだけ通しています。システムのPATHは触りません。

PYTHON を明示しています。 指定しないと webui.bat はPATHの python を使います。筆者の環境ではこれがpyenvのシム（3.10系）を指していて、Forge Neo が欲しい3.13とは違うものでした。事故のもとなので固定します。

--xformers は使いません。 公式に「xformers は RTX 50シリーズをサポートしていない」と明記されています。

ディレクトリ指定は複数形です。 Forge Neo は --ckpt-dirs --lora-dirs --vae-dirs と複数形になっています。本家A1111の記事を見ながら単数形で書くと弾かれるので要注意です。

初回起動

あとは start-forge.bat を叩くだけ。初回は依存関係を全部取りにいくので時間がかかります。

PyTorch の取得
venv "G:\AI\ForgeNeo\venv\Scripts\Python.exe"
Using Python 3.13.17 environment at: venv
Resolved 13 packages in 2.38s
Downloading torch (1.9GiB)
 ...
Prepared 13 packages in 6m 51s
Installed 13 packages in 2.81s
 + torch==2.14.0+cu130
 + torchvision==0.29.0+cu130
 + numpy==2.5.2
 + pillow==12.3.0

PyTorch 2.14.0 + CUDA 13.0 が入りました。RTX 50シリーズ（Blackwell）はここが新しくないと動かないので、重要なところです。

そして無事に起動。

起動ログ
Total VRAM 16284 MB, total RAM 65457 MB
PyTorch Version: 2.14.0+cu130
VRAM State: NORMAL_VRAM
Device: NVIDIA GeForce RTX 5060 Ti (cuda:0) - cudaMallocAsync
Using async weight offloading with 2 streams
Pinned Memory: 29456 MB
Using PyTorch Cross Attention

Running on local URL:  http://127.0.0.1:7860
Startup time: 597.8s (prepare environment: 549.2s, ...)

GPUがちゃんと認識されています。約10分かかりましたが、そのうち9分は依存関係のダウンロードなので、2回目からは一瞬です♪

バックスラッシュが消える罠

ところが起動ログをよく見たら、引数がおかしなことになっていました。

指定したはずのパスが…
Launching Web UI with arguments: --uv --cuda-malloc --cuda-stream
--pin-shared-memory --ckpt-dirs G:AIModelscheckpoints --lora-dirs G:AIModelsloras

G:\AI\Models\checkpoints が G:AIModelscheckpoints になっています。バックスラッシュが全部消えたわけですね。

原因はソースを読んで分かりました。

modules/paths_internal.py
commandline_args = os.environ.get("COMMANDLINE_ARGS", "")
sys.argv += shlex.split(commandline_args)

shlex.split() はUNIX系のシェルの文法で文字列を分解する関数です。そしてUNIX系では、バックスラッシュはエスケープ文字という扱いになります。\A は「Aという文字そのもの」と解釈され、バックスラッシュ自体は消えてしまうのです。

Windowsのパスを素直に書くと全滅するという、なかなか厄介な仕様でした。笑

対策はスラッシュ区切りにすることです。

直したもの
 --ckpt-dirs G:/AI/Models/checkpoints

Windowsでもスラッシュ区切りのパスはちゃんと通るので、これで解決します。エラーも警告も出ずに黙って壊れるタイプなので、起動ログの引数表示は毎回確認したほうが良さそうです。

モデルを選ぶ

ここは少し慎重になりました。ブログに載せる以上、ライセンスがはっきりしているモデルを選びたいからです。

今回選んだのは FLUX.1 [schnell]。理由はシンプルで、Apache 2.0 だからです。

モデルライセンス商用利用
FLUX.1 [schnell]Apache 2.0できる
FLUX.1 [dev]独自の非商用ライセンスできない
SDXL Base 1.0CreativeML Open RAIL++-Mできる（用途制限あり）

同じFLUXでも dev は非商用なので、うっかり使うと面倒なことになります。名前が似ているので注意が必要ですね。

ひとつ正直に書いておくと、Apache 2.0 が保証しているのは「モデルの重みをどう使っていいか」であって、学習に使われた画像の権利処理までは保証されていません。ここまで厳密に追いかけるなら、CC0やオプトインのデータだけで学習したモデルを選ぶことになりますが、品質はかなり落ちます。今回は「ライセンス上クリアなものを選んだ」という線で進めます。

ダウンロード

本家のリポジトリは利用規約への同意が必要で、トークン無しだと401が返ってきます。

本家は認証が要る
  Comfy-Org fp8 全部入り           HTTP 200   16.05 GB
  公式 bf16（拡散モデルのみ）        取得失敗: HTTP Error 401: Unauthorized

一方、Comfy-Org が再配布している fp8 版は認証なしで落とせます。しかもこちらは拡散モデル・テキストエンコーダ・VAEが1ファイルに入った全部入りなので、置くだけで動きます。ライセンスはschnellのままApache 2.0です。

ブラウザで落とすとCドライブの「ダウンロード」フォルダに入ってしまうので、コマンドで直接Gドライブに落とします。

モデルの取得
curl.exe -L --retry 3 --continue-at - `
  -o "G:\AI\Models\checkpoints\flux1-schnell-fp8.safetensors" `
  "https://huggingface.co/Comfy-Org/flux1-schnell/resolve/main/flux1-schnell-fp8.safetensors"
結果
100 16.0G  100 16.0G    0     0  4200k      0  1:06:47  1:06:47 --:--:-- 5380k

16GBで1時間7分かかりました。気長に待ちましょう。笑

--continue-at - を付けているので、途中で切れても同じコマンドで再開できます。

起動してみる

もう一度 start-forge.bat を叩きます。

2回目の起動
Model Selected:
{
  "checkpoint": "flux1-schnell-fp8.safetensors",
  "modules": [],
  "dtype": "[torch.float16, torch.bfloat16]"
}
Running on local URL:  http://127.0.0.1:7860
Startup time: 38.7s

モデルを認識しました。しかも起動時間が597秒から38.7秒に短縮されています。初回が遅いのは依存関係のダウンロードのせいだったので、2回目からは快適です♪

ブラウザで開くとこの画面。見た目は本家のWebUIとほぼ同じです

http://127.0.0.1:7860 を開くとこの画面になります。使ったことがある方なら迷わないはずです。

画像を出してみる

画面から操作してもいいのですが、設定を正確に残したかったのでAPIから叩くことにしました。起動オプションに --api を足すと /sdapi/v1/ が開きます。

FLUX.1 schnell を使ううえでここだけは押さえておきたい設定があります。

設定値理由
Steps4schnellは4ステップで完成するよう蒸留されている。増やしても良くならない
CFG Scale1.0schnellはCFGを使わない設計
SamplerEuler
ScheduleSimple

普通のモデルの感覚で「Steps 30、CFG 7」などとやると、遅いうえに結果も良くなりません。ここは割り切りが必要です。

生成のリクエスト
PAYLOAD = {
    "prompt": "a cozy desk at night, a small white PC case with softly glowing fans, "
              "a cup of coffee, a mechanical keyboard, warm desk lamp light, "
              "shallow depth of field, photorealistic",
    "steps": 4,            # schnell は 4 ステップで完成する
    "cfg_scale": 1.0,      # schnell は CFG を使わない
    "width": 1024,
    "height": 1024,
    "sampler_name": "Euler",
    "scheduler": "Simple",
    "seed": 20261023,
}

結果がこちらです。

初めての1枚。プロンプトは「夜の机、光るファンの小さなPC、コーヒー、メカニカルキーボード」

いい感じです♪ 光の回り方とか、手前のキーボードのボケ具合とか、ちゃんと写真っぽくなっています。

速度

生成時間
1回目: 57.9 秒   （モデルをVRAMに読み込む時間を含む）
2回目: 10.7 秒   （読み込み済み）

1024×1024が約10秒。4ステップのモデルなので速いです。

VRAMの使用量も見ておきます。

生成中のVRAM
11116 MiB / 16311 MiB

16GBのうち11GBほどでした。余裕があります。8GBのカードだとここが厳しくなるので、16GBにした甲斐がありました。

本題：Cドライブは汚れたのか

さて、ここからが今回の本題です。最初に記録した数字と比べてみます。

インストール前後の比較
=== 差分 ===
  C:\ 空きが 0.21 GB 減った
  G:\ 空きが 20.83 GB 減った

Cドライブの減りは 0.21GB。しかも監視していたキャッシュフォルダは、すべて1バイトも増えていませんでした。

フォルダ前後
%LOCALAPPDATA%\pip\Cache0.70 GB0.70 GB
%USERPROFILE%\.cache\huggingface0.53 GB0.53 GB
%USERPROFILE%\.cache2.12 GB2.12 GB
%LOCALAPPDATA%\Temp0.98 GB0.98 GB

0.21GBのほうは、Windowsのログなど普段の動作による変動です。AI環境が食った分はゼロと言っていいと思います。

念のため、Cドライブで最近更新された重いフォルダも探してみました。

漏れ探し
=== 直近24時間に更新された C: 配下のフォルダ（100MB以上）===
      70.45 GB  C:\Users\username
       1.57 GB  C:\Users\username\.cache\codex-runtimes
       1.09 GB  C:\Users\username\.codex
       0.12 GB  C:\Users\username\.codex\.tmp
       0.47 GB  C:\Users\username\.codex\plugins

引っかかったのは全部別のツールのものでした。Forge Neo 由来のものはひとつもありません♪

そして、本来Cドライブに行くはずだった20.83GBはこうなっています。

Gドライブの内訳
_cache                   4.24 GB    pip/uv が落としてきたもの
_tools                   0.09 GB    uv本体とPython
ForgeNeo                 4.25 GB    リポジトリ + venv
Models                  16.05 GB    FLUX.1 schnell
Output                   0.00 GB    生成画像

消すときはフォルダごと

この構成の良いところは、飽きたときの後始末が一瞬なことです。

G:\AI\ を削除 → 終わり

レジストリもPATHもシステム環境変数も触っていないので、これで元通りです。Pythonもuvもこの中にしか居ません。

「とりあえず試してみたいけど、合わなかったときに環境が汚れるのが嫌だな」という方には、特におすすめしたいやり方です♪