| Age | Commit message (Collapse) | Author |
|---|
|
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のロード順は
スタブを用いた自動テストで確認した。
|
|
実モデルを使用し、in-process MCP clientからgenerate_imageを再現可能に比較するbenchmark_generate_image.pyを追加。MCP schemaを変更せず、ベンチマーク内部だけでseedを固定し、2種類の評価シーンを同条件で生成できるようにした。
config、checkpoint、LoRA、VAE、scheduler、steps、CFGに加え、モデルロード時間、生成時間、prompt token数、PyTorch allocatorのallocated/reserved peakをJSONへ記録する。白背景率、外周白率、外周色分散、edge strengthも算出し、生成PNGと計測結果を指定先へ保存する。
CLIP tokenizerの最大長を生成前に検証し、token切り捨てによる比較条件の欠落を防止。READMEへ実行例と、CUDA初回warm-upを含む1枚目ではなく2枚目の定常生成時間を比較に使う注意事項を追加した。
実GPU検証としてRTX 5050、CUDA 13.2環境で18 configをvalidationし、MCP経由で36枚を生成。Ruff、Pyright、pytest（61 passed）、git diff --checkの成功を確認済み。モデル、config、prompt、生成画像、計測JSONを含むdata/配下は.gitignore対象のためコミットには含めない。
|
|
配布パッケージ名、CLIコマンド名、MCPサーバ名、文書中のアプリ名を
全て generate-image-sd15-mcp に統一した。Pythonパッケージ名
(mcp_sd15)とディレクトリ構造は変更せず、import文への影響なし。
変更内容:
- pyproject.toml: name="mcp-sd15" → "generate-image-sd15-mcp"
project.scripts: mcp-sd15 → generate-image-sd15-mcp
- cli.py: argparse prog="mcp-sd15" → "generate-image-sd15-mcp"
- server.py: MCPServer("mcp-sd15") → "generate-image-sd15-mcp"
- README.md: 見出しと起動コマンドを更新
- doc/config.md: アプリ名と起動コマンド例を更新
- doc/mcp.md: 概要のアプリ名を更新
- doc/Design.md: モジュール構成、設定オブジェクト、スクリプト名を更新
- .github/copilot-instructions.md: リポジトリ指示のアプリ名を更新
- script/smoke_streamable_http.py: docstringのアプリ名を更新
- script/smoke_matrix.py: docstringのアプリ名を更新
- uv.lock: パッケージ名を更新
検証:
- ruff format/check、pyright 0 errors、pytest 61 passed
- uv run generate-image-sd15-mcp --version でコマンド名を確認
|
|
IndexErrorを解消。あわせて外部VAEロードの既存バグも修正した。
問題:
kohya形式LoRA（pixelartV3, pixel_f2, pixel sprites等）のロード時に
Diffusers内部でIndexError: list index out of rangeが発生し、サーバが
起動失敗していた。LCM LoRAはtext encoderキーを含まないため成功していた。
原因:
Transformers 5.x系のCLIPTextModel.named_modules()が返すモジュール名
（encoder.layers.0.self_attn.k_proj）と、Diffusersがkohya形式LoRAを
PEFT形式へ変換後のキー（text_model.encoder.layers.0...lora_B.weight）の
間でtext_model.プレフィックスの有無が不一致となり、rank_dictが空になって
get_peft_kwargsでlist(rank_dict.values())[0]がIndexErrorになる。
Transformers 4.x系ではnamed_modules()がtext_model.プレフィックス付きの
モジュール名を返すため、PEFTキーと一致し正常にロードできる。
対応:
transformers>=4.45,<5 に固定。4.x系最新版の4.57.6を採用。
これに伴いdiffusers 0.40.0→0.39.0、huggingface-hub 1.31.0→0.36.2、
tokenizers 0.23.2→0.22.2に変更された。peft 0.20.0は変更なし。
LoDAロード処理のコードは変更せず、標準APIのpipeline.load_lora_weights()
をそのまま使用。モンキーパッチやキー書き換え等の互換性パッチは追加していない。
あわせて外部VAEロードの既存バグも修正:
AutoencoderKL.from_single_fileがネットワークからconfig.jsonを取得
しようとして失敗する問題を、_vae_config_dir()でローカルhuggingface
cache内のvae/config.jsonディレクトリを動的に見つけてconfigパラメータ
に渡すことで解消。
変更内容:
- pyproject.toml: transformers>=4.45 を transformers>=4.45,<5 に変更
- uv.lock: transformers 5.17.0→4.57.6, diffusers 0.40.0→0.39.0,
huggingface-hub 1.31.0→0.36.2, tokenizers 0.23.2→0.22.2
- pipeline_factory.py: _vae_config_dir()メソッド追加、VAEロード時に
configパラメータでローカルconfigディレクトリを指定
- tests/test_pipeline_factory.py: _vae_config_dirをモンキーパッチ、
VAE config引数の検証追加
- script/smoke_matrix.py: 10パターン網羅検証スクリプト追加
(4 checkpoint × VAE × 4種LoRA × scheduler)
検証:
- ruff format/check、pyright 0 errors、pytest 61 passed
- 実GPU・実モデルで10パターン全て成功（10 ok / 0 fail）
- 4種checkpoint単体: 全て成功
- 外部VAE差し替え: 成功
- pixel sprites / pixelartV3 / pixel_f2: 全て成功（IndexError解消）
- LCM LoRA + lcm scheduler: 成功
- animekawa + 外部VAE + pixelartV3 + euler_a: 成功
|
|
MCP SDK 2.xのMCPServer.run(transport="streamable-http")を使い、stdioに
加えてStreamable HTTPトランスポートで起動できるようにする。SSEはMCP仕様で
非推奨のため選択肢から除外し、transport enumはstdioとstreamable-httpの
2種類のみとした。
transportの選択はTOML [server] tableで指定し、CLI引数は追加しない。
仕様の「CLI上書きを行わない」「TOML集約」原則に準拠する。[server]省略時は
stdio（後方互換）、streamable-http時はhost=127.0.0.1 port=8000を既定値とする。
変更内容:
- config.py: ServerConfig dataclass、VALID_TRANSPORTS定数、AppConfig.server
フィールド、load_configの[server]読込・validation追加
- cli.py: main()でconfig.server.transportに応じたrun()引数分岐
- tests/conftest.py: app_config fixtureにserver=ServerConfig()追加
- tests/test_config.py: [server]の正常系・異常系・境界値テスト追加
(省略時stdio既定値、streamable-http読込、sse/http/ws/unknown拒否、
port境界値0/65536/-1/文字列、host空文字拒否)
- doc/config.md: [server]セクション追記、設定項目一覧表更新
- config.example.toml: [server]コメント例追記
- doc/Specifications.md: スコープ表にMCPトランスポート行追加
- doc/Design.md: 責務表と起動フロー更新
- doc/mcp.md: 概要のtransport記載更新
- README.md: streamable-http起動例追記
- script/smoke_streamable_http.py: streamable-http経由の検証スクリプト追加
検証:
- ruff format/check、pyright 0 errors、pytest 50 passed
- 実GPU・実モデルでstreamable-http経由generate_imageの全ルート確認
(HTTP接続→MCP initialize→tools/list→tools/call→PNG生成・返却)
- 生成結果: 335KB PNG、512x512、20 steps、CFG 7.0
|
|
CPU版PyTorchが選択されていた依存設定を修正し、RTX 5050上でStable Diffusion 1.5のMCP generate_imageを実行できる構成へ更新。併せてVAEとLoRAの仕様・実装・テストを明確化した。
CUDA / 依存管理:
- torch 2.14.0+cu132とtorchvision 0.29.0+cu132をruntime依存へ固定
- PyTorch CUDA 13.2のexplicit indexとtool.uv.sourcesをuv設定へ追加
- uv.lockをCUDA wheelに更新し、uv sync後もCPU版へ戻らないよう修正
- RTX 5050の認識、CUDA 13.2 runtime、GPU FP16演算を確認
モデル・オフライン実行:
- model.root配下のhuggingface cacheをDiffusersへ明示的に渡すよう変更
- checkpoint、外部VAE、ControlNetのsingle-file loadをlocal_files_onlyで統一
- SD 1.5 checkpointと公式pipeline構成・tokenizerによるオフラインloadを確認
- data/config.generate-image.tomlにText-to-Image用最小設定を追加
- data/MODELS.mdにモデル出典、容量、SHA-256、cache構成、検証結果を記録
- 4.27GBのcheckpoint、cache、生成画像はGit管理対象外を維持
VAE / LoRA:
- Stable Diffusion pipelineではVAE componentが必須であることを仕様・設計・設定文書に明記
- model.vaeはVAEの有無ではなく外部VAE差し替えの任意設定であることを明確化
- checkpoint内蔵VAEも外部VAEもない場合はpipeline初期化を失敗させる検証を追加
- 複数LoRAを起動時にロードし各weightでset_adaptersする既存動作を文書化
- generate_imageを含む全生成ツールへ設定済みLoRAが共通適用されることを明記
- 外部VAE差し替え、VAE欠落、複数LoRA適用のunit testを追加
動作確認:
- 実backendとin-process MCP Clientを使うsmoke_generate_image.pyを追加
- RTX 5050でSD 1.5、512x512、20 stepsのgenerate_imageを実行
- PNG ImageContent返却とseed、size、mode、timestamp、処理時間metadataを確認
- GPU生成時間18.313秒
- pytest: 32 passed
- Ruff lint/format: passed
- Pyright: 0 errors, 0 warnings
- uv lock check: passed
|
