Image Generation Without a GPU: What Works on CPU

Short answer: yes, and on a normal desktop CPU a 512x512 image takes about 0.82 seconds — if you use a 1-step distilled model with OpenVINO. FastSD CPU's published benchmarks on an Intel Core i7-12700 are 0.82s for SDXS-512-0.9, 1.7s for SD Turbo and 2.5s for SDXL Turbo, all at 512x512 in a single step with the tiny TAESD decoder. The same project measures FLUX.1-schnell at int4, 3 steps, 512x512 at 4 minutes 30 seconds — and it wants roughly 30GB of system RAM. So "slow" is not one number. It is a choice you make when you pick the model.

That is the answer nobody puts in the first paragraph, so here it is with the caveat attached: those are one project's measurements on one named CPU, not ours, and your box will differ. The rest of this page explains why the spread is so wide, what your own hardware will do, whether your integrated graphics can help, and which models to write off entirely.

---

Why Step Count Is Everything

A CPU is roughly 10-50x slower than a mid-range GPU at the dense matrix math diffusion models need — so the only way to win is to do that math fewer times.

A diffusion model generates an image by running the same denoising network over and over. Classic Stable Diffusion 1.5 does that 20-30 times. SDXL commonly does 30-50. That repetition is invisible on a GPU and fatal on a CPU: 25 steps means 25 full forward passes before you see anything.

The last few years produced a family of distilled models that collapse that loop:

• Adversarial Diffusion Distillation (ADD) gave us SD Turbo and SDXL Turbo — usable output in 1 step.
• Latent Consistency Models (LCM and LCM-LoRA) get SD 1.5-class checkpoints to 2-3 steps.
• SDXS-512-0.9, Hyper-SD and SDXL-Lightning push 1-2 step generation further.
• Newer entrants like Z-Image-Turbo (6B parameters, Apache-2.0, 8 NFEs) and FLUX.2 [klein] 4B aim at 4-8 steps with much better prompt following.

Here is the mental model: the cost of an image is roughly (model size) x (steps). A 1-step run of a small distilled UNet is dozens of times cheaper than an 8-step run of a 6B transformer. That single sentence explains every number below, and it is why "just use SD 1.5" is bad advice when it comes without a step count attached.

The second lever is the decoder. Turning the latent into pixels normally runs a full VAE. Swapping in a tiny autoencoder (TAESD / TAESDXL) is where a big chunk of the CPU speedup comes from: FastSD CPU's SDXS number drops from 3.8s with plain OpenVINO to 0.82s once TAESD is enabled — the decode was over three quarters of the wall clock.

---

The Measured Numbers

Every figure in this table is published by the FastSD CPU project and measured on an Intel Core i7-12700 — a 12-core (8P+4E), 20-thread desktop chip from 2021. They are not our measurements.

Read it as "what a mid-range desktop CPU of that generation does". Scale roughly by thread count and clock for your own box; an 4-core ultrabook chip will be meaningfully slower, a 16-core Ryzen faster.

Source: the FastSD CPU README benchmark tables, Core i7-12700. FastSD CPU is MIT-licensed with roughly 2,100 GitHub stars at the time of writing.

Three things fall out of that table:

1. OpenVINO is worth roughly 2x on its own, which matches the project's own claim ("We can get 2x speed improvement when using OpenVINO"). It converts the model to int8 and runs it through Intel's inference runtime instead of PyTorch's generic CPU kernels.
2. The tiny decoder is worth more than OpenVINO on the fastest configurations. On SDXS it took 3.8s down to 0.82s.
3. Resolution costs more than you expect. The jump from 512x512 to 768x768 is 2.25x the pixels and shows up almost linearly in the numbers.

What about plain SD 1.5 at 20-30 steps?

This is the path most people try first, and it is the reason "CPU image generation" has a reputation. We do not have a published, comparable measurement for it, so here is the arithmetic instead, clearly labeled as arithmetic: SD Turbo at 1 step in plain PyTorch takes 7.8s end-to-end on that i7-12700, and that figure already includes one-off text encoding and VAE decode. A stock SD 1.5 run at 20-25 steps drives a comparably sized UNet 20-25 times. Even being generous about the fixed overhead, you land at roughly 2-4 minutes per 512x512 image. That is the number the "it works!" pages leave out.

Treat that as an estimate to sanity-check against your own run, not a measurement. The fix is the same either way: switch to a distilled checkpoint and drop the step count.

---

Does More System RAM Help?

No. RAM is a pass/fail gate, not a speed dial. Below the threshold for your pipeline you either fail to load or you swap to disk and everything crawls. Above it, an extra 16GB changes nothing about how fast a matrix multiplies.

FastSD CPU documents its minimum system RAM per mode:

The project notes that enabling the tiny TAESD decoder saves about 2GB, so standard OpenVINO mode drops to roughly 9GB. It also flags one setting that quietly costs you both: guidance scale above 1.0 increases RAM usage and slows inference, so leave CFG at 1.0 on the distilled models that expect it.

The most useful data point for very low-end machines: the project reports FastSD CPU running on a Raspberry Pi 4 with 4GB of RAM plus 8GB of swap. Swap makes it work; it does not make it pleasant. If you are that tight on memory, target the LCM path (2GB) rather than the OpenVINO one (11GB).

What does move the needle on speed: more physical cores, AVX2/AVX-512 support, and the int8 OpenVINO conversion. If you are choosing hardware around this, our budget local AI machine guide and the honest laptop guide cover what actually matters.

---

The Intel iGPU and NPU Path

If you have Intel integrated graphics, you have an accelerator — and switching to it is one environment variable.

FastSD CPU's OpenVINO backend can target the CPU, the integrated GPU, or the NPU on Intel Core Ultra chips. The switch is:

# Linux / macOS
export DEVICE=GPU
./start-webui.sh

# Windows
set DEVICE=GPU
start-webui.bat

The project has supported Intel AI PC GPU and NPU targets since September 2024, and added Core Ultra Series 2 (Lunar Lake) NPU support in November 2024. The NPU path has real constraints worth knowing before you spend an evening on it:

• Only one converted model is currently supported on NPU: rupeshs/sd15-lcm-square-openvino-int8.
• You must select LCM-OpenVINO mode, pick that model in settings, then set DEVICE=NPU.
• The tiny autoencoder does not work in NPU mode, which costs you the single biggest speedup from the table above.
• Execution is heterogeneous — text encoder and UNet run on the NPU, the VAE runs on the GPU.
• Your NPU driver needs to be current.

We have not benchmarked an Intel iGPU or NPU ourselves, and FastSD CPU publishes its AI PC results as a screenshot rather than a table, so we are not going to quote a speedup figure we cannot verify. What to check on your own machine: run the built-in benchmark once with the default CPU device and once with DEVICE=GPU, same model, same steps, same resolution, and compare. The project ships benchmark.bat (PyTorch) and benchmark-openvino.bat (OpenVINO) on Windows, or pass -b in CLI mode on any platform. That is a five-minute experiment with a real answer, which beats anyone's estimate.

A word of caution on AMD and Apple: the OpenVINO path is Intel-specific. On an Apple Silicon Mac, FastSD CPU supports DEVICE=mps to use the Metal GPU instead — which is a different (and generally much better) story than true CPU-only generation.

---

Z-Image-Turbo on CPU: What We Could and Could Not Verify

Z-Image-Turbo has a genuine CPU path through stable-diffusion.cpp, but no one — including its authors — publishes CPU timings, so treat it as "worth trying" rather than "known good".

Here is exactly what is verified and what is not.

Verified from the official model card (Tongyi-MAI/Z-Image-Turbo on Hugging Face): 6B parameters, Apache-2.0, 8 NFEs (the reference code uses num_inference_steps=9 to produce 8 DiT forward passes), 882,177 downloads in the last month and 5.12k likes. Stated hardware: it "fits within 16G VRAM consumer devices", with sub-second latency quoted on H800 datacenter GPUs. CPU is not mentioned anywhere on the card. So the authors have not claimed it, and we are not going to claim it for them.

Verified from stable-diffusion.cpp (MIT, ~6,800 GitHub stars): the project's model list includes Z-Image, and its build docs contain an explicit CPU-only target — "If you don't have a GPU or CUDA installed, you can build a CPU-only version", which is a plain cmake .. with no backend flag. Its Z-Image doc says it runs "on GPUs with 4GB of VRAM — or even less". GGUF quants of Z-Image-Turbo published by the maintainer run from 2.59GB (Q2_K) to 6.58GB (Q8_0), with Q4_K at 3.86GB.

The part people forget: Z-Image uses Qwen3-4B as its text encoder. That is a second model you have to load — about 2.5GB at Q4_K_M — plus a VAE. So a realistic CPU memory budget for Z-Image-Turbo at Q4_K is roughly 3.9GB + 2.5GB + VAE, call it 7-8GB of RAM before the runtime's own working set. On an 8GB machine that is tight; 16GB is comfortable.

The documented command (from the project's own Z-Image doc, Windows form):

sd-cli --diffusion-model z_image_turbo-Q3_K.gguf \
  --vae ae.sft \
  --llm Qwen3-4B-Instruct-2507-Q4_K_M.gguf \
  -p "your prompt here" \
  --cfg-scale 1.0 --steps 8 -H 1024 -W 512 \
  --offload-to-cpu --diffusion-fa -v

Our honest expectation, stated as arithmetic and not measurement: SD Turbo is a sub-1B UNet run once. Z-Image-Turbo is a 6B transformer run eight times, plus a 4B language model for the text encode. That is tens of times more work per image on the same silicon. If SD Turbo takes 1.7 seconds on an i7-12700, Z-Image-Turbo on the same chip lands in minutes, not seconds. Run it if you want the much better prompt adherence and you are happy waiting; do not run it if you want to iterate.

If you have any discrete GPU at all, the Z-Image-Turbo ComfyUI guide is the faster route.

---

What to Skip Entirely

Some things simply are not worth the CPU time, and saying so is more useful than another workaround.

• FLUX on CPU — don't. 4 minutes 30 seconds per 512x512 image at 3 steps and int4, per FastSD CPU's own measurement, and its docs warn that FLUX at 512x512 needs around 30GB of system RAM. That is a workstation's memory budget for one image every four and a half minutes. If you need FLUX specifically, get a card — our 8GB FLUX model picks and the low-VRAM FLUX guide show how little you actually need.
• Stock SDXL at 30-50 steps. Same reasoning as SD 1.5, several times worse. Use SDXL Turbo or SDXL-Lightning instead — same model family, 1-2 steps.
• Anything above 768x768. FastSD CPU supports 1024, but the cost scales with pixel count and there is no distillation trick that undoes it. Generate small, then upscale — local AI upscaling is far cheaper per pixel than generating large.
• Guidance scale above 1.0 on distilled models. It costs RAM and speed and those models were trained to run at CFG 1.0.
• Video models. Not a close call on CPU.

---

Install It in 10 Minutes

Two projects cover the whole no-GPU space: FastSD CPU for speed, stable-diffusion.cpp for breadth of models.

FastSD CPU (Python 3.10+, uses the uv package manager, runs on Windows, Linux, Mac, Android+Termux and Raspberry Pi 4):

# Linux
chmod +x install.sh && ./install.sh
./start-webui.sh          # web UI
./start.sh                # desktop GUI

# Windows
install.bat
start-webui.bat

Then in the UI: pick LCM-OpenVINO mode, choose SD Turbo or SDXS-512-0.9, set steps to 1, guidance to 1.0, enable the tiny autoencoder, and generate. That configuration is the one the sub-2-second numbers came from.

stable-diffusion.cpp (C/C++, ggml-based, AVX/AVX2/AVX-512, no Python at all):

git clone --recursive https://github.com/leejet/stable-diffusion.cpp
cd stable-diffusion.cpp
mkdir build && cd build
cmake ..                       # CPU-only build
cmake --build . --config Release

./bin/sd-cli -m v1-5-pruned-emaonly.safetensors -p "a lovely cat"

Add -DGGML_OPENBLAS=ON at the cmake step if you have OpenBLAS installed. This is the path to take when you want the newer models — it supports SD 1.5, SDXL, SD3/3.5, FLUX.1/FLUX.2, Qwen Image, Chroma and Z-Image among others, all in GGUF.

If you eventually add a graphics card, everything you learned here transfers: see the full ComfyUI guide and our best GPU for image generation breakdown, and check what fits with the VRAM calculator.

---

Verdict

1. CPU-only image generation is genuinely fine now — for 1-4 step distilled models. Sub-second to a few seconds per 512x512 image on a 2021 desktop chip, per FastSD CPU's published benchmarks.
2. The number that matters is steps x model size, not "CPU vs GPU". Every disappointing CPU experience traces back to running a 20-50 step workflow.
3. Turn on the tiny decoder. On the fastest configurations it saved more time than OpenVINO did.
4. More RAM will not make it faster. Meet the minimum for your mode (2GB LCM, ~9-11GB OpenVINO) and stop there.
5. Try your Intel iGPU — it is one environment variable. Then benchmark it yourself instead of trusting anyone's number, including ours.
6. Skip FLUX, skip stock SDXL, skip 1024x1024. Generate small and fast, upscale after.

If your real goal is running language models rather than images on the same machine, the constraints are completely different — memory bandwidth rather than compute — and running LLMs on CPU only covers that side properly.

---

Sources

• FastSD CPU (rupeshs/fastsdcpu) — all Core i7-12700 latency figures, minimum RAM table, OpenVINO/iGPU/NPU support notes, Raspberry Pi 4 report. MIT licensed.
• stable-diffusion.cpp (leejet) — CPU-only build instructions, supported model list, Z-Image command line and GGUF quant sizes. MIT licensed.
• Tongyi-MAI/Z-Image-Turbo model card — 6B parameters, Apache-2.0, 8 NFEs, 16GB VRAM target, H800 latency claim, download and like counts.
• OpenVINO toolkit — the Intel runtime behind the int8 CPU/iGPU/NPU path.

Figures were checked against these sources at the time of writing. Benchmarks published by a project about its own software are still that project's numbers — verify on your hardware with the built-in benchmark before making a purchase decision.

---

FAQ