サムネイル生成のLCM-LoRA、速度は1.8倍でも「眠っている猫」が起きてしまった
きっかけ：サムネイル生成、実は画質を犠牲にしていないか うちのブログ記事のサムネイル生成では、LCM-LoRA(Latent Consistency Model)を使って6ステップという少ない工程数で高速に画像を作っている。速度を優先した設定なんだけど、これって実際どれくらい速くて、画質はどれくらい犠牲になっているのか、一度もちゃんと見比べたことがなかった。 というわけで、同じベースモデル(Lykon/dreamshaper-8)・同じプロンプト・同じシード値で、①LCM-LoRAあり(6ステップ、現行設定)と②LCM-LoRAなし(通常のDPMSolverMultistepスケジューラ、28ステップ)を実際に生成して比較した。 速度：思ったより差が小さかった LCM-LoRAなし(28ステップ): 8.0秒 LCM-LoRAあり(6ステップ): 4.3秒 速度差: 1.8倍 ステップ数だけ見れば28→6で約4.7倍の削減のはずなのに、実際の速度差は1.8倍にとどまった。これは、モデル読み込みやLoRA適用などの固定オーバーヘッドが、ステップ数を減らしても変わらず一定時間かかるため。ステップ数が少ないほど、この固定コストの割合が相対的に大きくなり、「ステップを減らした分だけ速くなる」わけではないことが分かった。 画質：LCM版は指示を守れていなかった ↑ LCM-LoRAなし(通常設定・28ステップ) ↑ LCM-LoRAあり(現行設定・6ステップ) プロンプトは「窓辺で眠っている猫がいる、居心地の良い和室、温かい午後の光」というもの。 LCM-LoRAなし版は、指示通り猫が眠っている姿勢で描かれ、障子越しの桜の木や山並みまで書き込まれていて、「温かい午後の光」の雰囲気もよく再現できていた。 一方、LCM-LoRAあり版は、猫が眠っておらず起き上がった姿勢になってしまっていて、「眠っている」という指示に従えていなかった。背景の書き込みも簡素で、部屋全体の雰囲気も「温かい午後の光」というよりは薄暗い印象になっていた。 結論 速度向上は1.8倍、ステップ数の削減比(4.7倍)ほどではない — 固定オーバーヘッドの存在を考慮する必要がある LCM-LoRA版は明確に画質・プロンプト忠実度が落ちる — 今回は「眠っている」という重要な指示が守られなかった サムネイル用途としては許容範囲内 — 記事のサムネイルという用途では、多少の細部の簡略化は実用上大きな問題にはならないが、「意図通りの構図か」は目視確認する価値がある 速度と画質のトレードオフは体感より大きい可能性がある — 1.8倍の高速化のために、指示忠実度という無視できない代償を払っている これまで「6ステップで十分速くて便利」と思って使ってきたけど、実際に横並びで比較してみると、思ったより画質面の犠牲が大きいことが分かった。プロンプトの重要な要素(今回で言えば「眠っている」)が守られないケースがあることは、今後サムネイル生成のプロンプト設計で意識しておきたい。