Style LoRA Training: What It Actually Takes

By Mark Nguyen · August 2026

A client came to us with a library of flat vector illustrations they’d built up over several years. The work was consistent: same line weight, same palette, same drawing conventions. They needed to keep making more of it, but they didn’t want every new lesson to have to go back through the original illustrator.

So we trained a Qwen Image LoRA on the artwork they already had.

The interesting thing about style LoRA training is that the actual training turned out to be the easy part. This is the full record of that build, including the images we threw away and the base model we abandoned two days before training. We sell custom model training, so keep that in mind when looking at the costs. The actual training bill was $3.00, but that turned out to be one of the least interesting numbers in the project.

Style LoRA training: the headline numbers

• 82 source illustrations delivered by the client
• 65 used, after a filtering pass that dropped 17
• 65 captions written by hand, one per image, zero auto-generated
• 1,500 training steps on fal-ai/qwen-image-trainer
• $3.00 in training spend, at $0.002 per step
• ~1 hour wall clock, a meaningful share of it queue time
• 562 MB trained adapter, delivered as a portable .safetensors file
• ~$3.42 total project spend including evaluation generations

Those numbers make the project look almost absurdly cheap. In terms of raw compute, it was. But the $3 training run wasn’t really the project.

The $3 isn’t the project

Training compute cost three dollars. Preparing the dataset took most of a working day, and the licensing research changed which model we ended up using.

That’s the part that gets lost when people talk about how cheap it is to train a LoRA. If someone quotes one of these projects based on GPU cost, they’re quoting the wrong part of the work.

We’ve seen the same thing across every Style LoRA Training project we’ve built. The actual model training is mostly a commodity step at this point. The work is figuring out what should go into the training set, what shouldn’t, how the images should be described, and whether the resulting model can actually be used the way the client expects to use it.

In this case, we started with 82 images. We didn’t train on 82.

We dropped 17 of 82 images before training anything

The client’s folder wasn’t a training set. It was a working art library, which is a different thing.

Before we trained anything, we went through all 82 images and removed the ones that were likely to hurt the result.

Reason dropped	Count
Near-duplicates	7
Off-style one-offs	4
Blank or near-blank templates	3
Too small to upscale (145 x 145 px)	3

The four off-style images were the interesting ones. They were legitimate client artwork, but they weren’t really part of the visual system we were trying to reproduce. A few abstract shapes, some stray graphics, things that had made their way into the library over the years.

If you have 10,000 training images, four oddballs probably don’t matter. When you have 82, they’re five percent of everything the model is going to see. That’s enough to start pulling the learned style in a direction you don’t want.

We ended up with 65 images. We upscaled each one so its shortest side was at least 1024 px using LANCZOS resampling, which matched the base model’s native training resolution. Training a 1024 px model on 512 px source doesn’t really save you anything. You’re just teaching the model that the client’s style is a little soft.

How many images do you need to train a LoRA?

For a style LoRA, we’ve found that 40 to 80 well-captioned, on-style images at 1024 px or better is a good range. We used 65 here, and it was enough.

More isn’t automatically better. I’d take a carefully selected set of 50 over an unfiltered set of 300. With a style LoRA, the problem isn’t always that you don’t have enough examples. It’s that you’ve given the model too many examples of things you don’t actually want it to learn.

That was also why we spent as much time on captions as we did on the images themselves.

Every caption was written by hand, because the filenames had typos in them

These are real filenames from the folder we received: environemnet, pruple, exicted, ired, yellw, appy.

A lot of LoRA training pipelines will auto-caption images or use filenames as part of the process. That would’ve been a bad idea here. If pruple gets treated as a meaningful token, the model can start associating it with whatever happened to be in that image. You’ve now created a private vocabulary by accident.

So we ignored the filenames as a source of meaning and captioned the images ourselves.

The basic pattern was:

[trigger], [subject + action + key visual details], flat vector illustration on white background

For environment scenes, we ended with flat vector illustration scene, because there wasn’t a white background to describe.

Two things mattered.

The trigger word came first in every caption. We used a short invented token with no existing meaning in the base model’s vocabulary. You don’t want to use something like flat, vector, or even the client’s brand name if the model already has strong associations with that word. You’re making the training compete with concepts the model already knows.

The subject changed, but the style description didn’t. That’s how you give the model a chance to separate style from subject. If you show it twenty illustrations of children and keep repeating “child” in every caption, the trigger can start picking up the idea of a child along with the visual style.

That’s one of the easiest ways to think you trained a style LoRA when what you really trained was partly a subject LoRA.

How to caption images for LoRA training

• One .txt file per image, matching filename
• Trigger token first, in every caption, without exception
• Describe the subject, the action, and only the visual details that distinguish this image from its neighbors
• Use identical wording for the style descriptor across the entire set
• Never caption from filenames
• Never ship auto-captioner output on a set this small without reading every line

At 65 images, captioning by hand is an afternoon. It’s not some huge bottleneck in the process, and it gives you a chance to actually look at every image you’re about to train on.

We had the dataset ready at that point. Then we changed the model.

The licensing check changed our base model two days before the run

We originally planned to train a Flux LoRA on Flux.1 [dev]. The endpoints are mature, the LoRA ecosystem is huge, and the output is strong. We’d already packaged the dataset for it.

Then we got deeper into the licensing.

Flux.1 [dev] isn’t licensed for commercial use out of the box. If you generate through a hosted provider that has its own commercial arrangement with Black Forest Labs, that’s covered. If you download the weights and self-host them to serve a paying client, it isn’t. That requires a separate paid license starting in the four-figures-per-month range.

That probably doesn’t matter the day you launch. It matters a lot more a year or two later when the client decides they want generation running behind their own firewall and discovers that the model you built around comes with a recurring license fee nobody talked about at kickoff.

The technical work would’ve been basically the same. The commercial position wouldn’t have been.

SDXL was the obvious fallback, but that created a different problem. Our training platform had dropped first-party SDXL LoRA training, which meant splitting the pipeline across two providers just for one step in the middle.

We ended up using Qwen-Image, which is released under Apache 2.0. It can be self-hosted commercially, indefinitely, with no revenue cap, no enterprise agreement, and no per-image fee.

Three things made it a good fit for this project:

1. Output quality is competitive with Flux for stylized illustration. Photorealism is a different discussion, but for this kind of flat vector work there wasn’t a meaningful gap.
2. Qwen renders legible in-image text unusually well. Some of the client’s artwork was printable classroom material with words in it, and most image models still have a tendency to turn text into visual noise.
3. One platform handled both training and inference, so we didn’t have to split the workflow.

The bigger takeaway for us was that the license mattered more than whichever benchmark happened to be getting attention that month. You’re not just choosing the model that works today. You’re choosing what the client is going to be able to do with it later.

We came to a similar conclusion from another direction when we looked at the legal gray areas around building on Kimi.

Training the Qwen Image LoRA: 1,500 steps, $3.00, about an hour

Once we settled on Qwen-Image, the actual style LoRA training was straightforward.

Setting	Value
Base model	Qwen-Image (Apache 2.0)
Dataset	65 images, 1024 px minimum, paired captions
Steps	1,500
Learning rate	0.0005 (trainer default)
Style handling	No trainer toggle; conveyed entirely through captions
Cost	$3.00 at $0.002 per step
Wall clock	~1 hour including queue
Output	562 MB .safetensors adapter plus a config file

How long does LoRA training take?

This run took roughly an hour on hosted infrastructure for 1,500 steps against 65 images, and a meaningful amount of that time was just waiting in the queue. On a local consumer GPU, you’re looking at several hours.

For us, the reason to use hosted training wasn’t really speed. It was not having to care about CUDA versions, dependencies, drivers, and whatever else decides to break that day.

For $3.00, I’m happy to let that be somebody else’s problem.

But finishing the training run didn’t mean we were done. We still needed to figure out whether the thing actually worked.

Ten prompts, two seeds each, scored against a threshold set in advance

One good generation doesn’t tell you much. A LoRA can nail the first prompt and fall apart as soon as you ask it to do something that wasn’t heavily represented in the training set.

Before generating anything, we wrote ten evaluation prompts. Each one was meant to push on a specific weak point:

1. A new character doing an everyday routine, testing whether style transferred off the training subjects
2. Wheelchair representation in a pose absent from training
3. An emotion the training set never contained
4. A multi-character scene, where composition breaks first
5. A fine-motor daily-living action, testing hands
6. A single object on white, testing background cleanliness
7. A small assistive-device detail
8. A chart containing literal text, testing text rendering
9. An environment with no characters
10. A combined action-plus-object prompt

Each prompt generates twice at different seeds, at 1024 x 1024, starting at a LoRA scale of 1.0. We score the output across five areas: style match, anatomy, subject accuracy, background cleanliness, and inclusivity rendering.

We also decided what counted as passing before we looked at the output.

An average of 3.5 or better across the set ships. Anything below 3.0 means we retrain or change the base model.

That matters because once you’ve spent most of a day cleaning and captioning a dataset, you’re not exactly an unbiased reviewer anymore. It’s very easy to look at a mediocre result and convince yourself it’s close enough.

We wrote down the fallback options at the same time. If quality holds, ship on hosted inference. If the client needs full data isolation, self-host Qwen-Image and the adapter on a private GPU, which Apache 2.0 permits at no cost. If quality falls short, train a Flux LoRA using the exact same dataset for about $4 more, A/B the two, and ship the winner. If the style is close but still a little soft, retrain at 2,000 to 2,500 steps or expand the dataset.

The point was to know what we were going to do before seeing the results. Otherwise it’s very easy to spend three weeks tweaking things without ever defining what you’re actually trying to fix.

What this style LoRA training project can’t tell you

There are some limits to what we can say from one project.

• We haven’t published the evaluation scores yet. The rubric and threshold were set in advance, but we want to validate the results before putting those numbers in print.
• 65 images covers the style, not the subject space. At this size, the LoRA can reproduce the visual grammar reliably, but it still has thin priors for subjects and poses that never appeared in the training set. That’s why four of the ten evaluation prompts deliberately ask for things that weren’t there. If the client starts needing a lot of new subject matter, we’d expand the dataset rather than simply rerun the same training set.
• One dataset, one style. Flat vector illustration with clean backgrounds is about as friendly a case as you can ask for. Painterly work, photoreal humans, and complex lighting are harder. I wouldn’t take the numbers from this project and assume they’ll carry over.
• We did not A/B against Flux. Once the licensing analysis made Qwen the better commercial choice, we didn’t see much reason to run the comparison. So I can’t tell you which one would’ve produced better output. I can tell you that one of them was licensed for the way the client might eventually need to use it.
• We sell this service. The $3 training figure is accurate. It’s also the number that makes the project sound dramatically cheaper than it really is. The day spent preparing the dataset is the part that ends up on an invoice.

What we’d do with these numbers

There are a few things from this project I’d carry directly into the next style LoRA training job.

Check the license early. It’s one of the few decisions in this process that can become expensive to change after the model has already been delivered, and it takes about twenty minutes to figure out.

Budget for the dataset work, not the GPU. Compute was basically a rounding error here. The real work was auditing, cleaning, captioning, and evaluating the data.

Set the pass threshold before you generate. Otherwise you’re judging your own work after you’ve already invested time in it, which makes “close enough” very tempting.

Treat the model URL like a credential. The download link most training platforms give you is an unauthenticated CDN URL, and it usually expires in about seven days. Archive the file locally on day one, keep the link out of Slack and Jira, and put a small server-side wrapper in front of it so the key and URL never make it into the browser.

Put ownership in the SOW. “We trained you a model” and “you own the model” aren’t the same sentence, even though most clients will understandably assume they are. A trained adapter is a portable file that can run on any GPU, so there isn’t much reason to leave ownership vague.

When style LoRA training is the wrong answer

A style LoRA makes sense when you have at least 40 usable, on-style images, the style is consistent enough to describe in a sentence, the content need is ongoing rather than a one-off batch, and somebody is going to review the output.

It’s a drafting tool. It isn’t an unattended publishing pipeline.

It’s also probably the wrong answer if the “style” is really just a color palette, if the entire library is fifteen images, or if the requirement is photoreal humans. Those are different problems, and we’d rather figure that out before the engagement than after it.

What actually mattered in this LoRA project

The training itself took about an hour and cost $3.00. We spent ~ $3.42 total including the evaluation generations. Those are the numbers that are easiest to put in a headline, but they aren’t where most of the work happened.

We started with 82 illustrations and used 65. We captioned all 65 by hand. We changed base models because of licensing. We set the evaluation criteria before looking at the outputs. The final adapter was 562 MB and portable as a .safetensors file.

That’s a better picture of what style LoRA training actually looks like. The GPU run is one step in the middle. Most of the decisions that determine whether the project works happen before and after it.

---

If you already have a visual library and an ongoing need to produce more content from it, custom LLM and model development is where this kind of work fits. If you’re earlier in the process and still trying to decide whether a custom model makes sense at all, AI consulting and strategy is probably the shorter conversation. You can also see more of this kind of work in our work.

Client details in this article have been anonymized.

By Mark Nguyen · August 2026