3-bit gewichten. 20% snellere decode. 1 × Radeon AI PRO R9700.

Een lokale assistent is nuttiger als hij sneller schrijft, lange documenten sneller verwerkt en ruimte heeft voor meerdere gebruikers tegelijk. Onze nieuwe Paiton-release brengt die verbeteringen naar Qwen3.8 27B op 1 × Radeon AI PRO R9700 (32 GB), zonder een tweede GPU toe te voegen.

Tegenover onze vorige MXFP4-release van 24 september stijgt de gewogen generatiesnelheid van 153,8 naar 184,4 tokens per seconde: 19,9% snellere decode. Acht gelijktijdige verzoeken leveren samen 492,1 tokens per seconde, tegenover 425,3. Kleinere modelgewichten maken in het 65K-serverprofiel ook ruimte voor 43,5% meer gerapporteerde cachecapaciteit in tokens.¹

De verandering bestaat uit onze eigen geroteerde 3-bit gewichten voor de grote decoderprojecties, met 4-bit activatierekenwerk in geselecteerde lagen tijdens de promptverwerking. Andere tensors behouden hun bestaande formaat. Daar staat een echte afweging tegenover: de MMLU-Pro-subset voor algemene kennis daalt met ongeveer drie procentpunten. De verschillen voor rekenen en code zijn in deze tests niet te onderscheiden van meetruis, en alle 80 afgebakende lang-contextopzoektests slagen. Als kennisnauwkeurigheid vooropstaat, blijft MXFP4 via één opstartoptie beschikbaar.

Wat verandert in dagelijks gebruik

De vorige release combineerde al MXFP4-gewichten, een FP8-cache, DFlash2-speculatieve decode en Paitons native AMD-uitvoering binnen vLLM. Deze update behoudt die basis en vermindert de hoeveelheid modeldata die de GPU moet lezen. Dat levert snellere uitvoer, snellere promptverwerking en meer cacheruimte op dezelfde kaart op.

Die voordelen zijn verschillende metingen. Decode is de generatie na het eerste token. Totale doorvoer is de uitvoer van meerdere gelijktijdige verzoeken samen. Prefill is het verwerken van de prompt voordat de generatie begint. Een hogere tokensnelheid in één fase betekent niet automatisch een even grote daling van de volledige verzoektijd.

De 19,9% uit de titel vergelijkt deze release met de MXFP4-image van 24 september, niet met de oudere Radiance-vergelijking in ons eerdere Qwen3.8-artikel. Het oorspronkelijke resultaat van 57% in dat artikel blijft een afzonderlijke benchmark met een eigen configuratie.

Snellere generatie in uiteenlopende taken

BetterBench 0.6.0, quick-profiel. Generatie na het eerste token, in tokens/s; hoger is beter. De waarden zijn gemiddelden van twee volledige runs. Het gewogen resultaat stijgt met 19,9% tegenover de vorige release. De winst verschilt per taak en belooft dus niet dat elke prompt 20% sneller genereert. Gepubliceerd benchmarkrapport.

De middelste kolom scheidt de kleinere runtimeverbeteringen met MXFP4 van de grotere winst door het nieuwe gewichtformaat. De gewogen decode van het MXFP4-pad van deze ronde ligt ongeveer 1,5% boven de vorige release.

Meer uitvoer bij overlappende verzoeken

Totale gegenereerde tokens/s, met 48 verzoeken per gelijktijdigheidsniveau; hoger is beter. Dit zijn gezamenlijke serversnelheden, niet de snelheid die elke gebruiker afzonderlijk krijgt. Eén R9700, 65.536 tokens ingestelde context, maximaal acht ingeplande reeksen.

Voor een gedeelde lokale assistent kan de GPU zo meer uitvoer leveren terwijl verzoeken overlappen. De precieze winst hangt af van de promptlengtes, uitvoerlengtes en beschikbare cache.

Ook de promptverwerking wordt sneller

Verwerkte invoertokens per seconde; hoger is beter. De dieptelabels zijn nominale BetterBench-instellingen, geen exacte promptlengtes. De grootste nominale 64K-werklast heeft mediaan 47.016,5 werkelijke prompttokens. De gemeten wachttijd tot het eerste token staat apart hieronder.

De geteste prefill-snelheden verbeteren met 5,0–12,7%. De clientwachttijd tot het eerste token daalt met 4,8–10,8%, op basis van het gemiddelde van de mediane TTFT van beide runs. Een hogere doorvoer en een lagere wachttijd zijn verschillende percentages. Ook planning en andere overhead kunnen de wachttijd beïnvloeden.²

Meer ruimte voor lange gesprekken

Het modelgeheugen daalt van 19,18 naar 15,89 GiB. De launcher gebruikt het vrijgekomen geheugen voor de gesprekscache: van 174.634 naar 250.578 gerapporteerde tokenplaatsen. Cachecapaciteit is een schatting uit de serverconfiguratie, geen aantal volledig gemeten gesprekken.

De laatste rij is een omgerekende capaciteitsschatting, geen bewering dat 3,8 verzoeken kunnen draaien. Prompttekst, chat- en toolopmaak en gegenereerde uitvoer tellen allemaal mee in de context. Acht ingeplande reeksen betekenen evenmin dat acht volledige 65K-gesprekken tegelijk passen.¹

We testten het praktische effect apart met vier prompts van ongeveer 61.400 tokens, elk met 512 aangevraagde uitvoertokens. De werkelijke promptlengtes lopen van 61.390 tot 61.426 tokens. Met het oorspronkelijke cachebudget passen slechts twee van deze verzoeken tegelijk. Als W3A4 het vrijgekomen geheugen als cache gebruikt, kunnen ze alle vier tegelijk decoderen:

Vier lange verzoeken op één R9700. Voor de volledige batchtijd is lager beter. De controle gebruikt de MXFP4-build van 26 september, niet de image van 24 september. W3A4 met uitgebreide cache verandert het geheugenbudget en gebruikt de uitgebrachte kalibratie. De W3A4-controle met dezelfde cache gebruikte een eerdere kalibratie.

De nieuwe gewichten versnellen de decode met twee verzoeken ook zonder extra cache. Het herverdelen van geheugen verkort daarna de wachttijd voor de volledige batch van vier verzoeken. De 199 tok/s is de gezamenlijke decode terwijl alle vier actief zijn, niet de doorvoer over de volledige batch. Het piekgebruik van de volledige GPU blijft vrijwel gelijk: 31,39 GiB met de standaardcache van W3A4 tegenover 31,37 GiB voor de MXFP4-controle. Er blijft dus weinig vrije marge op deze kaart. Dit is één lang-contextwerklast, geen algemene garantie voor elk aantal gelijktijdige gebruikers.²

Wat we veranderden en waarom

Eerst de bestaande runtime voorspelbaar maken

Voordat we de gewichten veranderden, onderzochten we serverstarts die ondanks dezelfde configuratie afwisselden tussen ongeveer 28 en 36 ms per speculatieve stap. Door de runtime met GPU_MAX_HW_QUEUES=1 aan één hardware-computewachtrij te koppelen, bleven die starts in de snellere modus. De image bevat die instelling. Alle vergelijkingsarmen gebruikten die al, zodat de winst door deze instelling niet in het hoofdcijfer zit.

We voegden ook de GatedDeltaNet-bewerking voor speculatieve verificatie samen in één native kernel. Die afzonderlijke bewerking werd 23–28% sneller; de gecombineerde runtimeverbeteringen verhogen de volledige gewogen MXFP4-decode met ongeveer 1,5%. Winst in één kernel is niet hetzelfde als winst in de volledige generatie.

Minder bytes lezen tijdens generatie

Decode op deze kaart wordt vooral begrensd door de geheugenbandbreedte. De vorige kernels zaten al dicht bij de beschikbare bandbreedte. Minder gewichtdata lezen bood daarom meer ruimte dan alleen de planning aanpassen.

De grote lineaire projecties gaan van ongeveer 4,25 bits per gewicht met MXFP4 naar 3,125 bits met gegroepeerde INT3. Dit betreft 24,3 miljard decoderprojectiegewichten, niet elke tensor in het 27B-model, en is ruwweg een kwart minder data voor die gewichten. Native Paiton-kernels verwerken de verpakte waarden rechtstreeks. Decode houdt 8-bit FP8-activaties; in de serververgelijking daalt de mediane forwardtijd met één stroom van ongeveer 28,3–28,4 ms naar 22,4–22,5 ms.¹²

Andere precisie gebruiken voor promptverwerking

Promptverwerking heeft een ander knelpunt. Alleen 3-bit gewichten combineren met het oude pad voor 8-bit activaties maakte die fase in onze controles trager. De release gebruikt daarom 4-bit activatierekenwerk alleen in geselecteerde prefill-projecties. Tijdens generatie blijven de activaties 8-bit.

Een bloksgewijze Hadamard-rotatie verdeelt grote activatieuitschieters over kleine groepen, zodat promptverwerking met lagere precisie bruikbaar wordt. De gewichten worden in die geroteerde basis gekalibreerd; de runtime past de overeenkomstige activatietransformatie toe. Schalen per groep behoudt meer lokale precisie dan één schaal voor een volledig token. Dit is de openbare methode achter de naam W3A4, geen nieuwe modelarchitectuur.¹

Onze eigen gewichten kalibreren en datalicenties controleren

Dit zijn onze eigen met GPTQ gekalibreerde gewichten; een 3-bit model van een derde partij is niet vereist. De kalibratie gebruikt 292.864 tokens uit rekenen, code, wetenschap, webtekst, meertalig materiaal, agenttraces en lange documenten. Het laag-voor-laagproces duurt ongeveer 13 minuten op één AMD Instinct MI355X.

Voor de release vervingen we kalibratiebronnen met niet-commerciële of share-alikevoorwaarden door bronnen met permissieve licenties. De uitgebrachte gewichten gebruiken die definitieve kalibratie. Het kalibratierapport vermeldt de datasetrevisies en licenties. De vermeldingen voor derden behouden de verplichte bronvermeldingen.

Opstarten en integriteitscontroles duidelijk houden

De runtime laadt de geroteerde vervangingsgewichten naast het vastgelegde basischeckpoint en controleert hun bestanden via SHA-256. Een apart 3-bit model van derden is niet nodig. We verholpen ook een opwarmprobleem waarbij niet-geïnitialiseerde dummyinvoer vóór het eerste echte verzoek een vlag voor niet-eindige waarden kon activeren. Die vlag wordt na de opwarming gewist, terwijl de strikte controles voor echte verzoeken actief blijven.

Opstarten duurt ongeveer 230 seconden, tegenover ongeveer 210 seconden eerder. De winst tijdens opgewarmde uitvoering neemt die eerste laadtijd niet weg.

Kwaliteit: de winst vraagt een keuze

Nauwkeurigheid in het draaiende model, met greedy decode, uitgeschakeld denken en identieke vragen. De gepaarde 95%-betrouwbaarheidsintervallen bevatten nul voor GSM8K en HumanEval, maar niet voor de MMLU-Pro-subset. De 80 needle-tests controleren gericht informatie ophalen, niet de volledige kwaliteit bij lange contexten.

Rekenen en code blijven dicht bij elkaar in de geteste sets; de intervallen bewijzen geen identieke kwaliteit. Meerkeuzevragen met veel algemene kennis tonen wel een meetbare daling van ongeveer drie punten. Ook de acceptatie van DFlash2 blijft dichtbij, met veranderingen per taak van −0,4% tot +2,8%.¹

Kies voor kennisintensief werk --weights mxfp4. Dat gebruikt het gewichtpad met hogere precisie en krijgt nog steeds de MXFP4-runtimeverbeteringen van deze ronde. W3A4 is nuttig als snellere generatie en meer gesprekscache de gemeten kwaliteitsafweging waard zijn. De uitvoer kan verschillen; we beloven geen identieke antwoorden.

Meertalige kwaliteit, tool-calling en kwaliteit bij langere contexten zijn niet gemeten in deze evaluatie. De uitgebrachte W3A4-bundel is alleen voor tekst en specifiek voor de R9700. Deze prestaties en kwaliteitsresultaten gelden voor het 65K-profiel. Andere launcherprofielcombinaties zijn niet gemeten; de aparte 200K-image blijft MXFP4 gebruiken. Deze vervangingsgewichten vereisen de Paiton-runtime: standaard-vLLM, Transformers en llama.cpp kunnen ze niet zelfstandig laden.¹³

Zo leest u deze resultaten

De prestatievergelijking gebruikt één R9700 met een vermogenslimiet van 300 W, vLLM 0.29, ROCm 10, een context van 65.536 tokens, maximaal acht reeksen, DFlash2 en uitgeschakeld denken. Automatische prefixcaching en n-gram co-drafting staan uit. Elke image draaide in twee nieuwe serverprocessen, afwisselend uitgevoerd, en de tabellen tonen het gemiddelde van die twee runs. BetterBench gebruikte versie 0.6.0 en het quick-profiel. De referentie-image is qwen38-rocm10-vllm029-65k-20260924-r3.

De openbare prestatieruns gebruikten de eerdere v3-kalibratie. De nauwkeurigheidscijfers en de run met vier verzoeken en uitgebreide cache gebruiken de definitieve, permissief gekalibreerde gewichten die worden uitgebracht. Het tensorformaat en de runtime zijn identiek, maar niet alle tests gebruiken precies dezelfde gewichtsbytes. Gegenereerde tekst en speculatieve acceptatie kunnen verschillen: W3A4 veranderde zeven van twaalf greedy controleresultaten tegenover MXFP4. Dit zijn metingen van serverdoorvoer, geen tijden voor identieke uitvoer. Procentuele verschillen zijn berekend uit niet-afgeronde metingen; narekenen vanuit de afgeronde tabellen kan daarom licht afwijken.¹²

De gewogen decode van BetterBench geeft code 30%, redeneren 20%, proza en JSON elk 15%, en bestandsbewerking en samenvatten elk 10%. Chat en rekenen worden apart getoond en tellen niet mee in het hoofdcijfer. Elke run meet na vaste opwarmverzoeken vijf verzoeken per decodecategorie, 48 per gelijktijdigheidsniveau en acht per nominale prefill-diepte. Bestandsbewerking varieert het meest tussen de twee W3A4-runs: 179,0 en 211,1 tok/s. Het volledige rapport en de brondata bewaren die meetdetails.

De 300 W is de ingestelde vermogenslimiet van de GPU. We hebben geen energieverbruik van het volledige systeem of kosten per token gemeten. Snellere generatie is op zichzelf geen meting van elektriciteitsbesparing.

Probeer het op uw R9700

Gebruik Linux x86-64, Python 3, Docker, de Hugging Face CLI en AMD GPU-toegang. De commando's hieronder leggen de openbare releasecheckout en de revisies van target, drafter en geroteerde gewichten samen vast. Hebt u de pluginrepository al, gebruik dan een aparte checkout in plaats van lokaal werk te vervangen. De releasehandleiding beschrijft bestaande downloads en andere profielen.³

git clone https://github.com/Eliovp-BV/paiton-vllm-plugin.git
cd paiton-vllm-plugin
git checkout a44044105287da3d040652ea8bcd3927a94a1bf2

export PAITON_TARGET_DIR="$PWD/model-cache/qwen38-nvfp4"
export PAITON_DRAFT_DIR="$PWD/model-cache/qwen38-dflash2"
export PAITON_W3ROT_DIR="$PWD/model-cache/qwen38-w3rot-int3"
export PAITON_CACHE_DIR="$PWD/runtime-cache/qwen38-rocm10-65k-w3a4"
mkdir -p "$PAITON_TARGET_DIR" "$PAITON_DRAFT_DIR" "$PAITON_W3ROT_DIR" "$PAITON_CACHE_DIR"

hf download unsloth/Qwen3.8-27B-NVFP4 \
  --revision f0b7c9e722f5565102fff8481c99e4d86ae099c7 --local-dir "$PAITON_TARGET_DIR"
hf download tcclaviger/Qwen3.8-27B-DFlash2-FP8 \
  --revision ee0cb26a8279b7910cc28d82a8a3e15e4728d56f --local-dir "$PAITON_DRAFT_DIR"
hf download EliovpAI/Qwen3.8-27B-W3Rot-INT3-Paiton-RDNA4 \
  --revision 278486debe64e21e5e9d45ac8d02798d72fbdf83 --local-dir "$PAITON_W3ROT_DIR"
(cd "$PAITON_W3ROT_DIR" && sha256sum -c SHA256SUMS)

bash models/Qwen3.8-MXFP4-DFlash2/run-rocm10-65k.sh

De uitgebrachte W3A4-image is ghcr.io/eliovp/paiton-vllm-plugin:qwen38-rocm10-vllm029-65k-20260926-w3a4-r1. De onveranderlijke digest is:

sha256:c4134aba665f6dd3b89354a43be2b5b814f7078db456351647a3f1b106a0da49

Als PAITON_W3ROT_DIR is ingesteld, selecteert de modelspecifieke launcher de geroteerde 3-bit gewichten. Stop die server eerst en selecteer daarna MXFP4 met:

bash models/Qwen3.8-MXFP4-DFlash2/run-rocm10-65k.sh --weights mxfp4

Zodra de server klaar is, biedt hij de OpenAI-compatibele API op http://127.0.0.1:18982/v1 aan met de modelnaam Qwen3.8. Stuur in een tweede terminal een streamingverzoek:

curl --fail http://127.0.0.1:18982/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen3.8","messages":[{"role":"user","content":"Write a short Python function that removes duplicates while keeping their original order."}],"temperature":0,"max_tokens":256,"stream":true,"chat_template_kwargs":{"enable_thinking":false}}'

Deze commando's starten het modelspecifieke W3A4-Dockerprofiel met DFlash2. De kortere native preset paiton serve qwen38-nvfp4 is een andere configuratie zonder speculatieve decode en laadt deze 3-bit gewichten niet.³

Wat volgt en wat niet is uitgebracht

Een 4-bit gesprekscache slaagde voor onze afgebakende kwaliteitscontrole, maar vermindert momenteel alleen het leeswerk van attention zonder extra bruikbare cachecapaciteit. De technische winst bedroeg ongeveer 4–5% met twee 61K-verzoeken. Dubbele capaciteit in hetzelfde geheugen is nog in ontwikkeling, geen voordeel van deze release. Een langer speculatief blok is een andere onderzoekspiste, geen gepubliceerde instelling in dit artikel.

Credits en licenties

Qwen3.8 27B is van het Qwen-team. Het vastgelegde targetcheckpoint komt van Unsloth en de DFlash2-drafter van tcclaviger, voortbouwend op het DFlash2-werk van z-lab. De uitgebrachte geroteerde gewichten zijn een gekwantiseerde afgeleide onder Apache-2.0. De modelkaart vermeldt ook Apache-2.0 voor die upstreamcheckpoints. De openbare methode bouwt voort op GPTQ en GSQ. vLLM biedt de serverbasis en BetterBench de generatietaken. De openbare runtimehandleiding vermeldt Radiance en StillDeadcode/libr4d voor aangepaste kerneltechnieken.¹³

Voor de openbare adapter, modelgewichten en verpakte native runtime gelden afzonderlijke voorwaarden. De Apache-2.0-licentie van de gewichten is geen algemene licentie voor propriëtaire compiler- of implementatiecode. Kalibratiedatasets behouden ook hun bronvermeldingsvereisten en, waar van toepassing, de Common Crawl-voorwaarden. Bekijk de gepubliceerde vermeldingen vóór inzet.

Ontdek Paiton, lees de vorige Qwen3.8-releasestory of neem contact op om een lokale AMD AI-werklast te bespreken.