NovelAI 5ch Wiki

広義では、HypernetworkやLoraで作成したファイルなども含まれるが、ここではいわゆるCheckpointの話をする。
2026年1月時点で依然としてSDXLが主流。次世代DiTアニメモデルは品質と負荷のバランスが取れたAnimaが有望？

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

• U-Netアーキテクチャ
• 860M(8.6億)パラメータ
• 解像度は512x512のみ
• 超軽量かつとても古いため低性能
• 欠陥のあるVAE(アーティファクトが発生したり特殊なノイズに弱かったりする)
• 文章は全く生成できない
• Text EncoderはCLIP-L
  • プロンプトの応答性がとても低い

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

• U-Netアーキテクチャ
• 865M(8.65億)パラメータ
• 解像度は768x768
• SD1と大差無し
• 使うためにはconfigファイル(yaml)を設置する必要がある。
• 大抵はモデルの配布元が配っている。
  • 無い場合は SD2.xのyamlを使ってみるとか。

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

• U-Netアーキテクチャ
• 2.6B(26億)パラメータ(3.5Bともされるが多分それはTE込みの数値)
• BaseとRefinerの二種類が存在する(通常はBaseのみでok)
• 基礎解像度の1024x1024への変更とVAEの改良によりディティールが改善
  • 特殊なノイズの影響を受けにくい。でも細部は相変わらず溶ける
• Text EncoderはCLIP-LとCLIP-G
  • 低性能で具体的な命令を無視する

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

• MMDiT
• Medium(2.5B)のみ
• 解像度は1024x1024
• 16チャネルVAE
  • ディティールが大きく改善
• Text EncoderはCLIP L/Gに加えてT5XXL(任意)
  • 位置や文字の描写などの具体的な命令もOK
• 表現規制がきつく解剖がおかしくなる欠陥あり
• 実質NSFW禁止
• fp16で動く
• パラメータ効率が低い

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

• 基本的にSD3.0と同じ
• MMDiT
• Large(8.1B)とMedium(2.6B)の二種類がある
• MediumはT5を除けばSDXLと同程度のメモリ使用量だが、計算はSDXLの二倍遅い。Largeはメモリ使用量、計算量ともに非常に多い。
• 規制の緩和とSD3.0の問題を解消
  • でもライセンスにより実質NSFW禁止
• パラメータ効率が低い
• Fine-tuningが困難
• fp16で動く

オープンソースのモデルのみ掲載する。

dev: https://huggingface.co/black-forest-labs/FLUX.2-de...

• APIのみのpro,flexとオープンなdev,kleinの四種類ある
• MMDiT
• devのパラメータ数は32Bで素の状態ではほとんどの一般消費者向けハードウェアで動作困難
  • 量子化やBlock Swapを使ってもなおメモリ消費が非常に多い
• ベンチマークスコアは高い(なおメモリ消費量)

https://huggingface.co/Qwen/Qwen-Image

• MMDiT
• パラメータ数は20Bですさまじいメモリ使用量と計算量
  • ハイエンドGPUでもBlock Swapを使わないときつい
• VAEのデコーダーはデュアル
• TEはQwen-VL
  • 位置や文字の描写などの具体的な命令もOK
  • 漢字を含む文字の描写が得意
• Apache 2.0 ライセンス

https://huggingface.co/Tongyi-MAI/Z-Image-Turbo

• MMDiT
• パラメータ数6Bで重い
• パラメータ数のわりに高品質
• TEはパラメータ効率のいいQwen3-4B
  • 位置や文字の描写などの具体的な命令もOKで応答性が高い
• TurboはDMDRで蒸留した収束が速いモデル
  • ただし蒸留+強化学習の影響で多様性が低い
• Apache 2.0ライセンス
• Fine-Tuningが困難な可能性あり

https://huggingface.co/Alpha-VLLM/Lumina-Image-2.0

• MMDiT
• パラメータ数はSDXLより小さい2BでSDXL程度のメモリ使用量
  • パラメータ数相応の品質だが計算がかなり遅い
• Text EncoderにはGemma 2 2Bを採用
  • 位置や文字の描写などの具体的な命令もOK(大型モデルほど得意ではない)
• SDXLよりは良いが大型モデルのZ-Image(6B)や小型で比較的高性能なCosmos-Predict(2B)には及ぼない
• Apache 2.0ライセンス
• 16チャネルVAE

https://huggingface.co/duongve/NetaYume-Lumina-Ima...

• Lumina-Image 2ベースのアニメモデル
• 品質はいまいち
• より高速・高品質なAnimaが出てしまったので今後の進展はなさそう

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

ノイズ予測アルゴリズムの種類。
v-predictionだからといって劇的に性能が上がるわけではない。わかりやすい変化はZero Terminal SNRを併用することで色の精度が上がる程度。一方で構図の不安定化の原因となる。
なお、計算式の違いで推論時に本来の予測方法とは別のものに変えても正しく動作しない(学習時のpredictionタイプに合わせる)。
SD3以降のほとんどのモデルはepsilonの色精度の低さとvの不安定性を解消したRectified Flowを使用する。

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を併用することで全体が明るい、暗い、または高コントラストの状況でグレー寄りになる問題を解消できる。単色背景やシルエットなどの表現が改善する。
これは実質Zero Terminal SNRのための技術であり、それがなければepsilonと変わらずv-predの利点もなくなる。

学習時、SNR=0(完全なノイズ)であるべき状況で0にならない(ノイズの中にわずかに元画像が残る)欠陥を修正するもの。
全体が明るい、暗い、または高コントラストの状況でグレー寄りになる問題を解消できる。単色背景やシルエットなどの表現が改善する。
低めのGuidance Scaleで運用できる(5以下)。言い換えれば低めでないと彩度が過度に高くなる。
欠点として、彩度やコントラストが極端に高くなったり構図の破綻が増加したりする。
また、LoRA学習においては不安定性が増大する(特に画風LoRA学習で相性が悪いと再現できずに品質が著しく低下する)。

ZTSNR有効のv-predictionモデルとepsilonモデルをマージするとZTSNRの効果が減少または消失し、「なんちゃってv-pred」になりやすいため注意。

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とは違うらしい。

拡張子で判別する。

• Hugging Face提唱の形式
• ロード時にPythonのコードを実行できないので安全

• 2023年まで主流だった古い形式
• checkpointの略。
• ロード時にPythonのコードを実行できるため安全とは言い切れない
  • まれにウィルスソフトが誤検知を起こして騒ぎになっていたりする
• 狭義のモデルではないファイル(VAEとか)にもこの拡張子が使われることがあるので注意

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

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

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

• 1ビットの符号と8ビットの指数部と7ビットの仮数部
• 処理が速い
• 容量がfp32の半分で済む
• fp32と指数部が一緒になる（ダイナミックレンジが広い代わりに仮数部が減ってるので小数点以下の表現力はfp16より少し落ちる）
• IntelとNVIDIA(Ampere以降)のGPUで対応している(AMDはRDNA3以降で対応？)
• DiTモデルで主流のフォーマット

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

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

• fp8の半分、fp16の1/4の計算量
• 精度が低い
  • 4ビット量子化のほうがマシだとか

• NVIDIA専用のfp4フォーマット
• NVIDIAのBlackwellアーキテクチャで利用可能

• 数が少ないので横着せずにドロップダウンから選択したほうがいい
  • A1111であればQuicksetting listにsd_vaeを追加する
• Checkpointに内蔵されているものを上書きする
• SDXL BaseのVAEはfp16ではオーバーフローによるNaN演算で動作しないので、sdxl-vae-fp16-fixを使う

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

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

• Checkpoint Merger
• 層別マージ

• HuggingFace Modelsがおすすめ

• 学習・推論共にfp16, pruned, safetensorsでよい。
• ファイル名には日本語やスペースが無いほうが文字化けやパスの区切りの誤判定によるトラブルが減る。