generate-image-sd15-mcp.git/tests, branch main

fix: 画像生成モデルのロードを初回生成まで遅延する

2026-10-13T17:21:50+00:00

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のロード順はスタブを用いた自動テストで確認した。

ddim timestep_spacingをtrailingに強制するモードを追加

2026-09-13T13:02:44+00:00

sd_embed導入による長文プロンプト・重み付きプロンプト対応

2026-09-12T14:36:33+00:00

SD1.5の77 token制限を回避するため、sd_embedを用いたprompt_embedsベースの入力方式に変更した。あわせてclip_skipとpad_last_blockの設定を追加した。 sd_embedのget_weighted_text_embeddings_sd15()でpositive/negativeのプロンプト埋め込みを同時生成し、pipeline呼び出し時にprompt_embeds/ negative_prompt_embedsを渡す。prompt/negative_promptは同時に渡さない。 LoRAロード後にembedding生成を行うため、text encoder LoRAが反映された状態で埋め込みが作られる。 sd_embedはcommit hash 4a47f71150で固定し、VCS dependencyとして追加。 hatchlingのallow-direct-referencesを有効化。変更内容: - pyproject.toml: sd-embed @ git+...@4a47f71150追加、 allow-direct-references=true - config.py: GenerationConfigにclip_skip=0, pad_last_block=False追加、 load_configで[generation]のclip_skip/pad_last_block読込・validation (clip_skip: 0-12のinteger, pad_last_block: boolean) - model_manager.py: 3つのpipeline呼び出しをprompt/negative_promptから prompt_embeds/negative_prompt_embedsに変更、_embed_prompts()メソッド追加 - tests/test_config.py: clip_skip/pad_last_blockの正常系・異常系テスト追加 - doc/config.md: [generation]セクションにclip_skip/pad_last_block説明追記、設定項目一覧表更新 - config.example.toml: clip_skip/pad_last_blockコメント例追記 - doc/Design.md: GenerationConfigにclip_skip/pad_last_block追記 - README.md: sd_embedの説明追記 - uv.lock: sd_embedおよび依存パッケージ追加検証: - ruff format/check、pyright 0 errors、pytest 67 passed - 実GPU・実モデルで確認: - 短いプロンプト: 生成成功 - 77 token超の長文プロンプト(122 token): 生成成功 - 重み付きプロンプト(word:1.5)((word)): 生成成功 - LoRA(pixelartV3) + sd_embed + 重み付き: 生成成功 - negative promptの重み付き埋め込み: 生成成功

transformersを4.x系に固定し、text encoder付きLoDA読み込み時の

2026-09-12T13:26:13+00:00

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: 成功

base prompt結合機能を追加

2026-09-12T12:19:16+00:00

config.tomlの[prompt]でpositive/negativeのbase promptファイルを指定し、 MCP経由でLLMから渡されたプロンプトと結合してpipelineへ渡す機能を追加する。プロンプトファイルは/prompts/に固定し、TOMLにはファイル名のみ指定する。モデルパスと同じ方針でパストラバーサルを拒否する。結合方式: - positive: base_positive, user_positive の順でカンマ区切り - negative: base_negative\nuser_negative の順で改行区切り - baseが空の場合はuserプロンプトのみ（後方互換） - [prompt]省略時はbase promptなし（後方互換）結合場所はschema.pyのTextToImageRequest.create()に集約し、GuidedImageRequest とInpaintImageRequestは内部でTextToImageRequest.create()を呼ぶため1箇所の変更で3ツールすべてに適用される。MCP Tool入力にはbase promptを公開しない。変更内容: - config.py: PromptConfig dataclass、AppConfig.promptフィールド、 _read_promptヘルパー、load_configの[prompt]読込・validation追加。 positive_file/negative_fileはファイル名のみ受け付け、/prompts/へ解決 - schema.py: _combineヘルパー、TextToImageRequest.create()に base_positive/base_negative引数追加、GuidedImageRequest.create()と InpaintImageRequest.create()から転送 - tools/generate_image.py: service.config.promptからbaseを取りcreate()へ渡す - tools/generate_guided_image.py: 同上 - tools/inpaint_image.py: 同上 - tests/conftest.py: app_config fixtureにprompt=PromptConfig()追加 - tests/test_config.py: [prompt]の正常系・異常系テスト追加 (省略時空、ファイル読込、パストラバーサル拒否、ファイル不存在、positiveのみ) - tests/test_schema.py: 結合ロジックのテスト追加 (base両方、positiveのみ、negativeのみ、base空、guided/inpaint転送) - doc/config.md: §10 [prompt]セクション追記、設定項目一覧表・ディレクトリ構成・全設定例更新、既存セクション番号を§11〜§13へ繰り下げ - config.example.toml: [prompt]コメント例追記 - doc/Specifications.md: モデル構成表にBase prompt行追加、推奨ディレクトリに prompts/追記、設定例更新 - doc/Design.md: 設定オブジェクトにPromptConfig追記、モデルパス解決表に prompts/追加 - doc/mcp.md: §2.1にbase prompt結合の記載追記 - README.md: [prompt]設定例と結合規則の説明追記検証: - ruff format/check、pyright 0 errors、pytest 61 passed - 実GPU・実モデルでstreamable-http経由generate_imageでbase prompt結合を確認 positive='masterpiece, best quality, ..., sharp focus, a small red cube on a white table' negative='low quality, ..., jpeg artifacts\nnoise' base前置・user後置の結合順序が仕様通り機能することをサーバログで検証済み

streamable-httpトランスポート対応を追加

2026-09-12T11:40:07+00:00

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

feat: SD 1.x向けScheduler対応を5種類に整理

2026-09-12T11:12:17+00:00

generation.schedulerの正式対応値をdpmpp_2m_karras、dpmpp_2m_sde_karras、euler_a、ddim、lcmに限定し、既定値をdpmpp_2m_karrasへ変更する。旧dpmpp_2m、eulerおよび未知値は起動時の設定validationで拒否する。 Scheduler生成処理をPipelineFactoryへ集約する。DPM++ 2M系はDPMSolverMultistepSchedulerを共用し、algorithm_type、solver_order=2、use_karras_sigmas=Trueで通常版とSDE版を切り替える。Euler Ancestral、DDIM、LCMは現在のpipeline scheduler configを引き継いで構築する。 LCM-LoRAは既存のmodel.lora設定から通常のLoRAとして読み込み、LCM選択時にもstepsとcfg_scaleを自動調整せずTOML値をそのまま使用する。MCP Tool schemaにはscheduler入力を追加しない。 Specifications.md、Design.md、config.mdおよびconfig.example.tomlのenum、既定値、対応表、設定例を新仕様へ統一する。5 schedulerの変換、DPM++ constructor option、旧値と未知値の拒否、省略時の既定値、MCP schema非公開をテストで検証する。検証: ruff check、ruff format --check、pyright、pytest（39 passed）、インストール済みDiffusersで5 schedulerの実インスタンス構築を確認。

feat: CUDA 13.2でgenerate_imageの実GPU生成に対応

2026-09-12T09:52:14+00:00

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

feat: Stable Diffusion 1.x MCPサーバを実装

2026-09-12T09:04:56+00:00

仕様書・設計書に基づき、ローカルCUDA GPU上のStable Diffusion 1.x互換モデルをMCP経由で利用するサーバを新規実装。実装内容: - generate_image、generate_guided_image、inpaint_imageの3ツールをMCP SDK v2で公開 - TOMLからcheckpoint、VAE、複数LoRAと重み、ControlNet、生成設定を読み込み - モデル種別ごとの固定ディレクトリ解決と起動時の設定・ファイル存在検証を追加 - Depth/MiDaS、OpenPose body/full、ControlNet Inpaintの前処理とパイプライン切替を実装 - FP16/CUDA、1枚固定生成、ControlNetオンデマンドロード、単一GPU直列実行を実装 - Base64 PNG/JPEG入力の形式・サイズ検証と任意のdata URI入力に対応 - seed、サイズ、モード、時刻、処理時間をPNG metadataへ記録 - 任意のローカルPNG保存、生成エラー分類、CUDA OOM後のキャッシュ回復を追加 - --configと--versionを備えたstdio CLIエントリポイントを追加開発・運用: - Python 3.11およびuvによる依存・lock管理を構成 - config.example.tomlとセットアップ・運用手順をREADMEへ追加 - Ruff、Pyright、pytestの設定を追加 - 設定、パス解決、schema、画像検証、サービスルーティング、排他制御、MCP画像返却をテスト検証結果: - pytest: 30 passed - Ruff lint/format: passed - Pyright: 0 errors, 0 warnings - CLI versionおよびMCPクライアント経由のPNG返却を確認 - 実GPU smoke testはCUDA GPUとモデルファイルがないため対象外