Een eerste blik op Paiton in actie: Deepseek R1 Distill Llama 3.1 8B

Betere prestaties dan standaardmodellen op de AMD MI300X

1. Introductie

We konden niet wachten om te tonen waartoe Paiton echt in staat is. Nadat we onze AMD-gerichte aanpak en optimalisaties op architectuurniveau in onze vorige blogpost hadden toegelicht, besloten we Paiton te testen met een model dat veel aandacht krijgt: Deepseek R1 Distill Llama 3.1 8B. We compileren het model naar efficiënte bibliotheken en combineren bewerkingen in kernels op maat. Die kernelementen van Paiton vermijden veelvoorkomende overhead, zoals herhaalde warm-ups en het capturen van CUDA graphs, die de prestaties in de praktijk vaak beperken. Ons doel was eenvoudig: nagaan hoe een met Paiton geoptimaliseerde versie van Deepseek R1 presteert tegenover de standaardversie op AMD MI300X-hardware.

Voor onze recentste online serving-tests gebruikten we vLLM met eager mode uitgeschakeld en CUDA graphs actief. Zo meten we representatieve first-run-prestaties. Het gekozen model is Deepseek R1 Distill Llama 3.1 8B, een gespecialiseerde Llama-variant die ontworpen is om latency en rekenkosten te beperken. We vergelijken:

1. Standaard Deepseek R1 Distill Llama 3.1 8B
2. Met Paiton geoptimaliseerd Deepseek R1 Distill Llama 3.1 8B

Voor het standaardmodel schakelden we alle relevante optimalisaties van vLLM en onze omgeving in: threadtuning, pinned GPU memory, concurrency-optimalisaties en de gebruikelijke performance flags. Zo kreeg de standaardversie alle kansen om optimaal te presteren. Toch komt Paiton als beste uit de vergelijking, vooral bij grotere batchgroottes.

We bekijken eerst de throughput (requests/s en tokens/s) en daarna de latency (TTFT, TPOT en ITL). Tot slot analyseren we de grafieken voor end-to-end latency. De korte conclusie: Paiton levert in de praktijk consistent betere algemene prestaties. Bij grotere batchgroottes is het verschil met de standaardversie bijzonder duidelijk, zowel voor throughput als latency.

Opmerking: deze benchmarks zijn midden januari uitgevoerd. Het landschap van LLM-engines evolueert snel, maar de optimalisaties van Paiton op modelniveau versterken doorgaans ook latere verbeteringen aan de engine.

2. Modeloverzicht

Deepseek R1 Distill Llama 3.1 8B

• Een gedistilleerde Llama 3.1-variant die gericht is op lagere latency en een lagere GPU-belasting.
• Geschikt voor online serving waarbij snelheid en geheugenefficiëntie essentieel zijn.

Waarom vLLM voor online serving?

• Actieve ontwikkeling van de scheduler- en samplermodules.
• Benchmarking die aansluit bij realtime gebruikspatronen.
• Ondersteuning voor uiteenlopende concurrency- en batchconfiguraties.

(We blijven SGLang onderzoeken, maar voorlopig is vLLM onze voorkeursengine voor deze online serving-tests.)

3. Benchmarkopstelling

• Hardware: AMD MI300X-server (met meerdere MI300X GPU's), gelegen in ons hoofddatacenter (Server A).
• Client: aanvragen worden vanaf Server B op een andere locatie verzonden om realistische netwerklatency na te bootsen.
• Engine: vLLM 0.6.3
• Tensorparallelisme: 1
• Batchgroottes: variërend van 1 tot 4096.
• Invoer-/uitvoertokens: standaardinstellingen
• Dataset: we hebben de ShareGPT-dataset gebruikt om realistische gebruikersquery's te genereren.
• Metrics:
  • Throughput: requests/s, output tokens/s en totale tokens/s.
  • Latency: TTFT (Time to First Token), TPOT (Time Per Output Token) en ITL (Inter-Token Latency).

Deze metingen bootsen een productieomgeving na, waarin gebruikersaanvragen onregelmatig binnenkomen in plaats van in netjes vooraf geplande batches.

4. Throughput

Throughputvergelijking: standaardmodel tegenover Paiton

We maten de throughput aan de hand van verschillende metrics:

• Succ. Req (Stock/Paiton): het aantal aanvragen dat tijdens de benchmark met succes is verwerkt.
• Duur (Stock/Paiton): Hoe lang elke test duurde, in seconden.
• Req/s (Stock/Paiton): requests per seconde, een rechtstreekse maatstaf voor concurrency.
• Out Tok/s (Stock/Paiton): hoeveel uitvoertokens er per seconde zijn gegenereerd, wat aangeeft hoe snel het model tekst produceert zodra het is gestart.
• Total Tok/s (Stock/Paiton): de som van de input- en outputtokens die per seconde worden verwerkt, als algemene maatstaf voor tokenthroughput.

Hieronder vindt u de tabel met resultaten van batchgrootte 1 tot 4096:

Gedetailleerde observaties

• Req/s (requests per seconde)
  • Kleine batches (1–8): Paiton ligt ongeveer 1 tot 4% achter voor ruwe Req/s. Kleinere batches benutten de fused kernels en concurrencyvoordelen van Paiton momenteel nog niet volledig.
  • Middelgrote batches (16–128): beide versies komen dichter bij elkaar. Paiton neemt voor Req/s soms de leiding, wat wijst op een betere verwerking van gelijktijdige aanvragen.
  • Grote batches (256–4096): Paiton schaalt aanzienlijk beter, bijvoorbeeld bij 512 (Stock ~13,37, Paiton ~18,54) en 4096 (Stock ~15,94, Paiton ~20,45).
• Out Tok/s (uitvoertokens/s)
  • Geeft weer hoe snel het systeem reactietokens kan produceren zodra het genereren begint.
  • Bij batchgrootte 512 haalt Stock ~2981,57, tegenover ~4126,93 voor Paiton. Dat is 38% meer outputtokens per seconde. Bij lange tekstuitvoer, zoals samenvattingen of gesprekken, merken eindgebruikers dit als een duidelijk snellere respons.
• Totaal tok/s (invoer + uitvoer)
  • Een algemene maatstaf voor het aantal verwerkte tokens.
  • Bij grotere batches evenaart of overtreft Paiton de standaardversie consequent. Bij batchgrootte 4096 stijgt het resultaat bijvoorbeeld van ~6612 naar ~8471, een totale verbetering van ongeveer 28%.
• Duur
  • De duur van de testruns toont eveneens dat Paiton een vergelijkbare workload bij bepaalde batchgroottes sneller voltooit. Bij 512 duurt Stock bijvoorbeeld ~36,43 seconden, tegenover ~26,33 seconden voor Paiton.

Opmerking: ook de volledige opstarttijd is aanzienlijk korter. Dat omvat het starten van vLLM, het laden en klaarmaken van het model en het initiëren van een aanvraag vanaf een tweede server.

Voorbeelden uit de praktijk

• Chatbots met pieken in aanvragen: bij een plotse toestroom van gebruikers ontstaan vaak batches tussen 64 en 256. Het concurrencyvoordeel van Paiton zorgt bij deze groottes voor meer Req/s en snellere antwoorden.
• Bulk-inferentietaken (batchgrootte 512+): bij het samenvatten van grote documenten of verwerken van veel aanvragen houdt Paiton de vertraging beperkt, terwijl de throughput van het standaardmodel begint af te vlakken of te dalen.

Interpretatie:

• Subplot 1: Rechtstreekse concurrencymaatstaf (Req/s). Naarmate de batchgrootte toeneemt, presteert Paiton doorgaans beter dan Stock. Dat weerspiegelt de betere scheduling en fused kernels.
• Subplot 2: Uitvoertokens/s laat zien hoe snel grote hoeveelheden tekst worden gegenereerd.
• Subplot 3: Total tokens/s combineert de verwerking van input- en outputtokens. Dat helpt om de tokenthroughput over de volledige pipeline te analyseren.

5. Latentie

Naast ruwe throughput is latency cruciaal voor elke realtime of interactieve toepassing. We hebben ons specifiek gericht op:

• TTFT (Time-to-First-Token): hoe snel het allereerste token wordt geproduceerd na een inferentieverzoek.
• TPOT (Time-Per-Output-Token): hoe lang het duurt om elk volgend token te genereren.
• ITL (Inter-Token Latency): de tijd tussen opeenvolgende tokens, bijzonder relevant bij streaming output.

Standaardmodel tegenover Paiton: TTFT, TPOT en ITL

Hieronder vindt u de latentiegegevens die we hebben verzameld bij batchgroottes variërend van 1 tot 4096:

Tijd tot eerste token (TTFT)

• De eerste indruk telt: bij interactieve toepassingen zoals chatbots ervaren gebruikers de snelheid vanaf het moment waarop het eerste token verschijnt.
• Aanzienlijke winst: Paiton is bij vrijwel alle batchgroottes sneller, bij de grootste batches soms met tienduizenden milliseconden.

TPOT & ITL

• Snelheid van tokengeneratie: nadat het eerste token verschijnt, moet ook de rest van de output snel volgen. TPOT meet het aantal milliseconden per outputtoken en bepaalt zo in grote mate de totale throughput van een lang antwoord.
• Stabiliteit: bij grotere batchgroottes (256+) blijft de TPOT van Paiton relatief stabiel, terwijl die van het standaardmodel sterker kan pieken.
  • Bij batchgrootte 2048 bedraagt de TPOT bijvoorbeeld ~95,91 ms voor Stock en ~58,61 ms voor Paiton. Over 50 tokens loopt dat verschil op tot 1,9 seconden extra generatietijd.

Impact in de praktijk

• Kleine batches:
  • Het verschil in TTFT bedraagt soms maar tientallen of honderden milliseconden, maar zelfs dat is belangrijk in toepassingen met lage latency, zoals type-ahead.
  • Een eerste token dat een halve seconde sneller verschijnt, kan voor eindgebruikers al veel responsiever aanvoelen.
• Grote batches:
  • Wanneer uw systeem veel aanvragen in de wachtrij plaatst of verkeerspieken verwerkt, voorkomt de stabielere TPOT en TTFT van Paiton dat de totale responstijd exponentieel oploopt.
  • Het resultaat is een lagere end-to-end latency (sectie 6) en meer capaciteit voor gelijktijdige aanvragen.

De grafieken interpreteren:

• TTFT-plot:
  • De Stock-lijn stijgt snel bij grotere batchgroottes, terwijl die van Paiton relatief lager blijft. Dat is cruciaal voor de snelheid waarmee het eerste token verschijnt.
• TPOT-plot:
  • De lijn van Paiton kan bij kleine batchgroottes iets hoger liggen en bij grote batchgroottes iets lager. Dat hangt af van de concurrencyoverhead tegenover de efficiëntie van de kernels. Over het geheel genomen is de trend stabieler dan bij het standaardmodel.

6. Verdere analyse: latency tegenover throughput

Waarom latency naast throughput telt

Eén throughputmetric, zoals requests per seconde, vertelt niet het volledige verhaal. Bij chatbots, vraag-antwoordsystemen en andere interactieve toepassingen hangt de gebruikerservaring sterk af van de latency: hoe snel het model begint te antwoorden (TTFT) en hoe snel de volgende tokens verschijnen (TPOT of ITL).

E2E-latentie: nader bekeken

We benaderen de end-to-end latency (E2E) met de formule:

E2E Latency ≈ TTFT + (num_tokens×TPOT)

waarbij:

• TTFT (Time-to-First-Token): de tijd voordat het eerste token wordt teruggegeven.
• TPOT (Time-Per-Output-Token): de tijd die ieder volgend token na het eerste nodig heeft.

Dit betekent dat elke verbetering in TTFT, TPOT of beide de E2E-latentie aanzienlijk kan verlagen.

In het ideale geval wilt u zowel een hoge doorvoer als een lage latentie. In realtime contexten (chatbots, vraag- en antwoordsystemen) zijn tokens/sec/gebruiker ook van belang. Hieronder ziet u een vereenvoudigd diagram (conceptueel) dat laat zien hoe een optimale aanpak de latentie-doorvoercurve naar boven en naar links verplaatst.

(Throughput) ↑

             |  ● Paiton model

             |               ● Stock model

             |`

             +--------------------------------→ (E2E Latency)

De cijfers vertalen naar praktijkscenario's

Door te kijken naar zowel batchgrootte als TTFT in de bovenstaande tabellen:

• Bij batchgrootte 512:
  • Stock TTFT is ~6788 ms, terwijl Paiton TTFT ~4440 ms is, een 2,3 seconde verschil.
  • Zodra u rekening houdt met meerdere tokens, bijvoorbeeld 50 tot 100 voor een gemiddeld chatbotantwoord, neemt het verschil in E2E-latency verder toe.
• Bij batchgrootte 2048:
  • De TTFT van Stock stijgt naar ~65322 ms, terwijl Paiton op ~37294 ms blijft. Dat verkort de wachttijd tot het eerste token met ongeveer 28 seconden. Voor gebruikers die grote outputs aanvragen in een omgeving met hoge concurrency kan dat het verschil maken tussen een responsieve en een onbruikbare toepassing.

Tegelijk blijft de throughput bij dezelfde batchgroottes aanzienlijk hoger met Paiton. U kunt dus meer aanvragen gelijktijdig verwerken en een snellere time-to-first-token bieden.

De curves interpreteren

Als we de doorvoer (Verzoeken/s) uitzetten tegen een geschatte E2E-latentie (TTFT + tokens × TPOT):

1. De Paiton-curve ligt doorgaans boven en links van de Stock-curve. Bij eenzelfde throughput is de E2E-latency dus lager. Omgekeerd kan Paiton bij een bepaalde latencyvereiste meer aanvragen per seconde verwerken.
2. Schaalgedrag: naarmate de batchgrootte stijgt naar 256, 512, 1024, 2048 en 4096, loopt de TTFT van het Stock-model sterk op. Dat veroorzaakt een hoge E2E-latency. De TTFT van Paiton neemt eveneens toe, maar trager, waardoor het systeem onder belasting responsiever blijft.

Belangrijkste aandachtspunten voor productie

• Hogere gelijktijdigheid: het model kan een grote wachtrij aan verzoeken afhandelen zonder de E2E-latentie tot ondraaglijke niveaus te laten stijgen.
• Betere gebruikerservaring: vooral de snelheid van het eerste token bepaalt hoe responsief een sessie aanvoelt. Zelfs als het laatste token maar iets vroeger aankomt, houdt die snelle eerste reactie eindgebruikers betrokken.
• Schaalbaarheid: als uw applicatie af en toe veel verkeer genereert (honderden of duizenden gelijktijdige verzoeken), zorgt de aanpak van Paiton ervoor dat u geen exponentiële stijging van de responstijd ziet.

Voorbeeld: als u 100 tokens per verzoek genereert

Met behulp van de formule TTFT + 100 × TPOT:

• Bij batchgrootte 512:
  • Standaard E2E ≈ 6788 + 100 × 87,42 = 6788 + 8742 = 15.530 ms ≈ 15,5 s
  • Paiton E2E ≈ 4440 + 100 × 57,89 = 4440 + 5789 = 10.229 ms ≈ 10,2 s

In dit scenario levert Paiton voor een antwoord van dezelfde lengte een meer dan 5 seconden lagere end-to-end latency, zelfs zonder het throughputvoordeel mee te rekenen. Bij duizenden gelijktijdige aanvragen wordt de impact op de gebruikerstevredenheid en infrastructuurbelasting aanzienlijk.

7. Belangrijkste observaties

Algemene voorsprong

• Kleine batches:
  • De throughput is vaak vergelijkbaar met Stock, of ligt iets lager, maar de TTFT is consequent beter. Dat is belangrijk voor gebruikersgerichte scenario's met weinig concurrency.
• Middelgrote tot grote batches:
  • De winst in doorvoer en latentie wordt aanzienlijk; Paiton blinkt uit in het benutten van gelijktijdigheid en gefuseerde kernels voor AMD GPU's.

Sterke prestaties bij grote batches

• 512 Voorbeeld:
  • Stock ≈ 13,37 req/s tegenover Paiton ≈ 18,54, een stijging van ongeveer 38% in ruwe throughput.
• 4096 Voorbeeld:
  • Stock ≈ 15,94 req/s tegenover Paiton ≈ 20,45, een verbetering van ongeveer 28%.
• Latentiewinst: TTFT-verschillen bij hoge batches variëren soms van duizenden ms, waardoor de gebruikerservaring voor grootschalige taken dramatisch wordt verbeterd.

Impact in de praktijk

1. Kleine batches (sporadische aanvragen)
   • Een snellere Time-to-First-Token geeft eindgebruikers vrijwel onmiddellijk respons, essentieel voor chatbots en realtime prompts.
2. Grote batches (piekbelasting en lange wachtrijen)
   • De efficiëntere schaling van Paiton kan in bepaalde gevallen tot 50% meer verzoeken verwerken.
   • Ideaal voor bulk-inferentietaken zoals samenvatten en grootschalige embeddings genereren.

Gevolgen voor kosten en energieverbruik

• Betere doorvoer vertaalt zich vaak in lagere cloudkosten bij het huren van GPU-tijd, omdat u workloads sneller kunt voltooien of meer gebruikers op dezelfde hardware kunt bedienen.
• Lagere latentie en minder inactieve cycli betekenen vaak energiebesparingen, vooral op grote HPC-clusters of datacenters met AMD MI300X GPU's.

Multi-GPU en HPC-schaling

• Hoewel deze resultaten één systeem behandelen, worden de voordelen van concurrency en kernelfusie bij multi-GPU- en HPC-opstellingen doorgaans nog groter.
• Toekomstige tests zullen aantonen hoe de architectuurgerichte compilatie van Paiton over meerdere AMD GPU's met veel VRAM schaalt en zo consistente prestatieverbeteringen biedt, ongeacht de clustergrootte.

8. Conclusie en volgende stappen

Hoewel we het standaardmodel Deepseek R1 Distill Llama 3.1 8B alle beschikbare voordelen binnen vLLM gaven, behoudt Paiton een duidelijke voorsprong in zowel throughput als latency:

• Betere TTFT voor onmiddellijke responsiviteit.
• Gelijke of hogere doorvoer bij middelgrote batchgroottes.
• Aanzienlijke doorvoerwinst bij grote batchgroottes, wat superieure schaling op AMD MI300X-hardware aantoont.

Vooruitkijken

• SGLang-evaluaties: we blijven onderzoeken hoe het concurrencymodel van SGLang samengaat met de AMD-optimalisaties van Paiton.
• Tokens/sec/gebruiker: toekomstige artikels behandelen metrics voor meerdere gebruikers, essentieel voor grootschalige chatbots.
• FP8 en andere kwantisering: het balanceren van nauwkeurigheid en snelheid is een prioriteit, en we zijn van plan om te delen hoe inferentie met ultra-lage precisie presteert op AMD.
• Optimalisatie van lagere batchgroottes: Zoals blijkt uit deze blog blinkt Paiton duidelijk uit als het gaat om hogere batchgroottes, ideaal voor productieomgevingen, maar we zullen ons werk voortzetten om ook voor kleinere batchgroottes te optimaliseren.
• Tensorparallelisme: multi-GPU-inferentie en het optimaliseren met Paiton van grotere modellen, zoals Deepseek R1 met 671 miljard parameters.

Onthoud: de LLM-ruimte evolueert snel. De bibliotheken van morgen kunnen die van vandaag overtreffen, maar de architecturale aanpak van Paiton zorgt ervoor dat u altijd kunt profiteren van toekomstige verbeteringen aan de engine.

Bijlage

• Vorige blog: “AI-modeloptimalisatie met Paiton” voor meer informatie over fused kernels en AMD-gerichte compilatie.
• Blijf op de hoogte: We zullen meer resultaten delen naarmate we elk aspect van de pijplijn blijven optimaliseren, zodat Paiton nog betere prestaties levert.

Bedankt voor het lezen! Voor vragen, samenwerkingsideeën of specifieke LLM-engineverzoeken kunt u contact met ons opnemen. Houd ons in de gaten voor verdere gedetailleerde vergelijkingen en omgevingsinstellingen waarmee u topprestaties op AMD GPU's kunt realiseren.

Het Paiton-team