[HN Gopher] Releasing open weights for FLUX.1 Krea
___________________________________________________________________
Releasing open weights for FLUX.1 Krea
Author : vmatsiiako
Score : 144 points
Date : 2025-07-31 13:41 UTC (9 hours ago)
(HTM) web link (www.krea.ai)
(TXT) w3m dump (www.krea.ai)
| dvrp wrote:
| Hello everyone.
|
| I'm the Co-founder and CTO of Krea. We're excited because we
| wanted to release the weights for our model and share it with the
| HN community for a long time.
|
| My team and I will try to be online and try to answer any
| questions you may have throughout the day.
| jackphilson wrote:
| Hi. Thanks for this. What is your goal of doing so? From a
| business standpoint. Or is it purely altruistic?
| dvrp wrote:
| Haha-classic!
|
| It's simple: hackability and recruiting!
|
| The open-source community hacking around it and playing with
| it PLUS talented engineers who may be interested in working
| with us already makes this release worth it. A single
| talented distributed systems engineer has a lot of impact
| here.
|
| Also, the company ethos is around AI
| hackability/controllability, high-bar for talent, and AI for
| creatives - so this aligns perfectly.
|
| The fact that Krea serves both in-house and 3rd-Party models
| tells you that we are not that bullish on models being a
| moat.
| wjrb wrote:
| I can say that it's definitely working on me! I hadn't
| heard of Krea before, and this is a great introduction to
| your work. Thanks for sharing it.
| dvrp wrote:
| For Dang or HN-mods:
|
| I noticed that the URL for this submission is wrong: I tried to
| submit the correct URL (https://www.krea.ai/blog/flux-krea-open-
| source-release) but, for some reason, the submission gets flagged
| as duplicated and then I can only find this item which has a URL
| to our old blog post.
|
| In the mean time, I'll setup a server-side redirect from the old
| blog post to our new one, but it would be nice to fix the link
| and I don't think I can do it on my side.
| dang wrote:
| It's because https://www.krea.ai/blog/flux-krea-open-source-
| release contains this: <link rel="canonical"
| href="https://www.krea.ai/blog/new-krea">
|
| Our software follows canonical links when it finds them.
|
| I've fixed the link above now (and rolled back the clock on the
| submission, to make up for lost time) but you might want to fix
| this for future pages.
| dvrp wrote:
| OMG. Thank you! I had to setup a CDN-level redirect and I was
| so confused as to why when I asked others to help, their
| submissions were flagged as [dupe] or [dead]
|
| Thank you so much! I knew that HN software was advanced, but
| I didn't know you guys used Canonical URLs like Google does.
| Smart and thanks for helping us with this slip!!!
| sangwulee wrote:
| Hi! I'm lead researcher on Krea-1. FLUX.1 Krea is a 12B rectified
| flow model distilled from Krea-1, designed to be compatible with
| FLUX architecture. Happy to answer any technical questions :)
| swyx wrote:
| thanks for doing this!
|
| what does " designed to be compatible with FLUX architecture"
| mean and why is that important?
| sangwulee wrote:
| FLUX.1 is one of the most popular open weights text-to-image
| models. We distilled Krea-1 to FLUX.1 [dev] model so that the
| community can adopt it seamlessly into existing ecosystem.
| Any finetuning code, workflows, etc that was built on top of
| FLUX.1 [dev] can be reused with our model :)
| swyx wrote:
| do LoRAs conflict with your distillation?
| oompty wrote:
| The model looks incredible!
|
| Regarding this part: > Since flux-dev-raw is a guidance
| distilled model, we devise a custom loss to finetune the model
| directly on a classifier-free guided distribution.
|
| Could you go more into detail on the specific loss used for
| this and any other possible tips for finetuning this that you
| might have? I remember the general open source ai art community
| had a hard time with finetuning the original distilled flux-dev
| so I'm very curious about that.
| vipermu wrote:
| hey hn! I'm one of the founders at Krea.
|
| we prepared a blogpost about how we trained FLUX Krea if you're
| interested in learning more: https://www.krea.ai/blog/flux-krea-
| open-source-release
| erwannmillon wrote:
| yoo i'm also a researcher on the krea 1 project and happy to
| answer any questions :)
| OsrsNeedsf2P wrote:
| Cool to see an open weight model for this. But what's the
| business use case? Is it for people who want to put fake faces on
| their website that don't look AI generated?
| dvrp wrote:
| Thanks!
|
| From a business point of view, there are many use-cases. Here's
| a list in no particular order:
|
| - You can quickly generate assets that can be used _alongside_
| more traditional tools such as Adobe Photoshop, After Effects,
| or Maya/Blender/3ds Max. I've seen people creating diffuse maps
| for 3D using a mix of diffusion models and manual tweaking with
| Photoshop.
|
| - Because this model is compatible with the FLUX architecture,
| we've also seen people personalizing the model to keep products
| or characters consistent across shots. This is useful in
| e-commerce and fashion industry. We allow easy training in our
| website -- we labeled it Krea 1 -- to do this, but the idea
| with this release is to encourage people with local rigs and
| more powerful GPUs to be able to tweak with LoRAs themselves
| too.
|
| - Then I've seen fascinating use-cases such as UI/UX designers
| who prompt the model to create icons, illustrations, and
| sometimes even whole layouts that then they use as a reference
| (like Pinterest) to refine their designs on Figma. This reminds
| me of people who have a raster image and then vectorize it
| manually using the pen tool in Adobe Illustrator.
|
| We also have seen big companies using it for both internal
| presentations and external ads across marketing teams and big
| agencies like Publicis.
|
| EDIT: Then there's a more speculative use-case that I have in
| mind: Generating realistic pictures of food.
|
| While many restaurants have people who either make
| illustrations of their menu items and others have
| photographers, the big tail of restaurants do not have the
| means/expertise to do this. The idea we have from the company
| perspective is to make it as easy as snapping a few pictures of
| all your dishes and being able to turn all your menu (in this
| case) into a set of professional-looking pictures that
| accurately represent your menu.
| gshklovski wrote:
| Helpful blog post for understanding what kind of data is needed
| for these models!
|
| Does this have any application for generating realistic scenes
| for robotics training?
| dvrp wrote:
| Hey thanks! I'll ask Sangwu to hop here to answer this and give
| a more research-oriented answer
| sangwulee wrote:
| Thank you! Glad you find it helpful. The model is focused on
| photorealism so it should be able to generate most realistic
| scenes. Although, I think using 3D engines would be more
| suitable for typical cases for robotics training since it gives
| you ground truth data on objects, location, etc.
|
| One interesting use case would be if you are focusing on a
| robotics task that would require perception of realistic
| scenes.
| erwannmillon wrote:
| yeah data really is everything that was the number one lesson
| from this whole project
| kmavm wrote:
| Amazing. I can practically _smell_ that owl it looks so darned
| owl-like.
|
| From the article it doesn't seem as though photorealism per se
| was a goal in training; was that just emergent from human
| preferences, or did it take some specific dataset construction
| mojo?
| sangwulee wrote:
| I love owls. Photorealism was one of the focus areas for
| training because "AI look" (e.g. plastic skin) was biggest
| complaint for FLUX.1 model series. Photorealism was achieved
| with both careful curation of finetuning and preference
| dataset.
| dvrp wrote:
| Relevant links:
|
| - GitHub repository: https://github.com/krea-ai/flux-krea
|
| - Model Technical Report: https://www.krea.ai/blog/flux-krea-
| open-source-release
|
| - Huggingface model card: https://huggingface.co/black-forest-
| labs/FLUX.1-Krea-dev
| bangaladore wrote:
| Can someone ELI5 why the safetensor file is 23.8 GB, given the
| 12B parameter model? Does the model use closer to 24 GB of VRAM
| or 12 GB of VRAM. I've always associated a 1 billion parameter =
| 1 GB of VRAM. Is this estimate inaccurate?
| petercooper wrote:
| That's a good ballpark for something quantized to 8 bits per
| parameter. But you can 2x/4x that for 16 and 32 bit.
| 7734128 wrote:
| I've never seen a 32 bit model. There's bound to be a few of
| them, but it's hardly a normal precision.
| zamadatix wrote:
| Some of the most famous models were distributed as F32,
| e.g. GPT-2. As things have shifted more towards mass
| consumption of model weights it's become less and less
| common to see.
| petercooper wrote:
| And on the topic of image generation models, I think all
| the Stable Diffusion 1.x models were distributed in f32.
| nodja wrote:
| > As things have shifted more towards mass consumption of
| model weights it's become less and less common to see.
|
| Not the real reason. The real reason is that training has
| moved to FP/BF16 over the years as NVIDIA made that more
| efficient in their hardware, the same reason you're
| starting to see some models being released in 8bit
| formats (deepseek).
|
| Of course people can always quantize the weights to
| smaller sizes, but the master versions of the weights is
| usually 16bit.
| piperswe wrote:
| A parameter can be any size float. Lots of downloadable models
| are FP8 (8 bits per parameter), but it appears this model is
| FP16 (16 bits per parameter)
|
| Often, the training is done in FP16 then quantized down to FP8
| or FP4 for distribution.
| sangwulee wrote:
| Quick napkin math assuming bfloat16 format : 1B * 16 bits = 16B
| bits = 2GB. Since it's a 12B parameter model, you get around
| ~24GB. Downcasting to bfloat16 from float32 comes with pretty
| minimal performance degradation, so we uploaded the weights in
| bfloat16 format.
| TuringNYC wrote:
| I usually use https://github.com/axolotl-ai-cloud/axolotl on
| Lambda/Together for working with these types of models. Curious
| what others are using? What is the quickest way to get started?
| They mention Pre-training and Post-training but sadly didnt
| provide any reference starter scripts.
| dvrp wrote:
| We actually have a GitHub repository to help with inference
| code.
|
| Check this out: https://github.com/krea-ai/flux-krea
|
| Let me see if we can add more details on the blog post and
| thanks for the flag!
| TuringNYC wrote:
| Thanks! Yes, the inference is pretty straightforward, but the
| real opportunity IMHO is the custom pre-training and post-
| training opportunities given the open weights.
| sergiotapia wrote:
| For the Krea team that might be reading: I was trying to evaluate
| Krea for my image gen use case, and couldn't find:
|
| - cost per image - latency per image
|
| Hope you guys can add it somewhere!
| dvrp wrote:
| Yup... We have the following: https://www.krea.ai/pricing
|
| Though we wanted to keep this technical blogpost free from
| marketing fluff, but maybe we over-did it.
|
| However, sometimes it's hard to give an exact price per image,
| as it depends on resolution, number of steps, whether a LoRA is
| being used or not, etc.
| bluehark wrote:
| Do you have an NVIDIA optimized version? Similar to how RTX
| accelerated FLUX.1 Kontext: https://blogs.nvidia.com/blog/rtx-ai-
| garage-flux-kontext-nim...
| sangwulee wrote:
| We have not added a separate RTX accelerated version for FLUX.1
| Krea, but the model is fully compatible with existing FLUX.1
| dev codebase. I don't think we made a separate onnx export for
| it though. Doing 4~8 bit quantized version with SVDQuant would
| be a nice follow up so that the checkpoint is more friendly for
| consumer grade hardware.
| bluehark wrote:
| How large was the dataset used for post-training?
| sangwulee wrote:
| We used two types of datasets for post-training. Supervised
| finetuning data and preference data used for RLHF stage. You
| can actually use less than < 1M samples to significantly boost
| the aesthetics. Quality matters A LOT. Quantity helps with
| generalisation and stability of the checkpoints though.
| qlm wrote:
| Images still look AI generated
| dvrp wrote:
| Yeah, there are still imperfections. But, it's surprising to us
| how much the quality can be improved without the need of a
| whole pre-training (re-) run.
| artninja1988 wrote:
| Thanks for the release to the team! Any plans on doing the same
| for FLUX.1 Kontext?
| leftstrokeviral wrote:
| How much data is the model trained on?
| dvrp wrote:
| Copying and pasting Sangwu's answer:
|
| We used two types of datasets for post-training. Supervised
| finetuning data and preference data used for RLHF stage. You
| can actually use less than < 1M samples to significantly boost
| the aesthetics. Quality matters A LOT. Quantity helps with
| generalisation and stability of the checkpoints though.
| paparicio wrote:
| Great, these people are crazy. CONGRATS!!!
| dvrp wrote:
| Haha thanks! Do you happen to have a use-case for it?
| TuringNYC wrote:
| I'd recommend you offer a clearly documented pathway for
| companies to license commercial output usage rights if they get
| the results they seek (i'll know soon enough!)
| dvrp wrote:
| You can find details about the license here:
| https://huggingface.co/black-forest-labs/FLUX.1-dev/blob/mai...
|
| In a nutshell, it follows the same license as BFL Flux-dev
| model.
| ilc wrote:
| Tried a simple prompt, and got some pretty interesting results:
|
| "Octopus DJ spinning the turntables at a rave."
|
| The human like hands the DJ sprouts are interesting, and no
| amount of prompting seems to stop them.
|
| Opinionated, as the paper says.
| earthicus wrote:
| Describing it as "Octopus DJ with no fingers" got rid of the
| hands for me, but interestingly, also removed every
| anthropomorphized element of the octopus, so that it was
| literally just an octopus spinning turntables.
| jacooper wrote:
| Non-commercial license... What's the point even, I can't use it
| for anything.
| hhh wrote:
| for the love of the game, not for corporate greed
___________________________________________________________________
(page generated 2025-07-31 23:00 UTC)