※現在CPU生成をローカルで利用している人向けです。openvinoでStable Diffusion初体験！とか縁起でもないのでやめましょう

#contents

#br
#hr
#br

* openVINOでStable Diffusionとは [#ld446d67]

''パソコンのCPUがintel製なら、今やってる1枚20分くらいのCPU生成が倍速くらいのGPU生成になるぞ！''

である。いろいろあったが、このwiki的にはこれが一番妥当な表現である。
なんか長くなったので先に結論

- CPUがintel製でtorchのバージョンの最後がcpuである人であるなら高速化が望める。xpuとかになってる人は逆に遅い
- openVINO用の形式変換が毎回行われる。メモリ32GBでも溢れる。スペックと画像サイズとLoRA数にもよるが10分くらい
- torchがcpu向けのままなのは変わらないので、グラボユーザー向け機能のオプションはcpu生成の時と同様未対応
- 一般的なGPU生成ともcpu生成とも異なる感じの生成画像になることがあるが、たぶん仕様である
#br

openVINO自体は「なんかAIっぽいものをintel製品で使う仕組み」で、Stable Diffusionだけのものではない。openVINO自体は新旧含めintelのCPU・NPU・iGPU・IntelArcシリーズ等対応しているが、前述の通り「intelのパーツが入ってれば共通で使える」ようにするのがメインなので、openVINOに切り替えたからといって、Stable Diffusionが速くなるとは限らない(高速化のための技術ではない)。CPUでもintelArcでも共通で動作するアプリをかんたんに作れる、みたいなほうに比重がかかっている。
具体的・理屈的には(py)torchが直接GPU相当依存の高速処理対応をしているものは、openVINOを通すと遅くなり得る(openVINOが使うtorchはcpuモード固定のため)。
//モードではないのだが、なんだっけバージョン表記のいちばん最後にある対応アーキテクチャの表記。アーキテクチャか。モードでいいや
''何を試しても生成に使ってるtorchのバージョン表記からcpuの文字が消えないという人向け''である。画像生成関連でopenVINOを紹介すると結構ウキウキされるのだが、速度面とかで実効性のある対象はとても狭い。最近買ったようなPCで、Stable Diffusionを速くしたいという目的だと活躍の場がないのではないだろうか。
バージョン表記にxpuとかが入ってる人は現状はIPEXを使うべき。[[IntelのGPUで画像生成]]を参照。単純な速度の話もあるが、前述の通りopenVINOが使うtorchはcpuモードのため、GPU生成で当然のように使える各種キラキラした機能が全部OFFである。そこまでしてopenVINOに拘る理由はないと思われる。

#br
** 【共通】openVINOと中間形式変換とキャッシュ [#u69f00ee]

- '''openVINOの起動時は大量にメモリが消費され、スワップが起こってPCが一時的に固まる。長くて10分くらい'''
- '''アプリによってはこの一時ファイルのキャッシュ設定があるが、トラブルしか起こさないのでOFFにしよう'''

openVINOはGPU経由で生成するとき、モデル（checkpointとLoRA）を一度中間形式に変換して画像生成を行う。必要なものを一度に読み込んで組み立てているらしく、一時的にメモリを大量に消費する。32GBでも溢れてページファイルへの退避が起こる。スペックにもよるがスワップが起こるとPCは物凄く動作が遅くなる（全体的にほぼ"止まる"のでWeb閲覧も厳しい）。使い慣れないうちはタスクマネージャーのパフォーマンスタブを表示させたままにしておくと状況に納得できて安心かと思う。かかる時間は5分前後だが、CPUとメモリ量とストレージ速度に依存する。ロースペだともう少しかかる。
中間形式データはメモリに保持されており、モデルとLoRAを変更しない限りは再利用される(再コンパイルは起こらない)。openVINOのバージョンとアプリの対応状況にもよるが、step数の変更とサンプラーの変更では再コンパイルは起こらないことが多い。プロンプトの変更もだいたい大丈夫。ただ、内部的に「前回と状況が異なる」と判断された場合は再コンパイルが起こる（プロンプトを物凄く長くしてみよう）。

アプリによってはこの中間形式をファイルに保存して次回起動後もキャッシュファイルとして利用できるように設定ができるが、openVINOの動かない・ググっても出てこないエラーが出る・何がおかしいか表現しづらいが何かおかしいといったトラブルはほぼキャッシュが原因なので、基本OFFをお勧めする。少なくとも安定して稼働するまではOFFでお願いしたい。
なおファイルサイズは''1回ごとに''5GBと10GBである。自動では消えないので設定をOFFにしたら自力で消すのがよい。
#br

* openVINOで検索するとよく見かけるWebUIアプリケーション [#wf98d255]

* ComfyUIのカスタムノード comfyui_openvino [#kfd3be6f]

https://github.com/openvino-dev-samples/comfyui_openvino

ComfyUIのノードとしてopenvinoを挟み込むもの。

すごい点： ComfyUI。ComfyUIでopenvinoが使える。SDXLで使える。画像もプラグイン経由じゃなく普通に出せる。SD.Nextの絵柄気に入らない人にも
いまいち： ComfyUI。Windows Portable版だとインストールが困難。メモリ16GBだと溢れる。C++コンパイラが必要

回線と時間とストレージに余裕のある方向け。

**インストールcomfyui_openvino [#k613c286]

現時点ではコンパイラ付属のclコマンドとかが必要。パス通って使える状態ならComfyUI Managerでopenvinoで検索してインストールするのが早くて安くて安心。
ただ、そんな人はWindowsではそれほど多くないと思われるので、以下を参考にComfyUI一式を別フォルダに手動で新規インストールするのが後腐れないと思う。torchとかも切り替わるし。

''手動新規インストール(Intel Arcテクノロジつきの人)''
公式でcomfy-cli経由のインストールの指示があるのでそっちで。というかopenvinoでなくてもよくないっすかね。
NPUは動いたという報告と動かねえという報告と動くけど遅いという報告があって使うメリットよくわからない。

''手動新規インストール(古いintel iGPUで、Windowsじゃない人)''
公式を見てなんとかしてくれ。C++コンパイラといわゆるpython-devパッケージが入ってればなんとかなるように見える。

''手動新規インストール(古いintel iGPUで、Windowsな人)''
・ Intel Arcテクノロジのない古いiGPUを日々ブン回している
・ ComfyUI Portableでやってみたけど Python.h が無いというエラーが出て検索しても意味不明

こんな人向け。後述のSD.Nextと同じ程度にはComfyUI openVINOカスタムノードはおすすめ。
ComfyUIを一度も使ったことがない場合はSD.Nextを先に試したほうがいいかもしれない。

*** 手動新規インストール(古いintel iGPUで、Windowsな人) [#q9a0212e]

iGPUさん向けメニュー
> 1. Windows版gitやWindows版Pythonは普通に入れておく
> 2. Visual Studio 2022とかのBuild Toolsを持ってなかったら入れる
> 3. 50GBくらい空いてるドライブにComfyUIをgit経由で複製する
> 4. venvフォルダを作る
> 5. venv有効にしてから、ComfyUIにtorchvisionとtorchaudioとComfyUIの依存関係をインストールする
> 6. openvinoカスタムノードをインストールする
> 7. 既存のモデルの場所をファイルで指定しておく
> 8. openvinoを有効化したComfyUIを起動する

''1. Windows版gitやWindows版Pythonは普通に入れておく''
えっまだ持ってないの？

''2. Visual Studio 2022とかのBuild Toolsを持ってなかったら入れる''
C++コンパイラに付随するものが必要。clコマンドとか。 なお、次の(a)(b)どちらかに当てはまる場合はインストールは不要なので3へ：
(a)ターミナルからclコマンドとかのC++コンパイラ一式がパス通ってて動く
(b)VSインストール済みでスタートメニューに「x64 Native Tools Command Prompt for VS 2022」がある

で、持ってない場合は以下からダウンロードしてインストール。10GBくらい必要。
https://visualstudio.microsoft.com/ja/downloads/
真ん中より下の「すべてのダウンロード」項目の「Tools for Visual Studio」項目の「Build Tools for Visual Studio 2022」が対象。ダウンロード、実行してVisual Studio Installerの指示に従いBuild Tools for Visual Studio 2022をインストールする。スタートメニューに登録されるものをコピペして使うだけなので、インストール先はデフォルトで構わない。

''3. 50GBくらい空いてるドライブにComfyUIをgit経由で複製する''
comfyui_openvino作者の指示に従うとcomfyui/venvというフォルダ構成にしづらいので先にこっちで。
以下はすべてWindowsターミナルから実行。管理者ターミナルは使う必要がないので使わないこと。

  # ComfyUIという名前のフォルダを作りたい場所に移動してから実行
  git clone https://github.com/comfyanonymous/ComfyUI

あ、ComfyUI自体は10GBないです。

''4. venvフォルダを作る''
ComfyUIフォルダの中にvenvというフォルダがある構造にする。こうじゃなくてもいいけど説明のためにこうする(ComfyUI以外でもこんな感じなので)。

  # ComfyUIフォルダの中に移動
  cd ComfyUI
  python -m venv venv

pythonというコマンド名が動作しないならpython3でもOK。なんかどうしても動かないならpython.exeのパス直書きでもOK。

  cd ComfyUI
  C:\Users\あなたのユーザー名\AppData\Local\Programs\Python\Python311\python.exe -m venv venv

実行に使ったpythonのバージョンごと「複製」されるので、python3.11かそれに近いやつでvenvする。3.12が想定されてる？
なお、他の用件でもpythonを入れてる等で、pythonとだけ打って実行したときのバージョンが想定と異なる場合、面倒なので上記のパス直書きの実行を推奨。

 PS E:\ComfyUI> python.exe
           ↓ちょっとバージョン高い
 Python 3.13.2 (tags/v3.13.2:4f8bb39, Feb  4 2025, 15:23:48) [MSC v.1942 64 bit (AMD64)] on win32
 Type "help", "copyright", "credits" or "license" for more information.
 >>> exit()

venvはフォルダを作ってしまうので、なにか間違った場合はvenvフォルダ（めちゃくちゃ消すの時間かかる）ごと普通に削除。

''5. venv有効にしてから、ComfyUIにtorchvisionとtorchaudioとComfyUIの依存関係をインストールする''
venv有効にしないとWindowsアプリ側のpythonのライブラリとしてインストールされて後々ものすごく面倒なので必ず行う。
最初のcmdは絶対必要なので忘れずに。batファイルとして書いて実行する場合はいらないけどかわりにActivate.batはcallすること。

  # ComfyUIフォルダで行う
  cmd
  
 # 1行ずつ
  venv\Scripts\Activate.bat
  
  # (venv) とか出てる？
  pip install torch torchvision torchaudio
  pip install -r ..\ComfyUI\requirements.txt

エラーなく終わったらターミナルは一旦閉じる。ここでエラー出た場合は知らん。
cmd打ち忘れなどで対象となるpythonを間違ってインストールした場合、pip installのかわりにpip uninstallとするとだいたい戻るはず。
// openvinoでtorchアンインストールするので無駄と言えば無駄なんだけど、一般的な記述から文字減らすと「俺のが動かないのはここが"間違ってる"からか？」と疑念の元になるだけなので全部書く

''6. openvinoカスタムノードをインストールする''

さっきやったらcmd忘れてローカル側のpythonに入ってムキーってなったのでここに書いておく。
ComfyUI Managerを利用可能にするために、まず[[ComfyUI Managerをgit経由でcustom_nodesフォルダに複製>https://github.com/Comfy-Org/ComfyUI-Manager?tab=readme-ov-file#installationmethod1-general-installation-method-comfyui-manager-only]]する。
ComfyUI Managerはgit cloneしたあとにComfyUIを起動すればpip install相当を自動でやってくれる。でもここでやる。

  # ComfyUIフォルダで行う
  cmd
  
  # 1行ずつ
  venv\Scripts\Activate.bat
  
  # (venv) とか出てる？
  git clone https://github.com/ltdrdata/ComfyUI-Manager custom_nodes\comfyui-manager
  pip install -r custom_nodes\comfyui-manager\requirements.txt
  
  # (venv) とか出てる？
  git clone https://github.com/openvino-dev-samples/comfyui_openvino custom_nodes\comfyui-openvino
  pip install -r custom_nodes\comfyui-openvino\requirements.txt

openvinoカスタムノードを普通に複製するとフォルダ名が「comfyuiあんだーばーopenvino」になってComfyUI Managerの命名規則と反してしまうので、コマンドライン上で「comfyuiはいふんまいなすopenvino」にしておく。
ComfyUI\custom_nodesというフォルダにcomfyui-openvinoというフォルダができて、中にnode_openvino.pyというファイルがある状態が成功。
場所間違った場合はinstall前ならcloneしたフォルダを消す。pip installしてしまった場合は同じファイルを指定したpip uninstallを行ってからcloneしたフォルダを消す。

''7. 既存のモデルの場所をファイルで指定しておく''
もし既存のStableDiffusion生成アプリを使っていてcheckpointやloraの詰まったフォルダが既にあるのなら、事前に以下を行う。あとでやってもいいのだけど、生成テストに使うファイルがなくて起動後に即閉じする羽目になるだけなので、今のうちにやる。

> ComfyUI\extra_model_paths.yaml.example

を「エクスプローラ上でコピーして」

> ComfyUI\extra_model_paths.yaml

に変更し（つまり、exampleファイルは直接編集せずにとっておく）、中身を次のように変更。

「モデルの入ったフォルダの管理方法がComfyUI以外の一般的なアプリ」の場合は、6行目くらいから始まる
  a111:
      base_path: path/to/stable-diffusion-webui/
の、base_pathの部分を
  a111:
      base_path: E:\SD\_SD_MODELS
といった感じに変更。E:\SD\_SD_MODELS\models\Stable-diffusionにcheckpointファイルがたくさん入ってると想定。

「モデルの入ったフォルダの管理方法がComfyUI」の場合は、26行目くらいから始まる
  #comfyui:
  #     base_path: path/to/comfyui/
  #     checkpoints: models/checkpoints/
  (中略)
  #     upscale_models: models/upscale_models/
  #     vae: models/vae/
の先頭の「#」を全部外したうえで
  comfyui:
       base_path: path/to/comfyui/
の、base_pathの部分を
  comfyui:
       base_path: E:\SD\ComfyUI_windows_portable
といった感じに変更。E:\SD\ComfyUI_windows_portable\ComfyUI\models\checkpointsにcheckpointファイルがたくさん入ってると想定。

''8. openvinoを有効化したComfyUIを起動する''
毎回やるのめんどくさいので、以下を記述したComfyUI\run_openvino.batを作成する。ファイル名はportable版にちなむ。

  call "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvars64.bat"
  call .\venv\Scripts\Activate.bat
  python main.py --cpu --use-pytorch-cross-attention
  pause

1行目のごついcallの引数は

>  「Windowsスタートメニュー」→
>  「Visual Studio 2022(※フォルダのほう)」→
>  「x64 Native Tools Command Prompt for VS 2022を右クリックして"詳細>ファイルのある場所を開く"」→
>  「x64 Native Tools Command Prompt for VS 2022というファイルの右クリックプロパティの"ショートカット"タブの"リンク先(T)"」

…にある内容。comfyui_openvino公式で「x64 Native Tools Command Prompt for VS 2022を起動してそこからmain.pyを起動しろ」と指示があるが、その自動化である。

もし出力先のフォルダをある程度事前に指定したいのなら、main.pyに--output-directoryで指定する。（画像保存のノードのファイル名プレフィックスに毎回フォルダ名書いちゃってもいいんだけど）

 python main.py --cpu --use-pytorch-cross-attention --output-directory 出力先フォルダ

ともあれ今作ったrun_openvino.batをダブルクリックすると起動する。はずである。 「To see the GUI go to: http://127.0.0.1:8188」といった表示がターミナル上にあるはずなので、Webブラウザで http://127.0.0.1:8188 にアクセスする。お使いのセキュリティソフトが「pythonというアプリが通信を行おうとしています」と報告してくる場合、心当たりがあるなら（あるので）今回のここに限り許可する。なお、知らないタイミングで出たときなど、なんでもかんでも許可しないこと。

** openvinoノードを接続して生成する [#u4c44e61]
えっComfyUI全然使ったことないの!? 誰かそのへんの人に聞いてきなさいTextToImage生成ができれば今回はいいです

■ ''TorchCompileDiffusionOpenVINO''

右クリック＞ノードを追加＞openVINO にある「TorchCompileDiffusionOpenVINO」か何かそんな名前のものが生成に必要。バージョンによってノード名が違うのだが、モデルの入力とモデルの出力があって、deviceの設定ができるやつがたぶん正解。

  [Checkpoint] -- [openVINO (Diffusion)] -- [Ksampler]
  [Checkpoint] -- [LoRA] -- [openVINO (Diffusion)] -- [Ksampler]

といった形で繋ぐ。「KSamplerのmodel入力の直前にopenvinoがある」状態であればよい。modelを繋ぐ線がたくさんある場合は知らん。
deviceはなんとなく検出されたPCの内容によって「CPU」「GPU」「NPU」が表示される。CPUだとCPUを使って生成するだけなので、GPUかNPUを選択。

■ ''TorchCompileVAEOpenVINO''

VAEのコンパイルができる。使ってるノードによっていろいろ複雑になると思うのだが、概念上は

  [VAE Loader] -- [openVINO (VAE)] -- [VAEデコード] -- [画像出力ノード]
  [CheckpointのVAE] -- [openVINO (VAE)] -- [VAEデコード] -- [画像出力ノード]

のような構成にする。VAEのエンコードとデコードの線をあちこち連れ回している場合の正解は不明。いろいろ試してくれ。
項目のencoderコンパイルとdecorderコンパイルは基本両方ともtrue。
remove_compileという項目がある場合、基本false。なにかvae関連のエラーや謎のエラーや謎の色調反転画像やらがある場合、trueにしてみるとよい。

■ ''LoRAとの関係''

以下の位置関係で繋ぐ。

  [Checkpoint] -- [LoRA] -- [openVINO (Diffusion)] -- [Ksampler]

LoRA起因の問題があった場合、LoRAでエラーですと終了するのではなく、CPU使用モードに切り替えて生成を継続を試行するようである。なので

- 他のLoRAを使うとGPU生成する→ そのLoRAがなんか悪い
- LoRAのノードを外して生成するとGPU生成する、LoRAつきで512x512とか極小サイズにするとGPU生成する→ メモリが足りない

という地道な切り分けが必要。
なお、現行のcomfyui-openvinoはperformance modeやquantizationを操作する設定がないので、メモリ不足になる場合の対処法がない。
※ComfyUI起動時のオプションはuse-pytorch-cross-attention以外対応していない
この記事の下にSD.Nextという別アプリがあるのだが、SD.Nextよりはサイズの制限が厳しい印象。[[comfyui-openvinoはオリジナルモデルとopenVINO変換後モデルの両方をメモリに保持するよ>https://github.com/openvino-dev-samples/comfyui_openvino/issues/15#issuecomment-3342302786]]という朗らかなやり取りがある。そりゃ厳しい。

■ ''LoRAとのおまけ''

つまり生成時にLoRAをゼロから読み込んでcheckpoint改変するからメモリ不足になるわけであって、事前にLoRA適用して改変した状態をopenvinoに渡せばワンチャンあるんじゃね？
ということで、ComfyUIにある「checkpoint読んでLoRA読んだ状態をcheckpointとして保存する」という機能を活用するとうまく行くことがある（改変後大きすぎるとやっぱりダメ）。
構造は以下。3個しかないので空のワークフローを作ってそこで実行するとよい。

 [チェックポイントを読み込む] -- [LoRAローダーモデルのみ] -- [チェックポイントを保存]

読み込みの、モデル・CLIP・VAEの3本を保存のところまで繋ぐ。ただしモデルの線はLoRAに寄り道させる。
バッチ数1で実行すると（メモリ不足になるような環境だと）10分くらいかけてsafetensorsファイルとして保存されるはずなので、いつものcheckpoint置き場にエクスプローラ経由で移動させて利用。ファイルサイズは10GB超。
ComfyUIのノードは対象のファイルやフォルダが変更されても自動で追従はしないので、ファイルやフォルダを読み込むノードをクリックで選択してからキーボードの r を押して「ノード定義を更新」を行うと楽。
LoRAにいわゆるトリガーワードがある場合、事前に埋め込んで"活性化"させておくことができるのかは知らない。
これ実は「モデルのマージ」という深い沼なので、これ以上はお近くのComfyUIに詳しい人に直接聞いて欲しい。

** ComfyUI+openvinoエラーとかコーナー [#ob9c9b3c]

■ ''キャッシュの設定はないんですか？''
1.1.2くらいで項目が無くなった。openVINOキャッシュは最初から無効で、制御もできない。

■ ''UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8d in position 214: invalid start byte''
手順8で作ったrun_openvino.batファイルの1行目(つまりいちばん最初)にchcp 65001を追加する。
…か、cmdで表示できないファイル名をもつcheckpointやloraを軒並み改名する。

■ ''RuntimeError: Compiler: cl is not found''
だからビルドツールは必要なんだって

■ ''include ファイルを開けません。'Python.h':No such file or directory''
Portable版でやるのは非推奨です

■ ''include ファイルを開けません。'pyconfig.h':No such file or directory''
Portable版でやるのは非推奨です

■ ''LINK : fatal error LNK1104: ファイル 'python311.lib' を開くことができません''
Portable版でやるのは非推奨ですってば（Windows版からファイル入ってるフォルダ移植すると動くかもしれないが自己責任で）

なお、「Windowsでvenvしたときになぜかlibsフォルダの中身を持ってきてもらえないのでopenvinoのファイル変換をclでやるときにpython311.libとかがないというエラーになる」というのがあるみたいなので、その場合は
 C:\Users\あなたのユーザー名\AppData\Local\Programs\Python\Python311\libs
とか
 C:\Python311\libs
とかにある、''venvを実行したpythonのバージョンの''libsフォルダごと ComfyUI\venv\Scripts\libs という形になるようにコピーするとclが動く。はずである。

■ ''CPU生成に切り替わる。おまけになんだか遅い''
openVINOがエラーを起こした場合、

- それっぽいエラーが出てその周回がスキップされる
- それっぽいエラーは出ず、CPU経由の生成に内部で勝手に切り替わる
- それっぽいエラーが出てその周回がスキップされ、CPU経由の生成に切り替わるのだが、openVINOなしでCPU生成したときの数倍の時間がかかる

という3パターンくらい存在する。
3つめが厄介。とりあえずなにかおかしいということしかわからない。ImpactWildcardProcessorのようなプロンプトが自動で伸びたり縮んだりするものを使ってる場合は[[SD.Next組み込みのwildcardsを利用しているが、途中でベクトル表記付きのエラーで止まる>#f3d7b61f]]も参照。

■ ''画像が一面マーブルっぽくなる''
CLIP_SKIP相当でうまく動作していない。「CLIPの最終層を決定」とか「clip skip layer」みたいなノードを外してみる。

■ ''fp8モデルが動作しない''
fp16から上じゃないとダメらしいよ？

#br
#br

* SD.Next [#hfa4e7b1]

https://github.com/vladmandic/automatic

openVINOを使いたい場合、現状最適解の位置にあるStable Diffusion生成アプリ。
webui-user.batに相当するものがついてないので、自作して起動オプションを記載するのが吉。オプションに --use-openvino とするだけで、初回はインストールを、初回以降はopenVINO対応を、全部やってくれる。

 @echo off
 webui.bat --use-openvino --models-dir メインアプリのモデルフォルダパス\models

SD.Next本体でSettingsを変更しても再度起動したときに戻っていることがあるが、ここのopenVINO利用設定で上書きされている。
2024年の冬以降のopenVINO設定はユーザーも増え、初期値が見直され、「openVINOに関係ないもの・動作しないと報告があったもの」はだいたい最初からOFFになっている。むしろ変更してもopenvinoオプションつきで再起動すると戻っていたりもする。どうしてもうまく動作せず、なおかつ変更後の挙動に心当たりがあるときにのみ変更を検討するとよい。

ここがopenVINOのページで、さらにSD.NextのopenVINOへの細かい対応が薄いため（継続的なユーザーの絶対数が少ないのだと思う）、「使えなさそうなアプリ」のような印象を受けるが、SD.Nextから見たopenVINOは対応バックエンドのひとつでしかない。また、この記事はSD.Next本体の使い方は説明しない。あくまで、SD.NextでopenVINOを利用したときのエラーなどをメインに扱う。
// SD.Nextのページがあってもいいような気がするがopenVINOでしか使ってない(一般的なグラボ、cudaで使う部分が丸ごと未経験で試用もできない)ので他の人にお任せ
#br

** SD.NextとopenVINOのもめごとをどうにかしたいコーナー [#x933d4ec]

*** キャッシュ設定どこですかね [#je4333d3]
古いSD.Nextではキャッシュ生成と利用が有効になっている。キャッシュ無効化の設定項目があるので以下をON。

 [ ] OpenVINO disable model caching

*** openVINOだけをうまくバージョン指定したい [#x9d85b27]

'''→できるけどおすすめはしない'''

環境変数OPENVINO_PACKAGEに、pipのrequirements.txtの書式でopenvinoのパッケージバージョンを指定する。
だいたいダウングレード用。SD.NextのGUI側のサポートは特にない（当時の選択肢verに戻ったりはしない）ので、どうしても特定の機能を避けたい場合にのみ検討を。

// https://github.com/vladmandic/automatic/issues/3512
 REM Windows版の.batに書く場合
 set OPENVINO_PACKAGE=openvino==2024.2.0
#br

*** SDXL画像生成の最後のVAE時にエラーが出て真っ黒画像になる [#y32411ed]

'''→baked VAEを使うのには調査と設定がいるらしい。前はこんなことなかったと思うのだが'''

だいたいこんなエラーが出る：
 ERROR  Decode: sample=(768, 1024, 3) invalid=2359296 dtype=float32 vae=torch.float32 upcast=True failed to validate

よくわからんが
> CPU mode: BF16, FP32
> GPU mode: FP16
// https://github.com/vladmandic/automatic/issues/3667

という対応らしいので、VAEを自力で、一般的な「sdxl_vae.safetensors」にしてみて再チャレンジ(巷にあるのはFP16のはず)。うまくいったらFP32VAE関連と思われるので、

- sdxl_vae.safetensorsを使い続ける
- Model Compile>Compile ModelのVAEチェックを外し、Execution Precision>Device precision typeでBF16かFP16を指定

のどちらかの運用にする。後者のはどっちかでいいような気がするのだが一旦どっちもで。

#br

*** 他のアプリで生成した絵と比べて細部が少し変わる [#y94c05d3]

'''→仕様。寄せたければPrompt attention parserを「a1111」に'''

実は、SD.Nextのテキストエンコーダは他のアプリと少し異なる独自のものを使っている。Text EncoderのPrompt attention parserを「a1111」のものに変更するとしっくりくると思われる。
#br

*** SD.Next+openVINOで絵がおかしい [#pae53666]

''絵がおかしい(1)：特定のモデルやLoRAで、絵はできてるが、表面(?)がおかしい''
'''→サンプラーによってはそうなるらしい。ダメ元で変えると直ることがある'''

まず、openVINOが動作すると言われているsamplerは以下の通り。この一覧はけっこう古く、これ以外の、新しいものなどは使えたり使えなかったり対応されてたりする。一旦はEular aで試すのがいいと思う。

- Euler、Euler a
- LMS、LMS Karras
- Heun
- DPM++ 2M、DPM++ 2M Karras
- DDIM、PLMS

そのうえで、モデル推奨のサンプラーなどとは別に「Eulerを使うと塗りがガサガサするがDPM++ 2M Karrasだと普通」のようなことが起こる。ガサガサしているEularの画像を他のopenVINOを使わないアプリで読み込んで再生成するとキレイになるので、openVINO側の原因だと思われるが、よくわからない。
#br

''絵がおかしい(2)：1周目の最初だけ毎回おかしい''
'''→理由は不明だが、直前の生成情報が参照されている。アプリ本体を閉じて再度起動が無難'''

どこかに何か直前の情報が残ってて混じってるのだと思われる。SD.Nextを一度終了させて再度起動して生成させると何も変な画像にならないので（Restert Serverでは駄目）、手間でなければ。openVINOが間借りしてるoliveとかあのへんのキャッシュが悪さしてるんじゃないかと思っているが確証はない。
checkpoint/LoRAを変更した直後や起動した直後の1枚目はおかしいことがあるので捨てる、という運用でもいいような気はする。お好みで。
//プロセス単位で何か掴んでるキャッシュ的な何かがどうにか…

 ↓怪しい？怪しくない？
 [*] Olive cache optimized models
 ↓これはONの維持推奨(=毎回の起動時には一時ファイルを全消しするように)
 [*] Cleanup temporary folder on startup

#br

''絵がおかしい(3)：絵はできてるが、プロンプトがかなり無視されて別物''
'''→mode:accuracyに変更'''

2024年のopenVINOあたりで、openVINOにaccuracy modeが導入された。SD.Nextでも設定があり、それが影響している。

|mode:performance&br;(デフォルト) |デバイスがbfloat16対応(例：AVX512_BF16、AMX)ならf32ではなくbf16で計算する|
|mode:accuracy|デバイスにf32を強制し、CPUの場合デフォルトで行われていたDynamic quantization処理を無効にする|

つまりmode:performanceが省きすぎて別物になってる場合にはmode:accuracyに変更するとよい。

// https://docs.openvino.ai/2024/learn-openvino/llm_inference_guide/llm-inference-hf.html#enabling-runtime-optimizations
https://docs.openvino.ai/2024/openvino-workflow/running-inference/optimize-inference/precision-control.html
#br

''絵がおかしい(4)：昔のSD.Nextで作った絵と全然違う''
'''→mode:accuracyに変更'''

上記同様、OpenVINO accuracy modeが影響している。mode:accuracyに変更するとよい。なお次項参照。

*** 昔のSD.Nextではできていたサイズの生成がCan not allocateのメモリ不足系エラーで作れない [#f3cf56e4]

SD.Next（と、openVINO本体）でaccuracy modeが導入されるより前は、CPU生成をしたときはDynamic quantizationというものが使われ、適度にデータを削りつつ省メモリにしていたのだが、accuracy modeが導入されて以降はモードをperformanceにしてもaccuracyにしてもDynamic quantizationの処理が行われなくなった。
つまり、現状、

- 過去とは別な理屈でガンガンデータが削られて省メモリだが再現性がない mode: performance
- だいたいオリジナルっぽい外見になるが全然省メモリされてない mode: accuracy

のどちらかとなる。欲しいのは

- Dynamic quantizationでデータが削られてまあまあ省メモリのやつ

なのだが、そういう設定はSD.Nextから触れる範囲にはないようである。
SD.Nextはmodules\intel\openvino\__init__.pyでopenVINOを起動してるのだが、ExecutionMode.ACCURACYではない状態でDYNAMIC_QUANTIZATION_GROUP_SIZE=64とか直接設定すればいけるはず。情報募集中。

https://docs.openvino.ai/2024/learn-openvino/llm_inference_guide/llm-inference-hf.html#enabling-runtime-optimizations

#br
余談：なお、''こんなこと''になってしまう前のSD.Nextを使うという手もある。だいたい2024年の9月ごろからおかしいので、2024-08-31あたりのファイルである
https://github.com/vladmandic/automatic/tree/4d9c7ba77e3c4bce2bd3ca74e0bfa5009dd5c05c
を
 git clone https://github.com/vladmandic/automatic.git sdnext0831
 cd sdnext0831
 git checkout 4d9c7ba77e3c4bce2bd3ca74e0bfa5009dd5c05c
とかで取得して使うとよい。このままだと中途半端だとgitが文句言うが別途調べてくれ。
#br

*** たくさん生成していると周期的にエラーが出る気がする [#t910351e]

これも理屈はわからないのだが、DeepCache cache intervalを1に設定すると激減する。

エラー例：
 Requested output shape [770,2048] is incompatible with input shape

#br

*** SD.Next組み込みのwildcardsを利用しているが、途中でベクトル表記付きのエラーで止まる [#f3d7b61f]

プロンプトのトークン数が75か77の3倍か4倍の境界を跨いだとき、openVINOの再コンパイルが起こり、直後にエラーになる、という流れがある気がする（LoRAを変更した直後になぜかエラーになるやつと傾向が類似）。
Stable Diffusionが受け付けできるトークン数の最大値は仕様的に77で、それでは短すぎるということでSD.Nextに限らず各地でいろいろ内部細工をしているのだが、それとopenVINOの相性がよくないのかもしれない。
wildcardsのような自動プロンプトを利用しているとハマりやすい。ランダム出力部分のトークン数を精密に(泣きながら)揃えるか、プロンプトの大部分をコンマ抜きにしてトークン数を稼ぐ運用をするくらいしか対処はなさそう。

#fold(エラーとトークン数){{
最後に生成し損ねた（エラーになった）プロンプトはエラーになって終わったWebUIのサムネ一覧画像の下に表示されているはずなので（sdnext.logのエラー表示とParametersのindexの値が同じことに注目）、正プロンプト部分をコピーしてプロンプト入力欄に貼り、右肩に表示される「233/75」といった数字の233部分を77とかで割ってみるとなにか掴めるかもしれない（=3.0259...）。通常画像のプロンプトのコピペは画像を無理矢理メモ帳で開くと便利（通常のかしこいエディタはバイナリの表示処理をしたりするので逆に不便不適）。生成し損ねたプロンプト本文は本体側のログファイルには残らず、WebUIを更新すると消えてしまうので、追跡調査したい時は注意（sdnext.logにあるwildcardsの生成ログから人力再構成はできるが大変手間である）。
起こるエラー例は以下：
 2025-01-16 00:27:02,073 | sd | ERROR | processing_diffusers | Processing:
  args={'prompt_embeds': tensor([[[-0.9315, -1.2590, -0.3556,  ..., -0.5484, -0.2234, -0.0566],
 (■ベクトル表記中略1)
 'pooled_prompt_embeds': tensor([[ 0.0975,  0.2765, -0.1881,  ...,  0.1111,  0.1252,  0.2509]]),
  'negative_prompt_embeds': tensor([[[-0.9315, -1.2590, -0.3556,  ..., -0.5484, -0.2234, -0.0566],
 (■ベクトル表記中略2)
 'negative_pooled_prompt_embeds': tensor([[-0.7722, -0.4779,  0.6809,  ..., -0.0427,  0.4145,  0.6125]]),
 (■生成時のサイズ情報など中略)
 Check 'false' failed at src\frontends\common\src\frontend.cpp:47:
 Loading input model
 AttributeError: 'TorchFXPythonDecoder' object has no attribute '_inputs'
 (■pythonのバックトレース表示中略)
 2025-01-16 00:27:02,121 | sd | ERROR | errors | Processing: RuntimeError
}}

***  Network load: type=LoRA name="LoRA名" detected=xl failed [#u9a65054]

''その1''

 WARNING  Network load: type=LoRA name="eroero-lora-v1" type=set() unmatched=2166 matched=0
 ERROR    Network load: type=LoRA name="eroero-lora-v1" detected=xl failed

まれに見る。そのタイプのLoRAにはまだ対応してない？らしい。SD.Nextでなければエラーなく動作すると思う。
[[[Feature]: Support for Flux depth and canny loras#3714>https://github.com/vladmandic/sdnext/issues/3714]]

''その2''

 ERROR    Network load: type=LoRA name="eroero-lora-v2" Checkpoint not supported because layer lora_unet_label_emb_0_0.alpha not supported.
 ERROR    Network load: type=LoRA name="eroero-lora-v2" detected=xl failed

たまに見る。LoRA内でdiffusersでは動作しないデータを設定していて、diffusersとしてはわかりませんと拒まれてる状態。LoRA作成スクリプトが悪い（または、わけもわからずLoRA公開してる人が無責任）。
//SD.Nextがdiffusersを採用したのが悪いと言えないでもない
ファイル内からデータ部分を物理的に消せば通るのだが、250MBとかのファイルを編集保存するのは厳しい。変換するpythonスクリプトがいくつかあるようだけど実行するの怖いので自己責任で。
これもSD.Nextでなければエラーなく動作すると思う。

ttps://civitai.com/articles/15204/valueerror-checkpoint-not-supported-because-layer-loraunetlabelemb00alpha-not-supported
…が消えてるので
https://github.com/MokubaAttack/scripts/tree/main/lora_mod

diffusersのissueで揉めた例↓
https://github.com/huggingface/diffusers/issues/6368#issuecomment-1965993330

*** Network load: type=LoRA name="lora名" adapters=[] not loaded [#d8ad12fd]
*** Network load: type=LoRA name="lora名" adapters=["lora1つ目", "lora2つ目"] not loaded [#c3d6f321]

時々見る。新SD.Nextで見る。なんらかの理由で、ストレージから読み取ったloraファイルがloraファイルとして解釈できなかったときに起こる。
どっちかのなにかのどこかが未対応かなにかだと思われるので対処法は特にない（例によってSD.Next以外のDiffusers使ってないアプリなら動作すると思う）。
なお、

 [*] LoRA load using Diffusers method

の初期値ONのチェックを外すことでエラーになっているloraに限っては読み取れるようになることがあるが、他のloraが動作しなくなる可能性がある。
エラーの文言は見かけが2パターンあるが、エラーとしてはどちらも同じ。adapters=[～]の部分はその時点で読み取りに成功しているloraの名前が入る。1個だけ指定してるloraや1個目に指定してるloraがエラーになった場合は読み取り成功済みリストは空っぽなので「adapters=[]」になるという理屈。


#br
* FastSD CPU [#lca67e3f]

https://github.com/rupeshs/fastsdcpu

Win/Mac/Linux/Termux+PRoot対応の、LCMモデル＆OpenVINOコンバートモデル用の画像生成アプリ。
// どう考えてもTermux+PRootは普通ではないのでAndroid対応と表現するのは禁止です禁止
「通常のWebUI系アプリで1枚何十分もかかるので、設定をこねくり回して頑張ったがなんの成果も得られませんでした」みたいなopenVINO好きのするロースペ向け生成環境を埋め込みで提供している。生成画像サイズに応じた空きメモリと時間さえあればだいたいの環境でなにがしかは生成できるはず。

ただし、そのかわり、うまくいくよう調整されているお仕着せのこと以外をやりたいという希望を叶えるのはけっこう難しい。2025年7月の時点で、

-プロンプトのトークン数の限界が77個でそれ以降は無視される（大昔のWebUIにあった制限そのまま）
-SDXLは(1)LoRAに非対応(2)Civitaiで一般的なsafetensors形式が読めない(authername/modelでHuggingFaceにアクセスする形式)
-openVINOは使えるが、あらかじめモデル変換してHuggingFaceに置いておく必要がある

という、超遅いが超自由な他アプリでのCPU生成に慣れた身にはわりと厳しい制限がある。

openVINOにこだわらず、LCMやLightningの外見が平気で、''ウチの古いパソコンでも1時間に何枚もえっちな画像を生成するシーンを味わいたい''という願望があって、使いたいモデル（の非作者による複製品）のちゃんとフォルダ分けされてるやつがHuggingFaceに置かれてるのなら一考の価値はある。えっちな画像じゃなくていいならネットサービス等の画像生成で昨今は充分なので、要はえっちな画像のためである。さあ素直になるんだ。
余談だが「Use locally cached model or downloaded model filder(offline)」のチェックは利用モデルのダウンロード成功後に有効のこと。HuggingFaceのオーサー名/モデル名で取得したファイルは何も設定してなければ{ユーザーホーム}/.cache/huggingfaceにある。Windowsなら C:\Users\ユーザー名\.cache\huggingface。
#br
#br


#br

* openvinotoolkit/sd-webui-openvino ※エクステンションのほう [#i4d22f26]

https://github.com/openvinotoolkit/sd-webui-openvino

A1111用に追加して使うExtension。
うちのローカルで使うA1111ではSigLIP関連の謎っぽいエラーで動作しないので使えた人いたらなんか書いて欲しい。COMMANDLINE_ARGSが足りないのだろうか。それともPC本体側に別途openVINOのインストールが必要？

    ImportError: cannot import name 'SiglipImageProcessor' from 'transformers'
      (E:\SD\stable-diffusion-webui\venv\lib\site-packages\transformers\__init__.py)

SiglipエラーはDiffusersが新しいことで古いTransformers?に対応できず起こるので、（下のhuggingface_hubとともに）古いもので上書きすることで動かすことはできる筈。ただ、それに対応できるOpenVINO、OpenVINOに対応できるTorch関連と、ドミノ倒し的に古いライブラリで上書きになるので、webui extensionsでなければ駄目という人以外は他を使ったほうが手軽かつ確実。
一例として、こちらの環境では
huggingface_hub==0.23.5, Diffusers==0.26.0, openvino==2024.2.0, torch==2.1.2
で上書き（requirements_versions.txt編集なり、activateしたvenvでpip install --upgradeで直接なり）、webuiが通れば起動時にinstalling extensionsでopenvinoも表示されT2Iタブ内のControlNet下にOV extensionが選択できるようになった。が、75トークン超は使えず…
#br
#br

* openvinotoolkit/stable-diffusion-webui ※A1111のフォークのほう [#s531949a]

https://github.com/openvinotoolkit/stable-diffusion-webui

2023年のstable-diffusion-webuiに「openVINOで生成」というscriptを追加したもの。
openVINOが確実に動作すると思われるもののひとつ。残念なことにフォーク時のA1111がかなり古く、新しい環境ではうまく動かない。過去のメジャーな不具合や残念動作も残ったままで、プロンプトの77トークン以降は切り捨てられる。

使用時はSelect a deviceで「GPU」を選択。それでも動かない場合、たぶんGPU相当が新し過ぎる（このアプリの想定はopenvino2023.2.0）。
キャッシュ設定はないが、アプリ直下のcacheというフォルダに自動で溜まっていく。手動で消すか、いっそ起動のbatファイルで毎回消すようにするとよい。

**力技で解決コーナー ※A1111のフォークのほう [#pef7fe2a]

*** huggingface_hubのエラー [#j81934bf]

 *** Error loading script: openvino_accelerate.py
 （中略）
    ImportError: cannot import name 'cached_download' from 'huggingface_hub'
      (E:\SD\stable-diffusion-webui\venv\lib\site-packages\huggingface_hub\__init__.py)

メンテされてないせいでhuggingface_hubの破壊的変更に追随できておらず、現在普通にインストールすると上記のエラーで動作しない。
issue参照：https://github.com/openvinotoolkit/stable-diffusion-webui/issues/122
参考：https://github.com/easydiffusion/easydiffusion/issues/1851
……。

 ＜requirements_versions.txtの最後あたりに追加しvenv/を消して再度起動し再インストールさせる＞
 huggingface_hub==0.23.5

ヨシ！（あまりよくない）

// t = "t"
*** text_encoder_2 のエラー [#i2fa903f]

 TypeError: StableDiffusionPipeline.__init__() got an unexpected keyword argument 'text_encoder_2'

「Loaded checkpoint is a SDXL checkpoint」をチェックし忘れるとこれが出る。SDXLかどうかはこのころはまだ申告制だったので、SDXL使用の場合はチェック。

*** モデルやLoRAのファイルが見つかりませんエラー [#p3eb8b4e]

 FileNotFoundError: [WinError 2] 指定されたファイルが見つかりません。:
    'E:\\SD\\stable-diffusion-webui\\models\\Stable-diffusion\\DosukebeModel.safetensors'

 OSError: Error no file named SuperOgeretsuLoRA.safetensors found in directory
    E:\SD\stable-diffusion-webui\models\Lora.

COMMANDLINE_ARGSには

 --data-dir フォルダ/models --ckpt-dir フォルダ/models/Stable-diffusion --lora-dir フォルダ/models/Lora

// r ="r"
が追記されてるんだがなんか足りないらしい。openvino_accelerate.pyがエラー起こしてるようなので、細かい設定を読まずに内部で決め打ちしてるのかもしれない。シンボリックリンクのようなものをうまく張るか、table-diffusion-webui\models\ の下の各ディレクトリにsafetensorsファイルをコピペ（お試しならこれが気楽なはず）。

*** 黒い画面にプロンプトの一部分が晒される [#edcc2c09]

 The following part of your input was truncated 
  because CLIP can only handle sequences up to 77 tokens: （以下なんか恥ずかしいプロンプト）

プロンプトの77トークン以降は切り捨てられる。各種"記号"なども「1個」にカウントされたりするので、余裕をもって書く。かなり厳選する必要があるのでけっこう大変。
一応のテクニックとしては「一度コンマなしでやってみる」というのがある。コンマは1トークンなので消しまくると結構余裕を稼げるうえに、そこまでぐちゃぐちゃにもならない（全くぐちゃぐちゃにならないわけではない）。ただ、コンマ最低限使用プロンプトで生きていくと決めた場合、従来型である単語コンマ列挙からのプロンプト並び替え＆作り替えの吟味の手間が別途発生はする。正直けっこう難しい。

#br

#hr

#pcomment(,7,reply)