3.9 KiB
LoRAロード最適化およびIssue #44解決 解説書
本ドキュメントでは、非対応LoRAロード時のフリーズ問題（Issue #44）の解決策と、LoRA読み込み処理の高速化のために実施した修正内容について解説します。
1. 修正の背景：Issue #44 について
SD1.5用やLoKR形式など、本モデル（Qwen2-VL系）がサポートしていないLoRAファイルを読み込んだ際、ComfyUIのコンソールが長時間フリーズする問題が報告されました。
原因
非対応LoRAには数千個の互換性のない「キー」が含まれています。以前の仕様では、これら全てのキーに対して「不一致（UNMATCHED）」というデバッグログを出力しようとしていました。この数千行にわたるログ出力の負荷が原因で、UIがフリーズしていました。
2. 実装された最適化内容
A. 重複読み込みの排除（ロードの高速化）
これまで、デバッグログの出力用と実際のモデル適用用の2回にわたってLoRAファイルを読み込んでいました。 修正後: 最初に読み込んだLoRAデータをメモリにキャッシュし、適用時に再利用するようにしました。これによりディスク読み込み時間が大幅に短縮されました。
B. 条件付きログ出力（フリーズの完全解消）
非対応形式のLoRAを検出した場合、詳細なキーマッピングの解析ループそのものをスキップするようにしました。 修正後: 解析の前にフォーマットを確認し、標準的なキーが含まれていない場合は簡潔な警告のみを出力します。これにより、非対応LoRA読み込み時の待ち時間はほぼゼロになりました。
C. 無駄なリトライ処理の抑制（重複ログの防止）
非対応LoRAを読み込んだ際、適用されるレイヤーが0件になるため、システムが「エラー」と誤認して自動的に再試行（リトライ）を行う仕様になっていました。 修正後:
compose_loras_v2が成功か失敗か（対応形式か否か）を返すように変更し、型ヒントおよびドキュメント文字列（Docstring）もboolを返すように修正しました。- 上位の処理（
qwenimage.pyおよびzimageturbo.py）にてその戻り値を判定し、非対応形式の場合は無意味なリトライをスキップさせるようにしました。これにより、いずれのモデルでもログが2回出力される現象を防いでいます。
3. 手動によるログ出力の制御（可逆性）
「非対応形式であっても詳細な解析ログを見たい」という場合は、コード内の1箇所を書き換えるだけで元の動作に戻せます。
対象ファイル: nunchaku_code/lora_qwen.py
書き換え箇所: 以下のコメントがある行を探してください。
# [USER REQUEST] To restore full logs for unsupported formats, change the condition below to "if True:".
この直後の if _first_detection["has_standard"]: を if True: に書き換えることで、制限が解除されます。
4. 特記事項：LoKR形式への対応について
LoKR（LyCORIS）形式などの非対応LoRAについては、内部構造の解析とマッピングテストを詳細に行いましたが、現在のモデル構造と根本的に互換性がないことが判明しました。 無理に適用しようとすると正常な画像生成ができなくなる（ノイズ化する）ため、現時点では「フリーズさせずにスキップする」ことを最善の策として実装しています。
本修正により、誤って非対応LoRAを読み込んだ際のリスクが解消され、快適な環境でLoRAを使用できるようになりました。