Z-Image Turbo LoRA Guide: Learning Rates, Steps and a Base Model Nobody Mentions (2026)

My first Z-Image Turbo LoRA was trained at a learning rate of 1e-3, because that number had worked for me on SDXL. Two thousand steps later the sample images were a soft-focus wax museum: the trigger token produced a face-shaped blur wearing the right jacket.

The second run, at 2e-4, produced something that looked like a slightly melted version of my subject — recognisable, unusable. The third run is the one that taught me the actual lesson, and it had nothing to do with learning rate: I was training the wrong checkpoint.

Z-Image ships as two models. Z-Image is the undistilled 6B foundation model built for control, CFG, negative prompts, diversity and fine-tuning. Z-Image Turbo is the distilled 8-step version — the one everyone actually runs — and its official model card lists fine-tunability as N/A. Almost every "Z-Image Turbo LoRA" guide on the internet skips that distinction, which is why so many people burn a weekend training a LoRA on a checkpoint that was never meant to be trained.

This guide is the version I wish existed: what Turbo does and does not accept, the two legitimate training paths, the settings that actually move the needle, and the failure map for when the loss curve looks fine and the samples do not.

TL;DR

• Decide what you are training first. Z-Image base is the fine-tunable checkpoint; Z-Image Turbo is the distilled 8-step model whose official card lists fine-tunability as N/A. Training Turbo is possible with a training adapter, but it is the harder path and not the default one.
• 1e-4 is a ceiling, not a starting point. The AI Toolkit walkthrough uses 1e-4 and advises going lower (down to 5e-5) when identity constraints are tight. Anything at 1e-3 or above melts the subject.
• 3,000 steps at batch 1 is the reference run for a character LoRA on a 15-30 image dataset, with checkpoints every 500 and samples every 250 so you can stop early.
• Rank 8 is enough for most subject and style work. Higher rank mostly buys you overfitting speed unless the concept is genuinely complex.
• The 512 vs 1024 resolution fight is real and unresolved. Train at 512 for speed and cleaner composition, at 1024 when fine texture and text matter — and expect a different number of usable steps for each.
• Turbo inference wants 8 steps and guidance 0. Community guides quoting CFG 1.5-2.0 are describing a different behaviour; if you follow the official example, you adjust lora_scale instead of CFG.
• 12GB of VRAM is enough with a low-VRAM config — the AI Toolkit issue thread reports roughly 2.9 seconds per iteration at 2000 steps on that budget.

What Z-Image Turbo Actually Is

Z-Image is Alibaba Tongyi Lab's open text-to-image family: 6B parameters, Apache 2.0, released late 2025, built on a Scalable Single-Stream DiT where text tokens, visual semantic tokens and image VAE tokens are concatenated into one input stream. That architecture is why a 6B model competes with much larger ones on prompt adherence and bilingual text rendering.

Turbo is the distilled variant. The official material is specific about what distillation bought and what it cost:

Property	Z-Image (base)	Z-Image Turbo
Parameters	6B	6B
Sampling steps	30+ typical	8 NFEs in the official example (9 pipeline steps = 8 DiT forwards)
Guidance	CFG supported	CFG not used — official example runs guidance_scale=0.0
Negative prompts	Supported	Effectively neutralised by zero guidance
Output diversity	High	Low (listed as a trade-off in the model zoo)
Fine-tunability	The intended target	Listed as N/A
Licence	Apache 2.0	Apache 2.0

That last row is the one that matters here, and it is easy to miss because it sits in a table cell. Turbo trades diversity and fine-tunability for eight-step speed. The base model keeps the tuning surface and pays for it in inference time.

None of this means Turbo LoRAs are impossible. The AI Toolkit workflow requires a separate training adapter file for Turbo — a checkpoint that reopens the fine-tuning surface the distillation closed. It works, and people ship good results with it. But it is a second-order path: one more file, one more version to keep in sync, and a base whose priors were already compressed.

The Two Legitimate Training Paths

Path	Train on	Runtime	Effort	Best for
A. Train base, run Turbo	Z-Image base	Apply the LoRA to base for fidelity checks, then to Turbo for speed	Medium — two checkpoints to manage	Most LoRAs you actually plan to use at 8 steps
B. Train Turbo directly	Z-Image Turbo + training adapter	Turbo only	Higher — adapter file, tighter LR window	Style LoRAs that need Turbo's exact texture response
C. No training	—	Reference images / IP-Adapter	Lowest	One-off consistency needs, under ~20 images of a person

Path A is the one I recommend to anyone asking "how do I train a Z-Image Turbo LoRA," because the honest answer is that you train on the model built to be trained and then run the result on the fast one. Path B is legitimate but you should know you are choosing it. Path C gets skipped constantly and should not be — if you need one character consistent across ten images, a reference workflow solves it without a training run.

The reference-image consistency approach covers path C properly, and it is the correct first stop before anyone spends GPU hours.

If you want output today, start here: Launch Z-Image Now →

The Starting Configuration

These are the numbers I would hand someone for a first run, drawn from the published AI Toolkit configuration and the community threads that corrected it. They are starting points, not commandments.

Setting	Character / subject	Style	Product & text
Base	Z-Image (path A)	Z-Image	Z-Image
Learning rate	5e-5 to 1e-4	1e-4	5e-5
Steps	3,000	3,000	3,000-4,500
Batch size	1	1	1
LoRA rank	8-16	8	16
Resolution	512-1024	512	1024
Checkpoint every	500	500	500
Sample every	250	250	250
Text encoder training	Off	Off	Off
Low VRAM	On if ≤16GB	On if ≤16GB	On if ≤16GB

The published AI Toolkit config for a Z-Image Turbo LoRA uses, concretely: image_size: 1024, steps: 3000, batch_size: 1, lr: 0.0001, lora_rank: 8, checkpoint_every: 500, sampling every 250 steps with sample prompts at lora_scale 0.8 and 1.0. The 12GB-VRAM experiment thread reports 2,000 steps at 0.0001-0.0002 with roughly 2.9 seconds per iteration, which puts a full run in the two-hour range on a modest card rather than an overnight one.

Two settings are doing quiet work in that table. Text encoder off keeps the run cheap and stops the LoRA from learning caption quirks instead of visual features. Sampling every 250 steps is what lets you stop at checkpoint 1,500 when the subject is already right — most wasted GPU time in this hobby is people running to 3,000 because the number said 3,000.

Learning Rate Is the Whole Game

If you change one number, change this one. Distilled and compressed models have a narrower usable window than SDXL, and the symptoms are distinctive enough to diagnose by eye.

What the samples look like	Diagnosis	Action
Wax, plastic skin, melted features	LR too high	Halve it: 1e-4 → 5e-5 → 2.5e-5
Subject barely changes at step 3,000	LR too low, or captions not learning the trigger	Double the LR before you double the steps
Background of every sample looks identical	Overfitting to dataset context	Lower steps, add caption variety, drop to 1,500
Style bleeds into unrelated prompts	Style LoRA applied too strongly	Evaluate at lora_scale 0.6 before retraining
Text renders garbled when it was fine before	Rank too low for a text-heavy concept	Rank 16, and check resolution before LR
Loss drops smoothly, samples never improve	Wrong checkpoint (training Turbo without an adapter, or a quantised base)	Verify the model file before re-running anything

That last row is worth repeating because it wastes the most time: you cannot train on an fp8 or GGUF-quantised base. The fp8 local guide is about inference, and quantised weights are for inference. Training wants bf16 or fp16.

The 512 vs 1024 Argument

This is where the community splits, and both camps are right about different things.

The case for 512: trainers report that high-quality images trained at 512 with 768 and 1024 unticked produce cleaner composition and less anatomical collapse, because the model sees more varied crops per step and spends its capacity on form rather than micro-detail. It is also faster per step, which means more steps in the same budget.

The case for 1024: Z-Image is natively a 1024-class model, and the published Turbo LoRA config uses image_size: 1024. Training at 512 can underfit fine texture, fabric weave, small text and skin detail — exactly the things Z-Image is good at. For product images with legible labels, 1024 is not optional.

My resolution: start at 512 to validate the concept and the LR, then re-run at 1024 for the final if texture matters. You will learn more from a fast 512 run in 40 minutes than from a 1024 run you are afraid to restart. And check your dataset before either — if the source images are 800px crops, training at 1024 is upscaling noise.

Steps, Checkpoints and How to Stop Early

The reference 3,000 steps is a default, not a target. What matters is the checkpoint curve, and the only way to read it is to sample during training.

A workable schedule for a 20-image character dataset:

1. 0-500 steps — samples look like the base model with a hint of the trigger. Normal. Do not judge.
2. 1,000-1,500 — subject recognisable, background still borrowed from dataset. This is usually the best checkpoint for character work.
3. 2,000-2,500 — subject solid, prompts start bending toward the dataset's lighting. Check for context lock.
4. 3,000+ — only if the concept is complex (a specific garment plus a specific face) or the dataset is large. Bigger datasets tolerate more steps; the community advice to raise steps above 3,000 for larger datasets follows from that.

Ready to try it yourself? Try Z-Image Free →

Then evaluate each checkpoint at three scales — 0.6, 0.8, 1.0 — on prompts that are deliberately outside the dataset. A LoRA that only works on prompts resembling its training captions has learned a scene, not a subject.

Dataset Rules That Decide the Outcome

The settings get the attention; the dataset decides whether the run is worth doing.

• 15-30 images for a character, 30-60 for a style. Below 15 the model memorises; above 60 with one subject it starts averaging.
• One trigger token, consistently spelled. <teach3r> in the published example — a rare token, not a real word. Two trigger variants in one dataset will split the concept.
• Captions describe what varies, not what is constant. If every image has the subject in a studio, captions must name the studio or the LoRA will bake it in.
• Vary framing and lighting on purpose. Head-and-shoulders only produces a head-and-shoulders LoRA that collapses at full body.
• No watermarks, no compression artefacts, no duplicates. Duplicates act as a step multiplier on that image, and it will dominate.
• Resolution close to your training size. 1024 training on 800px sources is interpolation, and interpolation is not detail.

Running the LoRA at 8 Steps in ComfyUI

Training is half the workflow; the other half is not breaking Turbo's speed profile when you load your LoRA.

• Keep the step count at 8 (9 in the pipeline, 8 DiT forwards). Adding steps to a distilled model does not refine the image; it moves the sampler past the trajectory it was distilled for.
• Keep guidance at the official value. The model card example uses guidance_scale=0.0, and ComfyUI's Turbo workflow keeps CFG effectively neutral. Community guides recommending 1.5-2.0 are buying contrast, not fidelity. If your LoRA output is washed out, raise lora_scale, not CFG.
• Model files land in three folders: models/diffusion_models/z_image_turbo_bf16.safetensors, models/text_encoders/qwen_3_4b.safetensors, models/vae/ae.safetensors. The GGUF walkthrough covers the quantised layout if VRAM is tight at inference time.
• Stack at most two LoRAs. Z-Image LoRAs interact less predictably than SDXL ones; a character plus a style at 0.7 each is usually the ceiling before texture turns plastic.
• Do not switch samplers casually. Turbo is distilled for a specific schedule; an exotic sampler plus 8 steps is how people conclude the LoRA is broken.

If your prompts are the variable rather than the LoRA, the Z-Image prompt guide is the better read — caption style in training and prompt style at inference should match, or the LoRA underperforms for reasons that have nothing to do with training. For a closer look at how it stacks up against other models, see GLM.

VRAM Reality

Budget	What works	What to change
8GB	GGUF inference; training only with heavy offload and small resolution	Train at 512, batch 1, expect slow iterations
12GB	Training at 512-1024 with low-VRAM config — reported ~2.9 s/it at 2,000 steps	Enable low-VRAM, checkpoint often, avoid text-encoder training
16GB	Comfortable 1024 training, 8-step inference at 1024	Nothing structural
24GB+	1024 training with larger batch, faster wall clock	Batch 2 can help stability, not quality

The low-VRAM switch is not cosmetic: it changes how the optimizer holds state and is the difference between a run that fits and a run that OOMs at step 30. Turn it on before you discover you needed it.

Want to see the difference on your own footage? Start creating with Z-Image →

Failure Map

Symptom	Cause	Fix
Melted features, plastic skin	LR too high	1e-4 → 5e-5
Trigger does nothing	Captions inconsistent, or trigger collides with a real word	Rare token, one spelling, verify captions
Every output has the same background	Dataset context baked in	Caption the background, add variety, 1,500 steps
Good at 1024, broken at 512 (or reverse)	Trained at one resolution only	Train at the resolution you will run
OOM at step 30	Low-VRAM off, batch too large	Batch 1, low-VRAM on, 512 first
Samples improve, then degrade	Passed the good checkpoint	Stop at the 1,000-1,500 checkpoint
Text garbled permanently	Rank too low, or text in dataset unreadable	Rank 16, 1024 training, clean text sources
LoRA does nothing on Turbo but works on base	Trained on base, applied without matching the pipeline	Check the adapter/checkpoint pairing

Evaluation Before You Ship It

Three tests, each cheap, each catching a different failure:

1. Out-of-dataset prompts. Five prompts that share the trigger but not the scenes. If only dataset-like prompts work, you trained a scene.
2. Scale sweep. The same prompt at lora_scale 0.5, 0.7, 0.9, 1.1. The usable range is the band where the subject is present and the texture is not yet plastic — often narrower than people expect.
3. Interference test. Your LoRA plus a second, unrelated LoRA at 0.5 each. If the output collapses, this LoRA will not survive a real workflow.

Keep the checkpoint that passes all three, not the one with the lowest loss.

When You Do Not Need a LoRA At All

Training is the right answer for a recurring subject across hundreds of images, a proprietary style, or a product line. It is the wrong answer for:

Skip the setup and test it in the browser: Experience Z-Image Free →

• One character in one campaign — reference images handle it faster.
• A style you can prompt — a well-written prompt plus a reference image often beats a weak LoRA.
• A single hero image — you are spending two hours of GPU time to save ten minutes of prompting.

The honest test: if you would not use the trigger token at least fifty times, do not train it.

FAQ

Can you train a LoRA on Z-Image Turbo? Yes, but it is not the intended path. Turbo's official model card lists fine-tunability as N/A, because distillation compressed the model's training surface. The AI Toolkit workflow supports it with a separate training adapter file. The simpler route is training on Z-Image base and running the result on Turbo at 8 steps.

What learning rate should I use for a Z-Image Turbo LoRA? Start at 1e-4 and expect to go lower — 5e-5 for tight identity constraints, and lower still if samples look plastic. Anything around 1e-3 melts the subject. Change one variable at a time and judge by samples, not by loss.

How many steps does a Z-Image LoRA need? 3,000 at batch 1 is the reference run for a 15-30 image dataset. Character LoRAs usually peak between 1,000 and 1,500, so checkpoints every 500 steps matter more than the final step count. Larger datasets tolerate, and often need, more steps.

Should I train at 512 or 1024? Both are defensible. 512 trains faster and often produces cleaner composition; 1024 preserves fine texture and text, and matches the published Turbo LoRA config. Validate the concept at 512, then re-run at 1024 if texture is part of the deliverable.

How much VRAM do I need to train a Z-Image LoRA? 12GB works with a low-VRAM configuration — one shared experiment reports about 2.9 seconds per iteration at 2,000 steps on that budget. 16GB removes most of the friction, and 8GB is inference territory unless you accept heavy offloading and 512 resolution.

Does a Z-Image LoRA work with video models? The LoRA affects image generation only. Its practical value for video is upstream: generating consistent stills as first frames for image-to-video models, where identity consistency across clips is the hard part. The image-to-video workflow is where that pays off.

The Bottom Line

The "Z-Image Turbo LoRA" search is a question with a hidden premise. Turbo is the model you run, not the model you train — the official card says so, in a table cell most guides never quote. Train on Z-Image base, keep the learning rate at or below 1e-4, pick your checkpoint from samples rather than from the step counter, and apply the result to Turbo at 8 steps with guidance at the official value.

If you only take one thing: the difference between a melted LoRA and a good one is usually a factor of two in learning rate and a factor of two in stop-early discipline, not a bigger GPU.

And if you want to see what the model does before committing two hours of training, the free Z-Image generator runs it in the browser, no install — enough to decide whether the base model's look is even what you want. For a hosted Wan-based pipeline with its own model stack, Wan 2.7 image-to-video on Pollo is the comparison I would run with the same stills.

Related guides

• Z-Image Turbo GGUF: quant sizes, VRAM and ComfyUI setup
• Z-Image prompt guide: what the model responds to
• Z-Image Turbo FP8 local guide: inference on a budget
• Z-Image Turbo reference images: consistency without training
• Z-Image Turbo fast generation: what 8 steps actually costs

References

• Z-Image-Turbo model card (Tongyi-MAI, Hugging Face) — 6B parameters, S3-DiT architecture, 8-step inference, guidance_scale=0.0, model zoo with fine-tunability listed as N/A
• Z-Image repository (Tongyi-MAI, GitHub) — model variants, Apache 2.0 licence, diffusers quick start
• Z-Image-Turbo in ComfyUI (official docs) — 8 NFE workflow, model file layout, 16GB VRAM guidance
• Training a LoRA for Z-Image Turbo with the Ostris AI Toolkit (Hugging Face) — reference config: training adapter, lr 1e-4 to 5e-5, 3,000 steps, rank 8, checkpoint and sampling intervals
• Training Z-Image LoRA on 12GB VRAM (AI Toolkit issue #550) — learning rate correction to 1e-4-2e-4, 2,000 steps, ~2.9 s/it
• Best Z-Image LoRA training settings (r/comfyui) — 512-only training recommendation and step adjustments for larger datasets
• What is Z-Image and how to train its LoRA (MimicPC) — ~3,000 step baseline and toolkit walkthrough
• Z-Image review: model, licence, setup and Turbo comparison (The Rundown) — base model positioned for CFG, negative prompts, diversity and fine-tuning