AI-Powered Food Image Generation System at Scale

delivery_hero · E-commerce · 2025 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Food-delivery menu image generation

Delivery Hero needed to generate high-quality product images at scale because missing menu images hurt conversion, but external image-generation APIs were too expensive for projected volumes.

Constraints:

Architecture

Delivery Hero built a production food-image generation system with two generation paths: text-to-image from product metadata and image inpainting from vendor assets. The production design self-hosted Stable Diffusion variants on GPU-backed EKS, used KEDA to autoscale model workers, evaluated generated images with computer-vision guideline checks, routed requests across model versions for local dishes, and kept restaurant owners/content teams in the final selection loop.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  product-metadata-extractor["product-metadata-extractor"]
  text-to-image-generator["text-to-image-generator"]
  inpainting-pipeline["inpainting-pipeline"]
  stable-diffusion-serving-cluster["stable-diffusion-serving-cluster"]
  grounding-dino-detector["grounding-dino-detector"]
  keda-autoscaler["keda-autoscaler"]
  quality-scoring-system["quality-scoring-system"]
  model-routing-layer["model-routing-layer"]
  restaurant-owner-review["restaurant-owner-review"]
  post-processing-store["post-processing-store"]
  product-metadata-extractor --> text-to-image-generator
  product-metadata-extractor --> inpainting-pipeline
  text-to-image-generator --> stable-diffusion-serving-cluster
  inpainting-pipeline --> grounding-dino-detector
  inpainting-pipeline --> stable-diffusion-serving-cluster
  stable-diffusion-serving-cluster --> keda-autoscaler
  stable-diffusion-serving-cluster --> quality-scoring-system
  stable-diffusion-serving-cluster --> model-routing-layer
  text-to-image-generator --> post-processing-store
  inpainting-pipeline --> post-processing-store
  quality-scoring-system --> restaurant-owner-review
  post-processing-store --> restaurant-owner-review
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
product-metadata-extractor pulls product names, categories, descriptions, attributes, and material/background preferences for generation prompts text-to-image-generator, inpainting-pipeline
text-to-image-generator generates product images directly from textual and categorical product context stable-diffusion-serving-cluster, post-processing-store
inpainting-pipeline selects vendor images, detects the food object, masks it, and runs image-to-image inpainting grounding-dino-detector, stable-diffusion-serving-cluster, post-processing-store
grounding-dino-detector detects food objects in vendor images so the inpainting pipeline can mask the right region inpainting-pipeline
stable-diffusion-serving-cluster hosts Stable Diffusion model variants on GPU-backed Kubernetes workers keda-autoscaler, quality-scoring-system, model-routing-layer
keda-autoscaler scales inference nodes according to message load stable-diffusion-serving-cluster
quality-scoring-system uses computer-vision checks for object placement, composition, color, content, and safety stable-diffusion-serving-cluster, restaurant-owner-review
model-routing-layer routes product requests to general or fine-tuned model versions based on product metadata stable-diffusion-serving-cluster
restaurant-owner-review lets content teams or restaurant owners choose the most appropriate generated images before production use post-processing-store
post-processing-store stores generation outputs in Postgres and GCS for review and publishing restaurant-owner-review

Data flow

Product names, categories, descriptions, attributes, and vendor background preferences feed a text-to-image prompt path; vendor images feed an inpainting path that selects the right source image, detects and masks the food object, then generates replacements. Model outputs are written to Postgres and GCS, surfaced through Google Forms and later restaurant-owner interfaces, then measured through guideline-scoring CV models and A/B conversion tests.

3 supporting quotes
“We provide the information regarding the product name, menu category, descriptions, some disrelated attributes that were extracted with an additional text classification model”article, stated
“We had to detect the right image within the set of images of each of the vendors. Then the second step was to detect the food object on this image to mask it”article, stated
“It started with data extraction from our data warehouse, then going through the generative flow, and the final outputs were transitioned to Postgres and GCS.”article, stated

Why this architecture

The architecture follows the production constraints: DALL-E-like hosted generation was too expensive at tens of millions of images, a single generic model missed local dishes, and image quality could not be optimized without automated measurement. Self-hosting, GPU autoscaling, model routing, and CV quality gates let the team lower cost while preserving restaurant-appropriate output quality.

3 supporting quotes
“we need to host our model internally within our infrastructure in order to reduce the costs.”article, stated
“Since we were hosting several versions of the models in our production inference cluster, that wasn't a problem for us to just serve several versions and route the request based on the product meta-attributes.”article, stated
“First, automate the way you measure the quality of your generative AI solution, and only then work on fine-tuning the actual generative part.”article, stated

Models used: Stable Diffusion Juggernaut V9 · Stable Diffusion XL · OpenAI DALL-E · Grounding DINO · Recognize Anything · EasyOCR · CLIP · OneTrainer fine-tuned Stable Diffusion

Scale

Alternatives considered (roads not taken)

Continue hosted DALL-E-style image generation

Rejected because: The team moved to internal hosting because hosted generation cost was too high for expected image volumes.

“the actual reason for us to migrate into self-hosted generative model was to actually optimize it for cost efficiency in the end.”article, stated
“It was already lower than the cost that we were paying with OpenAI, DALL·E, which was 2 cents per image.”article, stated

Thousands of LoRA adapters for local dishes

Rejected because: The number of local dishes would have made adapter generation and serving infrastructure too complex.

“we had thousands of local dishes. That would mean that we have to generate thousands of different LoRAs and also serve them, which wasn't that easy.”article, stated

Use Stable Diffusion outputs without a repeatable quality benchmark

Rejected because: The team needed automated scoring against product-image guidelines before judging whether a new model was better.

“how can we actually understand if a new version of the generative model that we deploy is better than the previous one?”article, stated
“Preparing for each of those aspects, a separate computer vision model that would classify if the image is aligned with our guidelines or not”article, stated

Run every component on the same GPU-heavy environment

Rejected because: Different components had different hardware and driver requirements, so separating environments avoided overprovisioning lighter steps.

“For each of the component, we had a separate environment, because, for instance, object detection, Grounding DINO model required its own drivers for running, and we were running it on GPU”article, stated

Patterns

eval-driven-development (generative-quality-measurement)

Delivery Hero created automated CV evaluators for image guidelines before iterating on model versions and fine-tuning.

“The idea was that we had some product guidelines regarding how our images should look like.”article, stated

safety-policy-enforcement (image-quality-and-safety-filtering)

The production safety layer detects creatures, people, malformed text, and layout violations before images can reach users.

“The first part of the component of this safety system was creature and people detection. We were using a customized version of the Recognize Anything model.”article, stated

latency-optimization (diffusion-inference-optimization)

The team optimized generation time with GPU choice, float16 precision, Tiny VAE, classifier-free guidance adjustments, and fewer diffusion steps.

“The first and the most obvious choice is to migrate from float 32 to float 16, which was already four times more efficient.”article, stated

cost-aware-routing (self-hosted-generation)

Delivery Hero migrated away from DALL-E toward self-hosted Stable Diffusion and L4 GPUs to lower cost per generated image.

“the cost per image generated, we have had a clear winner, which is L4, which introduced us at 50% decrease in terms of cost per generated image.”article, stated

model-routing (food-category-specialization)

Multiple model versions are served in production and requests route by product metadata to avoid fine-tuning regressions on common dishes.

“Since we were hosting several versions of the models in our production inference cluster, that wasn't a problem for us to just serve several versions and route the request based on the product meta-attributes.”article, stated

human-in-the-loop-gate (restaurant-owner-review)

Restaurant owners review suggested generated images and choose the image that best represents their menu item.

“Every restaurant owner could go to their application, choose the product that didn't have any images, see the suggestions, and choose the most relevant based on their opinion”article, stated

Tradeoffs

How to support thousands of local dishes.

Chose full model fine-tuning over thousands of separate LoRA adapters.

Rationale: Serving and managing thousands of adapters would have added too much infrastructure complexity.

“we had thousands of local dishes. That would mean that we have to generate thousands of different LoRAs and also serve them, which wasn't that easy.”article, stated

When to optimize generative AI quality.

Chose automate measurement before fine-tuning over tuning the generator without a repeatable quality metric.

Rationale: The team concluded that model improvement depends on first being able to measure system quality.

“First, automate the way you measure the quality of your generative AI solution, and only then work on fine-tuning the actual generative part.”article, stated

Gotchas (what bit them)

CLIP failed unexpectedly on non-Latin product names.

Root cause: Chinese and Arabic names did not work well inside the full Stable Diffusion generation process despite CLIP's multilingual training.

Resolution: Translate non-Latin product names to English before generation.

“Chinese or Arabic names of the products, for some reason, weren't generated well. That was weird, because CLIP was actually trained on around 50 different languages”article, stated

The multi-cloud architecture slowed delivery.

Root cause: Splitting infrastructure between GCP and AWS introduced integration work that took longer than planned.

Resolution: The talk identifies this as a mistake and a lesson to avoid unnecessary multi-cloud complexity.

“the decision was made to migrate part of the services, part of our infrastructure to AWS, because some of the services were cheaper there. That was a mistake.”article, stated

Generative image quality lacked a natural ground truth metric.

Root cause: Image generation quality is subjective and cannot be measured with simple supervised accuracy.

Resolution: Use product-guideline-aligned CV models to score positioning, composition, color, and content.

“Then I have realized that there are no ground truth. This is the general problem of all the generative AI solutions”article, stated

Fine-tuning for local dishes hurt some common foods.

Root cause: Specializing the denoising model on local cuisines changed behavior for broader food categories.

Resolution: Serve several model versions and route by product metadata.

“it has lost the concept of some of the other dishes, like pizzas became a little bit less appetizing.”article, stated

Evaluation

Delivery Hero evaluates generated food images with guideline-specific CV models, benchmark datasets, A/B conversion tests, and cost/time profiling of inference configurations.

Metrics: quality score · conversion lift · cost per image · generation time · daily generated images · restaurant-owner acceptance

“The dataset for this benchmarking framework consisted of 1000 product descriptions. Each of the versions of the models that we were iterating on was prompted with the same prompt”article, stated
“After conducting the A/B test, we have observed 6% to 8% increase in terms of conversion rate from menu to cart when we add an image to a product.”article, stated

Outcomes

The EKS inference cluster scaled from 0 to 36 nodes using KEDA, and the economics were evaluated for tens to hundreds of millions of images.

“Depending on the load, our cluster scaled from 0 to 36 nodes and back to 0. This allowed us to already cover around 100,000 images to be generated daily.”article, stated
“we have generated around a million images. More than 100,000 products have generated images on our platforms.”article, stated