summaryrefslogtreecommitdiff
path: root/docs/lazy-loading-verification.md
blob: 06b82bb9f886f9c052f91d670eb0ec5834101a0d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
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対象)。
初回生成のロード時間と、別プロセスで生成する際の再ロードは仕様として維持している。