Getting started with local image generation
Running an image model on your own machine is a different job from running a chat model, even though both are covered here, in image generation and local LLMs. The hardware questions are similar in shape but the answers land in different places. This page covers what changes, and the two decisions you need to make before you generate anything.
How image generation differs from text generation
Most local image models are diffusion models. Instead of producing output one token at a time, they start from noise and refine the whole image over a fixed number of steps. Every step touches the entire latent image, so the work per step is set by the resolution you asked for, not by how long the prompt was.
That changes what your hardware limits look like.
- VRAM capacity decides what you can attempt. The model weights, the text encoders and the working latents all have to fit at once. If capacity is tight, you are capped on resolution and on how many images you can generate in one batch. Running out is usually an abrupt failure rather than a slowdown.
- Memory bandwidth decides how fast it goes. Once everything fits, the step rate is largely a function of how quickly the card can move weights and activations. A card with the same capacity but slower memory will produce the same image, later.
- Generation is bursty, not conversational. A text model streams output you can read as it arrives. An image arrives all at once at the end of the run, so a slow setup feels slower than the raw numbers suggest.
There is also no long-running conversation state to hold, so the KV cache and context window concerns that dominate local LLM planning mostly do not apply. The trade is that you cannot shrink the working set by keeping prompts short.
If you are not sure where your machine sits, hardware and the GPU pages cover where it lands.
Pick a runtime
The app, sometimes called a runtime, is what loads the model and turns your prompt into an image. The image runtimes index covers the options in detail, but in short:
- ComfyUI builds generation as a node graph. Everything is explicit and reconfigurable, which is powerful once you know what the pieces are and noisy before that.
- SD WebUI is a form-driven interface: prompt, settings, generate. It is the shortest path from install to first image.
- InvokeAI sits between the two, with a canvas-style workflow aimed at iterating on an image rather than firing off one-shot prompts.
Any of them will run the common model families. Pick the interface you can tolerate while you are still learning, and switch later if you need to. Model files are portable between them.
Pick a model family
Then choose what to load. The models index explains what each family is and what it is good at, with pages for Stable Diffusion and Flux. Families differ in how much memory they want, how they interpret prompts, and how large the community ecosystem of fine-tunes and LoRA adapters around them is.
The practical filter is memory. Start with a variant that fits your card comfortably rather than the largest one that technically loads, because a setup with headroom lets you raise resolution and iterate quickly.
What the first run looks like
- The first generation after launching is slow. Weights have to be read from disk into memory, and some apps compile or cache work on first use. Judge speed from the second image onward.
- Default settings produce a mediocre image. That is normal. Step count, sampler and resolution all matter, and every family has its own sensible defaults.
- Expect to iterate. Local generation is cheap once running, so the workflow is to generate several variations and keep the good ones rather than to perfect a single prompt.
- Keep your model files organised from the start. See organising model files before your downloads folder becomes unmanageable.