bigASP 🧪 v2.5

⚠️これは通常のSDXLモデルではなく、デフォルトでは動作しません。⚠️

150億のトレーニングサンプルで、1300万枚以上の画像を用いてトレーニングされた非常に実験的なモデルです。基本的にはSDXLアーキテクチャに基づいていますが、フローマッチングを用いて品質とダイナミックレンジを向上させています。

⚠️⚠️⚠️警告⚠️⚠️⚠️

あなたは「ASPラボ」に足を踏み入れました

bigASP v2.5は、一般利用を目的としたモデルではなく、純粋な実験モデルです。

使用は本質的に困難です。

このモデルの利用を続けたい場合は、以下の使用ガイドに従ってください。

使用方法

現在、このモデルはComfyUIでのみ動作します。上記の画像には例となるワークフローが含まれており、それをComfyUIのワークスペースにドロップすることでロードできます。もし動作しない場合は、以下のように手動でワークフローを構築してください：

• 基本的なSDXLワークフローから始め、モデルにModelSamplingSD3ノードを追加します。例：

  • Load Checkpoint → ModelSamplingSD3 → KSampler

• その他の部分は、通常のSDXLワークフローと同じです（ポジティブとネガティブ用の2つのCLIPエンコーダー、空の潜在変数、サンプラー後のVAEデコーダーなど）。

解像度

サポートされる解像度を以下に示します。性能の良い順に大まかに並べています。これらの解像度より低くても高くても、動作する可能性は非常に低いです。

832x1216
1216x832
832x1152
1152x896
896x1152
1344x768
768x1344
1024x1024
1152x832
1280x768
768x1280
896x1088
1344x704
704x1344
704x1472
960x1088
1088x896
1472x704
960x1024
1088x960
1536x640
1024x960
704x1408
1408x704
1600x640
1728x576
1664x576
640x1536
640x1600
576x1664
576x1728

サンプラー設定

まず、通常のSDXL生成とは異なり、**新たなパラメータ「shift」**が存在します。

ShiftはModelSamplingSD3ノードのパラメータであり、ノイズスケジュールを歪ませます。1.0に設定すると何も変わりません。1.0より高く設定すると、サンプラーがスケジュールの高ノイズ領域に長く時間を割くようになります。これにより、サンプラーは画像の構造に更多の努力を傾け、細部にはそれほど注力しなくなります。

このモデルはサンプラーとスケジューラーに対して非常に敏感であり、スケジュールの高ノイズ領域に少しでも長く時間を割くことで、大幅に性能が向上します。これは通常のSDXLとは対照的で、SDXLの多くのスケジュールはむしろその領域に時間を割かないように設計されています。

これまで私が最も効果的だと感じた設定は以下の通りです。自分自身で調整・実験してください。ただし、多くの失敗を覚悟してください。

• Scale=1、Sampler=Euler、Schedule=Beta
• Scale=6、Sampler=Euler、Schedule=Normal
• Scale=3、Sampler=Euler、Schedule=Normal

Euler以外のサンプラーではあまり成功していません。UniPCは動作しますが、一般に性能が劣りました。その他の多くは失敗するか、さらに悪化しました。ただし、私のテストはまだ限られています。他のサンプラーが動作する可能性もありますが、このモデル（変態的モデル）を誤解している可能性があります。

Betaスケジュールが最も汎用的に使えるオプションであり、Scaleパラメータの調整は不要です。Betaスケジュールはノイズスケジュールに「S」字の形状を形成し、前半は通常よりも高ノイズ領域に時間を割き、後半は低ノイズ領域に時間を割きます。これにより、画像構造と細部の品質のバランスが良くなります。

Normalスケジュールは、一般的にScaleが1より大きい値（3～6が最適）である必要があります。6より大きい値ではメリットが見られませんでした。この設定では、サンプラーがほとんど画像の構造に時間を割くため、細部の品質が犠牲になります。

どの設定を使うかは、あなたの好みや生成したい内容により異なります。「画像構造の品質」とは、物体の全体的な形や配置が正しくなるかどうかを指します。構造が正しく形成されていないと、余計な手足や変形した物体などがよく発生します。クローズアップの場合は構造はそれほど重要ではなく、細部に時間を割くよう設定を調整できます。中距離や遠距離の場合は、構造がより重要になります。

CFGとPAG

私の限られたテストでは、CFG値が3.0～6.0の範囲で最も効果的でした。CFGは品質と多様性のトレードオフであり、低いCFG値は多様な画像を生成しますが品質が低く、高いCFG値は逆です。ただし、CFGが2.0以下になると品質が著しく低下し、実用性がなくなります。

PerturbedAttentionGuidanceノードの使用を強く推奨します。このノードはModelSamplingSD3の後に、KSamplerの前に配置してください。このノードにはscaleパラメータがあり、調整可能です。私は通常2.0前後に設定しています。PAGを使用する場合、CFG値を下げるのが一般的です。PAGを有効にしているときは、CFGを2.0～5.0の範囲に保っています。

CFGとPAGの正確な値は、個人の好みや生成したい内容によって変わります。これらに不慣れな場合は、推奨範囲の中央値からスタートし、徐々に上下に調整して、あなたの環境での挙動を理解してください。

PAGは画像の品質と信頼性を大幅に向上させますが、画像をより強調・コントラスト豊かにする傾向があり、目的によっては望ましくない場合があります。多くの要素と同様に、バランスを取ることが重要であり、必要に応じて無効にすることもできます。

ステップ数

28～50？私は大体40前後で動かしていますが、私は変人です。

ネガティブプロンプト

これまで私が見つけた最良のネガティブプロンプトは単に「low quality」です。空のネガティブプロンプトやより複雑なネガティブも動作しますが、「low quality」だけでも生成品質が大きく向上しました。「deformed」や「lowres」などの他の単語は、私にはあまり効果がありませんでした。

ポジティブプロンプト

ここについては、十分にモデルを試しておらず、最適なプロンプティング方法を確定していません。ただし、このモデルは以下のような品質キーワードでトレーニングされています：

• worst quality
• low quality
• normal quality
• high quality
• best quality
• masterpiece quality

これらはトレーニング中にタグ文字列やキャプションに挿入されました。品質キーワードをプロンプトのどこに置いても、モデルは基本的に気にしないでしょうが、先頭に近いほど効果が大きくなります。複数の品質キーワードを含める必要はなく、1つのみで十分です。キーワードに重みを付ける必要もありません。

プロンプトに品質キーワードを含めるのは必須ではありません。任意です。

「masterpiece quality」の使用は推奨しません。このキーワードはモデルが写真ではなくイラストやドローイングを生成しやすくなるためです。私は「high quality」がほとんどの用途に十分であり、プロンプトの始めに「A high quality photograph of」をよく使っています。

このモデルは、JoyCaption Beta Oneとタグ文字列を組み合わせた多様なキャプションスタイルでトレーニングされています。理論的には、どんなプロンプティングスタイルでも使用できます。ただし、私の限られたテストでは、自然言語のキャプションが最も効果的であり、ときどきタグ文字列を末尾に追加して微調整すると良い結果を得られました。お気に入りのチャットボットに書いてもらうか、私のカスタムプロンプトエンハンサー/ライター（https://huggingface.co/spaces/fancyfeast/llama-bigasp-prompt-enhancer）を使用してください。

成熟したテーマをプロンプトする場合は、チャットボットが身体の部位や行動を記述する際に使うような中立的な表現を試してみてください。モデルはスラングを理解するはずです。しかし、これまでの試行では、スラングを使うと生成品質が逆に悪化する傾向がありました。

このモデルは多様な画像でトレーニングされていますので、概念のカバー範囲は概ね良好ですが、Fluxのようなインターネット規模のモデルにはまだ及びません。

ラボ（v2.5の違い）

このモデルはv3の準備のために副次的にトレーニングされた実験モデルです。試してみたいあらゆる奇妙な要素が詰め込まれています。

v2と比較して：

• キャプション - データセットのキャプションは、以前のJoyCaptionではなく、JoyCaption Beta Oneを使用して生成されました。
• より多くのデータ - v2の600万枚から1300万枚に増加。
• アニメ - アニメ/フェッリーなどの画像を大量にデータセットに含めました。
• フローマッチング目的 - SDXLにワイヤーハンマーを突き刺し、フローマッチングをダクトテープで貼り付けました。
• より多くのトレーニング - 4000万サンプルから1億5000万サンプルに増加。
• 固定テキストエンコーダー - 両方のテキストエンコーダーは完全に固定されました。

では、なぜ？

キャプションの変更は、データ準備段階でBeta Oneが完成していたため、単に切り替えただけです。Beta Oneのパフォーマンスと多様性の向上が、このモデルのプロンプト柔軟性を高めるはずだと期待していました。しかし、テキストエンコーダーが固定されているため、実際の影響は不明です。

より多くのデータは、より良いことです。特に、既存の代替テキストが豊富で、概念の多様性を最大限にバランスよく含む画像を大量に追加しました。これは、トレーニング中にモデルがより広範な画像とキャプションスタイルに触れるようにするためでした。

アニメの追加には二つの理由があります。一つは、写実的と非写実的なモデルを分けるのではなく、統合されたモデルにしたいという願望です。GPT-4oのような大規模モデルは両方のモダリティを同等に扱えるため、少なくとも「可能」です。二つ目は、写実的側がアニメ/フェッリー側の概念を吸収したいという意図です。後者ははるかに広範なコンテンツと概念を持っています。一方、写実的データセットは制限が多く、それらでトレーニングされたモデルは創造性を発揮しにくいのです。

フローマッチングは、Fluxのような現代のモデルで使われる目的関数です。高品質な生成をもたらしますが、同時にノイズスケジュールが固定されます。SDXLのノイズスケジュールは壊れており、様々な問題を引き起こします。その中でも最も顕著なのは、構造生成の劣化です。これが、SDXLベースのモデルが手足の重複、溶けた物体、小さい「仲間」を生成しやすい主な原因です。また、SDXLはダイナミックレンジの高い画像、暗い画像、明るい画像の生成も苦手です。フローマッチングへの移行で、これらすべての問題が解決します。

より多くのトレーニングは、より良いことです。v2（およびv1）の最大の問題は、失敗する生成が多かったことです。多くの実験の末、これは主に二つの要因によるものだと判明しました：SDXLの壊れたノイズスケジュール、そして何よりトレーニング不足でした。PonyXLのようなモデルは、v2よりずっと長い時間トレーニングされています。トレーニングサンプルを4000万から1億5000万に増やしたことで、v2.5はPonyXLと同等のトレーニングスケールに達しました。

テキストエンコーダーを固定したのは、実はこのモデルの意図した特徴ではありません。単にトレーニングの不安定性に対処しようとして、結果として固定しただけです。

成功した点と失敗した点

最大の変更はフローマッチングでした。以前から、SDXLをv-predなどの他の目的に変更した試みはありましたが、フローマッチングに変更した例はおそらくありませんでした。しかし…うまくいきました。私はこれを成功と考えています。フローマッチングがSDXLの出力品質にどれだけ貢献したかは、トレーニング量の増加と混同されるため判断が難しいですが、画像のダイナミックレンジの向上は明らかで、私は非常に満足しています。また、前述したように、固定されたノイズスケジュールが、v2.5がv2よりも歪んだ生成を減らす大きな要因であると考えられます。

より多くのトレーニングも、間違いなくモデルの性能向上に寄与しました。v2.5の失敗率は著しく低下しました。

より多くのデータとアニメなどの追加は、モデルの概念と創造性を拡大しているように見えます。私は、芸術的で創造的でありながら、依然として写実的な画像を大幅に広い範囲で生成できるようになりました。

しかし、v2.5は非写実的なコンテンツの生成能力を実質的に得られませんでした。アニメスタイルの生成を試みたことはすべて失敗しました。奇妙なことです。

テキストエンコーダーの固定は、利点と欠点の両方をもたらします。固定することで、元の膨大なトレーニングで得られた知識と堅牢性を維持できます。これは、私のような小規模な実験にとって非常に有用で有益です。

一方で、調整が行われていないため、プロンプトの忠実度が大きく低下します。v2.5は、「汗の粒」を見て「粒の列」を生成してしまうような混乱が頻発します。

つまり、トレードオフです。テキストエンコーダーが固定されているため、v2.5はJoyCaption Beta Oneの改善をあまり享受していない可能性があります。

LORAのトレーニングとマージ

正直、このモデルをマージできるかどうかはわかりません。これは標準のSDXLとは異なる目的でトレーニングされたため、マージするとなにか変なことになるでしょう。しかし、誰かがこのモデルをDMD2とマージしてうまくいったという話もあるそうなので、何とも言えません。

既存のLORAの使用についても同様です：おそらく動作しないでしょうが、誰にも分かりません。

このモデルの異なるトレーニング目的のため、LORAのトレーニングも同様に動作しない可能性が高いです。

私は確かにこれは好きではありませんが、このモデルはあくまで実験用に作られたものであり、LoRAなどのサポートは優先事項ではありませんでした。v3は、既存のツールを備えたモデルを基に作られるか、もしそうしてもカスタムアーキテクチャの道に進まざるを得なくなった場合は、ツールを添えてリリースします。

サポート

このような愚かな実験やJoyCaption、そして（ hopefully）v3を支援したい場合: https://ko-fi.com/fpgaminer