技術 約13分で読めます

Z-AnimeはZ-Image系のアニメ特化フルファインチューンだった

AI 画像生成 Z-Image ComfyUI Apple Silicon 実験
いけさん目次

Hugging Faceで SeeSee21/Z-Anime を見かけた。
名前だけだとZ-Image系なのか、Z-Imageっぽい別モデルなのか分かりにくい。

Z-AnimeはZ-Image Baseアーキテクチャのアニメ特化フルファインチューン。
LoRAをマージしただけの派生チェックポイントではなく、Z-Image Baseからアニメ生成へ寄せて学習したモデルファミリーになっている。

Z-Imageの基本整理やRunPodで動かす調査を書いたときの見方で言うと、今回は「Z-Imageの軽さと自然文プロンプトの流れに、アニメ絵のフルモデルが乗った」もの。
前に試したZ-Image i2iのドット絵変換とは違って、用途はスタイル変換よりtxt2imgのアニメ生成に寄っている。

LoRAマージではなくZ-Image Baseのフルファインチューン

モデルカードでは、Z-Animeを「AlibabaのZ-Image Base architectureのfull fine-tune」と説明している。
ベースはS3-DiT、つまりZ-Imageと同じSingle-Stream Diffusion Transformer系。パラメータ規模もZ-Image Base由来の6B系として扱われている。

ここはけっこう大きい。
SDXL系のアニメモデルをZ-Imageに持ち込んだわけではないので、SDXL用LoRAやIllustrious系の資産とは互換性がない。
逆に、Z-Image用のLoRA学習やComfyUIワークフローの流れに乗る。

Z-Animeには以下の系統がある。

系統役割使いどころ
Z-Anime Base高品質版仕上げ生成、ネガティブプロンプト、細かい制御
Z-Anime Distill-8-Step8ステップ版普段使い、速度と品質のバランス
Z-Anime Distill-4-Step4ステップ版大量試行、ラフ生成
GGUF量子化版低VRAM、CPU、AMD寄りの構成
AIO単一ファイル版ComfyUIで手早く読み込む
DiffusersPython用ZImagePipeline.from_pretrained() で使う

Baseは28〜50ステップ、CFG 3.0〜5.0が推奨。
ネガティブプロンプトも効く。

Distill-8-StepとDistill-4-StepはCFG 1.0付近で使う前提。
ネガティブプロンプトの効きは限定的になる。
このへんはZ-Image-Distilledの記事で見た蒸留モデルの性格と同じで、速さの代わりに細かい制御幅は落ちる。

ローカルで動かすならAIOかGGUF

ローカルで触るなら、まず分岐はAIOにするか、標準構成にするか。

形式配置長所注意点
AIO FP8models/checkpoints/単一ファイルで楽ファイルは約10.5GB
標準 FP8models/diffusion_models/ + models/clip/ + models/vae/ComfyUIの通常構成に近いモデル、テキストエンコーダ、VAEを分ける
GGUF Q8_0models/unet/量子化でも品質寄りComfyUI-GGUFが必要
GGUF Q4_K_Smodels/unet/ファイル約4.5GBで軽い量子化劣化と速度低下の可能性
DiffusersPythonコードから読むスクリプト化しやすいComfyUI用途なら遠回り

Z-Animeのリポジトリ全体は203GBある。
全部落とすものではない。
ComfyUIでちょっと見るだけなら、AIO FP8の8-step版かBase版を1つ選ぶのが一番楽。

8GB VRAM対応と書かれているが、これは「何も考えず全部VRAMに常駐して余裕」という意味ではない。
Z-Image系はテキストエンコーダにQwen 3 4Bを使うので、モデル本体だけでなくエンコーダとVAEの置き場所が効く。
8GB GPUならFP8かGGUFを選び、ComfyUI側の低VRAM設定やオフロードを前提にしたほうがいい。

16GB以上のNVIDIA GPUならFP8構成が現実的。
24GB以上ならBase BF16も候補になる。
M1 Max 64GBのようなApple Silicon環境ならメモリ容量は足りる。実測は後の実行ログにまとめた。

ComfyUIの置き場所

AIO版は単一ファイルなので簡単。

ComfyUI/models/checkpoints/
├── z-anime-base-aio-fp8.safetensors
└── z-anime-distill-8step-aio-fp8.safetensors

標準版はZ-Imageの通常構成に近い。

ComfyUI/models/
├── diffusion_models/
│   └── z-anime-base-fp8.safetensors
├── clip/
│   └── qwen_3_4b-fp8.safetensors
└── vae/
    └── ae.safetensors

GGUF版はComfyUI-GGUFを使う。

ComfyUI/models/
├── unet/
│   └── z-anime-base-q4_k_s.gguf
├── clip/
│   └── qwen_3_4b-fp8.safetensors
└── vae/
    └── ae.safetensors

モデルカードには公式ワークフロー workflows/Z-Anime-Workflow-v1.json も入っている。
Base、Distill、GGUF、AIOを切り替える構成なので、最初はそれをそのまま読み込むのが早い。

プロンプトはDanbooruタグより自然文寄り

Z-Animeは自然文プロンプト推奨。
1girl, silver hair, shrine maiden のようなタグ列より、服装、光、背景、表情、構図を文で書いたほうがよいとされている。

これはSDXLアニメモデルの感覚と少し違う。
IllustriousやWAI系ではタグ列の資産が強いが、Z-AnimeはZ-Image由来の自然文理解を使うモデルとして見たほうがよさそうだ。

Baseで詰めるなら、以下の方向になる。

調整BaseDistill-8 / Distill-4
ステップ28〜508 / 4
CFG3.0〜5.0中心1.0中心
ネガティブプロンプト効く効きは限定的
試行回数少なめ多めに回せる
用途仕上げラフ、量産、候補出し

アニメ絵で顔や手を詰めたいなら、最初から4-stepだけで判断しないほうがいい。
4-stepは速いが、破綻の修正余地も少ない。
Baseか8-stepで画風と構図を見て、必要ならBaseに戻す流れが無難。

Z-Image派生モデルとしての面白さ

Z-Image系は、最初に調べたときは「FLUXより軽いオープン画像生成モデル」という印象が強かった。
その後、Z-Image-Distilled、BEYOND_REALITY_Z_IMAGE、ピクセルアートLoRA、漫画系ワークフローが出て、今回はアニメ特化フルファインチューンまで来た。

SDXLほど資産は厚くないが、Z-Image側はファインチューンと量子化の回転が速い。
Z-Animeが面白いのは、単に「アニメ絵が出る」ことより、Z-Image Base系列でアニメ向けのBase、蒸留、AIO、GGUF、Diffusersまで一気に揃えているところ。

ローカルで試すなら、まず z-anime-distill-8step-aio-fp8.safetensors で雰囲気を見る。
品質を詰めたくなったらBase FP8かBase BF16へ移る。
8GB GPUやAMD寄りの環境ならGGUFから入る、という順番でよさそうだ。

AIO版のComfyUIワークフロー

AIO版はモデル本体、テキストエンコーダ（Qwen 3 4B）、VAEを1つのsafetensorsにまとめた形式。
ComfyUIでは CheckpointLoaderSimple ノード1つで全部読み込む。

標準構成だと UNETLoader + CLIPLoader + VAELoader を個別に配線するが、AIOはそれが不要。
最小限のノードでワークフローが組める。

graph TD
    CKP["CheckpointLoaderSimple<br/>z-anime AIO FP8"]
    POS["CLIPTextEncode<br/>positive prompt"]
    NEG["CLIPTextEncode<br/>negative prompt"]
    LAT["EmptyLatentImage"]
    KS["KSampler"]
    DEC["VAEDecode"]
    SAVE["SaveImage"]

    CKP -->|MODEL| KS
    CKP -->|CLIP| POS
    CKP -->|CLIP| NEG
    CKP -->|VAE| DEC
    POS -->|CONDITIONING| KS
    NEG -->|CONDITIONING| KS
    LAT -->|LATENT| KS
    KS -->|LATENT| DEC
    DEC -->|IMAGE| SAVE

CheckpointLoaderSimpleからMODEL、CLIP、VAEの3本が出る。
MODELはKSamplerへ、CLIPは2つのCLIPTextEncodeへ、VAEはVAEDecodeへ。
あとはEmptyLatentImageでサイズを決めてKSamplerに流し、KSamplerの出力をVAEDecodeで画像にする。
ノード7つ、接続9本。

Distill-8-Step AIOのKSampler設定

steps: 8
cfg: 1.0
sampler_name: euler
scheduler: normal
denoise: 1.0

蒸留モデルなのでステップ数は8固定。
CFGは1.0付近が前提で、上げるとノイズが乗る。
ネガティブプロンプトは入れても効きが薄い。
空欄のまま、または low quality, blurry 程度にとどめておく。

Base AIOのKSampler設定

steps: 30
cfg: 4.0
sampler_name: euler
scheduler: normal
denoise: 1.0

stepsは28〜50で推奨されている。
30あたりから始めて、仕上げが甘いなら上げる。
CFGは3.0〜5.0の幅。低いとプロンプトの反映が緩く、高いと過剰適合で不自然になる。

Base版はネガティブプロンプトが効く。
手の破綻を避けるなら extra fingers, bad hands, deformed 系を入れておく意味がある。

解像度

1024x1024がベース。
縦長の立ち絵なら768x1024や832x1216あたりを使う。
EmptyLatentImageのwidthとheightに入れる。

ComfyUIは8の倍数なら受け付けるが、極端なアスペクト比はモデルの学習分布から外れる。
横長のワイドパノラマとか2048x512みたいなものは崩れやすい。

AIOは手早いが、テキストエンコーダやVAEを個別に差し替えたい場面には向かない。
Qwen 3 4Bの量子化版で軽量化したいとか、VAEだけ入れ替えてトーンを変えたいなら標準構成にする。
逆にそこまで触る予定がなければ、配線ミスのないAIOで十分。

AIO FP8のダウンロード

huggingface-cli でファイル単体を指定して取る。

pip install -U huggingface_hub

huggingface-cli download SeeSee21/Z-Anime \
  z-anime-distill-8step-aio-fp8.safetensors \
  --local-dir ./z-anime-download

Distill-8-Step AIO FP8が約10.5GB。
ダウンロードしたら ComfyUI/models/checkpoints/ へ移す。

mv ./z-anime-download/z-anime-distill-8step-aio-fp8.safetensors \
  /path/to/ComfyUI/models/checkpoints/

Base版も試すなら z-anime-base-aio-fp8.safetensors を同じ要領で取る。
まず8-step版で画風を確認して、詰めたくなったらBase版を足す流れでいい。

公式ワークフローJSONも落としておく。

huggingface-cli download SeeSee21/Z-Anime \
  workflows/Z-Anime-Workflow-v1.json \
  --local-dir ./z-anime-download

HuggingFaceのWeb UIからFiles and versionsタブで直接ダウンロードしても同じ。

Apple SiliconでのComfyUI起動

M1/M2/M3系では、ComfyUIはMPS（Metal Performance Shaders）バックエンドで動く。
ユニファイドメモリが64GB以上あればAIO FP8を読み込んで余裕がある。

起動は python main.py のままでいい。
MPSはFP8ネイティブ演算に対応していないので、内部でFP16にアップキャストされる。
--force-fp16 を明示しても実質変わらないが、ワーニングが消える場合がある。

NVIDIA GPU環境だと --lowvram でVRAM配分を制御するが、Apple Siliconはユニファイドメモリなのでオフロードの事情が違う。
メモリが十分ならデフォルト起動で問題ない。

ワークフロー読み込みから初回生成まで

ComfyUIが開いたら、ダウンロードした Z-Anime-Workflow-v1.json を画面にドラッグ&ドロップする。
公式ワークフローにはBase、Distill、GGUF、AIOの切り替えスイッチが入っている。
ノード数は多いが、全体の構成を掴むのに使える。

最小構成で自前で組むなら、前述のMermaid図の7ノードをそのまま並べる。
CheckpointLoaderSimpleで z-anime-distill-8step-aio-fp8.safetensors を選択し、KSamplerは前述のDistill-8-Step設定にする。

テストプロンプトは自然文で書く。

A girl with long silver hair standing in a shrine at sunset,
wearing a white and red shrine maiden outfit,
cherry blossom petals floating in the warm golden light,
detailed anime style

Distill-8-Stepならnegative promptは空欄でいい。
Queue Promptを押せば生成が走る。

Apple Siliconの生成速度はNVIDIA GPUより遅い。
1024x1024の8ステップでM1 Maxだと数十秒から数分の範囲になる。
初回はモデル読み込みが入るのでさらに時間がかかるが、2回目以降はキャッシュが効いて生成部分だけになる。

M1 Max 64GBで実際に動かしてみた

手元のM1 Max 64GB / ComfyUI 0.16.4 / PyTorch 2.10.0 / MPSバックエンドで生成してみた。

  • モデル: z-anime-distill-8step-aio-fp8.safetensors（9.8GB）
  • 解像度: 1024×1024
  • KSampler: steps=8 / cfg=1.0 / sampler=euler / scheduler=normal / denoise=1.0
  • ネガティブプロンプト: 空欄
  • ポジティブ: 前述のテストプロンプト（巫女装束、銀髪、夕暮れの神社、桜）

初回実行（モデル読み込み込み）で約135秒。
RAMはComfyUI起動直後で41GBほど空いていて、生成中も足りなくなる気配はなかった。
2回目以降はチェックポイントがキャッシュに乗るので、もう少し短くなる想定。

Z-Anime Distill-8-Step AIO FP8で生成した巫女

「detailed anime style」を入れただけで、Z-Image Baseのフルファインチューンらしいアニメ調がそのまま出る。
鳥居、桜、夕日、巫女装束を自然文だけで指定して、構図と配色は1回目で素直に乗ってきた。
タグ列を組み立てなくても1024×1024で破綻なく出るのは、SDXLアニメ系の感覚とは違う。

Distill-8-Step AIOでM1 Max 64GBから1024×1024が135秒で出るなら、雰囲気確認用としては回せるレンジ。
画風を詰めにいく段でBase AIO FP8（30〜50ステップ）に切り替えれば、所要時間は4〜6倍くらいになる見込み。

i2iで既存キャラを通せるか試す

既存のキャラLoRA（waiANIMA / SDXL系）はZ-Image系には流用できない。アーキテクチャが別物だから。
じゃあLoRAなしでi2iに突っ込むとどこまで同一性が残るか、というのを試した。

入力にはwaiANIMA + 自作kanachan LoRAで以前生成した立ち絵を使う。
ワークフローは前述の最小構成に LoadImage → VAEEncode を足して、KSamplerの denoise を1.0未満にするだけ。

graph TD
    CKP["CheckpointLoaderSimple<br/>z-anime AIO FP8"]
    LI["LoadImage<br/>kana_input.png"]
    VE["VAEEncode"]
    POS["CLIPTextEncode<br/>positive"]
    NEG["CLIPTextEncode<br/>negative"]
    KS["KSampler<br/>denoise=0.5/0.7/0.85"]
    DEC["VAEDecode"]
    SAVE["SaveImage"]

    CKP -->|MODEL| KS
    CKP -->|CLIP| POS
    CKP -->|CLIP| NEG
    CKP -->|VAE| VE
    CKP -->|VAE| DEC
    LI -->|IMAGE| VE
    VE -->|LATENT| KS
    POS -->|CONDITIONING| KS
    NEG -->|CONDITIONING| KS
    KS -->|LATENT| DEC
    DEC -->|IMAGE| SAVE

入力画像（waiANIMA + kanachan LoRA、SDXL系で生成。サイドポニー＋青シュシュ＋アホゲ＋制服立ち姿）。

i2i入力に使ったかなちゃん立ち絵

denoiseだけ変えて3パターン生成。プロンプトには「サイドポニー、青シュシュ、アホゲ、白シャツ、赤ネクタイ、紺プリーツ、立ち姿」を自然文で書いた。

denoise=0.5: ほぼ変わらない

denoise=0.5の結果

出力はほぼ入力と同じ。Z-Animeの画風は乗っていない。
i2iで「画風だけ変える」用途には不足。VAEを通って戻ってきた程度の差しかない。

denoise=0.7: 顔も髪型も崩れる

denoise=0.7の結果

ここですでにサイドポニーが崩れて、横に流した髪のように変化している。青シュシュも消えた。
顔も同じ方向で、目の形と輪郭がZ-Anime寄りに引っ張られて入力のかなちゃんとは別人。
服装（白シャツ・赤ネクタイ・紺プリーツ）は残るが、髪型と顔はもう同一性を主張できない。

denoise=0.85: ポニーテール形状は復活するが位置と顔が別物

denoise=0.85の結果

面白いのが、d07で崩れていたポニーテールがこちらでは復活している。
ただし位置はサイドではなく後頭部寄りの高めの位置で、青シュシュもなく、結ぶ位置自体がズレている。
顔はさらにZ-Anime寄りに振れていて、別キャラ。
プロンプト側で side ponytail と書いていないのも効いていそうだが、いずれにせよ入力画像から髪型を保つ働きはdenoise=0.85では弱い。

LoRAなしのi2iでは、denoiseを動かしても「Z-Animeの画風 × かなちゃんの顔・髪型」を両立する点は見つからなかった。低いと画風が乗らず、0.7で髪型と顔が崩れ、0.85ではポニーテール形状は戻るが位置も顔も別キャラ。入力画像のシルエットや構図を借りて新キャラを出す、くらいの使い方になる。

本格的にZ-Animeでかなちゃんを出したいなら、Z-Image用にLoRAを学習し直す必要がある。SDXL用のkanachan LoRA資産はZ-Anime側では使えない。

センシティブ表現の通り具合

AIO Distill-8-stepでNSFW系プロンプトを通したらどうなるか、というのも見ておきたかった。
プロンプト側で nude, no clothes, bare skin を含めてtxt2imgで投げる。

以下の画像はGoogle対応で全体ぼかしをかけている。
NSFWが苦手な方はここまでで大丈夫です。

Z-Anime AIO Distill-8-stepでNSFWプロンプトを通した結果（ぼかし）

ブロックなしで素直に出力された。プロンプト方向に追従するだけで、組み込みのセーフティフィルタや黒塗り処理は入らない。
SDXL Illustrious系やwaiANIMA系のアニメモデル群と同じ扱い。Z-Image Baseは比較的穏当な印象だったが、Z-AnimeのアニメフルFTでは規制を抜く方向に振られている、というのが手元での観察。

ローカル運用前提の話なので、共有環境やクラウドで使う場合はサービス側の規約と独立に考える必要がある。

参考リンク