Paiton: 21% meer Qwen3.8-doorvoer op Radeon AI PRO R9700

Eén GPU. Hetzelfde publieke broncontrolepunt. Dezelfde benchmarkverzoeken. Meer output.

Paiton draaide AMD's publieke Qwen3.8-27B-Quark-Qronos-INT4-W4A16 met 39,77 outputtokens per seconde in onze interactieve benchmark met batchgrootte één op één AMD Radeon AI PRO R9700 met 32 GB geheugen.

Onze snelste gekwalificeerde standaard-vLLM-configuratie op hetzelfde systeem behaalde 32,86 outputtokens per seconde. Daardoor levert Paiton 21,0% meer output per actief inferentie-uur uit dezelfde GPU.

Bij de codeerworkload liep het voordeel op tot 54,3%. Met een input van 4.096 tokens bedroeg het 26,8%.

Throughput voor drie workloads

Dit zijn servingtests voor één gebruiker, met één verzoek tegelijk, één actieve modelsequentie, temperatuur nul, thinking uitgeschakeld en vaste willekeurige inputs.

Elke workload werd twee keer uitgevoerd vanaf een nieuw gestarte server. Elke run bestond uit drie warm-ups, gevolgd door 12 gemeten verzoeken. De tabel vermeldt het gemiddelde van beide runs. Alle zes Paiton-runs verwerkten de 12 verzoeken zonder fouten en leverden telkens de volledig gevraagde outputlengte.

Door de chattemplates bedroegen de werkelijke promptlengtes respectievelijk 268 tot 270, 1.036 tot 1.038 en 4.108 tot 4.110 tokens.

Latency: sneller streamen, gemengde resultaten voor het eerste token

Outputthroughput is slechts één onderdeel van de gebruikerservaring. Daarom publiceren we ook de latency voor het eerste token en voor streaming.

Paiton verminderde de mediane tijd per uitvoertoken in elke workload:

• Interactief: 30 ms tot 24 ms
• Codering: 39 ms tot 25 ms
• Lange context: 37 ms tot 28 ms

De Time to First Token hing af van de workload. De mediane interactieve TTFT steeg van 258 ms naar 290 ms. Bij codering verbeterde die licht, van 757 ms naar 737 ms, terwijl de TTFT voor lange context daalde van 3.337 ms naar 2.984 ms.

Het resultaat is een duidelijke winst in streamingthroughput. We beweren niet dat elke latencymetric in elk scenario verbetert.

Wat de winst betekent voor de kosten

Bij eigen inferentiehardware bepaalt de throughput hoeveel output een vast uur GPU-tijd oplevert. Bij gelijke systeemkosten per uur levert 21,0% meer throughput ook 21,0% meer tokens op binnen hetzelfde actieve runtimebudget.

Omdat de kosten per token omgekeerd evenredig zijn met de throughput, bedraagt de overeenkomstige gemodelleerde daling van de tijdsgebonden kosten per miljoen outputtokens 17,4%.

In de onderstaande voorbeelden schrijven we de GPU af over 5.000 productieve inferentie-uren. Voor beide runtimes gaan we uit van hetzelfde systeemverbruik van 450 W.

Bij de gemeten interactieve snelheden produceert dezelfde kaart over 5.000 productieve uren ongeveer 124 miljoen extra outputtokens.

Met hetzelfde gemodelleerde budget van $ 100 voor eigendom en elektriciteit produceert Paiton ongeveer 42,6 miljoen tokens in plaats van 35,2 miljoen. In het Europese voorbeeld levert € 100 ongeveer 30,8 miljoen tokens op in plaats van 25,4 miljoen.

Deze cijfers vormen een transparant, tijdsgebonden eigendomsmodel en geen claim over gemeten energie-efficiëntie. Het model houdt geen rekening met de hostcomputer, inactieve tijd, koeling, onderhoud, financiering, belastingen of restwaarde. U kunt de aankoopprijs, het elektriciteitstarief en de productieve levensduur door uw eigen waarden vervangen. De relatieve daling van 17,4% blijft gelijk zolang beide runtimes dezelfde uurkosten hebben.

Een relevante standaardbaseline

We vergeleken Paiton niet met een eager- of standaardinstallatie om het resultaat vervolgens een optimalisatiewinst te noemen. We investeerden veel tijd in het kwalificeren van de snelste stabiele standaardconfiguratie die we op dit systeem konden realiseren.

De standaardbaseline gebruikte gecompileerde vLLM-uitvoering op optimalisatieniveau 2, volledige en gedeeltelijke HIP-graph capture, standaard hybride W4A16-kernels voor RDNA, vLLM's Triton GDN-implementatie, de ROCm-attentionbackend en het ondersteunde high-clockbeleid van de R9700.

Beide configuraties gebruikten dezelfde GPU, ROCm-host, modelrevisie, tokenizer, vastgezette vLLM-revisie, verzoekgegevens, random seed, outputlengtes, concurrency en hetzelfde ondersteunde GPU-klokbeleid. We bewaarden de volledige resultaatbestanden en namen per workload het gemiddelde van twee runs vanaf een nieuw gestarte server. We selecteerden dus niet één gunstig terminalresultaat.

De standaardlogs bevestigen de gecompileerde uitvoering en graph capture. Ze laden geen Paiton-modelartefact en geen Paiton-computekernel.

Wat Paiton doet

Op hoofdlijnen bouwt Paiton een gekwalificeerd, model- en hardwarespecifiek uitvoeringspad en integreert dat met de servingruntime. Het oorspronkelijke AMD-checkpoint blijft ongewijzigd op schijf.

Tijdens het laden van het model stelt Paiton doelspecifieke runtimeartefacten samen. Er mag daarom niet van worden uitgegaan dat het geoptimaliseerde pad output oplevert die bit voor bit identiek is aan de standaard W4-uitvoering.

Daar stopt de technische toelichting over de implementatie. De modelspecifieke kernels, fusie, scheduling en het runtimeontwerp zijn gesloten Paiton-IP. We publiceren wel wat klanten kunnen valideren: het ondersteunde doel, de benchmarkmethode, throughput, latency, kwaliteitscontroles, pakketidentiteit en operationele scope.

Kwaliteitscontroles

We voerden een deterministische testreeks met 12 gevallen uit. Die omvatte het volgen van instructies, rekenkunde, algebra, logica, feitenkennis, vertaling, gestructureerde JSON, Python, SQL, samenvatting, formaatbeperkingen en modulair redeneren.

Alle 12 tests slaagden. Herhaalde antwoorden met temperatuur nul waren byte-identiek en alle geregistreerde logwaarschijnlijkheden waren eindig.

Dit is een praktische kwaliteitscontrole voor de vermelde lokale chatscope. Ze vervangt geen volledige academische nauwkeurigheidsevaluatie en vormt geen claim van gelijke kwaliteit voor elke taak of promptverdeling.

Voer de lokale chatbot uit

De publieke image bevat de Paiton-runtimeplug-in en gecompileerde runtimeartefacten. De image downloadt het oorspronkelijke AMD-checkpoint van 19,9 GB rechtstreeks van Hugging Face naar een persistent Docker-volume. Paiton distribueert de modelgewichten niet opnieuw.

docker run -d \
  --name paiton-qwen38 \
  --device /dev/kfd \
  --device /dev/dri \
  --group-add video \
  --ipc=host \
  --network host \
  --mount type=volume,src=paiton-qwen38-cache,dst=/models/cache \
  ghcr.io/eliovp/paiton-vllm-plugin@sha256:c56baf54aca1ad229829c1de26e8792806608e65ee9d06ee210b79cd49f70bc9

Bij de eerste start wordt het checkpoint gedownload. Als de gewichten al in de cache staan, duurt de modelsamenstelling op onze R9700 ongeveer 10 tot 12 minuten. Volg het opstartproces met:

docker logs -f paiton-qwen38

Zodra de logs melden dat de applicatie gereed is, opent u de meegeleverde streamingchat:

docker exec -it paiton-qwen38 paiton-chat

Gebruik /reset om het gesprek te wissen en /quit om af te sluiten. Thinking is standaard uitgeschakeld voor een responsieve lokale chat. Geef indien nodig --thinking mee.

Dezelfde server stelt een OpenAI-compatibel eindpunt beschikbaar op http://127.0.0.1:8000/v1/chat/completions met modelnaam qwen38.

Reproduceer de interactieve benchmark

Nadat de server gereed is:

docker exec paiton-qwen38 sh -lc '
MODEL_DIR="$(find /tmp -maxdepth 2 -type d \
  -path "/tmp/paiton-qwen38-reused-*/model" -print -quit)"
exec vllm bench serve \
  --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/chat/completions \
  --model qwen38 \
  --tokenizer "$MODEL_DIR" \
  --dataset-name random \
  --seed 42 \
  --num-warmups 3 \
  --num-prompts 12 \
  --random-input-len 256 \
  --random-output-len 256 \
  --random-range-ratio 0 \
  --random-prefix-len 0 \
  --request-rate inf \
  --max-concurrency 1 \
  --temperature 0 \
  --ignore-eos \
  --extra-body '\''{"chat_template_kwargs":{"enable_thinking":false}}'\'' \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,90,95,99 \
  --disable-tqdm
'

Eén run is nuttig als lokale controle, maar het energiebeheer van een consumentengpu kan een cold run vertragen. Voer eerst een korte warm-up uit en controleer of de geheugenklok zijn normale belaste toestand heeft bereikt voordat u een vergelijking registreert.

Geteste configuratie

Het pakket weigert veilig te starten bij een niet-ondersteunde GPU-identiteit, architectuur, runtimecontract, artefactchecksum, modelcontract of servingconfiguratie. Meerdere gelijktijdige verzoeken worden in een wachtrij geplaatst.

Dit artikel claimt geen ondersteuning voor andere GPU's, ROCm-versies, tensorparallelle configuraties, multimodale input of continuous batching in productie.

Het praktische resultaat

Op één Radeon AI PRO R9700 verhoogde Paiton de interactieve Qwen3.8-outputthroughput van 32,86 naar 39,77 tokens per seconde. Dat betekent 21,0% meer output per actief uur, een daling van 17,4% in de gemodelleerde tijdsgebonden kosten per miljoen outputtokens en ongeveer 124 miljoen extra tokens over 5.000 productieve uren bij de gemeten interactieve snelheid.

De resultaten voor codering en lange context tonen dat de winst niet beperkt blijft tot één promptvorm. De latencygegevens maken ook de nuance duidelijk: streaming werd bij alle drie de workloads sneller, terwijl de latency van het eerste token afhankelijk bleef van de workload.

Optimaliseer uw inferentieworkload met Paiton

Dit is een gekwalificeerd resultaat voor de Radeon AI PRO R9700, één model en één servingscope. Paiton's bredere commerciële werk richt zich ook op AMD Instinct CDNA-accelerators voor grotere inferentiedeployments, waar throughput, benutting van de volledige GPU-vloot en kosten per gegenereerde token elkaar op infrastructuurniveau versterken.

We benchmarken de echte workload, identificeren het runtimeknelpunt, bouwen het gekwalificeerde AMD-pad en meten het geleverde resultaat aan de hand van een overeengekomen baseline.

Meer informatie over Paiton.