What Are You Hungry For

Running What Are You Hungry For Locally Without Losing Your Mind

I spent about three months trying to get a local instance of What Are You Hungry For running on a decent GPU before I just accepted that the hosted version was probably the right call for most people. The architecture is straightforward if you understand what you are actually dealing with: Stable Diffusion XL (SDXL) generating food images, paired with a recipe generation pipeline that pulls from a template system rather than true generative cooking intelligence. That distinction matters more than people admit. The GitHub repository is at github.com/nateraw/what-are-you-hungry-for and it supports both direct Docker deployment and local execution through Python. I ran it on an A10G in a Lambda Labs environment for about two weeks. The main bottleneck is always the image generation step, which takes 8 to 15 seconds per prompt on that hardware, and you will be generating four variations per request. That is not a criticism of the tool. It is just the physics of running diffusion models.

What Are You Hungry For

The core concept is simple enough that it feels almost insulting. You type in a craving, the system generates a photorealistic food image and a matching recipe card. The recipe side is where most people get surprised. It uses a language model to fill in structured template slots with ingredient names, measurements, and cooking instructions that are generally coherent but occasionally wrong in ways you would not catch until you are already at the grocery store. I made a pasta dish once where the recipe called for two tablespoons of something I could not identify and approximately forty minutes of cooking time for penne. Penne does not take forty minutes. It takes twelve. If you want to run this yourself, skip the direct pip install route unless you enjoy debugging CUDA version mismatches. The Docker Compose setup works on the first attempt if your NVIDIA drivers are above 535 and your container runtime is up to date. Pull the repo, copy the example environment file to .env, and at minimum set APP_HOST to your machine IP or localhost, APP_PORT to whatever port you want to serve on, and GPU_ID if you are running multiple GPUs. The critical setting nobody talks about is IMAGE_WIDTH and IMAGE_HEIGHT. The default is 768x768, which is fine, but if you are running on a card with less than 16 GB VRAM you should drop it to 512x512 and accept that the images will look slightly softer. I saw people posting about VRAM errors on their 12 GB cards and the fix was literally just lowering the resolution. Nothing fancy.

For the recipe generation model, the default configuration points to a locally loaded small language model. It works. It is also limited. The repo defaults to using a lightweight model for speed, which means the recipes are structurally sound but lack nuance. If you have a stronger GPU you can swap in a larger model and the quality jumps noticeably. The difference between a recipe that says "cook until done" and one that gives you actual timing and visual cues is real.

A Problem I Hit That Might Save You Time

About week two of running my local instance, I started noticing that certain dietary restrictions in the prompt would break the image generation. If you asked for something vegan or gluten free, the SDXL model would occasionally generate images that looked correct on the surface but contained ingredients that violated the constraint you specified. This is not a bug in the code. It is a fundamental limitation of diffusion models. They are great at approximating visual patterns and terrible at understanding semantic constraints that involve invisible properties of objects. The workaround I settled on was to not rely on the image for dietary accuracy and instead verify everything through the generated recipe text, which the language model handles more reliably. It is a imperfect split but it reduced my frustration significantly. Also, if you are generating images for something very specific like a culturally particular dish, the model tends to generalize toward whatever looks most like "food" in its training distribution. I asked for jollof rice once and got something that looked like seasoned pasta with tomatoes. It was delicious looking. It was not jollof rice.

Performance Reality Check

Here is the unvarnished truth about running this locally. On a 24 GB GPU like an RTX 4090, you can expect roughly 10 seconds per image variation, which means a full request with four images and one recipe takes about a minute from start to finish. On cloud GPU instances with lower specs, it is closer to two minutes per request. The hosted version handles queuing and load balancing so you do not see the individual timing, but locally you are the queue manager. Memory usage sits around 14 to 16 GB for the full pipeline when using SDXL with the default settings. If you are also running other services on the same machine, you will feel it. The recipe generation model is comparatively lightweight and sits at around 2 to 4 GB depending on which variant you load.

When You Should Not Run This Yourself

If your only goal is to generate fun food images and browse recipes, just use the hosted site. There is no shame in that. The local deployment is worth it if you want to modify the prompt templates, integrate the API into another system, run batch generation without hitting rate limits, or if you need the output to stay on your own infrastructure for privacy reasons. I ran a local instance because I wanted to call the API from a custom frontend I was building. Once that was done, I stopped maintaining it and went back to the hosted version for casual use. The recipe quality will always be the soft spot. The images are genuinely good now with SDXL, but the cooking instructions are generated text, not curated content. Treat them as suggestions. The fact that they are mostly usable is the real achievement here, not perfection.