Krea 2 Character LoRA Training: A Complete Workflow from Dataset to Epoch Selection

A developer recently shared on Reddit an update to his free Krea 2 character LoRA library — growing from 18 models to 70. More valuable than the sheer number is the complete training workflow he made public. Rather than chasing stunning single-portrait results, this process is built around one core goal: can the character's identity hold up consistently across a wide variety of prompts? It's directly applicable to anyone looking to train their own character LoRAs.

Training Environment & Overall Pipeline

The author chose to run Fizgig on RunPod cloud GPUs for Krea 2 LoRA training, offloading the heavy compute to the cloud rather than local machines. The entire process is broken down into interconnected stages: dataset collection, identity filtering, manual curation, dataset preparation, captioning, training, testing, and final publishing.

Worth noting is how he defines "training complete." In his view, a finished training run does not equal a usable model. If a LoRA's similarity falls short, it gets retrained with a better dataset or a different epoch is selected; models showing significant improvement replace the original or are published as V2. This iterative mindset runs throughout the entire workflow and is key to producing 70 production-ready models.

LoRA (Low-Rank Adaptation) is a parameter-efficient fine-tuning technique originally proposed by Microsoft Research. It injects low-rank matrices into a model to learn new concepts or styles without modifying the original weights. In image generation, LoRA typically trains on top of a frozen base diffusion model (like Stable Diffusion or, here, Krea 2), updating only a small set of additional parameters. Network rank and Alpha are the core hyperparameters controlling LoRA capacity: rank determines the dimensionality of the low-rank matrices — higher means more expressive but also more prone to overfitting; Alpha acts as a scaling factor, with the effective learning rate roughly approximating Alpha / rank, so setting them equal means a scaling ratio of 1. EMA (Exponential Moving Average) smooths model weights over time during training — a coefficient of 0.98 means the current step contributes only 2% to the final result while historical weights contribute 98%, helping reduce late-stage oscillation and achieve more stable convergence.

Dataset Philosophy: Quality and Diversity First

The author repeatedly emphasizes that for character LoRAs, dataset quality and diversity matter far more than image count. His approach is to first collect a candidate pool far larger than what's actually needed, targeting as much variety as possible across angles, expressions, lighting, hairstyles, outfits, and image sources — not stacking dozens of nearly identical photos.

The identity filtering stage uses a reference image with face detection/recognition to remove group photos, look-alikes, and irrelevant images that sneak into search results. However, the author explicitly notes that automation can only do so much — manual review is irreplaceable. He manually removes duplicates, bad crops, over-edited images, heavy occlusions, and low-quality shots.

A practical tip: supplement with face crops. When the dataset contains many half-body or full-body shots, faces become very small once images are scaled to training resolution. Extra face crops ensure that the key features defining identity occupy a larger portion of the image. His stance is clear: he'd rather work with a smaller, clean dataset than pad the count with mediocre images.

The face crop supplementation strategy touches on a fundamental tension between training resolution and feature representation. When a diffusion model trains at a fixed resolution, the entire image is treated equally — in a 0.25MP (roughly 512×512) full-body shot, the face region might occupy only 3–8% of total pixels, resulting in extremely weak gradient signal from facial features. Adding face-focused crops is effectively a way to amplify the signal weight of critical identity features within each batch without changing the resolution. This is why, even when a dataset is primarily composed of half-body or full-body shots, the resulting LoRA can still accurately capture facial details. The same logic applies to other LoRA types requiring fine-grained features, such as hands, tattoos, or specific clothing details.

Fizgig / RunPod Configuration

The author publicly shared the standardized training parameters for this batch, making them highly reproducible:

• Model: Krea 2 Standard
• Training type: Standard LoRA
• Network rank: 32
• Alpha: 32
• Epochs: 64 (checkpoint saved every 4 epochs)
• Batch size: 1
• Target resolution: 0.25 MP
• EMA: 0.98
• Problem image detection: Enabled
• Adaptive learning rate: Disabled
• Auto re-captioning: Disabled

For captioning, Qwen3-VL is used to generate captions that describe the actual image content while keeping the character identity/trigger token consistent across the entire dataset. The author also shares a concrete performance benchmark: an Angel Reese training run completed 64 epochs and 4,416 steps on a cloud GPU in 48 minutes and 46 seconds, producing the final EMA LoRA.

Epoch Selection: The Best Isn't Always the Last

One of the biggest mindset shifts in this workflow is moving away from "X steps = done" toward visual-comparison-based epoch selection. The author saves checkpoints throughout the 64-epoch training run, then generates images from multiple checkpoints for visual comparison — looking for the point where similarity, flexibility, anatomy, and prompt adherence all work together.

He explains the tradeoff: later checkpoints may have stronger similarity but can start overfitting to training data and respond worse to prompts; earlier checkpoints are more flexible but may not have fully learned the identity yet. In the Angel Reese example, he compared epochs 24, 51, and 64, ultimately selecting 64. This is also why models in the browser are labeled "Selected Epoch" rather than a raw step count.

Overfitting in LoRA training manifests differently from classical machine learning. Character LoRA overfitting typically isn't a drop in test set accuracy — it's the model beginning to "memorize" the specific compositions, backgrounds, and outfits from training images, while losing responsiveness to new prompts. For example, inputting "sitting in a café" may still generate the standing pose or specific scene common in the training set. This is why the checkpoint saving strategy matters: saving every 4 epochs produces 16 intermediate states across 64 epochs, providing opportunities to find the optimal balance between "hasn't fully learned the identity yet" and "starting to rote-memorize training images." The methodology of selecting epochs through visual comparison is essentially using human perception as a substitute for traditional validation set metrics — in generative AI, this often aligns much more closely with real-world usage experience.

LoRA Strength Testing & Standardized Validation

The author also doesn't default to using 1.0 strength for every LoRA. After selecting an epoch, he tests at multiple strength values to observe how well the model maintains identity without suppressing the base model or interfering with prompt following. Most models land in the 0.8–1.2 range, but the difference between 1.0 and 1.2 can sometimes be significant — some identities benefit from higher strength, while others degrade when pushed too far. Each LoRA's recommended strength is therefore based on actual generation testing.

To avoid being misled by a single great portrait, he uses standardized testing: validation across portrait, half-body, and full-body compositions, combined with varied outfits, environments, lighting, expressions, camera angles, and more challenging prompts. Full-body generation is especially valuable because it exposes issues that portraits can hide — anatomical errors, body proportion problems, loss of facial identity at distance, or the LoRA attempting to replicate outfits and compositions from training images.

He also plans a controlled experiment: comparing 0.25 MP vs. 0.5 MP training resolution using the exact same dataset and settings, with matched checkpoints, strengths, prompts, and seeds — to determine whether higher resolution delivers meaningful improvements in similarity and detail, or whether 0.25 MP is already sufficient with the added benefit of faster training.

In-House Dataset Preparation Tools

The project has spawned an in-house dataset preparation pipeline that automates much of the pre-training work: collecting candidate images from multiple sources, filtering identities using a reference face, removing obviously problematic images, generating face crops, preparing dataset structure, generating captions, and running validation before the dataset enters the trainer. The author emphasizes that this tooling is not a prerequisite for following his workflow — Fizgig itself can handle many of the same data preparation functions. The tools are currently used internally, but the team is considering cleaning them up, packaging them, documenting them, and open-sourcing them if there's sufficient demand.

The author closes with a restatement of responsible AI use principles: users are responsible for how they use generated content and must comply with applicable laws, platform policies, and the rights of others. These models must not be used to deceive, impersonate, harass, defame, or harm anyone, and generated content must not be passed off as real photos or recordings of actual people. All LoRAs will continue to be released for free, with Ko-fi supporters receiving priority on the request queue.

Fizgig is a LoRA training frontend tool designed specifically for Krea-series models, running on cloud GPU platforms like RunPod. It wraps dataset preprocessing, training scheduling, and checkpoint management, lowering the technical barrier compared to working directly with underlying training frameworks like kohya_ss. RunPod is an on-demand cloud GPU rental platform for AI workloads — users can rent high-end GPUs like A100s and H100s by the hour, avoiding the high upfront cost of local hardware. Given that the 64-epoch, 4,416-step training run described here completed in about 50 minutes, the cloud cost per training session typically amounts to just a few dollars. This combination of cloud GPU plus a dedicated frontend enables individual developers to run large-scale batch training experiments without deep infrastructure knowledge — making it one of the most common working setups for independent LoRA creators today.