CPU-Only Local Image Generation

Local image generation on hardware with no usable GPU acceleration: AMD Ryzen (integrated Radeon 680M / RDNA2, gfx1035), Fedora Linux. Same constraint-driven approach as agent-under-manager-hierarchy and hive-mind-agents — work within real hardware limits, measure everything, don't assume online benchmarks apply to this specific machine.

Why this exists

AMD's ROCm compute stack does not support this GPU target (confirmed via driver logs: "dropping ROCm device — no rocblas support for gfx target"). Vulkan compute was also attempted and did not work. A prior ComfyUI attempt on this same hardware, without resource monitoring in place at the time, took 3+ hours for a single image at standard step counts (30-50). CPU-only is the realistic path for this hardware — not a temporary workaround, a starting constraint.

Approach

Instead of standard Stable Diffusion (30-50 inference steps), this uses OpenVINO (optimum-intel) for CPU-optimized inference paired with a Latent Consistency Model (LCM) checkpoint that needs only 4-10 steps — roughly an order of magnitude less compute per image.

python3 -m venv venv
source venv/bin/activate
pip install torch --index-url https://download.pytorch.org/whl/cpu
pip install --upgrade-strategy eager optimum[openvino] diffusers gradio

from optimum.intel import OVStableDiffusionPipeline
from diffusers import LCMScheduler

pipe = OVStableDiffusionPipeline.from_pretrained(
    "OpenVINO/LCM_Dreamshaper_v7-fp16-ov", safety_checker=None
)
pipe.scheduler = LCMScheduler.from_config(pipe.scheduler.config)  # required -- see Findings
image = pipe("prompt here", num_inference_steps=8, guidance_scale=1.6).images[0]

A local Gradio GUI (gradio_app.py) wraps this with adjustable steps/guidance sliders and loads the model once at startup rather than per-generation.

Findings so far (see TESTING.md for full logged data)

• Result vs. baseline: ~50-85s per image at 6-10 steps, vs. 3+ hours for the prior ComfyUI attempt at standard step counts. Roughly a 70-150x speedup from the step-count reduction alone.
• Scheduler matters more than sampling parameters. An LCM checkpoint run under the wrong (default) scheduler produces washed-out, low-contrast, blurry output regardless of guidance scale — this looks like an NSFW-filter artifact but isn't; it's a scheduler mismatch. Fix: explicitly set LCMScheduler after loading.
• Guidance scale had near-zero effect on generation time, only on output character. Step count is what drives time.
• RAM usage was flat regardless of prompt content or settings (~10.3-10.4GB / 77-78% of 13.4GB total, consistently, across all 16 test-grid runs) — driven by the loaded model itself, not by what's being generated. This leaves meaningfully less headroom than initially assumed; worth watching closely before testing larger models (e.g. SDXL-based checkpoints).
• Anatomy failures are structural, not random noise. Hands consistently failed at digit count and fingernail placement; a cartoon fox consistently confused its tail with a leg (3 of 4 test runs). More steps improved some failure modes (text legibility) but not others (hand anatomy stayed broken at both 6 and 10 steps).
• Significant, unprompted demographic homogeneity. With no age, gender, or race specified in the prompt, portrait generations defaulted to ~50-year-old Caucasian males with 4/4 consistency across the test grid; hand generations showed zero skin-tone variability. This is a real limitation of the checkpoint's training data/defaults, not a one-off — documented as a measured finding, not a complaint.

Status

Baseline (SD1.5-class LCM Dreamshaper) tested and logged. SDXL-class comparison (heavier model, better anatomy in general but higher resource cost) planned as next test.