NovelAI 5ch Wiki

広義では、HypernetworkやLoraで作成したファイルなども含まれるが、
ここではいわゆるCheckpointの話をする。
2025年4月時点でSDXLが主流だが、次世代モデルはSD3.5 Mediumが定番になるかも

SD1.5: https://huggingface.co/stable-diffusion-v1-5/stabl...

• U-Netアーキテクチャ
• 860M(8.6億)パラメータ
• 基礎解像度は512x512
• そのまま使える。
• 軽量だが低性能
• 文章は全く生成できない

SD2.1: https://huggingface.co/stabilityai/stable-diffusio...

• U-Netアーキテクチャ
• 865M(8.65億)パラメータ
• 基礎解像度は768x768
• 文章は全く生成できない
• 使うためには同名のyamlファイルを設置する必要がある。
• 大抵はモデルの配布元が配っている。
  • 無い場合は SD2.xのyamlを使ってみるとか。

SDXL Base 1.0: https://huggingface.co/stabilityai/stable-diffusio...

• U-Netアーキテクチャ
• 2.6B(26億)パラメータ
• BaseとRefinerの二種類が存在する
• 基礎解像度の1024x1024への変更とVAEの改良によりディティールが改善
• そのまま使える。
• 文章を正しく生成できない

https://huggingface.co/stabilityai/stable-diffusio...

• DiTアーキテクチャ
• Medium(2.5B)のみ
• 基礎解像度は1024x1024
• VAEの改良によりディティールが大幅改善
• (DiTモデル全般に言えることだが)破綻が少なく、線を真っすぐ引ける。
• 表現規制がきつく解剖がおかしくなる欠陥あり
• 文章を正しく生成できる

Large: https://huggingface.co/stabilityai/stable-diffusio...
Medium: https://huggingface.co/stabilityai/stable-diffusio...

• DiTアーキテクチャ
• Large(8.1B)とMedium(2.6B)の二種類がある
• 基礎解像度は1024x1024
• MediumはT5を除けばSDXLと同程度のメモリ使用量だが、計算はSDXLの二倍遅い。Largeはメモリ使用量、計算量ともに非常に多い。
• 使うには、モデル本体に加えてCLIP L/Gが必要。T5XXLは任意
• 規制の緩和とSD3.0の問題を解消
• 文章を正しく生成できる
• FLUX.1より美的スコアが低い
• Fine-tuningがしやすい(公式がFTのチュートリアルを出している)
  • 実際にはFine-Tuningの難易度が高いとか

dev: https://huggingface.co/black-forest-labs/FLUX.1-de...
schnell: https://huggingface.co/black-forest-labs/FLUX.1-sc...

• DiTアーキテクチャ
• DevとSchnellの二種類がある
• 使うには、モデル本体に加えてCLIP LとT5XXLが必要
• 文章を正しく生成できる
• 蒸留モデル(Fine-tuningが困難らしい)
• オープンなモデルの中では最大級のパラメータ数(12B)。
  • それゆえにSD3.5Lを超える重さ

https://huggingface.co/fal/AuraFlow

• DiTアーキテクチャ
• 現在開発中
• 開発中のものが公開されているが最近更新なし
• 文章を正しく生成できる

https://huggingface.co/Efficient-Large-Model/Sana_...

• DiTアーキテクチャ
• 軽量なことが売り
• 使えるUIがほとんどない(ComfyUIなら使えるがカスタムノードが必要)
• 文章を正しく生成できる?
• 商用利用禁止(研究で開発したものを公開しただけ?)

• マルチモーダル(画像の理解と生成をする)
• 1Bと7Bの二種類ある
  • 1BはSD1と同程度の品質
  • 7BもSD3.5 Medium未満な感じ
• 解像度は384x384のみ
  • その割には生成がかなり遅い

※間違っている可能性あり。間違っていたら修正してください。

ノイズ予測アルゴリズムの種類。
v-predictionだからといって劇的に性能が上がるわけではない。わかりやすい変化はZero Terminal SNRを併用することで色の精度が上がる程度。一方で構図の不安定化の原因となる(NoobAI-XL特有の可能性が高い)。
なお、計算式の違いで推論時に本来の予測方法とは別のものに変えても正しく動作しない(学習時のpredictionタイプに合わせる)。

SD1とSDXLのデフォルト
画像のノイズ部分を予測する。
SNR=0(純粋なノイズ)では機能しない。そのためSNR=0になるよう修正するZero Terminal SNRは使用できない。
全体が明るい/暗い/原色が強い状況でグレー寄りになるため、単色背景やシルエットなどの表現が苦手。これはNoise offsetやMultires noiseで緩和可

SD2と一部のSDXLモデル(NovelAI Diffusion V3、NoobAI-XL)が使用
ノイズ除去前と除去後の差分を予測する。
SNR=0(純粋なノイズ)でも機能する
Zero Terminal SNRを併用することで全体が明るい、暗い、または高コントラストの状況でグレー寄りになる問題を解消できる。単色背景やシルエットなどの表現が改善する。
ほかにも安定性が改善するらしい

SNR=0であるべき状況(完全なノイズ)で0にならない(ノイズの中にわずかに元画像が残る)欠陥を修正するもの。
全体が明るい、暗い、または高コントラストの状況でグレー寄りになる問題を解消できる。単色背景やシルエットなどの表現が改善する。
低めのGuidance Scaleで運用できる(大体5以下)、というか低めじゃないと彩度が高すぎる。
欠点として、彩度やコントラストが極端に高くなったり構図の破綻が増加したりする(NoobAI-XL特有の現象の可能性が高い)。

v-predictionは高速化する技術ではない。低ステップ動作を謳うcheckpointは高速化LoRAをマージしている。
v-predictionそのものは明暗に強くする効果はない。それはZero Terminal SNRの効果。
VはVelocityの頭文字でありν(ニュー)ではない。

2024年11月27日時点の情報です。

webuiのディレクトリ直下で次のコマンドを実行する。

git checkout -b dev origin/dev

あるいは、Github DesktopでFile->Add local repositoryで1111のフォルダを選択してリポジトリを追加した後、Current branchでorigin/devを選択する。
You have changed...と聞かれたらBring my changesを選択してswitch branchを押す。
あとはいつも通りwebuiを使用する。

最新版にアプデする。

次のリンクからsd_xl_v.yamlをwebui/models/Stable-diffusionにDLする。
https://github.com/AUTOMATIC1111/stable-diffusion-...
DLしたyamlファイルを使用するcheckpointと同じ名称に変更する。

必要に応じて、Settings>Sampler parametersにあるNoise schedule for sampling(sd_noise_schedule)をZero Terminal SNRにする。

inpaint.ckptは普通のcheckpointとは違うらしい。

Model hashとsha256の対応表はここ

• Model hash(shorthash)はファイルの一部のみを対象とするため衝突が頻発している
• 2023-01-15の更新でとうとうModel hashが10桁の完全なsha256に更新された
  • 新旧の見分け方はたぶん桁数だけ
  • VAEとHypernetworkに対応していないのは実用上(まだ)問題が出ていないからだと思われる
• 完全なファイルのsha256を取ることで衝突回避は可能
  • https://github.com/aka7774/sd_filer
  • https://github.com/aka7774/sd_infotext_ex
  • https://github.com/aka7774/sd_infotexts

拡張子で判別する。

• checkpointの略。
• チクポチではない。が、チクポチが出るかどうかはこいつ次第。
• ロード時にPythonのコードを実行できるため安全とは言い切れない
  • まれにウィルスソフトが誤検知を起こして騒ぎになっていたりする
• 狭義のモデルではないファイル(VAEとか)にもこの拡張子が使われることがあるので注意

• Hugging Face提唱の形式
• ロード時にPythonのコードを実行できないので安全
• 読み込みも速くなる(はず)
• NMKDでは対応していない

あくまで数値の精度であって、見た目の綺麗さや絵の細かさに直結するわけではない。

• floating pointの略。A1111系でfullとかいう言葉が出てきたら大抵これのこと。コンピュータの世界ではfloatと呼ぶ場合はこれ。
• 1ビットの符号と8ビットの指数部と23ビットの仮数部
• 現行のハードウェアはすべて対応
• 高精度だが計算量が多い
• 生成AIでは重い割にfp16とあまりかわらない

• 生成AIで主流の精度
• floating pointの略。halfとかいう言葉が出てきたら大抵これのこと。
• 1ビットの符号と5ビットの指数部と10ビットの仮数部
• 処理が速い
• 容量が半分で済む
• IntelとNVIDIAのGPUで対応している(AMDはRDNA3以降で対応？)
• ダイナミックレンジが狭いためオーバーフローによるNaN演算を起こしやすい
• Torch2.6以降であればCPUでも動作する

• 1ビットの符号と8ビットの指数部と7ビットの仮数部
• fp32と指数部が一緒になる（ダイナミックレンジが広い代わりに仮数部が減ってるので小数点以下の表現力はfp16より少し落ちる）
• IntelとNVIDIAのGPUで対応している(AMDはRDNA3以降で対応？)
• fp16よりNaN演算を起こしづらい

• 1ビットの符号と4ビットの指数部と3ビットの仮数部(ほかにもある)
• fp16の半分のメモリ使用量
• だが精度も落ちる
• Torchが自動でキャストするので非対応のGPUでも動作する。
• NVIDIAのRTX40以降であればそのまま動いて速くなる(TensorRTが必要?)
  • しかしほとんどのソフトがfp8演算に非対応でfp16にアップキャストするので若干遅くなる。

• 量子化をすることで精度低下を抑える？

• NVIDIAのBlackwellアーキテクチャで利用可能
  • TensorRTが必要？
• fp8の半分、fp16の1/4の計算量
• 精度も低い？

• 数が少ないので横着せずにドロップダウンから選択したほうがいい
  • Quicksetting listにsd_vaeを追加する
• Checkpointに内蔵されているものを上書きする

モデルファイルを得られる方法

• Full Fine-tuning
• DreamboothやLoRAのマージ
• checkpoint同士のマージ

• Checkpoint Merger
• 層別マージ

• HuggingFace Modelsがおすすめ

• 学習・推論共にfp16, pruned, safetensorsでよい。
• ファイル名には日本語やスペースが無いほうがトラブルが減るかも。

• https://github.com/arenatemp/stable-diffusion-webu...
  • モデルのpruneや変換ができる
  • 更新停止。一部のVAE焼き込み済みのcheckpointを読み込めない。