A product concept. A woodland photograph. A rainy street in watercolor. The useful part of local image generation is being able to change the prompt and try again, without sending the request to an external service.
Our free Paiton profile brings that workflow to FLUX.2 klein 4B on one AMD Radeon AI PRO R9700, with a ready-to-run ComfyUI setup.
At 1024 × 1024, four steps and batch size one, complete warm generation averages 1.054 seconds per image, against 1.258 seconds for the strongest stock configuration we qualified. That is 16.2% lower generation latency and 19.4% more projected images per hour.
Memory use falls too: peak Torch allocation drops from 19.3 to 12.9 GiB, a reported 33.4% reduction. The text encoder, transformer and VAE stay on the GPU, with no CPU offload.
The headline timing is warm prompt-to-image generation, not startup or browser-click latency. It includes text encoding, denoising, VAE decoding and conversion to a PIL image; it excludes PNG encoding, file writing and the interface.
The fox pictured above is an actual retained benchmark output from the Paiton FLUX.2 klein profile, seed 42.
Start creating locally
On a Linux R9700 workstation with Docker, the Compose plugin and a working AMD GPU driver, launch the included workflow with:
git clone --depth 1 \
--branch paiton-flux2-klein-gfx1201-v1.0.1 \
https://github.com/Eliovp-BV/paiton-vllm-plugin.git
cd paiton-vllm-plugin
./models/FLUX.2-klein/launch.sh
Open ComfyUI at localhost:8188, edit the prompt and click Run. The connected workflow includes an engine selector for Paiton or Stock (Diffusers), a seed control, an image preview and a Save Image node. Images are saved in paiton-images/.
The first image loads and compiles the selected engine and can take several minutes. Later prompts reuse it. Switching engines unloads the previous model and incurs setup again; they are not held in GPU memory together. To compare outputs, keep the prompt and seed unchanged and select fixed in the seed control.
The tested host has 16 GB of RAM. We recommend 24 GB of system RAM and 60 GB of free disk space for compilation headroom, containers, model files, caches and outputs. Downloads and caches persist between starts. Once setup is complete, generation stays local; no paid inference service or cloud GPU is required.
The model guide also covers a lightweight prompt interface, terminal generation and adding the node to an existing ComfyUI installation.
What the speed result includes
Both engines use the same model checkpoint and generation settings. The comparison measures the whole warm generation loop rather than extrapolating from a faster individual kernel.
| Generation metric | Qualified stock + weight cache | Paiton |
|---|---|---|
| Mean warm seconds per image | 1.258 | 1.054 |
| Projected images per hour | 2,862 | 3,416 |
Projected output is 3600 / mean generation seconds. It is not an hour-long throughput measurement, and it excludes PNG writing and time spent editing prompts. The 19.4% output increase and 16.2% latency reduction express the same improvement in different ways.
The interface has its own costs. In a separate ComfyUI validation, two warm workflow executions took 1.408 and 1.404 seconds, averaging 1.406 seconds including local engine transport, image handling and saving. Those server-side timings exclude browser display and are not the headline prompt-to-PIL benchmark.
Lower memory use, without CPU offload
A model's download size is not its runtime memory requirement. The full pipeline also needs its text encoder, decoder, activations, temporary buffers and compilation allocations.
Paiton reduces all three reported memory measures in this comparison:
| Memory measurement | Qualified stock + weight cache | Paiton |
|---|---|---|
| Peak Torch allocation | 19.3 GiB | 12.9 GiB |
| Peak Torch reservation | 22.1 GiB | 14.1 GiB |
| Maximum sampled driver VRAM | 23.0 GiB | 14.6 GiB |
12.9 GiB is not total VRAM consumption. Allocation records tensor memory; reservation records memory held by the Torch allocator; driver samples include memory outside that allocator. These views overlap and must not be added together.
Allocation and reservation peaks include compilation, warmup and generation. Driver sampling also includes loading. Values are rounded and use binary GiB; the card is marketed as 32 GB.
The practical benefit is more memory headroom on the tested R9700 while retaining GPU-resident generation. These measurements do not establish support for a 16 GB GPU or any other card. This release qualifies the R9700 only.
Same settings, inspectable images, not identical pixels
The retained examples cover wildlife photography at seed 42, product photography at 31415, and a watercolor bookshop at 2026. All final latents were finite, and each fixed-seed result repeated exactly within its benchmark process.
Both product images retain the teal cup, yellow lemon, window light and readable “PAITON” card. The fox pair preserves the overall pose and woodland lighting. Fine textures, reflections and shadows differ.
The bookshop pair shows a larger difference in scene details, including masonry, shelving and lettering. Both retain the watercolor style, wet street, red raincoat and bicycle. The person stands beside the bicycle rather than visibly riding it.
| Prompt | RGB SSIM | RGB PSNR | Final latent relative RMSE |
|---|---|---|---|
| Fox | 0.975 | 32.45 dB | 0.146 |
| Product | 0.974 | 30.10 dB | 0.242 |
| Bookshop | 0.859 | 21.38 dB | 0.289 |
These metrics measure similarity to the stock output, not aesthetic quality or complete prompt adherence. Small numerical differences can propagate through denoising, so operator checks are accompanied by final-image inspection.
Repeatability also has a boundary: a separately compiled, empty-cache Paiton run produced a fox image with SSIM 0.948 against the populated-cache Paiton image. The cause was not isolated to one operation. This three-prompt check does not establish unchanged quality or identical pixels across all prompts, styles or independently compiled processes.
What to expect at startup
Once the engine is loaded, repeated generation is the fast path. A new process still pays for loading and graph initialization, even with persistent caches.
| Paiton startup condition | Process loading | First generation |
|---|---|---|
| Compilation caches populated | 44.7 s | 19.4 s |
| Compilation caches empty; weights already prepared | 48.2 s | 104.1 s |
The first-generation timings include graph setup and any remaining compilation. The next two warm generations in the empty-cache test took 1.050 and 1.052 seconds. These startup examples are separate from the six-image headline comparison.
Initial provisioning adds the download and model-preparation stages. On our system, the source download took 110.7 seconds and conversion took 88.7 seconds. Network speed and cache history will change those numbers.
For repeated use, keep the selected engine loaded and iterate on prompts rather than switching backends after every image.
More images per euro
At the same cost per productive hour, lower generation time gives the workstation more output capacity.
For an illustrative ownership model, assume €2,000 for the workstation, 4,000 productive generation hours, electricity at €0.30/kWh, and equal assumed wall power of 350 W for both engines. Hardware contributes €0.50 per hour and electricity adds €0.105, giving €0.605 per productive hour.
At the reported generation rates, that produces approximately 4,730 images per euro for stock and 5,647 for Paiton, 19.4% more modeled output per euro.
This is a capacity and cost model, not measured energy savings. It assumes sustained productive use and excludes idle time, taxes, labor, financing, cooling outside the workstation and PNG writing. It also does not measure how many generated images a user will choose to keep. Lower utilization raises capital cost per useful image.
How the comparison was run
The baseline was the strongest stock path retained during our qualification, not an untouched default installation. It used Diffusers 0.40.0 and SDNQ 0.2.6, prepared immutable weights, compiled pipeline components and graph capture. Other tuning options were tested; not every option improved the full pipeline.
Both engines used the same pinned checkpoint, prompts, fixed seeds, equivalent runtime precision and full GPU residency. Paiton contributes a qualified compiled execution path for this model and Radeon profile. The scheduler, step count and guidance remain unchanged; the result is not obtained by generating a smaller image or running fewer steps.
| Tested setting | Value |
|---|---|
| GPU | AMD Radeon AI PRO R9700, 32 GB |
| Model profile | FLUX.2 klein 4B, text-to-image |
| Resolution / steps / batch | 1024 × 1024 / 4 / 1 |
| Guidance / text sequence | 1.0 / 512 tokens |
| Measurement date | September 7, 2026 |
| Repetitions | Three fixed prompts; two warmups and two measured runs per prompt |
| Measured sample | Six images per backend |
| Timing boundary | GPU-synchronized wall clock, prompt to PIL image |
| GPU policy | AUTO performance level, COMPUTE profile |
| Common PyTorch build | 2.12.0+rocm7.14.0 |
| HIP | 7.14.60850 |
| Triton | 3.7.1+git0263a6a6.rocm7.14.0 |
| Transformers | 5.15.1 |
No clock, power, voltage or fan limits were changed. Automatic clocks and temperatures varied. This small sample describes the tested workstation and settings; it is not a universal speed guarantee.
The supported release is deliberately specific: Linux, R9700, text-to-image, 1024-square, four steps, batch one. Image editing, adapters, other resolutions and other GPUs are outside its qualified scope.
Model provenance and release notes
The package downloads Disty0's SDNQ checkpoint, pinned to revision 45e9cc76cb70f84473ce5c6c2e2282d0ef3c6ecd. The download is about 5.46 GB; a separate preparation stage produces about 12 GB of tensor files. Checkpoint size should not be confused with runtime precision or GPU memory usage.
The release notes identify the original FLUX.2 klein 4B weights as Apache 2.0. They also flag a contradictory non-commercial link in the community checkpoint's metadata and an unpinned pre-quantization source revision. Weights are downloaded separately; those provenance limitations should be reviewed before commercial redistribution.
The SDNQ conversion/stock tools and ComfyUI retain their upstream source and notices. The Paiton inference path does not import SDNQ. See the official model card, SDNQ source and release guide for the associated documentation.
Reproduce the workflow
From the cloned repository, enter the model directory and generate an image:
cd models/FLUX.2-klein
./run.sh generate \
--prompt 'A teal ceramic coffee cup beside a lemon, soft window light, product photograph' \
--seed 42
Use --count 4 to try consecutive seeds in one loaded process. The default output is outputs/image.png. For the lightweight interface, run ./launch.sh --ui simple and open localhost:7860.
Stop other generation services before comparing both engines:
./launch.sh --stop
./run.sh benchmark --backend stock --suite --output /outputs/stock
./run.sh benchmark --backend paiton --suite --output /outputs/paiton
The compiled artifacts on Hugging Face are already included in the containers. The release guide covers the build recipes, runtime bindings, workflow, launchers and notices. Use ./launch.sh --build to build the containers locally.
More useful work from AMD hardware
Our recent Qwen3.8 and Ornith 1.5 releases focused on local language-model serving. This profile brings the same practical focus to a visual workflow: faster iteration, less memory pressure and a ComfyUI setup people can use on their own machine.
Building image-generation services or running inference at scale on AMD CDNA? Talk to us about your workload. Paiton's wider work targets throughput, memory efficiency and cost per useful output across AMD deployments. Learn more about Paiton.