diff options
| author | tanaka takashi <isazaka@gmail.com> | 2026-10-14 02:21:50 +0900 |
|---|---|---|
| committer | tanaka takashi <isazaka@gmail.com> | 2026-10-14 02:21:50 +0900 |
| commit | 583a56f1ac3d9be9ce2f8c1715d77423347d4a4e (patch) | |
| tree | ec2789b91bfa4cfded83fa64adf044347926ecbf /docs | |
| parent | 213e738140859dbcc12c2540ce40d6b6d2875aa7 (diff) | |
stdio MCPのツール一覧取得でも、受付開始前にModelManagerがSD本体・
外部VAE・LoRAをロードし、CUDAへ転送していた。画像生成しない通常の
質問でもこの起動コストが発生するため、有効な生成要求の実行時まで
モデル初期化を遅らせ、一覧取得時の不要な遅延とVRAM消費を除去する。
実装:
- ModelManagerの構築時は未ロード状態とし、冪等なload()を追加する。
- 初期化ロックで二重ロードを防ぎ、成功時だけモデルを保持する。
失敗時は未ロード状態を維持し、次の要求で再試行できるようにする。
- 3種類の生成メソッドからload()を呼び、既存サービスの入力検証・
生成ロックを経由したワーカースレッド内で初期化する。
- ControlNetと前処理モデルの既存の遅延ロード・モデル共有を維持する。
- 起動・設定読み込みと実際のモデルロードのログを分離し、ロードの
開始・完了・失敗をstderrへ出力する。
- benchmarkの計測区間で明示的にload()を呼び、ロード時間とVRAMの
計測の意味を維持する。READMEにロードタイミングと確認手順を追記する。
変更範囲:
- stdioのプロセス起動・終了方式を維持し、常駐化やHTTP切り替え、
チャット側の接続管理・一覧キャッシュ・アイドル解放は追加しない。
- MCPスキーマ、設定形式、CLI引数、プロンプト・seed処理、scheduler、
生成サイズ、PNGメタデータ・保存仕様は変更しない。
- 設定とモデルファイルの存在確認は起動時に残し、モデル互換性・
CUDA・推論依存関係のエラー検出は初回生成時へ移す。
- 同一プロセス内ではモデルを再利用し、終了時に解放する。
別の生成プロセスでの再ロードは引き続き許容する。
回帰テスト:
- 修正前の既存69件に対し、修正後は追加18件を含む87件すべて成功。
既存テストと期待値は変更していない。
- CLI/stdioでの一覧取得時にモデルロードと推論ライブラリのimportを
禁止しても成功することを確認する。
- 全生成方式の初回ロード、ワーカースレッド実行、同時要求、冪等性、
不正入力・無効なControlNet指定、失敗後の再試行、ログを検証する。
- ruff check .は成功、pyrightは0 errors / 0 warnings。
実GPU・stdioでの確認:
- 現在の設定(外部VAE、2件のLoRA、LCM、6 steps)を維持して計測した。
- 起動から一覧取得までの時間は8.233秒から0.671秒に短縮した。
- 一覧取得前後のGPU全体の使用量は修正前808→3233 MiBに対し、
修正後682→682 MiBで増加しなかった。
- 同じ接続で2枚生成してもベースモデルのロードは1回で、一覧取得では
0回だった。ロード時間は7.812秒で、初回生成要求に移った。
- 同じ設定・プロンプト・seedによる修正前後の画像は画素が完全一致。
PNG形式・寸法・メタデータと、返却PNGおよび保存PNGの一致を確認した。
- 最終版スクリプトでの再確認でも一覧取得0.655秒、初回生成14.089秒、
2枚目1.221秒で、画素・保存結果の一致と生成プロセス終了を確認した。
- 通常質問の親アプリの処理経路でも、LLMのみをスタブ化し、実際の
設定済みuvコマンドで一覧取得・3ツールの登録を確認した。
- 計測スクリプトと詳細な検証報告を追加する。生のJSON・stderr・PNGは
gitignore対象のdata/verification-lazy-loadに保存する。
確認の限界:
- Windowsのプロセス別VRAMはN/Aのため、GPU全体の使用量・プロセス一覧・
tasklistによる終了確認で評価した。全体値には他プロセスの変動がある。
- 計測値は単一セッションの観測であり、統計的な速度保証ではない。
- ブラウザ操作と実LLMを含むチャット全体、および現在の設定で無効な
ControlNetの実GPU生成は未実施。誘導生成・Inpaintのロード順は
スタブを用いた自動テストで確認した。
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/lazy-loading-verification.md | 75 |
1 files changed, 75 insertions, 0 deletions
diff --git a/docs/lazy-loading-verification.md b/docs/lazy-loading-verification.md new file mode 100644 index 0000000..06b82bb --- /dev/null +++ b/docs/lazy-loading-verification.md @@ -0,0 +1,75 @@ +# 画像モデル遅延ロードの検証結果 + +実施日: 2026-10-14。常駐化やクライアントの接続方式は変更せず、モデル初期化のタイミングだけを変更した。 + +## 回帰テスト + +| 検査 | 修正前 | 修正後 | +| --- | --- | --- | +| `python -m pytest -q` | 69 passed | 87 passed | +| `ruff check .` | 成功 | 成功 | +| `pyright` | 0 errors, 0 warnings | 0 errors, 0 warnings | + +既存69件のテストと期待値は変更していない。追加18件で、一覧取得時の推論ライブラリの +import禁止、CLI/stdio経路、全生成方式の初回ロード、ワーカースレッドでの実行、 +同時要求・明示的な同時ロード、無効な入力、ロード失敗後の再試行、ロードログを確認した。 +推論依存ファイルがサンドボックス内で読み取り拒否となったため、実行時は通常の権限を使用した。 + +## 実GPU・stdio経路 + +現在の `data/config.toml` を使用した。checkpoint、外部VAE、2件のLoRA、LCM、6 stepsは変更していない。 +seedは確認用の子プロセス内だけで `2026091201` に固定した。 + +| 計測 | 修正前 | 修正後 | +| --- | --- | --- | +| 一覧取得のみ: 起動~初期化~一覧取得 | 8.233秒 | 0.671秒 | +| 生成セッション: 起動~初期化~一覧取得 | 7.898秒 | 0.650秒 | +| 生成セッション: 初回生成要求~PNG応答 | 17.656秒 | 25.089秒 | +| 生成セッション: 2枚目の生成要求~PNG応答 | 1.211秒 | 1.229秒 | +| 一覧取得のみ: GPU全体の使用量(開始→取得後) | 808→3233 MiB | 682→682 MiB | +| 生成セッション: GPU全体の使用量(開始→終了後) | 806→674 MiB | 682→692 MiB | + +各値は単一セッションの観測値で、統計的な速度保証ではない。初回生成にはCUDA等のwarm-upも含まれる。 +修正後のベースモデルのロード時間は7.812秒。一覧取得時のロードは0回、同じ接続で2枚生成しても +ロード開始・完了はそれぞれ1回で、生成開始後にのみ記録された。 + +最終版の確認スクリプトでも2枚生成して再確認した。一覧取得は0.655秒、初回生成は14.089秒、 +2枚目は1.221秒だった。画素・保存PNGは一致し、ロードは1回、生成プロセスの終了も確認した。 +この再実行では一覧取得前後のGPU全体の使用量は683→683 MiB、終了後は693 MiBだった。 + +Windowsのプロセス別VRAMは `N/A` だったため、個別使用量は測定不能。 +GPU全体の使用量には他プロセスの変動が含まれる。修正前後の一覧取得・生成の計4プロセスは +`tasklist` で終了を確認し、生成プロセスは終了後のGPUプロセス一覧にも残らなかった。 + +## 画像生成の回帰確認 + +修正前後で同じ設定・プロンプト・seedによる2枚ずつの画像を比較した。 + +- すべて512×512のPNGで、修正前後の画素は完全一致した。 +- 画素SHA-256は `5325bca0f3bf757e40ef28dfd4e6e16d0d316a95285f770cef7b55b9d3d92137`。 +- PNGメタデータのキーとseed・size・mode・schedulerの値は一致した。 +- timestamp・elapsed_secondsは実行時刻・ロード時間を反映して変わることを確認した。 +- 修正前後とも返却されたPNGとアプリが保存したPNGがバイト単位で一致した。 + +ControlNetの実GPU生成は現在の設定で無効のため未実施。 +誘導生成・Inpaint・前処理のロード順はスタブを用いた自動テストで確認した。 + +## 通常質問の経路と確認範囲 + +親アプリの `_chat_event_stream` に通常の質問を渡し、実際の設定済みuvコマンドを使った +MCP起動・一覧取得・3ツールの登録を確認した。ロードログは発生せず、GPU全体の使用量は +693→682 MiBだった。他のMCPを起動しないよう対象をこのサーバーに限定し、allowlistは +確認プロセス内だけに設定した。会話の保存は行っていない。 + +LLM応答はスタブ化した。ブラウザ操作と実LLMを含むチャット全体の確認は未実施。 + +## 再実行と成果物 + +```powershell +.venv/Scripts/python.exe script/smoke_stdio.py --config data/config.toml --result data/verification-lazy-load/list.json +.venv/Scripts/python.exe script/smoke_stdio.py --config data/config.toml --result data/verification-lazy-load/generate.json --images 2 +``` + +生の計測JSON・stderr・PNG・比較結果・チャット確認結果は +`data/verification-lazy-load/` に保存した(既存のgitignore対象)。 +初回生成のロード時間と、別プロセスで生成する際の再ロードは仕様として維持している。 |
