RouWei-Gemma
https://huggingface.co/Minthy/RouWei-GemmaMinthy/RouWei-Gemma
https://civitai.com/models/1782437/rouwei-gemma?modelVersionId=2017254civitai
https://github.com/NeuroSenko/ComfyUI_LLM_SDXL_Adapter動かすためにはカスタムノードとGemma 3-1b-itモデルが必要
https://civitai.com/models/1782437?modelVersionId=23471152025/10/26 v0.2
v*_t5gemma2b_33k7版はt5gemma-2bエンコーダーを使用するらしい
v*_g3-1b_51k版も引き続き存在していて、それぞれ得手不得手があるようだ
導入方法も上記ページに詳しく書いてある
https://gyazo.com/3659451b3bac29883d41911e7171bae5
上記はv*_g3-1b_51k版モデルのワークフロー付き画像(公式のサンプル)
https://gyazo.com/ec7ea3197af421ede0bac570ac3f7f40
こちらが(2025/10/28現在)新しい(v*_t5gemma2b_33k7版向け)workflow
https://www.reddit.com/r/StableDiffusion/comments/1m2k0lw/gemma_as_sdxl_text_encoder/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button情報ソース
https://www.reddit.com/r/StableDiffusion/comments/1m2k0lw/comment/n3rqjb7/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_buttonllmを使った副産物として英語以外でも生成できるらしい
日本語はちょっと通じなかった(選んだキーワードがよくなかった可能性はある)
皆さん、これは誰も話したことのないクールなプロジェクトです
RouWei-Gemmaと呼ばれるこのアダプタは、SDXLのCLIPテキストエンコーダをGemma-3に置き換えるものです。SDXLエンコーダのドロップインアップグレードとしてお考えください（RouWei 0.8用に構築されていますが、他のSDXLチェックポイントでもお試しいただけます）。
現時点でできること: • booru スタイルのタグと自由形式の言語を、最大 512 トークンまで、奇妙な分割なしで均等に処理します。 • 複数の命令が互いに「にじみ出る」のを防ぎ、複数の文字やネストされたシーンを鮮明に保ちます。
まだ問題が発生する箇所:
1. 非常に複雑なプロンプトが混乱を招く
2. 珍しい文字やスタイルが誤認識されることがある
3. アーティストスタイルのタグが他の指示を上書きすることがある
4. プロンプトの重み付けや括弧による強調がまだサポートされていない
5. テキストキャプションを生成しない
HuggingFace.icon側のReadmeより
まず第一に、現状ではこれは実際に機能するというよりは概念実証に近いものです。トレーニング予算を考えると、実際に機能すること自体が奇跡です。
とのことなので動いてるのが不思議なレベルらしい。
初期バージョンなど、v*_g3-1b_51k版はGemma 3のモデル(google/gemma-3-1b-it)が別途必要
v*_t5gemma2b_33k7版はt5gemma-2bエンコーダーが必要
RouWeiモデル向けに調整されているので他のSDXL 1.0系モデルでの動作は不明(多分動くと思うが断言できない)らしい
一応他のモデルでも動いてはいる(下記の参照画像は別のモデルを使っている)
(v*_g3-1b_51k版)ひとまず動作報告的な参考例として「髪を頭の上で結ぼうとしてる青髪の女の子」的なプロンプトを
自然言語+RouWei-Gemma
https://gyazo.com/9b3989dc050ed78f9f044ea83ed6ad52
英語自然言語で通常(モデル内蔵)TextEncoder
https://gyazo.com/9e12dc0abff8776d82f827cb3000eef0
となるので自然言語指示だと指示への追従性が大きく上がりそう。
ワークフローや解像度、乱数など各種条件まで揃えてないのであくまで参考レベルの出力として、ではあるが…
📦️タグベースだとそこまで大きな差はでなかった(どちらも概ねは似た感じになった)morisoba65536.icon
v*_t5gemma2b_33k7版(t5gemma-2b版v2)でも動作確認。かき分け能力は結構高そう(とはいえ限度はある感じ)
試した範囲では「Clip以上、ネイティブにLLM TextEncoderを使うモデル未満」と言った追従性に感じる。morisoba65536.icon
SDXLのエコシステムでこれだけの追従性が得られるのは十二分に利点だが、Lumina-Image 2.0(Neta Lumina)等には追従性で劣るといった感じ。
同一プロンプト(少しマーキングを入れた自然言語)での比較
ざっくり内容は「ピンクゴスロリ、ピンクミドルヘアの緑目の少女と銀髪ロング、紫目、タイトスカートで背が高い少女」をかき分けさせる(詳細は画像についてるWorkflowを参照)
一枚目が通常のTextencoder、二枚目がt5gemma-2b版v2(どちらもかなりのチェリーピック)
https://scrapbox.io/files/6901f72079c2a8af453e1008.webphttps://scrapbox.io/files/6901f72212e902d939dd4e4e.webp
1枚目のほうは本当に奇跡の一枚くらいにかき分けできたのだがどうしても色味がや大まかな形はちょっと混ざる
CLIPでは大抵は二人とも同じ服になってしまう。(上記はほんとに稀な出力)
t5gemma-2b版はかなりモデルとの相性がでるが服装は50～70%くらいの確立ではかき分けできる。
ただ、なぜか髪の長さと目の色はCLIP以上に安定しない。目の色の書き分けはかなりモデル依存が強い、髪の長さは調べた範囲ではどのモデルでも片方(長い方)に引っ張られやすい
髪は私のプロンプト指定がミスってる可能性が出てきた…(たまたまCLIPのほうが出るだけという可能性)morisoba65536.icon
プロンプトを変えたら多少マシにはなったが、やはりネイティブにT5以上のTextEncoderを採用してるモデルには一段劣る感じ(ガチャの試行回数は必要、指定すべき要素が増えすぎると厳しいかも)
女性二人の服装と髪の色・髪の長さ・目の色違いという割とモデルいじめな混ざりやすい要素をたっぷり指定。
どうも拡散モデルは「近い属性の(上記では女性二人)パターン違い(服装や髪型)が混在する」画像が苦手らしい
モデルとの相性はものすごく出るが、相性の良いモデルなら比較的目の色と髪の長さ以外はそれなりにいい確率でかき分けてくれる。
髪の長さと目の色は割と混ざる…
相性が悪いモデルだと色が飛んだりして絵としても破綻しがち
2025/11/07
https://note.com/gentle_murre488/n/nc0ae247a4912?sub_rt=share_bllmのエンコードした結果と元々のCLIPのエンコード結果を混ぜることでモデルとの相性が激しい問題に対応しようとしてるWorkflow、試せるときに試すmorisoba65536.icon
上記ノードがv*_g3-1b_51k版(v0.1以前)のGemmaモデルを使ったノードだったのでv*_t5gemma2b_33k7版に対応したworkflowを作った
https://gyazo.com/787b57f47801d053973ddb142519f72e
RouWei-Gemma_t5gemma-2b_and_CLIP.json
もともと相性の良いほうのモデル(1枚目)で安定しづらかった髪の長さが比較的通りやすくなった、相性があまりよくなかったモデルでも確認したしたかったが、そもそも画像が荒れるレベルの相性の悪さだったモデルが何だったか、保存してなくていくえ不明になった…(わからないので検証できず)morisoba65536.icon
https://scrapbox.io/files/690de45694e7c00854923d1d.webp