57% meer Qwen3.8-doorvoer. Dezelfde Radeon. Gewoon vLLM.

Eén Radeon AI PRO R9700. Hetzelfde Qwen3.8-27B MXFP4-checkpoint. Dezelfde 5 GiB voor de cache. Paiton levert 57% meer totale doorvoer dan onze vergelijkbare Radiance + DFlash2-referentie bij acht gelijktijdige verzoeken. De mediane tijd tot het eerste token daalt van 6,59 seconden naar 195 milliseconden.

De kerncijfers voor doorvoer en responstijd komen uit de volledige vergelijking met 188 verzoeken, bij acht gelijktijdige verzoeken. Beide versnelde engines gebruiken dezelfde snapshots van het doelmodel en het DFlash2-draftmodel. De GPU-afbeelding is illustratief.

Dit is een flinke stap vooruit voor het aanbieden van een 27B-model op één workstation-GPU. Het gaat niet alleen om snellere generatie voor één gebruiker: er kunnen meer verzoeken tegelijk vooruitgang boeken, de geschatte cachecapaciteit is bijna drie keer zo groot en de wachttijd onder belasting is veel korter.

Paiton haalt 314,5 uitvoertokens per seconde in totaal, tegenover 200,3 tok/s voor de vergelijkbare versnelde referentie. De gewogen seriële decodesnelheid stijgt met 22% en prefill is sneller bij elke geteste promptlengte. De uitvoering loopt via een plugin op de officiële vLLM 0.28 ROCm-runtime. De geïnstalleerde vLLM-bibliotheek blijft ongewijzigd.¹

Het waardevolle zit in die combinatie: duidelijk betere lokale prestaties, met behoud van de reguliere vLLM-deployment.

Bekijk het in actie

Bekijk hoe Qwen3.8 antwoorden genereert op één Radeon AI PRO R9700, met Paiton + DFlash2 via regulier vLLM. De opname toont de gestreamde uitvoer, live generatiecijfers en GPU-activiteit.

Schermopname van 70 seconden met telkens één actief verzoek. De live cijfers gelden voor de getoonde verzoeken, niet voor de totale doorvoer bij acht gelijktijdige verzoeken in de benchmark hieronder.

Open de opname (MP4, 10,2 MB). Gebruik de knop voor volledig scherm om alles van dichtbij te bekijken.

Een sterke referentie. Een beter resultaat.

Het onderzoek begon met het indrukwekkende werk rond vLLM-Radiance. De resultaten op AMD-hardware brachten ons op ideeën en moedigden ons aan onze eigen R9700-implementatie verder te optimaliseren. De publieke documentatie beschrijft ondersteuning voor hetzelfde AMD Quark MXFP4-model en DFlash2-versnelling. De gepubliceerde prestatiecijfers van dat project gebruiken twee R9700's.²

Radiance inspireerde dit onderzoek. De native implementatie van Paiton is ons eigen werk.

Onze vraag was: hoeveel kunnen we met dit model uit één kaart halen, met behoud van de reguliere vLLM-deployment?

Daarom hebben we Radiance + DFlash2 en Paiton op vLLM + DFlash2 zelf op één R9700 getest. Beide gebruikten hetzelfde checkpoint, dezelfde snapshots van doel- en draftmodel, een FP8-KV-cache, een cachetoewijzing van 5 GiB en een contextlimiet van 8.192 tokens. De twee versnelde profielen gebruikten zeven speculatieve tokens, greedy sampling en uitgeschakelde prefixcaching.¹

Onze winstpercentages vergelijken die gelijk opgezette tests op één GPU. We vergelijken dus geen resultaat op één kaart met een extern gepubliceerd resultaat op twee kaarten.

57% meer doorvoer, met een grotere voorsprong onder belasting

Het hoofdresultaat komt uit de volledige BetterBench-preset met 188 verzoeken, niet uit de kortere vergelijking met maximaal 128 uitvoertokens. We behielden de oorspronkelijke, ruimere uitvoerbudgetten van de preset, met tien gemeten herhalingen per taakcategorie, 24 verzoeken per getest gelijktijdigheidsniveau en herhaalde prefill-metingen. Beide engines voltooiden alle verzoeken.¹³

Volledige workload met 188 verzoeken, runs 495 / 494. De totale doorvoer omvat prefill en wachtrijtijd. Hoger is beter.¹

Paiton loopt voor bij elk getest gelijktijdigheidsniveau. Ook de resultaten per taakcategorie laten een voorsprong zien voor code, redeneren, proza, JSON, bestandsbewerking, samenvatten, wiskunde en chat. De winst houdt dus stand in de langere workload en hangt niet af van één gunstige prompt.¹

Dit zijn totale verwerkingssnelheden voor de actieve workload. 314,5 tok/s betekent niet dat elk van de acht gebruikers 314,5 tok/s ontvangt.

Van 6,59 seconden wachten naar een eerste token in 195 milliseconden

De winst in doorvoer is groot. De verbetering in responsiviteit onder belasting is nog groter.

Bij vier gelijktijdige verzoeken daalt de mediane tijd tot het eerste token van 1.627 ms naar 180 ms. Bij acht daalt die van 6.586 ms naar 195 ms: 97% korter. Deze tijden zijn inclusief wachtrijtijd en beschrijven dus hoe lang de client wacht voordat het antwoord begint.¹

Volledige workload met 188 verzoeken. Lager is beter. Bij één en twee gelijktijdige verzoeken behoudt Radiance een TTFT-voordeel van 10 tot 11 ms. Paiton levert bij beide niveaus wel meer doorvoer.¹

Voor een gedeelde programmeerassistent of een lokaal endpoint voor agents is doorvoer alleen niet genoeg. Een endpoint dat meer tokens produceert maar verzoeken lang laat wachten voordat de generatie begint, kan nog steeds traag aanvoelen. Hier gaat de hogere doorvoer bij meer gelijktijdige verzoeken samen met een veel kortere wachttijd tot het eerste token.

Dezelfde 5 GiB biedt bijna drie keer de tokencapaciteit

Met precies 5 GiB gereserveerd per engine rapporteren de runtimes 25.746 cachetokenslots voor Radiance en 74.430 voor Paiton. Dat is 2,89× de geschatte tokencapaciteit binnen dezelfde geheugentoewijzing.¹

Door de runtime gerapporteerde schattingen van de gedeelde cachecapaciteit, geen fysieke VRAM-capaciteit. De contextlimiet per verzoek blijft 8.192 tokens.¹

De logs van deze tests tonen maximaal drie actieve verzoeken voor Radiance en acht voor Paiton binnen de vergelijkbare configuratie. Dat zijn waarnemingen uit deze runs, geen algemene limieten voor het aantal gelijktijdige verzoeken van beide engines.¹

Die extra capaciteit helpt de betere ervaring bij gelijktijdig gebruik te verklaren: meer verzoeken kunnen binnen hetzelfde geheugenbudget vooruitgang boeken. De capaciteitscijfers en het waargenomen aantal actieve verzoeken passen bij de gemeten doorvoer en responstijd. Ze bewijzen niet dat alleen het cachebeheer de verbetering veroorzaakt.

Meer bruikbare capaciteit voor verzoeken, niet meer VRAM of een groter contextvenster.

Snellere decode en prefill, over de hele workload

De winst beperkt zich niet tot het tegelijk toelaten van meer verzoeken. In de volledige workload stijgt de gewogen seriële decodesnelheid van 86,0 naar 104,9 uitvoertokens per seconde: 22% hoger. Dit meet de generatie na het eerste token en staat los van de totale doorvoer voor de volledige workload hierboven.¹

Gewogen seriële decodesnelheid voor de volledige workload. Dezelfde snapshots van doel- en draftmodel op dezelfde R9700.¹

Ook prefill verbetert bij elke geteste promptlengte. Bij ongeveer 1.556 / 3.024 / 5.226 invoertokens haalt Radiance 2.828 / 3.003 / 2.926 invoertokens per seconde. Paiton haalt 3.182 / 3.521 / 3.367 invoertokens per seconde.¹

Prefill voor de volledige workload: 12,5%, 17,2% en 15,1% hoger, berekend op basis van de getoonde samenvattingswaarden. Dit is het werkelijke aantal prompttokens gedeeld door de HTTP-tijd tot het eerste token, geen geïsoleerde kerneldoorvoer.¹

Samen laten deze resultaten verbetering zien op meerdere momenten die een gebruiker merkt: de prompt verwerken, onder belasting aan het antwoord beginnen en de rest van het antwoord genereren.

Het verschil met standaard-vLLM is groot

Daarnaast testten we een afzonderlijke matrix met 54 verzoeken en maximaal 128 uitvoertokens. Daarin vergeleken we standaard-vLLM O2, Radiance + DFlash2 en Paiton op vLLM + DFlash2. Voor standaard-vLLM gebruikten we de beste O2-instellingen die we hadden getest.¹

Totale uitvoerdoorvoer in de afzonderlijke matrix met 54 verzoeken en een uitvoerlimiet van 128 tokens, runs 403 / 493 / 492. Waarden uit de gepubliceerde benchmarksamenvatting. Deze vergelijking is niet de bron van het hoofdresultaat van 57%.¹

Bij acht gelijktijdige verzoeken stijgt de totale doorvoer van 33,7 tok/s met standaard-vLLM naar 328,5 tok/s met Paiton, bijna een vertienvoudiging. De gewogen seriële decodesnelheid in deze kortere vergelijking stijgt van 4,5 naar 113,5 tok/s.¹

De reikwijdte van die vergelijking is belangrijk. Standaard-vLLM gebruikt W4A4-emulatie volgens het checkpoint, terwijl de versnelde configuraties W4A8-uitvoering met DFlash2 gebruiken. Dit zijn volledige engineconfiguraties met dezelfde gewichten, niet identieke berekeningen voor activaties. De cijfers betekenen ook niet dat het vervangen van één kernel de volledige winst oplevert, of dat dit resultaat geldt voor elk model of elke kwantisatie op standaard-vLLM.

Prefill in de afzonderlijke matrix met beperkte uitvoerlengte, op basis van de werkelijke getokeniseerde promptlengtes. Deze waarden horen niet bij de prefill-reeks voor de volledige workload hierboven.¹

Daarom baseren we het hoofdresultaat op de zwaardere vergelijking: Paiton tegenover een al versnelde Radiance + DFlash2-referentie, bevestigd in de langere workload.

Regulier vLLM. De geïnstalleerde bibliotheek blijft intact.

Die deploymentvorm is een bewuste keuze. Paiton integreert via de uitbreidingsmechanismen van vLLM en levert native HIP-runtimebestanden voor de geoptimaliseerde uitvoering. Het pluginsysteem van vLLM is bedoeld om uitbreidingen mogelijk te maken zonder de codebase aan te passen.¹⁴

De geoptimaliseerde uitvoering gebruikt Paitons native HIP-kernels en DFlash2-integratie. De release bundelt de benodigde runtimebestanden voor de geteste deployment, inclusief de DFlash2-integratie, zodat gebruikers geen apart DFlash-pakket hoeven te installeren. Onze Paiton-compiler blijft gesloten.¹⁵

We controleerden ook de reguliere API-server via vllm.entrypoints.openai.api_server, los van de benchmarkomgeving. Die slaagde voor streamingchat, acht gelijktijdige verzoeken, een verzoek op de ingestelde contextgrens en een nieuw verzoek daarna. Alle 2.893 geïnstalleerde vLLM-bestanden kwamen overeen met de officiële basisimage. Deze validatie geldt voor de vastgelegde geteste runtime en het ondersteunde profiel, niet voor elke vLLM-functie of toekomstige versie.¹

Standaard-vLLM behoudt zijn gebruikelijke frameworkafhankelijkheden. De native bibliotheken van Paiton laden onafhankelijk van die frameworks. Dat maakt niet de volledige serving-stack frameworkvrij.

Dat alle verzoeken worden voltooid en de API-controles slagen, is nuttig om de betrouwbaarheid te toetsen. Het is geen onafhankelijke evaluatie van de modelnauwkeurigheid of garantie op identieke gegenereerde tekst tussen uitvoeringsprofielen.

Meer uitvoer uit hetzelfde actieve uur

De doorvoercijfers bij acht gelijktijdige verzoeken uit de volledige workload maken de capaciteitswinst concreet. Een volgehouden snelheid van 200,3 tok/s zou ongeveer 721.000 uitvoertokens per actief uur opleveren. Bij 314,5 tok/s is dat ongeveer 1,13 miljoen: zo'n 411.000 extra uitvoertokens in hetzelfde uur.

Anders uitgedrukt: één miljoen uitvoertokens kost bij de referentiesnelheid 1,387 actieve uren, tegenover 0,883 uur met Paiton. Dat is 36,3% minder actieve tijd.

Rekenvoorbeeld op basis van de doorvoer bij acht gelijktijdige verzoeken in de volledige workload. Het veronderstelt dat die snelheden worden volgehouden. Dit is geen meting van een uur, geen energiemeting en geen claim over financiële kosten.¹

De hardware verandert niet. Hoeveel nuttig werk die hardware kan leveren wel.

Geteste configuratie

Deze resultaten gelden voor het geteste model, de runtime en de workload. Ze bieden geen garantie voor andere GPU's, langere contexten, andere draftmodellen of niet-geteste aantallen gelijktijdige verzoeken.¹

Aan de slag op je R9700

De Paiton-modelhandleiding is het startpunt voor de deploymentinstructies en benchmarkonderbouwing. De bijbehorende Hugging Face-repository identificeert de modelrelease.¹⁶

Runtimepakket: Download het runtimepakket en bekijk de release notes.⁷

Containerimage voor deze release:

ghcr.io/eliovp/paiton-vllm-plugin:qwen38-mxfp4-dflash2-rdna4-v1.0.0

Gebruik de vastgelegde configuratie uit de modelhandleiding om het resultaat te reproduceren. De cachetoewijzing van 5 GiB, snapshots van doel- en draftmodel, speculatieve instellingen en contextlimiet maken deel uit van de vergelijking. Het zijn geen toevallige standaardwaarden.

Dezelfde hardware. Duidelijk meer capaciteit.

57% meer totale doorvoer. Een 97% kortere mediane tijd tot het eerste token bij acht gelijktijdige verzoeken. 2,89× de geschatte cachecapaciteit. Daarnaast snellere seriële decode en prefill, allemaal op één Radeon AI PRO R9700 via regulier vLLM.

Voor lokale ontwikkelaars betekent dit een krachtiger gedeeld endpoint op één workstation-GPU. Voor teams die AMD-inference op grotere schaal draaien, laat het opnieuw zien waarom efficiënte uitvoering naast hardwarecapaciteit telt. De R9700-cijfers voorspellen geen winst op andere AMD-platforms.

Wil je meer uit je AMD-inferenceworkload halen? Bespreek met ons wat Paiton kan betekenen. Neem het model, de workload en de huidige referentiemetingen mee.

Dank aan de betrokken teams

Dank aan het Radiance-team voor het uitstekende werk aan AMD-inference, de inspiratie en een sterke vergelijkingsbasis.

We bedanken ook vLLM, StillDeadcode/libr4d, de Qwen- en DFlash2-teams, het Quark-checkpointteam van AMD en BetterBench voor de bouwstenen, modellen en meetinstrumenten waarop dit werk steunt.