Z-Image-Turboの蒸留を外してLoRA学習する話を調べた

Z-ImageをRunPodで動かせるか調べたときは、LoRAをやるならTurboではなく通常のZ-Imageを使う、くらいの認識だった。
ただ、Z-Image-Turboにも「蒸留を外してLoRA学習する」方法があるらしい。
自キャラLoRAで試す前に、何が起きているのかを把握しておく。

調べた限り、話は「Turboを本当に非蒸留モデルに戻す」ではない。
学習時だけTurboの蒸留済み挙動を少し崩して、LoRA側にTurboの高速軌道まで壊させないための迂回路だった。

Turboをそのまま学習すると8ステップ性が壊れる

公式のZ-Image-Turboは、8ステップ前後で動くように蒸留されたモデルだ。
通常のZ-ImageがCFG 3.0〜5.0、28〜50ステップ、ネガティブプロンプトありで動くのに対して、Turboはguidance 0.0付近、少ないステップ、ネガティブプロンプトなしが基本になる。

この差がLoRA学習で問題になる。
通常のdiffusionモデルにLoRAを焼く感覚でTurboを直接fine-tuneすると、LoRAが対象キャラや画風だけでなく、Turboの「少ないステップで着地する軌道」まで変えてしまう。

DiffSynth-StudioのDistillPatch説明では、Z-Image-Turbo上で直接学習したLoRAは8ステップ設定だとぼやけ、30ステップ程度に増やすと普通に見える、という症状が書かれている。
つまりLoRA自体は何かを学んでいるが、Turboとしての加速能力が崩れている。

flowchart TD
  A[Z-Image-Turbo] --> B[直接LoRA学習]
  B --> C[対象や画風を学ぶ]
  B --> D[高速生成の軌道も崩れる]
  D --> E[8ステップでぼやける]
  D --> F[ステップを増やすと戻る]

これは画像生成の品質問題というより、蒸留済みモデルを学習ベースにしたときの構造的なズレに見える。
Turboは推論用に圧縮された状態であって、LoRA学習の起点としては不安定。

de-distill adapterは学習時だけ使う補助具

Ostrisの zimage_turbo_training_adapter は、このズレを避けるための学習用LoRAだ。
モデルカードでは、Turboの蒸留を壊す処理を先にadapter側へ持たせることで、短い学習なら新しいLoRAが対象だけを学びやすくなる、と説明されている。

流れはこうなる。

flowchart TD
  A[Z-Image-Turbo] --> B[training adapterを重ねる]
  B --> C[学習中だけde-distill寄りにする]
  C --> D[新しいLoRAを学習]
  D --> E[推論時はtraining adapterを外す]
  E --> F[Turboと新LoRAだけで生成]

ポイントは、推論時にtraining adapterを残さないこと。
学習中はTurboを普通の拡散モデル寄りに見せておき、生成時には外してTurboの速度に戻す。
「蒸留を外す」という言い方をすると恒久的なモデル変換に聞こえるが、実態は学習時の補助具に近い。

ただしOstris自身も、これはハックだと書いている。
短いrun、たとえばキャラ、スタイル、コンセプトLoRAには効くが、長時間fine-tuneすると蒸留崩れが進み、adapterを外したときにアーティファクトが出る。

Baseがある今はBase学習が一番素直

2026年1月に通常版のZ-Imageが公開されてからは、まずBaseでLoRAを学習するのが素直な選択になる。
公式のZ-Imageモデルカードも、通常版を「非蒸留の基盤モデル」として、LoRA、ControlNet、semantic conditioning向けと説明している。

Z-ImageとZ-Image-Turboの違いをLoRA視点で見るとこうなる。

ベース	学習のしやすさ	推論速度	ネガプロ	向いている用途
Z-Image	高い	28〜50ステップ	使える	キャラLoRA、画風LoRA、長めの検証
Z-Image-Turbo + training adapter	中くらい	8ステップ狙い	基本使わない	Turboで使う短期LoRA
Z-Image-Turbo直接学習	低い	崩れやすい	基本使わない	検証用途
Z-Image-De-Turbo	中くらい	20〜30ステップ	低CFG	Base公開前の迂回路、Turbo寄りの見た目を残す実験

キャラの顔や衣装を安定させたいなら、Baseで学習して、まずBase上で品質を見る。
その後で同じLoRAをTurboに載せて、速度と品質の落ち方を見るのが現実的だと思う。

一方で、最初からTurboの8ステップ運用が目的ならtraining adapterを使う価値がある。
ただし、その場合は学習中のvalidationもTurbo設定で見る必要がある。
30ステップで良く見えても、8ステップで崩れるなら目的に合っていない。

DistillPatchはあとから加速能力を戻す別ルート

もう一つ出てくるのがDiffSynth-Studioの Z-Image-Turbo-DistillPatch だ。
これはLoRA学習時のadapterではなく、推論時に一緒に読み込んでTurbo LoRAの加速能力を補正するLoRAとして配布されている。

考え方はtraining adapterと逆に近い。

方法	使うタイミング	目的
training adapter	学習時	Turboの蒸留崩れをLoRAへ移さない
DistillPatch	推論時	崩れたTurbo LoRAを8ステップで使いやすくする

DiffSynth側は、標準SFTでTurbo LoRAを作り、推論時にDistillPatchを重ねる方式を「学習の簡単さと推論速度のバランスが良い」としている。
ComfyUI向けには、キー名を diffusion_model.layers に合わせた派生版も出ている。

ただ、個人的には最初の実験でDistillPatchから入るより、Base学習とtraining adapter学習を比べるほうが分かりやすい。
DistillPatchは「直接Turbo学習したLoRAが8ステップでぼやける」と確認できてから試すほうが、効いているか判断しやすい。

実験するならこの順番にする

自キャラLoRAで試すなら、いきなり設定を盛らない。
比較できないと、失敗したときに原因が分からなくなる。

1回目はZ-Image Baseで学習する。
1024px、rank 16、batch 1、過学習しない短めのstepから始める。
validationは同じseed、同じprompt、違う構図を数本固定する。

2回目はZ-Image-Turbo + training adapterで同じdatasetを使う。
推論時はtraining adapterを外し、Turbo本来の8〜9ステップ、guidance 0.0付近で見る。
ここでBase版より顔が崩れないか、速度を保てるかを見る。

3回目にTurbo直接学習を短く回す。
これは本命ではなく、DistillPatchの効果を見るための対照実験にする。
8ステップでぼやけ、30ステップで戻るなら、DistillPatchを重ねたときの差が分かる。

学習ツールは、現時点だとSimpleTuner、AI Toolkit、Musubi Tunerが候補になる。
SimpleTunerはZ-Image Turbo LoRAのquickstartでassistant adapterを扱う前提を書いている。
Musubi Tunerは2026年1月29日の更新でZ-Image BaseのLoRAとfine-tuningが動作確認済みになっており、Z-Image系を触るなら追う価値がある。

前にZ-Image-Distilledの記事で、蒸留してもLoRA互換性を残す派生モデルの話を書いた。
今回のTurbo training adapterはそれとは違って、Turbo本体を非蒸留モデルに戻すわけではない。
学習中だけ蒸留済みモデルの癖を逃がして、生成時にはTurboへ戻すための道具だ。

SDXL系のアニメLoRAはZ-Imageに持ち込めない

Z-ImageのアーキテクチャはS3-DiT（Single-Stream Diffusion Transformer）で、SDXLのUNetとは根本的に違う。
Z-Imageはテキストと画像を1つのストリームに連結し、共有トランスフォーマーブロックで処理する。
SDXLはエンコーダ・デコーダ構造のクロスアテンションでテキスト条件を注入する設計で、レイヤー名もテンソル形状も一致しない。
SDXL系で学習したLoRAのsafetensorsをZ-Image側に読み込んでも、対応するキーが存在せずエラーになる。

waiANIMAやIllustrious系で作ったキャラLoRAも当然使えない。
Z-Animeの実験でi2iを試したときにも確認したが、SDXL用LoRAファイルはZ-Image系のComfyUIワークフローでそもそもマッチしない。
FLUXのLoRAも同様で、FLUX・SDXL・Z-Imageはそれぞれ完全に独立したLoRA生態系になっている。

M1 Maxの手元環境でZ-Anime系を動かしつつ、waiANIMA向けに学習したkanachan LoRAをそのまま持ってくることはできない。
Z-Image系でキャラLoRAを使いたいなら、Z-Image BaseかZ-Anime Baseでデータセットから学習し直す必要がある。

Z-Image LoRA学習はタグ列でも自然言語でも動く

SDXL系のアニメモデルではDanbooruタグのカンマ区切りキャプションが主流だった。
Z-Imageの公式推奨は自然言語プロンプトで、100〜300トークンの文章を被写体、雰囲気、画風の順に書く形式になっている。
テキストエンコーダがQwen3 4Bなので、文の意味を理解する前提の設計。

ただしLoRA学習に限れば、タグ列でも普通に動く。
CivitaiでZ-Image-Turbo向けアニメLoRAを100本以上学習したユーザーの報告では、タグでもキャプションでも学習結果に大きな差は出ていない。
キャラLoRAではキャプションを詰め込みすぎると過学習しやすく、トリガーワード1つだけの最小構成で十分なケースもあるとのこと。

waiANIMAのLoRA学習で起きた「Danbooruタグだけだと方向情報がテキストエンコーダに伝わらない」問題は、Z-Imageでは事情が違う。
waiANIMAの場合はAnimaのCLIP-lessアーキテクチャ（Qwen3 0.6B TE）への切り替えで、SDXL時代のタグ列最適化が崩れたのが主因だった。
Z-Imageは最初からQwen3 4B TEで設計されているため、タグ列に対するCLIP的な最適化がそもそも存在しない。
タグを渡しても自然言語を渡しても、Qwen3 TEが同じように文脈を解釈する。

推論時は自然言語のほうが品質が安定する傾向がある。
学習キャプションをタグ列で書いたとしても、推論でトリガーワードを自然言語プロンプトに組み込む形で使えば問題ない。

保存形式はsafetensorsの標準LoRA一択。
LoKR形式だと「lora key not loaded」の警告が大量に出てレイヤーの大半が読み込まれない報告がある。
fp32保存が推奨で、量子化保存は品質が落ちるとされている。

学習パラメータのベースラインもSDXL時代とは変わる。
rank 8〜16、学習率1e-4〜5e-5、素材5〜15枚で3,000ステップ前後、1024x1024、バッチサイズ1〜2あたりがZ-Image LoRA学習の出発点になる。
SDXL向けのrank 32から下げて、ステップ数で調整する方向。

RunPodでやるならこうなる

手元のM1 Maxで画像生成は動くが、LoRA学習は現実的ではない。
問題は学習コストではなく時間で、6BモデルのLoRA学習をMPSバックエンドで回すと1エポックに何時間もかかる。
前回RunPodで4090を借りてLoRA学習したときの実績からすると、Z-Image Base（6Bパラメータ）のrank 16 LoRAならRTX 4090（24GB）で十分足りる。
推論がbf16で約12GBなので、学習時のオプティマイザ状態を含めても24GBに収まる計算。

ワークフロー自体はWAI-Anima向けLoRAをRunPodで焼いたときと同じCPU + GPU二段構成を使う。
違いはモデルサイズとツールだけ。

モデル転送量の見積もり

Z-Image系のLoRA学習に最低限必要なファイル群を並べる。

ファイル	サイズ	備考
Z-Image Base本体	約12GB	safetensors、bf16
Qwen3 4B TE	約8GB	HuggingFace形式フォルダ
VAE	約200MB
training adapter（Turbo用）	約600MB	Base学習なら不要
学習素材 + キャプション	数十MB	10〜20枚想定

合計20GB前後。
前回のIL学習ではsd-scripts + ILモデル6.5GBで30分程度だったが、Z-Imageは転送量が3倍になる。
CPU Pod（$0.08/h）で1時間半ほどかかる見込み。
HuggingFaceからのダウンロード速度はリージョンに依存するので、us-tx-3やeu-ro-1など回線が太いリージョンでNetwork Volumeを作るのが無難。

ツール選定

Z-Image系LoRA学習に対応しているツールは以下。

ツール	Z-Image Base	Z-Image-Turbo + adapter	特徴
SimpleTuner	対応	quickstart記載あり	training adapterの設定手順がドキュメント化済み
Musubi Tuner	対応	未確認	2026年1月にZ-Image BaseのLoRA動作確認済み
AI Toolkit	対応	対応	Ostrisが開発元なのでtraining adapter前提の設計

最初はAI ToolkitかSimpleTunerから入るのが筋が良い。
training adapterはOstris製なので、AI Toolkitとの親和性が一番高い。
SimpleTunerはZ-Image Turbo LoRAのquickstartでassistant adapter（training adapterの別名）を前提にした設定例を載せているので、Turbo学習をやるならこちらも候補。

Musubi TunerはZ-Image Base学習が確認済みだが、Turbo + training adapterの組み合わせは現時点で記載がない。
Base学習だけやるならMusubi Tunerでも問題ない。

想定コストと時間

前回のIL学習の実績をZ-Image Baseに外挿する。

項目	見積もり
Network Volume 50GB	$0.01〜0.02（数時間で破棄）
CPU Pod（モデル転送 + venv構築）	$0.12〜0.16（1.5〜2時間）
RTX 4090（学習本体）	$0.69〜1.38（1〜2時間）
合計	$0.8〜1.5

6Bモデルのrank 16 LoRA、batch 1、3,000ステップ前後なら4090で1時間以内に終わる見込みだ。
ただしZ-Image系はSDXLより学習が遅いという報告もあるので、初回は倍の2時間を見ておく。
Community Cloudで4090が$0.44/hで取れるリージョンなら全体で$0.7前後まで下がる。

具体的な手順（Base学習の場合）

Network Volumeを先に作り、CPU Podでモデル転送と環境構築を済ませてからGPU Podを借りる流れ。

flowchart TD
  A[Network Volume作成<br/>50GB, us-tx-3] --> B[CPU Pod起動]
  B --> C[venv + ツールclone<br/>pip install]
  C --> D[Z-Image Base 12GB<br/>Qwen3 4B TE 8GB<br/>VAE 200MB を転送]
  D --> E[学習素材アップロード]
  E --> F[CPU Pod停止]
  F --> G[GPU Pod起動<br/>RTX 4090]
  G --> H[学習実行<br/>rank 16, 3000 steps]
  H --> I[LoRA safetensors DL]
  I --> J[GPU Pod停止<br/>Volume破棄]

GPU Podの在庫が揮発的なので、CPU側の転送が終わる少し前に4090を先に確保する並行パターンも使える。
Network Volumeは複数Podに同時attachできるので、CPU転送中でもGPU Podで同じvolumeをマウントして待機できる。

キャプションの生成は手元のMacでやるほうが速い。
RunPodのGPU時間をキャプション生成に使う必要はない。
10〜20枚程度ならVLMで一括生成してからtxtファイルごとアップロードすればいい。

Turbo学習をやる場合の追加手順

Base学習との違いは2点だけ。

Z-Image-Turbo本体（約12GB）をBase本体の代わりに転送する
ostris/zimage_turbo_training_adapter（約600MB）を追加で取得し、学習設定でassistant adapterとして指定する

推論時の検証はtraining adapterを外した状態で、guidance 0.0付近、8〜9ステップで確認する。
学習中のvalidationもTurbo設定で見ないと意味がない。
30ステップで綺麗に出ても、8ステップで崩れるなら目的に合っていない。

1回の学習サイクルにかかる実時間

手元でやらない理由は学習コストではなく時間だ。
6BモデルのLoRA学習をMPSバックエンドで回すと、3,000ステップで半日以上かかる。
RTX 4090なら同じ処理が1〜2時間で終わる。
差額$1前後で半日が浮くなら、RunPodを使わない理由がない。

1回の完全サイクルはこうなる。

フェーズ	場所	時間
素材選定 + キャプション生成	手元Mac	1〜2時間
CPU Pod: モデル転送 + venv構築	RunPod	1.5〜2時間
GPU Pod: 学習実行	RunPod	1〜2時間
LoRAダウンロード + ローカル検証	手元Mac	30分

初回は半日かかるが、2回目以降はNetwork Volumeを残しておけばCPU転送が丸ごと消える。
GPU Podを借りて学習→LoRAをダウンロード→停止、で2時間以内に回る。

パラメータ調整の反復パターン

rank、学習率、ステップ数を変えて何度か回す想定なら、Network Volumeを数日間残しておくのがコスパ良い。
ストレージ代は$0.07/GB/monthなので、50GBで$3.5/月。
3日以内に実験を終えるなら$0.35程度。

反復のサイクルは短い。

flowchart TD
  A[パラメータ調整] --> B[GPU Pod起動]
  B --> C[学習 1〜2h]
  C --> D[LoRA DL]
  D --> E[GPU Pod停止]
  E --> F[手元ComfyUIで検証]
  F --> A

検証は手元のM1 MaxのComfyUIで回す。
Z-Image Baseの推論自体はbf16で12GB程度、M1 Max 64GBなら余裕で動く。
LoRAの効き具合やキャラの崩れ方を見るのにGPU時間を使う必要はない。

具体的な検証は、同じseed・同じプロンプト・異なるポーズで5枚ほど固定して比較する。
A/B比較のために「LoRAなしのBase推論」も保存しておく。
差分が出すぎていれば過学習、差分がなければ効いていない。

先にGPU Podを確保する問題

RunPodの4090はCommunity Cloudの在庫が不安定で、欲しいタイミングで確保できないことがある。
CPU Podでモデル転送中に4090が空いたら、同じNetwork Volumeに4090 Podをattachして待機させておくのが安全。
Network Volumeは同時に複数Podからマウントできるので、CPU転送とGPU待機を並行して走らせられる。

逆に4090が長時間確保できないときは、A5000（24GB、$0.22/h）やL40S（48GB、$0.74/h）も候補になる。
6BモデルのLoRA学習は24GBに収まるので、A5000でも動く。
速度は4090の6〜7割程度だが、待ち時間ゼロで借りられるなら実時間では速い。

BaseのLoRAをTurboに載せると何が起きるか

記事中で「Baseで学習してTurboに載せる」と書いたが、これが実際にどう動くのかもう少し掘る。

重みの互換性自体は問題ない。
BaseもTurboも同じS3-DiTアーキテクチャで、レイヤー構造とテンソル形状が同一。
BaseのLoRA safetensorsをTurboに読み込ませてもキーは全部一致するし、ComfyUIでエラーにならず普通に適用される。

動かないのではなく、ノイズ除去の軌道が違うところに効かせることになる。
Baseは28〜50ステップ、CFG 3.0〜5.0で長い経路をたどってノイズを取る。
Turboは8ステップ、guidance 0.0付近で一気に着地する。
LoRAが学んだ「このステップでこの方向に補正する」という重みは、Baseの長い軌道に合わせて最適化されている。
Turboの短い軌道では、補正のタイミングとスケールが本来の想定からズレる。

実際に起きそうなことは、キャラの特徴自体は出るが、Base推論時よりも安定しない。
顔の一貫性が落ちたり、衣装のディテールが甘くなったり、LoRA強度を上げると破綻が早くなったりする。
8ステップの出力がぼんやりする場合もある。
完全に無視されるわけではないが、品質の上限がBase推論時より確実に下がる。

training adapterの存在意義はまさにここで、Turbo軌道に合った学習をさせることで、8ステップでも品質を保つ。
BaseのLoRAをそのままTurboに載せるのは「動くけど最適ではない」状態。

ただ、「最適ではない」がどの程度の劣化かは学習対象とパラメータ次第。
キャラの大まかな見た目を出すだけなら十分な場合もあれば、顔の安定が必須の用途では使えない場合もある。
実験の順番としては、まずBase学習→Base推論で品質の天井を確認し、同じLoRAをTurboに載せて落ち幅を計る。
落ち幅が許容内ならそのまま使えるし、足りなければtraining adapter学習に切り替える判断ができる。

Base学習→Turbo推論は蒸留のぶんだけズレる

「安定したBaseで学習して速いTurboで使う」が正しいフローに見えるのは、fp32で学習してint8で推論するのと同じ感覚でいるから。
量子化は重みの精度を下げるだけで推論パス自体を変えないので、LoRAの補正は同じタイミングで効く。
蒸留はノイズ除去のステップ数自体を圧縮しているので、LoRAが学んだ「ステップNでこう補正する」のタイミングがTurboの8ステップ軌道と噛み合わなくなる。

これが「キーは全部一致するのに品質が落ちる」の根っこで、training adapterはまさにこのズレを学習段階で吸収する設計になっている。
Base学習→直接Turbo推論は、その吸収を省略したショートカット。

ショートカットが実用になるかは、キャラのディテール要求次第。
シルエットや髪色のような大きな特徴は残りやすく、目の描き分けや衣装の細部が先に崩れる。
8ステップの出力がBase推論の7〜8割保てればそのまま使えるし、顔の安定が足りなければtraining adapter学習に進む判断になる。