Training your own FLUX checkpoint takes four things: a dataset curated hard enough to hurt, captions that tell the model exactly what to learn, a fixed eval suite you run before and after every change, and enough GPU time to iterate past your first bad ideas, and everything after that is a hyperparameter. I’ve shipped twelve versions of Nepotism, my FLUX.1 checkpoint family, and that short list is what actually moved quality.
I publish as BobsBlazed on Civitai, where Nepotism has run from version I through XII. The training pool for Nepotism XII hit 8.5 million images, and the final version logged 124+ epochs and 2.1 million+ steps, all on GPUs I own. I’ve also shipped Tenos v1.25, a 12B FLUX finetune on HuggingFace under Tenos-ai, plus Brainwashed on the SDXL side. The rest of my model work lives on my studio page.
What follows is the playbook I had to work out myself between version I and version XII.
How do you curate a dataset for FLUX training?
Curation beats scale at every size I could afford, and I could afford more than most. Nepotism XII drew from 8.5 million images, but the quality jumps never came from adding more. They came from what I refused to let in. A few hundred bad images removed did more for outputs than any hyperparameter sweep I ever ran. Anything with tangled hands, mushy backgrounds, or watermark ghosts taught the model that those were acceptable answers.
Models end up learning your tolerance rather than your intention.
That’s the whole theory of dataset curation for diffusion model training in one line, because the dataset is the spec. My working rules:
- If you wouldn’t be happy seeing the model output it, it doesn’t go in. No exceptions for “but the composition is nice.”
- Dedupe hard. Near-duplicates quietly overweight whatever they contain.
- Cut by failure mode, not by folder. “Bad hands” is a category you can empty. “Portraits, misc” is a category you’ll argue with forever.
- Re-audit old data every version. My standards rose between Nepotism I and XII, so images that survived early cuts didn’t survive later ones.
Nobody wants to be the person who deletes training data, and that person ships the better model anyway.
How should you caption images for FLUX finetuning?
FLUX reads prompts through a T5 text encoder alongside CLIP, and it rewards plain, literal prose over tag soup, so caption the way you want people to prompt. What worked for me:
- Describe what you want to control at prompt time. Anything you want baked into default behavior, leave out of the captions.
- Keep vocabulary consistent. If one caption says “soft window light” and another says “diffused natural lighting” for the same look, you’ve split one concept into two weak ones.
- Describe, don’t review. “A beautiful, stunning photo” teaches the model nothing. “A woman in a red coat crossing a wet street at dusk, shot from hip height” teaches it plenty.
- Caption the boring stuff. Backgrounds, framing, lens height, lighting direction. The model can’t separate concepts you never name.
At multi-million image scale, captioning is obviously not a by-hand job. Automate the first pass, then spot-check like you’re paid per error you catch.
Why do you need a fixed eval suite before training?
Eyeballing a grid of samples will not catch a regression. One of my versions got noticeably better at portraits while quietly losing the ability to draw a straight roofline, and only a pinned eval suite surfaced it.
Every release since gets the same treatment: a fixed prompt suite with pinned seeds, pinned samplers, and pinned step counts, rendered before and after any change to the weights, with everything held identical except the model itself. If the comparison isn’t pinned you are grading impressions, and impressions always favor the thing you just spent three days training.
Build the suite before your first run and render it on the base model, because that render is your baseline. Cover the subjects you care about and the subjects you think you don’t, because the second group is where regressions hide. Portraits improving while architecture degrades isn’t hypothetical, it’s the exact trade I caught happening.
Training your own checkpoint is 90% custodial work and 10% watching a progress bar, because the run itself is the easy part. The model people actually want gets made in the unglamorous hours around it: pruning the dataset again, tightening captions, rendering eval grids, and writing release notes. It is maintenance work, and it is also the difference between a checkpoint someone downloads once and one they build workflows on for a year.
How do you version a checkpoint family?
Nepotism ran I through XII in Roman numerals, partly for the brand and partly because it made the release history easy to follow. The numerals weren’t what kept it honest though, the changelog was - every release stated what changed, what improved, what broke, and what to expect from prompts people already relied on.
That sounds obvious until you notice how much of the ecosystem ships final_v3 (2).safetensors. When thousands of strangers build on your weights, a version is a promise. Half the trust Nepotism earned came from boring release notes. I kept the same rules for Tenos v1.25 on HuggingFace and for Brainwashed on SDXL, because the discipline transfers to any architecture.
Version your inputs alongside the weights, so dataset snapshots and training configs get tagged to the release they produced. When someone reports a quirk in an old version, “what data did it see?” deserves an answer, not archaeology.
What hardware do you need to train FLUX locally?
If you want to train your own image model locally, the spec sheet is the smallest problem. FLUX.1 dev is a 12B parameter model, so full finetunes are a serious commitment, while LoRA training fits on a single high-VRAM consumer card if you’re patient with quantization and offloading. Rent cloud compute if you’d rather, since I train on my own GPUs for reasons that have nothing to do with romance.
Local hardware keeps you honest in a way rented compute doesn’t. Every experiment has a visible cost in heat, hours, and electricity, so you plan the run, define success before you press go, and kill failing runs early instead of letting them ride because the meter is somebody else’s problem. I’ve kept that habit even when compute is someone else’s line item: exit criteria first, then spend.
Tooling matters as much as silicon. Running training scripts, samplers, and eval renders across a dozen terminal windows stopped being workable, so I built Bobs Studio, a desktop app that supports 20+ model architectures and runs my daily loop. It started as a personal itch and became the tool I open every morning. Build or adopt something like it before the pipeline sprawls across too many tools.
How do you publish and distribute a checkpoint?
Shipping is its own skill, and it’s where most trained models die quietly. What worked for Nepotism:
- Post honest samples with full generation parameters. Everyone cherry-picks; at least pick from a representative tree and let people reproduce your exact images.
- Write release notes like people depend on them, because they do.
- Read the base model’s license before you publish, not after. FLUX.1 dev ships with usage terms, and “I didn’t read it” is not a defense.
- Mirror where your users already are. Nepotism lives on Civitai under BobsBlazed, and the SeaArt, Tungsten, and PromptHero mirrors reached people Civitai never would - that’s how the family’s download total passed 35,000.
- Answer comments. The stranger reporting that your model draws six-fingered bassists is doing free QA.
Publishing openly compounds in ways you can’t schedule. The Nepotism work led to a talk at the Symposium on Visual GenAI, which I did not see coming when I uploaded version I. Weights travel further than you expect.
Pre-flight checklist before your first FLUX training run
- Write your success criteria in one sentence before you spend a single GPU hour.
- Curate the dataset, then cut deeper. The worst image you keep sets your floor.
- Dedupe, and hunt near-duplicates specifically.
- Standardize caption vocabulary and describe what you want to control.
- Build the fixed eval suite: prompts, seeds, samplers, and step counts, all pinned.
- Render that suite on the base model first. That’s your baseline.
- Snapshot the dataset and config so every run is reproducible.
- Set kill criteria now. Decide what makes you stop a run early.
- Check the base model license if you ever plan to publish.
- Draft the release notes template. Future you is lazier than current you.
FAQ
How many images do you need to finetune FLUX?
Depends entirely on the job. A narrow style LoRA can work with under a hundred well-captioned images. A general-purpose checkpoint is a different sport: Nepotism XII drew on 8.5 million images across 124+ epochs. Either way, the count matters less than the worst image you keep.
Can you train a FLUX checkpoint on a single consumer GPU?
You can train LoRAs on one high-VRAM consumer card with quantization and patience. Full finetunes of a 12B model want much more, in VRAM or in offloading tricks that turn days into weeks. I run my own local GPUs and still plan every run like it costs real money, because it does.
Should you train a LoRA or a full checkpoint?
Start with a LoRA. It’s cheaper and faster to iterate, and it covers most style and subject work. Go full checkpoint when you need to move the model’s baseline behavior, the stuff a low-rank adapter can’t reach. Nepotism went the checkpoint route because I wanted the defaults themselves to change.
What tools did you use to train and test Nepotism?
My own GPUs and my own software. Bobs Studio runs my daily loop across 20+ architectures, and my fixed-seed eval workflow lives inside it, so before-and-after comparisons are routine instead of a ritual.
Where can you download Nepotism?
On Civitai under my BobsBlazed account, with mirrors on SeaArt, Tungsten, and PromptHero if one of those is home for you. Tenos v1.25, my 12B FLUX finetune, is on HuggingFace under Tenos-ai. Bring your own eval prompts and tell me what breaks.