Black Forest Labsが公開したFLUX.2 Small Decoderについて、Redditで使い道や互換性を巡る議論が広がっている。
FLUX.2 Small Decoderの話題の概要
今回話題になったのは、Black Forest Labsが公開したFLUX.2向けの軽量デコーダーである。
Hugging Face上では標準デコーダーの置き換え候補として案内されており、投稿では高速化とVRAM削減が注目されていた。
一方で、海外ユーザーの関心は単純な速度差だけではなく、TAEF2との比較やComfyUIでの扱いやすさにも向いていた。
FLUX.2 Small Decoderを巡るやり取り
TAEF2と比べてどうなのか
TAEF2と比べてどうなんだろう。
あっちはまだComfyUIと完全互換じゃないはずだよね。
最初に目立ったのは、既存の軽量系デコーダーであるTAEF2と比べて優位性があるのか、という反応である。
これは新しいVAEだけど、TAEF2は厳密にはVAEではなく、VAEから蒸留したオートエンコーダーなんだ。
実用上はTAEF2でも画質差はほとんど感じないし、この小型VAEでも結局TAEF2よりかなり遅い気がする。
TAEF2のほうがサイズは10分の1だよ。
PRを入れればComfyUIでも使える。
かなり小さいし、速い以外の違いはほぼ感じない。
この流れでは、新モデルの意義を認めつつも、既に軽量環境を組んでいるユーザーほど慎重な見方をしていたのが印象的である。
ComfyUIでどう扱えばいいのか
生成中のライブプレビュー用として使えるのかな。
使うならvae_approxフォルダに入れればいいのか、それとも別の手順があるのか知りたい。
ComfyUIユーザーからは、理論よりもまず実運用でどこに置いてどう使うのか、という実務的な疑問が多く出ていた。
いま使っているComfyUI標準のFlux.2プレビューはかなり荒いんだ。
Flux.1 Devのほうが生成途中の見え方はずっと分かりやすい。
単なるベンチマークの話ではなく、プレビュー品質の改善まで期待している声があった点も興味深い。
3つのファイルの違いが分かりにくい
22ミリ秒速いって、1枚あたりの話なのかな。
ファイルが3つあるけど、ComfyUIではどれをどのFlux.2モデルに使えばいいんだろう。
公開物の構成が直感的ではないため、速度向上より先にファイルの役割を知りたいという反応も多かった。
小さいほうはデコーダー専用だから、latentから画像に戻す処理にしか使えないよ。
VAEは最大のボトルネックではないけど、改善があるならそれはそれで助かる。
派手な性能革命というより、既存ワークフローの細かい待ち時間を減らす改善として受け止める声が近そうである。
FLUX.2 Small Decoderへの見解まとめ
今回の反応を見る限り、FLUX.2 Small Decoderは歓迎されつつも、決定版とまでは見られていないようである。
特にTAEF2を既に使っている層は、速度だけで乗り換える理由が十分かを慎重に見ていた。
一方で、ComfyUIでの導入手順や各ファイルの役割が明確になれば、軽量な選択肢として試すユーザーはさらに増えそうである。
参考リンク：
