| Age | Commit message (Collapse) | Author |
|---|
|
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: 成功
|
|
config.tomlの[prompt]でpositive/negativeのbase promptファイルを指定し、
MCP経由でLLMから渡されたプロンプトと結合してpipelineへ渡す機能を追加する。
プロンプトファイルは<root>/prompts/<file>に固定し、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はファイル名のみ受け付け、<root>/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後置の結合順序が仕様通り機能することをサーバログで検証済み
|
|
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
|
|
リポジトリ全体へ自動適用される.github/copilot-instructions.mdを追加し、仕様書と設計書を正本とする作業手順、変更範囲の確認、文書同期、利用者差分の保護、明示依頼なしのコミット禁止を定義する。
SD 1.x、Python 3.11、uv、CUDA 13.2、FP16、VAE必須、ローカルモデル、LoRA共通適用、固定ControlNet、単一GPUジョブ、限定サイズとschedulerなど、実装時に維持すべきシステム要件を常時コンテキストとして固定する。MCP公開面を小さく保ち、設定をTOMLへ集約する既存方針も明文化する。
server、tools、service、config、model_manager、pipeline_factoryの責務境界を定義し、設定やMCP schemaを変更する際に実装、validation、contract test、関連文書を一組として更新するよう指示する。
Python実装、pytest、文書と設定例に対するパス別instructionsを追加する。GPU不要テストの分離、設定enumと異常系、MCP非公開項目、pipeline constructor option、Service routingとエラーsanitizeなど、領域ごとの確認事項を固定する。
設計から実装、テスト、文書同期まで担当するsd15-maintainerカスタムエージェントを追加し、全ツール利用、手動選択、自動推論の両方を有効化する。Ruff format/check、Pyright、pytest、git diff/statusを完了ゲートとして必須化し、GPU smoke test未実施時は自動テストと区別して報告させる。
検証: ruff check、ruff format --check、pyright、pytest（39 passed）、git diff --checkを実行済み。data/配下は引き続きGit管理対象外。
|
|
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の実インスタンス構築を確認。
|
|
|
|
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
|
|
|
|
現行実装を利用者が正確に設定・呼び出せるよう、MCP公開スキーマとconfigファイルの詳細リファレンスを追加。
MCPツール仕様:
- generate_image、generate_guided_image、inpaint_imageの用途と入力項目を整理
- MCP SDKが生成する3ツールのJSON Schemaを掲載
- positive/negative promptのvalidationとsize列挙値・解像度を明記
- PNG/JPEGのBase64およびdata URI入力形式、文字数・pixel数上限を記載
- Depth、OpenPose、OpenPose FullのControlNet対応関係を説明
- Inpaint maskの白黒規約と50%閾値を明記
- ImageContentによるPNG返却と埋め込みmetadataを説明
- 単一GPU直列実行、入力・設定・推論・CUDA OOM・保存エラーを整理
設定ファイル仕様:
- model、LoRA、generation、ControlNet、outputの全設定キーを一覧化
- 各項目の型、必須条件、既定値、数値範囲、許可値を記載
- checkpoint、VAE、LoRA、ControlNetの固定ディレクトリ解決規則を説明
- 相対パスの基準とモデル項目で任意パスを禁止する制約を明記
- schedulerと画像サイズの対応、ControlNetごとの利用方法を整理
- annotator重みのローカルキャッシュおよびオフラインロード要件を記載
- 最小構成と全機能構成のTOML例を追加
- 起動時validation条件と未定義keyの扱いを明記
|
|
仕様書・設計書に基づき、ローカル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とモデルファイルがないため対象外
|
