vLLM Benchmark: Qwen3-8B vs Llama 3.1 8B vs Ministral 8B op een enkele A10

We hebben GuideLLM-benchmarktests met gelijktijdigheid uitgevoerd voor drie modellen met 8 miljard parameters op een enkele NVIDIA A10 (24 GB) GPU: Qwen3-8B, Llama 3.1 8B Instruct en Ministral 8B. Deze vLLM-benchmark varieerde de gelijktijdigheid van 4 tot 256 simultane gebruikers over twee workloads: korte conversationele chat en intentieclassificatie. Eén model hield stand over het gehele bereik. De andere twee niet.

De opstelling

Alle drie de modellen draaiden in FP16 op vLLM, geserveerd via het standaard /v1/chat/completions streaming-eindpunt. GuideLLM hield gedurende 90 seconden per gelijktijdigheidsniveau (4, 8, 16, 32, 64, 128, 256) exact N aanvragen actief, met 30 seconden afkoeltijd tussen de niveaus.

Twee workloads:

• Korte chat: ongeveer 180 input-tokens, 130-150 output-tokens. Weerspiegelt een copilot- of conversationele assistent-use case.
• Classifier: ongeveer 60 input-tokens, 4 output-tokens. Weerspiegelt een intentie-router of ticket-classifier.

Dezelfde vLLM-versie, dezelfde gateway-configuratie en dezelfde GPU voor alle drie. De onderstaande resultaten weerspiegelen deze omstandigheden.

Resultaten in één oogopslag

De samenvattende tabel gebruikt 64 gelijktijdige gebruikers voor de vergelijking van korte chat. Dat is het laatste gelijktijdigheidsniveau waarop Llama foutloos draaide (0% fouten), waardoor het de eerlijkste gemeenschappelijke uitgangspositie is voor alle drie de modellen.

Qwen3 heeft de laagste typische wachttijd (524 ms p50) en de strakste tail (2.840 ms p95). Llama levert 11% meer tokens per seconde, maar de mediane gebruiker wacht 2.569 ms op het eerste token vergeleken met 524 ms bij Qwen3. Eén ding viel op in de data: Llama's E2E p95 (10,4 s) is lager dan die van Qwen3 (11,4 s), hoewel de TTFT veel slechter is. Llama start langzaam, maar decodeert snel. Zodra tokens beginnen te stromen, gaan ze sneller dan bij Qwen3. Voor streaming UI's is die vertraging bij het eerste token echter wat gebruikers daadwerkelijk merken.

Volledige percentieloverzichten op elk gelijktijdigheidsniveau, resultaten bij Poisson-piekverkeer en downloadbare CSV's zijn te vinden in het interactieve benchmarkrapport.

Korte chat: wie faalt het eerst onder gelijktijdige belasting

Bij lage gelijktijdigheid begonnen alle drie de modellen met ongeveer dezelfde TTFT p50, rond 350 ms. Qwen3 bleef daar. Bij 16 gelijktijdige gebruikers was de p50 van Qwen3 388 ms. Die van Llama was al opgelopen tot 794 ms.

Qwen3-8B: nul fouten op elk niveau

Qwen3 voltooide elke aanvraag op elk gelijktijdigheidsniveau tot 256. Geen weggevallen aanvragen. TTFT p50 bij 64 gelijktijdige gebruikers was 524 ms met een throughput van 851 tok/s.

Onze werkhypothese voor waarom het standhoudt onder belasting: Qwen3 gebruikt QK-LayerNorm, wat attention scores stabiliseert bij lange KV caches, en de iets kleinere KV-footprint per laag geeft vLLM meer scheduling-ruimte voordat aanvragen zich opstapelen bij de gateway. Llama's grotere FFN (14.336 vs. 12.288 bij Qwen3) zorgt voor een hogere throughput per token, maar vult de decode pipeline sneller, waardoor er minder ruimte overblijft voor nieuwe prefills naarmate de gelijktijdigheid toeneemt. We doen nog onderzoek, maar het architectuurverschil lijkt hier van belang te zijn.

Llama 3.1 8B: hoogste throughput, stort in bij 128

Llama behaalde de hoogste ruwe throughput in de piek: 1.181 tok/s bij een gelijktijdigheid van 256. Bij een gelijktijdigheid van 128 kregen echter 86,9% van de aanvragen een 408-timeout. Het cijfer van 1.181 tok/s is afkomstig van de weinige aanvragen die doorkwamen nadat de server het grootste deel van zijn wachtrij al had laten vallen.

Bij 64 gelijktijdige gebruikers (het laatste foutloze punt) leverde Llama 947 tok/s met een TTFT p95 van 4.062 ms en 0% fouten. Dat is 11% meer throughput dan Qwen3 bij dezelfde belasting. Voor batch-inference of asynchrone pipelines waar retries acceptabel zijn, is dat throughput-voordeel reëel. Beperk dit voor interactief gebruik tot 32-64 gelijktijdige gebruikers.

Ministral 8B: aanhoudende fouten over het gehele bereik

We moeten dit eerlijk vermelden. Ministral vertoonde 3,8% echte HTTP-fouten bij een gelijktijdigheid van 4, de lichtste belasting die we hebben getest. Bij 64 gelijktijdige gebruikers was dit 5,3%. Bij 128 bereikte het 8,9%. Dit waren daadwerkelijke 408/503-fouten, geen artefacts van de benchmark. Dit weerspiegelt waarschijnlijk instabiliteit van de deployment tijdens onze testperiode in plaats van een fundamentele beperking van het model, maar de gegevens spreken voor zich.

Waar aanvragen slaagden, was de latency van Ministral competitief: TTFT p50 van 350 ms bij de nullijn en 512 ms bij een gelijktijdigheid van 64, dicht bij de 524 ms van Qwen3. Latency-cijfers zeggen echter niet veel als ongeveer 1 op de 20 aanvragen nooit een antwoord krijgt.

Classificatie: alle drie bereikten 256 gelijktijdige gebruikers, maar latency-curves lopen uiteen

Voor de classifier-workload draaiden alle drie de modellen foutloos tot 256 gelijktijdige gebruikers met 0% fouten. Llama leidde op het gebied van ruwe aanvragen per seconde (173 RPS), gevolgd door Qwen3 (157 RPS) en Ministral (143 RPS).

Het meerzeggende cijfer is hoeveel de latency veranderde onder belasting. Qwen3's TTFT p95 bij 128 gelijktijdige gebruikers was 541 ms, slechts 32% boven de uitgangswaarde van 409 ms. De p50 verschoof van 358 ms naar 467 ms. Llama's p95 verdubbelde bijna (351 ms naar 689 ms). Die van Ministral meer dan verdubbelde (390 ms naar 823 ms).

Als u een intentie-router of classifier nodig hebt met voorspelbare latency bij piekerig verkeer, is de vlakke curve van Qwen3 de moeite waard om te bekijken. De GPU verwerkt korte classifier-aanvragen in één batch zonder wachtrijen, en dat is terug te zien in de cijfers.

Throughput-schaling over de test

Alle drie beginnen op hetzelfde punt en schalen lineair tot 16 gelijktijdige gebruikers. Daarna ontstaat de kloof.

Boven de 64 blijft Llama's throughput op papier stijgen (1.181 tok/s bij 256), maar het merendeel van de aanvragen wordt geweigerd. Qwen3 stabiliseert rond 830-850 tok/s en verwerkt elke aanvraag. Ministral blijft bij 64 gelijktijdige gebruikers ongeveer 15% achter op Qwen3, zelfs onder de geslaagde aanvragen.

Het ruwe piekgetal zonder een foutpercentage daarnaast is vrijwel betekenisloos voor capaciteitsplanning. Dat tonen al deze drie vLLM-benchmarks aan.

Welk model te implementeren

• Chat en copilots: Implementeer Qwen3-8B. Het laat geen aanvragen vallen, schaalt soepel en de TTFT is competitief. Begrens de gelijktijdigheid op 64 voor interactief gebruik (TTFT p95 blijft onder 3 seconden) of ga hoger voor asynchrone workloads.
• Batch-inference: Llama 3.1 8B, begrensd op 64 gelijktijdige gebruikers. Daarboven laat de gateway aanvragen agressief vallen. De beste keuze wanneer u retries kunt uitvoeren en maximale tokens per GPU-seconde wilt.
• Classificatie: Elk van de drie werkt op schaal. Allemaal draaiden ze foutloos tot 256 gelijktijdige gebruikers. Llama is ongeveer 10% sneller in ruwe RPS. Qwen3 heeft de meest constante latency onder belasting.
• Ministral 8B: Opnieuw testen op een schone deployment voordat er conclusies worden getrokken. De aanhoudende fouten bij lage gelijktijdigheid in chat maken de data van deze test onbetrouwbaar voor streaming workloads.
  

Hoe u deze modellen serveert met TrueFoundry

We hebben deze vLLM-benchmark uitgevoerd op een enkele A10 spot instance die is geimplementeerd via TrueFoundry. De volledige vLLM-configuratie en GuideLLM-commando's worden gepubliceerd bij het verdiepende artikel.

TrueFoundry's model serving-laag implementeert vLLM-backends op elk GPU-tier (A10, A100, H100) rechtstreeks vanuit het control plane. U kiest het model, stelt max_model_len en tensor_parallel_size in, en TrueFoundry beheert de container, de GPU-toewijzing en de health checks. Het model komt beschikbaar op een standaard OpenAI-compatibel eindpunt.

Vóór vLLM voegt TrueFoundry's AI Gateway ongeveer 3-4 ms overhead toe, terwijl het 350+ RPS verwerkt op een enkele vCPU. Het biedt u rate limits per model, kostentoewijzing, fallback-routing over providers en een volledige request trace. Als u meerdere modellen vergelijkt (zoals in deze benchmark), kunt u ze alle drie via hetzelfde gateway-eindpunt routen en ertussen wisselen door het model-veld in de aanvraag te wijzigen. De URL en inloggegevens blijven hetzelfde.

TrueFoundry ondersteunt 1.000+ LLM's via één enkele OpenAI-compatibele API, dus overstappen van een gebenchmarkt open-weight model naar een commerciële provider vereist geen wijzigingen aan de clientzijde.

Voor teams die open-weight modellen zelf hosten achter een gateway, houdt deze architectuur de serving-laag gescheiden van routing en governance. Zie 10 Best LLM Observability Tools in 2026 voor het monitoren van uw vLLM-deployment zodra deze actief is.

Gerelateerde artikelen

• Top 5 LiteLLM Alternatives in 2026 — als u gateway-opties evalueert naast model serving
• 10 Best LLM Observability Tools in 2026 — monitoren van uw vLLM-deployment in productie
  

Conclusie

Deze vLLM-benchmark maakt één ding duidelijk: throughput-cijfers moeten vergezeld gaan van foutpercentages om enige betekenis te hebben. Llama 3.1 8B's piek van 1.181 tok/s ziet er indrukwekkend uit, totdat u ziet dat 87% van de aanvragen bij die belasting een timeout kreeg. Qwen3-8B's 851 tok/s bij 64 gelijktijdige gebruikers, met nul fouten tot 256, is het cijfer dat telt voor productieplanning.

Voor de selectie van een 8B-model op een enkele A10 wijzen de gegevens in de richting van Qwen3 voor interactieve workloads en Llama voor batch-taken waarbij u de gelijktijdigheid beheert en retries kunt opvangen. Ministral heeft een schone herbeschouwing nodig vóór een eventuele aanbeveling voor productie.