Supermicro JumpStart Review: Een week met een NVIDIA HGX B200

Het JumpStart-programma van Supermicro hanteert een heel andere aanpak voor hardware-evaluatie. In plaats van een korte, gescripte demo in een gedeelde labomgeving, biedt JumpStart gekwalificeerde klanten gratis, time-boxed, bare-metal toegang tot een catalogus met echte productieservers. Van nieuwe X14-platforms met Intel Xeon 6 tot H14-systemen met 5e generatie AMD EPYC en grote HGX GPU-configuraties: klanten reserveren systemen, loggen op afstand in en voeren hun eigen workloads uit alsof de hardware in hun eigen rack staat.

De bedrijfswaarde wordt duidelijk wanneer er snel en weloverwogen platformbeslissingen worden genomen. Het opstellen van een realistisch proof of concept voor AI of high-performance computing betekent meestal wachten op evaluatiehardware, afstemmen met meerdere leveranciers en hopen dat de testconfiguratie voldoende aansluit bij wat u van plan bent te implementeren. JumpStart neemt die frictie weg. Teams kunnen de prestaties valideren, de softwarecompatibiliteit controleren, het stroomverbruik en thermisch gedrag onderzoeken en architecturen vergelijken zonder interne labcycli te verspillen of een pallet servers door het hele land te verschepen. Voor de meeste organisaties is een week lang focussen op de juiste configuratie voldoende om te bevestigen dat een platform aan hun behoeften voldoet of om het uit te sluiten voordat het een commitment wordt.

Wat JumpStart zo aantrekkelijk maakt, is niet alleen het aantal systemen online, maar ook de diepgang van de technologie die Supermicro bereid is te onthullen. Populaire keuzes zijn onder andere X14 GPU-servers met Intel Xeon 6- en NVIDIA-accelerators, H14-platforms geoptimaliseerd voor compacte CPU-computing met 5e generatie AMD EPYC, en opslaggerichte systemen die moderne CPU's combineren met alle NVMe-backends. Aan de bovenkant biedt Supermicro al toegang tot HGX B200- en B300-klasse systemen voor AI-training en -inferentie, en gebruikt het JumpStart om vroege, op NDA gebaseerde inzichten te geven in next-generation platforms die nog niet breed beschikbaar zijn. We hebben nog geen enkele andere OEM gezien die zo agressief pre-GA-infrastructuur omzet in een gestructureerde, herhaalbare remote lab-ervaring.

De meeste demo-omgevingen van leveranciers stoppen bij begeleide oplossingslabs of smalle productsandboxes. Deze zijn nuttig om te leren over beheertools en orkestratieworkflows, maar bieden zelden root-toegang tot een top-tier server of de vrijheid om uw eigen stack te installeren en te gebruiken. JumpStart gedraagt ​​zich veel meer als een leenrack in een extern datacenter. Wanneer u een specifiek systeem boekt, krijgt u volledige controle via SSH, VNC en IPMI gedurende de reservering, en Supermicro wist en herbouwt de omgeving voordat de volgende klant deze gebruikt. In de praktijk voelt dat minder als een marketingdemo en meer als een korte, gerichte betrokkenheid bij een goed gerund extern lab.

Voor deze analyse heeft Supermicro StorageReview toegang gegeven tot JumpStart, precies zoals een klant dat zou ervaren. We hebben tijd ingepland op een X14 10U GPU-systeem Gevuld met een NVIDIA HGX B200 8-GPU baseboard en twee 6e generatie Intel Xeon Platinum 6960P processors. De server was geconfigureerd met 3 TB DDR5-6400 ECC-geheugen, een mix van M.2 en U.2 NVMe SSD's voor lokale opslag en acht B200 GPU's, elk met 180 GB HBM3e. Gedurende een week gebruikten we dat platform om AI-workloads en systeemgedrag steekproefsgewijs te controleren, waarbij we ons concentreerden op het soort vragen dat daadwerkelijke kopers beantwoord willen hebben voordat ze zich committeren aan een nieuwe generatie infrastructuur.

Onze week in het Supermicro JumpStart-programma

Zodra ons reserveringsvenster openging, werd de JumpStart-portal de centrale hub voor onze tests. Het initiële dashboard, hieronder weergegeven, gaf de reserveringstijdlijn weer en bood alles wat nodig was om aan de slag te gaan, inclusief SSH-referenties voor de externe Ubuntu-omgeving en volledige IPMI-toegang. Doordat beide interfaces direct beschikbaar waren, konden we binnen enkele minuten beginnen met de validatie van het systeem, in plaats van te wachten op provisioning of ondersteuning.

De eerste stap in onze workflow was het bevestigen dat de hardware gereed was. Met behulp van de pagina Systeemoverzicht in de portal (zie onderstaande schermafbeelding) controleerden we of de behuizing was ingeschakeld, beide CPU's waren gedetecteerd, het geheugen volledig was gevuld en de BMC een groene systeemstatus rapporteerde. Deze snelle controle is standaard geworden in onze labevaluaties, en de mogelijkheid om dit proces op afstand via de portal te bekijken, stroomlijnde dit proces.

Nadat het systeem gevalideerd was, gingen we over op hands-on werk. Bestandsuploads voor testassets werden rechtstreeks via de JumpStart-interface afgehandeld, waardoor de gebruikelijke problemen met het stagingen van datasets op een extern platform werden opgelost. Van daaruit maakten we via SSH verbinding voor de implementatie van workloads en gebruikten we de externe console via IPMI wanneer we toegang op laag niveau nodig hadden of het opstartgedrag wilden observeren.

De workflow gedurende de week leek erg op het bedienen van apparatuur in ons eigen lab. We konden workloads snel starten, stoppen en itereren, het platform indien nodig opnieuw opstarten en het hardwaregedrag monitoren zonder de ondersteuning van Supermicro in te schakelen. De combinatie van toegang op besturingssysteemniveau en volledige out-of-band controle maakte de omgeving voorspelbaar en efficiënt voor korte testcycli.

Aan het einde van de reservering werd het systeem automatisch hersteld en gereset, waardoor de opdracht netjes werd afgesloten. Deze voorspelbare structuur stelde ons in staat om ons te concentreren op testen in plaats van op logistiek, en zorgde ervoor dat we het beperkte toegangsvenster optimaal benutten.

GPUDirect-opslagprestaties

Een van de tests die we op het Supermicro X14-platform hebben uitgevoerd, was de Magnum IO GPUDirect Storage (GDS)-test. GDS is een door NVIDIA ontwikkelde functie waarmee GPU's de CPU kunnen omzeilen bij het benaderen van gegevens die zijn opgeslagen op NVMe-schijven of andere snelle opslagapparaten. In plaats van gegevens via de CPU en het systeemgeheugen te routeren, maakt GDS directe communicatie tussen de GPU en het opslagapparaat mogelijk, wat de latentie aanzienlijk vermindert en de gegevensdoorvoer verbetert.

Hoe GPUDirect-opslag werkt

Traditioneel, wanneer een GPU gegevens verwerkt die zijn opgeslagen op een NVMe-schijf, moeten de gegevens eerst door de CPU en het systeemgeheugen reizen voordat ze de GPU bereiken. Dit proces creëert knelpunten, omdat de CPU een tussenpersoon wordt, wat latentie verhoogt en waardevolle systeembronnen verbruikt. GPUDirect Storage elimineert deze inefficiëntie door de GPU in staat te stellen gegevens rechtstreeks vanaf het opslagapparaat te benaderen via de PCIe-bus. Dit directe pad vermindert de overhead van gegevensverplaatsing, wat zorgt voor snellere en efficiëntere gegevensoverdracht.

AI-workloads, met name die met deep learning, zijn zeer data-intensief. Het trainen van grote neurale netwerken vereist de verwerking van terabytes aan data, en elke vertraging in de dataoverdracht kan leiden tot onderbenutting van GPU's en langere trainingstijden. GPUDirect Storage pakt deze uitdaging aan door ervoor te zorgen dat data zo snel mogelijk naar de GPU wordt verzonden, waardoor inactieve tijd wordt geminimaliseerd en de rekenefficiëntie wordt gemaximaliseerd.

Bovendien is GDS met name gunstig voor workloads die het streamen van grote datasets omvatten, zoals videoverwerking, natuurlijke taalverwerking of realtime-inferentie. Door de afhankelijkheid van de CPU te verminderen, versnelt GDS de databeweging en maakt CPU-bronnen vrij voor andere taken, wat de algehele systeemprestaties verder verbetert.

Naast de ruwe bandbreedte levert GPUDirect met NVMe-oF (TCP/RDMA) ook I/O met extreem lage latentie. Dit zorgt ervoor dat GPU's nooit een datatekort hebben, waardoor het systeem ideaal is voor realtime AI-inferencing, analysepijplijnen en videoherhaling.

GDSIO-sequentiële leesdoorvoer

Voor onze sequentiële GDSIO-leestest op het B200-platform begon de workload bescheiden met een enkele thread die een snelheid van ongeveer 14 tot 15 GiB/s haalde, afhankelijk van de blokgrootte. Zodra we zowel het aantal threads als de blokgrootte verhoogden, verbeterden de prestaties snel. De overstap naar 2 en 4 threads verhoogde de doorvoer naar het bereik van 20 tot 36 GiB/s, wat aantoont hoe goed het systeem schaalbaar is zodra parallellisme wordt geïntroduceerd.

De echte versnelling vond plaats toen we acht of meer threads bereikten, waarna de meeste workloads zich stabiliseerden rond de hoge 30 GiB/s. Grotere blokken profiteerden het meest, waarbij blokken van 5M en 10M consistent hoge waarden leverden over alle threadaantallen.

De maximale doorvoersnelheid lag uiteindelijk op ongeveer 43 GiB/s met een blokgrootte van 10 M bij 256 threads. Dit was de hoogste aanhoudende sequentiële leessnelheid die we in deze test hebben waargenomen.

GDSIO-sequentiële leeslatentie

Wat de latentie betreft, begon de workload zeer responsief, met single-thread reads die binnen het bereik van 0.06-0.1 ms voor kleinere blokken vielen. Naarmate het aantal threads toenam, nam de latentie geleidelijk toe en bleef onder de 1 ms tot het punt van 8 threads voor de meeste workloads.

Zodra we de grens van 16 threads overschreden, begonnen grotere blokgroottes op te lopen tot in de milliseconden, naarmate het opslagpad meer verzadigd raakte. De hoogste latentie trad op aan het einde van de test, toen een blokgrootte van 10 MB met 256 threads piekte op iets meer dan 1.2 seconde (ongeveer 1200 ms), wat een ongunstige belasting weerspiegelde die ontworpen was om het systeem te overbelasten.

GDSIO-schrijfsequentiële doorvoer

Bij sequentiële schrijfbewerkingen waren de prestaties veel vlakker dan bij leesbewerkingen. De werklast stabiliseerde zich snel, met de meeste combinaties van thread- en blokgroottes rond de 6.3–6.5 GiB/s. Dit wijst erop dat het schrijfpad al vroeg een consistent plafond bereikt, waarschijnlijk gekoppeld aan opslagmedia en buffering in plaats van GPU- of PCIe-limieten.

Het opschalen van het aantal threads had geen significante impact, aangezien de doorvoer vrijwel ongewijzigd bleef van 2 naar 128 threads. Het enige opvallende resultaat kwam aan het einde, waar een blokgrootte van 10M bij 256 threads piekte tot 18.2 GiB/s. Dit leverde een kortstondig voordeel op wanneer het systeem diepe wachtrijen en schrijfaggregatie volledig kon benutten.

GDSIO-schrijfsequentiële latentie

De schrijflatentie begon relatief laag, met single-thread workloads die rond de 0.15-0.5 ms lagen bij kleinere blokgroottes. Naarmate het aantal threads toenam, nam de latentie veel agressiever toe dan aan de leeskant, met een bereik van 1-4 ms bij vier threads en 4-9 ms bij acht threads.

Zodra we 32 threads met grotere blokgroottes bereikten, nam de latentie sterk toe, waarbij blokken van 5M en 10M sprongen naar het bereik van 170-350 ms. Het meest extreme geval was de blokgrootte van 10M bij 256 threads, die piekte op iets minder dan 3 seconden (ongeveer 2900 ms), wat duidelijk aantoont hoe snel het schrijfpad verzadigd raakt onder zware parallelle belasting.

GDSIO willekeurige leesdoorvoer

Voor willekeurige leesbewerkingen liep de werklast snel op. De single-thread prestaties varieerden van ongeveer 11 tot 31 GiB/s, afhankelijk van de blokgrootte, waarbij grotere blokken direct profiteerden van een hogere bandbreedte. Zodra we overschakelden naar twee en vier threads, steeg de doorvoer naar 20 tot 36 GiB/s, wat al snel een sterke schaalbaarheid liet zien.

Vanaf 8 threads stabiliseerde het systeem zich op een stabiel plateau rond de 30 GiB/s, vergelijkbaar met wat we zagen in de sequentiële leestest. Het hoogste resultaat werd behaald met een blokgrootte van 10 MB en 256 threads, met een piek van ongeveer 42.7 GiB/s.

GDSIO willekeurige leeslatentie

De latentie bij willekeurig lezen begon erg laag, met single-thread workloads die rond de 0.15-0.4 ms lagen bij kleinere blokgroottes. Naarmate het aantal threads toenam, nam de latentie geleidelijk toe, tot onder de 1 ms bij het punt van 4 threads en ongeveer 1-3 ms bij acht threads.

Zodra we overschakelden naar 32 threads en grotere blokken, nam de latentie scherper toe, met 5M en 10M overdrachten die opliepen tot tussen de 30 en 55ms. Het meest extreme geval deed zich voor bij 256 threads met een blokgrootte van 10M, waar de latentie piekte op iets meer dan 1.1 seconde (ongeveer 1180ms).

 

GDSIO willekeurige schrijfsnelheid

De willekeurige schrijfprestaties waren over de hele linie zeer consistent, met de meeste blokgroottes en threadaantallen rond de 5.8–6.1 GiB/s. De werklast bereikte dit niveau vrijwel direct en vertoonde minimale schaalvergroting naarmate er meer threads werden toegevoegd, wat aangeeft dat het schrijfpad al snel zijn limiet bereikt.

De enige noemenswaardige uitschieter ontstond aan het einde van de test, toen een blokgrootte van 10M bij 256 threads kortstondig piekte naar 12.5 GiB/s. Dit kwam waarschijnlijk door de grote wachtrijen en schrijfaggregatie bij zware parallelle belasting.

GDSIO willekeurige schrijflatentie

De latentie bij willekeurig schrijven begon relatief laag, met single-thread prestaties variërend van ongeveer 0.6 tot 1.2 ms voor kleinere blokgroottes en 5 tot 12 ms voor de grootste overdrachten. Naarmate de gelijktijdigheid toenam, nam de latentie snel toe en bereikte 4 tot 9 ms bij acht threads en 18 tot 38 ms bij 32 threads.

Vanaf dat punt raakte het schrijfpad verzadigd. Grotere blokgroottes sprongen naar het bereik van 150-380 ms bij 64 threads, en doorlopende schaalvergroting verhoogde de latentie aanzienlijk. Het slechtste geval was de blokgrootte van 10 Mb bij 256 threads, met een maximum van ongeveer 4.4 seconden.

vLLM Online Serving – LLM Inferentie Prestaties

vLLM is de populairste high-throughput inferentie- en serverengine voor LLM's. De vLLM online serverbenchmark is een prestatie-evaluatietool die de real-world servercapaciteiten van deze inferentie-engine meet bij gelijktijdige aanvragen. De benchmark simuleert productieworkloads door aanvragen te versturen naar een actieve vLLM-server met configureerbare parameters, zoals de aanvraagsnelheid, invoer-/uitvoerlengtes en het aantal gelijktijdige clients. De benchmark meet belangrijke statistieken, waaronder doorvoer (tokens per seconde), tijd tot eerste token en tijd per uitvoertoken (TPOT), waardoor gebruikers beter begrijpen hoe vLLM presteert onder verschillende belastingsomstandigheden.

We hebben de inferentieprestaties getest in een uitgebreid pakket aan modellen die verschillende architecturen, parameterschalen en kwantificeringsstrategieën omvatten om de doorvoer onder verschillende gelijktijdigheidsprofielen te evalueren.

Dichte modelprestaties

Dichte modellen volgen de conventionele LLM-architectuur, waarbij alle parameters en activeringen tijdens de inferentie worden geactiveerd, wat resulteert in een rekenintensievere verwerking dan hun spaarzame tegenhangers. Om de prestatiekenmerken op verschillende modelschalen en kwantiseringsstrategieën uitgebreid te evalueren, hebben we meerdere dichte modelconfiguraties uit de Llama 3.1 8B-familie gebenchmarkt.

Onze testsuite omvatte Meta Llama 3.1 8B-evaluaties in drie precisieformaten: de standaardconfiguratie, plus gekwantiseerde FP8- en FP4-versies die gebruikmaken van NVIDIA's NVFP4-formaat. Het is belangrijk om te weten dat vLLM momenteel de Marlin-kernel gebruikt voor gekwantiseerde NVFP4-modellen, en dat de volledige prestatievoordelen van dit kwantificeringsformaat nog niet worden gerealiseerd in deze benchmarks. Toekomstige vLLM-optimalisaties gericht op native NVFP4-tensorkernbewerkingen kunnen leiden tot extra prestatieverbeteringen. Deze modelselectiestrategie maakt directe prestatievergelijking mogelijk, terwijl de impact van progressieve kwantificering op de inferentiedoorvoer wordt geïsoleerd.

Llama 3.1 8B Prestaties

De Llama 3.1 8B vertoont bij standaardprecisie de volgende schaalkarakteristieken over gelijktijdigheidsniveaus. Bij gelijktijdigheid voor één gebruiker (BS=1) levert het model 279.27 tok/s per gebruiker, met een totale doorvoer van 1,727.62 tok/s en een TPOT van 3.37 ms. Naarmate de batchgrootte toeneemt, neemt de doorvoer per gebruiker af, terwijl de totale doorvoer toeneemt. Bij BS=8 bereikt het model 82.85 tok/s per gebruiker met een totale doorvoer van 3,386.48 tok/s en een TPOT van 3.28 ms. De prestaties blijven schalen tot BS=32 (56.46 tok/s per gebruiker, 8,274.66 tok/s totaal) en BS=64 (52.70 tok/s per gebruiker, 13,707.66 tok/s totaal).

Het model bereikt zijn maximale totale doorvoersnelheid bij BS=256, met een snelheid van 32,797.67 tok/s, met 30.64 tok/s per gebruiker en een TPOT van 16.13 ms. Dit vertegenwoordigt een 19x hogere totale doorvoersnelheid in vergelijking met de prestaties van één gebruiker. De TPOT-waarden blijven binnen het bereik van 3-4 ms tot BS=64, en stijgen tot 16.13 ms bij BS=256.

Llama 3.1 8B FP8-prestaties

De gekwantiseerde FP8-variant vertoont verschillende kenmerken. Bij BS=1 behaalt deze een snelheid van 149.46 tok/s per gebruiker, met een totale doorvoer van 9,565.20 tok/s en een TPOT van 3.44 ms. De Pareto-grensanalyse laat drie optimale punten zien (BS=1, BS=128, BS=256).

Bij BS=128 levert het model 44.12 tok/s per gebruiker met 19,198.40 tok/s totaal en 11.04 ms 

TPOT. De maximale totale doorvoer vindt plaats bij BS=256 met een totale doorvoersnelheid van 29,219.67 tok/s, 30.13 tok/s per gebruiker en een TPOT van 13.26 ms. De FP8-variant behaalt een lagere maximale totale doorvoersnelheid in vergelijking met de standaardprecisie (29.2K versus 32.8K tok/s).

Llama 3.1 8B FP4-prestaties

De gekwantiseerde FP4-configuratie laat de volgende resultaten zien: bij gelijktijdige verwerking door één gebruiker (BS=1) worden 279.73 tok/s per gebruiker, een totale doorvoer van 830.46 tok/s en een TPOT van 3.43 ms behaald.

Het FP4-model toont zeven Pareto-grenspunten. Bij BS=2 levert het 159.95 tok/s per gebruiker, 928.60 tok/s in totaal en 3.43 ms TPOT. De prestaties blijven toenemen tot BS=4 (76.36 tok/s per gebruiker, 1,631.69 tok/s in totaal) en BS=32 (76.09 tok/s per gebruiker, 9,014.29 tok/s in totaal). Het model bereikt de maximale totale doorvoer bij BS=256 met 29,340.89 tok/s in totaal, 30.13 tok/s per gebruiker en 16.18 ms TPOT.

Sparse Model Prestaties

Sparse modellen, met name Mixture of Experts (MoE)-architecturen, zijn een opkomende aanpak voor het efficiënt schalen van taalmodellen. Deze architecturen behouden een hoog totaal aantal parameters terwijl ze slechts een subset parameters per token activeren, wat potentieel betere prestaties per actieve parameter biedt.

We hebben twee MoE-architecturen geëvalueerd: DeepSeek-R1, een model gericht op redeneren, en Qwen3 Coder 30B-A3B, een sparse architectuur die gespecialiseerd is in codegeneratie. DeepSeek-R1 is het populairste model gericht op redeneren en vertoont onderscheidende prestatiekenmerken vergeleken met traditionele taalmodellen. Het Qwen3 Coder-model handhaaft een volledige grootte van 30B parameters en activeert slechts 3B parameters per gegenereerd token. We hebben de Qwen3 Coder gebenchmarkt in zowel standaard- als FP8-gekwantiseerde varianten om de prestatiekenmerken van verschillende kwantiseringsstrategieën te begrijpen.

DeepSeek-R1-prestaties

Het DeepSeek-R1-model vertoont interessant schaalgedrag over batchgroottes heen. Bij gelijktijdige verwerking door één gebruiker (BS=1) behaalt het model 30.24 tok/s per gebruiker, een totale doorvoer van 88.13 tok/s en een TPOT van 29.85 ms. Bij schaling naar BS=4 bereikt de prestatie 29.77 tok/s per gebruiker, met een totale doorvoer van 266.40 tok/s bij een TPOT van 32.04 ms. Dit is de maximale totale doorvoer die over alle configuraties is bereikt.

De prestaties van DeepSeek-R1 bereiken een plateau boven BS=4. Bij BS=8 daalt de doorvoer per gebruiker scherp tot 14.98 tok/s, en de daling zet zich voort bij hogere batchgroottes, tot slechts 0.46 tok/s per gebruiker bij BS=256. De totale doorvoer blijft relatief stabiel tussen 200 en 260 tok/s tussen BS=4 en BS=256, omdat het model niet kan schalen met extra gelijktijdige verzoeken op één node, wat leidt tot een verhoogde latentie zonder noemenswaardige doorvoerwinst. Belangrijk om te weten is dat de B200 DGX een van de weinige single-serveroplossingen is die dit enorme model kan draaien.

Qwen3 Coder 30B-A3B-prestaties

De Qwen3 Coder met standaardprecisie toont de volgende schaalverdeling over gelijktijdigheidsniveaus. Bij gelijktijdigheid voor één gebruiker (BS=1) behaalt het model 178.30 tok/s per gebruiker, een totale doorvoer van 527.25 tok/s en een TPOT van 5.46 ms. Bij BS=2 bereikt de prestatie 174.56 tok/s per gebruiker met een totale doorvoer van 718.70 tok/s en een TPOT van 5.60 ms. Naarmate de batchgrootte toeneemt, neemt de doorvoer per gebruiker af, terwijl de totale doorvoer blijft schalen: BS=16 levert 127.76 tok/s per gebruiker, een totale doorvoer van 4,204.40 tok/s en een TPOT van 6.93 ms.

Het model bereikt zijn maximale totale doorvoersnelheid bij BS=256, met een totaal van 22,305.88 tok/s, met 46.16 tok/s per gebruiker en een TPOT van 17.64 ms. De Pareto-grens omvat acht verschillende punten, met een dubbele waarde bij BS=32 (72.97 tok/s en 93.50 tok/s per gebruiker, wat waarschijnlijk verschillende configuraties vertegenwoordigt). De TPOT-waarden blijven binnen het bereik van 5-9 ms tot BS=64.

Qwen3 Coder 30B-A3B FP8-prestaties

De gekwantiseerde FP8-variant vertoont de volgende prestatiekenmerken. Bij gelijktijdige verwerking door één gebruiker (BS=1) levert het model 107.46 tok/s per gebruiker, een totale doorvoer van 317.75 tok/s en een TPOT van 9.16 ms. Bij BS=2 behaalt het model 99.55 tok/s per gebruiker met een totale doorvoer van 409.87 tok/s en een TPOT van 9.86 ms.

Schaalvergroting naar hogere batchgroottes: BS=8 levert 54.60 tok/s per gebruiker met een totaal van 1,383.13 tok/s en een TPOT van 10.24 ms, terwijl BS=32 48.78 tok/s per gebruiker bereikt met een totaal van 3,874.21 tok/s en een TPOT van 10.67 ms. De maximale totale doorvoer vindt plaats bij BS=256 met een totaal van 19,114.86 tok/s, 36.38 tok/s per gebruiker en een TPOT van 20.00 ms. Dit komt overeen met ongeveer 86% van de maximale doorvoer met standaardprecisie.

Microschaling Datatype Prestaties

Microscaling is een geavanceerde kwantiseringsmethode die fijnmazige schaalfactoren toepast op kleine blokken gewichten in plaats van uniforme kwantisering over grote parametergroepen. NVIDIA's NVFP4-formaat implementeert deze techniek via een geblokkeerde floating-point representatie, waarbij elk microschaalblok van 8-32 waarden een gemeenschappelijke exponent als schaalfactor deelt. Deze gedetailleerde aanpak behoudt de numerieke precisie en bereikt tegelijkertijd een 4-bits representatie, waardoor het dynamische bereik dat cruciaal is voor transformatorarchitecturen behouden blijft. Het formaat integreert met NVIDIA's Tensor Core-architectuur, wat efficiënte berekeningen met gemengde precisie mogelijk maakt met on-the-fly decompressie tijdens matrixbewerkingen.

We hebben de GPT OSS-modellen van OpenAI geëvalueerd op twee parameterschalen met behulp van NVFP4-kwantisering: de 20B-variant en de grotere 120B-variant. Deze benchmarks laten zien hoe microschalingskwantisering presteert bij verschillende modelgroottes.

GPT-OSS-20B-prestaties

Het 20B-parametermodel behaalt de volgende prestaties over batchgroottes. Bij gelijktijdige verwerking door één gebruiker (BS=1) levert het 299.28 tok/s per gebruiker, een totale doorvoer van 943.43 tok/s en een TPOT van 3.23 ms. Bij BS=2 handhaaft het model 299.19 tok/s per gebruiker met een totale doorvoer van 1,356.87 tok/s en een TPOT van 3.19 ms.

Schaalvergroting naar hogere batchgroottes: BS=8 behaalt 259.02 tok/s per gebruiker met een totaal van 5,149.59 tok/s en een TPOT van 3.42 ms, terwijl BS=16 200.69 tok/s per gebruiker behaalt met een totaal van 7,765.73 tok/s en een TPOT van 3.77 ms. Het model blijft schalen tot BS=32 (168.34 tok/s per gebruiker, 12,411.72 tok/s totaal) en BS=64 (123.96 tok/s per gebruiker, 16,931.47 tok/s totaal).

De totale doorvoer vindt plaats bij BS=256, met een totaal van 38,258.50 tok/s, met 65.08 tok/s per gebruiker en een TPOT van 9.39 ms. Dit vertegenwoordigt een toename van 40.5x in de totale doorvoer vergeleken met de prestaties van één gebruiker. De TPOT-waarden blijven binnen het bereik van 3-5 ms tot BS=32. De Pareto-grens omvat acht verschillende punten.

GPT-OSS-120B-prestaties

Het grotere 120B-parametermodel behoudt de volgende prestaties ondanks het verhoogde aantal parameters. Bij gelijktijdige verwerking door één gebruiker (BS=1) behaalt het model 248.62 tok/s per gebruiker, een totale doorvoer van 783.73 tok/s en een TPOT van 3.89 ms. Bij BS=2 levert het model 240.99 tok/s per gebruiker, een totale doorvoer van 1,092.91 tok/s en een TPOT van 3.99 ms.

De prestaties blijven toenemen bij hogere batchgroottes: BS=4 behaalt 190.63 tok/s per gebruiker met een totaal van 2,096.73 tok/s en een TPOT van 4.22 ms, terwijl BS=8 172.66 tok/s per gebruiker behaalt met een totaal van 3,692.10 tok/s en een TPOT van 4.54 ms. Schaalvergroting via BS=16 (138.28 tok/s per gebruiker, 5,751.41 tok/s totaal), BS=32 (111.63 tok/s per gebruiker, 8,646.05 tok/s totaal) en BS=64 (88.64 tok/s per gebruiker, 13,027.97 tok/s totaal) laat een consistente uitbreiding van de doorvoer zien.

Het model bereikt zijn maximale totale doorvoer bij BS=256, met een snelheid van 29,976.99 tok/s, met 48.64 tok/s per gebruiker en een TPOT van 12.53 ms. Dit vertegenwoordigt een toename van 38.2x in de totale doorvoer vergeleken met de prestaties van één gebruiker. De maximale totale doorvoer bedraagt ​​ongeveer 78% van de piek van het 20B-model. De Pareto-grens omvat negen afzonderlijke punten, het hoogste aantal van alle geteste modellen.

Onverwachte gekwantiseerde modelprestaties

De resultaten van het gekwantiseerde model waren onverwacht en rechtvaardigen nader onderzoek. In verschillende gevallen behaalden de gekwantiseerde NVFP4- en FP8-versies van de modellen niet de verwachte prestatieverbeteringen ten opzichte van hun tegenhangers met native precisie. Zo behaalde het Llama 3.1 8B FP4-model slechts een totale doorvoersnelheid van 830.46 tok/s bij BS=1, vergeleken met 1,727.62 tok/s voor de variant met standaardprecisie, ondanks een vergelijkbare doorvoersnelheid per gebruiker. Bij hogere batchgroottes benaderden de gekwantiseerde modellen weliswaar de doorvoersnelheid met standaardprecisie (29.2K-29.3K tok/s versus 32.8K tok/s bij BS=256), maar de algehele resultaten suggereren dat de huidige implementatie van vLLM mogelijk niet volledig geoptimaliseerd is voor Blackwell.

We zijn van plan om aanvullende tests uit te voeren op vLLM en deze ook te vergelijken met TensorRT-LLM om te zien welke prestaties eindgebruikers vandaag de dag kunnen verwachten.

Supermicro JumpStart verandert het AI PoC-spel

Het JumpStart-programma van Supermicro levert wat het belooft: daadwerkelijke, onbeperkte toegang tot productiehardware zonder de logistiek, verzendvertragingen of laboratoriumoverhead van een traditionele PoC. Onze JumpStart-week op het X14 HGX B200-platform ging vlot van start, verliep soepel en stelde ons in staat de prestaties te evalueren zoals we dat zouden doen met apparatuur in onze eigen racks.

Voor organisaties die snel beslissingen nemen over AI-infrastructuur, kan dit soort platformtoegang wekenlange planning in dagen samenvatten. Als het doel is om GPU-doorvoer, opslaggedrag, modelprestaties of simpelweg de stackcompatibiliteit te valideren, geeft JumpStart u antwoorden met minimale frictie. Het is een vertrouwenwekkende aanpak voor hardware-evaluatie en we zouden graag zien dat meer leveranciers deze aanpak omarmen.