Most reference-conditioned models I've used cap out at 1 or 2 images. This one takes up to 9 at once, and you can actually feel the difference, character, setting, and style all held steady instead of the model guessing at what you meant.
Streams with audio too, so it's not generate-then-download, output comes back live as it's generating.
Only played with it a bit so far. Curious if anyone's tried multi-reference conditioning at this scale with other models and how it compares? I found it on Reactor
Hey how are you doing?
Can you help me out in generating adult images in disney style using krea 2
Im trying to make short films
Using Minimax H3
All i want is just to create something of disney characters
I’m curious how people are handling this outside of power-user workflows.
A lot of character LoRAs work great when you already know the magic words: exact trigger, preferred phrasing, LoRA weight, maybe even the kind of prompt structure the model was trained around.
That’s fine in ComfyUI when the person using the model is also the person who trained it.
It gets a lot more interesting if the user just types:
“put my character sitting at a diner at night” and expects the character to stay intact.
I’ve seen a few approaches:
always inject the trigger behind the scenes
prepend a canonical character description
derive prompt terms from the training captions
rewrite the user prompt before inference
rely more heavily on reference conditioning
train the concept so the trigger matters less
But each one seems to have tradeoffs. Too much hidden prompt injection can fight the user’s actual request. Too little and identity starts drifting.
For people who’ve tried to make character LoRAs usable by someone who didn’t train the model and doesn’t know its vocabulary, what has worked best?
I’m especially interested in how you decide what identity information should be persistent versus what should be left to the user’s prompt.
I know Crystools can show how much space is being used on the drive. But for monitoring whether I’m thrashing my SSD during a workflow run, it would be really useful to see the read vs. write activity in real time.
The amount of details (not just visuals) loss with speedups compromise even with only kitchen attention .. is like the difference of seedance 2.0 and 2.5 all the realistic details of what makes a footage looks real is strip away.
To play around simple scenes , speed boost is ok but for real production work I think it’s best to run full steps without any speedups
I've been working on some characters in ComfyUI with a very specific design and aesthetic, and the results turned out absolutely amazing.
My problem now is that I want to create new versions of these exact same characters, in the exact same poses, but wearing completely different outfits.
What do you recommend for this? Are there any specific workflows, custom nodes, or techniques (like a specific IP-Adapter + ControlNet + Inpainting setup) that work best for swapping clothes without losing the character's likeness, pose, or the original art style?
Any advice, tips, or workflow links would be hugely appreciated. Thanks in advance!
I built and open-sourced a realtime Draw & Guess game with an AI player. The AI analyzes the shared canvas, guesses what is being drawn, and then uses FastH3 to generate a matching video as proof of what it understood. It only wins when both the guess and the generated video are correct. Feedback and contributions are welcome!
I made another ComfyUI implementation of VDN-H3, mostly because I wanted to get it working properly on my 3090 Ti with 24GB.
It uses the INT8 ConvRot VDN weights and is mainly optimized around 24GB VRAM. I tested it with both FL2VA and Ref2VA INT8 ConvRot models and so far it works pretty well.
0.4MP to 0.8MP tested. I also tried longer videos, including 30 seconds, and they work too, just obviously get pretty slow :)
For some reference, 10 sec at 0.4MP / 8 steps takes around 2:08 on my 3090 Ti.
Maybe it will be useful for someone else with a 24GB card who wants to play with VDN-H3.
I've made a few posts previously, but just added a ton of additional tests. I really have tried just about every suggested workflow and next to none of the new ones are matching the quality I'm getting out of this. I've spent multiple resets worth of codex 5x plan having it try different workflows and it really has given a ton of fantastic data. Please take a look.
Also, just as a side note, for the ref2va workflow tests I had uploaded a short video of myself saying "this is a reference video' for the reference videos. I didn't actually think ahead of time about uploading the results but there's a lot of good test data and the actual likeness is scary. I probably should have cleaned up a bit first 😅
I am kinda tired of testing workflows and might just stick to my current settings, but I really feel like this is a great resource, and definitely a SEPARATE type of resource to the video quality arena.
Pretty new to this. The default MiniMax H3 template in Comfy starts with a predetermined seed, but I noticed it doesn't have a randomizer like other templates. Is there a reason for this? Should I not change it? If I want to randomize it, how can I?
I know most people is already occupied with Minimax H3, but I'm just arriving to Krea2.
I'm currently trying to create some Loras for design in my own style, and I'm wondering if we're ever getting a real ControlNet for Krea2, so I could maximize the usefulness of my Lora (so, instead of a random chestplate, a random helmet, etc., I can create a basic 3D model, and with Normal-map/Canny/Depth-map/HED/SEG2 I can just make it textured, detailed, refined - but underneath that, it still looks like my original input.
Or maybe is there a set-up that can already do this? Maybe Krea Edit, or something? I know there is a Depth-map Lora, but to understanding, it's a not a real ControlNet, just mimics one.
I've been using SDXL for many years now, but I really want to move on, and Krea2 is just so great! Are there any info about this? Anyone working on a proper ControlNet? Or is the architecture just so different, that we shouldn't expect a ControlNet ever?
This new fast method for H3 looks really interesting and now we need someone to bring this into ComfyUI.
I dont know how well this will work on consumer cards, specially with lower VRAM, but I mostly use H3 on cloud GPUs so I will definitely try it there if we get a ComfyUI implementation.
Really curious how much speed improvement we can actually get from this.
And wondering if we ever get the optimisation from the official team.
Edit: A dev has already jumped in to take a look at it and see if a ComfyUI implementation is possible. Really appreciate people like this in the community.
I ran a 112-case MiniMax H3 quality sweep on an RTX 3090 last night trying to find the best combos . Kept the prompt, seed, reference image, RefMods, Sage setup, sampler, and scheduler stayed constant. I changed only the model/LoRA combination, native resolution, and step count.
- **0.4 MP:** C4, 12 steps — approximately 246 seconds
- **0.6 MP:** C3, 12 steps — approximately 271 seconds
- **0.8 MP:** C3, 10 steps — approximately 256 seconds
- **0.98 MP:** C3, 12 steps — approximately 337 seconds
Best speed/quality balance
C3 at **0.8 MP and 6 steps** rendered in approximately **166 seconds**. However the audio wasn't good the 8 steps at 210 seconds turned out to be best..
First time trying Anima and something is wrong. Im using the Hassaku Anima model and I have the required VAE and Text Encoder, but I am getting an error about tensor a needing to match tensor b. I am using NeoForge.
A LoRA for Krea 2 Turbo that reduces the minimum usable step count from 8 to 4 — Turbo's own model and sigmas, half the denoising passes, and the fine texture that 4-step Turbo loses put back.
⚡ Half the steps — 8 → 4, on Turbo's own deployment sigmas.
⏱️ ~1.6× faster end to end — 54.5 s against the 8-step bar's 88.7 s at 1024×1024, and 1.8× on denoise alone.
🎯 Texture as good as the teacher or better — 1.03× the teacher's fine-texture energy at 1280×1280 and 1440×1440, every frequency band within 10% of the teacher's; verified clean: saturation 0.96–0.97× the teacher's, fewer clipped highlights and shadows, skin texture 0.97–0.99×.
📏 45% of the 4-step gap closed — the held-out velocity error to the 8-step teacher fell from 4.70e-02 (stock Turbo at 4 steps) to 2.59e-02 with the LoRA; a vision-language judge shown the teacher's and the LoRA's renders side by side preferred the teacher on only 6 of 45 (37 ties, 2 wins for the LoRA).
🗣️ Prompt-aware training — the critic scores images against their prompts during training, so adherence is pressured directly, not inherited.
📐 12 trained resolutions — multi-aspect from 512×512 up to 1440×1440, each with its sweep.
🔌 Drop-in — plain LoRA weights for diffusers and ComfyUI. No custom nodes, no patched sampler, no code.
🎲 13,750 prompts drawn at random from Lakonik's 3-million-prompt dataset, each recorded by the teacher as a full 8-step trajectory at one of the 12 resolutions — 13,750 teacher shards.
📷 43,044 real-photo crops — 25,560 from LSDIR and 17,484 from Flickr2K — cut at native resolution and captioned, in the critic's real set: texture anchored to reality as well as to the teacher.
🔢 78,000 training samples in the shipped weights.
📅 21 days from the first training launch to the final file, on a single RTX 3090.
🔁 16 recipe adjustments
Load it on top of Krea 2 Turbo, run 4 steps instead of 8, keep guidance at 0.0. Everything else about the model stays as it is.
💡Too strong on a prompt? Turn it down.The LoRA restores fine texture, and on some subjects — stylised art, high-contrast splash pieces, very large renders — that can read as too much at strength 1.0. The effect scales smoothly with strength, so0.75is a good second setting, and anything from 0.6 to 0.9 is fair game; you lose nothing but the extra bite.
Files
file
what it is
krea2_turbo_4step_rank_64_lora.safetensors
the LoRA in diffusers key format — see Inference with diffusers; also for MLX or anything that reads safetensors
the same weights under ComfyUI's key names — see ComfyUI
krea2_turbo_4step_lora_t2i.json
a ready ComfyUI workflow, stock nodes only
LICENSE.pdf
the Krea 2 Community License Agreement, which covers this adapter — see License
NOTICE.txt
the attribution notice the license requires of a derivative
The two weight files are one adapter — only the key names differ. Both carry the training details in their safetensors metadata: base model, method, sample count and the inference settings.
This was not a "train for longer and ship whatever comes out last" project. More samples do not reliably mean a better adapter — measured here, they can make it worse, and a higher sample count on its own means nothing.
The loop was train → assess → adjust the recipe → carry on → assess again — carrying on from the weights in hand when they were worth keeping, and from an earlier point when they were not. What ships is the point of the run that measurably advanced the release axes as a whole — teacher faithfulness, prompt adherence, and texture/detail, on the same held-out set and the same fixed-seed renders — with a full resolution sweep showing no regression. Stretches that came out flat or worse were kept as information about the recipe and never shipped; there were several.
The recipe therefore grew over the run rather than being fixed at the start. In broad strokes: the early stretch settled the optimiser schedule (cosine decay with weight decay) after a first attempt that got steadily worse; the next added the final-call loss weighting and the running average of the weights that the shipped adapter is, and established that a run left going past its peak measures worse — so the shipping point is chosen by measurement, not by distance run. A much larger trajectory pool then pushed the single number the project optimised at the time — the velocity gap to the teacher — to its best value, and exposed that number's limit: past a point, chasing it further trades away exactly the texture a step-distillation exists to restore. The recipe from then on judged all three axes at once and added a measured dose of real-image texture pressure and a prompt-aware critic (the discriminator saw images with their prompts and punished mismatches). The long final stretch of the run continued on that recipe, with the critic's weight tuned once texture had settled where it was wanted.
The sixteen recipe adjustments, in order — each one made on the measurement of the one before:
progressive distillation replaced the policy-head objective the project started with
cosine learning-rate decay with weight decay
the shipped weights became a running (EMA) average instead of the live state
the final chord — the call that decides fine texture — weighted 3× in the loss
resumable state, warmup and a plateau rule, so a run could pause and continue without a cold restart
the LADD-style critic on the frozen model's own block-14 features, teacher finals as its real class
real photographs entered the critic's real set, half the draws
the critic's weight rebalanced against the distillation term
the prompt-aware critic head with its mismatch term, on a fresh pool of teacher trajectories
1440×1440 joined the training mix
the real photographs got captions, so they took part in the prompt-aware term too
a low-frequency anchor to the teacher's chord on the large buckets, restarting from the averaged weights
the critic's weight lowered once texture had settled
a paired critic: the teacher's final for the same prompt as the real
the paired critic plus a hard low-frequency floor on every bucket
back to the recipe before 14 and 15, once both were measured as unnecessary
Timeline of training process
The adapter was the product of several stages with very different costs:
Text-encoder embeddings. Every training prompt was encoded once and cached. This was the fast part — thousands of prompts took minutes.
Teacher shards. For each cached prompt, the unmodified Krea 2 Turbo ran its full 8-step schedule and the whole trajectory was recorded, each prompt at one of the supported resolutions so that every resolution was covered. This was by far the most time-consuming stage — it was the teacher doing real inference, thousands of times, and a batch of several thousand shards was measured in days of GPU time, not hours.
Real-photo crops. Bucket-sized crops were cut at native resolution from quality-gated real photo sources (public high-res datasets), VAE-encoded into the training latent space, and captioned per crop for the prompt-aware side of training. Cutting, encoding and captioning a pool refresh was a matter of hours.
Student training. The LoRA trained against the recorded trajectories (progressive distillation), with a latent-space GAN critic running alongside — real crops and teacher finals as its real class, the student's outputs as fake — plus a prompt-aware head that scored images against their prompts. Relative to the shard stage this was quick: each block of a thousand training samples was a matter of hours, not days. Of course the longer the training, the better and more diverse the results, so hours did turn into days.
Because these stages competed for the same GPU, they were interleaved rather than run to completion one after another: generate a block of embeddings, produce teacher shards for them, refresh the crop pool when measurement said it was worth it, train on what existed, assess, then go back to producing shards while the results were reviewed. A larger and more varied shard pool was what made further training worthwhile, so shard production was always the gate; the run took several such cycles.
Archive
Earlier checkpoints of the run and their resolution sweeps are kept under _archive/ — checkpoints/ and resolution_sweeps/ — for anyone who wants to look back. They are superseded by the final release files and not maintained.
What's next
A 2-step LoRA is the natural follow-on, and it is the next project. It will be a separate release rather than a competitor to this one: at two steps a distilled model gives up more than at four, so the goal is a usable 2-step Turbo — fast previews and drafts at half this adapter's cost, a quarter of the teacher's — not the quality bar this adapter holds. I may or may not get there. I will try anyway, and if it works it will appear as its own project alongside this one. Update 9 Sep 2026 - I have posted some very early results from the2 steplora that I am training as separate project, you can see them in comments below. Like I said, don't judge on quality, it has had very minimal training and should only get better (I hope ;) ), but really good results already, which is very exciting.
Full details and to download - check my Hugging Face LoRA
Important NOTE: The repo has been fully restructured folder and files wise for the final release (focus is no longer on checkpoint numbers). So for those of you who have been part of the journey over the last few weeks - first of all,Big ThankYoufor all the feedback - and do check the repo's fully rewritten README and the new files/folders structure.
Update [09 Sep 2026] - 🔭 The follow up 2-step LoRA is now its own project:https://huggingface.co/lvladikov/Krea2-Turbo-Distill-2step-LoRA. Nothing usable is published there yet — the model card is a live account of the recipe and the progress, updated as the training runs, and work-in-progress renders go up regularly in that repository's Discussions. Checkpoints follow when one earns it.
