QwQ-32B optimaliseren (door Qwen): AMD MI300X versus NVIDIA H200

1. Introductie

In de wereld van grote taalmodellen (LLM's) richten de meeste benchmarks zich op afgeleiden van Llama of DeepSeek. Daarom voegden we met ons Paiton-framework ook de Qwen2-architectuur toe. Dit model met 32 miljard parameters benut de GPU maximaal en vormt een sterke basis om NVIDIA's H200 te vergelijken met de AMD MI300X, waarop Paiton geavanceerde concurrency en aangepaste kernelcompilatie toepast.

Waarom QwQ-32B?

• Veel parameters: Met 32 miljard parameters kan het model complexe dialogen, domeinspecifieke kennis en geavanceerd redeneren aan.
• Minder gebruikelijk: gaat verder dan de typische Llama/DeepSeek-oplossingen, waardoor we de flexibiliteit van Paiton bij het optimaliseren van een breder scala aan LLM's kunnen benadrukken.
• Ongelooflijke resultaten: vooral QwQ-32B laat geweldige resultaten zien vergeleken met Deepseek-R1, GPT-4o, Claude 3.7 en andere modellen die relatief groot zijn.

Deze resultaten zijn hier te vinden: Artificial Analysis AI

2. Paiton- en vLLM-versies

Paiton op AMD MI300X

• vLLM: We gebruikten vLLM 0.7.3 voor Paiton. Hoewel er nieuwere versies (zoals 0.8.0) bestaan, is ons testsysteem geconfigureerd met 0.7.3, dat nog steeds profiteert van veel gelijktijdigheidsverbeteringen.
• Vlaggen: standaardomgeving, op HIP gebaseerde gelijktijdigheid, geen verborgen schakelaars naast de kernelfusie van Paiton.

Runs met standaard-vLLM

• NVIDIA H200: vLLM 0.8.0 uitvoeren met de best geteste opties:
  • CUDA-grafiek vastleggen ingeschakeld (via standaard of expliciete vlaggen)
  • “V1” gelijktijdigheidsplanning (standaard in vLLM 0.8.0, indien use-case ondersteund)
• AMD MI300X (standaard): Voor een directe vergelijking tussen standaard-vLLM en Paiton testten we ook dezelfde vLLM-versie als Paiton, vLLM 0.7.3, met de beste beschikbare flags:
  • --num_sched_steps=10
  • CUDA-grafiek vastleggen (waar relevant)
  • Bepaalde functies in- of uitschakelen voor optimale gelijktijdigheid

We wilden ervoor zorgen dat elke GPU de best mogelijke omgeving had.

Opmerking: bij de standaardruns op AMD passen we Paiton's aangepaste kernelcompilatie en concurrencylogica niet toe. Zo meten we de native prestaties van de MI300X.

3. Testopstelling en methodologie

Hardware

• NVIDIA H200 (enkele GPU)
• AMD MI300X (enkele GPU), getest in twee modi:
  1. Paiton-geoptimaliseerd
  2. Standaard-vLLM, dezelfde versie als Paiton (0.7.3), met de beste concurrencyflags.

Model en commando

QwQ-32B geserveerd met:

vllm serve Qwen/QwQ-32B --num-scheduler-steps=10 --swap-space=16 ...

• Voor de H200 hebben we de standaard gelijktijdigheidsaanpak gebruikt (-tp 1 of vergelijkbaar) plus 'V1-planning'.
• Geteste batchgroottes: van 1 tot 128.

Metrics: verzoeken/s, throughput van outputtokens, TTFT, TPOT, ITL en E2E-latency.

4. Resultaten: standaard-vLLM versus Paiton

We hebben de prestatiegegevens opgesplitst in twee hoofdtabellen, één voor doorvoerstatistieken en één voor latentiestatistieken. Daarna ziet u grafieken in de tekst, telkens met een toelichting op de vergelijkende prestaties van AMD MI300X en NVIDIA H200.

4.1 Doorvoertabellen

Standaard-vLLM: AMD MI300X

Standaardmodel: NVIDIA H200

Paiton op AMD MI300X

Grafiek 1: Verzoeken/s versus batchgrootte

(Hoger is beter.)

Opmerking: Merk op hoe bij kleine tot middelgrote batchgroottes (bijvoorbeeld 1 tot 32) Paiton op MI300X de verzoeken per seconde van de H200 evenaart of overtreft. Naarmate de batchgrootte groter wordt dan 64, heeft de H200 nog steeds een lichte voorsprong, maar Paiton verkleint de kloof vergeleken met de "standaard" AMD-runs. Dit onderstreept het vermogen van AMD MI300X om NVIDIA H200 te overtreffen of nauw te evenaren onder veel gelijktijdigheidsomstandigheden wanneer optimalisaties (Paiton) worden toegepast.

4.2 Latentietabellen

Standaard-vLLM: AMD MI300X

Standaardmodel: NVIDIA H200

Paiton op AMD MI300X

Grafiek 2: Tijd tot eerste token (TTFT) versus batchgrootte

(Lager is beter)

Opmerking: TTFT is de vertraging voordat een enkel token wordt geproduceerd. Bij lage batchgroottes ligt H200 iets voor. Zodra we echter Paiton toepassen op de MI300X, wordt het verschil bij kleine gelijktijdigheid kleiner. Uit de gegevens blijkt ook dat AMD + Paiton de TTFT binnen een concurrerend bereik kan houden zodra de batchgrootte boven 8 of 16 uitkomt.

Grafiek 3: gemiddelde end-to-end latentie (E2E) versus batchgrootte

(Lager is beter)

Opmerking: E2E-latency omvat het volledige verzoek, vanaf het indienen van de prompt tot het genereren van het laatste token. Met Paiton verlaagt de MI300X de E2E-latency consequent ten opzichte van de standaard AMD-resultaten en kan hij bij veel batchgroottes met de H200 wedijveren.

5. Analyse en observaties

Vergelijking bij kleine batches

• Batch=1 of 2: Paiton op MI300X en de H200 liggen qua doorvoer extreem dicht bij elkaar (~0,4–0,44 req/s).
• TTFT voor Paiton op MI300X is iets hoger (61 ms versus 44 ms op H200 bij batch=1), maar de algehele E2EL blijft in hetzelfde bereik (~2,29–2,48 s).

Grafiek 4: Verzoeken/s vs. E2E-latentie (kleine batches)

(Lager is beter)

Opmerking: als we verzoeken/s specifiek uitzetten tegen end-to-end latentie voor kleine batchgroottes (1-8), kan de MI300X met Paiton niet alleen de gelijktijdigheid van de H200 evenaren, maar in sommige runs zelfs overschrijden. Dit is een belangrijk voorbeeld van hoe gerichte optimalisaties de hardware van AMD verder kunnen brengen.

Middenbatches (16–32)

• AMD + Paiton heeft bij batch=32 bijvoorbeeld een lichte voorsprong in req/s ten opzichte van standaard AMD (1,9 tegenover 1,79) en nadert de concurrency van de H200.
• TTFT ziet een sprong (bereik van 472-928 ms), wat typisch is voor grote LLM's, maar de gelijktijdigheidsaanpak van Paiton helpt het totale aantal tokens/s hoog te houden.

Grafiek 5: totale doorvoer (tok/s) versus batchgrootte

(Hoger is beter)

Opmerking: de totale tokendoorvoer (invoer- en uitvoertokens) schaalt aanzienlijk met gelijktijdigheid. Merk op hoe Paiton op MI300X daadwerkelijk beter presteert dan de H200 bij bepaalde batches uit het middensegment in termen van tokens die per seconde worden verwerkt, wat aantoont dat de MI300X-architectuur + Paiton's kernelfusie kan schitteren als deze zorgvuldig wordt afgestemd.

Hoge batches (64–128)

• De H200 leidt voorlopig bij batch=128 met 6,0 req/s tegenover 5,56 voor Paiton, maar Paiton presteert beter dan de standaard AMD MI300X met 4,94 req/s.
• De end-to-end-latency kan bij deze grote batches nog steeds ongeveer 9 tot 12 seconden bedragen, wat past bij de zware tokengeneratie van een 32B-model.

Grafiek 6: P99 end-to-end latentie versus batchgrootte

(Lager is beter)

Opmerking: de P99 E2E-latentie bij zeer hoge gelijktijdigheid is begrijpelijkerwijs groot. Hoewel de H200 de top bereikt met een iets hogere verzoekdoorvoer, verkleint MI300X met Paiton de prestatiekloof aanzienlijk. Dit wijst op het sterke potentieel van verdere verfijningen van gelijktijdigheid, waardoor uiteindelijk de prestaties van NVIDIA bij bepaalde workloads overtroffen worden.

Samenvatting: Hoewel de H200 misschien een kleine voorsprong vertoont bij de hoogste gelijktijdigheid, verbetert Paiton de prestaties van de AMD MI300X aanzienlijk buiten de standaardbenadering, vooral bij kleine tot middelgrote batchgroottes. Dit suggereert dat echte AI-clusters een betere schaalbaarheid zouden kunnen zien met behulp van Paiton als gelijktijdigheid of batchplanning zorgvuldig wordt afgestemd.

6. AMD's sterke punten en verdere verbeteringen

• HBM-voordeel: het grote HBM-geheugen van de MI300X zorgt voor stabiele prestaties over een breed tokenbereik; zelfs bij grotere batchgroottes blijft het systeem stabiel.
• Kernelcompilatie: de aangepaste aanpak van Paiton levert betere gelijktijdigheid op, vooral voor kleinere batchbewerkingen, waardoor de typische overhead wordt overbrugd.
• Nog niet “er”: in sommige gevallen met de hoogste batches behoudt de H200 een voorsprong, maar we zijn actief bezig met het verfijnen van Paiton's kernellancerings- en concurrency-strategieën om die kloof te dichten.

QwQ-32B werd minder vaak gebenchmarkt, dus de ondersteuning ervan binnen Paiton demonstreert het model-agnostische ontwerp van onze bibliotheek. Verwacht verdere winst als we de gelijktijdigheidsverbeteringen van vLLM 0.8.x op AMD overnemen of aanpassen.

7. Volgende stappen en toekomstig werk

1. Tensor-parallellisme: evaluatie van multi-GPU-schaling voor QwQ-32B, vooral als AI-clusters latenties van minder dan 2 seconden willen.
2. Geavanceerde kwantisering: 8- of 4-bitscompressie om de geheugenvoetafdruk te verkleinen en inferentie verder te versnellen.
3. Verdere kerneloptimalisaties: gebruik onze huidige en nieuwe optimalisatietechnieken om de hardware nog verder te pushen.
4. RAG: hoe Paiton Retrieval Augmented Generation verbetert.

8. Conclusie

QwQ-32B biedt een nieuw perspectief op grootschalige inferentie buiten de gebruikelijke benchmarks op basis van Llama. Onze resultaten tonen dat:

• Paiton optimaliseert de AMD MI300X en presteert aanzienlijk beter dan standaard-vLLM op dezelfde hardware.
• Bij kleine tot middelgrote batchgroottes zijn de prestaties concurrerend met of beter dan die van NVIDIA's H200.
• Bij grotere batchgroottes is nog ruimte voor verbetering. Die willen we met verdere concurrencyoptimalisaties benutten.

Blijf op de hoogte voor meer updates over verdere integratie en optimalisaties, clusterconcurrency-tests en nieuwe optimalisatiedoorbraken voor op AMD gebaseerde oplossingen. Hebt u vragen of wilt u specifieke tests zien, neem dan contact met ons op. We blijven Paiton verfijnen voor een zo breed mogelijk scala aan modellen en hardware.

Hier hebben we gedemonstreerd hoe cruciaal gelijktijdigheid en optimalisaties op kernelniveau zijn bij het dichten (en vaak overtreffen) van de prestatiekloof met de nieuwste hardware van NVIDIA. Met Paiton is de AMD MI3**-serie voorbestemd om een topkeuze te worden voor high-throughput, grootschalige inferentie.

Bedankt voor het lezen! Het Paiton-team