# From Pixels to Robots: How we customize FLUX for production to make it steer robots and play games — Jakob Pörschmann — session 2026-09-24T07:30:00.000Z → 2026-09-24T08:00:00.000Z _96 transcript lines · 58 slides_ ## Transcript Ladies and gentlemen, please join me in welcoming to the stage your MC for the AI Engineer Paris 2026, developer relations engineer at Replit, Raouf Chevre. Morning, everybody. How's it going? Hey. This feels like day two energy, so we need to bring it up. Okay? How's it going, everybody? Yeah. Nice. Nice. Nice. Well, welcome to AI Engineer Paris, day two. Alrighty. So who was it that's yesterday? Show of hands. Okay. Most of you guys. That's awesome. So yesterday was all about how to think about the evolution of technology, to think about AI today, and then we talked about the future of AI. Right? The future. Software factories, and also, the the future of Frontier models. But I'm particularly excited about today. Today, we're gonna talk about generative media, about software factories again. We're gonna talk about graph rags, and we're and we're gonna cover so much more. So, with that, I want you to, think about what you want to see. Please pay attention to everything that is gonna be said here. Our speakers are gonna be hanging out, so also take the time and go to the expo, and talk to everybody to learn as much as you can. Alright. So you know the drill by now if you were here. Right? This event wouldn't be possible without Mistral, so I would like to give it up for them. So please, let's give it up for Mistral. Thanks for organizing. And let's give it up for our sponsors, our platinum sponsor, NVIDIA. Yes. Please. Yeah. Keep it going. So to for all our, gold sponsors, silver Sponsors, bronze sponsors, and also our supporting sponsors. Let's give it up one more time. Yeah. Thank you. Okay. Alright. So without further ado, our next speaker is from Black Forest Labs, and he's got some tendency. He loves going to the dentist. I don't know why. Maybe we can ask him later. But he's going to talk to us about about how they went from image generation to robotics. So please join me in welcoming The stage, Jacob Borschman. Thank you very much. Super nice to meet you, Ron. I just need my slides maybe in here. Awesome. Nice to meet you, everyone. My name is Jacob. I lead the AI solutions team. That's the four deployed engineering team and solutions engineering team at Black Forest Labs. And I would like to start in with a hopefully trivial question. So Give me a brief show of hands of who has generated an image or a video before using AI. Just give me a brief show of hands. This should be trivial. Come on. This is almost everyone, hopefully. And, then hopefully, if you generate an image or a video before, you hopefully were in contact with Flux or Black Forest Labs before. Because Black Forest Labs at Black Forest Labs, we are a research lab based in Germany, and we build Foundational image and video models for image generation, and you can see some of the samples, videos and images that were generated with our recent model FLUX3 in the back, back here. Now, the second question that I have for you is who of you would believe me, if I would tell you that you can use that same video model to also control robots and play video games? Okay. That's a few people. Not really everyone. Well, it's kind of a it's kind of a Question, obviously. Otherwise, I wouldn't talk about it because that's exactly the final thing that I'm gonna close with today is how we're gonna customize Flux, to not just generate media, generate images, generate videos, and and edit, edit both. But we we're gonna talk about how to steer video games and steer robots with it. So you can see two different samples here that were also, on the left, generated with Flux. On the left, you have Flux actually actually playing a video game. So this is not just a Video of a, generated, but it's actually Flux taking the control and and generating the frames that are happening. And on the right, you have a Lirobot that is completing pick and place tasks, with Flux, the video our video model Flux three as a intelligence backbone. And what is in between video generation and using Flux as a backbone for a robot, that's exactly what we're gonna talk about today. Because the part that is in between, that's basically bridging that Gap is customization of this Flux model. Right? There is a super powerful model that we pretrained, mid trained on essentially understanding the visual world, having having an understanding for, how objects are behaving in the visual world. And we are taking this model and customizing it for certain use cases. And that's exactly what we do in our AI solutions team as well. And this is what I want to talk to you about, in a couple different steps. To break this down a little bit before we go into robots, that's going to be the final Stage of what we're gonna talk about. I'm gonna talk a little bit about the anatomy of the inference pipeline because this is also going to give you an overview of sort of the customization vectors that we have when we walk work, work with Flux, and we talk to enterprise customers that want to use Flux for very specific use cases. This breaks down in approximately six steps. First, of course, there is a user input, that can be optimized. This is usually a text prompt, an image prompt, a video prompt. Fairly straightforward. Right? Second step is the prompt upsampling. Prompt upsampling essentially means that we have an LLM or a VLM that sits between the user prompts that is sent to us and the flux model, and And we essentially try to understand the intent. We try to understand what the user actually wants to do, and we try to improve the prompt that the model generates something that's closer to what the user user is actually intending to do. Then there's moderation. You might be surprised and see Motivation when it took when it comes to, when it comes to customization of a model. Well, actually, motivation is one of the most important product surfaces, because motivation essentially decides what you're gonna see or what you're not gonna see. It's not part of mostly not part of the model, but it is part of the user experience. And we're gonna talk a little bit about how we customize it and also how we actually embed moderation into the model rates. Fourth, there's, of course, the model. There are the model rates which we can fine tune. We can run low hours on it. We can fine tune for style, for Characters for products. We can fine tune also for behaviour. And, using fine tunes, we can also add whole new modalities. And that's exactly what we did with Flux Flux3 Action, which I'm going to talk about in the end of my presentation. Then there's a post processing step, of course. This is kind of arbitrary. There can be upscaling, there can be restoration, there can be further moderation, right? Endless customization opportunities here. And then finally, there is, we also work a lot about, how we actually serve the model, how we deploy it. How we optimize it, how we distill it, etcetera, etcetera. And what I want to do in the next twenty ish minutes is I want to go through essentially the four deployed engineers' toolbox at least scratch the surface a little bit of how we customize Flux, in our day to day. So, starting with the first major customization, I wanna focus on this prompt up sampling step. As I already mentioned, prompt up sampling means that there is a VLM or an LLM that sits between the And the model. That looks in practice something like this. So on the left here, you have a user prompt. So this might be super, super straightforward, a cabin in the forest. And if you send that straight to the Flux model, generate an image, you'll see something like the image on the left. It's a plain, cabin in the forest. Right? The mission completed. However, it might not be optimized for user intent. It might not be optimized for user preferences. It highly depends, of course, what the user wants. Yeah. In this case, the The prompt is fairly simple, but it demonstrates the purpose quite well. So essentially, we take the cabin in the forest, and we essentially extend the prompt. In this case, the default upsampler just optimizes for user preference, extends the prompt to use it with the cabin in the forest to something like a hyper realistic, right angle, stone chimney, soft warm, golden light, etcetera, etcetera. And then you see the final result, on the right. Whether you like the left or the right better, that's up for up for discussion, of course. But The point being here is that the prompt of sampling step gives us an incredibly powerful tool to actually steer the user intent and the generation that we're taking into any direction possible. So let's take a look at a concrete, concrete case. So this specific this was a real customer case. The customer essentially came to us and told us, well, actually, we want to illustrate certain conversations that our user are having and our users are having in our application with Flux images. So they wanna create illustration. For topics. These topics could be completely random. And they're machine generated, so they're not hunt created, and they're also not image prompts. So, for example, this could be family friendly travel destinations or draining water from my dishwasher. Right? Completely random topics, not in the form of an image prompt, machine generated. This could be a vast priority of topics. Now, our task is to generate an illustration, somehow illustrate this nicely, but the trick to this is that, of course, there are certain design requirements that we need to meet. So For example, in this specific case, the subject is supposed to be on the right, it's supposed to be a very clean image, there's supposed to be a lot of space on the left for a text overlay, and there are certain design rules that also apply, for example, no people involved, no landmarks, and a couple others. So, what we essentially do, or what this actually comes down to, is that the model, the image model is actually not the bottleneck anymore because the model technically can generate all of these all of these different different things. Right? No problem at all. But really Design requirements end up being the bottleneck. And where prompt up sampling comes in is matching and bridging the user prompt with the design requirements and matching these design requirements to the training distribution of Flux. So finding the exact right spot that we need to send to the model, from the training distribution to generate the the exact image, that slides are gone. Here we go. To generate Exact image that actually follows the design requirements. So, to give you two examples from the the topics that you already saw, first, they have family friendly travel destinations. If you send that as a RAW prompt to Flux, completely unupsambled, you're gonna see complete gibberish, complete, trash trash images, essentially. For example, there's this postcard style. The variety between different seats also is extremely high, when you just send this completely unupsambled. If you use our default Upsampler, which is just optimized for general user, user preference, then you'll see you'll see something like in the middle, probably a little bit closer to somewhat of an illustration, but not at all matching the design requirements. But if we actually customize the upsampling step and we embed the design requirements directly in the prompt upsampling, you'll see something on the right. So the subject is on the right. It's a very clean image, very sort of glossy. There's a lot of space on the left for text overlay. So meeting exactly the design requirements. Same goes for the second example. So drinking water in the dishwasher without propped up sampling complete complete random image. Getting a little bit better, some sort of instruction video, but still not at all what we want In the second case, but if we actually customize this Upsampler, which is essentially the system prompt that looks at the intent and tries to match that into the training distribution knowing the design requirements, we'll get a very nice, very clean image, subject on the right, a lot of space on the left, text overlay possible. And this is essentially a pretty simple trick, because the massive example and what we essentially learn from this, the massive advantage is that it's super quickly to iterate. You essentially just iterate over a system prompt. There's no training needed, and you have maximum use case flexibility. And this is sort of necessary as well to include this step because what we learned, especially with end... When talking with enterprise customers, that users are just lazy. Users don't necessarily want to Know exactly how our training distribution looks like. Right? How to perfectly, perfectly, prompt flux. That's in a lot of cases where we come in and we customize prompt upsampling to match exactly user intent, design requirements, and training distribution to find exactly the right sweet spot here. Yeah, point of settling seems super simple but it's an incredibly powerful tool because it is so simple to iterate over and it doesn't need any training. Moving on to the next stop Is moderation and safety. And you might be, again, a little bit surprised to see this in the customization surface here, but moderation is actually one of the most important product surfaces that we have, especially when offering a model to the through the API because, essentially, moderation decides on what the user sees and whatnot, what do you read which prompts we allow and which not. So this is an incredibly important piece of the user experience that we offer. If you have tried some video models, state of the art video models in the past, you might be very aware of Messages like this. You put in an image of yourself, and you wanna animate yourself, but you're getting something like, the images or videos might provide likenesses of real people, etcetera. This is obviously not a model limitation. This is purely moderation service, right, that doesn't allow you to generate something. And when talking to larger customers that want to do very specific thing, thinks this is a massive issue, and we need to customize and solve for this. So, two ways that I would like to talk about moderation. First is It's the most simple way, and it is essentially in the configs. We have a modular setup to essentially customize configs. There is a fairly straightforward safety parameter here, that allows you to set that via API. And when customizing, when customizing moderation for specific customers, we have a very fine grained config setup that essentially allows us to set safety tolerance, but also allow or block certain, certain categories, specifically. So Violence, sexual prompts, self harm, IP, and likeness. And we also combine that with certain block lists and allow lists that we can set specifically for every customer. So think about, for example, a kid's platform being much more strict, blocking violence, sexual, self harm, IP likeness, obviously, and then having even a specific blocklist. Fashion retailer being a little bit more a little bit more open, maybe allowing a little bit more of sexual leaning prompts, but blocking specifically competitor brands and allowing the own Folio, essentially only trying to generate their own their own stuff, of course. Right? And then there might be a media or a movie studio that, is much more flexible, allows even some violence, and specifically wants to allow certain licensed characters, even if they're IP protected, and wants to block every other character that is not that they don't have a license for. So this is fairly straightforward. We just set the config super modular, super simple. However, this doesn't work for every case, because we also deploy our model. Directly on customer's infrastructure. So, in these cases, we don't ship the entire moderation stack, we somehow need to find a way to actually embed the moderation and the safety into the model rates. And, this is where, for example, a slider lower comes in, which is the next tool in the toolbox of our FDEs. A slider lower tries to learn an abstract concept or tries to learn the specific abstract concept that we're trying to block and tries to Then turn around the rates that it learned to block that specifically. So, let's take the example of a desexualization slider lower, which you have essentially simplified here on the slide. Essentially, you try to tweak the model, tweak the lower end adaptation matrix you try to tweak that into the the rates into the direction of the of the pure concept of sexualization. How we do this is that you have a generic data set of images, for example, of people, in this case, one image of a woman in a black dress, and you That to every, training loop tries. Once with a modest caption and once with a sexualized caption. So then you essentially train the model. This is the image, and you see it tries. One once modest and once sexualized. And what, what what is left in the rates is essentially the delta between both learnings. And the delta between both learnings is both both captions essentially contain, there's a woman, black hair, black dress, whatever. But the delta between those is essentially the concept of sexualization because the Sexualized caption contains that, but the modest caption doesn't. It's much more descriptive. So you end up with a law matrix, with an adaptation matrix that essentially describes the concept of sexualization. Right? And in inference, we can now go ahead and apply that to our model rates with a negative alpha. So we turn the rates exactly around to go in exactly the opposite direction, which then turned out in this specific case for, for minus 20. The nudity detections and, 68% judged less less sexualized image quality. While, at the same time, the image quality generally is a complete tie because we literally only turn around the concept of sexualization. So this is a nice tweak to really bake in moderation into the rates, and this is something that you can also ship directly to customer. They can deploy it on their own infrastructure, to have a much safer model without any deterministic, moderation around it. So what we And from the moderation piece is that, first of all, safety is an extremely important product product service. It's essentially the first thing that users interact with in some sense. It decides what users see, what users don't see. And it can be a USB, it can even be a business model in certain cases. Modularity wins. Baking in moderation into model rates is cool, it's fun, it's a nice concept, let's let you build some slider doors. However, it's expensive to train, it's static, you need to update it. Somehow. So in many cases, or in most cases, we just go with simple config customizations because it's just modular, it's easy, it's scalable, right? It's much cheaper to actually set up. And, yeah, as I already mentioned, motivation and weight is possible. However, it is expensive and static. Right. Let's move on. So we already looked at the fine tune that changes behaviour in the moderation direction, but I promised you some robots and I promised you some Flux controlling some things. So, finally, we're going to look at customization of model weights, and how to fine tune Flux for specifically Action Prediction. Just to give you an overview, generally if you fine tune a model, usually we come with a certain goal in mind. If we're talking about video models or or image models, we either fine tune for a certain style, we fine tune for a certain object that we want to present or a set of objects, we fine tune for a certain character that needs to be, extremely accurately, displayed. Date, or we fine tune for behaviour. We also have some models that we find in, for example, out painting, specific local editing, desexualization, right, all of these are behavioural fine tunes. And then, if you go even further, you can even think about fine tuning for certain to to add certain modalities. If we even go a little bit into mid training and post training again. That's exactly what we did with Flux Action. Flux Action is a new, version of Flux, Flux Backbone that we, continued mid training and post Drained and fine tuned for specifically action prediction. This was actually released into OpenWeards yesterday night. So check it out. It's brand new. It's on a hugging page. You can try it out, pull the weights, and control your own layer of bot with it. But just to give you a brief rundown on how it works. So, we have an image model that essentially predicts frames, predicts video frames based on, based on a text input mostly. Right? So how FluxAction works is that it has a text conditioning, and it has a video conditioning. And this specific Case, we work with a Lirobot that completes pick and place task. The Lirobot in this case has two camera sets one is at the, grabber hand, one is above, the top camera, essentially. At the same time, we also fine tuned Flux Action for the, for the embodiment of the SL101, the Lirobot robot arm specifically. So we actually teach Flux that this specific robot has six axes, and the movement of the This axis essentially represented by a vector that in every frame defines the direction that every axis needs to move into. So essentially, it's simplified a six dimensional vector that we're trying to predict here. Now, we feed the the the vector node, the the embodiment knowledge is already embedded in the model weights. We feed in the video frames and the text conditioning, which defines the task. And the output essentially is a video of the continuation of These video frames and also, the actual vector that defines the direction that the robot needs to move in to actually complete the task. And then you can, on the right, see how the layer robot, is actually controlled by Flux. I mean, you'll have to trust me that it's actually controlled by Flux, but you can check that out yourself. And it actually completes, exactly the task that it's, supposed to do. You actually can see the the text prompts there. But, so that is pretty fun. How that Folks, in the background, let's take a little look at the architecture, is that we have a video model traditionally. It takes certain frames, and it feeds them through a variable autoencoder. The autoencoder projects my frames, my pixel space into a latent space, which is an abstract representation, of of these exact frames. And then we go through this denoising process that gradually reduces noise and tries to predict these next video frames. Usually, when we just predict an image or a video, we then have a a decoder as well that then takes these latents, these abstract representation, and brings them back into the pixel space. Now, Flux Action is a world action model. That means that we don't even send these action vectors, through the viral autoencoder into the latent space anymore, but we just normalize them into the dimensionality of the, of the latent space. And we directly denoise the, Denoise essentially the action vector. That is a huge example because we essentially denoise both in the same transformer. In the end, for the action case, we actually don't even use the, decoder for the, for the frames and video part. We only denormalize the action part. We have the robot actually apply it, and that's how we complete the task. Essentially, the video needs encoder and decoder. Actions are already a vector, so we can actually naturally feed them through the through the Auto that has been mid trained and fine tuned on exactly solving these tasks. So flux flux two action, flux three action. You can check out the research. You can download the rates here. It has dropped literally last night. It's right now topping leaderboards and being, being state of the art in exactly, this action prediction space. So check it out. It's pretty exciting research. And we're pretty excited about venturing in this domain as a new modality. And this is also already where I'd like to wrap up. What we basically looked at is customizing Flux for the use cases. We looked at prompt upsampling and how prompt upsampling can be an incredibly efficient method to actually match user intent with the design requirements into the training distribution of Flux to actually get out an image that, at scale, conforms certain design requirements. We also looked at moderation. We looked at sort of Static deterministic, or more or less deterministic moderation that modularly, is embedded in configs. We also looked at how to embed moderation preferences into model weights directly using a sliding lower. And then finally finally, we looked at how to add a new modality to Flux, specifically looking at Flux action and how to tweak Flux to actually control a robot and predict the next action. If you want to take away one single thing Across all these methods, and this is obviously just scratching the surface. So if you wanna take away one single thing, about good customizations of AI models in general and also Flux specifically, it is that great customization customizations in all of these cases are as specific as needed and as general as possible. So they solve one specific problem to exactly the extent that it needs to solve them, but it also generalizes to actually maybe solve an entire domain, maybe be a solution that you can also roll out further. So, With that I'll wrap it up. I have another advertising block here. We are hiring forward deployed engineers solution engineers. If you want to check that out, you can also find me, find me at the conference, find me online. And, yeah, thank you very much for attending. Thank you, Good job. Alright. K. Yeah. Let's give it up once more for Jakub, please. Thank you, guys. I'm so excited for Black Forest Labs. And, the nice thing about them as well is that they're based in Europe. They're based in Germany, and they're they're at the front front of everything generative media related. And now they do robotics, which is so cool. But, you know, another company that is European based and also at the the frontier of AI is Eleven Labs. So our next speaker is actually is going to talk. Talk to you about generative identity at scale with orbs. And basically, who here has used the ChatGPT voice mode or Eleven Labs? So you've seen that little circle, that orb? If you use that, you probably have used something that our next speaker has built. So please join me in welcoming to the stage creative experience engineer at eleven Labs, Dorian Lauds. Seems that Internet's not working. That's a good start. Alright. Hi, everyone. I I'm Dorian. I'm a creative engineer at Eleven Labs. We're currently based in Paris. ## Slides ### 00:01:18 # AI Engineer PARIS ## Organized By Mistral ## Sponsored By - Sonar - Cloudflare - Daytona - Langfuse by ClickHouse - Mod - Latitude - Makora - Fimo - Stripe - ZenML ### 00:01:51 # Theresa Bradford ## Team Lead Data Science ### otto group data.works # Lara Khanafer ## Head of Startup Programs & Partnerships ### Gr... [Black and white headshot of Theresa Bradford, a smiling woman with glasses] [Black and white photo of Lara Khanafer, a smiling woman] ### 00:02:19 # Partners and Sponsors - NVIDIA - AI Engineer Paris - Cockroach Labs - Mistral - FACTORY - SENTRY - Sonar - CLOUDFLARE - Daytona - langfuse by ClickHouse - Modal - neo4j - Qdrant - CodeRabbit - cominty - descope - Latitude - FIMO - MAKORA - stripe - ZenML labs - Backblaze - Notion - SIERRA [Grid of company logos on a dark background] ### 00:02:54 - AI Engineer PARIS - Notion - Mistral - langfuse by ClickHouse - NVIDIA - AI Engineer - AI Engineer [Grid of company logos, including stylized logos for Notion, Mistral, langfuse, NVIDIA, and a floral-like logo for an unknown company starting with S.] ### 00:03:20 - Mistral - AI Engineer - NVIDIA - langfuse by ClickHouse - AI Engineer PARIS - desc... ### 00:03:53 # Sponsors ## Silver - Cloudflare - Daytona - Lansweeper - Modal - neo4j - (Unidentified logo) - codeRabbit - cominty ### 00:04:18 # Silver - Daytona - langfuse by ClickHouse # Bronze - cominty - des... - ...tude - M... # Supporting partners - Noti... ### 00:04:46 # Jakob Pörschmann ## AI Engineer Paris Organized by Mistral ### STATION F | September 23-24 AI Solutions Lead Black Forest Labs [Logo for AI Engineer Paris] [Logo for Mistral] [Logo for Black Forest Labs] ### 00:05:22 SHOW OF HANDS # Who here has generated an image or a video with AI? ### 00:05:53 Forest Labs — foundation image & video models, open and served. [Collage of five images: a news reporter holding a microphone, a blue sports car at a gas station, a close-up ### 00:06:19 # ...ve a robot ### 00:06:52 # PREDICTION - THE VIDEO MODEL'S NEXT FRAMES - BOT - 02511 - FLUX - 2.32 KM W 1 - ### 00:07:21 - NITRO - STEP 1000 - STEER +0.42 - CAMERA - 4x SPEED - box - ENGINEER PARIS 202 ### 00:07:49 # I — Pipeline ## Our inference builds on six customization vectors 1. **User input** Reference conditioning > a cabin in the forest 2. **Prompt upsampling ### 00:08:24 # Our inference builds on six customization vectors 1. **User input** Reference conditioning 2. **Prompt upsampling** Behavior, quality & design guidelines 3. **Moderation** Behavior, policy, blocklists, allowlists 4. **Model** Task & Behavior, fine tunes 5. **Post-processing** Upscaling, restoration 6. **Serving** Distillation for speed & deployment [Diagram showing a six-stage pipeline. Stage 1: text input "> a cabin in the forest". Stage 2: text input "35 mm · dusk · fog · low angle". Stage 3: text with a "CLEARED" stamp. Stage 4: four small textured images. Stage 5: a high-resolution image of a cabin in a foggy forest, labeled "4K" and "CLEARED". Stage 6: an image icon with "SHIPPED" text.] ### 00:08:51 # Our inference builds on six customization vectors I — Pipeline - 01 **User input** Reference conditioning - 02 **Prompt upsampling** Behavior, quality & design guidelines - 03 **Moderation** Behavior, policy, blocklists, allowlists - 04 **Model** Task & Behavior · fine tunes - 05 **Post-processing** Upscaling · restoration - 06 **Serving** Distillation for speed & deployment [Diagram illustrating an AI inference pipeline with six steps, showing text inputs (`> a cabin in the forest`, `35 mm · dusk · fog · low angle`) leading to a "CLEARED" status, then two generated images (one with a "4K" label and "CLEARED" stamp), and finally a "SHIPPED" icon.] ### 00:09:21 # Our inference builds on six customization vectors ## I — Pipeline 1. **User input** Reference conditioning 2. **Prompt upsampling** Behavior, quality ### 00:09:49 - 35 mm - dusk - fog - v angle ### 00:10:21 # Prompt upsampling projects user intent into training distribution ## II — Stop 1 • Prompt upsampling ### USER PROMPT • NO UPSAMPLING - `a cabin in the forest` ### 00:10:54 - foregr - moss- - morni - diffus - creati - quiet a ### 5 WORDS SAME M [Image of a wooden cabin in a forest] ### 00:11:19 II — Stop 1 · Prompt upsampling # Prompt upsampling projects user intent into training distribution ## USER PROMPT · NO UPSAMPLING `a cabin in the forest` ## UPSAMPLED PROMPT hyper-realistic wide-angle photograph of a secluded wooden cabin deep in a dense evergreen forest, the small rustic cabin made of dark weathered logs with a steep pitched roof and **stone chimney**, **soft warm golden light glowing from the cabin windows**, tall pine and fir trees surrounding it on all sides with rich green foliage, a **narrow dirt path leading from the foreground up to the front door**, scattered ferns and moss-covered rocks on the forest floor, gentle morning mist hanging low between the trees, soft diffused sunlight filtering through the branches creating dappled light and shadow, peaceful and quiet atmosphere, **no people**, high detail, natural 5 WORDS → 118 WORDS SAME MODEL, SAME SEED ## OUTPUT · UPSAMPLED `a cabin in the forest` [Image of a rustic wooden cabin in a forest during the day] [Image of a cozy wooden cabin in a misty forest at dusk, with warm light glowing from its windows] ### 00:11:52 ## II — Stop 1 - Prompt upsampling # Prompt upsampling is the most flexible way to match design guidelines ### WHAT COMES IN - `"Family-Friendly Travel Destinations"` - `"Draining Water from Dishwasher"` Not a prompt. A machine-generated topic title. ### WHAT HAS TO COME OUT - **The subject, right** An illustration about the topic - **Room for text** Composition leaves space for text overlay - **Design rules** No people. No landmarks. The model is not the bottleneck. The design requirements are. ### 00:12:21 II — Stop 1: Prompt upsampling # Prompt upsampling is the most flexible way to match design guidelines ## WHAT COMES IN - "Family-Friendly Travel Destinations" - "Draining Water from Dishwasher" Not a prompt. A machine-generated topic title. ## WHAT HAS TO COME OUT - **The subject, right** - An illustration about the topic - **Room for text** - Composition leaves space for text overlay - **Design rules** - No people. No landmarks. The **prompt** is not the **bottleneck**. The design requirements are. ### 00:12:53 # Prompt upsampling is the most flexible way to match design guidelines ## II — Stop 1 • Prompt upsampling ### WHAT COMES IN - "Family-Friendly Travel Destinations" - "Draining Water from Dishwasher" Not a prompt. A machine-generated topic title. ### WHAT HAS TO COME OUT **The subject, right** An illustration about the topic **Room for text** Composition leaves space for text overlay **Design rules** No people. No landmarks. The model is not the bottleneck. The design requirements are. ### 00:13:18 # Draining Water from Dishwasher [Image of the inside of a dishwasher with water spraying] ### 00:13:53 # Not just prettier, but on-design is the goal ## II — Stop 1: Prompt upsampling ### Topic: "Family-Friendly Travel Destinations" - **01 RAW ### 00:14:21 # Not just prettier, but on-design is the goal ## II — Stop 1: Prompt upsampling **TOPIC TITLE** "Family-Friendly Travel Destinations" ### 00:14:46 ### II — Stop 1 - Prompt upsampling # What we learned 1. Users are lazy, and they're right to be. 2. The upsampler is often the most efficient customization lever. - No training run - Rapid iteration - Maximum use-case flexibility ### 00:15:20 # The upsampler is often the... - No training run - Rapid iteration ### 00:15:49 ## Stop 2 of 3 - Moderation & safety ### II — Stop 2 • Moderation & safety 1. **User input** Reference conditioning 2 ### 00:16:25 ## II — Stop 2: Moderation & safety # One policy for the whole world fails everyone differently > lunch on a Berlin sidewalk, slow push-in, 5 s > reference ### 00:16:49 - l - arm - keness - list weapons - public fig - BLOCK - BLOCK - BLOCK - LOCK - ED ### 00:17:22 ### Safety Tolerance: 0 - Violence: **BLOCK** - Sexual: **BLOCK** - Self harm: **BLOCK** - IP & likeness - blocklist weapons - alcohol - public figures ### Safety Tolerance: 3 - Violence: **STRICT** - Sexual: **ALLOW** - Self harm: **BLOCK** - IP & likeness: **BLOCK** - blocklist competitor brands - allowlist own catalogue - **CLEARED** ### 00:17:53 # The fix lies in flexible configs `safety_tolerance` LOW = STRICT (Slider set to 2) Moderation Reasons: - Violence - Sexual content - ### 00:18:20 # The fix lies in flexible configs - **safety_tolerance**: 2 (LOW to STRICT scale from 0 to 6) - **Moderation Reasons**: - Violence ### 00:18:52 # Slider LoRAs learn an abstract concept as weights ## 01 TRAIN ### Find the direction Same noise, same prompt. One word differs. - `Δ = pred_lewd - pred_safe` The sexualization direction. A rank-16 LoRA learns to reproduce it; the base stays frozen. ## 02 STEER ### Dial it at inference Negative α subtracts the direction. - ~20% nudity detections - 68% judged less sexualized - Image quality — a tie - Same seed, same prompt. The filter's dial, continued past zero into the weights. [Diagram showing an image and prompt being processed with "modest" and "lewd" prompts through a "FLUX frozen" model to produce "pred · safe" and "pred · lewd" outputs, which are then differenced to define a sexualization direction.] [Slider labeled "α · adapter scale" ranging from -1.0 to +1.0, with "LESS" and "MORE" indicators.] [Two images of a woman on a beach at sunset, one labeled "α = 0" showing her in a light dress, and another labeled "α = -1" showing her in a different, more modest dress.] ### 00:19:20 # Slider LoRAs learn an abstract concept as weights ## 01 · TRAIN ### Find the direction Same noise, same prompt. One word differs. Δ = pred_lewd - pred_safe The sexualization direction. A rank-16 LoRA learns to reproduce it; the base stays frozen. ## 02 · STEER ### Dial it at inference Negative α subtracts the direction. α = -1 -20% nudity detections 68% judged less sexualized **Image quality — a tie** Same seed, same prompt. The filter's dial, continued past zero into the weights. [Diagram showing an input image of a woman, processed with prompts "modest" and "lewd" through a "FLUX frozen" model to produce "pred · safe" and "pred · lewd" outputs.] [Slider control for "α · adapter scale" ranging from -1.0 (LESS) to +1.0 (MORE).] [Two images of a woman on a beach, one labeled α=0 and the other α=-1, with the α=-1 image appearing less sexualized.] ### 00:19:52 # Slider LoRAs learn an abstract concept as weights ## 01 TRAIN ### Find the direction Same noise, same prompt. One word differs. `Δ = pred_lewd - pred_safe` The sexualization direction. A rank-16 LoRA learns to reproduce it; the base stays frozen. ## 02 STEER ### Dial it at inference Negative α subtracts the direction. -20% nudity detections 68% judged less sexualized Image quality — a tie Same seed, same prompt. The filter's dial, continued past zero into the weights. [Diagram showing an input image and prompt being processed through two parallel paths with "modest" and "lewd" modifiers, leading to `pred · safe` and `pred · lewd` outputs, which are then used to calculate `Δ`.] [Slider diagram for `α adapter scale` ranging from -1.0 (LESS) to +1.0 (MORE).] [Two generated images of a woman on a beach at sunset, one labeled `α = 0` and the other `α = -1`.] ### 00:20:20 # Slider LoRAs learn an abstract concept as weights ## 01 TRAIN ### Find the direction Same noise, same prompt. One word differs. Δ = pred_lewd - pred_safe The sexualization direction. A rank-16 LoRA learns to reproduce it; the base stays frozen. ## 02 STEER ### Dial it at inference Negative α subtracts the direction. -20% nudity detections 68% judged less sexualized Image quality — a tie Same seed, same prompt. The filter's dial, continued past zero into the weights. [Flow diagram showing an image and prompt being processed with "modest" and "lewd" modifiers through a "FLUX frozen" model to produce "pred · safe" and "pred · lewd" outputs.] [Horizontal slider with values from -1.0 to +1.0, labeled "base" in the middle.] [Two images of a woman on a beach at sunset, one labeled `α = 0` and the other `α = -1`, showing a subtle difference in appearance.] ### 00:20:46 ### II — Stop 2 · Moderation & safety ## What we learned 1. Safety is a product surface — it can be a USP, even a business model. 2. Modularity wins. 3. Moderation in weights is possible, but expensive and static. ### 00:21:23 # What we learned 1. Safety is a product surface—it can be a USP, even a business model. 2. Modularity wins. 3. Moderation weights is possible, but expensive and static. ### 00:21:50 `fog . low angle` --- ### 00:22:21 ## II — Stop 3 • Action prediction # Stop 3 of 3 - Action prediction 1. **User input** Reference conditioning 2. **Prompt upsampling** ### 00:22:52 ### II — Stop 3 • Action prediction ## FLUX Action, conceptually: frames in, frames and actions out **INPUT** > put the blue box into the container Front + wrist camera frames Joint state: six values* **OUTPUT** Predicted next frames** Action tokens driving the actuators **ON THE ROBOT** On the robot — looped until the task is done. [Two images showing a robotic arm interacting with a blue box and a container] [Diagram illustrating the joint states of a robotic arm with labels like elbow flex, wrist flex, wrist roll, gripper, shoulder lift, shoulder pan] [Two images showing predicted next frames of the robotic arm and the blue box] [3D model of a robotic arm, representing action tokens] [Image of a real robotic arm on a table with a blue block, clear bowl, green bowl, and a container, labeled "TOP CAMERA • REAL ARM"] ### 00:23:20 # Front + wrist camera frames # Predicted next frames** ## Joint state · six values* ## ...ction tokens driving the actuators [Diagram of a robotic arm with labeled joints: elbow flex, wrist flex, wrist roll, gripper, shoulder lift, shoulder pan] [3D rendering of a robotic hand/gripper] ### 00:23:53 ## II — Stop 3 · Action prediction # FLUX Action, conceptually: frames in, frames and actions out ### INPUT > put the blue box into the container ### OUTPUT ### ON THE ROBOT On the robot — looped until the task is done. [Two images showing a robotic arm and a blue box from front and wrist ### 00:24:20 ## II — Stop 3 · Action prediction # FLUX Action, conceptually: frames in, frames and actions out ### INPUT > put the blue box into the container ### OUTPUT ### ON THE ROBOT - Front + wrist camera frames - Joint state - six values* - Predicted next frames** - Action tokens driving the actuators - On the robot — looped until the task is done. BFL — AI ENGINEER PARIS 2026 [Image showing a robotic arm's gripper holding a blue box, from a front camera view] [Image showing a blue box on a surface, from a wrist camera view] [Diagram of a robotic arm's joint states with labels like elbow key, wrist roll, gripper, shoulder pan, shoulder lift] [Image showing a robotic arm's gripper holding a blue box, labeled "Predicted next frames"] [3D model of a robotic arm's gripper, labeled "Action tokens driving the actuators"] [Image of a real robotic arm on a table with a blue box, a green bowl, and a clear container, labeled "TOP CAMERA + REAL ARM"] ### 00:24:53 ### II — Stop 3. Action prediction # One denoiser, two modalities - **ENCODE** - Camera frames - front + wrist - VAE EN ### 00:25:18 # NORMALIZE - already a vector - — no encoder 6 values needs an encoder and a decoder [Diagram showing "gripper" and "pan"] [Bar chart] ### 00:25:53 ## II — Stop 3 · Action prediction # One denoiser, two modalities ### ENCODE - Camera frames - front + wrist - **VAE ENCODER**: pixels ### 00:26:21 ## II — Stop 3 · Action prediction # FLUX 3 Action leads on task success | MODEL | CLOSED SOURCE | TYPE | SR% | PARAMS | | :---- | ### 00:26:48 e forest 35 mm . dusk . fo low angle --- eer Mistral ### 00:27:18 - st - 35 mm - dusk - fog - long angle ### 00:27:48 ### GREAT CUSTOMIZATIONS ARE ... **As specific as needed.** As general as possible. BFL — AI ENGINEER PARIS 2026 ### 00:28:19 # We're hiring. **ROLES** Forward Deployed Engineers · Solution Engineers **APPLY** bfl.ai/careers **FIND ME** [linkedin.com/in/jakob-poerschmann](https://linkedin.com/in/jakob-poerschmann) hello-jp.net [QR code for open roles] [QR code for AI solutions blog post] ### 00:28:49 - AI Engineer PARIS - NVIDIA - Sonar [Logo for AI Engineer PARIS] [Logo for NVIDIA] [Stylized 'S' or bird/wave logo] ### 00:29:22 - AI Engineer PARIS - NVIDIA - Sonar - Engineer PARIS - Ocaml - ss(o)no [NVIDIA logo] [ ### 00:29:49 - NVIDIA - AI Engineer Paris - Cockroach Labs - Mistral - FACTORY - SENTRY - Sonar - CLOUDFLARE - Daytona - langfuse by ClickHouse - Modal - neo4j - Qdrant - CodeRabbit - cominty - descope - Latitude - FIMO - MAKORA - stripe - ZenML labs - Backblaze - Notion - SIERRA [Grid of company logos, including NVIDIA, Cockroach Labs, Mistral, Sentry, Sonar, Cloudflare, Daytona, Langfuse, Modal, Neo4j, Qdrant, CodeRabbit, Cominty, Descope, Latitude, Fimo, Makora, Stripe, ZenML Labs, Backblaze, Notion, Sierra, and Factory, with the "AI Engineer Paris" logo frequently repeated.]