この記事を作った動機

 なんか最近 AUR に Stable Diffusion WebUIが出現していて気軽に試せそうだったのでインストールして使ってみたということがあった。

 その過程で記録しておきたいことがあったので、Stable Diffusion WebUI の導入過程とともに記事を書こうと思った。

AURの様子

環境

System Details Report


Report details

  • Date generated: 2025-07-13 20:41:10

Hardware Information:

  • Hardware Model: HP ProLiant DL60 Gen9
  • Memory: 32.0 GiB
  • Processor: Intel® Xeon® E5-2620 v4 × 16
  • Graphics: Unknown ※ GTX1080ti
  • Disk Capacity: 30.0 TB

Software Information:

  • Firmware Version: U15
  • OS Name: Arch Linux
  • OS Build: rolling
  • OS Type: 64-bit
  • GNOME Version: 48
  • Windowing System: X11
  • Kernel Version: Linux 6.15.5-arch1-1

導入

yay コマンドでインストール

yay -Sy stable-diffusion-webui

コンフィグの場所

/etc/stable-diffusion-webui/webui.conf

コンフィグの設定例(webui.conf)

 DATA_DIR は専用にディレクトリを作り、変更した方がいいかもしれない。デフォルトの場所だと、モデルを配置したり出力された画像などにアクセスしずらい。

 デフォルトだと、"/var/opt/stable-diffusion-webui/data"配下にモデルを配置する場所や、生成した画像が置かれてしまう。都合に合わせてユーザのホームディレクトリとか、適当な場所に専用のフォルダを設けた方が便利ではある。

# Flags to pass to the `accelerate launch` command
# See: https://huggingface.co/docs/accelerate/package_reference/cli#accelerate-launch
ACCELERATE_FLAGS="--num_cpu_threads_per_process=6"

# Flags for stable-diffusion-webui
# See: https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Command-Line-Arguments-and-Settings
#
# Example: WEBUI_FLAGS="--listen"
WEBUI_FLAGS="--listen --api --api-log --xformers --lowvram --disable-safe-unpickle --enable-insecure-extension-access"

# Path to save model files and outputs
DATA_DIR="/var/opt/stable-diffusion-webui/data" 

サービスを設定し起動

sudo systemctl enable --now stable-diffusion-webui # 起動と有効化の両方
# sudo systemctl enable stable-diffusion-webui // PC が起動したときに立ち上がるようにするだけの時
# sudo systemctl start stable-diffusion-webui   // 単に webui を起動するだけ

 この時点で、localhost:7860からは、webui にchromeなどからアクセスできると思われる。正しく起動していれば、とりあえず何か生成できるか試すこともできる。

httpd のプロキシ設定

 私の場合はデータサーバとして専用に設けているPCに、今回 stable diffusion webui をインストールしたので、localhostだけで動かれるといちいちリモートデスクトップか何かで、直接サーバ内部の GUI 環境に入る必要があり不便であった。

 なので、httpd のプロキシ機能を使って、プライベートなLAN内だけで運用している専用のドメイン名でアクセスされると、localhost:7860として転送するように設定した。

 この方法であれば、firewalld などの設定をわざわざ変えなくて済むという点からも管理的な意味合いでは都合がいい。

 注意点としては、httpの設定だけでなく、websocket も localhost:7860 に転送する設定が必要であるというところがある。また、httpd 側の専用のモジュールも有効化が必要である。また今回は SSL の設定も混じっているが、そこについては大変すぎるので説明は省くことにする。

  • /etc/httpd/conf/httpd.conf (モジュール周りの設定)
# 設定項目自体はすでに "#" でコメントアウトされて存在するので、必要な項目の行の "#" を消すだけでよい。
...
# 必要なモジュールの有効化
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so
LoadModule rewrite_module modules/mod_rewrite.so

# 必要な設定の書いてあるコンフィグファイルの有効化
Include conf/vhost/service.conf

# オプション
LoadModule ssl_module modules/mod_ssl.so # SSL の設定。一応ここは載せておく
...
  • /etc/httpd/conf/extra/httpd-vhosts.conf (プロキシ設定本体)
...
<VirtualHost *:80>
        # SSL (HTTPS) の設定なので今回はあまり関係がない
        ServerName stable.internal.domain.name
        Redirect permanent / https://stable.internal.domain.name/
</VirtualHost>

<VirtualHost *:443>
        ServerName stable.internal.domain.name

        # SSL (HTTPS) の設定なので今回の設定とはこの 3行はあまり関係ない
        SSLEngine on
        SSLCertificateFile "/etc/httpd/conf/ssl/stable.internal.domain.name.pem"
        SSLCertificateKeyFile "/etc/httpd/conf/ssl/stable.internal.domain.name-key.pem"

        # websocket 転送設定
        RewriteEngine On
        RewriteCond %{HTTP:Upgrade} =websocket [NC]
        RewriteCond %{HTTP:Connection} upgrade [NC]
        RewriteRule ^/(.*) "ws://localhost:7860/$1" [P,L]

        # HTTP 転送設定
        ProxyPreserveHost on
        ProxyRequests off
        ProxyPass / http://localhost:7860/
        ProxyPassReverse / http://localhost:7860/
</VirtualHost>
...

モデルや生成画像の場所

# DATA_DIR="/home/username/Documents/AI" の場合
/home/username/Documents/AI/models/Stable-diffusion # モデルを配置する場所
/home/username/Documents/AI/outputs                 # 生成された画像の場所

# デフォルト設定の場合
/var/opt/stable-diffusion-webui/data/models/Stable-diffusion # モデルを配置する場所
/var/opt/stable-diffusion-webui/data/outputs                  # 生成された画像の場所

## hint
# @ /etc/stable-diffusion-webui/webui.conf
# Path to save model files and outputs
# DATA_DIR="/var/opt/stable-diffusion-webui/data"

# @ /usr/lib/systemd/system/stable-diffusion-webui.service
# destdir="${DATA_DIR}/models/Stable-diffusion"; \

/usr/share/stable-diffusion-webui/models/Stable-diffusion
/opt/stable-diffusion-webui/models/Stable-diffusion

追記

(2025/9/14)

 最近気づいたこととして、VRAM の残りがたくさんあったりするのに、GPU が全然使われてなかったり、70GB くらいあるメインメモリを画像生成ごとに徐々にメモリリークして全部食いつぶし、結果的に linux 環境では完全にシステム全体をフリーズさせてしまい、強制的に再起動しないと復帰しないということがあった。

 そこで気づいたことややったほうがいいことがわかったのでそれを記録する。

lowvram オプション

 私は、GTX1080ti を画像生成のために割り当てているが、VRAM が約 11GB 程度ある中で、lowvram オプションが付いていると、せいぜい数 GB 程度しか使わない状態で、GPU自体も 30% 程度しか使えていなかったりと、全体的に動作が遅かった。

 またモデルがメインメモリの方に読み込まれてしまうからか、画像生成だけで初回で、20GB程度持っていかれて、その後は使い込むほど WebUI ごと再起動しない限り、メモリリークを起こして食いつぶして行く様相だった。

 このような状況では、webui.conf から使いたいモデルが VRAM 内に収まっているとわかっているなら、デフォルトで AUR からインストールしたときには付いている、--lowvram を消したほうがいいかもしれない。ちなみにこのオプションを消すと、メインメモリの使用率は圧倒的に下がるが、変わりに GPU のメモリをいっぱい使うようになる。

画像生成はせずモデルがロードされた様子の例

# nvidia-smi
Sun Sep 14 01:02:25 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.82.09              Driver Version: 580.82.09      CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce GTX 1080 Ti     Off |   00000000:07:00.0  On |                  N/A |
| 36%   46C    P8             13W /  250W |    8845MiB /  11264MiB |     10%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A            1504      G   /usr/lib/Xorg                           303MiB |
|    0   N/A  N/A            1867      G   /usr/bin/gnome-shell                     60MiB |
|    0   N/A  N/A            7409    C+G   ...b/gnome-remote-desktop-daemon        298MiB |
|    0   N/A  N/A          467649      C   ...ffusion-webui/venv/bin/python       7726MiB |
|    0   N/A  N/A         1984341      G   ...ersion=20250910-180038.780000        430MiB |
+-----------------------------------------------------------------------------------------+

画像生成中の例

# nvidia-smi
Sun Sep 14 01:05:49 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.82.09              Driver Version: 580.82.09      CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce GTX 1080 Ti     Off |   00000000:07:00.0  On |                  N/A |
| 41%   67C    P2            236W /  250W |    9656MiB /  11264MiB |    100%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A            1504      G   /usr/lib/Xorg                           303MiB |
|    0   N/A  N/A            1867      G   /usr/bin/gnome-shell                     93MiB |
|    0   N/A  N/A            7409    C+G   ...b/gnome-remote-desktop-daemon        298MiB |
|    0   N/A  N/A          467649      C   ...ffusion-webui/venv/bin/python       8666MiB |
|    0   N/A  N/A         1984341      G   ...ersion=20250910-180038.780000        268MiB |
+-----------------------------------------------------------------------------------------+

結局メモリリークする例

 GPU 側にモデルを読み込むようになり、メインメモリをあまり使わなくなっても、起動したてのときは、1 GB も使ってなかった気がするが、このようにして使い込むほどにだんだんと、何 GB も食いつぶし始める。

 定期的に再起動したり、メモリ使用が一定を超えたら、自動的に kill して再起動するとか、そういう工夫が必要であることに変わりはないようである。

● stable-diffusion-webui.service - Stable Diffusion Web UI
     Loaded: loaded (/usr/lib/systemd/system/stable-diffusion-webui.service; enabled; preset: disabled)
    Drop-In: /etc/systemd/system/stable-diffusion-webui.service.d
             └─override.conf
     Active: active (running) since Thu 2025-09-11 21:40:13 JST; 2 days ago
 Invocation: 478bf01465a74b3aa9632b822857dc0b
   Main PID: 467428 (accelerate)
      Tasks: 92 (limit: 629145)
     Memory: 8.2G (max: 20G, available: 11.7G, peak: 8.6G)
        CPU: 23h 31min 19.092s
     CGroup: /system.slice/stable-diffusion-webui.service
             ├─467428 /opt/stable-diffusion-webui/venv/bin/python /opt/stable-diffusion-webui/venv/bin/accele>
             └─467649 /opt/stable-diffusion-webui/venv/bin/python /opt/stable-diffusion-webui/launch.py --dat>

systemd メモリ制限

 どうやっても、メモリリークするし、それでメインメモリを全部食いつぶされて、linux がフリーズして強制的に再起動するまで、HDD が永遠にガリガリいうみたいな光景は、まさしくハードウェアの寿命を無駄にしているって感じで嫌だしうざいので、Systemd 側でメモリ使用に制限をかけてしまうことにした。

 AUR にある stable-diffusion-webui にはすでに systemd のサービスがデフォルトで用意されているので、ChatGPT-5 にそのことを投げたら、追加設定がアプデ時に毎回上書きされないように、drop-in 設定を使えと帰ってきて、実際試してみてそれが動いたため、今回はそれを採用した。

追加した設定

 Service の項目に、メモリ管理の有効化と、メモリの最大の設定や、OOM Killer が優先的にメモリが足りなくなったら stable-diffusion-webui を Kill するように、スコアを設定したりした。

[Service]
MemoryAccounting=true
MemoryMax=20G           # メモリ上限 20GB。 本当は 5GB 程度でいいかもしれない
OOMScoreAdjust=1000     # 1000 で最も優先的に Kill されやすくなり、 -1000 で Kill されなくなるとのこと。

既存の systemd サービスをオーバーライドする方法

# エディタが立ち上がるので、追加したい設定項目で全部上書きする。
sudo systemctl edit stable-diffusion-webui.service

# 正常に設定が反映されたときは以下のように、メッセージが出てくる
Successfully installed edited file '/etc/systemd/system/stable-diffusion-webui.service.d/override.conf'.

stable-diffusion-webui.service オーバーライド例

### Editing /etc/systemd/system/stable-diffusion-webui.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file

# ここに上書き設定を書く ------------------------------------
# ここに上書き設定を書く ------------------------------------
[Service]
MemoryAccounting=true
MemoryMax=20G
OOMScoreAdjust=1000
# ここに上書き設定を書く ------------------------------------
# ここに上書き設定を書く ------------------------------------

### Edits below this comment will be discarded
# ここからしたに書いても何も反映されず、消されてしまう。

### /usr/lib/systemd/system/stable-diffusion-webui.service
# [Unit]
# Description=Stable Diffusion Web UI
# After=network.target
# 
# [Service]
# Type=simple
# User=sdwebui
# Group=sdwebui
# WorkingDirectory=/opt/stable-diffusion-webui
# Environment=PYTHONUNBUFFERED=1
# EnvironmentFile=/etc/stable-diffusion-webui/webui.conf
# ExecStart=/bin/bash -c '\
#     : "${DATA_DIR:=/var/opt/stable-diffusion-webui}"; \
#     srcdir="/usr/share/stable-diffusion-webui/models/Stable-diffusion"; \
#     destdir="${DATA_DIR}/models/Stable-diffusion"; \
#     modelfile="v1-5-pruned-emaonly.safetensors"; \
#     mkdir -p "$destdir" && \
#     [ ! -f "$destdir/$modelfile" ] && cp "$srcdir/$modelfile" "$destdir/"; \
#     exec /opt/stable-diffusion-webui/venv/bin/accelerate \
#     launch ${ACCELERATE_FLAGS:+$ACCELERATE_FLAGS} \
#     /opt/stable-diffusion-webui/launch.py \
#     --data-dir "$DATA_DIR" ${WEBUI_FLAGS:+$WEBUI_FLAGS}'
# 
# Restart=always
# StartLimitInterval=120
# StartLimitBurst=15
# UMask=007
# 
# [Install]
# WantedBy=multi-user.target

ChatGPT-5 以外の参考

 正直 ChatGPT は平気で変なことを堂々と言ってきて、どれが正しい、それは絶対間違ってるみたいな、あたかも確かなことを言っているかのような言い方してきて鬱陶しく、非常に私はそれに対し疑心暗鬼でもあるので、自分でも OOMScoreAdjust についての説明が ChatGPT の出力したこととおかしくないかとか、適当にぼちぼちネットを調べたりした。

 以下は、似たような systemd でメモリ管理をしたいケースにおいて、参考になりそうなサイトでもあると思われる。

GPU のファン速度の設定

 画像生成で GPU に負荷をかけまくると、私の環境の場合、どうもデフォルトのファン回転数制御では、85℃ あたりでうろつきながら、サーマルスロットリングって感じで、電力にはまだ余裕があるのに、GPU の性能を使い切れないという現象が起こることがわかった。

 気づいた過程としては、

  • 画像生成を始めて最初は、徐々に40℃あたりから温度が上がっていき、パワーリミットで 240w/250w という感じで動いている
  • 数分後には、80℃以上に達し、190w/250w という感じでサーマルスロットリングでうろつくようになる
     ということがあった。
温度 ファン速度 電力 パワーリミット サーマルスロットリング
生成をしていないとき 40℃ 30%くらい? 20~60w なし なし
生成はじめ 40℃から上昇 徐々に上昇 240w~260w あり(250w) なし
生成を始めて数分後 85℃あたりをうろつく 65% 180w~200w なし あり

 最初は単に画像生成AIとはそういうものなのだと思っていたが、段々と温度と消費電力の関係をぼーっとなんとなく見ていたら、おかしいなと気づいた。

 ここでは具体的にどうやって、nvidia 製 GPU のファンの速度を linux 上で nvidia-settings コマンドを使って制御するか記録しようと思う。

-c 0 って何?

sudo nvidia-settings -a ‘[fan:0]/GPUTargetFanSpeed=100’
# Authorization required, but no authorization protocol specified
#
#
# ERROR: The control display is undefined; please run `nvidia-settings --help` for usage information.

 -c を指定しなかったときの、上記のエラーに従って、調べてみると、以下のようなことが書かれていた。

nvidia-settings --help

# ...
#   -c CTRL-DISPLAY, --ctrl-display=CTRL-DISPLAY
#       Control the specified X display.  If this option is not given, then nvidia-settings will control the di
#       splay specified by '--display'; if that is not given, then the $DISPLAY environment variable is used.
# ...

 どうも、明示的に GPU が制御している X11 の画面を指定する必要があるようで、SSH 経由でリモートで作業していたのも相まって、nvidia-settings が $DISPLAY 環境変数からも何も得られなかったようである。

 よくわからなければ、0 ~ 10 くらいまで試していれば多分いつか当たると思われ、特殊な構成にしていなければ、X11 のディスプレイは基本 0 番に描画されるようになっているので、そこをまず当たればいいと思われる。

設定できるファンを調べる

sudo nvidia-settings --query fans -c 0
# Authorization required, but no authorization protocol specified
#
#
# 1 Fan on 0
#
#     [0] [fan:0] (Fan 0)
#
#       Has the following name:
#         FAN-0

ファン回転数を 0~100 % の間で設定する

sudo nvidia-settings -c 0 -a [fan:0]/GPUTargetFanSpeed=100
# Authorization required, but no authorization protocol specified
# 
# 
#   Attribute 'GPUTargetFanSpeed' ([fan:0]) assigned value 100.

ファンを最大回転数で回してみた様子

 ざっと、5℃ 程度の温度低下が見られた。パワーリミットで再び動作するようになったりと効果はあるようである。しかし、ファンのベアリングの寿命を考えると、正直あんまりこういう強引なやり方はよくないかもしれないので、使っているとき以外はファン制御は GPU に返したほうがいいかも。

# nvidia-smi
Sun Sep 14 02:59:16 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.82.09              Driver Version: 580.82.09      CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce GTX 1080 Ti     Off |   00000000:07:00.0  On |                  N/A |
|100%   80C    P2            253W /  250W |    9574MiB /  11264MiB |    100%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A            1504      G   /usr/lib/Xorg                           353MiB |
|    0   N/A  N/A            1867      G   /usr/bin/gnome-shell                     60MiB |
|    0   N/A  N/A            7409    C+G   ...b/gnome-remote-desktop-daemon        298MiB |
|    0   N/A  N/A          467649      C   ...ffusion-webui/venv/bin/python       8668MiB |
|    0   N/A  N/A          759787      G   /usr/bin/kgx                              7MiB |
|    0   N/A  N/A          760274      G   nvidia-settings                           2MiB |
|    0   N/A  N/A         1984341      G   ...ersion=20250910-180038.780000        155MiB |
+-----------------------------------------------------------------------------------------+

GPU にファン制御を返す

sudo nvidia-settings -c 0 -a GPUFanControlState=0

試行錯誤と結局ググる過程

 手動のファン回転数指定から、元の自動制御に戻す方法についても調べてみた。とは言ってもどうすればいいかわからないので、とりあえず、nvidia-settings --help してみると、以下の項目が気になった。

nvidia-settings --help

# ...
#   -e DESCRIBE, --describe=DESCRIBE
#       Prints information about a particular attribute.  Specify 'all' to list the descriptions of all attribu
#       tes.  Specify 'list' to list the attribute names without a descriptions.
# ...

 そこで、Fan についてどういう項目があるか調べてみると以下のようになった。

nvidia-settings -e all | grep Fan
# Attribute 'GPUFanControlState':
# Attribute 'GPUTargetFanSpeed':
# Attribute 'GPUCurrentFanSpeed':
# Attribute 'GPUResetFanSpeed':
# Attribute 'GPUCurrentFanSpeedRPM':
# Attribute 'GPUFanControlType':
# Attribute 'GPUFanTarget':

 GPUFanControlStateGPUFanControlType あたりが怪しそうだと思い、更に調べてみる。

nvidia-settings -e GPUFanControlState

# Attribute 'GPUFanControlState':
#   - Attribute value is an integer.
#   - Attribute is not written to the rc file.
#   The current fan control state; the value of this attribute controls the availability of additional fan
#   control attributes.  Note that this attribute is unavailable unless fan control support has been enabled by
#   setting the "Coolbits" X config option.
nvidia-settings -e GPUFanControlType

# Attribute 'GPUFanControlType':
#   - Attribute value is an integer.
#   - Attribute is not written to the rc file.
#   Returns how the GPU fan is controlled.  '1' means the fan can only be toggled on and off; '2' means the fan
#   has variable speed.  '0' means the fan is restricted and cannot be adjusted under end user control.

 それで、GPUFanControlState あたりを試してみるも、どういう値にすればいいかまでは、コマンドのヘルプを見てもわからなかったので、適当にネットで調べて、GPUFanControlState=0 に至る。

nvidia-settings -e GPUFanControlState

# Attribute 'GPUFanControlState':
#   - Attribute value is an integer.
#   - Attribute is not written to the rc file.
#   The current fan control state; the value of this attribute controls the availability of additional fan
#   control attributes.  Note that this attribute is unavailable unless fan control support has been enabled by
#   setting the "Coolbits" X config option.

参考

関係のありそうなページ

参考にしたサイトとか