Nvidia presenteert Blackwell-AI-gpu met 208 miljard transistors

Op Nvidia’s GPU Technology Conference heeft de fabrikant zijn Blackwell-gpu aangekondigd. Ceo Jensen Huang presenteerde tijdens zijn keynote de op AI-gerichte B200-chip en de gecombineerde GB200 ‘superchip’. Productie en levering van deze chip moet later dit jaar op gang gaan komen.

De B200-chip telt 208 miljard transistors en bestaat uit twee gpu-chiplets (B100) die verbonden zijn met wat Nvidia zijn High Bandwidth Interface (NV-HBI) noemt. De voorgangers GA100 en GH100 waren nog opgebouwd uit een enkele, grote processordie. Bij Blackwell kiest Nvidia nu dus voor een multichipmodule, maar de B100-gpu’s zijn met een oppervlakte van naar schatting meer dan 800mm² ongeveer even groot als wat het bedrijf voorheen in dit segment uitbracht. Er wordt dus flink meer chipoppervlakte gebruikt om de rekenkracht te vergroten. Nvidia zal voor Blackwell gebruik blijven maken van TSMC’s 5nm-proces, zij het op een sterk verfijnde versie van deze node, genaamd N4P.

De twee gpu-chiplets op B200 zijn elk voorzien van vier geheugencontrollers, met op elk 24GB HBM3e-geheugen dat met een 1024bit-geheugenbus is verbonden. Elke gpu-chiplet beschikt daarmee over een 4096bit-geheugenbus met daar in totaal 96GB werkgeheugen aan gekoppeld. Op B200 komt het totaal dan uit op 8192bit en 192GB, wat onder de streep een geheugenbandbreedte van 8TB/s betekent. Dankzij NV-HBI functioneren de twee chiplets als één gpu, en kan software ze ook als zodanig benaderen. Het is momenteel nog onduidelijk welke technologie Nvidia heeft gekozen voor het packagingproces, net als het aantal rekenkernen dat op de chip beschikbaar is.

De Blackwell-architectuur voegt hardwarematige ondersteuning voor een lagere precisie van zwevendekommagetallen toe, namelijk FP4 en FP6. De FP4-ondersteuning kan voor kunstmatige intelligentie nuttig zijn wanneer een hogere snelheid sterk verkozen wordt boven precisie. Met FP6 wordt ook nog een middenweg mogelijk wanneer FP4 niet nauwkeurig genoeg is, maar wanneer FP8 dan weer niet nodig is. Omdat de Ampere- en Hopper-chips voor deze lagere precisie geen hardwarematige ondersteuning bieden, valt er geen directe vergelijking wat rekenkracht betreft te maken. Op FP8 levert B200 tweeënhalf keer de snelheid van de H100-chip. Om automatisch de juiste precisie voor rekenmodellen toe te passen en zo prestaties te optimaliseren, heeft Nvidia een nieuwe generatie Transformer Engine ontworpen voor de Blackwell-architectuur.

Op de Grace Blackwell 200 (GB200) combineert Nvidia twee B200’s met een Grace-cpu tot wat de fabrikant zelf een ‘superchip’ noemt. De op Arm gebaseerde Grace-cpu op de GB200 telt 72 cores en het geheel krijgt een maximum tdp van 2700W. De GB200 Superchips kunnen in grotere aantallen gecombineerd worden om de rekenkracht voor AI-gerelateerde toepassingen te vergroten en te versnellen.

Bedrijven zoals Amazon, Dell, Google, Meta, Microsoft, OpenAI, Oracle, Tesla en xAI hebben interesse getoond in de Blackwell-gpu. Nvidia's jaaromzet verdubbelde in 2023 door de sterk toegenomen vraag naar AI-toepassingen. Voor de consumentenmarkt betekent de aankondiging vooralsnog weinig, maar volgens geruchten brengt Nvidia zijn GeForce RTX 50-serie videokaarten voor gamers later in 2024 ook uit.

	Blackwell B200	Hopper H100
Architectuur	Blackwell	Hopper
Gpu Diesize	"Blackwell GPU" 2x +800mm²	GH100 814mm²
Transistors	208 (2x 104) miljard	80 miljard
Productieprocedé	TSMC N4P (5nm)	TSMC 4N (5nm)
Rekenkernen	onbekend	16896
FP4 FP8 FP16 FP64	9 pflops 4500 tflops 2250 tflops 40 tflops	n.v.t. 1980 tflops 990 tflops 67 tflops
Geheugenopstelling	192GB HBM3e 2x 4096bit	80GB HBM3 5120bit
Geheugenbandbreedte	8TB/s	3,35TB/s
Tdp	1000W	700W

Reacties (63)

[quizzical]

Ik vraag me af wanneer het voor de gewone prosumer mogelijk zal zijn om een lichtere variant van zo een ding aan te schaffen voor <1000€ om daar dan Home Assistant en een LLM enz op te draaien om je huis lokaal te besturen met behulp van AI.

[MSalters]

Het probleem met dat idee is dat je home automation zo'n 99.9% van de tijd niets te doen heeft. De zinnige optie daar is om het in de cloud te draaien, tegen 0.1% van de kosten.

[Exirion]

Besturing en beveiliging van je huis is bij uitstek iets waarvoor je niet 100% afhankelijk van een cloud service en internetverbinding wil zijn.

[ViPER_DMRT]

Sure, maar mits je via AI Models al je 3 Peta aan 720p 'Media' naar 4k wil laten up-scalen op je rack vol infiniflash nodes, zijn er ook voor je local managed k8s cluster zeker wel goedkopere oplossingen te verzinnen. Maar dat het een bijzonder hoog LVT (Leuk voor thuis) gehalte heeft. For sure !

Je zal ene goeie PowerPoint moeten hebben als je getrouwd bent, I know that much.

[Reactie gewijzigd door ViPER_DMRT op 22 juli 2024 13:57]

[biert1982]

Zijn hiervoor niet hybride vormen bedacht dat het geen noodzaak is om cloud contact te hebben voor bediening, maar enkel de berekeningen in de cloud worden gedaan met geanonimiseerde gegevens van lokale devices?

[n4m3l355]

Nu echter je ziet dat AI steeds toegankelijker wordt voor de thuis gebruiker. Zij het door betere modellen, beperktere modellen, betere hardware enz. En natuurlijk AI staat niet stil maar is het onwaarschijnlijk dat op korte termijn we een LLM fatsoenlijk zelf kunnen draaien? Nvidia heeft nu al voor je 30x een package beschikbaar gemaakt voor de enthousiastelingen onder ons.

[MSalters]

Een modern LLM heeft circa 50 4090s nodig. Nee, dat draait niet lokaal. Die "Large" in LLM is niet overdreven.

[svane]

Als je met modern, 'groot' bedoelt, dan heb je gelijk. ChatGPT 4 draai je niet zo maar lokaal nee.

Er zijn echter ook kleinere 'moderne' modellen. Zoals Gemma wat vorige maand online gezet werd. Dit draait gewoon prima lokaal:

And Gemma models are capable of running directly on a developer laptop or desktop computer.

Ik heb nog niet me Gemma gespeeld, maar LLaMA 2, ook een LLM, draait meer dan prima op mijn laptop.

Het aansturen van wat apparaten in huis, waar @quizzical het over heeft, zou nu al geen enkel probleem moeten zijn. Laat staan in de (nabije) toekomst.

[Reactie gewijzigd door svane op 22 juli 2024 13:57]

[hub0]

Quantized versies van Mixtral8x7b en Llama2-70b draaien goed op een 24 gb videokaart. Dat zijn realistische opties voor prosumers zoals @quizzical ze noemt en de enthousiastelingen die @n4m3l355 bedoelt. Deze modellen vergelijken zich in benchmarks met GPT-3.5. Ze hebben meer dan voldoende capaciteiten voor geavanceerde home automation, op een ander niveau dan 'simpele' edge-modellen zoals Gemma of Llama2-7b/13b.

Dat zijn geen 'state-of-the-art'-modellen van vandaag, waar je 2 ton aan hardware voor nodig hebt als je alleen al inference wil doen, laat staan training. Het zijn het soort modellen waar OpenAI vorig jaar nog 2 ton aan hardware voor nodig had, maar die je nu als prosumer gewoon thuis kan draaien.

Dus ja, @quizzical, het kan thuis prima, nu al. Met edge-modellen die @svane noemt op vrijwel alle hardware die je nu hebt staan, of met quantized modellen op een prosumer videokaart met 16 tot 24 gb vram.

[Reactie gewijzigd door hub0 op 22 juli 2024 13:57]

[k995]

De 4090 is een "lichtere" variant van de H100 dus de 5090 of zo?

[Cergorach]

Een 4060 is een goedkopere variant (<€300) van een 4090. Het issue, ook met een 4090, is hoeveel geheugen er inzit (dat beperkt welke LLM variant je kan draaien) en hoe snel het de AI berekeningen kan doen. RAM heeft impact op wat de LLM kan en snelheid hoe lang het duurt voordat de LLM een antwoord heeft.

Ik denk dat dit meer een issue gaat zijn met wat voor LLM hier specifiek je homeautomation gaat besturen, dan de daadwerkelijke kracht/RAM van de videokaart. Maar waarom zou je in godsnaam je homeautomation willen laten besturen door een LLM!?!? Het lijkt wel alsof een hele generatie is opgegroeid zonder "De Lift"...

[k995]

Een 4090 (buiten het geheugen idd) is wel heel dicht tegen een H100, een 4060 langs geen kanten natuurlijk.

En een 4090 kan perfect aan wat hij zegt, heel dure automatisatie zou ik denken maar het kan. Alhoewel er dan goedkopere online alternateievn zijn vermoed ik.

[A Lurker]

Je bent appels met peren aan het vergelijken.

De H100 heeft (maximaal) 80GB HBM memory tegenover de 24GB GDDR6X van de 4090.

Een H100 is niet zoals vroeger een quadro variant van de commerciële kaart. Sowieso is de H100 een generatie nieuwer dan de 4090.

Je redenatie omtrent 5090, 4060 en LLMs lokaal draaien is dus echt uit de lucht gegrepen. Dat gezegd hebbende kan het met kleinere LLMs nu al, zelfs met een 4060.

[caipirinha]

Dat was een bio chip die begon te muteren, dat gebeurt hier natuurlijk nooit mee
Maar verder heb je gelijk een raspberry met wat slimme code is genoeg AI voor home automation.

[Relaxations]

Kan nu al op een 4070 Ti Super met 16GB.
Die staan nu vanaf € 879,- in pricewatch.
Het gaat er vooral om dat de GPU minimaal 16GB VRAM heeft om de modellen (waaronder LLM's) te kunnen draaien.

[Reactie gewijzigd door Relaxations op 22 juli 2024 13:57]

[goarilla]

Waar ga jij de TB's aan gecureerde data verkrijgen laat staan de tijd ?

[ViPER_DMRT]

AWS S3 / Pipelines

[jimh307]

Wordt dit een AI vraagbaak voor consumenten?

Dit zijn serieus zware chips en AI gaat serieuze vormen aannemen. Echter blijft de vraag of dit ook ingezet kan worden voor 'uiteraard' gaming. Het gaat hier over bizar veel rekenkracht en ik zie het nog gebeuren dat AI systemen overstappen naar 128-bit brede calculaties. Een soort voorloper van quantum processing en uiteraard voor een consumenten systeem.

We kunnen zo bizar veel op computing-gebied dat AI straks je vrouw kan gaan vervangen.

Uiteraard een pracht ontwikkeling, maar gaat Tennet hier blij mee zijn. Laten we eerst de energietransitie oplossen eer we massaal deze chips gaan inzetten.....

[ViPER_DMRT]

NVidia be like ...

TDP 700W FP16 990 tflops
vs
TDP 1000W FP16 2250 tflops

[djwice]

2x9 pflops = 18 peta floating point operaties op 4 bits.

Oftewel elke seconde op 9.000.000.000.000.000 bytes (9 PetaBytes) een floating point bewerking doen.

Uiteraard zullen veel bewerking op twee resultante van een vorige berekening worden gedaan, maar dan nog.

Voor huidige begrippen in consumenten toepassingen: extreem veel; ongeveer 55x de snelheid van een 4090.

[familyman]

Ik vraag me af wat je hierbij voorstelt.

Dit is toch meer voor het maken van nieuwe grotere modellen.

Voor het gebruiken ervan bestaan al goede oplossingen, zoals de coral tpu, die je veel performance geven.

Alleen het finetunen van modellen hou je dan over, maar heb je in het algemeen geen echte monsters voor nodig?

[MR501]

Met een beetje creativiteit kan dit allang op een p40 of rtx 3090 draaien, je moet gewoon weten wat je doet.

[Tourmaline]

Koop een Intel(ASUS) NUC en draai het daar op.

[Jefrey Lijffijt]

Er zijn al zat taalmodellen die je lokaal kunt draaien. Probeer het gerust eerst eens via een desktopapp zoals LMstudio. Bijvoorbeeld llama-2-7B of mistral-7B met quantizatie kun je direct mee spelen. Bovenstaande kaarten zijn meer voor trainen/fine-tunen van modellen, of het draaien van grote modellen als je een veel ingewikkeldere use case hebt dan als home assistant.

[SjardWillems]

Ik denk dat je een LLM misschien nu al op een raspberry pi kan draaien.
Het trainen doe je sowieso niet zelf, je hoeft alleen het model te downloaden en prompts te geven.

En dat is allemaal niet zo zwaar en heb je uberhaubt geen GPU voor nodig.

[uray]

Maar op FP64 is die Winst verdampt... Curious...

[CrazyJoe]

Dit is FP64 op de Tensor Cores, niet FP64 op de normale CUDA cores. Waarschijnlijk hebben ze na feedback uit de AI wereld ontdekt dat FP64 daar "bijna" niet gebruikt wordt en het dus beter is om meer lagere precisie functionaliteit in de Tensor Cores te stoppen.

Je moet de Tensor Cores zien als vrij beperkte supersnelle matrix berekenaars.

Ze doen in principe maar 1 type operatie: D = A * B + C (of C = A * B +C), waarbij A, B, C en D matrices zijn. De grootte van de matrices zijn onderhevig aan een strikte set voorgedefinieerde afmetingen die bepaald worden door de gebruikte types voor A, B & C en D.

Maar aangezien deze operaties op warp niveau plaatsvinden kun je de matrix operatie op tile basis laten uitvoeren (dus door grotere matrices in stukjes te hakken, kun je de resultaten tegelgewijs laten uitrekenen)

Het voordeel van deze beperkte functionaliteit is dat deze operaties aanzienlijk sneller uitgevoerd kunnen worden om dat het de threads in een warp (32) ieder meerdere operaties laat uitvoeren (voor FP16 en aanverwante types zouden dat ongeveer 8 fma operaties moeten zijn per thread)

Natuurlijk moet je probleem natuurlijk wel gestructureerd kunnen worden zodat het met de tensor core operaties (ook wel fragment operations genoemd) uitgevoerd kunnen worden.

Maar als dat kan dan is de performance makkelijk een factor of 10 vergeleken met de normale CUDA cores.

[Sando]

Je moet de Tensor Cores zien als vrij beperkte supersnelle matrix berekenaars.

Ze doen in principe maar 1 type operatie: D = A * B + C (of C = A * B +C), waarbij A, B, C en D matrices zijn.

Kan je op een versimpelde manier ook uitleggen hoe CUDA cores (en CPU cores) daartoe in verhouding staan?

Met Tensor Lite kan ik meerdere objecten moeiteloos detecteren. Mijn Nvidia kaart kan dat ook, maar die krijgt het flink warm. Mijn CPU doet 0,5 frames per seconden. En op een abstracte manier snap ik het ook wel. Ik kan het alleen niet uitleggen.

[Werelds]

Het gaat vooral om de data (en precisie daarvan) waar mee gewerkt wordt, en hoe er mee gewerkt wordt.

Korte versie: de "CUDA cores" zijn volwaardige rekenmachines. Je hebt twee operanden en een operator en je hebt controle over alle 3; de operanden kunnen integers of floating point zijn, 8, 16 of 32 bits en de operator mag van alles zijn. Tensor Cores daarentegen hebben vaste operators en de operanden moeten een specifieke vorm (matrix) hebben, enkel floating point binnen die matrices.

Lange versie:
Een "CUDA Core" (zie onderaan waarom de aanhalingstekens) is een heel simpel ding. Je voert 2 stukjes data in, de ALU voert een berekening daarop uit en klaar. Dat komt neer op A ? B = C, waarbij het vraagteken een simpele rekenoperatie is. Die dingen zitten allemaal gegroepeerd in een SIMD cluster; in Nvidia's geval, per 16 of 32, afhankelijk van workload en architectuur - we houden nu even 16 aan. Dat SIMD slaat er op dat alle 16 ALU's in zo'n cluster dezelfde rekenopdracht uitvoeren, maar met verschillende cijfers; dat wil zeggen dat als je ook maar één optelopdracht uit moet voeren, je meteen zo'n heel cluster kwijt bent, zelfs als het maar om een enkel cijfer gaat. Voor graphics is dit echter ideaal, omdat er heel vaak dezelfde berekening met verschillende cijfers gedaan moet worden.

Tensor Cores doen specifiek D = ( A * B ) + C. De rekenoperaties liggen vast en wat A, B en C zijn ligt ook grotendeels vast; althans, hun vorm.

Het eerste hele grote verschil zit hem in wat die letters allemaal zijn. Voor de SIMD ALU's zijn dat maximaal 32-bits cijfers; dat betekent veel decimalen óf hele grote hele getallen. Minder bits mag ook, dat gaat echter niet per definitie sneller. Omdat die ALU's allerlei verschillende berekeningen moeten kunnen doen, is de fysieke logica (de gates, zoals dat heet) vrij complex.

Voor de TC is dat maximaal 16-bits, half zo groot dus. En omdat er heel specifieke operaties uitgevoerd worden (vermenigvuldigen en daarna optellen), is de fysieke logica dus ook een stuk simpeler. Belangrijker echter is dat de gewone ALU's met enkele cijfers werken, terwijl TC's met matrixes werken. Dat is een wiskundig dingetje, maar het komt er op neer dat A, B en C voor TC's in feite groepen van 16 cijfers zijn (en specifiek floating point), in plaats van enkele cijfers. De manier waarop die groepen vervolgens vermenigvuldigd worden betekent dat er heel veel rekenopdrachten zijn.

Dit is hoe matrix vemenigvuldiging er uit ziet (A * B = C; dit zijn 2x2 matrices, ik moet ze helaas onhandig weergeven omdat de "code" BB tag niet werkt op de FP):

[ 1 2 ] * [ 5 6 ] = [ 19 22 ]
[ 3 4 ] * [ 7 8 ] = [ 43 50 ]

Ik zal matrix vermenigvuldiging niet helemaal uit leggen, maar in dit geval heb je voor elke "positie" in C 2 vermenigvuldigingen en 1 optel operatie nodig. Om dat dus op de SIMD's te doen, heb je minimaal 2 kloktikken nodig (immers 1 opdracht per kloktik; de vermenigvuldigingen zouden in theorie parallel in aparte SIMD's kunnen), in de werkelijkheid zijn het er zelfs meer dan dat omdat data verschoven moet worden en dergelijke. En dat is voor een 2x2 matrix - voor een 4x4 matrix (zoals bij de TC's) heb je per "positie" 4 vermenigvuldigingen en 3 optel operaties, 112 in totaal. Wederom zou je in theorie tegelijkertijd kunnen vermenigvuldigen (in de praktijk ligt dat genuanceerder), maar dan heb je ook 8 SIMD's nodig. In Nvidia's geval betekent dat minstens 2 SM's; een 3090 Ti heeft bijvoorbeeld 84 SM's, dus je ziet dat dat heel snel heel veel van de GPU kost. En wederom, in de praktijk kun je dat niet in 2 kloktikken op 2 SM's doen; je gaat meer SM's en meer kloktikken nodig hebben, maar dat gaat toch echt te ver voor dit al veel te lange verhaal

Een Tensor Core doet dat alles in één kloktik. Dus vandaar dat dat zo veel sneller gaat.

Waarom matrixes voor machine learning ("AI") en niet voor graphics en dergelijke ga ik verder maar niet op in


Als laatste de aanhalingstekens: "CUDA core" is een vrij onzinnige term, omdat het nu iets heel anders betekent dan 10 jaar geleden; en zelfs binnen de huidige ontwerpen is de ene "CUDA core" de andere niet. Zo heeft Nvidia in hun GeForce GPU's "CUDA cores" die enkel floating point doen, maar ze hebben er ook die ook met integers overweg kunnen. En dan heb je ook nog specifiek de FP64 ALU's, die ze óók CUDA core noemen maar nooit meetellen in hun "CUDA core count". Om de 4090 als voorbeeld te nemen: Nvidia zegt dat die 16384 "CUDA cores" heeft. Daarvan is de helft echter FP-only en de helft FP/INT. Met die FP/INT cores is er ook een beperking dat ze dus ook allemaal tegelijk moeten schakelen: dus heb jij één INT vermenigvuldiging, ben je gelijk 15 andere FP/INT cores kwijt.

[Reactie gewijzigd door Werelds op 22 juli 2024 13:57]

[goarilla]

Prachtige uitleg. Veel van geleerd echter:

[ 1 2 ] * [ 5 6 ] = [ 19 22 ]
[ 3 4 ] * [ 7 8 ] = [ 43 50 ]

Het is al lang geleden en ook toen had ik er moeilijkheden mee maar
Je kan toch geen 1 x 2 matrix vermenigvuldigen met een 1 x 2 matrix.
Wanneer je 2 kolommen hebt in de eeste matrix, moet de 2de matrix toch
2 rijen hebben. Wolframalpha geeft aan "incompatible dimensions bij jouw voorbeeld"

https://www.wolframalpha....3E%22%7B%7B1%2C2%7D%7D%22

Terwijl dit: https://www.wolframalpha....3E%22%7B%7B1%2C2%7D%7D%22

Wel een valide resultaat geeft maar helemaal niet in de buurt komt van wat jouw
berekening gaf.

Mvg,

"De muggenzifter"

[Werelds]

Je kan toch geen 1 x 2 matrix vermenigvuldigen met een 1 x 2 matrix.

Hah, nee dat moeten 2 2x2 matrices zijn, maar ik kan dat hier op T.net niet zo netjes weergeven

Dit is wat ik bedoelde: https://www.wolframalpha....%7D%2C+%7B3%2C+4%7D%7D%22

[Rudie_V]

Kan je op een versimpelde manier ook uitleggen hoe CUDA cores (en CPU cores) daartoe in verhouding staan?

Bedoel je dit misschien?
https://blogs.nvidia.com/blog/double-precision-tensor-cores/

With FP64 and other new features, the A100 GPUs based on the NVIDIA Ampere architecture become a flexible platform for simulations, as well as AI inference and training — the entire workflow for modern HPC. That capability will drive developers to migrate simulation codes to the A100.

Users can call new CUDA-X libraries to access FP64 acceleration in the A100. Under the hood, these GPUs are packed with third-generation Tensor Cores that support DMMA, a new mode that accelerates double-precision matrix multiply-accumulate operations.

Accelerating Matrix Math

A single DMMA job uses one computer instruction to replace eight traditional FP64 instructions. As a result, the A100 crunches FP64 math faster than other chips with less work, saving not only time and power but precious memory and I/O bandwidth as well.

We refer to this new capability as Double-Precision Tensor Cores. It delivers the power of Tensor Cores to HPC applications, accelerating matrix math in full FP64 precision.

Beyond simulations, HPC apps called iterative solvers — algorithms with repetitive matrix-math calculations — will benefit from this new capability. These apps include a wide range of jobs in earth science, fluid dynamics, healthcare, material science and nuclear energy as well as oil and gas exploration.

[DvanRaai89]

Dit is FP64 op de Tensor Cores, niet FP64 op de normale CUDA cores.

Kun je mij uitleggen wat je daar mee bedoelt? Voor zo ver ik weet zijn CUDA cores helemaal geen cores, maar eenheden bestaande uit
bijvoorbeeld FP32, FP64, INT32, FP16 of FP8 (of INT8 en INT4 bij Tensor "cores") operaties uit kunnen voeren.

Het enige wat echte rekenkernen zijn, zijn SM's (Simultaneous Multiprocessor), welke bestaan uit eenheden die daadwerkelijk waarden uit het geheugen kunnen lezen (load) hier een berekening mee uitvoeren, en en die waarde weer in het geheugen plaatsen (store). Dan komt er natuurlijk ook gedeeld gehuegen, cache, registers en andere ongein bij kijken, maar je snapt het idee.

Vroegâh (Pre Pascal) verwees "CUDA core" naar FP32-eenheden, en bestond iedere SM bij de Pacal microarchitectuur uit 128 FP32 FPU's en 128 INT32 ALU's, maar moest er per klokcyclus voor een van de twee gekozen worden. Bij Turing werd de mogelijk om tegelijkertijd 64 FP32 en 64 INT32 berekeningen te doen. En tenslotte viel er bij Ampère te kiezen uit 64 FP32 en 64 INT32 of 128 FP32, maar niet allebei.

Voor zover ik weet doen Tensor core helemaal geen double precision berekeningen, alleen FP16 met FP32 output, maar kan er naast zitten.

Ik vermoed dat Nvidia gewoon de hoeveelheid FP64 FPU's per SM gehalveerd heeft, of SM's zijn veel groter geworden, t.o.v. de vorige generatie, waardoor er minder van zijn.

[CrazyJoe]

Je moet het zo zien: Een GPU heeft een aantal SM's, iedere SM heeft een bepaalde hoeveelheid threads die ze parallel kunnen laten processen. Die threads worden gegroepeerd in blocks, welke onder water weer opgedeeld worden in warps. Alle threads in een warp worden samen uitgevoerd en werken optimaal als ze allemaal dezelfde instructie uitvoeren.

Neem een RTX A4000. Die heeft 48 SM's die ieder 128 CUDA cores hebben (NVIDIA noemt ze nog steeds CUDA cores). Dat geeft dus een totaal van 6144 CUDA cores. Iedere SM kan dus 128 threads parallel runnen. Echter de fundamentele unit is een warp en dat zijn 32 threads (ja er wordt tegenwoordig ook met half-warps geschermt, dus 16 threads). Dus een SM kan theoretisch 4 warps parallel laten runnen en iedere warp kan een andere kernel executeren.

In CUDA definieer je hoe een kernel (het stukje code dat uitgevoerd gaat worden in iedere thread) de data die verwerkt wordt gaat processen, door een grid van blokken te definiëren. Belangrijk hier is dat een block maximaal uit 1024 threads mag bestaan. Een grid heeft ook zijn beperkingen, maar die zijn vele male groter. Een block kan 1D, 2D of 3D zijn zolang het aantal threads niet meer is dan 1024 (dus 1x1024 of 32x32 of 16x16x4).. Belangrijk hier is dat een block uit meervouden van warps moet bestaan.

De grootte van het grid is afhankelijk van de data die je wil verwerken.

Laten we zeggen dat je een plaatje van 512x512 pixels wil bewerken en dat je een 2D block van 16x16 threads daarvoor wil gebruiken (256 = 8 warps). Dat betekent dus dat je een grid van 32x32 blokken moet gebruiken (een grid hoeft niet exact even groot te zijn als de data die verwerkt moet worden, je kunt in de kernel zorgen dat threads die buiten de data zouden vallen met een groter grid, niet uitgevoerd worden).

CUDA gaat bij executie de blokken verdelen over de beschikbare SM's en zal proberen zoveel mogelijk blokken op aan een SM toe te wijzen (met blokken die bij elkaar genomen niet over een maximum van 1024 threads heen gaan) en zal vervolgens uit die blokken proberen 4 warps te nemen die tegelijkertijd actief kunnen zijn en deze te schedulen op de SM.

Deze warps hoeven niet uit dezelfde kernel te komen. Er is een scheduler die probeert de SM's zoveel mogelijk actief te houden en als er kernels zijn die niet afhankelijk zijn van elkaar en die klein genoeg zijn om niet alle SM's volledig te belasten, dan kan de scheduler ook meerdere verschillende kernels parallel schedulen op een SM. Zolang alle blokken samen die op de SM gescheduled worden maar niet over de 1024 thread heen gaan.

Maar voor kernels die op grote data items losgelaten worden (zoals ons plaatje van 512x512) is het vrijwel zeker dat alle warps die gescheduled worden uit de kernel komen die daarvoor opgesteld staat.

Dus voor onze RTX A4000 betekent dat de scheduler dus tegelijkertijd 48x4 warps loslaat op het plaatje, waardoor er 6144 threads parallel op het plaatje bezig zijn. Zodra die hun werk gedaan hebben worden de volgende 48x4 warps gelaunched (de SM heeft deze al klaar staan). En dit gaat zo door totdat alle warps in een block uitgevoerd zijn (een block wordt altijd in zijn geheel op een SM uitgevoerd, blokken worden niet gesplitst over meerdere SM's).

Zodra een blok in zijn geheel uitgevoerd is op de SM, dan komt er weer plaats vrij voor nieuwe blokken.

Om nu alle pixels van ons 512x512 plaatje te verwerken moeten er dus 8192 warps gerund worden en dat gaat dus dan 43 iteraties kosten ((512x512) / (32x4x48) = 42.666667).

De instructies in een CUDA kernel zijn in tegenstelling tot de Tensor Cores niet beperkt tot de D = A * B + C operatie (ook wel Matrix Fused Multiply Acculate genoemd). De code is veel generieker van aard. Je kunt een zelfde berekening ook in CUDA schrijven, waarbij je per thread 1 element van A met 1 element van B vermenigvuldigt, daar 1 element van C bij optelt en de uitkomst daarvan dan naar het equivalente element van D te schrijven. Maar je kunt eigenlijk zo'n beetje alle type operaties schrijven in een kernel die je wil, zolang je maar in de gaten houdt dat de code massief parallel uitgevoerd gaat worden.

Iedere CUDA core heeft een bepaalde hoeveelheid onderliggende ALU implementaties, maar hoeveel er van een bepaald type in een SM zit is iets wat NVIDIA op chip niveau bepaald. Bij de RTX A4000 is het bijvoorbeeld zo dat voor iedere CUDA core een 32-bit float ALU aanwezig is, maar er is maar 1 64-bit float ALU per 32 32-bit float ALU's.

Dus code geschreven met FP32 variabelen zal tot 32x sneller uitgevoerd worden dan code met FP64 variabelen.

Alleen in de data center GPUs (zoals de A100) is de verhouding gunstiger 32 en 16.

[Reactie gewijzigd door CrazyJoe op 22 juli 2024 13:57]

[DvanRaai89]

Iedere CUDA core heeft een bepaalde hoeveelheid onderliggende ALU implementaties, maar hoeveel er van een bepaald type in een SM zit is iets wat NVIDIA op chip niveau bepaald. Bij de RTX A4000 is het bijvoorbeeld zo dat voor iedere CUDA core een 32-bit float ALU aanwezig is, maar er is maar 1 64-bit float ALU per 32 32-bit float ALU's.

Ik snap dat er veel minder 64-bit FPU's zijn, en de performance van double precision berekeningen daardoor larger is.
Maar ik begrijp niet hoe dat in verband staat met het volgende:

Dit is FP64 op de Tensor Cores, niet FP64 op de normale CUDA cores.

Double precision berekeningen gebeurt toch niet op de TC's, maar juist op een andere plek in de SM? Daar heb juist die je die 64-bit FPU's voor.
Kunnen wij hieruit opmaken dat (een zelfde gepositioneerde) Blackwell-chip een stuk minder, maar veel grote SM's heeft met evenveel FP64 eenheden, waardoor het totale aantal 64-bit FPU's wat lager ligt; of dat de hoeveelheid SM's toch waarschijnlijk weer stijgt, en Nvidia de verhouding FP64/FP32 verlaagt heeft? Want is uiteindelijk waar de reactie van @uray over ging.
I.i.g. vinden FP64 operaties, zoals ik het altijd begrepen heb niet plaats op de Tensor "Cores".

[CrazyJoe]

Nee, de Tensor Cores zijn aparte units die structureel naast de normale ALUs staan. Bij de RTX A4000 heeft iedere SM 4 Tensor Cores. Echter deze Tensor Cores zijn intern anders opgebouwd dan een typische CUDA core en hebben dus hun eigen ALU implementatie per data type die ze kunnen verwerken (die anders is dan de generieke ALUs die de CUDA cores gebruiken).

Aangezien ze alleen de D=A * B + C Matrix operatie hoeven te ondersteunen zijn ze veel simpeler van opbouw en kunnen daardoor voor een klein aantal variaties van data types voor D, A, B en C geïmplementeerd worden in de chip zonder dat de transistor count heel hoog wordt.

De tweede beperking die Tensor Cores opgelegd krijgen is dat de tile sizes gelimiteerd zijn. Dus de grootte van de matrixen die in een MFMA operatie verwerkt kunnen worden is gelimiteerd. Daarom moet je voor grote matrixen met tegels werken.

CUDA cores hebben die beperking niet. Als jij een thread middels een kernel een volledige array row wil laten verwerken, dan kun je dat doen met een for loop (mits je in de gaten houdt dat iedere thread die gelanceerd wordt voor je kernel een volledige array row zal afwerken en je dus condities in moet bouwen als deze rows niet allemaal even lang zijn, met performance verlies ten gevolg (sommige threads zullen niets doen onder omstandigheden en dat probeer je zoveel mogelijk te vermijden).

Stel bevoorbeeld dat het 512x512 image eigenlijk een 512x512x512 3D matrix is. Het is dan niet ongewoon om de kernel code zo te schrijven dat er meer data in de Z- richting verwerkt wordt per thread i.p.v een 3D grid te definiëren (zeker als de berekening in Z richting steeds met dezelfde data uit een buffer werkt, dat scheelt namelijk memory accesses).

Dit zou in het geval van de Tensor Cores niet werken. Daar moet je voor de data in Z richting ook weer een X/Y tile gebruiken vanwege de manier waarop de Tensor Cores hun data verwerken.

Het schema in de link die je post laat in principe zien dat de ALUs voor CUDA los staan van de Tensor Cores. Alle functionaliteit die de Tensor Cores hebben zit in de Tensor Core blokken, de INT32/FP32/FP64 blokken daarnaast zijn de ALUs voor de CUDA cores.

Zoals het schema laat zien zijn er per Hopper SM vier processing clusters met daarin: 16 INT32 ALUs, 32 FP32 ALUs en 16 FP64 ALUs voor generieke CUDA instructies en 1 Tensor Core blok voor de MFMA operaties.

NVIDIA laat dus niet zien hoe dat Tensor Core blok intern opgebouwd is en de CUDA documentatie over de Tensor Core functies is niet de meest uitgebreide die er is (ben er zelf naar aan het kijken om te bepalen of het voor sommige algoritmes zinnig is om deze in te schakelen voor meer performance met acceptabele precisie verliezen):

https://docs.nvidia.com/c...tml#warp-matrix-functions

Hoe deze indeling van de SMs van Blackwell zal zijn is nog niet bekend gemaakt, dus dat is nog even afwachten.

[dehardstyler]

Volgens de tabel doet de Blackwell chip wel minder FP64 berekeningen per seconde. Is hier een specifieke reden voor? Of is er een cijfertje weggevallen?

[johnbetonschaar]

Ik weet verder weinig van hoe AI modellen precies werken maar vermoedelijk heeft het simpelweg geen toegevoegde waarde om met 64-bit precisie te rekenen voor AI, en kan je de transistors dus gewoon beter aan FP32/8/6/4 besteden? Volgens mij is FP16 zo'n beetje de norm voor dit soort dingen?

[ronaldmathies]

FP64 wordt relatief weinig gebruikt, veel modellen gebruiken of FP32 of FP16. Het heeft nogal gevolgen voor je geheugen verbruik of je voor 64, 32 of 16 kiest, en het is maar de vraag if hogere precisie wel waarde oplevert.

Hogere precisie is leuk als je je model optimaal getrained wilt hebben, maar vaak gaat het om marginale verbeteringen, terwijl je geheugen verbruik 2x tot wel 4x zo hoog is.

Daarnaast kost het trainen van een model op hogere precisie ook veel meer tijd.

[ThanosReXXX]

Wow, dat wordt echt een beest van een console, die nieuwe Switch.

Maar even serieus: wel mooi dat ze de chip als eerbetoon vernoemd hebben naar Harold Blackwell, de allereerste Afro-Amerikaanse geleerde ooit opgenomen/ingewijd in de National Academy of Sciences:

Named in honor of David Harold Blackwell — a mathematician who specialized in game theory and statistics, and the first Black scholar inducted into the National Academy of Sciences — the new architecture succeeds the NVIDIA Hopper™ architecture, launched two years ago.

https://nvidianews.nvidia...er-a-new-era-of-computing

[Reactie gewijzigd door ThanosReXXX op 22 juli 2024 13:57]

[ymmv]

Blackwell was 46 jaar oud toen hij als 1e zwarte wetenschapper toetrad tot de National Academy of Sciences. Hij was toen al 20 jaar universiteitsprofessor en natuurlijk geen student.

[ThanosReXXX]

Ik had mezelf al gecorrigeerd voordat jij reageerde:

Ik ben zelf tweetalig, maar doordat ik al zo lang in Nederland woon, mis ik heel soms even de context en pak ik de verkeerde vertaling. Scholar kan zowel student als geleerde betekenen, vandaar.

[Reactie gewijzigd door ThanosReXXX op 22 juli 2024 13:57]

[oli4100]

De impliciete performance per watt stijging is indrukwekkend; als we uitgaan van de throughput, bijv. fp16:
990/700=1.4 tops / watt
2250/1000=2.25 tops / watt

Dat is 60% sneller, best indrukwekkend, helemaal omdat het op een vergelijkbare node is gedaan (4 nm).

[Paprika]

Efficiënter zou denk ik de juiste verwoording zijn in dit geval. De ruwe prestaties zouden immers met 127% zijn toegenomen.

[Alxndr]

@Trygve nast FP8 is de eenheid ineens tops en geen tflops, dit lijkt me een typo?

En met een tdp van 1000W per blackwell betekent dat dat die grace cpu zelf ook nog eens 700W kan verstoken? Wow.


On topic:
Ik las afgelopen jaar dat Nvidia's marge op AI 900% is, klopt dat echt en wie kan er met ze gaan concurreren om dat naar een normaler niveau te brengen? Helaas heb ik m'n aandelen aan het begin van de oorlog allemaal verkocht... Weer lekkere timing

[Reactie gewijzigd door Alxndr op 22 juli 2024 13:57]

[Tomas Hochstenbach]

Tflops gaat specifiek over floatingpoints en in principe geldt de FP8-rekensnelheid ook voor INT8, waarbij je over Tops zou spreken. Het is dus niet per se fout maar ik heb er voor de consistentie ook Tflops voor gemaakt.

[Mellow Jack]

In deze lijken ze daadwerkelijk iets te doen wat op LLM modellen lijkt te zijn aangepast. In het verleden had ik altijd het gevoel dat dit soort kaarten niets meer waren dan bijv een 4090 met wat extra geheugen. Dus ja, als je vanuit daar gaat rekenen dan kom je idd uit op een flinke marge

[Relaxations]

Sinds begin dit jaar staan ze ook alweer +80%, je kunt nog steeds (weer) instappen natuurlijk...
Zelf was ik ook liever eerder ingestapt, maar ik verwacht aankomende jaren (helaas, dubbel gevoel nu) nog weinig concurrentie, dus zou zomaar nog tijdje omhoog kunnen gaan.

[voxilla]

Misschien beter om te vergelijken met de H200, die heeft meer en rapper geheugen:
141GB / 4,8TB/s
De hoeveelheid TFLOP/s per TB/s is van groot belang, en dat gaat eigenlijk achteruit.
De vraag is ook in hoeverre de 2 GPU dies een beperking zijn qua praktisch rekenkracht tov theoretische getallen.

[Zezura]

“zwevendekommagetallen“ ik ken ze als floatingpoints oftewel floats. Dat was even hersenen gebruiken.. nog nooit ergens de Nederlandse vertaling ervan gelezen. Eerste keer voor alles.

[PrettigGestoord]

Ik moest ook even denken...wat heb ik nou gelezen?

[TPar]

Ja, de laatste tijd slaat men hier wel heel hard door met het vermijden van Engelse termen. Ook op de podcast. Wordt lichtjes irritant en komt me zelfs wat xenofoob over (dit is natuurlijk wat overdreven). Laat de Fransen en Duitsers begaan en gebruik gewoon de Engelse termen.

[Geo1984]

The question is - "does it run Crysis?"

[Tweakriez]

The question is: vind iemand deze opmerking überhaupt nog origineel/grappig

[HKS-Skyline]

Ik zou heel benieuwd zijn wat voor resoluties en framerates mogelijk zouden zijn in moderne games als je een dergelijke chip op een normale videokaart zou kunnen plakken en op een of andere manier zou kunnen voorzien van de benodigde bandbreedte, stroom en koeling. (en uiteraard drivers)

[Cergorach]

Dat ligt er aan over welke 'moderne games' je het hebt. Een Immortals of Aveum is iets andere koek dan een F1 22... Wat voor engine wordt er gebruikt, hoe goed heeft de developer het geoptimaliseerd? Je blindstaren op de performance van zware game X is imho gekkenwerk, want volgende week/maand/jaar zal er vast een developer een game op de markt zetten die nog minder goed is geoptimaliseerd. En tenzij je echt een fanaat bent, is specifiek een highend videokaart kopen voor een specifiek spel een te dure aangelegenheid voor het gros van de gamers.

[Zoijar]

Niet veel, aangezien een moderne game meestal geen bizar grote matrix multiplies doet.