Een productconcept. Een bosfoto. Een regenachtige straat in aquarel. Het handige aan lokale beeldgeneratie is dat u de prompt kunt aanpassen en meteen opnieuw kunt proberen, zonder het verzoek naar een externe dienst te sturen.
Ons gratis Paiton-profiel maakt dat mogelijk met FLUX.2 klein 4B op één AMD Radeon AI PRO R9700, inclusief een gebruiksklare ComfyUI-configuratie.
Bij 1024 × 1024 pixels, vier stappen en een batchgrootte van één duurt de volledige generatie met een opgewarmde pipeline gemiddeld 1,054 seconden per beeld, tegenover 1,258 seconden voor de beste standaardconfiguratie die we hebben gekwalificeerd. Dat betekent 16,2% minder generatietijd en 19,4% meer berekende beelden per uur.
Ook het geheugengebruik daalt: de piekallocatie in Torch neemt af van 19,3 naar 12,9 GiB, een gerapporteerde daling van 33,4%. De tekstencoder, transformer en VAE blijven op de GPU. Er worden geen modelonderdelen naar de CPU verplaatst.
Het hoofdcijfer meet de generatie van prompt tot beeld met een opgewarmde pipeline, niet het opstarten of de tijd vanaf een klik in de browser. Tekstcodering, denoising, VAE-decodering en omzetting naar een PIL-afbeelding zijn inbegrepen. PNG-codering, het wegschrijven van bestanden en de interface zijn niet meegerekend.
De vos bovenaan is een bewaard benchmarkresultaat van het Paiton FLUX.2 klein-profiel, met seed 42.
Ga lokaal aan de slag
Op een Linux-workstation met een R9700, Docker, de Compose-plugin en een werkend AMD GPU-stuurprogramma start u de meegeleverde workflow als volgt:
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 op localhost:8188, pas de prompt aan en klik op Run. De aangesloten workflow bevat een enginekeuze voor Paiton of Stock (Diffusers), een seedinstelling, een beeldvoorbeeld en een Save Image-node. De beelden worden opgeslagen in paiton-images/.
Bij het eerste beeld wordt de gekozen engine geladen en gecompileerd. Dat kan enkele minuten duren. Volgende prompts gebruiken dezelfde geladen engine. Bij het wisselen van engine wordt het vorige model uit het geheugen verwijderd en moet de nieuwe engine opnieuw worden voorbereid. Beide modellen staan dus niet tegelijk in het GPU-geheugen. Wilt u resultaten vergelijken, houd dan de prompt en seed gelijk en kies fixed bij de seedinstelling.
De geteste computer heeft 16 GB RAM. We raden 24 GB systeemgeheugen en 60 GB vrije schijfruimte aan voor compilatie, containers, modelbestanden, caches en resultaten. Downloads en caches blijven tussen starts bewaard. Na de installatie gebeurt de generatie lokaal, zonder betaalde inferentiedienst of cloud-GPU.
De modelhandleiding beschrijft ook een eenvoudige promptinterface, generatie via de terminal en het toevoegen van de node aan een bestaande ComfyUI-installatie.
Wat de snelheidsmeting omvat
Beide engines gebruiken hetzelfde modelcheckpoint en dezelfde generatie-instellingen. We meten de volledige generatiecyclus met een opgewarmde pipeline. Het resultaat is dus niet afgeleid van de versnelling van één afzonderlijke kernel.
| Generatiemeting | Gekwalificeerde standaardconfiguratie + gewichtencache | Paiton |
|---|---|---|
| Gemiddelde seconden per beeld, opgewarmde pipeline | 1,258 | 1,054 |
| Berekende beelden per uur | 2.862 | 3.416 |
De berekende capaciteit is 3600 / gemiddelde generatietijd in seconden. Dit is geen throughputmeting van een uur. Het wegschrijven van PNG-bestanden en de tijd om prompts aan te passen zijn niet inbegrepen. De stijging van 19,4% in capaciteit en de daling van 16,2% in generatietijd drukken dezelfde verbetering op een andere manier uit.
De interface voegt eigen verwerkingstijd toe. In een afzonderlijke ComfyUI-validatie duurden twee workflowuitvoeringen met een opgewarmde engine 1,408 en 1,404 seconden, gemiddeld 1,406 seconden inclusief lokale communicatie met de engine, beeldverwerking en opslag. Deze servertijden omvatten niet de weergave in de browser en zijn niet de prompt-naar-PIL-benchmark waarop het hoofdcijfer is gebaseerd.
Minder geheugengebruik, zonder CPU-offload
De downloadgrootte van een model zegt niet hoeveel geheugen het tijdens gebruik nodig heeft. De volledige pipeline gebruikt ook geheugen voor de tekstencoder, decoder, activaties, tijdelijke buffers en compilatie.
Paiton verlaagt alle drie de gerapporteerde geheugenmetingen in deze vergelijking:
| Geheugenmeting | Gekwalificeerde standaardconfiguratie + gewichtencache | Paiton |
|---|---|---|
| Piekallocatie in Torch | 19,3 GiB | 12,9 GiB |
| Piekreservering in Torch | 22,1 GiB | 14,1 GiB |
| Maximaal gemeten VRAM-gebruik via het stuurprogramma | 23,0 GiB | 14,6 GiB |
12,9 GiB is niet het totale VRAM-verbruik. Allocatie meet het geheugen voor tensors. Reservering meet het geheugen dat de Torch-allocator vasthoudt. Metingen via het stuurprogramma omvatten ook geheugen buiten die allocator. Deze meetwaarden overlappen en mogen niet worden opgeteld.
De pieken in allocatie en reservering omvatten compilatie, opwarming en generatie. De steekproeven via het stuurprogramma omvatten ook het laden. De waarden zijn afgerond en uitgedrukt in binaire GiB. De kaart wordt verkocht als een model met 32 GB.
Het praktische voordeel is meer vrije geheugenruimte op de geteste R9700, terwijl de generatie volledig op de GPU blijft. Deze metingen tonen geen ondersteuning voor een GPU van 16 GB of een andere kaart aan. Deze release is uitsluitend gekwalificeerd voor de R9700.
Dezelfde instellingen, beelden om te vergelijken, geen identieke pixels
De bewaarde voorbeelden omvatten natuurfotografie met seed 42, productfotografie met 31415 en een boekwinkel in aquarel met 2026. Alle uiteindelijke latente waarden waren eindig en elk resultaat met een vaste seed werd binnen het eigen benchmarkproces exact gereproduceerd.
Beide productbeelden behouden de blauwgroene kop, gele citroen, het raamlicht en de leesbare kaart met “PAITON”. Ook bij de vos blijven de algemene houding en bosbelichting behouden. Fijne texturen, reflecties en schaduwen verschillen.
Bij de boekwinkel zijn de verschillen in details groter, onder meer in metselwerk, rekken en opschriften. Beide beelden behouden de aquarelstijl, natte straat, rode regenjas en fiets. De persoon staat naast de fiets in plaats van er zichtbaar op te rijden.
| Prompt | RGB SSIM | RGB PSNR | Relatieve RMSE van de uiteindelijke latente representatie |
|---|---|---|---|
| Vos | 0,975 | 32,45 dB | 0,146 |
| Product | 0,974 | 30,10 dB | 0,242 |
| Boekwinkel | 0,859 | 21,38 dB | 0,289 |
Deze meetwaarden beschrijven de gelijkenis met het standaardresultaat, niet de esthetische kwaliteit of hoe volledig de prompt wordt gevolgd. Kleine numerieke verschillen kunnen tijdens denoising doorwerken. Daarom combineren we controles op bewerkingen met een visuele beoordeling van de eindbeelden.
Ook reproduceerbaarheid heeft grenzen. Een afzonderlijk gecompileerde Paiton-run met een lege compilatiecache leverde een vosbeeld op met een SSIM van 0,948 ten opzichte van het Paiton-beeld met een gevulde cache. De oorzaak kon niet tot één bewerking worden herleid. Deze controle met drie prompts bewijst niet dat de kwaliteit ongewijzigd blijft of dat alle prompts, stijlen en afzonderlijk gecompileerde processen identieke pixels opleveren.
Wat u bij het opstarten kunt verwachten
Zodra de engine geladen is, verloopt herhaalde generatie snel. Een nieuw proces heeft nog altijd tijd nodig om te laden en de rekengrafen te initialiseren, ook als de caches bewaard zijn.
| Startsituatie van Paiton | Laden van het proces | Eerste generatie |
|---|---|---|
| Compilatiecaches gevuld | 44,7 s | 19,4 s |
| Compilatiecaches leeg, gewichten al voorbereid | 48,2 s | 104,1 s |
De tijden voor de eerste generatie omvatten het opzetten van de rekengrafen en eventuele resterende compilatie. De volgende twee generaties met een opgewarmde pipeline in de test met een lege cache duurden 1,050 en 1,052 seconden. Deze opstartvoorbeelden staan los van de vergelijking met zes beelden waarop het hoofdcijfer is gebaseerd.
Bij de eerste installatie komen downloaden en modelvoorbereiding daar nog bij. Op ons systeem duurde de brondownload 110,7 seconden en de conversie 88,7 seconden. De netwerksnelheid en aanwezige caches beïnvloeden die tijden.
Voor herhaald gebruik laat u de gekozen engine geladen en past u de prompts aan, in plaats van na elk beeld van backend te wisselen.
Meer beelden per euro
Bij gelijke kosten per productief uur geeft een kortere generatietijd het workstation meer capaciteit.
Neem als illustratief kostenmodel € 2.000 voor het workstation, 4.000 productieve generatie-uren, elektriciteit aan € 0,30/kWh en een gelijk verondersteld vermogen aan het stopcontact van 350 W voor beide engines. De hardware kost dan € 0,50 per uur en de elektriciteit € 0,105. Samen is dat € 0,605 per productief uur.
Met de gerapporteerde generatiesnelheden komt dat neer op ongeveer 4.730 beelden per euro voor de standaardconfiguratie en 5.647 voor Paiton, of 19,4% meer berekende output per euro.
Dit is een capaciteits- en kostenmodel, geen gemeten energiebesparing. Het gaat uit van aanhoudend productief gebruik en sluit stilstand, belastingen, arbeid, financiering, koeling buiten het workstation en het wegschrijven van PNG-bestanden uit. Het meet evenmin hoeveel gegenereerde beelden een gebruiker uiteindelijk bewaart. Bij een lagere bezettingsgraad stijgen de kapitaalkosten per bruikbaar beeld.
Hoe we de vergelijking uitvoerden
De referentie was de sterkste standaardconfiguratie die we tijdens onze kwalificatie behielden, geen onaangepaste standaardinstallatie. Ze gebruikte Diffusers 0.40.0 en SDNQ 0.2.6, voorbereide onveranderlijke gewichten, gecompileerde pipelineonderdelen en graph capture. We testten ook andere optimalisaties, maar niet elke optie verbeterde de volledige pipeline.
Beide engines gebruikten hetzelfde vastgelegde checkpoint, dezelfde prompts, vaste seeds, gelijkwaardige numerieke precisie tijdens uitvoering en een volledig op de GPU geladen model. Paiton voegt voor dit model en Radeon-profiel een gekwalificeerd, gecompileerd uitvoeringspad toe. De scheduler, het aantal stappen en de guidance blijven gelijk. Het resultaat is dus niet behaald met een kleiner beeld of minder stappen.
| Geteste instelling | Waarde |
|---|---|
| GPU | AMD Radeon AI PRO R9700, 32 GB |
| Modelprofiel | FLUX.2 klein 4B, tekst naar beeld |
| Resolutie / stappen / batch | 1024 × 1024 / 4 / 1 |
| Guidance / tekstsequentie | 1,0 / 512 tokens |
| Meetdatum | 7 september 2026 |
| Herhalingen | Drie vaste prompts, twee opwarmruns en twee gemeten runs per prompt |
| Gemeten steekproef | Zes beelden per backend |
| Meetgrens | GPU-gesynchroniseerde verstreken tijd, van prompt tot PIL-afbeelding |
| GPU-beleid | Prestatieniveau AUTO, profiel COMPUTE |
| Gemeenschappelijke PyTorch-build | 2.12.0+rocm7.14.0 |
| HIP | 7.14.60850 |
| Triton | 3.7.1+git0263a6a6.rocm7.14.0 |
| Transformers | 5.15.1 |
Er werden geen limieten voor kloksnelheid, vermogen, spanning of ventilatoren aangepast. Automatische kloksnelheden en temperaturen varieerden. Deze kleine steekproef beschrijft het geteste workstation en de gebruikte instellingen, geen universele snelheidsgarantie.
De ondersteunde release is bewust specifiek: Linux, R9700, tekst naar beeld, 1024 × 1024, vier stappen en een batchgrootte van één. Beeldbewerking, adapters, andere resoluties en andere GPU's vallen buiten het gekwalificeerde bereik.
Herkomst van het model en release-informatie
Het pakket downloadt het SDNQ-checkpoint van Disty0, vastgelegd op revisie 45e9cc76cb70f84473ce5c6c2e2282d0ef3c6ecd. De download is ongeveer 5,46 GB groot. Een afzonderlijke voorbereidingsstap levert ongeveer 12 GB aan tensorbestanden op. De checkpointgrootte mag niet worden verward met de precisie tijdens uitvoering of het GPU-geheugengebruik.
Volgens de release-informatie vallen de oorspronkelijke FLUX.2 klein 4B-gewichten onder Apache 2.0. Die informatie wijst ook op een tegenstrijdige niet-commerciële link in de metadata van het communitycheckpoint en een niet-vastgelegde bronrevisie van vóór de kwantisatie. De gewichten worden afzonderlijk gedownload. Bekijk deze beperkingen rond de herkomst voordat u ze commercieel herverdeelt.
De SDNQ-conversietools, de tools voor de standaardconfiguratie en ComfyUI behouden hun upstreambroncode en vermeldingen. Het Paiton-inferentiepad importeert SDNQ niet. Zie de officiële modelkaart, de SDNQ-broncode en de releasehandleiding voor de bijbehorende documentatie.
De workflow zelf uitvoeren
Ga vanuit de gekloonde repository naar de modelmap en genereer een beeld:
cd models/FLUX.2-klein
./run.sh generate \
--prompt 'A teal ceramic coffee cup beside a lemon, soft window light, product photograph' \
--seed 42
Gebruik --count 4 om opeenvolgende seeds te proberen binnen één geladen proces. Het standaarduitvoerbestand is outputs/image.png. Voor de eenvoudige interface voert u ./launch.sh --ui simple uit en opent u localhost:7860.
Stop andere generatiediensten voordat u beide engines vergelijkt:
./launch.sh --stop
./run.sh benchmark --backend stock --suite --output /outputs/stock
./run.sh benchmark --backend paiton --suite --output /outputs/paiton
De gecompileerde bestanden op Hugging Face zijn al opgenomen in de containers. De releasehandleiding beschrijft de bouwinstructies, runtimebindings, workflow, startscripts en vermeldingen. Met ./launch.sh --build bouwt u de containers lokaal.
Meer nuttig werk uit AMD-hardware
Onze recente releases voor Qwen3.8 en Ornith 1.5 richtten zich op het lokaal draaien van taalmodellen. Dit profiel brengt diezelfde praktische aanpak naar een visuele workflow: sneller varianten uitproberen, minder geheugendruk en een ComfyUI-configuratie die u op uw eigen machine kunt gebruiken.
Bouwt u diensten voor beeldgeneratie of draait u inferentie op grote schaal op AMD CDNA? Bespreek uw workload met ons. Het bredere werk achter Paiton richt zich op throughput, geheugenefficiëntie en kosten per bruikbaar resultaat in AMD-omgevingen. Meer over Paiton.